The Ad Hoc On-Demand Distance-Vector Protocol: Quality of Service Extensions

The Ad Hoc On-Demand Distance-Vector Protocol: Quality of Service Extensions Jani Lakkakorpi Nokia Research Center jani.lakkakorpi@nokia.com Abstract Ad Hoc On-Demand Distance-Vector routing protocol provides fast and efficient route establishment between mobile nodes that need to communicate with each other. Since AODV has been specifically designed for ad hoc wireless networks, it has minimal control overhead and route acquisition latency. In addition to unicast routing, AODV supports multicast and broadcast as well. Moreover, AODV can be extended to support Quality of Service (QoS). The goal of this paper is to take a closer look at these QoS extensions. Since the QoS extensions are relatively new concept, it is not that clear yet how to properly utilize them. They may introduce some problems as well. 1 Introduction Ad hoc networks can be defined, for example, as networks that come together as needed even without any assistance from the existing Internet infrastructure [1]. Internet Engineering Task Force (IETF) has an official charter on Mobile Ad-hoc Networks (manet) [2]. The Ad Hoc On-Demand Distance-Vector routing protocol (AODV) has its roots in Destination- Sequenced Distance-Vector (DSDV) routing protocol [3]. However, AODV has been designed specifically for ad hoc wireless networks. AODV provides fast route establishment and minimal control overhead. The system-wide broadcasts have been minimized from those of DSDV [1]. built only when they are requested by originator nodes. Routes are maintained only as long as originators need them. Multicast mode is supported by forming trees composed of multicast group members and intermediate nodes that are needed to connect the group members. In order to ensure route validity, AODV uses sequence numbers (just like DSDV [3]). AODV is loop-free, self-starting and scales to very large numbers of mobile nodes [4]. The basics of AODV s unicast routing mode are described according to presentations in the following references: [1, 4, 5, 6]. As stated before, route discovery in AODV is done on demand and it follows a route request / route reply discovery cycle. Whenever a route is needed between two nodes, the originator node broadcasts a route request (RREQ, see Figure 4) across the network. Nodes that receive this RREQ will update their information for the originator node in question and set up backward pointers to the originator node in their route tables (reverse route is set up in order to forward a RREP packet back to the originator from the destination or from an intermediate node having a route to the destination [6]). This paper is organized as follows: section 2 describes the basic properties of AODV (mainly concentrating on unicast routing), section 3 focuses on the Quality of Service extensions, section 4 gives some performance figures and section 5 includes some conclusions. 2 AODV Properties AODV is a routing protocol designed especially for ad hoc mobile networks. In addition to unicast routing, AODV supports multicasting. AODV is an on-demand algorithm, which means that routes between nodes are Figure 1: RREQ propagation

RREQ contains the most recent Destination Sequence Number of which the originator node is aware. A node that receives the RREQ message may unicast a route reply (RREP, see Figure 5) back to the originator node if: (1) it is the destination or (2) if it has a fresh enough route to the destination (corresponding sequence number greater than or equal to that contained in the RREQ). Otherwise, the node will rebroadcast the RREQ. All nodes keep track of those RREQs they have already seen (Originator IP Address RREQ ID pair). If the same RREQ is received again, it is silently discarded. - Routing Flags Figure 3: Route maintenance Figure 2: Reverse route entries As the RREP propagates back to the originator node, all nodes along the path set up forward pointers to the destination node (a forward route is set up to send data packets from a node originating the route discovery operation towards its desired destination [6]). Once the originator node receives the RREP, it will be able to send data packets to the destination node. If the originator node later happens to receive a RREP containing a greater sequence number or a RREP with the same sequence number but a smaller hop count, it may update its routing information for that destination and start using the better route. Each route table entry includes the following fields: - Destination IP Address - Destination Sequence Number - Interface - Hop Count (number of hops to destination) - Last Hop Count (the Hop Count indicated in the RREP packet is stored as the Last Hop Count in the route table; see [6] for details) - Next Hop - List of Precursors (contains the IP addresses for neighbors that are likely to use this node as a next hop towards the destination that is now unreachable) - Lifetime (expiration or deletion time of the route) Routes are maintained as long as they remain active (as long as there is frequent enough data traffic to the destination). When traffic to a destination stops, the route will time out and eventually it will be deleted from the route table. If a link break occurs while the route is still active, a route error (RERR, see Figure 6) message to the originator node is sent by the node that is closer to originator node. RERR message includes information on the now unreachable destinations. If the originator node still needs routes to these destinations, it can reinitiate route discovery. 3 QoS Extensions to AODV AODV is one of the few ad hoc routing protocols that are able to provide some sort of Quality of Service (QoS) guarantees at least on paper. It seems that there are no (public) AODV implementations that would realize the proposed QoS features. (At least we did not find any.) However, there are more and more new applications that might benefit from these QoS guarantees. For example, guaranteed maximum delay and jitter might be very useful for Voice over IP (VoIP) also in mobile ad hoc networks. In order to provide QoS, certain extensions can be added to the messages that are used for route discovery. A node which receives a RREQ message with a QoS extension must be able to meet the given service requirement in order to either rebroadcast the RREQ message (if the node does not have a route to the destination) or unicast a RREP message back to the originator. If, after route establishment, any node along the path detects that the requested QoS parameters cannot be maintained anymore, that node must send an ICMP QOS_LOST message back to the node, which originally requested these parameters.

