Optimiertes Link -Status -Routing -Protokoll

"OLSR" leitet hier weiter. Für die gewöhnliche Regression mit den kleinsten Quadraten siehe Gewöhnliche kleinste Quadrate.
Diagramm des OLSR -Datenflusss.

Das Optimiertes Link -Status -Routing -Protokoll (OLSR)[1] ist ein IP Routing -Protokoll optimiert für Mobile Ad -hoc -Netzwerke, was auch für andere verwendet werden kann drahtlose Ad -hoc -Netzwerke. OLSR ist proaktiv Link-State-Routing-Protokoll, was verwendet hallo und Topologiekontrolle (TC) Nachrichten zum Entdecken und Verbrennen von Link -Statusinformationen im gesamten mobilen Ad -hoc -Netzwerk. Einzelne Knoten verwenden diese Topologieinformationen, um die nächsten Hop -Ziele für alle Knoten im Netzwerk mit den kürzesten Hop -Weiterleitungspfaden zu berechnen.

Merkmale spezifisch für OLSR

Link-State-Routing-Protokolle wie z. öffne den kürzesten Weg zuerst (OSPF) und Zwischensystem zum Zwischensystem (Is-is) wählen a Bezeichnender Router Auf jedem Link zur Durchführung von Überschwemmungen von Topologieinformationen. In drahtlosen Ad -hoc -Netzwerken gibt es unterschiedliche Begriffe eines Links, Pakete können und gehen dieselbe Schnittstelle aus. Daher ist ein anderer Ansatz erforderlich, um den Überflutungsprozess zu optimieren. Mit Hello-Nachrichten entdeckt das OLSR-Protokoll an jedem Knoten 2-Hop-Nachbarinformationen und führt eine verteilte Wahl von einem Satz von durch Multipoint -Relais (MPRS). Knoten wählen MPRs so aus, dass es einen Weg zu jedem seiner 2-Hop-Nachbarn über einen als MPR ausgewählten Knoten gibt. Diese MPR -Knoten beziehen und leiten TC -Nachrichten, die die MPR -Selektoren enthalten. Dieses Funktionieren von MPRS macht OLSR auf verschiedene Arten aus anderen Link -Status -Routing -Protokollen eindeutig: Der Weiterleitungspfad für TC -Nachrichten wird nicht zwischen allen Knoten weitergegeben, sondern variiert je nach Quelle, nur eine Untergruppe von Knoten -Quellen -Link -Statusinformationen, nicht alle Links eines Knotens werden beworben, aber nur diejenigen, die MPR -Auswahlen repräsentieren.

Da das Link-State-Routing erfordert, dass die Topologie-Datenbank über das Netzwerk synchronisiert wird, führen OSPF und IS-IS-IS-IS-Überschwemmungen mit einem zuverlässigen Algorithmus durch. Ein solcher Algorithmus ist sehr schwer für Ad -hoc -drahtlose Netzwerke zu entwerfen, sodass sich OLSR nicht mit Zuverlässigkeit beschäftigt. Es überflutet einfach die Topologiedaten oft genug, um sicherzustellen, dass die Datenbank über längere Zeitraum nicht unsynchronisiert bleibt.

Multipoint -Relais

Multipoint Relays (MPRS) Relay -Nachrichten zwischen Knoten. Sie haben auch die Hauptaufgabe in Routing und Auswahl der richtigen Route von einer beliebigen Quelle zu einem gewünschten Zielknoten.

MPRS bewerben Link-State-Informationen für ihre MPR-Selektoren (ein als MPR ausgewählter Knoten) in ihren Steuermeldungen regelmäßig. MPRs werden auch verwendet, um eine Route von einem bestimmten Knoten zu jedem Ziel in der Routenberechnung zu bilden. Jeder Knoten überträgt regelmäßig eine Hallo -Nachricht für die Link -Erfassungs-, Nachbarerkennungs- und MPR -Auswahlprozesse.[2]

Vorteile

