Internet Protokolle II

Transkript

1 Lecture 4 Internet Protokolle II Routing in Wireless d-hoc Networks Thomas uhrmann Part I Network rchitectures omputer Science epartment Technical University Munich

2 Mobile d-hoc Networks (MNT) Hoch dynamische Netztopologie urch Mobilität der eräte und sich verändernde igenschaften des drahtlosen Kanals (fading) uch Partitionierung des Netzes möglich adurch Paketverluste symmetrische Verbindungen Verbindungsqualität kann in beiden Richtungen stark unterschiedlich sein rahtloses Medium ist roadcast-medium Versteckte und ausgelieferte ndgeräte egrenzte atterieleistung der mobilen eräte Verstärkt durch Signalisierungsverkehr z.. des Routingprotokolls egrenzte andbreite Verstärkt durch Signalisierungsverkehr z.. des Routingprotokolls und M-Protokoll (Kollisionen, versteckte ndgeräte etc.) Zeitliche Synchronisation der eräte schwierig rschwert z.. nergiesparmodi der eräte (z.. periodisches Schlafen) Sicherheitsmechanismen schwierig anzuwenden bhören des drahtlosen Kanals Jedes erät muss Pakete an andere weiterleiten können Internet Protocols II Thomas uhrmann, Technical University Munich, ermany 2

3 Routing Recap from Last Term (1) other Router Router other Internet Router other 9 Internet Protocols II Thomas uhrmann, Technical University Munich, ermany 3

4 Routing Recap from Last Term (2) istance Vector Routers exchange their routing tables No additional state Slow adaptation to failed links usfall 1 : 2 : 2 : 2 : 2 : 3 : 3 : 2 : 2 : 3 : 3 : Link State Routers flood and store full topology ijkstra to calculate routing table Responds flexibly to topology changes High memory, bandwidth, and processing cost 1. Schritt 3 : 3 : 3 : 3 : 2. Schritt 3. Schritt 4. Schritt 4 : 4 : 5 : Internet Protocols II Thomas uhrmann, Technical University Munich, ermany 4

5 Problems with Mobile d-hoc Networks Nodes move No easy address aggregation! Mobile IP like approach: ut where do you fix the home agent? ynns like approach: ut where do you fix the look-up service? ll nodes move istance vector routing would not converge. Link state routing would cause giant communication and processing overhead. Internet Protocols II Thomas uhrmann, Technical University Munich, ermany 5

6 Proactive and Reactive Routing lassic Internet Routing is proactive Routing protocol builds up routing table in case a packet needs to be routed Reasonable in the Internet because large sub-networks and autonomous systems Relatively stable topology Mobile d-hoc Network Routing could be reactive Wait for a packet; then try to find an appropriate route. Network isn t stable, so why invest effort to build up routing state that won t be used before it is outdated? Internet Protocols II Thomas uhrmann, Technical University Munich, ermany 6

7 Routing in Mobile d-hoc Networks xtension of fixed wire protocols void count to infinity by exchanging richer state info amp updates to limit traffic looding to acquire state o not proactively maintain state Search reactively for the requested destinations Limited flooding Scopes and landmarks ifferent areas have more or less detailed routing information eographic routing xploit the fact that nodes have coordinates Virtual structures stablish virtual coordinates istribute routing info according to virtual coordinates Internet Protocols II Thomas uhrmann, Technical University Munich, ermany 7

8 estination-sequenced istance Vector Protocol rweiterungen der Routingeinträge um Sequenznummern Sequenznummern werden von jeweiligen Zielknoten vergeben Sicherstellung, dass ktualisierungen in der richtigen Reihenfolge ausgeführt werden Vermeidet dadurch Schleifen und Inkonsistenzen ufbau / Unterhalten einer Routingtabelle mit Zieladresse, Next Hop, nzahl der Hops zum Ziel, Sequenznummer, letzte Änderung des intrags und Zeiger zu alternative Routen Periodisches Versenden der Routinginformation inträge der versendete Routingtabelle enthalten Teilmenge der eigenen Routingtabelle: Zieladresse, nzahl der Hops zum Ziel, Sequenznummer Neue Sequenznummer für eigenen intrag Signifikante Änderungen werden sofort verschickt Linkänderungen aufgrund von Mobilität rkennbar durch Hello-Nachrichten oder M-cknowledgements Toter Link wird mit Metrik versehen Unterscheidung zwischen full dump: nthält inträge aller Knoten incremental dump: nthält nur geänderte inträge SV berücksichtigt nur bidirektionale Links Internet Protocols II Thomas uhrmann, Technical University Munich, ermany 8

