4. Applicability Statement

The AODVv2 routing protocol is designed for stub (i.e., non-transit) or disconnected (i.e., from the Internet) mobile ad hoc networks (MANETs). AODVv2 handles a wide variety of mobility patterns by determining routes on-demand. AODVv2 also handles a wide variety of traffic patterns. In networks with a large number of routers, AODVv2 is best suited for relatively sparse traffic scenarios where any particular router forwards packets to only a small percentage of the AODVv2 routers in the network, due to the on-demand nature of route discovery and route maintenance. AODVv2 supports routers with multiple interfaces, as long as each interface has its own (unicast routeable) IP address; the set of all network interfaces supporting AODVv2 is administratively configured in a list (namely, AODVv2_INTERFACES).

Although AODVv2 is closely related to AODV [RFC3561], and has some of the features of DSR [RFC4728], AODVv2 is not interoperable with either of those other two protocols.

AODVv2 is applicable to memory constrained devices, since little routing state is maintained in each AODVv2 router. Only routing information related to routes between active sources and destinations is maintained, in contrast to proactive routing protocols that require routing information to all routers within the MANET be maintained.

In addition to routing for its own local applications, each AODVv2 router can also route on behalf of other non-routing nodes (i.e., "hosts", or, in this document, "clients"), reachable via those interfaces. Each AODVv2 router, if serving router clients other than itself, is configured with information about the IP addresses of its clients. No AODVv2 router is required to have information about the relationship between any other AODVv2 router and its router clients (see Section 5.3).

The coordination among multiple AODVv2 routers to distribute routing information correctly for a shared address (i.e. an address that is advertised and can be reached via multiple AODVv2 routers) is not described in this document. The AODVv2 router operation of shifting responsibility for a routing client from one AODVv2 router to another is mentioned in Appendix C. Address assignment procedures are entirely out of scope for AODVv2. Any such node which is not itself an AODVv2 router SHOULD NOT be served by more than one AODVv2 router at any one time.

Multi-homing is difficult unless the sequence number is expanded to include the AODVv2 router's IP address as well as SeqNum. Otherwise, comparing sequence numbers would not work to evaluate freshness. Even when the IP address is included, there isn't a good way to compare sequence numbers from different IP addresses, but at least a handling node can determine whether the two given sequence numbers are comparable. If the route table can store multiple routes for the same destination, then multi-homing can work with sequence numbers augmented by IP addresses.

AODVv2 routers perform route discovery to find a route toward a particular destination. Therefore, AODVv2 routers MUST must be configured to respond to RREQs for a certain set of addresses. When AODVv2 is the only protocol interacting with the forwarding table, AODVv2 MAY be configured to perform route discovery for all unknown unicast destinations.

AODVv2 only supports bidirectional links. In the case of possible unidirectional links, either blacklists (see Section 5.2) or other means (e.g. adjacency establishment with only neighboring routers that have bidirectional communication as indicated by NHDP [RFC6130]) of assuring and monitoring bi-directionality are recommended. Otherwise, persistent packet loss or persistent protocol failures could occur. The cost of bidirectional link L (denoted Cost(L)) may depend upon the direction across the link for which the cost is measured. Metric information from incoming AODVv2 messages SHOULD NOT be used for route table updates unless it has been received over a link that is bidirectional.

The routing algorithm in AODVv2 may be operated at layers other than the network layer, using layer-appropriate addresses. The routing algorithm makes of some persistent state; if there is no persistent storage available for this state, recovery can impose a performance penalty (e.g., in case of AODVv2 router reboots).

5. Data Structures

5.1. Route Table Entry

The route table entry is a conceptual data structure. Implementations may use any internal representation so long as it provides access to the information specified below.

Conceptually, a route table entry has the following fields:

Route.Address

The (host or network) destination address of the node(s) associated with the routing table entry

Route.PrefixLength

The length of the netmask/prefix. If the value of the Route.PrefixLength is less than the length of addresses in the address family used by the AODVv2 routers, the associated address is a routing prefix, rather than a host address. A PrefixLength is stored for every route in the route table.

