Skip to main content

Neighbor Management Policy for 6LoWPAN
draft-ietf-lwig-nbr-mgmt-policy-01

The information below is for an old version of the document.
Document Type
This is an older version of an Internet-Draft whose latest revision state is "Expired".
Authors Rahul Jadhav , Rabi Narayan Sahoo , Simon Duquennoy , Joakim Eriksson
Last updated 2018-02-22 (Latest revision 2017-08-28)
Replaces draft-jadhav-lwig-nbr-mgmt-policy
RFC stream Internet Engineering Task Force (IETF)
Formats
Additional resources Mailing list discussion
Stream WG state WG Document
Document shepherd (None)
IESG IESG state I-D Exists
Consensus boilerplate Unknown
Telechat date (None)
Responsible AD (None)
Send notices to (None)
draft-ietf-lwig-nbr-mgmt-policy-01
LWIG                                                      R. Jadhav, Ed.
Internet-Draft                                                  R. Sahoo
Intended status: Informational                                    Huawei
Expires: August 26, 2018                                    S. Duquennoy
                                                                   Inria
                                                             J. Eriksson
                                                          Yanzi Networks
                                                       February 22, 2018

                 Neighbor Management Policy for 6LoWPAN
                   draft-ietf-lwig-nbr-mgmt-policy-01

Abstract

   This document describes the problems associated with neighbor cache
   management in constrained multihop networks and a sample neighbor
   management policy to deal with it.

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 https://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 August 26, 2018.

