[Docs] [txt|pdf] [Tracker] [WG] [Email] [Diff1] [Diff2] [Nits]

Versions: (draft-dearlove-manet-nhdp-optimization) 00 02 03 04 RFC 7466

Mobile Ad hoc Networking (MANET)                             C. Dearlove
Internet-Draft                                           BAE Systems ATC
Updates: RFC 6130, RFC 7181                                   T. Clausen
(if approved)                                   LIX, Ecole Polytechnique
Intended status: Standards Track                           July 21, 2014
Expires: January 22, 2015


  An Optimization for the MANET Neighborhood Discovery Protocol (NHDP)
                 draft-ietf-manet-nhdp-optimization-00

Abstract

   The link quality mechanism of the MANET Neighborhood Discovery
   Protocol (NHDP) enables "ignoring" some 1-hop neighbors if the
   measured link quality from that 1-hop neighbor is below an acceptable
   threshold, while still retaining the corresponding link information
   as acquired from HELLO message exchange.  This allows immediate
   reinstatement of the 1-hop neighbor if the link quality later
   improves sufficiently.

   NHDP also collects information about symmetric 2-hop neighbors.
   However it specifies that if a link from a symmetric 1-hop neighbor
   ceases being symmetric, including while "ignored" as described above,
   then corresponding symmetric 2-hop neighbors are removed.  This may
   lead to symmetric 2-hop neighborhood information being permanently
   removed (until further HELLO messages are received) if the link
   quality of a symmetric 1-hop neighbor drops below the acceptable
   threshold, even if only for a moment.

   This specification updates NHDP, and the Optimized Link State Routing
   Protocol version 2 (OLSRv2) to permit retaining, but ignoring,
   symmetric 2-hop information when the link quality from the
   corresponding 1-hop neighbor drops below the acceptable threshold.
   This allows immediate reinstatement of the symmetric 2-hop neighbor
   if the link quality later improves sufficiently, thus making the
   symmetric 2-hop neighborhood more "robust".

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/.




Dearlove & Clausen      Expires January 22, 2015                [Page 1]


Internet-Draft              NHDP Optimization                  July 2014


   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 22, 2015.

Copyright Notice

   Copyright (c) 2014 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.






























Dearlove & Clausen      Expires January 22, 2015                [Page 2]


Internet-Draft              NHDP Optimization                  July 2014


Table of Contents

   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  4
   2.  Terminology  . . . . . . . . . . . . . . . . . . . . . . . . .  5
   3.  Applicability Statement  . . . . . . . . . . . . . . . . . . .  5
   4.  Changes to NHDP  . . . . . . . . . . . . . . . . . . . . . . .  5
     4.1.  Interface Information Bases  . . . . . . . . . . . . . . .  5
     4.2.  HELLO Message Processing . . . . . . . . . . . . . . . . .  6
     4.3.  Information Base Changes . . . . . . . . . . . . . . . . .  6
     4.4.  Constraints  . . . . . . . . . . . . . . . . . . . . . . .  7
   5.  Changes to OLSRv2  . . . . . . . . . . . . . . . . . . . . . .  7
   6.  MIB Considerations . . . . . . . . . . . . . . . . . . . . . .  8
     6.1.  Updates to the State Group . . . . . . . . . . . . . . . .  9
     6.2.  Updates to the Notification Group  . . . . . . . . . . . . 10
   7.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 11
   8.  Security Considerations  . . . . . . . . . . . . . . . . . . . 11
   9.  Acknowledgments  . . . . . . . . . . . . . . . . . . . . . . . 11
   10. Normative References . . . . . . . . . . . . . . . . . . . . . 11
   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 12
































Dearlove & Clausen      Expires January 22, 2015                [Page 3]


Internet-Draft              NHDP Optimization                  July 2014