Route.SeqNum

The Sequence Number associated with destination of the route, as obtained from the last packet that updated the route table entry associated with a route table entry.

Route.NextHopAddress

An IP address of the adjacent AODVv2 router on the path toward the Route.Address

Route.NextHopInterface

The interface used to send packets toward the Route.Address

Route.LastUsed

The time that this route was last used

Route.ExpirationTime

The time at which this route must expire

Route.Broken

A flag indicating whether this Route is broken. This flag is set to true if the next-hop becomes unreachable or in response to processing to a RERR (see Section 8.4)

Route.MetricType

The type of the metric for the route towards Route.Address

Route.Metric

The cost of the route towards Route.Address

A route table entry (i.e., a route) may be in one of the following states:

Active

An Active route is in current use for forwarding packets

Idle

An Idle route can be used for forwarding packets, even though it is not in current use

Expired

After a route has been idle for too long, it expires, and may no longer be used for forwarding packets

Broken

A route marked as Broken cannot be used for forwarding packets but still has valid destination sequence number information.

Timed

The expiration of a Timed route is controlled by the Route.ExpirationTime time of the route table entry (instead of MAX_IDLETIME). Until that time, a Timed route can be used for forwarding packets. Afterwards, the route must be Expired (or expunged).

The route's state determines the operations that can be performed on the route table entry. During use, an Active route is maintained continuously by AODVv2 and is considered to remain active as long as it is used at least once during every ACTIVE_INTERVAL. When a route is no longer Active, it becomes an Idle route. After an idle route remains Idle for MAX_IDLETIME, it becomes an Expired route. An Expired route is not used for forwarding, but the sequence number information can be maintained until the destination sequence number has had no updates for MAX_SEQNUM_LIFETIME; after that time, old sequence number information is considered no longer valuable and the Expired route MUST BE expunged.

MAX_SEQNUM_LIFETIME is the time after a reboot during which an AODVv2 router MUST NOT transmit any routing messages. Thus, if all other AODVv2 routers expunge routes to the rebooted router after that time interval, the rebooted AODVv2 router's sequence number will not be considered stale by any other AODVv2 router in the MANET.

When the link to a route's next hop is broken, the route is marked as being Broken, and the route may no longer be used.

5.2. Bidirectional Connectivity and Blacklists

To avoid repeated failure of Route Discovery, an AODVv2 router (HandlingRtr) handling a RREP message SHOULD attempt to verify connectivity to the next upstream router towards AODVv2 router originating an RREQ message. This MAY be done by including the Acknowledgement Request (AckReq) message TLV (see Section 15.2) in the RREP. Any unicast packet will satisfy the Acknowledgement Request, for example an ICMP REPLY message. If the verification is not received within UNICAST_MESSAGE_SENT_TIMEOUT, HandlingRtr SHOULD put the upstream neighbor in the blacklist. RREQs received from a blacklisted node, or any node over a link that is known to be incoming-only, SHOULD NOT be retransmitted by HandlingRtr. However, the upstream neighbor SHOULD NOT be permanently blacklisted; after a certain time (MAX_BLACKLIST_TIME), it SHOULD once again be considered as a viable upstream neighbor for route discovery operations.

For this purpose, a list of blacklisted nodes along with their time of removal SHOULD be maintained:

Blacklist.Node

The IP address of the node that did not verify bidirectional connectivity.

Blacklist.RemoveTime

The time at which Blacklist.Node will be removed from the blacklist.

5.3. Router Clients and Client Networks

An AODVv2 router may offer routing services to other nodes that are not AODVv2 routers. AODVv2 defines the Sequence Number to be the same for the AODVv2 router and each of its clients.

For this purpose, CLIENT_ADDRESSES must be configured on each AODVv2 router with the following information:

Client IP address

The IP address of the node that requires routing service from the AODVv2 router.

Client Prefix Length

The length of the routing prefix associated with the client IP address.

