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 Abstract 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. Status of This Memo 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 Notice 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 Perkins Expires December 1, 2015 [Page 1] Internet-Draft Intermediate RREP May 2015 the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Table of Contents 1. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . 2 2. Terminology and Notation . . . . . . . . . . . . . . . . . . 3 3. Intermediate RREP Protocol Features . . . . . . . . . . . . . 5 4. Intermediate RREP Generation . . . . . . . . . . . . . . . . 6 5. Unsolicited RREP Generation . . . . . . . . . . . . . . . . . 7 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7 7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 8 8. Security Considerations . . . . . . . . . . . . . . . . . . . 8 9. Normative References . . . . . . . . . . . . . . . . . . . . 8 Appendix A. Changes since version ...-02 . . . . . . . . . . . . 8 Appendix B. Previous Changes . . . . . . . . . . . . . . . . . . 9 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 9 1. Overview 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). Perkins Expires December 1, 2015 [Page 2] Internet-Draft Intermediate RREP May 2015 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. 2. Terminology and Notation 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. AODVv2 Sequence Number (SeqNum) An AODVv2 Sequence Number is maintained by each AODVv2 router process. This sequence number is used by other AODVv2 routers to identify the temporal order of routing information generated and ensure loop-free routes. Intermediate Route Reply (iRREP) A RREP message that is originated by an Intermediate router. Intermediate Router An AODVv2 router along a route between RREQ_Gen and TargRtr that itself is not RREQ_Gen or TargRtr. iRREP_Gen An Intermediate Router that generates an iRREP message and a uRREP message. Perkins Expires December 1, 2015 [Page 3] Internet-Draft Intermediate RREP May 2015 OrigAddr An IP address of the Originating Node used as a data element within AODVv2 messages. Originating Node (OrigNode) The Originating Node is the node that launched the application requiring communication with the Target Address. RREQ Generating Router (RREQ_Gen) The AODVv2 router that provides network connectivity to the Originating Node (OrigNode). RREQ_Gen creates a AODVv2 control message (namely, RREQ) on behalf of OrigNode to discover a route to TargAddr. Router Client A node that requires the services of an AODVv2 router for route discovery and maintenance. An AODVv2 router is always its own client, so that its list of client IP addresses is never empty. Target Address (TargAddr) The Target Address is the address for which a route discovery is initiated by RREQ_Gen. Target Router (TargRtr) TargRtr is the AODVv2 router providing connectivity for TargAddr. Unsolicited Route Reply (uRREP) An unsolicited RREP message is a RREP originated by an AODVv2 router to a router which did not send a RREQ. In previous documents, uRREP was also sometimes called "Gratuitous RREP". This document uses the Data Elements and conventions found in Table 1 and Table 2. Perkins Expires December 1, 2015 [Page 4] Internet-Draft Intermediate RREP May 2015 +------------------+------------------------------------------------+ | 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 | +------------------+------------------------------------------------+ Table 1 +------------------------+------------------------------------------+ | 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 | +------------------------+------------------------------------------+ Table 2 3. Intermediate RREP Protocol Features The protocol features specified in this document are as follows: o DestOnly Message TLV o iRREP o uRREP 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. Perkins Expires December 1, 2015 [Page 5] Internet-Draft Intermediate RREP May 2015 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. o RREQ does not contain the DestOnly Message TLV. o iRREP_Gen has a valid route with the same MatricType for TargAddr (namely Route[TargAddr]). o Route[TargAddr].SeqNum >= RREQ.TargSeqNum 4. Intermediate RREP Generation The data elements for the iRREP are assigned as follows. o IP.DestinationAddr := Route[OrigAddr].NextHop o AddressList := {OrigAddr, TargAddr} o TargSeqNum := Route[TargAddr].Seqnum o Include the MetricType data element if offering a route for a non- default metric type, and set the type accordingly. o MetricList := {null, Route[TargAddr].Metric} o PrefixLengthList contains the length of the prefix for TargAddr, if TargAddr resides on a Client Network with a prefix length shorter than the number of bits of the address family for TargAddr. o If Route[TargAddr].Timed is TRUE, include the ValidityTimeList and set ValidityTimeList := {Route[TargAddr].ExpirationTime - Current_Time, null} Perkins Expires December 1, 2015 [Page 6] Internet-Draft Intermediate RREP May 2015 If TargAddr has an associated subnet prefix in the route table, insert its prefix in the PrefixLengthList; otherwise, omit the PrefixLengthList. 5. Unsolicited RREP Generation 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. o IP.DestinationAddr := Route[TargAddr].NextHop o AddressList := {uOrigAddr, uTargAddr} o TargSeqNum := Route[uTargAddr].Seqnum o Include the MetricType data element if offering a route for a non- default metric type, and set the type accordingly. o MetricList := {null, Route[uTargAddr].Metric} o PrefixLengthList contains the length of the prefix for uTargAddr, if uTargAddr resides on a Client Network with a prefix length shorter than the number of bits of the address family for uTargAddr. o If Route[OrigAddr].Timed is TRUE, include the ValidityTimeList and set ValidityTimeList := {Route[OrigAddr].ExpirationTime - Current_Time, null}. 6. IANA Considerations This section specifies one new RFC 5444 message-tlv type. Perkins Expires December 1, 2015 [Page 7] Internet-Draft Intermediate RREP May 2015 +------------------------------------+-------+----------+-----------+ | Name of RFC 5444 Message TLV | Type | Length | Cross | | | | (octets) | Reference | +------------------------------------+-------+----------+-----------+ | Destination RREP Only (DestOnly) | TBD | 0 | Section 3 | +------------------------------------+-------+----------+-----------+ Table 3: RFC 5444 Message TLV Types 7. Acknowledgments Victoria Mercieca 8. Security Considerations 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]. 9. Normative References [I-D.ietf-manet-aodvv2] Perkins, C., Ratliff, S., Dowdell, J., Steenbrink, L., and V. Mercieca, "Ad Hoc On-demand Distance Vector (AODVv2) Routing", draft-ietf-manet-aodvv2-09 (work in progress), 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. Appendix A. Changes since version ...-02 o Text rewritten to conform to new terminology in [I-D.ietf-manet-aodvv2]. o Updated to handle nondefault metrics. o Replace SeqNum by OrigSeqNum and TargSeqNum as needed. Perkins Expires December 1, 2015 [Page 8] Internet-Draft Intermediate RREP May 2015 o Minor editorial improvements. Appendix B. Previous Changes o Many changes for RFC 5444 compliance. o Added unsolicitied RREP (uRREP). o Added notation from [I-D.ietf-manet-aodvv2]. o Rewrote many paragraphs to conform to above changes. o Added section about "prefix-length"=0. o Added this "Changes" section. Author's Address Charles E. Perkins Futurewei Inc. 2300 Central Expressway Santa Clara, CA 95053 USA Phone: +1-408-330-4586 Email: charliep@computer.org Perkins Expires December 1, 2015 [Page 9]