The Ad Hoc On-Demand Distance-Vector Protocol (AODV)

1. The Ad Hoc On-Demand Distance-Vector Protocol (AODV) Charles E. Perkins Elizabeth M. Royer 발표자 : CCLAB 이 호 영

2. AODV Overview (1/2) • AODV : DSDV + DSR • AODV attempts to improve on DSRby maintaining routing tables at the nodes, so that data packets do not have to contain routes • AODV retains the desirable feature of DSR that routes are maintained only between nodes which need to communicate • Route Requests (RREQ) are forwarded in a manner similar to DSR • When a node re-broadcasts a Route Request, it sets up a reverse path pointing towards the source • AODV assumes symmetric (bi-directional) links

3. AODV Overview (2/2) • When the intended destination receives a Route Request, it replies by sending a Route Reply(RREP) • Route Reply travels along the reverse path set-up when Route Request is forwarded

4. AODV Properties (1/2) • Routes are discovered on an as-needed basis and are maintained only as long as they are necessary • Loop Freedom • using sequence numbers • AODV is able to provide unicast, multicast, and broadcast communication ability. • Route information obtained when searching for a multicast route can also increase unicast routing knowledge and vice versa. • simplifying coding. • AODV is capable of operating on both wired and wireless media, although it is designed specifically for the wireless domain.

5. AODV Properties (2/2) • AODV utilizes both a route table (for unicast routes) and a multicast route table (for multicast routes). • Associated with each route table entry is a lifetime, which is updated whenever a route is used. • Multicast route table entry may have more than one next-hop associated with it. • AODV provides for the quick deletion of invalid routes through the use of a special route error message(RERR). • AODV requires nodes to maintain only next-hop routing information.

6. Unicast Route Establishment

7. Overview • Route discovery with AODV is purely on demand and follows a route request/route reply discovery cycle. • Requests are sent using a Route Request (RREQ) message. • Information enabling the creation of a route is sent back in a Route Reply (RREP) message.

8. Route Discovery (1/4) • If the node does not have a valid route to the destination, it must initiate a route discovery process. • creation of a route request packet (RREQ) • RREQ contains • Source Addr, current seq#, Dest Addr, Dest seq# • Broadcast ID • Identifier for RREQ : source address + broadcast ID • After creating the RREQ, the source node broadcasts the packet and then sets a timer to wait for a reply. • When a node receives a RREQ, it first checks whether it has seen it before by noting the source IP address and broadcast ID.

9. Route Discovery (2/4) • Each node maintains a record of the source IP address/ broadcast ID for each RREQ it receives. • The node sets up a reverse route entry for the source node in its route table. • source node’s IP address and sequence number • the number of hops to the source • IP address of the neighbor from which the RREQ was received • If the route entry is not used within the specified lifetime, the route information is deleted.

10. Route Discovery (3/4) • To respond to the RREQ, • the node must have an unexpired entry for the destination in its route table. • the sequence number associated with that destination must be at least as great as that indicated in the RREQ. (Loop Freedom) • The node responds by unicasting a RREP back to the source. • If the RREQ is lost, the source node is allowed to retry the broadcast route discovery mechanism. (rreq_retries)

11. Route Discovery (4/4) Destination Propagation of RREQ Reverse Route Entry Source Propagation of RREQ throughout the Network

12. Expanding Ring Search • Route Requests are initially sent with small Time-to-Live (TTL) field, to limit their propagation • DSR also includes a similar optimization • If no Route Reply is received, then larger TTL tried • This process of increasing the TTL value continues until a threshold value is reached.

13. Forward Path Setup • The RREP sent in response to the RREQ contains the IP address of both the source and destination. • When an intermediate node receives the RREP, it sets up a forward path entry to the destination in its route table. • After processing the RREP, the node forwards it toward the source. • The source node can begin data transmission as soon as the first RREP is received.

14. Forward Path Setup Destination Propagation of RREQ Reverse Route Entry Source Route Determination from Source to Destination

15. Route Maintenance (1/2) • The discovered route is maintained as long as needed by the source node. • Movement of the source node • reinitiate route discovery for the destination • Movement of the destination or some intermediate node • create a Route Error message (RERR). • Precursor nodes mark their route to the destination as invalid by setting the distance to the destination equal to infinity. • reinitiate route discovery for the destination

16. Route Maintenance (2/2) 3’ 3 1 RERR RERR 2 Destination Source 4 (a) 3’ 1 2 Destination Source 4 (b)

17. Local Connectivity Management • Neighborhood information is obtained from broadcasts or Hello messages sent by neighboring nodes. • Updates the lifetime whenever receiving. • Hello message contains a TTL value of 1. • Periodic message. • If a Mac layer protocol capable of providing feedbackinformation about unreachable next hops is run under AODV, the Hello message need not be used.

18. Actions after Reboot • Each node on reboot waits for delete_period. • lost a various sequence number. • so, creating routing loops. • When it receive a RREQ from any other node, its own sequence number is updated.

19. Multicast Route Establishment

