Peer-to-peer és mobil ad hoc

Peer-to-peer és mobil ad hoc Távközlési és Médiainformatikai Tanszék simon@tmit.bme.hu

AODV simon@tmit.bme.hu Felhasznált fóliák: Nitin H. Vaidya (http://www.crhc.uiuc.edu/~nhv)

Ad Hoc On-Demand Distance Vector Routing (AODV) • Amikor azS állomás csomagot akar küldeni a Dállomásnak, de nem ismer érvényes útvonalat D felé, S felderítést [route discovery] kezdeményez • AODV útvonalválasztási táblát [routing table] • a csomagokaban elég a célcímet feltüntetni • Az AODV csak az aktív útvonalakat tartja fenn • Timeout alapján kiöregednek a nem frissített bejegyzések simon@tmit.bme.hu

AODV • Route Requests (RREQ)-el árasztja el a hálózatot (flooding) • Az állomások újra-küldik elárasztással a Route Request üzenetet • Megjegyzik, honnan érkezett az üzenet „reverse path” • Szimmetrikus kapcsolatokat feltételezünk • Ha a Route Request eléri a célállomást, az Route Reply üzenttel válaszol • Route Reply ugyanazokon az állomásokon keresztül éri el a forrást, mint amelyeken az azt kiváltó RREQ érkezett simon@tmit.bme.hu

AODV Route Requests Y Z S E F B C M L J A G H D K I N Olyan állomás, amely már fogadott RREQ-et simon@tmit.bme.hu

AODV Route Requests Y Broadcast Z S E F B C M L J A G H D K I N RREQ küldés adott irányba simon@tmit.bme.hu

AODV Route Requests Y Z S E F B C M L J A G H D K I N Reverse Path pointerek simon@tmit.bme.hu

AODV Reverse Path Y Z S E F B C M L J A G H D K I N • C állomás már nem továbbítja a G és H-tól kapott RREQ-et • korábban már továbbította simon@tmit.bme.hu

AODV Reverse Path Y Z S E F B C M L J A G H D K I N simon@tmit.bme.hu

AODV Reverse Path Y Z S E F B C M L J A G H D K I N • Mivel D a célállomás, nem továbbítja a RREQ üzenetet simon@tmit.bme.hu

AODV Route Reply Y Z S E F B C M L J A G H D K I N Reverse Path, ahol a RREP-et küldik simon@tmit.bme.hu

AODV Route Reply • Egy X belső állomás (azaz egy állomás az S és D között)is küldhet Route Reply (RREP) üzenetet • Egy FRISSEBB útvonalat kell ismernie, mint az S • Az időrendi sorrend nyilvántartása érdekében új mező az útvonalválasztó üzenetekben • Destination Sequence Number (SeqNr) • Minden S által küldött új Route Request üzenetben megnöveli a SeqNr-t • X csak akkor válaszolhat Route Reply-al, ha saját SeqNr nagyobb az üzenet SeqNr-nál • Ha Xegy olyan RREQ-t fogad, amelynek SeqNr nagyobb saját SeqNr-nál, saját SeqNr-t átállítja erre a nagyobb értékre simon@tmit.bme.hu

AODV Útvonalak Y Z S E F B C M L J A G H D K I N Forward link (next hop)bejegyzés, amint RREP-et a reverse path-on továbbítják Érvényes útvonalbejegyzés simon@tmit.bme.hu

AODV adattovábbítás Y Adatcsomag Z S E F B C M L J A G H D K I N Routing table–alapú továbbítás Csak a célcímet tartalmazza a csomag simon@tmit.bme.hu

Timeout • Útvonalválasztó tábla bejegyzését a reverse path-ra törlik (purge) egy timeout periódus után • a timeout periódusnak biztosítnaia kell a RREP terjedéséhez szükséges időt • Útvonalválasztó tábla bejegyzését a forward path-ra törlik ha egy active_route_timeout intervallumon belül nem volt olvasva • Ha nincs adatforgalom az adott irányba, akkor nincs szükség az útvonalra sem • kiöregedés simon@tmit.bme.hu

Link hiba jelzés • X állomás szomszédja aktív, ha active_route_timeout intervallumon belül olyan csomagot küldött, amit adott bejegyzésalapján routoltak • Ha a „next hop” meghibásodik • Értesíteni az aktív szomszédokat • Route Error (RERR) üzenetek segítségével • RERR frissíti a SeqNr-t is simon@tmit.bme.hu

RERR • S a forrás, D a célállomás, X és Y két állomás az S-D útvonalon • X nem tud egy csomagot továbbküldeni az (X,Y) linken, RERR üzenetet generál • Xnöveli a destination sequence number a D-hez tartozó routing bejegyzéséhez • Ezt a megnövelt SeqNR-t beleteszi a RERR üzenetbe • Amint azRERReléri S-t, új útvonalfelderítést kezdeményez D-hez • Az új RREQ-be a RERR SeqNr-nél nagyobb SeqNr-t kerül simon@tmit.bme.hu

AODV RERR Y Adatcsomag Z S E F B C M L J A G H D K I N Kiépült kapcsolat S és D között simon@tmit.bme.hu

AODV RERR Y Adatcsomag Z S E F B C M L J A G H D K I N F és J között megszakad a kapcsolat simon@tmit.bme.hu

AODV RERR Y Z S E F B C M L J A G H D K I N F RERR üzenetet generál és visszaküldi a reverse path-on S-nek RERR üzenet simon@tmit.bme.hu

Reverse path pointer RREQ üzenet AODV RERR S E F B C M L J A G H D K I N • S új útvonalkeresést indít D felé, megnövelt SeqNr értékkel • Átugrottuk az első három lépést a RREQ flooding-ból • Csak azokat az üzeneteket/pointereket tüntettük fel, amelyek • D felé eső rövidebb utakat jelölik simon@tmit.bme.hu

Reverse path pointer RREQ üzenet AODV RERR S E F B C M L J A G H D K I N • J-en érvényes bejegyzés volt D felé • Viszont a RREQ SeqNr-ja nagyobb a J-ben tároltnál • Emiatt J továbbítja a RREQ-t simon@tmit.bme.hu

AODV RERR S E F B C M L J A G H D K I N Új útvonal • K felől érkezett a legelső RREQ D-be • A reverse pathon keresztül kiépül az új útvonal simon@tmit.bme.hu

Link Hiba észlelés • HELLO üzenetek • Szomszédos állomások rendszeresen küldenek HELLO üzeneteket • HELLO üzenet elmarad = linkhiba • Jellemzően 3 HELLO üzenet kimaradása után értékelik hibásnak a linket • HELLO üzenetek gyakoriságának • Növelésével gyorsabb reakció a linkhibára • Csökkentésével kisebb terhelés (forgalom) simon@tmit.bme.hu

Destination Sequence Number értelme • Ne használjunk kiöregedett, hibás linkeket • Eldöntjük, melyik a frisebb útvonal • Hurkok kialakulásának megakadályozása • Van egy kiépült útvonalunk: A-B-C-D, majd a C-D link meghibásodik • C-D áltlal küldött RERR nem jut el A-ig (pl. elveszik a RERR) • C keres egy új útvonalat Dfelé • Amegkapja a RREQ-t a C-E-A útvonalon C A B D E simon@tmit.bme.hu

Destination Sequence Number értelme A B C D • Aválaszolni fog, mivel ő ismer egy érvényes utat D felé • Ha nincsen SeqNr, hogy észrevegye, hogy a RREQ frisebb, mint a saját routing bejegyzése • Hurok alakult ki: C-E-A-B-C E simon@tmit.bme.hu

AODV teljesítmény elemzése Távközlési és Médiainformatikai Tanszék simon@tmit.bme.hu

Hatékonyság növelés • Expanding Ring Search • RREQ eredetileg kis Time-to-Live (TTL) értéket tartalmaz • Korlátozza a forrástól mért elárasztott területet • Ha nincs RREP, nagyobb TTL értékkel küldik újra a RREQ-t simon@tmit.bme.hu

AODV RREQ üzenet – IPv4 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type |J|R|G|D|U| Reserved | Hop Count | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | RREQ ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Destination IP Address | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Destination Sequence Number | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Originator IP Address | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Originator Sequence Number | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 32 bit szélesség simon@tmit.bme.hu

AODV a gyakorlatban • Originator Seq Nr • Visszafelé is frissítik a címlistát • G flag = gratuitous • Köztes állomás válaszol a RREQ-re • RREP-t küldeni a Destination-nak is • D flag = destination • Mindenképpen a címzett válaszoljon simon@tmit.bme.hu

AODV RREQ – IPv6 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type |J|R|G| Reserved | Hop Count | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 32-bit Flooded Packet ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 32-bit Destination Sequence Number | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 32-bit Source Sequence Number | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | : 128-bit Destination IP Address : | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | : 128-bit Source IP Address : | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ simon@tmit.bme.hu

RREP Ack • Route Reply Acknowledgment (RREP-ACK) • RREP nyugtázása • Instabil link esetében 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ • Type = 19 • Reserved = 0 • Nem értelmezik a fogadó oldalon simon@tmit.bme.hu

HELLO üzenet • RREP • TTL = 1 • Destination IP Address = saját IP cím • Dest SeqNr = Utolsó Seq Nr az útvonalon • Hop Count = 0 simon@tmit.bme.hu

AODV szimuláció Útvonal érvényességi idő = 300 s Célállomás által küldött RREP érvényességi ideje = 600 s RREQújraküldések száma, sikertelen útvonalkérés esetén = 3 RREQ újraküldések közti idő = 6 s Továbbított RREQ-hez tartozó bejegyzések fenntartás = 3s RREP továbbítása után reverse route info fenntartása = 3 s Hibás link észlelése és routing táblából kitörlés közti idő = 3 s MAC szintű linkhiba észlelés? = igen simon@tmit.bme.hu

Goodput/mobilitás simon@tmit.bme.hu

Routing overhead/mobilitás simon@tmit.bme.hu

AODV mérések • MN1 elveszti kapcsolatát MR2-vel • HELLO üzenetekkel észreveszi, hogy nincs érvényes útvonal • Új útvonalat keres simon@tmit.bme.hu

Útvonalkeresési idő függ az útvonal hosszától simon@tmit.bme.hu

Útvonalkeresési idő függ a HELLO üzenetek gyakoriságától simon@tmit.bme.hu

Útkeresési idő és linkhiba észlelés idje közti viszony Nagyon fontos a hatékony linkhiba felderítés! simon@tmit.bme.hu

Peer-to-peer és mobil ad hoc