| Mobile Ad hoc Networks Working Group | C.E. Perkins |
| Internet-Draft | Futurewei |
| Intended status: Standards Track | July 10, 2012 |
| Expires: January 09, 2013 |
Intermediate RREP for dynamic MANET On-demand (AODVv2) Routing
draft-perkins-manet-precursor-00
The Dynamic MANET On-demand (AODVv2) routing protocol is intended for use by mobile routers in wireless, multihop networks. AODVv2 determines unicast routes among AODVv2 routers within the network in an on-demand fashion, offering on-demand convergence in dynamic topologies. This document specifies a simple modification to AODVv2 (and possibly other reactive routing protocols) enabling faster notifications to known sources of traffic upon determination that a route for such traffic's destination has become invalid.
This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress."
This Internet-Draft will expire on January 09, 2013.
Copyright (c) 2012 IETF Trust and the persons identified as the document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
If an AODVv2 router, while attempting to forward a packet to a particular destination, determines that the next hop (one of its neighbors) is no longer reachable, AODVv2 specifies that the router notify the source of that packet that the route to the destination has become invalid. In the existing specification, the notification to the source is a unicast RERR message.
However, in many cases there will be several sources of of traffic for that particular destination. In fact, the broken link for the next hop in question may be a path component of numerous other routes for other destinations, and in that case the node detecting the broken link must invalidate multiple routes, one for each of the newly unreachable destinations. Each route that uses the newly broken link is no longer valid. For each such route, every node along the way from the source using that route, to the node detecting the broken link, is known as a "precursor" for the broken next hop. All the precursors for a particular next hop should be notified about the change in status of their route to a destination downstream from the broken next hop. This can be done in several ways.
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119]. Additionally, this document uses some terminology from [RFC5444] and [I-D.ietf-manet-dymo], duplicated here for convenience.
During normal operation, each node wishing to enable the improved notification for precursors of any links to its next hop neighbors has to keep track of the precursors. This is done by maintaining a precursor table and updating the table whenever the node initiates or relays a RREP message back to a node originating a RREQ message. When the node transmits the RREP message, it is implicitly agreeing to forward traffic from the RREQ originator towards the RREP originator (i.e., along the next hop link to the neighbor from which the RREP was received). The "other" next hop, which is the neighbor along the way towards the originator of the RREQ message, is then the next precursor for the route towards the destination requested by the RREQ.
Each such precursor should then be recorded as a precursor for a route along the next hop. The same next hop may be in service for routes to multiple destinations, but for precursor list management it is only important to keep track of precursors for a particular next hop; the exact destination does not matter, only the particular next hop towards the destination(s).
When a node observes that one of its neighbors is no longer reachable, the node first checks to see whether the link to that neighbor is a next hop for any more distant destination in its route table. If not, then the node simply updates any relevant neighorhood information and takes no further action.
Otherwise, for all destinations no longer reachable because of the changed status of the next hop, the reachable, the node first checks to see whether the link to that neighbor is a next hop for any more distant destination in its route table. If not, then the node simply updates any relevant neighorhood information and takes no further action.
For each precursor of the next hop, the node MAY notify the the changed status of the next hop, the reachable, the node first checks to see whether the link to that neighbor is a next hop for any more distant destination in its route table. If not, then the node simply updates any relevant neighorhood information and takes no further action.
Otherwise, for all destinations no longer reachable because of the changed status of the next hop, the reachable, the node first checks to see whether the link to that neighbor is a next hop for any more distant destination in its route table. If not, then the node simply updates any relevant neighorhood information and takes no further action.
For each precursor of the next hop, the node MAY notify the precursor in one of three ways:
Each precursor then MAY execute the same procedure until all affected traffic sources have received the RERR route maintenance information.
When a precursor receives a unicast RERR, the precursor MUST further unicast the RERR message towards the affected traffic source. If a precursor receives a broadcast or multicast RERR, the precursor MAY further retransmit the RERR towards the traffic source.
TBD
The ability of to use broadcast instead of unicast can in some cases cause additional network traffic. This would happen when many traffic sources were never going to re-use a particular route, and yet were receiving essentially useless notifications about that route. It remains to be determined whether such scenarios, where route tables have significant numbers of useless routes, would be encountered in practice.
| [RFC2119] | Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. |
| [RFC5444] | Clausen, T., Dearlove, C., Dean, J. and C. Adjih, "Generalized Mobile Ad Hoc Network (MANET) Packet/Message Format", RFC 5444, February 2009. |
| [RFC3561] | Perkins, C., Belding-Royer, E. and S. Das, "Ad hoc On-Demand Distance Vector (AODV) Routing", RFC 3561, July 2003. |
| [I-D.ietf-manet-dymo] | Chakeres, I and C Perkins, "Dynamic MANET On-demand (DYMO) Routing", Internet-Draft draft-ietf-manet-dymo-21, July 2010. |