9 eispiel SV M3 M4 M5 M2 M6 M8 M1 M7 d-hoc Netz mit mobilem Knoten M1 M1 bewegt sich von M2 zur Nachbarschaft von M7 und M8 Im folgenden wird der mobile Knoten M4 und dessen Routingtabelle genauer betrachtet M1 harles. Perkins and Pravin hagwat, Highly ynamic estination-sequenced istance-vector Routing for Mobile omputers. SIOMM 1994 Internet Protocols II Thomas uhrmann, Technical University Munich, ermany 9

10 sp: Routingtabelle von M4 vor dem Wechsel... bevor M1 in die Nachbarschaft von M7 und M8 gewandert ist Ziel Next Hop Metrik Seq.-Nr. Install Stable_ata M1 M2 2 S406_M1 T001_M4 Ptr1_M1 M2 M2 1 S128_M2 T001_M4 Ptr1_M2 M3 M2 2 S564_M3 T001_M4 Ptr1_M3 M4 M4 0 S710_M4 T001_M4 Ptr1_M4 M5 M6 2 S392_M5 T002_M4 Ptr1_M5 M6 M6 1 S076_M6 T001_M4 Ptr1_M6 M7 M6 2 S128_M7 T002_M4 Ptr1_M7 M8 M6 3 S050_M8 T002_M4 Ptr1_M8 Install-Zeit aller inträge sind etwa gleich lle mobilen Knoten waren M4 ungefähr zum gleichen Zeitpunkt bekannt Stable_ata sind Zeiger auf eine Liste alternativer Routen Ptr1_Mi sind alles Nullpointer, da jeweils nur ein möglicher nächster Nachbar (Next Hop) pro Zielknoten existiert Internet Protocols II Thomas uhrmann, Technical University Munich, ermany 10

11 sp: Routingtabelle von M4 nach dem Wechsel... nachdem M1 in die Nachbarschaft von M7 und M8 gewandert ist Ziel Next Hop Metrik Seq.-Nr. Install Stable_ata M1 M6 3 S516_M1 T810_M4 Ptr1_M1 M2 M2 1 S128_M2 T001_M4 Ptr1_M2 M3 M2 2 S564_M3 T001_M4 Ptr1_M3 M4 M4 0 S710_M4 T001_M4 Ptr1_M4 M5 M6 2 S392_M5 T002_M4 Ptr1_M5 M6 M6 1 S076_M6 T001_M4 Ptr1_M6 M7 M6 2 S128_M7 T002_M4 Ptr1_M7 M8 M6 3 S050_M8 T002_M4 Ptr1_M8 ie Mobilität von M1 veranlasst Senden eines Incremental ump von M1 ieses gelangt über M7, M6 zu M4 M4 aktualisiert seine Routingtabelle Internet Protocols II Thomas uhrmann, Technical University Munich, ermany 11

12 ämpfung von Änderungen Ziel Vermeidung von luktuationen in den Routen Änderungen werden entsprechend folgender Kriterien berücksichtigt Routen mit neueren Sequenznummern werden bevorzugt ei gleichen Sequenznummern werden Routen mit der besseren Metrik bevorzugt Szenario lle mobilen Knoten übertragen M9 Update ungefähr alle 15 Sekunden M2 hat Route zu M9 mit 12 Hops M6 hat Route zu M9 mit 11 Hops Mob. Hosts 1 Mob. Hosts 2 Routinginfo von M2 trifft bei M4 ca. 10s vor M6 ein M2 M6 aher oszilliert der nächste Hop von M4 zu M9 zwischen M2 und M6 Lösung Speichern der Zeitdauer zwischen erster und bester nkündigung eines Weges M4 Zurückhalten einer ktualisierung, wenn sie vermutlich nicht stabil ist (basierend auf der gespeicherten Zeit) Internet Protocols II Thomas uhrmann, Technical University Munich, ermany 12