20. Overview • Each multicast group has a group leader • Group leader is responsible for maintaining group sequence number (which is used to ensure freshness of routing information) • Similar to sequence number for AODV unicast • First node joining a group becomes group leader • A node on becoming a group leader, broadcasts a Group Hello message • Multicast Routing Tables contain • Multicast Group IP Address, Multicast Group Leader IP Address, Multicast Group Sequence Number, Hop Count to Multicast Leader, Next Hops, and Lifetime.

21. Route Discovery (1/2) • Multicast route discovery begins • when a node wishes to join a multicast group • when a node has data to send to a multicast group and does not have a current route to it • The source node creates a RREQ with destination address. • Join flag in RREQ sets when a source node wants to join a multicast group. • Only members of multicast tree can respond to join request • RREQ propagates until it meet to any multicast member • Non members create a reverse route entry to the source and then broadcasts the RREQ to its neighbors.

22. Group Leader Group Leader R R R R ? ? (a) RREQ message propagation Group Leader R R Prospective group member Multicast group member R R Multicast tree member Non-tree member ? ? Multicast tree link (c) Multicast tree branch addition Route Discovery (2/2) (b) RREP sent back to source Multicast Join Operation

23. Forward Path Setup • RREP generated and unicast back to the source • RREP has address of group member and distance from closest tree member • Nodes forwarding RREP update route tables and multicast route entries

24. Multicast Route Activation • Source waits the length of the route discovery interval • Notes route with the largest sequence number and the smallest hop count to the nearest tree member • After the route discovery interval, unicast MACT (Multicast Activation) to selected next hop • Node receiving MACT enables multicasting route table entry for source • Sends own MACT to its next hop if not the originator of the RREP • New path is added to the multicast tree

25. Multicast Route Deactivation (1/2) • MACT message is also used • A leaf node that wishes to revoke its member status unicasts a MACT with the Prune flag set to its next hop • When the next hop receives the prune message, it deletes the next-hop information for the sending node • This process continues to meet another group member.

26. R Group member initiating prune Path of MACT with set Prune flag Multicast Route Deactivation (2/2) B R R A R R (a) Pruning of multicast group member (b) Multicast tree after pruning Leaving the Multicast Group

27. Multicast Tree Maintenance • Requires ongoing route maintenance • A unicast destination doesnot need to be reachable unless another node is currently sending packets to it • Multicast tree maintenance takes two forms • repairing a broken tree branch following a link break • reconnecting the tree after a network partition

28. Link Breaks (1/2) • When a link (X,Y) on the multicast tree breaks, the node that is further away from the leader is responsible to reconstruct the tree, say node X • Node X, which is further downstream, transmits a Route Request (RREQ) • Only nodes which are closer to the leader than node X’s last known distance are allowed to send RREP in response to the RREQ, to prevent nodes that are further downstream from node X from responding.

29. R R Link Breaks (2/2) Group Leader Group Leader R R Downstream Node R R R (a) Link break (b) Repaired multicast tree Repair of a Broken Tree Link

30. Reconnecting Partitioned Trees (1/4) • If the network is partitioned, then each partition has its own group leader • When two partitions merge, group leader withthe larger identifier of the two partitions is chosen as the leader for the merged network • Each group leader periodically sends Group Hello(GRPH)

31. R R Reconnecting Partitioned Trees (2/4) Group Leader 1 Group Leader 1 Network Partition Network Partition Hello(GL2) Group Leader 2 Group Leader 2 R R (a) Partitioned network before the repair

32. R R Reconnecting Partitioned Trees (3/4) Group Leader 1 Group Leader 1 Network Partition Network Partition RREQ (can I repair partition?) RREP (Yes) RREQ (repair) Group Leader 2 Group Leader 2 R R

33. Group Leader 2 becomes leader of the merged multicast tree New group sequence number is larger than most recent ones known to both GL1 and GL2 New group leader then sends a Group Hello message (with a special flag) R Reconnecting Partitioned Trees (4/4) Group Leader R R (b) Reconnected network

34. Action after Reboot • lose all of its multicast tree information • Upon reboot, broadcast a MACT with a set Reboot flag • When a node on the multicast tree receives the reboot MACT, it checks whether this message came from one of its next hops on the multicast tree. If so, • From a downstream link, • deletes that link from its list of next hops • proceeds such as break link • From a upstream link, • rebuild the tree

35. Others

36. Optimizations And Enhancements • excellent performance in various network scenarios • There are still ways to improve and to enhance AODV • QoS • AODV defines extensions that can be used to request certain QoS parameters (i.e. Maximum Delay, Minimum Bandwidth) • Subnet Routing • If all nodes are reachable in a single hop, the collection can be treated as a subnet, and it has many advantages in management. • Mobile IP • There are various approach to offering Mobile IP to an ad hoc network

37. Future Work • Security • Asymmetric Routing

38. Conclusion • AODV offers excellent performance for both unicast and multicast routing • Continue to explore the performance of AODV under new conditions • Encourage further research and development for distance-vector routing protocols in general and AODV specifically.