| Mobile Ad hoc Networks Working Group | C. Perkins |
| Internet-Draft | Futurewei |
| Intended status: Standards Track | May 30, 2015 |
| Expires: December 1, 2015 |
Intermediate RREP for dynamic MANET On-demand (AODVv2) Routing
draft-perkins-irrep-03
The Ad Hoc On-demand Distance Vector (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 an extension to AODVv2 (possibly useful with other reactive routing protocols) enabling intermediate nodes to shorten route discovery times.
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 December 1, 2015.
Copyright (c) 2015 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.
The Ad Hoc On-demand Distance Vector (AODVv2) routing protocol [I-D.ietf-manet-aodvv2] enables on-demand, multihop unicast routing among participating AODVv2 routers. The basic operations of the AODVv2 protocol are route discovery and route maintenance. Route discovery is performed by an AODVv2 router when one of its clients (called OrigNode) attempts to transmit a packet towards a destination for which the router does not have a route.
OrigNode's AODVv2 router (denoted RREQ_Gen) initiates route discovery by multicasting a Route Request (RREQ). During the hop-by-hop multicast operation, each intermediate AODVv2 router records a route to the IP address of OrigNode (i.e., OrigAddr). If an intermediate router has a route to the destination requested (denoted TargAddr) in the RREQ, it could transmit an RREP with that routing information to RREQ_Gen. Such an RREP message is called an "Intermediate RREP" (or, "iRREP"). The intermediate router (denoted iRREP_Gen) also generates another RREP message, which is called an "Unsolicited RREP" (or, "uRREP"), to TargRtr, the router TargAddr. The uRREP supplies TargRtr and other intermediate routers with a route towards OrigAddr. When RREQ_Gen receives the iRREP, and TargRtr receives the uRREP, a bi-directional route is established between RREQ_Gen and TargRtr.
In this document, RREQ always refers to the incoming RREQ message received by iRREP_Gen. RREQ_Gen, OrigAddr, TargRtr, and TargAddr always refer to the addresses and routers as defined in [I-D.ietf-manet-aodvv2]; they are named from the context of RREQ_Gen (the AODVv2 router originating the RREQ message).
Intermediate RREP can be particularly effective in conjunction with the use of "expanding rings multicast", which is specified as an optional feature in [I-D.ietf-manet-aodvv2]. Together, these two features enable a simple "route repair" mechanism. When a route breaks close to the origin, RREQ_Gen MAY limit the flooding of a RREQ using expanding rings multicast. Then, nearby AODVv2 routers could in many situations generate iRREP to supply a new route to the desired destination.
When an AODVv2 router receives an RREQ, it first uses the information in the RREQ to update any relevant route table entries. Then, if the router is able to generate an iRREP to satisfy the RREQ, it uses the up-to-date information in its route table to assign proper values to the data elements of the iRREP and uRREP.
Other Intermediate routers receiving the iRREP and uRREP messages use the same procedures to process those messages as specified in [I-D.ietf-manet-aodvv2]. In other words, when iRREP_Gen sends iRREP and uRREP messages, other AODVv2 routers along the route receive and regenerate those messages using the same rules as for any other RREP message.
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119]. Additionally, this document uses some terminology and notation from [RFC5444] and [I-D.ietf-manet-aodvv2], some of which is duplicated here for convenience.
This document uses the Data Elements and conventions found in Table 1 and Table 2.
| Data Elements | Meaning |
|---|---|
| MetricType | The metric type for OrigMetric and TargMetric |
| AddressList | A list of IP addresses |
| OrigAddr | IP address of the Originating Node |
| TargAddr | IP address of the Target Node |
| PrefixLengthList | Routing prefixes associated with addresses in AddressList |
| OrigSeqNum | Originating Node Sequence Number |
| TargSeqNum | Target Node Sequence Number |
| OrigMetric | Metric value for route to OrigAddr |
| TargMetric | Metric value for route to TargAddr |
| ValidityTime | Validity Time values for routes |
| Notation | Meaning |
|---|---|
| Route[Address] | A route table entry towards Address |
| Route[Address].{field} | A field in such a route table entry |
| -- | -- |
| iRREP_Gen | AODVv2 Router generating Intermediate RREP |
| uOrigAddr | Used as OrigAddr in the uRREP message |
| uTargAddr | Used as TargAddr in the uRREP message |
The protocol features specified in this document are as follows:
RREQ_Gen MAY specify that only the router serving TargAddr is allowed to generate an RREP message, by including the DestOnly data element (see Section 6) as part of the message. This also assures that RREP_Gen increments its sequence number. Otherwise Intermediate AODVv2 routers MAY respond to the RREQ if they have a valid route to TargAddr, as detailed in this document.
If an intermediate AODVv2 router (iRREP_Gen) has a Route that can satisfy an incoming RREQ, it MAY respond with an Intermediate RREP (iRREP). As usual with any incoming RREQ, iRREP_Gen first updates its route table using the information contained in the RREQ. For example, a route to OrigAddr may be created or updated. After the incoming route update information is applied, iRREP_Gen has valid routes to both OrigAddr and TargAddr (Route[OrigAddr] and Route[TargAddr] respectively).
iRREP_Gen SHOULD also send a RREP to TargRtr, so that TargRtr can obtain a route towards OrigAddr. This RREP sent towards the TargAddr is known as an "Unsolicited RREP" (uRREP). Each AODVv2 router between iRREP_Gen and TargRtr that receives the uRREP, uses the uRREP information to update their route table entry for OrigAddr.
The following conditions must be satisfied before iRREP_Gen can generate iRREP and uRREP.
The data elements for the iRREP are assigned as follows.
If TargAddr has an associated subnet prefix in the route table, insert its prefix in the PrefixLengthList; otherwise, omit the PrefixLengthList.
The uRREP is intended to fulfill the function of an RREP as if in response to a (fictional) RREQ message sent by TargRtr for discovering a route to OrigAddr. The sense of the addresses in the uRREP has to be reversed. To reduce confusion which might result from this reversal, the OrigAddr data element of the uRREP is denoted "uOrigAddr"; uOrigAddr has the same value as the TargAddr of the incoming RREQ. Similarly, the TargAddr data element is denoted "uTargAddr", and it has the same value as the OrigAddr of the incoming RREQ.
The data elements of the uRREP are assigned as follows.
This section specifies one new RFC 5444 message-tlv type.
| Name of RFC 5444 Message TLV | Type | Length (octets) | Cross Reference |
|---|---|---|---|
| Destination RREP Only (DestOnly) | TBD | 0 | Section 3 |
Victoria Mercieca
Since the RREP message is used in the same way as in AODVv2, no new security vulnerabilities are introduced. The effect of an intermediate node erroneously inserting a DestOnly TLV is minimal, and would simply prevent other routers from offering the benefit of generating Intermediate RREP. Security associations SHOULD be maintained in the same way as specified in AODVv2 [I-D.ietf-manet-aodvv2]. Likewise, RREP messages generated according to the specification in this document SHOULD be protected in the same way as specified in AODVv2 [I-D.ietf-manet-aodvv2].
| [I-D.ietf-manet-aodvv2] | Perkins, C., Ratliff, S., Dowdell, J., Steenbrink, L. and V. Mercieca, "Ad Hoc On-demand Distance Vector (AODVv2) Routing", Internet-Draft draft-ietf-manet-aodvv2-09, May 2015. |
| [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. |