Intermediate RREP for dynamic MANET On-demand (AODVv2) Routing
draft-perkins-irrep-03

Versions: 00 01 02 03                                                   
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]