Copyright Notice

   Copyright (c) 2018 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
   (https://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

Jadhav, et al.           Expires August 26, 2018                [Page 1]
Internet-Draft   Neighbor Management Policy for 6LoWPAN    February 2018

   the Trust Legal Provisions and are provided without warranty as
   described in the Simplified BSD License.

Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   2
     1.1.  Requirements Language and Terminology . . . . . . . . . .   4
   2.  Neighbor Management . . . . . . . . . . . . . . . . . . . . .   5
     2.1.  Significance of Neighbor management policy  . . . . . . .   5
     2.2.  Trivial neighbor management policies  . . . . . . . . . .   6
     2.3.  Lifecycle of a NCE  . . . . . . . . . . . . . . . . . . .   7
       2.3.1.  NCE Insertion . . . . . . . . . . . . . . . . . . . .   7
       2.3.2.  NCE Deletion  . . . . . . . . . . . . . . . . . . . .  10
       2.3.3.  NCE Eviction  . . . . . . . . . . . . . . . . . . . .  11
         2.3.3.1.  Eviction for directly connected routing entries .  11
       2.3.4.  NCE Reinforcement . . . . . . . . . . . . . . . . . .  12
     2.4.  Requirements of a good neighbor management policy . . . .  12
     2.5.  Approaches to neighbor management policy  . . . . . . . .  13
       2.5.1.  Reactive Approach . . . . . . . . . . . . . . . . . .  13
       2.5.2.  Proactive Approach  . . . . . . . . . . . . . . . . .  13
   3.  Reservation based Neighbor Management Policy  . . . . . . . .  14
     3.1.  Limitations of such a policy  . . . . . . . . . . . . . .  15
   4.  Acknowledgements  . . . . . . . . . . . . . . . . . . . . . .  16
   5.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .  16
   6.  Security Considerations . . . . . . . . . . . . . . . . . . .  16
   7.  References  . . . . . . . . . . . . . . . . . . . . . . . . .  16
     7.1.  Normative References  . . . . . . . . . . . . . . . . . .  16
     7.2.  Informative References  . . . . . . . . . . . . . . . . .  17
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  17

1.  Introduction

   In a wireless multihop network, the node densities (maximum number of
   devices connected on a single hop) may vary significantly depending
   upon deployments/scenarios.  While there is some policy control
   possible with regards to the network size in terms of maximum number
   of devices connected, it is especially difficult to set a figure on
   what will be the maximum node density given a deployment.  For e.g.
   A network can put an upper limit on max 1000 devices but it is
   impossible to state what the node density will be in this 1000 node
   network.

   A neighbor cache is used for populating neighboring one-hop connected
   nodes information such as MAC address, link local IP address and
   other reachability state information.  Node density has direct
   implications on the neighbor cache and in constrained network
   scenario the size of the neighbor cache will be limited.  Thus there
   are chances that a node may not be able to fit all the neighboring

Jadhav, et al.           Expires August 26, 2018                [Page 2]
Internet-Draft   Neighbor Management Policy for 6LoWPAN    February 2018

   nodes in its cache in which case it has to prioritize entries and
   thus needs a neighbor management policy.

   This draft presents problems related to neighbor management policies
   by considering a security-enabled multi-hop 6lo network.  This
   document considers RPL [RFC6550] as a routing protocol and PANA (EAP-
   PANA) [RFC5191] as a network access protocol.  For RPL, both the
   storing and non-storing mode of operations are considered.  We also
   provide a sample neighbor management policy which can be used in such
   networks and its limitations.  The aim of such a policy is to retain
   set of neighbor cache entries with high quality links such that
   routing adjacencies are stablized.

   The problem statement and the proposed solution described is also
   relevant to other multihop constrained scenarios such as 6TiSCH
   [I-D.ietf-6tisch-architecture].  [I-D.ietf-6tisch-minimal-security]
   talks about a pledge (new joinee) node authenticating via a Join
   Proxy.  The considerations mentioned in this document are applicable
   for such networks as well.

Jadhav, et al.           Expires August 26, 2018                [Page 3]
Internet-Draft   Neighbor Management Policy for 6LoWPAN    February 2018

                                          +--------+
                                          | PAA/   |
                                   +------| Auth   |
                                   |      | Server |
                                   |      +--------+
                      +------------|-------------+
                      |            |             |
                      |          (BR)            |
                      |          / \             |
                      |         /   \            |
                      |        /     \           |
                      |      (N1)   (N2)         |
                      |      / :     / \         |
                      |     /   :   /   \        |
                      |    /     : /     \       |
                      |  (N8)    (N3)   (N4)     |
                      |    :     / \     :       |
                      |     :   /   \   :        |
                      |      : /     \ :         |
                      |      (N5)   (New)        |
                      |      / \                 |
                      |     /   \                |
                      |    /     \               |
                      |  (N6)   (N7)             |
                      |                          |
                      |        6Lo Network       |
                      +--------------------------+

                         Figure 1: Sample Topology

1.1.  Requirements Language and Terminology

   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 RFC 2119 [RFC2119].

   PaC (PANA Client): New joining node which is yet to be authenticated.

   PRE (PANA Relay Element): An already authenticated and network joined
   node which is willing to act as a relay element for PaCs to complete
   their authentication procedure on multi-hop networks.  [RFC6345]
   describes the details of PRE.

   PAA (PANA Auth Agent): Auth server which hosts the credentials
   database.  PaC will handshake with PAA to complete authentication
   procedure.

Jadhav, et al.           Expires August 26, 2018                [Page 4]
Internet-Draft   Neighbor Management Policy for 6LoWPAN    February 2018

   Routing Child: A downstream node who is part of the routing table of
   the parent.  For e.g. in the sample topology above N5 is the directly
   connected routing child for N3.  N6 and N7 are also part of N3
   routing table, they are routing child nodes but not directly
   connected.  For N6 and N7 the document might alternatively use a term
   grand-child.

   Routing Parent: In Figure 1, N1 and N2 are possible routing parents
   for N3.

   Neighbor Cache Entry (NCE): A neighbor entry managed on behalf of
   directly connected peer.

   This document also uses terminology described in [RFC6550] and
   [RFC6775].

2.  Neighbor Management

2.1.  Significance of Neighbor management policy

   Multihop mesh networks present unique challenges to neighbor
   management especially with resource constrained nodes.  In cases
   where the node density is higher that the neighbor cache size, the
   entries have to be prioritized.  [Woo_et_al] and [Dawans_et_al] talk
   about prioritization of neighbor entries by using link quality
   estimation techniques.  But prioritization alone may not necessarily
   be optimal in all cases.  The reason or function why neighbor entry
   was added also needs to be taken in consideration.  For example,
   evicting a routing direct child might have a ripple effect in turn
   impacting all the sub-childs as well.

   In case of key management protocols deployed above MAC layer in
   multihop network, the neighbor management kicks in early even before
   the routing adjacencies are established.  Since a new joining node
   needs to discover/attach to a relay element for completing its
   authentication procedure, the neighbor cache entries have to be
   appropriately populated both on a PaC and on the PRE.  If a neighbor
   entry whose authentication is in progress is evicted, it will
   negatively impact the authentication procedure.

   Another important consideration is that with increased node density,
   the prioritization based on link estimation parameters might not help
   since there might be more well connected peers.  In dense deployments
   the number of directly attached neighbors with good quality links
   might still be higher than the max entries in neighbor cache size.

Jadhav, et al.           Expires August 26, 2018                [Page 5]
Internet-Draft   Neighbor Management Policy for 6LoWPAN    February 2018

2.2.  Trivial neighbor management policies

   This section investigates policies which are used by most of the
   current operating systems for constrained nodes.  While such policies
   are trivial to implement they may not be able to deal with the
   constrained network scenario.  Note that such policies can still be
   used if it is known apriori that the neighbor cache can hold entries
   for maximum node density.

   a.  First Come First Serve (FCFS) policy

   b.  Least Recently Used (LRU) policy

   The primary distinction between these policies is how it treats a new
   entry when the neighbor cache is full.  In case of FCFS policy, the
   new entry is simply rejected while with LRU, the new entry replaces
   the least recently used entry.

   RPL works by initiating a downstream multicast DIO to establish
   upstream network path.  Subsequently DAO messages might be sent by
   the nodes to establish downstream paths to the nodes.  Thus the
   network is flooded with multicast DIO messages initially and
   similarly there are chances that the same node is ended up been
   selected as a preferred parent by most of the child nodes and thus
   receives a DAO message from all these child nodes.  Note that once a
   node establishes a parent entry or a routing entry on behalf of a
   directly connected node then it has to also provision a neighbor
   cache entry for it for subsequent unicast traffic.

   In case of FCFS policy, a node might end up hosting all the neighbor
   entries based on DIO or DAO messages.  Once the cache is full all the
   subsequent attempts to add an NCE will fail.

   In case of LRU policy, a node might end up churning lot of neighbor
   entries because once the cache gets full and there is a request for
   new entry, it would result in evicting the least recently used (but
   active) entry.  If at later point of time, there is a traffic for the
   evicted entry then the old entry has to be reinstated using IPv6 NDP
   procedure.  This would mean reinstating the entry by evicting another
   least recently used entry.  If the node density is very high, then
   this churn would be substantially high to extent that it would
   disrupt any routing adjacencies to be established in the network in a
   stable way.

Jadhav, et al.           Expires August 26, 2018                [Page 6]
Internet-Draft   Neighbor Management Policy for 6LoWPAN    February 2018

2.3.  Lifecycle of a NCE

2.3.1.  NCE Insertion

   IPv6 NDP [RFC6775] defines signaling involved in resolving the IPv6
   addresses to its corresponding MAC addresses which gets populated in
   the neighbor cache.  In case of constrained network, it is desired
   that such control traffic is minimized and thus the neighbor cache
   entries are populated as part of existing messaging.  One example
   would be when the node receives a DAO message from its immediate
   child node, it not only makes an addition to the routing table but
   also creates a neighbor cache entry for the node.  Thus it eliminates
   need for additional IPv6 NDP NS/NA messaging involved to resolve MAC
   address.  Similar hueristic is used to add neighbor entries in other
   cases as well.  Section 10.3.2 of [RFC6775] describes update and
   addition of such NCEs based on roting information packets.

   Following are the possible signaling scenarios in which case a
   neighbor entry may get added.

   Node Joining procedure: A new joinee node discovers a relay element
   to initiate its auth procedure.  At the end of the discovery phase
   the new joinee node would have known the link local IP address of the
   relay element.  The joinee node will send an unsecured-NS to the
   relay element to solicit its NA.  The PRE may send a NA with the
   suitable status code as defined in section 6.5.3 of [RFC6775].

Jadhav, et al.           Expires August 26, 2018                [Page 7]
Internet-Draft   Neighbor Management Policy for 6LoWPAN    February 2018

                                             RPL
                   New           PRE         Parent        PAA
                    |             |            |            |
                    |  PRE Disc   |            |            |
                    |<----------->|            |            |
                    |             |            |            |
                    |   UNSEC-NS  |            |            |
                    |------------>|            |            |
                    |             |            |            |
                    |   addNCE(new,reason=PANA)|            |
                    |             |            |            |
                    | UNSEC-NA(status)         |            |
                    |<------------|            |            |
                    |             |            |            |
            addNCE(PRE,reason=PANA)            |            |
                    |             |            |            |
                    |    PCI      |            |            |
                    |------------>|            |            |
                    |             |            |            |
                    |             |  AUTHPROC  |            |
                    |<----------->|<----------------------->|
                    |             |            |            |

     Figure 2: NCE creation between PaC and PRE during relay discovery
                                  process

   Relay element does not hold any state information on behalf of the
   new joinee node except for its neighbor cache entry.  Thus in the
   Figure 1 the new joinee node may select node N3 as its PRE, in which
   case N3 has to add a neighbor entry on behalf of the new joinee node.

   Post authentication the node enters into network discovery phase.
   The node selects one or more of its neighboring peer as its preferred
   parent based on the DIO received from these peers.  Note that the
   node's selected relay element and its preferred parent may not be
   same.  The preferred parent serves as a default router node to which
   all its upstream traffic is directed.  Thus an NCE on behalf of
   preferred parent needs to be added.  In Figure 1 node N5 selects N3
   as its preferred parent.  N5 needs to add neighbor entry on behalf of
   N3 which is its directly connected RPL preferred parent.

   In case of RPL storing MOP (mode of operation), the node may send a
   DAO message containing its reachability information to its preferred
   parent.  The parent node in turn may pass this information upstream
   to its parent by generating a DAO retaining the child node's
   reachability information, establishing a downstream routing path
   towards the node who originated the DAO.  The preferred parent has to
   maintain a neighbor entry on behalf of the directly connected child

Jadhav, et al.           Expires August 26, 2018                [Page 8]
Internet-Draft   Neighbor Management Policy for 6LoWPAN    February 2018

   node.  For example, in the Figure 1, node N3 needs to maintain a
   neighbor entry on behalf of N5 which is its directly connected child
   node.  Nodes N6 and N7 are grand-child nodes for node N3 for whom no
   neighbor entry is required.

   As mentioned in Section 10.3.2 of [RFC6775], the NCEs on parent and
   child can be added directly as a result of RPL DIO/DAO signalling
   without any explicit NS/NA messaging.

                                             RPL
                   New           PRE         Parent        PAA
                    |             |            |            |
                    |             |  AuthProc  |            |
                    |<----------->|<----------------------->|
                    |             |            |            |
                    |             |  RPL-DIO   |            |
                    |<-------------------------|            |
                    |             |            |            |
            addNCE(parent,reason=PARENT)       |            |
                    |             |            |            |
                    |             |  RPL-DAO   |            |
                    |------------------------->|            |
                    |             |            |            |
                    |             |   addNCE(new,reason=CHILD)
                    |             |            |            |

           Figure 3: NCE creation call Flow for RPL storing MOP

   In case of non-storing MOP, the parent node needs to know the global
   IPv6 address of the immediate child nodes.  This is needed since the
   source routing header carries the global addresses and thus the NCE
   of the child node should contain the global address.  Secondly, the
   RPL DAO is addressed directly to the root node in case of non-storing
   mode.  Thus RPL messaging cannot be used for creating NCE entries on
   parent and child, unlike storing MOP.  The child node may send a
   secure unicast NS with ARO option containing its global address to be
   registered on the parent node.  The child node can still use RPL DIO
   to create an NCE on behalf of the parent node.

Jadhav, et al.           Expires August 26, 2018                [Page 9]
Internet-Draft   Neighbor Management Policy for 6LoWPAN    February 2018

                                           RPL
                 New           PRE         Parent        Root
                  |             |            |            |
                  |             |  AuthProc  |            |
                  |<----------->|<----------------------->|
                  |             |            |            |
                  |             |  RPL-DIO   |            |
                  |<-------------------------|            |
                  |             |            |            |
          addNCE(parent,reason=PARENT)       |            |
                  |             |            |            |
                  | sec-NS(ARO=GlobalIPv6)   |            |
                  |------------------------->|            |
                  |             |            |            |
                  |             |       addNCE(new,reason=CHILD)
                  |         sec-NA(status)   |            |
                  |<-------------------------|            |
                  |             |            |            |
                  |             |  RPL-DAO   |            |
                  |-------------------------------------->|
                  |             |            |            |

           Figure 4: NCE creation call Flow for non-storing MOP

   This document expects the neighbor management policy to remember the
   reason why the neighbor entry is inserted.  Secondly, the router may
   remember whether the NS received was secured or unsecured and
   accordingly use it to prioritize eviction entries.  As described in
   the next sections, this reason will help the policy to prioritize the
   entries in case an eviction is required.

2.3.2.  NCE Deletion

   It is imperative that an unwanted neighbor entry be removed as soon
   as possible.  This section talks about different cases in which
   neighbor entry can be deleted.

   Route Invalidation: In case of storing MOP, when the child node
   decides to switch its preferred parent, the RPL specifications allows
   the node to send a no-path DAO message to invalidate the route along
   the previous path(s).  A directly connected parent node can use this
   message to clear the NCE.  While the entry can be immediately
   cleared, usually the implementations choose to wait a small amount of
   time before clearing the entry.  This is to avoid any impact on the
   in-transit traffic.  Thus this also establishes the importance of
   route invalidation to achieve optimized neighbor cache utilization.

Jadhav, et al.           Expires August 26, 2018               [Page 10]
Internet-Draft   Neighbor Management Policy for 6LoWPAN    February 2018

   In case of non-storing mode, the no-path DAO cannot be not employed
   since the previous parent does not having any routing information to
   be invalidated.  But the previous parent may still contain the NCE on
   behalf of the child node.  This document recommends use of [RFC6775]
   section 6.5.3. which allows sending a zero lifetime ARO option in NS
   for deregistering the corresponding neighbor entry.

   [RFC6775], ND optimizations for 6LoWPANs, section 5.5.3. talks about
   deleting the entries in case the NUD (neighbor unreachability
   detection) fails either due to no response to NS messages or due to
   failure response.  NCEs in such cases should be deleted.  An example
   where NUD NS would fail because of no response is the case where the
   child node switches its parent due to link unavailability.  The
   parent in such a case would not receive the no-path DAO message or
   any other traffic from the child node.  Thus on NCE lifetime expiry,
   the parent node would send NS which would fail with no response, thus
   triggering entry deletion.

2.3.3.  NCE Eviction

   The eviction rules have a major impact on the neighbor management
   policy.  Eviction rules are used when the policy has to forcibly
   remove an active neighbor entry from the cache to make space for the
   new (hopefully higher priority) entry.  The eviction policy may take
   into account several considerations such as the reason why the entry
   was made, is the entry in active use currently, how good (for e.g.,
   based on link estimation) the entry currently is.

2.3.3.1.  Eviction for directly connected routing entries

   This section talks about implications of an eviction in which a
   parent node decides of evicting a directly connected routing child
   NCE.  In the sample topology Figure 1, lets assume N3 needs to evict
   N5 from its neighbor cache.  In case of RPL's storing MOP, eviction
   of directly connected routing child NCE also has impact on all the
   sub-children.  Thus not only will it result in impacting N5 but also
   nodes N6 and N7.  It is important to note that such an eviction has
   less impact on RPL's non-storing MOP i.e. in case of non-storing mode
   N5 might end up selecting alternate parent N8 and does not result in
   any additional control overhead for node N6 and N7.

   Thus RPL's non-storing MOP provides additional eviction flexibility
   for a neighbor management policy in terms evicting directly connected
   child entries.

Jadhav, et al.           Expires August 26, 2018               [Page 11]
Internet-Draft   Neighbor Management Policy for 6LoWPAN    February 2018

2.3.4.  NCE Reinforcement

   It is expected that the latest reachability state and metric
   information be maintained in context to the NCE.  With wireless
   networks, the neighbor cache entries prioritization may change over a
   period of time especially the link quality estimation parameters or
   the routing metrics.  Reinforcement refers to updating the parameters
   in context to the NCEs which helps in prioritizing the entries when
   it comes to handling eviction.  In wireless networks, on reception of
   incoming packet, the receiver node's physical and MAC layer may
   derive certain signal reception parameters (such as RSSI, LQI) which
   can be considered for reinforcement purpose if the corresponding
   transmitter/source entry in neighbor cache is found.  It should be
   noted that the signal quality parameters may have high variance in
   6lo networks and thus statistical techniques (such as weighted
   averaging) are usually employed for deciding about a link quality
   over a period of time.  Reinforcement can be achieved using one or
   more of the following techniques:

   Passive Monitoring:  Reinforcing the quality parameters using packets
      received from the source.  Trickled DIO, periodic beacons,
      application traffic etc can be used for such monitoring.

   Active Probing:  A node may select subset of entries for active
      probing wherein it sends a message to the neighbor entry's target
      and can expect a response message back.  An example of such
      probing is [CONTIKI] where unicast DIS is sent to solicit a
      unicast DIO without impacting the trickle timers.  Though it adds
      a control overhead on the link, periodic probing can help to
      ascertain connectivity in the absence of any other traffic from
      the neighboring node.

2.4.  Requirements of a good neighbor management policy

   Route Stability:  Stable NCEs will result in stable routing
      adjacencies.  Thus it is important to avoid unnecessary NCE churn
      for routing path stability.

   Control overhead:  A neighbor management policy may have to use
      signalling messages for policy handling (such as rejection of
      NCE).  It is required that such overhead be kept as low as
      possible.

   Scalability:  Scalability with respect to large and uneven node
      densities in the network.

Jadhav, et al.           Expires August 26, 2018               [Page 12]
Internet-Draft   Neighbor Management Policy for 6LoWPAN    February 2018

2.5.  Approaches to neighbor management policy

   Neighbor management policy depends upon the neighbor cache space
   availability and the same can be advertised proactively or can be
   handled reactively.

2.5.1.  Reactive Approach

   In this approach, the nodes select their RPL parent or the relay
   element purely based on link metrics and subsequently when they try
   to allocate their NCE in the target node, it may fail due to
   unavailability of the cache space.  The failure can be communicated
   depending upon the signaling involved:

   NS failure:  Section 6.5.3 of [RFC6775] defines a procedure for NS
      failure handling in case the router's neighbor cache is full.  It
      results in a unicast NA with ARO status field set to two.

   DAO NACK:  Section 9.3 of RPL [RFC6550] specifies on how can the
      parent node react to DAOs from child.  In case the parent could
      not make a NCE on behalf of the child node, a negative ACK with
      status (between 127-255) should be sent to the child node.  The
      natural reaction of the child node would be to switch to an
      alternate parent.

   PANA Failure:  PaC's auth session starts with a PaC discovering a
      PRE.  The discovery procedure is not standardized and can be based
      upon various factors including signal strength of discovery
      messages from PRE.  Post discovery, the PaC needs to send an
      unsecured unicast NS message with an ARO containings its link-
      local IPv6 address.  NS helps to determine whether the PRE can
      allocate an NCE for the PaC.  PRE accordingly sends a NA response
      with appropriate status field.

2.5.2.  Proactive Approach

   Neighbor cache availability could be proactively advertised by the
   parent nodes in the DIO messages and in the PRE discovery messages.
   A child RPL node may additionally use this information from DIO as
   part of parent selection process.  In case of new joinee node, the
   node may use PRE discovery messages with space availability
   information to select an appropriate PRE.  Proactive signaling of
   neighbor cache space availability will help the nodes to select the
   parent node or relay node such that the failure signaling due to
   cache full event can be reduced.

   Currently there is no standard way of signaling such neighbor cache
   space availability information.  RPL's DIO messages carry metric

Jadhav, et al.           Expires August 26, 2018               [Page 13]
Internet-Draft   Neighbor Management Policy for 6LoWPAN    February 2018

   information and can be augmented with neighbor cache space as an
   additional metric.  In case of PRE discovery however there is no
   standard way of defining this information since the PRE discovery
   procedure itself is not standardized.

   In a wireless or shared bus network, a multicast DIO metric
   advertisement may reach several child nodes eventually everyone
   responding by selecting the same parent node causing neighbor cache
   to be exhausted.  Thus the failure handling approaches defined in the
   Reactive Approach section applies here as well.  But importantly the
   failure signaling will be significantly reduced because of proactive
   advertisement.

3.  Reservation based Neighbor Management Policy

   This section defines a sample neighbor management policy, with the
   primary objective to reduce NCE churn and to ensure stability of
   routing adjacencies.  The scheme uses a reservation based policy to
   reserve NCEs for:

   +-----------------------------+----------------------------+--------+
   |        NCE Entry for        |         MAX count          | Reason |
   +-----------------------------+----------------------------+--------+
   |        Routing Parent       | MAX_ROUTING_PARENT_NCE_NUM | PARENT |
   |                             |                            |        |
   |        Routing child        | MAX_ROUTING_CHILD_NCE_NUM  | CHILD  |
   |                             |                            |        |
   |   Others such as pre-auth   |     MAX_OTHER_NCE_NUM      | OTHER  |
   |           sessions          |                            |        |
   +-----------------------------+----------------------------+--------+

                 Table 1: Neighbor Cache Entry reservation

   Note that reservation policy depends upon identification of the
   reason behind making an NCE . In case of pre-auth sessions, the
   corresponding NCE is created based on the unsecured NS/NA.  In case
   of storing MOP, CHILD_ENT NCEs are created either based on DAO (as
   shown in Figure 3) or based on secured NS/NA messaging (as shown in
   Figure 4).  In case of non-storing MOP, a secured NS/NA messaging as
   shown in Figure 4 needs to be used.

     <- - - - - - - - - - - Routing Parents - - - - - - - - - - - - ->
     +---------------------------------------------------------------+
     |                                 |                   |         |
     +-----------------------------------------------------+---------+
       Routing Child                    Routing Parents     Other

              Figure 5: Reservation of NCEs in neighbor table

Jadhav, et al.           Expires August 26, 2018               [Page 14]
Internet-Draft   Neighbor Management Policy for 6LoWPAN    February 2018

   As shown in the figure, the neighbor cache is partitioned into
   different entry types.  The routing parents can possibly occupy any
   entry type if found vacant since in case an eviction is sought the
   non-preferred routing parent could be evicted without much impact on
   the functioning or on the control traffic.  The eviction could be
   done based on reasons specified in Section 2.3.3.

   Routing Child entries are made in context to directly connected peers
   and these entries are not deleted unless they are unreacable or there
   is any reason for the parent node to believe that it is no longer the
   preferred parent for the child node.  Deletion may happen based on
   reasons mentioned in Section 2.3.2.

   Other entries (OTHER) may be made in response to temporary
   requirement of making an NCE.  One such case is the pre
   authentication phase where in the relay node makes an entry of the
   PaC temporarily till the time the authentication phase is completed.
   The NCE made thus is garbage collected at the end of the lifetime.
   Also an implementation may choose to keep a lower lifetime for such
   NCEs depending upon the time taken to complete the authentication
   process.

3.1.  Limitations of such a policy

   The reservation based policy mentioned in this section may result in
   sub-optimal path selection due to lack of NCE resource on the parent
   nodes.  Also the restriction of maximum pre-auth sessions in the form
   of MAX_OTHER_NCE_NUM limits the maximum relay sessions that can be
   supported on the relay node.

   The reservation policy allows the parent node to reject the child
   node's DAO or NS.  But the child node cannot remember this rejection
   and may reattempt the same parent after some time depending upon
   triggers such as reception of DIO from the same parent who rejected
   it previously.  One of the only way to stop the child node from
   reattempting such parent selection would be to also include a
   proactive approach wherein the parent node signals its resource
   availability in the DIO message as mentioned in Section 2.5.2.  Such
   a scheme of signalling parent node's resource availability is
   currently not standardized.

   RPL's storing MOP imposes additional restrictions.  One such case is
   where a child node may have a given parent node as its only parent
   and that parent node's NCE are all used up.  In such a case, the
   child node would keep on retrying and failing to send a DAO through
   the parent node.  Ideally the parent node could have evicted a least
   used child node or a child node who has an alternate parent
   available.  Evicting such a child node is a complex process and may

Jadhav, et al.           Expires August 26, 2018               [Page 15]
Internet-Draft   Neighbor Management Policy for 6LoWPAN    February 2018

   increase the control overhead as described in Section 2.3.3.1.  Thus
   the reservation based policy requires that the minimum node density
   is sufficiently high so that every child finds a parent node in its
   vicinity with enough resources.

4.  Acknowledgements

   Thanks to Malisa Vucinic for pointing towards security aspects of un-
   authenticated nodes neighbor cache management.

5.  IANA Considerations

   This memo includes no request to IANA.

6.  Security Considerations

   The Join Relay or the PANA Relay Element allows the un-authenticated
   nodes to join the network.  Since the NS/NA signaling is unencrypted,
   it is possible that a malicious node may try spoof and occupy all the
   entries.  This draft explains the use of reservation based policy for
   managing such entries.  Following points try to reduce the impact of
   such attacks: Only a subset of entries are reserved for un-
   authenticated nodes.

   a.  Only a subset of entries are reserved for un-authenticated nodes
       doing plain-text NS/NA

   b.  It is recommended that NCE timeout be configured a lower value to
       evict such entries as soon as possible.  New joining nodes are
       supposed to use these entries and thus are only needed during the
       time the authentication is in progress.  Thus a short-duration
       NCE timeout will help reduce the impact of DoS attacks.

7.  References

7.1.  Normative References

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119,
              DOI 10.17487/RFC2119, March 1997,
              <https://www.rfc-editor.org/info/rfc2119>.

   [RFC6550]  Winter, T., Ed., Thubert, P., Ed., Brandt, A., Hui, J.,
              Kelsey, R., Levis, P., Pister, K., Struik, R., Vasseur,
              JP., and R. Alexander, "RPL: IPv6 Routing Protocol for
              Low-Power and Lossy Networks", RFC 6550,
              DOI 10.17487/RFC6550, March 2012,
              <https://www.rfc-editor.org/info/rfc6550>.

Jadhav, et al.           Expires August 26, 2018               [Page 16]
Internet-Draft   Neighbor Management Policy for 6LoWPAN    February 2018

   [RFC6775]  Shelby, Z., Ed., Chakrabarti, S., Nordmark, E., and C.
              Bormann, "Neighbor Discovery Optimization for IPv6 over
              Low-Power Wireless Personal Area Networks (6LoWPANs)",
              RFC 6775, DOI 10.17487/RFC6775, November 2012,
              <https://www.rfc-editor.org/info/rfc6775>.

7.2.  Informative References

   [CONTIKI]  Thingsquare, "Contiki: The Open Source OS for IoT", 2012,
              <http://www.contiki-os.org>.

   [Dawans_et_al]
              Dawans, S., Duquennoy, S., and O. Bonaventure, "On Link
              Estimation in Dense RPL Deployments", 2012.

   [I-D.ietf-6tisch-architecture]
              Thubert, P., "An Architecture for IPv6 over the TSCH mode
              of IEEE 802.15.4", draft-ietf-6tisch-architecture-13 (work
              in progress), November 2017.

   [I-D.ietf-6tisch-minimal-security]
              Vucinic, M., Simon, J., Pister, K., and M. Richardson,
              "Minimal Security Framework for 6TiSCH", draft-ietf-
              6tisch-minimal-security-04 (work in progress), October
              2017.

   [RFC5191]  Forsberg, D., Ohba, Y., Ed., Patil, B., Tschofenig, H.,
              and A. Yegin, "Protocol for Carrying Authentication for
              Network Access (PANA)", RFC 5191, DOI 10.17487/RFC5191,
              May 2008, <https://www.rfc-editor.org/info/rfc5191>.

   [RFC6345]  Duffy, P., Chakrabarti, S., Cragie, R., Ohba, Y., Ed., and
              A. Yegin, "Protocol for Carrying Authentication for
              Network Access (PANA) Relay Element", RFC 6345,
              DOI 10.17487/RFC6345, August 2011,
              <https://www.rfc-editor.org/info/rfc6345>.

   [Woo_et_al]
              Woo, A., Tong, T., and D. Culler, "Taming the Underlying
              Challenges of Reliable Multihop Routing in Sensor
              Networks", 2003.

Authors' Addresses

Jadhav, et al.           Expires August 26, 2018               [Page 17]
Internet-Draft   Neighbor Management Policy for 6LoWPAN    February 2018

   Rahul Arvind Jadhav (editor)
   Huawei
   Kundalahalli Village, Whitefield,
   Bangalore, Karnataka  560037
   India

   Phone: +91-080-49160700
   Email: rahul.ietf@gmail.com

   Rabi Narayan Sahoo
   Huawei
   Kundalahalli Village, Whitefield,
   Bangalore, Karnataka  560037
   India

   Phone: +91-080-49160700
   Email: rabinarayans@huawei.com

   Simon Duquennoy
   Inria
   40 Avenue Halley
   Building A
   Villeneuve d'Ascq
   France

   Phone: +33 768227731
   Email: simon.duquennoy@inria.fr

   Joakim Eriksson
   Yanzi Networks

   Email: joakime@sics.se

Jadhav, et al.           Expires August 26, 2018               [Page 18]