1.  Introduction

   The MANET Neighborhood Discovery Protocol (NHDP) [RFC6130], Section
   14, contains a link admission mechanism known as "link quality" that
   allows a router using that protocol to "take considerations other
   than message exchange into account for determining when a link is and
   is not a candidate for being considered as HEARD or SYMMETRIC".
   Specifically, [RFC6130] permits a router to disallow consideration of
   some of its 1-hop neighbors, for as long as the quality of the link
   from that 1-hop neighbor is below an acceptable link quality
   threshold.

   A feature of this mechanism is that while the link quality remains
   too low, the link information, established by the exchange of HELLO
   messages, is retained.  Thus if the link quality later goes above the
   required threshold (note that a hysteresis mechanism means that two
   thresholds are used) then the link is immediately established and
   will be immediately available for use.

   [RFC6130] collects not just 1-hop neighbor information, but also
   information about symmetric 2-hop neighbors.  However [RFC6130]
   specifies that if a 1-hop neighbor was, but no longer is, considered
   symmetric, then the corresponding 2-Hop Tuples that may have been
   recorded for that 2-hop neighbor, are to be removed, without a
   retention mechanism for a (possibly temporary) loss due to link
   quality.

   This means that if there is a short period in which link quality is
   too low, then when the link quality is reestablished, all 1-hop
   neighbor information is immediately available for use again.
   However, the corresponding symmetric 2-hop neighbor information has
   been removed, and is not available for use until restored by receipt
   of the next corresponding HELLO message.

   This specification describes how [RFC6130] can be modified to avoid
   this situation, by retaining (but not using) 2-hop information,
   similar to what is done with 1-hop information.  This modification is
   strictly optional, and routers that do and do not implement it can
   interwork entirely successfully (as they also can with different link
   quality specifications).  In addition, by a suitable interpretation
   (that ignored 2-Hop Tuples are not externally advertised), this
   change can be invisible to any other protocols using [RFC6130], in
   particular [RFC7181].  However the impact on [RFC7181] when 2-Hop
   Tuples are not so handled is also described, in particular owing to
   the existence of implementations of that protocol that are not
   modularly separated from [RFC6130].

   This specification therefore updates [RFC6130] and [RFC7181].



Dearlove & Clausen      Expires January 22, 2015                [Page 4]


Internet-Draft              NHDP Optimization                  July 2014


2.  Terminology

   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 the terminology of [RFC6130] and
   [RFC7181].


3.  Applicability Statement

   This specification updates [RFC6130].  The optimization presented in
   this specification is simply permissive, as it allows retaining
   information which otherwise would have been removed, but does not use
   that information except when it could have been used by [RFC6130].

   This can, in some cases, ensure that the symmetric 2-hop neighborhood
   is more robust against temporary link quality changes, and
   consequently yield a more stable network.  The only other consequence
   of this optimization is that state for some otherwise expired 2-Hop
   Tuples may be maintained for longer.

   This specification also updates [RFC7181].  This could be avoided by
   simply noting that this specification describes how the updates to
   [RFC6130] may be handled so as to be invisible to any other protocol
   using it.  However as it is known that some implementations of
   [RFC7181] are not independent of the implementation of [RFC6130] that
   they use, it is useful to indicate the direct impact on [RFC7181].

   A router that implements the optimization described in this
   specification will interoperate successfully with routers that
   implement [RFC6130], but do not implement this optimization.


4.  Changes to NHDP

   The following changes are made to [RFC6130] if using this
   specification.  Note that while this specification is OPTIONAL, if
   any of these changes are made then all of these changes MUST be made.

4.1.  Interface Information Bases

   The 2-Hop Set is modified by adding this additional element to each
   2-Hop Tuple:





Dearlove & Clausen      Expires January 22, 2015                [Page 5]


Internet-Draft              NHDP Optimization                  July 2014


      N2_lost is a boolean flag, which indicates the state of the
      corresponding Link Tuple.  If L_status = SYMMETRIC (and thus
      L_lost = false), then N2_lost = false.  If L_SYM_time has not
      expired, and L_lost = false (and hence L_status = LOST), then
      N2_lost = true.

   In all other cases, including other cases with L_status = LOST, there
   will be no such 2-Hop Tuples.

4.2.  HELLO Message Processing

   In Section 12.6 of [RFC6130] make the following changes:

   o  In point 2, change "L_status = SYMMETRIC" to "L_SYM_time not
      expired".

   o  When creating a 2-Hop Tuple, set N2_lost := L_lost.