If the Client Prefix Length is not the full length of the Client IP address, then the prefix defines a Client Network. If an AODVv2 router is configured to serve a Client Network, then the AODVv2 router MUST serve every node that has an address within the range defined by the routing prefix of the Client Network. The list of Routing Clients for an AODVv2 router is never empty, since an AODVv2 router is always its own client as well.

5.4. AODVv2 Packet Header Fields and Information Elements

In its default mode of operation, AODVv2 transmits UDP packets using the parameters for port number and IP protocol specified in [RFC5498] to carry protocol packets. By default, AODVv2 packets are sent with the IP destination address set to the link-local multicast address LL-MANET-Routers [RFC5498] unless otherwise specified. Therefore, all AODVv2 routers MUST subscribe to LL-MANET-Routers [RFC5498] to receiving AODVv2 messages. In order to reduce multicast overhead, retransmitting multicast packets in MANETs SHOULD be done according to methods specified in [RFC6621]. AODVv2 does not specify which method should be used to restrict the set of AODVv2 routers that have the responsibility to retransmit multicast packets. Note that multicast packets MAY be sent via unicast. For example, this may occur for certain link-types (non-broadcast media), for manually configured router adjacencies, or in order to improve robustness.

The IPv4 TTL (IPv6 Hop Limit) field for all packets containing AODVv2 messages is set to 255. If a packet is received with a value other than 255, any AODVv2 message contained in the packet MUST be disregarded by AODVv2. This mechanism, known as "The Generalized TTL Security Mechanism" (GTSM) [RFC5082] helps to assure that packets have not traversed any intermediate routers.

IP packets containing AODVv2 protocol messages SHOULD be given priority queuing and channel access.

AODVv2 messages are transmitted in packets that conform to the packet and message format specified in [RFC5444]. Here is a brief summary of the format. [RFC5444]. The length of an address (32 bits for IPv4 and 128 bits for IPv6) inside an AODVv2 message is indicated by the msg-addr-length (MAL) in the msg-header, as specified in [RFC5444].

A packet formatted according to RFC 5444 contains zero or more messages.

A message contains a message header, message TLV block, and zero or more address blocks.

Each address block may also have an associated TLV block; this TLV block may encode multiple TLVs. According to RFC 5444, each such TLV may itself include an array of values.

If a packet contains only a single AODVv2 message and no packet TLVs, it need only include a minimal Packet-Header

When multiple messages are aggregated into a single packet according to RFC 5444 formatting, and the aggregation of messages is also authenticated (e.g., with IPsec), and the IP destination is multiple hops away, it becomes infeasible to delete individual messages. In such cases, instead of deleting individual messages, they are maintained in the aggregation of messages, but simply ignored for further processing. In such cases where individual messages cannot be deleted, in this document "disregarded" means "ignored". Otherwise, any such "disregarded" AODVv2 messages SHOULD be deleted from the aggregated messages in the RFC 5444 packet.

5.5. Sequence Numbers

Sequence Numbers allow AODVv2 routers to evaluate the freshness of routing information. Each AODVv2 router in the network MUST maintain its own sequence number. Each RREQ and RREQ generated by an AODVv2 router includes that sequence number. Each AODVv2 router MUST make sure that its sequence number is unique and monotonically increasing. This can be achieved by incrementing it with every RREQ or RREP it generates.

Every router receiving a RREQ or RREP can thus use the Sequence Number of a RREQ or RREP as information concerning the freshness of the packet's route update: If the new packet's Sequence Number is lower than the one already stored in the routing table, its information is considered stale.

As a consequence, loop freedom is assured.

An AODVv2 router increments its SeqNum as follows. Most of the time, SeqNum is incremented by simply adding one (1). But when the SeqNum has the value of the largest possible number representable as a 16-bit unsigned integer (i.e., 65,535), it MUST be incremented by setting to one (1). In other words, the sequence number after 65,535 is 1.