13 Optimized Link State Routing (OLSR) Minimierung des Overheads dadurch, dass Link Status Informationen nur von bestimmten Knoten weitergeleitet werden Jedem Knoten wird mindestens ein Multipoint Relay zugeordnet Multipoint Relays sind bestimmte Nachbarn von X, so dass jeder 2-hop Nachbar von X ein 1-hop Nachbar von wenigstens einem Multipoint Relay ist rmittelt werden diese durch Versenden periodischer Nachrichten, die eine Liste der 1-hop Nachbarn des jeweiligen Knotens enthalten Internet Protocols II Thomas uhrmann, Technical University Munich, ermany 13

14 eispiel OLSR (1) Knoten versendet Link Status Informationen (roadcast) J H K Quelle: N. Vaidya, Tutorial Mobicom 01 Internet Protocols II Thomas uhrmann, Technical University Munich, ermany 14

15 eispiel OLSR (2) Knoten und sind Multipoint Relays von und leiten daher Link Status Informationen von weiter J H K Knoten, der Link Status Informationen von weiterleitet Quelle: N. Vaidya, Tutorial Mobicom 01 Internet Protocols II Thomas uhrmann, Technical University Munich, ermany 15

16 eispiel OLSR (3) Knoten H ist Multipoint Relay von und leitet daher Link Status Informationen weiter J H K Knoten, der Link Status Informationen von weiterleitet Quelle: N. Vaidya, Tutorial Mobicom 01 Internet Protocols II Thomas uhrmann, Technical University Munich, ermany 16

17 ynamic Source Routing (SR) nnahmen urchmesser des Netzes ist meist klein Mobilität der Knoten ist nicht zu hoch Knoten stellen ggfs. Promiscuous -Modus zur Verfügung Unidirektionale Übertragungsabschnitte evtl. vorhanden Trennung der Routing-ufgabe in uffinden und ufrechterhalten uffinden eines Wegs Nur wenn wirklich ein Weg zum Senden von aten zu einem bestimmten Ziel benötigt wird und noch keiner vorhanden ist ufrechterhaltung eines Wegs Nur wenn ein Weg aktuell benutzt wird muss dafür gesorgt werden, dass er weiterhin funktioniert Keine periodischen ktualisierungen! Internet Protocols II Thomas uhrmann, Technical University Munich, ermany 17

18 uffinden eines Pfads bei SR Knoten speichern Pfade (Source Routen) zu den Knoten mit denen sie kommunizieren nnahme: Sender hat noch keinen Weg zu einem (neuen) mpfänger im ache Protokoll zum uffinden des Wegs Sender flutet das Netz mit einem Route Request-Paket RRQ enthält Zieladresse und eindeutige I für dieses RRQ ei mpfang eines Route Request-Pakets alls Paket bereits früher erhalten (I gleich), RRQ verwerfen ndgültiger mpfänger? ann Route Reply-Paket an ursprünglichen Sender schicken Sonst eigene dresse anhängen und per roadcast weiterleiten Sender erhält Route Reply mit aktuellem Weg (Source Route) zurück Nicht unbedingt über den gleichen Weg (bei unidirektionalen Links) alls M unidirektionale Links zulässt, muss mpfänger erst einen Weg zum Sender mit Hilfe eines Route Requests auffinden Internet Protocols II Thomas uhrmann, Technical University Munich, ermany 18

19 eispiel SR (1) Y Z S H I K J M N L Knoten, der Route Request (RRQ) empfangen hat Knoten in Sende/mpfangsreichweite Quelle: N. Vaidya, Tutorial Mobicom 01 Internet Protocols II Thomas uhrmann, Technical University Munich, ermany 19