Type J R G Reserved Hop Count RREQ ID Destination IP Address Destination Sequence Number Originator IP Address Originator Sequence Number Figure 4: RREQ message format [6] Type R A Reserved Prefix Sz Hop Count Destination IP Address Destination Sequence Number Originator IP Address Lifetime Figure 5: RREP message format [6] Type N Reserved DestCount Unreachable Destination IP Address (1) Unreachable Destination Sequence Number (1) +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- Additional Unreachable Destination IP Addresses (if needed) Additional Unreachable Destination Sequence Numbers (if needed) The old Internet Draft on QoS extensions to AODV has already expired (14 January 2001), and the new version does not have manet working group document status yet [2]. However, Internet Draft search finds the new version (see also the manet mailing list archive from December 2001 [10]). The latest Internet Draft on QoS extensions to AODV [9] defines QoS Object extension, which includes bandwidth and delay parameters. In order to enable accumulated measurement for end-to-end delay, this draft also provides a Maximum Permissible Delay extension. If, after establishment of a QoS route, any node along the path detects that the requested QoS parameters cannot be Figure 6: RERR message format [6] maintained anymore, that node has to originate an ICMP QOS_LOST message back to the node, which had originally requested these parameters. In order to support QoS routing, extensions are needed in the route table structure and the RREQ and RREP messages. These extensions conform to the format defined for extensions to RREQ and RREP messages. 3.1 Route Table Extensions The following fields are added to each route table entry corresponding to each destination: Maximum Delay Minimum Available Bandwidth

List of Originators Requesting Delay Guarantees List of Originators Requesting Bandwidth Guarantees 3.2 QoS Object Format The QoS information about a microflow can be encoded into a standard format illustrated in Figure 7. This standard format allows complete flexibility for specification of arbitrary values for various QoS requirements. It also allows compact representation, especially for well-known requirements for common applications. The standard object format is used as the main part of the QoS Object Extension (see Figure 8). The fields of QoS Object have the following meanings: Reservd: Sent as zero, unused and undefined on reception. QoS Profile Type: If set to zero, the fields are as listed below in this section, and there are no default values. Otherwise, an index for a list of QoS parameter field definitions and default values for those fields. NNNNN: If QoS Profile Type is zero, this bit is not defined to be part of the QoS Object format. Otherwise, when the N bit is set, the next 31 bits are part of Non-Default Values. Non-Default Values: A bit vector with one bit for each field parameter field defined for the particular QoS Profile Type number. QoS Parameter Fields: Defined in accordance with the QoS Profile Type. For QoS Profile Type zero, the following parameter fields are defined: Capacity Requirement: 32-bit number [bps]. Maximum Permissible Delay: 16-bit number [ms]. Maximum Permissible Jitter: 16-bit number [ms]. Traffic Class: According to Differentiated Services Code Points. 3.3 QoS Object Extension Format A node originating a RREQ message may append a QoS Object extension to the RREQ in order to find a path that satisfies the QoS parameters in the QoS Object. If a delay parameter is specified (either explicitly or implicitly by a default value for some QoS Profile type) the originating node also has to append a Maximum Delay Extension (see Figure 9) for use of the intermediate nodes that need to accumulate the expected value for delay across various candidate paths. Likewise, if an originating node specifies a maximum value for allowable jitter as part of the QoS parameter data, the node has to append a Maximum Jitter Extension after the QoS Object extension. 3.4 Maximum Delay & Jitter Extension Formats The Maximum Delay and Jitter Extensions (see Figure 9 and Figure 10) can only be added to RREQ messages that contain the QoS Object extension. They provide information about the cumulative delay and jitter along the path from the originating node to the node currently processing the RREQ Delay and Jitter fields indicate the current estimates of cumulative delay and jitter from the originating node up to the intermediate node retransmitting the RREQ on behalf of the originating node. The Maximum Delay and Jitter Extensions can be appended to a RREQ by a node requesting a QoS route in order to measure the existing delay or jitter from the originating node. The goal is to check whether the path can still meet the required Maximum Delay or Jitter specification within the QoS Object data. Before forwarding the RREQs, intermediate nodes have to compare their NODE_TRAVERSAL_TIME or approximate jitter to the (remaining) Delay or Jitter indicated in the Maximum Delay/Jitter Extension. If the Delay/Jitter is less, the node has to discard the RREQ message. Otherwise, the node subtracts the value of NODE_TRAVERSAL_TIME or its estimated jitter from the Delay or Jitter value in the extension and continues processing the RREQ message. A node forwarding a RREP message also has to store the Originator IP Address in the RREP to the list of originator nodes that have requested delay or jitter guarantees to the corresponding destination. These originators will be notified with an ICMP QOS_LOST message if there is a change in NODE_TRAVERSAL_TIME or jitter experienced at this node. 3.5 ICMP QOS LOST Message An ICMP QOS_LOST message is generated when an intermediate node experiences a significant change in its ability to provide to the QoS guarantees it has made as part of generating a RREP during the QoS Route Discovery process. Destination IP Address in ICMP QOS_LOST message (see Figure 11) is the address of the destination node using the link for which there has been a change in some QoS parameter. This message is extended using the QoS Object Extension (see Figure 8). Typically, QoS Profile Type