An AODVv2 router SHOULD maintain its SeqNum in persistent storage. If an AODVv2 router's SeqNum is lost, it MUST take the following actions to avoid the danger of routing loops. First, the AODVv2 router MUST invalidate all route table entries, by setting Route.Broken for each entry. Furthermore the AODVv2 router MUST wait for at least MAX_SEQNUM_LIFETIME before transmitting or retransmitting any AODVv2 RREQ or RREP messages. If an AODVv2 protocol message is received during this waiting period, the AODVv2 router SHOULD perform normal route table entry updates, but not forward the message to other nodes. If a data packet is received for forwarding to another destination during this waiting period, the AODVv2 router MUST transmit a RERR message indicating that no route is available. At the end of the waiting period the AODVv2 router sets its SeqNum to one (1) and begins performing AODVv2 protocol operations again.

5.6. Enabling Alternate Metrics

AODVv2 route selection in MANETs depends upon associating metric information with each route table entry. When presented with candidate route update information, deciding whether to use the update involves evaluating the metric. Some applications may require metric information other than Hop Count, which has traditionally been the default metric associated with routes in MANET. Unfortunately, it is well known that reliance on Hop Count can cause selection of the worst possible route in many situations.

It is beyond the scope of this document to describe how applications specify route selection at the time they launch processing. One possibility would be to provide a route metric preference as part of the library routines for opening sockets. In view of the above considerations, it is important to enable route selection based on metric information other than Hop Count -- in other words, based on "alternate metrics". Each such alternate metric measures a "cost" of using the associated route, and there are many different kinds of cost (latency, delay, monetary, energy, etc.).

The most significant change when enabling use of alternate metrics is to require the possibility of multiple routes to the same destination, where the "cost" of each of the multiple routes is measured by a different metric. Moreover, the method by which route updates are tested for usefulness has to be slightly generalized to depend upon a more abstract method of evaluation which, in this document, is named "Cost(R)", where 'R' is the route for which the Cost is to be evaluated. From the above, the route table information for 'R' must always include the type of metric by which Cost(R) is evaluated, so the metric type does not have to be shown as a distinct parameter for Cost(R). Since determining loop freedom is known to depend on comparing the Cost(R) of route update information to the Cost(R) of an existing stored route using the same metric, AODVv2 must also be able to invoke an abstract routine which in this document is called "LoopFree(R1, R2)". LoopFree(R1, R2) returns TRUE when, (under the assumption of nondecreasing SeqNum during Route Discovery) given that R2 is loop-free and Cost(R2) is the cost of route R2, Cost(R1) is known to guarantee loop freedom of the route R1. In this document, LoopFree(R1,R2) will only be invoked for routes R1 and R2 to the same destination which use the same metric.

Generally, HopCount may still be considered the default metric for use in MANETs, notwithstanding the above objections. Each metric has to have a Metric Type, and the Metric Type is allocated by IANA as specified in [RFC6551]. Each Route has to include the Metric Type as part of the route table entry for that route. Hop Count has Metric Type assignment 3. The Cost of a route using Metric Type 3 is simply the hop count between the router and the destination. For routes R1 and R2 using Metric Type 3, LoopFree (R1, R2) is TRUE when Cost(R2) ≤ (Cost(R1) + 1). The specification of Cost(R) and LoopFree(R1,R2) for metric types other than 3 is beyond the scope of this document.

Whenever an AODV router receives metric information in an incoming message, the value of the metric is as measured by the transmitting router, and does not reflect the cost of traversing the incoming link. In order to simplify the description of storing accrued route costs in the route table, the Cost() function is also defined to return the value of traversing a link 'L'. In other words, the domain of the Cost() function is enlarged to include links as well as routes. For Metric Type 3, (i.e., the HopCount metric) Cost(L) = 1 for all links. The specification of Cost(L) for metric types other than 3 is beyond the scope of this document. Whether the argument of the Cost() function is a link or a route will, in this document, always be clear. As a natural result of the way routes are looked up according to conformant metric type, all intermediate routers handling a RteMsg will assign the same metric type to all metric information in the RteMsg.

For some metrics, a maximum value is defined, namely MAX_METRIC[i] where 'i' is the Metric Type. AODVv2 does not store routes that cost more than MAX_METRIC[i]. MAX_METRIC[3] is defined to be MAX_HOPCOUNT, where as before 3 is the Metric Type of the HopCount metric. MAX_HOPCOUNT MUST be larger than the AODVv2 network diameter. Otherwise, AODVv2 protocol messages may not reach their intended destinations.