20 eispiel SR (2) Y roadcast [S] Z S H I K J M N L Sender S versendet RRQ (roadcast) igene dresse wird an RRQ angehängt Quelle: N. Vaidya, Tutorial Mobicom 01 Internet Protocols II Thomas uhrmann, Technical University Munich, ermany 20

21 eispiel SR (3) Y Z S [S,] H [S,] I K J M N L Jeder Knoten, der Paket empfängt, leitet es per roadcast weiter igene dresse wird an RRQ angehängt Quelle: N. Vaidya, Tutorial Mobicom 01 Internet Protocols II Thomas uhrmann, Technical University Munich, ermany 21

22 eispiel SR (4) Y Z H S I [S,,] J [S,,] K M N L leitet Paket nicht ein zweites Mal weiter Sequenznummern verhindern, dass ein Knoten das gleiche Paket mehrfach weiterleitet Quelle: N. Vaidya, Tutorial Mobicom 01 Internet Protocols II Thomas uhrmann, Technical University Munich, ermany 22

23 eispiel SR (5) Y Z S H I K [S,,,J] M J [S,,,K] N L ei könnte Paket von J und K kollidieren alls M-Schicht keine Übertragungswiederholungen ausführt, wird RRQ nicht ankommen und müsste erneut von S versendet werden Quelle: N. Vaidya, Tutorial Mobicom 01 Internet Protocols II Thomas uhrmann, Technical University Munich, ermany 23

24 eispiel SR (6) Y Z H S I K J [S,,,J,M] M L N Zielknoten empfängt das Paket und leitet es nicht weiter Quelle: N. Vaidya, Tutorial Mobicom 01 Internet Protocols II Thomas uhrmann, Technical University Munich, ermany 24

25 eispiel SR (7) Y S RRP [S,,,J,] Z H I K J M N L Route Replay (RRP) enthält Weg von S zu alls M unidirektionale Links zulässt, muss ein RRQ zu S starten und den RRP anhängen (hier nicht angenommen) Quelle: N. Vaidya, Tutorial Mobicom 01 Internet Protocols II Thomas uhrmann, Technical University Munich, ermany 25

26 eispiel SR (8) Y aten [S,,,J,] Z S H I K J M N L aten können über die Source Route [,J,,,S] gesendet werden röße des IP-Kopfs steigt mit nzahl Hops Quelle: N. Vaidya, Tutorial Mobicom 01 Internet Protocols II Thomas uhrmann, Technical University Munich, ermany 26

27 Nochmal: uffinden eines Pfads bei SR RRQ wird beim Sender ggf. nach Timeout wiederholt abei Verwendung eines exponentiellen ackoff, um den Overhead zu limitieren. Optimierungen egrenzung des lutens auf urchmesser des mobilen Netzes (=Hop Limit) gf. xpanding Ring Search zum rmitteln des urchmessers aching von Weginformationen aus vorbeikommenden Paketen Sender kann ache nutzen um RRQ zu sparen Knoten auf dem Weg zum Ziel können vorzeitig auf RRQ antworten mit Information aus eigenem ache Internet Protocols II Thomas uhrmann, Technical University Munich, ermany 27

28 ufrechterhalten eines Wegs bei SR Nach dem Senden Warten auf die Quittung auf Schicht 2 (falls vorhanden, z.. bei I ) Mithören im Medium, ob Paket weitergeleitet wird (falls möglich) nforderung einer expliziten estätigung auf SR-bene Quittung kann über einen anderen Weg laufen Wiederholen des Pakets, falls obige Maßnahmen nicht erfolgreich Nach maximaler nzahl Wiederholungen wird Route rror gesendet Übertragungsabschnitt wird aus dem ache genommen alls Probleme erkannt werden kann der Sender informiert oder lokal ein neuer Weg gesucht werden Internet Protocols II Thomas uhrmann, Technical University Munich, ermany 28