4.3.  Information Base Changes

   In Section 13, replace the second bullet point by:

   o  A Link Tuple's L_status changes from SYMMETRIC, L_SYM_time
      expires, or the Link Tuple is removed.  In this case, the actions
      specified in Section 13.2 are performed.

   and replace the paragraph after the bullet points by:

   If a Link Tuple is removed, or if L_HEARD_time expires and either
   L_status changes from SYMMETRIC or L_SYM_time expires, then the
   actions specified in Section 13.2 MUST be performed before the
   actions specified in Section 13.3 are performed for that Link Tuple.

   In Section 13.2 of [RFC6130], add the following, before all other
   text:

   For each Link Tuple that has L_SYM_time not expired:

   1.  If L_SYM_time then expires, or if the Link Tuple is removed:

       1.  Remove each 2-Hop Tuple for the same MANET interface with:

           +  N2_neighbor_iface_addr_list contains one or more network
              addresses in L_neighbor_iface_addr_list.

   2.  If L_status then changes from SYMMETRIC to LOST because L_lost is
       set to true:




Dearlove & Clausen      Expires January 22, 2015                [Page 6]


Internet-Draft              NHDP Optimization                  July 2014


       1.  For each 2-Hop Tuple for the same MANET interface with:

           +  N2_neighbor_iface_addr_list contains one or more network
              addresses in L_neighbor_iface_addr_list;

           set N2_lost := true.

   Also in Section 13.2 of [RFC6130], remove point 2, renumbering point
   2 as point 1.

4.4.  Constraints

   In Appendix B, under "In each 2-Hop Tuple:" change the first bullet
   point to:

   o  There MUST be a Link Tuple associated with the same MANET
      interface with:

      *  L_neighbor_iface_addr_list = N2_neighbor_iface_addr_list; AND

      *  L_SYM_time not expired; AND

      *  L_lost = N2_lost.


5.  Changes to OLSRv2

   If the implementation of [RFC6130] conceals from any protocol using
   it the existence of all 2-Hop Tuples with N2_lost = true, then no
   changes are required to any protocol using [RFC6130], in particular
   no changes are required to [RFC7181].

   However if instead the implementation of [RFC6130] makes all 2-Hop
   Tuples visible, including those with N2_lost = true, then protocols
   using [RFC6130] MUST ignore such 2-Hop Tuples.

   For [RFC7181], given that this protocol uses 2-hop information for
   MPR Set and Routing Set calculation, but not includes that
   information in control traffic, this means that an implementation
   must be (i) behaving as if a 2-Hop Tuple only exists if
   N2_lost=false, and (ii) as if a change of N2_lost (from false to
   true, or true to false) corresponds to a 2-Hop Tuple appearing or
   being removed.  Specifically, this means behaving as if all of the
   following changes were to be made to [RFC7181]:

   o  In Section 17.6 of [RFC7181], point 1, replace the final two
      bullet points with:




Dearlove & Clausen      Expires January 22, 2015                [Page 7]


Internet-Draft              NHDP Optimization                  July 2014


      *  A 2-Hop Tuple with N2_out_metric != UNKNOWN_METRIC and N2_lost
         = false is added or removed, OR;

      *  A 2-Hop Tuple with N2_out_metric != UNKNOWN_METRIC has N2_lost
         changed, OR;

      *  The N2_out_metric of any 2-Hop Tuple with N2_lost = false
         changes, and either the flooding MPR selection process uses
         metric values (see Section 18.4) or the change is to or from
         UNKNOWN_METRIC.

   o  In Section 17.6 of [RFC7181], point 3, replace the final two
      bullet points with:

      *  A 2-Hop Tuple with N2_in_metric != UNKNOWN_METRIC and N2_lost =
         false is added or removed, OR;

      *  A 2-Hop Tuple with N2_in_metric != UNKNOWN_METRIC has N2_lost
         changed, OR;

      *  The N2_in_metric of any 2-Hop Tuple with N2_lost = false
         changes.

   o  In Section 17.7 of [RFC7181], in the fifth bullet point, add "and
      N2_lost = false" after "N2_out_metric != UNKNOWN_METRIC".

   o  In Section 18.4 of [RFC7181], in the third bullet point, add ",
      N2_lost = false" after "N2_out_metric != UNKNOWN_METRIC".

   o  In Section 18.5 of [RFC7181], in the third bullet point, add ",
      N2_lost = false" after "N2_in_metric != UNKNOWN_METRIC".

   o  In Section 19.1 of [RFC7181], in the final main bullet point
      (marked as "(OPTIONAL)"), add "and N2_lost = false" after
      "N2_out_metric != UNKNOWN_METRIC".

   o  In Appendix C.7 of [RFC7181], in point 1, add "and N2_lost =
      false" after "N2_out_metric != UNKNOWN_METRIC".