5.7. RREQ Table: Received RREQ Messages

Two incoming RREQ messages are considered to be "comparable" if they were generated by the same AODVv2 router in order to discover a route for the same destination with the same metric type. According to that notion of comparability, when RREQ messages are flooded in a MANET, an AODVv2 router may well receive comparable RREQ messages from more than one of its neighbors. A router, after receiving an RREQ message, MUST check against previous RREQs to assure that its response message would contain information that is not redundant. Otherwise, multicast RREQs are likely to be retransmitted again and again with almost no additional benefit, but generating a great deal of unnecessary signaling traffic and interference.

To avoid transmission of redundant RREQ messages, while still enabling the proper handling of earlier RREQ messages that may have somehow been delayed in the network, it is needed for each AODVv2 router to keep a list of the certain information about RREQ messages which it has recently received.

This list is called the AODVv2 Received RREQ Table -- or, more briefly, the RREQ Table. Two AODVv2 RREQ messages are comparable if:

• they have the same metric type
• they have the same OrigNode and TargNode addresses

Each entry in the RREQ Table has the following fields:

• Metric Type
• OrigNode address
• TargNode address
• Sequence Number
• Metric
• Timestamp

The RREQ Table is maintained so that no two entries in the RREQ Table are comparable -- that is, all RREQs represented in the RREQ Table either have different OrigNode addresses, different TargNode addresses, or different metric types. If two RREQs have the same metric type and OrigNode and Targnode addresses, the information from the one with the older Sequence Number is not needed in the table; in case they have the same Sequence Number, the one with the greater Metric value is not needed; in case they have the same Metric as well, it does not matter which table entry is maintained. Whenever a RREQ Table entry is updated, its Timestamp field should also be updated to reflect the Current_Time.

When optional multicast RREP (see Section 13.4) is used to enable selection from among multiple possible return routes, an AODVv2 router can eliminate redundant RREP messages using the analogous mechanism along with a RREP Table. Nevertheless, the description in this section only refers to RREQ multicast messages.

Protocol handling of RERR messages eliminates the need for tracking RERR messages, since the rules for RERR regeneration prevent the phenomenon of redundant retansmission that affects RREQ and RREP multicast.

6. AODVv2 Operations on Route Table Entries

In this section, operations are specified for updating the route table due to timeouts and route updates within AODVv2 messages. Route update information in AODVv2 messages includes IP addresses, along with the SeqNum and prefix length associated with each IP address, and including the Metric measured from the node transmitting the AODVv2 message to the IP address in the route update. IP addresses and prefix length are encoded within an RFC 5444 AddrBlk, and the SeqNum and Metric associated with each address in the AddrBlk are encoded in RFC 5444 AddrTLVs. In this section, RteMsg is either RREQ or RREP, RteMsg.Address[i] denotes the [i]th address in an RFC 5444 AddrBlk of the RteMsg. RteMsg.PrefixLength[i] denotes the associated prefix length for RteMsg.Address[i], and RteMsg.{field} denotes the corresponding value in the named AddrTLV block associated with RteMsg.Address[i]. All SeqNum comparisons use signed 16-bit arithmetic.

6.1. Evaluating Incoming Routing Information

If the incoming RteMsg does not have a Metric Type Message TLV, then the metric information contained by RteMsg is considered to be of type DEFAULT_METRIC_TYPE -- which is 3 (for HopCount) unless changed by administrative action. Whenever an AODVv2 router (HandlingRtr) handles an incoming RteMsg (i.e., RREQ or RREP), for every relevant address (RteMsg.Address) in the RteMsg, HandlingRtr searches its route table to see if there is a route table entry with the same Metric Type of the RteMsg, matching RteMsg.Address. If not, HandlingRtr creates a route table entry for RteMsg.Address as described in Section 6.2. Otherwise, HandlingRtr compares the incoming routing information in RteMsg against the already stored routing information in the route table entry (Route) for RteMsg.Address, as described below.

	 (RteMsg.SeqNum > Route.SeqNum) OR
	{(RteMsg.SeqNum == Route.SeqNum) AND
       [(RteMsg.Cost < Route.Metric) OR
       ((Route.Broken == TRUE) && LoopFree (RteMsg, Route))]}
		 