zero is used, including the actual measured parameter, which fails to meet some previously requested QoS. For example, the Minimum Bandwidth field is used when capacity of some link decreases. The ICMP_QOS_LOST message is forwarded to all originator nodes that might be affected by the change in the QoS parameter value; i.e., those originators to which a RREP with a QoS extension has been forwarded before. As stated before, these originators are recorded in a list as a part of the route table entry. 4 AODV Performance References [11, 12] Performance Comparison of Two On-Demand Routing Protocols for Ad Hoc Networks (same paper, different versions) shed some light on the performance of AODV protocol. AODV s performance was compared to that of Dynamic Source Routing (DSR) using detailed simulation models. The authors demonstrate that even though DSR and AODV share similar on-demand behavior, their differences can lead to significant differences in performance. One of the main results of these simulations was that for application-oriented metrics like delay and throughput, DSR outperforms AODV in less loaded situations (50 nodes and lower mobility). On the other hand, AODV outperformed DSR in more loaded (100 nodes and higher mobility) situations. DSR, however, consistently generates less routing load than AODV. One can try to verify these results, for example, with the Network Simulator (ns-2) [13] or GloMoSim [14]. +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Reservd QoS Profile Type :N: Non-Default Values Bit Vector :N Additional Non-Default Values Bit Vector (if present) : : QoS fields with non-default values (if present) : Figure 7: QoS object format Type (TBD) Length (var.) QoS Object (variable)... : Figure 8: QoS object extension format Type (TBD) Length (2) Delay Figure 9: Maximum delay extension format Type (TBD) Length (2) Jitter Figure 10: Maximum jitter extension format Type (8) Destination IP Address +-+-+-+-+-+-+-+-+ Figure 11: ICMP QoS Lost message format