6.  MIB Considerations

   This update to [RFC6130] does not change the definition of a
   symmetric 2-hop neighbor.  It adds new information and states for
   each symmetric 2-hop neighbor, recorded in the Neighbor Information
   Base of a router and to be reflected in the appropriate tables of the
   corresponding NHDP-MIB module [RFC6779].




Dearlove & Clausen      Expires January 22, 2015                [Page 8]


Internet-Draft              NHDP Optimization                  July 2014


6.1.  Updates to the State Group

   This update introduces, to the state of each 2-Hop Tuple, the boolean
   flag N2_lost.  In order to reflect this, the updates in this section
   are to be made to the State Group (nhdpStateObjGrp) of the NHDP-MIB
   module [RFC6779].

   The DESCRIPTION of nhdpIib2HopSetEntry Object Type is to be updated,
   so as to read as follows:

      nhdpIib2HopSetEntry  OBJECT-TYPE
         SYNTAX      NhdpIib2HopSetEntry
         MAX-ACCESS  not-accessible
         STATUS      current
         DESCRIPTION
            "nhdpIib2HopSetTable consists of 2-Hop Tuples, each
             representing a single network address of a symmetric
             2-hop neighbor and a single MANET interface of a
             symmetric 1-hop neighbor.

             (N2_neighbor_iface_addr_list,
              N2_2hop_addr, N2_lost, N2_time).

             The entries include the 2-hop neighbor addresses, which
             act as the table index, and associated symmetric 1-hop
             neighbor address set, designated through nhdpDiscIfIndex,
             an expiration time, and a flag indicating if the 1-hop
             neighbor, through which this 2-hop neighbor is reachable,
             is considered lost due to link quality, or not.

             The nhdpIfIndex in the INDEX is the interface index of
             the local interface through which these 2-hop addresses
             are accessible.  The nhdpDiscIfIndex in the INDEX
             represents the 1-hop neighbor interface through which
             these 2-hop neighbor addresses are reachable."


         REFERENCE
            "RFC 6130 - Mobile Ad Hoc Network (MANET) Neighborhood
             Discovery Protocol (NHDP), Clausen, T., Dearlove,
             C., and J. Dean, April 2011"
         INDEX { nhdpIfIndex,
                 nhdpDiscIfIndex,
                 nhdpIib2HopSetIpAddressType,
                 nhdpIib2HopSetIpAddress
         }
      ::= { nhdpIib2HopSetTable 1 }




Dearlove & Clausen      Expires January 22, 2015                [Page 9]


Internet-Draft              NHDP Optimization                  July 2014


   The SEQUENCE of NhdpIib2HopSetEntry is to be updated, so as to read
   as follows:

    NhdpIib2HopSetEntry ::=
       SEQUENCE {
         nhdpIib2HopSetIpAddressType
            InetAddressType,
         nhdpIib2HopSetIpAddress
            InetAddress,
         nhdpIib2HopSetIpAddrPrefixLen
            InetAddressPrefixLength,
         nhdpIib2HopSet1HopIfIndex
            NeighborIfIndex,
         nhdpIib2HopSetN2Time
            TimeStamp,
         nhdpIib2HopSetN2Lost
            TruthValue
       }

   The nhdpIib2HopSetN2Lost OBJECT-TYPE is to be defined as follows:

    nhdpIib2HopSetN2Lost OBJECT-TYPE
       SYNTAX          TruthValue
       MAX-ACCESS      read-only
       STATUS          current
       DESCRIPTION
          "nhdpIib2HopSetN2Lost corresponds to N2_lost of NHDP and
           is a boolean flag, describing if for a 2-Hop Tuple, the
           corresponding Link Tuple currently is considered lost
           due to link quality."

       REFERENCE
          "draft-ietf-manet-nhdp-optimization-00"
       ::= {nhdpIib2HopSetEntry 5}