Suppose Route[RteMsg.Address] uses the same metric type as the incoming routing information, and the route entry contains Route.SeqNum, Route.Metric, and Route.Broken. Suppose the incoming routing information for Route.Address is RteMsg.SeqNum and RteMsg.Metric. Define RteMsg.Cost to be (RteMsg.Metric + Cost(L)), where L is the incoming link. The incoming routing information is classified as follows:

1. Stale::

RteMsg.SeqNum < Route.SeqNum :
If RteMsg.SeqNum < Route.SeqNum the incoming information is stale. Using stale routing information is not allowed, since that might result in routing loops. HandlingRtr MUST NOT update the route table entry using the routing information for RteMsg.Address.

2. Unsafe against loops::

(TRUE != LoopFree (RteMsg, Route)) :
If RteMsg is not Stale (as in (1) above), RteMsg.Cost is next considered to insure loop freedom. If (TRUE != LoopFree (RteMsg, Route)) (see Section 5.6), then the incoming RteMsg information is not guaranteed to prevent routing loops, and it MUST NOT be used to update any route table entry.

3. More costly::

(RteMsg.Cost >= Route.Metric) && (Route.Broken==FALSE)
When RteMsg.SeqNum is the same as in a valid route table entry, and LoopFree (RteMsg, Route) assures loop freedom, incoming information still does not offer any improvement over the existing route table information if RteMsg.Cost ≥ Route.Metric. Using such incoming routing information to update a route table entry is not recommended.

4. Offers improvement::

Incoming routing information that does not match any of the above criteria is better than existing routing table information and SHOULD be used to improve the route table. The following pseudo-code illustrates whether incoming routing information should be used to update an existing route table entry as described in Section 6.2.

• it is more recent, or
• it is not stale and is less costly, or
• it can safely repair a broken route.

6.2. Applying Route Updates To Route Table Entries

To apply the route update, a route table entry for RteMsg.Address is either found to already exist in the route table, or else a new route table entry for RteMsg.Address is created and inserted into the route table. The route table entry is populated with the following information:

• If RteMsg.PrefixLength exists, then Route.PrefixLength := RteMsg.PrefixLength. Otherwise, Route.PrefixLength := maximum length for address family (either 32 or 128).
• Route.SeqNum := RteMsg.SeqNum
• Route.NextHopAddress := IP.SourceAddress (i.e., an address of the node from which the RteMsg was received)
• Route.NextHopInterface is set to the interface on which RteMsg was received
• Route.Broken flag := FALSE
• If RteMsg.MetricType is included, then
  Route.MetricType := RteMsg.MetricType. Otherwise, Route.MetricType := DEFAULT_METRIC_TYPE.
• Route.Metric := (RteMsg.Metric + Cost(L)), where L is the incoming link.
• Route.LastUsed := Current_Time
• If RteMsg.VALIDITY_TIME is included, then
  Route.ExpirationTime := Current_Time + RteMsg.VALIDITY_TIME, otherwise, Route.ExpirationTime := Current_Time + (ACTIVE_INTERVAL + MAX_IDLETIME).

With these assignments to the route table entry, a route has been made available, and the route can be used to send any buffered data packets and subsequently to forward any incoming data packets for Route.Address. An updated route entry also fulfills any outstanding route discovery (RREQ) attempts for Route.Address.

6.3. Route Table Entry Timeouts

During normal operation, AODVv2 does not require any explicit timeouts to manage the lifetime of a route. However, the route table entry MUST be examined before using it to forward a packet, as discussed in Section 8.1. Any required expiry or deletion can occur at that time. Nevertheless, it is permissible to implement timers and timeouts to achieve the same effect.