5 IETF Status & Conclusions The latest AODV base specification (draft-ietf-manetaodv-10.txt) was published in January 2002 [6]. The changes include the following: In RREQ & RREP message formats: changed the Source IP Address field to be Originator IP Address. In RREQ message format: changed the Source Sequence Number' field to be Originator Sequence Number. The lifetime for the route to the next hop towards a destination should be updated when a data packet is forwarded to that node. It seems that this draft might soon become an experimental RFC. It can also be expected that at least DSR would gain the RFC status [15]. The status of the other Internet Drafts on AODV is the following: draft-ietf-manet-bcast-00.txt (flooding): expires 14 May 2002 draft-perkins-manet-aodvqos-00.txt (QoS ext.): not a manet working group document yet, expires 14 May 2002 draft-perkins-manet-aodv6-01.txt (IPv6): expired draft-ietf-manet-maodv-00.txt (multicast): expired Mobile ad hoc networks will surely gain popularity if Internet connectivity could be provided. Internet Drafts Global Connectivity for IPv4 Mobile Ad hoc Networks [16] and Global Connectivity for IPv6 Mobile Ad hoc Networks [17] give descriptions how to do this using e.g., AODV and Mobile IP. Some of the recent developments in AODV (and ad hoc routing protocols in general) include multipath routing. For example, [18] proposes an AODV-based routing protocol that establishes multiple paths for a route discovery procedure. This should save bandwidth and reduce route reconstruction times when routes fail. QoS extensions of AODV may result into better performance, but intermediate nodes modifying the packet, however, may introduce a serious problem with IPSEC. It may be possible that IPSEC cannot be used with these QoS extensions [19]. Moreover, it seems that there are no (public) AODV implementations that would support the proposed QoS extensions. However, this will most probably change in the near future as QoS becomes increasingly popular. 6 References [1] Charles E. Perkins (editor): Ad Hoc Networking, 2001, Addison-Wesley, ISBN 0-201-30976-9. [2] Mobile Ad-hoc Networks (manet) charter, http://ietf.org/html.charters/manet-charter.html. [3] Charles E. Perkins, P. Bhagwat: Highly Dynamic Destination-Sequenced Distance-Vector Routing (DSDV) for Mobile Computers, ACM SIGCOMM '94 Computer Communications Review 24 (4), pp. 234-244, October 1994. [4] Elizabeth M. Belding-Royer s AODV page, March 2002, http://www.cs.ucsb.edu/~eroyer/aodv.html. [5] Charles E. Perkins and Elizabeth M. Royer: Ad hoc On-Demand Distance Vector Routing, Proceedings of the 2nd IEEE Workshop on Mobile Computing Systems and Applications, New Orleans, LA, February 1999, pp. 90-100. [6] Charles E. Perkins, Elizabeth M. Belding-Royer, and Samir Das: Ad Hoc On-Demand Distance Vector (AODV) Routing, IETF Internet draft, draft-ietf-manet-aodv-10.txt, January 2002 (Work in Progress), http://search.ietf.org/internet-drafts/draftietf-manet-aodv-10.txt. [7] Elizabeth M. Royer and Charles E. Perkins: Multicast Operation of the Ad hoc On-Demand Distance Vector Routing Protocol, Proceedings of MobiCom '99, Seattle, WA, August 1999, pp. 207-218. [8] Charles E. Perkins, Elizabeth M. Royer, and Samir R. Das: IP Flooding in Ad hoc Mobile Networks, IETF Internet Draft, draft-ietf-manet-bcast-00.txt, November 2001 (Work in Progress), http://search.ietf.org/internet-drafts/draft-ietf-manetbcast-00.txt. [9] Charles E. Perkins and Elizabeth M. Royer: Quality of Service in Ad hoc On-Demand Distance Vector Routing, IETF Internet Draft, draft-perkinsmanet-aodvqos-00.txt, November 2001 (Work in Progress), http://search.ietf.org/internet-drafts/draftperkins-manet-aodvqos-00.txt. [10] Elizabeth M. Belding-Royer: New/Revised Internet Drafts (December 3, 2001), manet mailing list archive of December 2001, ftp://manet.itd.nrl.navy.mil/pub/manet/2001-12.mail. [11] Samir R. Das, Charles E. Perkins, Elizabeth M. Royer and Mahesh K. Marina: Performance Comparison of Two On-demand Routing Protocols for Ad hoc Networks, IEEE Personal Communications Magazine special issue on Ad hoc Networking, February 2001, p. 16-28. [12] Samir R. Das, Charles E. Perkins, and Elizabeth M. Royer: Performance Comparison of Two Ondemand Routing Protocols for Ad Hoc Networks, Proceedings of the IEEE Conference on Computer Communications (INFOCOM), Tel Aviv, Israel, March 2000, p. 3-12.

[13] UCB/LBNL/VINT, Network Simulator ns2, March 2002. http://www.isi.edu/nsnam/ns/index.html. [14] GloMoSim Global Mobile Information Systems Simulation Library, http://pcl.cs.ucla.edu/projects/glomosim/. [15] manet WG session of the 53rd IETF, Minneapolis, Minnesota, USA, March 17-22, 2002. [16] Elizabeth M. Belding-Royer, Yuan Sun, and Charles E. Perkins: Global Connectivity for IPv4 Mobile Ad hoc Networks, IETF Internet Draft, draft-royermanet-globalv4-00.txt, November 2001 (Work in Progress), http://search.ietf.org/internet-drafts/draftroyer-manet-globalv4-00.txt. [17] Ryuji Wakikawa, Jari T. Malinen, Charles E. Perkins, Anders Nilsson, and Antti J. Tuominen: Global Connectivity for IPv6 Mobile Ad hoc Networks, IETF Internet Draft, draft-wakikawamanet-globalv6-00.txt, November 2001 (Work in Progress), http://search.ietf.org/internet-drafts/draftwakikawa-manet-globalv6-00.txt. [18] Ming-Hong Jiang, Rong-Hong Jan and Chu-Fu Wang: An Efficient Multiple-Path Routing Protocol for Ad Hoc Networks, Computer Communications 25 (2002), pp. 478-484. [19] Pekka Savola: [manet] AODV QoS incompatible with IPSEC (April 7, 2002), manet mailing list archive of April 2002, http://www1.ietf.org/mailarchive/workinggroups/manet/current/msg00120.html.