29 eispiel SR Route rror Y S RRR [J-] Z H I K J M N L J sendet Route rror (RRR) zu S, weil er Paket von S nicht weiterleiten konnte und entfernen den Link J- aus ihrem Route ache Quelle: N. Vaidya, Tutorial Mobicom 01 Internet Protocols II Thomas uhrmann, Technical University Munich, ermany 29

30 d-hoc On emand istance Vector Routing (OV) Mischung zwischen SR und SV Source Routes bei SR führen zu großen RRQ/RRP-Paketen OV benutzt keine Source Routes Stattdessen zusätzliche Informationen in Routingtabellen ei Weiterleitung eines RRQ wird ein Reverse Path in die entgegengesetzte Richtung aufgebaut unktioniert nur bei bidirektionalen Links! RRP kann dann den vom RRQ aufgebauten Reverse Path verwenden urch den RRP wird wiederum ein Reverse Path, der orward Path, aufgebaut, der dann für den atenverkehr verwendet werden kann Internet Protocols II Thomas uhrmann, Technical University Munich, ermany 30

31 OV Route Request (1) Y Z S H I K J M N L Knoten, der Route Request (RRQ) empfangen hat Knoten in Sende/mpfangsreichweite Quelle: N. Vaidya, Tutorial Mobicom 01 Internet Protocols II Thomas uhrmann, Technical University Munich, ermany 31

32 OV Route Request (2) Y roadcast Z S H I K J M N L RRQ Quelle: N. Vaidya, Tutorial Mobicom 01 Internet Protocols II Thomas uhrmann, Technical University Munich, ermany 32

33 OV Route Request (3) Y Z S H I K J M N L Reverse Path Jeder Knoten merkt sich, von welchem Nachbar ein RRQ-Paket empfangen wurde Zustandshaltung Quelle: N. Vaidya, Tutorial Mobicom 01 Internet Protocols II Thomas uhrmann, Technical University Munich, ermany 33

34 OV Route Request (4) Y Z S H I K J M N L adurch baut sich ein Reverse Path von jedem Zwischenknoten zum Sender auf Quelle: N. Vaidya, Tutorial Mobicom 01 Internet Protocols II Thomas uhrmann, Technical University Munich, ermany 34

35 OV Route Request (5) Y Z S H I K J M N L Quelle: N. Vaidya, Tutorial Mobicom 01 Internet Protocols II Thomas uhrmann, Technical University Munich, ermany 35

36 OV Route Request (6) Y Z S H I K J M N L Wenn der RRQ bei angekommen ist, existiert ein Reverse Path von zu S Quelle: N. Vaidya, Tutorial Mobicom 01 Internet Protocols II Thomas uhrmann, Technical University Munich, ermany 36

37 OV Route Reply Y orward Path für aten Z S H I RRP K J M N L sendet daraufhin RRP über Reverse Path zu S urch den RRP wird wiederum ein Reverse Path aufgebaut, der den orward Path für den atenverkehr bildet atenpakete enthalten keine Source Route Quelle: N. Vaidya, Tutorial Mobicom 01 Internet Protocols II Thomas uhrmann, Technical University Munich, ermany 37

38 Sequenznummern und Route rror Reverse/orwarding Path inträge werden nach Timeout gelöscht Softstate Jedem RRQ wird eine destination sequence number zugeordnet Zum rkennen von alten, nicht mehr gültigen Routen alls Zwischenknoten eine neuere Route kennen, können sie mit RRP antworten Verhindert Schleifen! - eispiel: RRR von geht verloren sendet RRQ empfängt RRQ über -- und antwortet mit RRP alls ein Link nicht mehr zur Verfügung steht, werden alle aktiven Nachbarn mit RRR informiert Nachbar ist aktiv, wenn er kürzlich ein Paket verschickt hat (active_route_timout) Link ehler werden durch Hello-Messages oder Link-layer cknowledgements erkannt RRR erhält höhere destination sequence number RRR wird so bis zur Quelle fortgepflanzt Internet Protocols II Thomas uhrmann, Technical University Munich, ermany 38

