OSLR (Optimized Link-State Routing): Difference between revisions

From
Jump to navigation Jump to search
No edit summary
No edit summary
Line 1: Line 1:
'''Optimized Link State Routing''', kurz OLSR, ist ein Routingprotokoll für mobile [[Ad-hoc-Netz|Ad-hoc-Netze]], das eine an die Anforderungen eines
Coming soon..
mobilen drahtlosen LANs angepasste Version des [[Link-State|Link State Routing]] darstellt. Es wurde von der [[IETF]] mit dem RFC 3626 standardisiert.
[[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]]
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.

== 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/>
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.

== 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.]]

== Weblinks ==
* [http://rfc.net/rfc3626.txt RFC3626]
* 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

[[Kategorie:Netzwerkprotokoll]]
[[Kategorie:Freifunk-Netzwerk]]

[[en:Optimized Link State Routing protocol]]
[[es:Optimized Link State Routing protocol]]
[[fr:Optimized link state routing protocol]]
[[it:OLSR]]
[[pt:OLSR]]





Revision as of 15:40, 17 July 2007

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. right|thumb|200px|Das Visualisierungsplugin "OLSR-Viz" der FreifunkFirmware bei der Arbeit Bei diesem verteilten flexiblen Routingverfahren 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.

Optimierungen

OLSR ist ein optimiertes Link-State-Routingprotokoll, das auf die Anforderungen von 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 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 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.

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

Weblinks

Kategorie:Netzwerkprotokoll Kategorie:Freifunk-Netzwerk

en:Optimized Link State Routing protocol es:Optimized Link State Routing protocol fr:Optimized link state routing protocol it:OLSR pt:OLSR


Java example

Flash Implementation