AODV

AODV Description
People
DYMO
Related Publications
Current Internet Drafts
Public Implementations
Implementors Mailing List
Simulation Code
AODV Next Generation (AODVng) 2002 Workshop
Internet Draft Archives
Presentations


The Ad hoc On Demand Distance Vector (AODV) routing algorithm is a routing protocol designed for ad hoc mobile networks. AODV is capable of both unicast and multicast routing. It is an on demand algorithm, meaning that it builds routes between nodes only as desired by source nodes. It maintains these routes as long as they are needed by the sources. Additionally, AODV forms trees which connect multicast group members. The trees are composed of the group members and the nodes needed to connect the members. AODV uses sequence numbers to ensure the freshness of routes. It is loop-free, self-starting, and scales to large numbers of mobile nodes.

AODV builds routes using a route request / route reply query cycle. When a source node desires a route to a destination for which it does not already have a route, it broadcasts a route request (RREQ) packet across the network. Nodes receiving this packet update their information for the source node and set up backwards pointers to the source node in the route tables. In addition to the source node's IP address, current sequence number, and broadcast ID, the RREQ also contains the most recent sequence number for the destination of which the source node is aware. A node receiving the RREQ may send a route reply (RREP) if it is either the destination or if it has a route to the destination with corresponding sequence number greater than or equal to that contained in the RREQ. If this is the case, it unicasts a RREP back to the source. Otherwise, it rebroadcasts the RREQ. Nodes keep track of the RREQ's source IP address and broadcast ID. If they receive a RREQ which they have already processed, they discard the RREQ and do not forward it.

As the RREP propagates back to the source, nodes set up forward pointers to the destination. Once the source node receives the RREP, it may begin to forward data packets to the destination. If the source later receives a RREP containing a greater sequence number or contains the same sequence number with a smaller hopcount, it may update its routing information for that destination and begin using the better route.

As long as the route remains active, it will continue to be maintained. A route is considered active as long as there are data packets periodically travelling from the source to the destination along that path. Once the source stops sending data packets, the links will time out and eventually be deleted from the intermediate node routing tables. If a link break occurs while the route is active, the node upstream of the break propagates a route error (RERR) message to the source node to inform it of the now unreachable destination(s). After receiving the RERR, if the source node still desires the route, it can reinitiate route discovery.

Multicast routes are set up in a similar manner. A node wishing to join a multicast group broadcasts a RREQ with the destination IP address set to that of the multicast group and with the 'J'(join) flag set to indicate that it would like to join the group. Any node receiving this RREQ that is a member of the multicast tree that has a fresh enough sequence number for the multicast group may send a RREP. As the RREPs propagate back to the source, the nodes forwarding the message set up pointers in their multicast route tables. As the source node receives the RREPs, it keeps track of the route with the freshest sequence number, and beyond that the smallest hop count to the next multicast group member. After the specified discovery period, the source node will unicast a Multicast Activation (MACT) message to its selected next hop. This message serves the purpose of activating the route. A node that does not receive this message that had set up a multicast route pointer will timeout and delete the pointer. If the node receiving the MACT was not already a part of the multicast tree, it will also have been keeping track of the best route from the RREPs it received. Hence it must also unicast a MACT to its next hop, and so on until a node that was previously a member of the multicast tree is reached.

AODV maintains routes for as long as the route is active. This includes maintaining a multicast tree for the life of the multicast group. Because the network nodes are mobile, it is likely that many link breakages along a route will occur during the lifetime of that route. The papers listed below describe how link breakages are handled. The WMCSA paper describes AODV without multicast but includes detailed simulation results for networks up to 1000 nodes. The Mobicom paper describes AODV's multicast operation and details simulations which show its correct operation. The internet drafts include descriptions of both unicast and multicast route discovery, as well as mentioning how QoS and subnet aggregation can be used with AODV. Finally, the IEEE Personal Communications paper and the Infocom paper details an in-depth study of simulations comparing AODV with the Dynamic Source Routing (DSR) protocol, and examines each protocol's respective strengths and weaknesses.


People


DYMO


Related Publications


IETF Internet Drafts and RFC


AODV Public Implementations

KERNEL-AODV NIST Implementation, RFC compliant (recommended - interoperability tested)

AODV-UU Uppsala University Implementation, RFC compliant (recommended - interoperability tested)

UoBWinAODV Windows Implementation

AODV-UIUC Implementation

AODV-UCSB Implementation, draft v6 (interoperability tested), no longer recommended.

UoB-JAdhoc AODV Implementation, RFC 3561

AODV For IPv6

HUT AODV For IPv6

MAODV-UMD, Multicast Extensions of AODV

Mad-hoc Implementation (not recommended - no longer supported)

TinyAODV for TinyOS

Simulation and partial implementation of AODV for IPv6 (mostly userspace python)

AODV-Implementors Mailing List

AODV Simulation Code

Uppsala University Implementation (recommended)

NS-2 Simulation Code, NS-2 version 2.1b3a and 2.1b4a

NS-2 Simulation Code, NS-2 version 2.1b8a

Glomosim Code, AODV Draft v13 compliant

OPNET 7 Simulation Model

NS-2 Simulation Code for MAODV (new!)


AODV Next Generation (AODVng) 2002 Workshop


AODV Draft Archives


Presentations