1 / 42

Peer-to-peer és mobil ad hoc

Peer-to-peer és mobil ad hoc. T ávközlési és Médiainformatikai Tanszék. AODV. Felhasznált fóliák: Nitin H. Vaidya ( http://www.crhc.uiuc.edu/~nhv ). Ad Hoc On-Demand Distance Vector Routing (AODV).

sani
Download Presentation

Peer-to-peer és mobil ad hoc

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript


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

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

  3. 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

  4. 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

  5. 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

  6. 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

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

  8. 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

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

  10. 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

  11. 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

  12. 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

  13. 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

  14. 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

  15. 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

  16. 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

  17. 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

  18. 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

  19. 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

  20. 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

  21. 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

  22. 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

  23. 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

  24. 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

  25. 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

  26. 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

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

  28. 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

  29. 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

  30. 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

  31. 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

  32. AODV RREP – IPv6 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type |R|A| Reserved | Prefix Size 1B | 1B Hop Count | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 32-bit Destination Sequence Number | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | : 128-bit Destination IP Address : | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | : 128-bit Source IP Address : | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Lifetime | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1B = 1byte simon@tmit.bme.hu

  33. 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

  34. 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

  35. 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

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

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

  38. 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

  39. 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

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

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

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

More Related