OSLR (Optimized Link-State Routing): Difference between revisions
Jump to navigation
Jump to search
No edit summary |
|||
| (41 intermediate revisions by the same user not shown) | |||
| Line 1: | Line 1: | ||
==Was ist OLSR ?== |
|||
'''Optimized Link State Routing''', kurz OLSR, ist ein Routingprotokoll für mobile Ad-hoc-Netze, das eine an die Anforderungen eines |
|||
mobilen drahtlosen LANs angepasste Version des Link State Routing darstellt. Es wurde von der [[IETF]] mit dem RFC 3626 standardisiert. |
|||
Optimized Link State Routing ist ein Routingprotokoll für mobile Ad-hoc-Netze, das eine an die Anforderungen eines |
|||
[[Bild:Olsr-map_nogps_seen_from_10.127.0.8_on_2006-12-10_2300CEST.png|right|thumb|200px|Das Visualisierungsplugin "OLSR-Viz" der FreifunkFirmware bei der Arbeit]] |
|||
mobilen drahtlosen LANs angepasste Version des Link State Routing darstellt. Es wurde von der IETF unter RFC 3626 standardisiert. |
|||
Bei diesem verteilten flexiblen [[Routing]]verfahren ist allen Routern die vollständige [[Topologie (Rechnernetz)|Netztopologie]] bekannt, sodass sie von Fall zu Fall den kürzesten Weg zum Ziel festlegen können. Als [[Mobiles Ad-hoc-Netz#proaktive Verfahren|proaktives Routingprotokoll]] hält es die dafür benötigten Informationen jederzeit bereit. |
|||
Bei diesem verteilten flexiblen Routing verfahren ist allen Routern die vollständige Netztopologie bekannt, sodass sie von Fall zu Fall den kürzesten Weg zum Ziel festlegen können. Als proaktives Routingprotokoll hält es die dafür benötigten Informationen jederzeit bereit. |
|||
==Arbeitsweise== |
|||
== Arbeitsweise == |
|||
Topologieentdeckung erfolgt bei OLSR über zwei Arten von Nachrichten: ''HELLO''- und ''Topology-Control (TC)-Nachrichten''. HELLO-Nachrichten dienen zum Link Sensing, zur Nachbarentdeckung und zur Mitteilung der MPR-Wahl. Die TC-Nachrichten dienen dazu, die so gewonnenen Informationen über mögliche Verbindungen im Netz zu verteilen.<br/> |
Topologieentdeckung erfolgt bei OLSR über zwei Arten von Nachrichten: ''HELLO''- und ''Topology-Control (TC)-Nachrichten''. HELLO-Nachrichten dienen zum Link Sensing, zur Nachbarentdeckung und zur Mitteilung der MPR-Wahl. Die TC-Nachrichten dienen dazu, die so gewonnenen Informationen über mögliche Verbindungen im Netz zu verteilen.<br/> |
||
Ein im Netz teilnehmendes Gerät (Knoten) entdeckt seine 1-Hop- und 2-Hop-Nachbarn über die periodisch verschickten HELLO-Nachrichten. Diese enthalten die IP-Adressen der bereits |
Ein im Netz teilnehmendes Gerät (Knoten) entdeckt seine 1-Hop- und 2-Hop-Nachbarn über die periodisch verschickten HELLO-Nachrichten. Diese enthalten die IP-Adressen der bereits |
||
bekannten 1-Hop-Nachbarn sowie den Status der Verbindung zu ihnen und werden nicht weitergeleitet. Aus seinen 1-Hop-Nachbarn wählt jeder Knoten ''Multipoint Relays (MPRs)'', so dass er über sie jeden seiner 2-Hop-Nachbarn erreichen kann. Die MPRs sind die Knoten, die |
bekannten 1-Hop-Nachbarn sowie den Status der Verbindung zu ihnen und werden nicht weitergeleitet. Aus seinen 1-Hop-Nachbarn wählt jeder Knoten ''Multipoint Relays (MPRs)'', so dass er über sie jeden seiner 2-Hop-Nachbarn erreichen kann. Die MPRs sind die Knoten, die Broadcast-Nachrichten weiterleiten, was das Fluten effizienter macht. Sie sind es auch, die die TC-Nachrichten erstellen, die eine Liste mindestens der Knoten enthalten, von denen sie als MPRs gewählt wurden, so dass für jeden Knoten mindestens eine Möglichkeit bekannt ist, wie er erreicht werden kann. Diese TC-Nachrichten werden im gesamten Netzwerk verteilt. Auf diese Weise erhält jeder Knoten eine Vorstellung des Netzwerkes und kann Routingtabellen erstellen. |
||
== Optimierungen == |
|||
OLSR ist ein optimiertes [[Link-State]]-Routingprotokoll, das auf die Anforderungen von [[Mobiles Ad-hoc-Netz|mobilen Ad-hoc-Netzen]] angepasst wurde, jedoch auch in anderen Strukturen Anwendung findet. |
|||
Hier gibt es folgende Hauptansätze zur weiteren Entwicklung und Optimierung: |
|||
=== Auto-Assignment von IP-Adressen === |
|||
Kritisch bei dem OLSR Protocol ist derzeit, dass kein Auto-Assignment von IP-Adressen möglich ist. Um zu vermeiden, dass die IP Adressen der Wireless Clienten (z.B. Laptops) doppelt vergeben werden, werden diese in manchen Projekten bzw. der Router Firmware zentral vergeben. Damit wird auch der Internetzugang nur nach Registrierung möglich. Es wäre auch möglich, die IP-Vergabe dezentral zu organisieren und an der MAC-Adresse der Wlan-karte zu orientieren. Dazu benötigt es noch ein Update der OLSR-Software. |
|||
In einigen [[Freifunk]]-Initiativen werden an zentrale (immobile) OLSR-Knoten hierarchisch Pools von IP-Adressen vergeben, die diese wiederum per [[Dynamic Host Configuration Protocol|DHCP]] an die umliegenden (mobilen) Knoten vergeben. |
|||
=== End-to-End Encryption === |
|||
Derzeit kann jeder Node sehen, was die anderen Nodes im Netzwerk durchleiten bzw. welche Webseiten sie anfordern oder Dateien sie laden. Ist eine Route erstmal gefunden, ist die geplante Optimierung, sie mit End-to-End Verschlüsselung abzusichern. |
|||
=== Hybrider Zugang === |
|||
Vermaschte Netzwerke erfordern OLSR-Knoten. Dennoch soll den Usern, die kein OLSR auf dem Laptop oder PC installiert haben, der Wireless-Zugang durch den normalen Funk-Radius möglich gemacht werden. Dazu müsste ein OLSR-Knoten nicht nur Pakete von OLSR-Knoten weiterleiten, sondern auch von normal konfigurierten Wireless-Karten im definierten Umkreis des Nodes. Ein OLSR-Knoten würde dabei eine IP-Adresse aus einem ihm zentral zugeteilten Pool per [[DHCP]] an einen nicht OLSR-fähigen Knoten zuteilen und diesem als Gateway in das OLSR-Netzwerk dienen. Allerdings ist ein solchermaßen angebundener Client an das DHCP-[[Lease]] des Knoten gebunden und somit nur begrenzt zu Roaming fähig. Jede Bewegung in den Einzugsbereich eines anderen Knoten führt beim Ablaufen des DHCP-Lease zu einer anderen IP-Adresse, so dass beispielsweise Streaming-Anwendungen unterbrochen werden. Dieses Problem wäre aber lösbar, wenn ein Auto-Assignment eingeführt werden würde. |
|||
=== Bandbreitenmanagement === |
|||
Ziel in ferner Zukunft ist, wenn die Software sowohl für Wireless Chips im Laptop als auch im Router einsatzfähig ist, ein [[Qos|Bandbreitenmanagement]] wie z.b. in Protokoll [[SrcRR]] zu implementieren à la Netlimiter, bei der die zur Verfügung stehende Bandbreite aufgeteilt und dynamisch genutzt werden kann für die drei Nutzergruppen: Owner, OLSR-Nodes ein paar Hops entfernt, und schließlich den Non-OLSR-Nodes in der direkten Umgebung des Wireless Routers. |
|||
Somit gäbe es ein Breitbandmanagement für den Betreiber des Nodes und seine private, nicht geteilte Bandbreite, die weiterzuleitende Bandbreite für andere OLSR-Nodes und eine Bandbreite für normale Nodes in der direkten Umgebung des Acess Points, die nicht OLSR benutzen. |
|||
=== Wireless-Karten als Router betreiben === |
|||
Derzeit ist für einen Router und einen Laptop mit Wireless Chip eine unterschiedliche Software notwendig. Elegant wäre es, wenn die OLSR Installierungssoftware sowohl auf einen Router wie auch auf dem Laptop mit einem Wireless Chip aufgespielt werden kann. Es gibt erste Ansätze, die über die Software regeln wollen, dass jeder Wireless Chip einen Router simuliert, auf dem dann auch OLSR unterstützt wird. |
|||
* http://hostap.epitest.fi/ |
|||
=== Umstellung auf IPv6 === |
|||
Wird gerade diskutiert. |
|||
=== Feinoptimierungen === |
|||
* Nicht jeder Node erstellt LSAs, sondern nur die als Multipoint Relay (MPR) markierten. |
|||
* Es werden so wenig Kontrollmeldungen wie möglich über das Netzwerk verschickt. |
|||
* MPRs können sich entscheiden, lediglich Informationen über die Knoten zwischen sich und den MPRs zu versenden, die sie ausgewählt haben. |
|||
== Vergleich mit anderen Ad-hoc-Routingprotokollen == |
|||
* [[:en:Ad hoc routing protocol list|Ad hoc routing protocol list (en)]] |
|||
* [[Ad-hoc On-demand Distance Vector|AODV]] |
|||
* [[B.A.T.M.A.N.]] |
|||
{|width="100%" border="0" |
|||
== Weblinks == |
|||
|- |
|||
* [http://rfc.net/rfc3626.txt RFC3626] |
|||
|[[Image:Fluten.JPG|thumb|center|600px|Fluten der TC-Nachrichten]] |
|||
* aktuelle Weiterentwicklungen von olsr.org werden auf http://olsr.funkfeuer.at gesammelt |
|||
|- |
|||
* Implementation für [[Linux]], [[FreeBSD]], [[Windows]] und [[Mac OS]]: [http://www.olsr.org www.olsr.org (offizielle Homepage des OLSRd)] |
|||
|} |
|||
* Online Simulation einiger Routing Protokolle: [http://www.dpunkt.de/mobile www.dpunkt.de/mobile] ([[Java-Applet]]) |
|||
* Praktische Anwendung in freien Funknetzen: [http://www.olsrexperiment.de www.olsrexperiment.de (Berlin)] , [http://www.openwireless.ch www.openwireless.ch (St. Gallen)] |
|||
* Organisatorische Plattform im Internet [http://olsr.freifunk.net olsr.freifunk.net (deutsche Plattform für OLSR-Funknetzwerke)] |
|||
* [http://freifunk.net/wiki/OLSR OSLR_erklärt: An die RFC angelehnte, einfache Funktionsbeschreibung zu OLSR] |
|||
* [http://www.meshnode.org Meshnode] - OLSR auf linux embedded Hardware |
|||
Ablauf in 5 Schritten: |
|||
[[Kategorie:Netzwerkprotokoll]] |
|||
[[Kategorie:Freifunk-Netzwerk]] |
|||
*Suchen von Nachbarknoten |
|||
[[en:Optimized Link State Routing protocol]] |
|||
**jeder Knoten sendet periodisch so genannte HELLO-Pakete |
|||
[[es:Optimized Link State Routing protocol]] |
|||
**Multipoint relay bestimmen |
|||
[[fr:Optimized link state routing protocol]] |
|||
*Messen der Distanzen zu den Nachbarn |
|||
[[it:OLSR]] |
|||
**ein Knoten sendet Echo-Pakete an alle Nachbarn, die diese sofort beantworten müssen |
|||
[[pt:OLSR]] |
|||
**die Zeit, die zwischen Echo-Paket und Antwort vergeht, kann als Distanz benutzt werden |
|||
*Erzeugen eines Kontrollpakets (engl.: Topology Control Message, TC), |
|||
*Senden des Kontrollpakets an alle Knoten des Netzwerks (Multipoint relay) |
|||
*Erstellen eines Abbilds der Netzwerktopologie |
|||
==Beispiel== |
|||
{|width="100%" border="0" |
|||
|- |
|||
|[[Image:Bei1.JPG|thumb|left|500px|]] |
|||
|- |
|||
|} |
|||
{|width="100%" border="0" |
|||
|- |
|||
|[[Image:Bei2.JPG|thumb|left|500px|]] |
|||
|- |
|||
|} |
|||
{|width="100%" border="0" |
|||
|- |
|||
|[[Image:Bei3.JPG|thumb|left|500px|]] |
|||
|- |
|||
|} |
|||
{|width="100%" border="0" |
|||
|- |
|||
|[[Image:Bei4.JPG|thumb|left|500px|]] |
|||
|- |
|||
|} |
|||
{|width="100%" border="0" |
|||
|- |
|||
|[[Image:Bei5.JPG|thumb|left|500px|]] |
|||
|- |
|||
|} |
|||
{|width="100%" border="0" |
|||
|- |
|||
|[[Image:Bei6.JPG|thumb|left|500px|]] |
|||
|- |
|||
|} |
|||
{|width="100%" border="0" |
|||
|- |
|||
|[[Image:Bei7.JPG|thumb|left|500px|]] |
|||
|- |
|||
|} |
|||
==Links== |
|||
[http://www.dpunkt.de/mobile/code/olsr.html Java example] |
|||
[http://www.dpunkt.de/mobile/code/olsr.html Java Implementation] |
|||
[http://hipercom.inria.fr/olsr/mpr-flooding.html Flash Implementation] |
[http://hipercom.inria.fr/olsr/mpr-flooding.html Flash Implementation] |
||
Latest revision as of 17:05, 17 July 2007
Was ist OLSR ?
Optimized Link State Routing ist ein Routingprotokoll für mobile Ad-hoc-Netze, das eine an die Anforderungen eines mobilen drahtlosen LANs angepasste Version des Link State Routing darstellt. Es wurde von der IETF unter RFC 3626 standardisiert. Bei diesem verteilten flexiblen Routing verfahren ist allen Routern die vollständige Netztopologie bekannt, sodass sie von Fall zu Fall den kürzesten Weg zum Ziel festlegen können. Als proaktives Routingprotokoll hält es die dafür benötigten Informationen jederzeit bereit.
Arbeitsweise
Topologieentdeckung erfolgt bei OLSR über zwei Arten von Nachrichten: HELLO- und Topology-Control (TC)-Nachrichten. HELLO-Nachrichten dienen zum Link Sensing, zur Nachbarentdeckung und zur Mitteilung der MPR-Wahl. Die TC-Nachrichten dienen dazu, die so gewonnenen Informationen über mögliche Verbindungen im Netz zu verteilen.
Ein im Netz teilnehmendes Gerät (Knoten) entdeckt seine 1-Hop- und 2-Hop-Nachbarn über die periodisch verschickten HELLO-Nachrichten. Diese enthalten die IP-Adressen der bereits
bekannten 1-Hop-Nachbarn sowie den Status der Verbindung zu ihnen und werden nicht weitergeleitet. Aus seinen 1-Hop-Nachbarn wählt jeder Knoten Multipoint Relays (MPRs), so dass er über sie jeden seiner 2-Hop-Nachbarn erreichen kann. Die MPRs sind die Knoten, die Broadcast-Nachrichten weiterleiten, was das Fluten effizienter macht. Sie sind es auch, die die TC-Nachrichten erstellen, die eine Liste mindestens der Knoten enthalten, von denen sie als MPRs gewählt wurden, so dass für jeden Knoten mindestens eine Möglichkeit bekannt ist, wie er erreicht werden kann. Diese TC-Nachrichten werden im gesamten Netzwerk verteilt. Auf diese Weise erhält jeder Knoten eine Vorstellung des Netzwerkes und kann Routingtabellen erstellen.
Ablauf in 5 Schritten:
- Suchen von Nachbarknoten
- jeder Knoten sendet periodisch so genannte HELLO-Pakete
- Multipoint relay bestimmen
- Messen der Distanzen zu den Nachbarn
- ein Knoten sendet Echo-Pakete an alle Nachbarn, die diese sofort beantworten müssen
- die Zeit, die zwischen Echo-Paket und Antwort vergeht, kann als Distanz benutzt werden
- Erzeugen eines Kontrollpakets (engl.: Topology Control Message, TC),
- Senden des Kontrollpakets an alle Knoten des Netzwerks (Multipoint relay)
- Erstellen eines Abbilds der Netzwerktopologie