At any time, the route table can be examined and route table entries can be expunged according to their current state at the time of examination, as follows. Section 13.3) then the precursor lists must also be expunged at the same time that the route itself is expunged.

• An Active route MUST NOT be expunged.
• An Idle route SHOULD NOT be expunged.
• An Expired route MAY be expunged (least recently used first).
• A route MUST be expunged if (Current_Time - Route.LastUsed) >= MAX_SEQNUM_LIFETIME.
• A route MUST be expunged if Current_Time >= Route.ExpirationTime

If precursor lists are maintained for the route (as described in

7. Routing Messages RREQ and RREP (RteMsgs)

AODVv2 message types RREQ and RREP are together known as Routing Messages (RteMsgs) and are used to discover a route between an Originating and Target Node, denoted here by OrigNode and TargNode. The constructed route is bidirectional, enabling packets to flow between OrigNode and TargNode. RREQ and RREP have similar information and function, but have some differences in their rules for handling. The main difference between the two messages is that RREQ messages are typically multicast to solicit a RREP, whereas RREP is typically unicast as a response to RREQ.

When an AODVv2 router needs to forward a data packet from a node (OrigNode) in its set of router clients, and it does not have a forwarding route toward the packet's IP destination address (TargNode), the AODVv2 router (RREQ_Gen) generates a RREQ (as described in Section 7.3) to discover a route toward TargNode. Subsequently RREQ_Gen awaits reception of an RREP message (see Section 7.4) or other route table update (see Section 6.2) to establish a route toward TargNode. Optionally, RREQ_Gen MAY specify that only the router serving TargNode is allowed to generate an RREP message, by including the DestOnly message TLV (see Section 7.3). The RREQ message contains routing information to enable RREQ recipients to route packets back to OrigNode, and the RREP message contains routing information enabling RREP recipients to route packets to TargNode.

7.1. Route Discovery Retries and Buffering

After issuing a RREQ, as described above RREQ_Gen awaits a RREP providing a bidirectional route toward Target Node. If the RREP is not received within RREQ_WAIT_TIME, RREQ_Gen may retry the Route Discovery by generating another RREQ. Route Discovery SHOULD be considered to have failed after DISCOVERY_ATTEMPTS_MAX and the corresponding wait time for a RREP response to the final RREQ. After the attempted Route Discovery has failed, RREQ_Gen MUST wait at least RREQ_HOLDDOWN_TIME before attempting another Route Discovery to the same destination.

To reduce congestion in a network, repeated attempts at route discovery for a particular Target Node SHOULD utilize a binary exponential backoff.

Data packets awaiting a route SHOULD be buffered by RREQ_Gen. This buffer SHOULD have a fixed limited size (BUFFER_SIZE_PACKETS or BUFFER_SIZE_BYTES). Determining which packets to discard first is a matter of policy at each AODVv2 router; in the absence of policy constraints, by default older data packets SHOULD be discarded first. Buffering of data packets can have both positive and negative effects (albeit usually positive). Nodes without sufficient memory available for buffering SHOULD be configured to disable buffering by configuring BUFFER_SIZE_PACKETS == 0 and BUFFER_SIZE_BYTES == 0. Doing so will affect the latency required for launching TCP applications to new destinations.

If a route discovery attempt has failed (i.e., DISCOVERY_ATTEMPTS_MAX attempts have been made without receiving a RREP) to find a route toward the Target Node, any data packets buffered for the corresponding Target Node MUST BE dropped and a Destination Unreachable ICMP message (Type 3) SHOULD be delivered to the source of the data packet. The code for the ICMP message is 1 (Host unreachable error). If RREQ_Gen is not the source (OrigNode), then the ICMP is sent over the interface from which OrigNode sent the packet to the AODVv2 router.

7.2. RteMsg Structure

RteMsgs have the following general format:

    +---------------------------------------------------------------+
    |                    RFC 5444 Message Header                    |
    +---------------------------------------------------------------+
    | MsgTLVs (e.g., Metric Type TLV {OrigNode,TargNode}(optional)) |
    +---------------------------------------------------------------+
    |                AddrBlk := {OrigNode,TargNode}                 |
    +---------------------------------------------------------------+
    |      AddrBlk.PrefixLength[OrigNode OR TargNode] (Optional)    |
    +---------------------------------------------------------------+
    |              OrigSeqNum_TLV AND/OR TargSeqNum_TLV             |
    +---------------------------------------------------------------+
    |                Metric TLV {OrigNode, TargNode}                |
    +---------------------------------------------------------------+

    +---------------------------------------------------------------+
    |     RFC 5444 Message Header <msg-hoplimit> <msg-hopcount>     |
    +---------------------------------------------------------------+
    |      UnreachableNode AddrBlk (Unreachable Node addresses)     |
    +---------------------------------------------------------------+
    |             UnreachableNode SeqNum AddrBlk TLV                |
    +---------------------------------------------------------------+

     /-------------------------\
    / +----------------+        \
   /  |  AODVv2 Router |         \
   |  |  191.0.2.2/32  |         |
   |  +----------------+         |            Routable 
   |                       +-----+--------+   Prefix
   |                       |   Internet   |  /191.0.2/24
   |                       | AODVv2 Router| /
   |                       |  191.0.2.1   |/      /---------------\         
   |                       | serving net  +------+    Internet     \  
   |                       |  191.0.2/24  |      \                 /  
   |                       +-----+--------+       \---------------/ 
   |         +----------------+  |
   |         |  AODVv2 Router |  |
   |         |  191.0.2.3/32  |  |
   \         +----------------+  /
    \                           /
     \-------------------------/

     0                   1                   2                   3
     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
    +-+-+-+-+-+-+-+-+
    | PV=0 |  PF=0  |
    +-+-+-+-+-+-+-+-+

     0                   1                   2                   3
     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
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    | msg-type=RREQ | MF=4  | MAL=3 |          msg-size=28          |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    | msg-hop-limit |      msg.tlvs-length=0        |   num-addr=2  |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |1|0|0|0|0| Rsv | head-length=3 | Head (bytes for Orig & Target):
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    :Head(Orig&Targ)|   Orig.Tail   |  Target.Tail  |addr.TLV.len=11:
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    :addr.TLV.len=11|type=OrigSeqNum|0|1|0|1|0|0|Rsv| Index-start=0 |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    | tlv-length=2  |     Orig.Node Sequence #      |  type=Metric  |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |0|1|0|1|0|0|Rsv| Index-start=0 | tlv-length=1  | OrigNodeHopCt |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

     0                   1                   2                   3
     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
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    | msg-type=RREP | MF=4  | MAL=3 |          msg-size=28          |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    | msg-hop-limit |      msg.tlvs-length=0        |   num-addr=2  |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |1|0|0|0|0| Rsv | head-length=3 | Head (bytes for Orig & Target):
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    :Head(Orig&Targ)|   Orig.Tail   |  Target.Tail  |addr.TLV.len=11:
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    :addr.TLV.len=11|type=TargSeqNum|0|1|0|1|0|0|Rsv| Index-start=1 |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    | tlv-length=2  |     Targ.Node Sequence #      |  type=Metric  |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |0|1|0|1|0|0|Rsv| Index-start=1 | tlv-length=1  | TargNodeHopCt |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

     0                   1                   2                   3
     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
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    | msg-type=RERR | MF=4  | MAL=3 |          msg-size=24          |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    | msg-hop-limit |      msg.tlvs-length=0        |   num-addr=2  |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |1|0|0|0|0| Rsv | head-length=3 | Head (for both destinations)  :
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    :Head (3rd byte)|  Tail(Dest_1) | Tail(Dest_2)  | addr.TLV.len=7:
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    :addr.TLV.len=7 |  type=SeqNum  |0|0|1|1|0|1|Rsv| tlv-length=4  |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |        Dest_1 Sequence #      |        Dest_2 Sequence #      |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

     0                   1                   2                   3
     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
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |msgtype=RREPAck| MF=0  | MAL=3 |          msg-size=4           |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+