Als proaktives Protokoll werden Routen zu allen Zielen innerhalb des Netzwerks vor der Verwendung bekannt und gewartet. Die verfügbaren Routen in der Standard -Routing -Tabelle können für einige Systeme und Netzwerkanwendungen nützlich sein, da mit der Suche nach einer neuen Route keine Routenerfassungsverzögerung verbunden ist.

Der erzeugte Routing -Overhead, der im Allgemeinen größer als der eines reaktiven Protokolls ist, nimmt jedoch nicht mit der Anzahl der erzeugten Routen zu.

Standard- und Netzwerkrouten können durch HNA -Nachrichten in das System eingefügt werden, die eine Verbindung zum Internet oder anderen Netzwerken innerhalb des OLSR ermöglichen Manet Wolke. Netzwerkrouten sind etwas, was reaktive Protokolle derzeit nicht gut ausgeführt werden.

Zeitüberschreitungswerte und Gültigkeitsinformationen sind in den Nachrichten enthalten, die Informationen vermitteln, die es ermöglichen, dass unterschiedliche Timerwerte an unterschiedlichen Knoten verwendet werden.

Kritik

Die ursprüngliche Definition von OLSR enthält keine Bestimmungen für die Erfindung der Verbindungsqualität. Es wird einfach davon ausgegangen, dass kürzlich ein Link abgelaufen ist, wenn eine Reihe von Hello -Paketen eingegangen sind. Dies setzt voraus, dass Links bi-modal sind (entweder funktionieren oder fehlgeschlagen), was bei drahtlosen Netzwerken nicht unbedingt der Fall ist, wo Links häufig intermediäre Paketverlustraten aufweisen. Implementierungen wie die Open Source OLSRD (häufig verwendet auf Linux-Basierte Netzrouter) wurden (ab V. 0.4.8) mit Verbindungsqualitätserfassung erweitert.

Als proaktives Protokoll verwendet OLSR Strom- und Netzwerkressourcen, um Daten über möglicherweise nicht verwendete Routen zu verbreiten. Dies ist zwar kein Problem für Kabelzugriffspunkte und Laptops, aber es macht OLSR für Sensornetzwerke, die die meiste Zeit versuchen, zu schlafen, ungeeignet. Für kleine kabelgebundene Zugangspunkte mit niedrig Zentralprozessor Kraft, die Open Source Olsrd Das Projekt zeigte, dass groß angelegte Netznetzwerke mit OLSRD auf Tausenden von Knoten mit sehr wenig CPU -Strom eingeschaltet werden können 200MHz Eingebettete Geräte.

Als Link-State-Protokoll erfordert OLSR eine einigermaßen große Menge an Bandbreite und CPU -Strom zur Berechnung optimaler Pfade im Netzwerk. In den typischen Netzwerken, in denen OLSR verwendet wird (die nur selten einige Hundert Knoten überschreiten), scheint dies kein Problem zu sein.

Durch die Verwendung von MPRS zur Überschwemmungstopologieinformationen entfernt OLSR einige der Redundanz des Überflutungsprozesse[3] -Allerdings ist der MPR-Mechanismus sich selbst (was bedeutet, dass bei Paketverlusten einige Knoten, die kein Paket erneut übertragen hätten, dies tun können).

Mitteilungen

OLSR nutzt "Hallo" Nachrichten, um seine einen Hop -Nachbarn und seine beiden Hop -Nachbarn durch ihre Antworten zu finden. Der Absender kann dann seine Multipoint Relays (MPR) basierend auf dem einen Hop -Knoten auswählen, der die besten Routen zu den beiden Hopfenknoten bietet. Jeder Knoten hat auch einen MPR -Selektorsatz, der Knoten aufzählt, die ihn als MPR -Knoten ausgewählt haben. OLSR verwendet Topology Control -Nachrichten (TC) sowie die MPR -Weiterleitung, um Nachbarinformationen im gesamten Netzwerk zu verbreiten. Host- und Netzwerkverband (HNA) Nachrichten werden von OLSR verwendet, um Netzwerk -Routenanzeigen auf die gleiche Weise zu verbreiten, wie TC -Nachrichten Hostrouten werben.