6.2.  Updates to the Notification Group

   This update introduces an additional state for each 2-Hop Tuple.
   Whereas [RFC6130] has two states for 2-Hop Tuples, 'up' (a 2-Hop
   Tuple exists) and 'down' (a 2-Hop Tuple expires), this update
   introduces a third state for a 2-Hop Tuple: it exists, but (due to
   the link quality of the link to the corresponding 1-Hop neighbor) is
   not currently considered.

   To reflect this, the SYNTAX and DESCRIPTION of nhdp2HopNbrState
   OBJECT-TYPE are to be updated, so as to read as follows:




Dearlove & Clausen      Expires January 22, 2015               [Page 10]


Internet-Draft              NHDP Optimization                  July 2014


     nhdp2HopNbrState  OBJECT-TYPE
        SYNTAX      INTEGER {
                       down(0),
                       up(1),
                       notconsidered(2)
                    }
        MAX-ACCESS  read-only
        STATUS      current
        DESCRIPTION
           "NHDP 2-hop neighbor states. In NHDP, it is not necessary
            to remove Protocol Tuples from Protocol Sets at the
            exact time indicated, only to behave as if the Protocol
            Tuples were removed at that time. This case is indicated
            here as 'down(0)'; otherwise, it is either 'up(1)', if
            N2_lost for the 2-Hop Tuple is equal to false, or
            'notconsidered(2)' otherwise."
        ::= { nhdpNotificationsStates 2 }



7.  IANA Considerations

   This document has no actions for IANA.

   [This section may be removed by the RFC Editor.]


8.  Security Considerations

   The update to [RFC6130] enables the retention and reuse of some
   information collected by that protocol, for only the duration that it
   could have been used in any case.  As such, this protocol introduces
   no new security considerations to an implementation of [RFC6130] or
   of any other protocol that uses it, such as [RFC7181].


9.  Acknowledgments

   The authors would like to thank Liz Cullen (BAE Systems) for first
   illustrating the issue addressed in this specification.


10.  Normative References

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119, March 1997.

   [RFC6130]  Clausen, T., Dean, J., and C. Dearlove, "Mobile Ad Hoc



Dearlove & Clausen      Expires January 22, 2015               [Page 11]


Internet-Draft              NHDP Optimization                  July 2014


              Network (MANET) Neighborhood Discovery Protocol (NHDP)",
              RFC 6130, April 2011.

   [RFC6779]  Herberg, U., Cole, R., and I. Chakeres, "Definition of
              Managed Objects for the Neighborhood Discovery Protocol",
              RFC 6779, October 2012.

   [RFC7181]  Clausen, T., Dearlove, C., Jacquet, P., and U. Herberg,
              "The Optimized Link State Routing Protocol version 2",
              RFC 7181, April 2014.


Authors' Addresses

   Christopher Dearlove
   BAE Systems Advanced Technology Centre
   West Hanningfield Road
   Great Baddow, Chelmsford
   United Kingdom

   Phone: +44 1245 242194
   Email: chris.dearlove@baesystems.com
   URI:   http://www.baesystems.com/


   Thomas Heide Clausen
   LIX, Ecole Polytechnique

   Phone: +33 6 6058 9349
   Email: T.Clausen@computer.org
   URI:   http://www.ThomasClausen.org/




















Dearlove & Clausen      Expires January 22, 2015               [Page 12]


Html markup produced by rfcmarkup 1.129b, available from https://tools.ietf.org/tools/rfcmarkup/