39 Hybride Routingprotokolle eispiel: Zone Routing Protocol (ZRP) lle Knoten innerhalb einer istanz von d Hops von Knoten X sind in der Routing Zone von Knoten X Routing Zonen der einzelnen Knoten überlappen sich Intra-zone Routing ist proaktiv, d.h. Routen zu allen Knoten innerhalb der Zone sind aus Routingtabelle bekannt. Inter-zone Routing ist reaktiv. azu wird ein RRQ zu allen Knoten am Rand der Zone geschickt, die dann entweder den Zielknoten kennen (proaktiv) oder wiederum ein Route iscovery ausführen müssen (reaktiv). H I Routing Zone von mit d=1 Quelle: N. Vaidya, Tutorial Mobicom 01 Internet Protocols II Thomas uhrmann, Technical University Munich, ermany 39

40 Hierarchische Routingprotokolle ereitstellung einer geeigneten selbstorganisierenden Kontrollstruktur für große dynamische Netze eispiel: Landmark Routing (LNMR) nnahme: ruppe von Knoten, die sich größtenteils im Verbund bewegen, bilden logisches Subnetz In jedem Subnetz wird ein Landmark Knoten gewählt Jeder Knoten besitzt eigenen Scope, definiert als Menge aller Knoten, die nicht weiter als r Hops entfernt sind Jeder Knoten leitet Link Status Informationen von Knoten innerhalb seines Scopes und istanz Vektor Informationen aller Landmarks weiter Knoten kennen nur Routen zu Knoten innerhalb des eigenen Scopes lle Knoten kennen nächsten Hop zu allen Landmarks Pakete außerhalb des Scopes werden in Richtung des zum Zielknoten gehörenden Landmarks geschickt rmittelt durch Subnetz-Teil der hierarchischen dresse Wenn Paket in Scope des Zielknoten eintritt, wird es direkt zum Zielknoten weitergeleitet Route muss nicht durch Landmark Knoten gehen! Internet Protocols II Thomas uhrmann, Technical University Munich, ermany 40

41 eispiel LNMR (1) Routing innerhalb des Scopes Knoten möchte Knoten erreichen Knoten sendet atenpakete Richtung H Knoten, und kennen nächsten Hop zu Knoten H auf rund erhaltener istanz Vektor Informationen H Landmark von Knoten gehört zum Scope von Knoten Knoten gehört zum Scope von Knoten Quelle: N. Vaidya, Tutorial Mobicom 01 Internet Protocols II Thomas uhrmann, Technical University Munich, ermany 41

42 eispiel LNMR (2) Routing außerhalb des Scopes Knoten ist im Scope von Knoten aher kennt Knoten nächsten Hop zu und kann Paket direkt zu weiterleiten Route muss nicht Landmark (Knoten H) enthalten H Landmark von Knoten gehört zum Scope von Knoten Knoten gehört zum Scope von Knoten Quelle: N. Vaidya, Tutorial Mobicom 01 Internet Protocols II Thomas uhrmann, Technical University Munich, ermany 42

43 usblick: eographisches Routen 4 5;4 3 2;2 2 1 eographisches Routing muss alle eräte in einem Vektorraum verorten. gf. müssen Sackgassen überwunden werden Internet Protocols II Thomas uhrmann, Technical University Munich, ermany 43

44 Summary Routing protocols from the fixed wired Internet must be adapted to work in wireless and mobile settings SV: Introduce sequence numbers to avoid routing loops (= count to infinity problem) OLSR: Not all routers relay topology information SR: lood the network with discovery packets; reply caries source route to the destination OV: lood the network and build up state while flooding and replying Zone routing: Route differently in the vicinity of the sender Landmark routing: Have different granularity of routing information depending on distance from sender eographic routing: Use physical coordinates as destination address Internet Protocols II Thomas uhrmann, Technical University Munich, ermany 44

45 Questions? Thomas uhrmann epartment of Informatics Self-Organizing Systems roup c/o I8 Network rchitectures and Services Technical University Munich, ermany Internet Protocols II Thomas uhrmann, Technical University Munich, ermany 45