RFC 3561 AODV Routing Protocol

1. RFC 3561 AODV Routing Protocol Mobile Ad Hoc Networking Working Group Charles E. Perkins INTERNET DRAFT Nokia Research Center 19 June 2002 Elizabeth M. Belding-Royer University of California, Santa Barbara Samir R. Das University of Cincinnati 資料來源：draft-ietf-manet-aodv-11.txt 報告人：吳政鴻 日期：2005/2/29

2. What an ad-hoc routing protocol needs • Multi-hop paths • Self-starting • Dynamic topology maintenance • Loop-free • Low consumption of memory, bandwidth • Scalable to large node populations • Localized effect of link breakage • Minimal overhead for data transmission • Rapid convergence

3. AODV: Ad-Hoc On-Demand Distance Vector Routing • Quick loop-free convergence • Route creation on demand, localizing the effect of topology changes, and minimizing control traffic. • Distance Vector, using Destination Sequence numbers for route updates (on both forward and reverse paths) • Triggered updates and minimal latency for route replies • two-dim'l metric: <seq#, hop-count>

4. A destination node increments its own sequence number in two circumstances: • before a node originates a route discovery • before a destination node originates a RREP in response to a RREQ

5. AODV route table entry • Destination IP Address • Destination Sequence Number • Vaild Destination Sequence Number flag • Network Interface • Hop Count (number of hops needed to reach destination) • Next Hop • List of Precursors • Lifetime (expiration or deletion time of the route) • Other State and routing flag (e.g. valid, invalid, repairable, being repaired)

6. A node may change the sequence number in the routing table entry • it is itself the destination node, and offers a new route to itself • it receives an AODV message with new information about the sequence number for a destination node • the path towards the destination node expires or breaks

7. The route is only updated ifthe new sequence number • higher than the destination sequence number in the route table • the sequence numbers are equal, but the hop count is smaller than the existing hop count in the routing table • the sequence number is unknown

8. AODV Unicast Route Discovery • RREQ (route request) is broadcast • Reverse path is set up along the way • RREQ message contains < bcast_id; dest_ip; dest_seqno;src_ip; src_seqno; hop_count > • RREP (route reply) is unicast back • From destination if necessary • From intermediate node if that node has a recent route

9. AODV Route Discovery Time Out Time Out : RREQ : RREP :Valid Route

10. AODV Local Route Repair : RREQ : RREP :Valid Route Data packet be buffered

11. : RREQ : RREP :Valid Route :RERR Data packet be buffered Data packet be discarded

12. Route Request (RREQ) Message Format

13. Route Reply (RREP) Message Format

14. Route Error (RERR) Message Format

15. Link Breakage • Nodes remember active routes • Next hop breaks ­> neighbors using that route are notified • Notification is a RREP with: - metric = ∞ - dest_seqno = previous + 1 and is sent to each active neighbor

16. Ad-hoc Networking Example • Suppose MH1 moves away from MH2 towards MH7, and has active sessions with MH3 and MH6. The following actions occur:

17. MH2 notices that its link to MH1 is broken • MH2 checks its routing table, and finds that its link to MH1 was actively in use by MH3 and MH4. • MH2 unicasts an ∞-metric route update, with an incremented destination sequence number, to MH3 and MH4. MH3 may subsequently issue a new route request for MH1. • MH4 also notes that its route to MH1 was actively in use, and forwards the ∞-metric route update to MH6. • MH6 may subsequently issue a new route request for MH1.

18. Conclusions • AODV has the following features: - Nodes store only the routes that are needed - Need for broadcast is minimized - Reduces memory requirements and needless duplications - Quick response to link breakage in active routes - Loop-free routes maintained by use of destination sequence numbers - Scalable to large populations of nodes.