Hallo

Olsr-hello-packet.png

Topology Control (TC)

Olsr-tc-packet.png

Andere Ansätze

Das Problem des Routings in ad -hoc -drahtlosen Netzwerken wird aktiv erforscht, und OLSR ist nur eine von mehreren vorgeschlagenen Lösungen. Für viele ist nicht klar, ob ein ganz neues Protokoll benötigt wird oder ob OSPF könnte mit Unterstützung von drahtlosen Schnittstellen erweitert werden.[4][5]

In Bandbreiten- und Power-Hart-Umgebungen ist es interessant, das Netzwerk schweigen zu lassen, wenn kein Datenverkehr aufgeleitet werden muss. Reaktive Routing -Protokolle halten keine Routen auf, sondern bauen sie auf Bedarf auf. Da Link-State-Protokolle eine Datenbanksynchronisation erfordern, verwenden solche Protokolle typischerweise den Abstandsvektoransatz, wie in Aodv und DSDV, oder mehr Ad -hoc -Ansätze, die nicht unbedingt optimale Wege aufbauen, wie z. Dynamisches Quellenrouting.

Weitere Informationen finden Sie in der Liste der Ad -hoc -Routing -Protokolle.

OLSR Version 2

OLSRV2 wurde im April 2014 von der IETF veröffentlicht.[6] Es unterhält viele der wichtigsten Merkmale des Originals, einschließlich MPR -Auswahl und -verbreitung. Wichtige Unterschiede sind die Flexibilität und das modulare Design mithilfe gemeinsamer Komponenten: Paketformatpaketbb und NHDP. Diese Komponenten sind so konzipiert, dass sie bei IETF -Manet -Protokollen der nächsten Generation gemeinsam sind. Es gibt auch Unterschiede in der Behandlung mehrerer Adresse und Schnittstellen -fähiger Knoten zwischen OLSR und OLSRV2.

Implementierungen

  • Olsr.org - herunterladbarer Code für OLSR unter Linux, Windows, Mac OS X, FreeBSD, NetBSD und OpenBSD Systeme. Funktioniert viel Dokumentation, einschließlich einer informativen Übersicht über verwandte Arbeiten.
  • NRL-OLSR -Open Source-Code von NRL-OLSR. Funktioniert unter Windows, MacOS, Linux und verschiedenen eingebetteten PDA -Systemen wie Arm/Zaurus und PocketPC sowie Simulationsumgebungen NS2 und opnet., http://cs.itd.nrl.navy.mil/focus/
  • SourceForge.net-olsr - Erstellt durch Moviquity und basierend auf Studien innerhalb des Projekt -Arbeitspads bietet es einen Code in C#, um ein Manet (ad hoc, meshnet) mit Protokoll -OLSR bereitzustellen. Für WM 6 entwickelt, win XP und kann mit .NET Framework und Compact an andere Plattformen angepasst werden. http://sourceforge.net/projects/wmolsr/

Siehe auch

Verweise

  1. ^ RFC 3626
  2. ^ Leistungsvergleich des drahtlosen mobilen Adhoc -Netzwerkroutings - Arun Kumar, Lokanatha C. Reddy, Prakash S. Hiremath[Klarstellung erforderlich]
  3. ^ M. Abolhasan; B. Hagelstein; J. C.-P. Wang (2009). "Reale Leistung der aktuellen proaktiven Multi-Hop-Netzprotokolle". {{}}: Journal zitieren erfordert |journal= (Hilfe)
  4. ^ Erweiterungen an OSPF zur Unterstützung des mobilen Ad-hoc-Netzwerks, Madhavi Chandra, Abhay Roy, März-10, RFC 5820
  5. ^ MANET-Erweiterung von OSPF mit CDS-Überschwemmungen, Richard Ogier, Phil Spagnolo, August09, RFC 5614
  6. ^ RFC 7181

Externe Links