OSLR (Optimized Link-State Routing): Difference between revisions
| (14 intermediate revisions by the same user not shown) | |||
| Line 13: | Line 13: | ||
{|width="100%" border="0" |
{|width="100%" border="0" |
||
|- |
|- |
||
|[[Image:Fluten.JPG|thumb| |
|[[Image:Fluten.JPG|thumb|center|600px|Fluten der TC-Nachrichten]] |
||
|- |
|- |
||
|} |
|} |
||
| Line 30: | Line 30: | ||
==Beispiel== |
==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== |
==Links== |
||
[http://www.dpunkt.de/mobile/code/olsr.html Java 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
