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

Versions: (draft-ietf-roll-mopex-cap) 00 01 02

ROLL                                                      R. Jadhav, Ed.
Internet-Draft                                               Huawei Tech
Intended status: Standards Track                              P. Thubert
Expires: September 12, 2020                                        Cisco
                                                           M. Richardson
                                                Sandelman Software Works
                                                           R. Sahoo, Ed.
                                                          March 11, 2020


                            RPL Capabilities
                    draft-ietf-roll-capabilities-02

Abstract

   This draft enables the discovery, advertisement and query of
   capabilities for RPL nodes.

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 September 12, 2020.

Copyright Notice

   Copyright (c) 2020 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 September 12, 2020               [Page 1]


Internet-Draft               RPL Capabilties                  March 2020


   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 . . . . . . . . . .   3
     1.2.  What are Capabilities?  . . . . . . . . . . . . . . . . .   3
   2.  Requirements for this document  . . . . . . . . . . . . . . .   4
     2.1.  How are Capabilities different from MOP or DIO
           Configuration Option? . . . . . . . . . . . . . . . . . .   4
   3.  Capabilities  . . . . . . . . . . . . . . . . . . . . . . . .   5
     3.1.  Capability Catagories . . . . . . . . . . . . . . . . . .   5
     3.2.  Capability Control Message Option . . . . . . . . . . . .   5
     3.3.  Capabilities Handshake  . . . . . . . . . . . . . . . . .   6
   4.  Guidelines for defining new capabilities  . . . . . . . . . .   7
     4.1.  Handling Capability flags . . . . . . . . . . . . . . . .   7
       4.1.1.  Rules to handle capabilities flag . . . . . . . . . .   7
   5.  ROLL Capabilities . . . . . . . . . . . . . . . . . . . . . .   8
     5.1.  Projected Route Capability (PRC)  . . . . . . . . . . . .   8
       5.1.1.  Format of Projected Route Capability  . . . . . . . .   9
     5.2.  6LoRH Capability  . . . . . . . . . . . . . . . . . . . .   9
       5.2.1.  Format of 6LoRH Capability  . . . . . . . . . . . . .  10
     5.3.  Routing Resource Capability . . . . . . . . . . . . . . .  11
       5.3.1.  Format of Routing Resource Capability . . . . . . . .  11
     5.4.  Neighbor Cache Capability . . . . . . . . . . . . . . . .  12
       5.4.1.  Format of Neighbor Cache Capability . . . . . . . . .  13
   6.  Acknowledgements  . . . . . . . . . . . . . . . . . . . . . .  13
   7.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .  13
     7.1.  New option: Capabilities  . . . . . . . . . . . . . . . .  13
     7.2.  New Registry for Capabilities Flags . . . . . . . . . . .  13
   8.  Security Considerations . . . . . . . . . . . . . . . . . . .  14
   9.  References  . . . . . . . . . . . . . . . . . . . . . . . . .  14
     9.1.  Normative References  . . . . . . . . . . . . . . . . . .  14
     9.2.  Informative References  . . . . . . . . . . . . . . . . .  15
   Appendix A.  Capability Handshake Example . . . . . . . . . . . .  15
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  15

1.  Introduction

   RPL [RFC6550] specifies a proactive distance-vector based routing
   scheme.  The protocol creates a DAG-like structure which operates
   with a given "Mode of Operation" (MOP) determining the minimal and
   mandatory set of primitives to be supported by all the participating
   nodes.

   This document adds a notion of capabilities using which the nodes in
   the network could inform its peers about its additional capabilities/



Jadhav, et al.         Expires September 12, 2020               [Page 2]


Internet-Draft               RPL Capabilties                  March 2020


   features.  This document highlights the differences of capabilities
   from that of Mode of operation and explains the necessity of it.

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

   MOP: Mode of Operation.  Identifies the mode of operation of the RPL
   Instance as administratively provisioned at and distributed by the
   DODAG root.

   MOPex: Extended MOP: As defined in [I-D.jadhav-roll-mopex].

   Capabilities: Additional features or capabilities which might
   possibly be optional that are supported by the node.

   DAO: DODAG Advertisement Object.  An RPL message used to advertise
   the target information in order to establish routing adjacencies.

   DIO: DODAG Information Object.  An RPL message initiated by the root
   and is used to advertise the network configuration information.

   Current parent: Parent 6LR node before switching to the new path.

   NPDAO: No-Path DAO.  A DAO message which has target with lifetime 0.

   MOPex: MOP extension as defined in this document.

   Upstream path/direction: Path or direction from the node to the Root
   in a DAG.

   Downstream path/direction: Path or direction to the node from the
   Root in a DAG.

   This document uses terminology described in [RFC6550].  For the sake
   of readability all the known relevant terms are repeated in this
   section.

1.2.  What are Capabilities?

   Currently RPL specification does not have a mechanism whereby a node
   can signal the set of features that are available on its end.  Such a
   mechanism could help the root to advertise its capabilities and in
   response also determine some advanced information about the
   capabilities of the joining nodes.  This document defines
   Capabilities which could be supported by the nodes and handshaked as



Jadhav, et al.         Expires September 12, 2020               [Page 3]


Internet-Draft               RPL Capabilties                  March 2020


   part of RPL signaling.  Capabilities are embedded as RPL control
   message option as defined Section 6.7 of [RFC6550] in the base
   messages of DIO, DAO and DAO-ACK signaling.

2.  Requirements for this document

   Following are the requirements considered for this documents:

   REQ1:  Backwards compatibility.  The new options and new fields in
          the DIO message should be backward compatible i.e. if there
          are nodes which support old MOPs they could still operate in
          their own instances.

   REQ2:  Optional capabilities handshake.  Capabilities are features,
          possibly optional, which could be handshaked between the nodes
          and the root within an RPL Instance.

   REQ3:  Capabilities handshake could be optionally added with existing
          MOPs.  Capabilities been optional in nature could be put to
          use with existing MOPs.  Capabilities and MOP-extension is
          mutually independent i.e. a DIO can have a capabilities
          option, MOP-extension option or both in the same message.

   REQ4:  Capabilities could be explicitly queried.

2.1.  How are Capabilities different from MOP or DIO Configuration
      Option?

   The Mode of Operation (MOP) field in RPL mandates the operational
   requirement for the nodes joining as routers.  MOP and DIO
   Configuration Option is strictly controlled by the Root node in RPL.
   Intermediate 6LRs could not modify the values.  Also, the MOP never
   changes for the lifetime of the RPL Instance.  Changes in DIO
   Configuration Option are possible but are very rare.  Capabilities,
   on the other hand, might change more dynamically.

   RPL DIO message also carries routing metrics and constraints as
   specified in [RFC6551].  Metrics and constraints are used as part of
   objective function which aids in node's rank calculation.  A router
   may use capabilities carried in DIO message as additional metrics/
   constraints.  However, capabilities have a larger scope and may be
   carried in other messages other than DIO and can flow in both the
   directions (upstream and downstream).








Jadhav, et al.         Expires September 12, 2020               [Page 4]


Internet-Draft               RPL Capabilties                  March 2020


3.  Capabilities

   Handling of Capabilities MUST be supported if the network uses MOPex
   [I-D.jadhav-roll-mopex].

   Note that capabilities and MOPex are mutually exclusive and it is
   possible for an implementation to support either or both of the
   options.

3.1.  Capability Catagories

   Capabilities can be divided into two broad categories:

   Global Capabilities: It will include the features and capability
   supported across an RPL instance.  These capabilities can be
   advertised by the Root or 6LRs of the DODAG.  If a Node in the LLN
   doesn't support a paticular global capability it may have to join the
   RPL instance as a leaf node, as indicated by that individual
   capability option.  Example of such capabilities are Compression
   Methods Supported, Support for TE paths (P-DAO).

   Local Capabilities: It will include the cpabilities very specific to
   a Node in the LLN.  Example of such capabilities are NBR Cache
   information, Routing Table Information.

   Note that some capabilities can be either global or local depending
   upon the context they are used ex.P-DAO [TODO: This is not clear]

3.2.  Capability Control Message Option

      0                   1                   2                   3
      0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |   Type = TODO | Option Length | Capabilities TLVs
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+


                       Figure 1: Capabilities Option

   Multiple capabilities could be sent in the same message.  The length
   field allows the message parser to skip the capability TLV parsing.










Jadhav, et al.         Expires September 12, 2020               [Page 5]


Internet-Draft               RPL Capabilties                  March 2020


      0                   1                   2                   3
      0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |   CAPType     |J|I|G|C|.|.|.|.| CAPInfo(Opt)
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                        Figure 2: Capabilities TLV

   Every capability is identified by its type and it may have an
   optional Capability Info.  Note that a given capability may or may
   not be diseminated with additional information depending on the scope
   of the capability indicated by the I bit.

   J = Join only as leaf if capability not understood

   I = Capability Info present

   C = Flag indicating that the capability MUST be copied in the
   downstream messages

   G = If set indicates a Global Capability else its a local.  For a
   capability if it's mandatory and global bit is set then node those
   either doesn't understand the capability or doesn't have this
   capability should not join the DODAG as a router.  All the global
   capablities MUST be diseminated across the network. 6LRs in the
   network MUST copy the global capabilities in their DIOs.

      0                   1                   2                   3
      0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |   CAPLen      | Cap Info(format decided by individual cap spec)
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                        Figure 3: Capabilities Info

   Capability Information provides additional information for the given
   capability.  The format of this field should be defined as part the
   individual capability specification and is beyond the scope of this
   document.  This document provides a container format for carrying the
   capability and its context information.

3.3.  Capabilities Handshake

   The root node could advertise the set of capabilities it supports in
   the DIO message.  A node could take advantage of the knowledge that
   the root supports a particular capability.  Similarly a node could
   advertise its capabilities in the DAO message using the capability
   control message option defined in this document.  Capabilities



Jadhav, et al.         Expires September 12, 2020               [Page 6]


Internet-Draft               RPL Capabilties                  March 2020


   advertised by non-root nodes are strictly a subset of the
   capabilities advertised by the root.

   In storing MOP, the DAO message from the 6LR could contain multiple
   target options because of the DAO-Aggregation.  The targets of the
   capabilities option are indicated by one or more Target options that
   precede the Capabilties Option.  This handling is similar to the
   Transit Information Option as supported in Section 6.7.8. of
   [RFC6550].

4.  Guidelines for defining new capabilities

   This section provides guidelines/recommendations towards defining new
   capabilities.  Note that the capabilities might be carried as part of
   the multicast messaging such as DIO and hence the set should be used
   in restrictive manner as far as possible.

4.1.  Handling Capability flags

   The 'G' (global) flag indicating global capability should be set only
   by the root.  However, it is not mandatory for the root to set this
   flag for all capabilities it indicates.  It should set this flag only
   for those capabilities which the 6LRs downstream must propagate
   further downstream.

   The 'I' (information) flag is set only when there is additional
   information to be set in context to the capability.

   The 'J' (join) flag can be set in context to a capability either by a
   6LR or the root.  The 'J' flag indicates that if the capability is
   not supported by a node then it can join the instance only as a 6LN
   (or do not join as 6LR).

   The 'C' (copy) flag is set by the node indicating that the
   capabilities MUST be copied downstream by the node.

4.1.1.  Rules to handle capabilities flag
   On receiving a capability it does not support, the node MUST check
   the 'J' flag of the capability before joining the Instance.  If the
   'J' flag is set then it can only join as a 6LN.
   If the node is operating as 6LR and subsequently it receives a
   capability which it doesn't understand with 'J' flag set, then the
   node has to switch itself to 6LN mode.  During switching the node
   needs to inform its downstream peers of its changed status by sending
   a DIO with infinite rank as mentioned in [RFC6550].






Jadhav, et al.         Expires September 12, 2020               [Page 7]


Internet-Draft               RPL Capabilties                  March 2020


5.  ROLL Capabilities

5.1.  Projected Route Capability (PRC)

   [I-D.ietf-roll-dao-projection] proposes mechanisms to compute and
   install traffic engineered paths in the RPL network.  It enables an
   RPL Root to install and maintain Projected Routes based on requested
   path metric, within its DODAG, along with a selected set of nodes
   that may or may not include self, for a chosen duration.  Projected
   Route Capability will be used to enable this TE path calculation.
   PRC will be an optional global capability.  Any node that does not
   understand or support the projected route functions can still act as
   an LR.

   The DODAG root will use projected routes capability to advertise the
   support of projected routes with the possible mode of operations and
   set of path metrics it can use to calculate a projected route.  DODAG
   root will add the PRC to DIO message so that it can disseminate the
   information in entire DODAG.  Router nodes in the LLN receiving DIOs
   with PRC MUST forward the same into their sub-DODAG without any
   change even though they don't understand or support the projected
   route feature.LR will use the path metric information advertised by
   the DODAG root to learn these metrics from the network and neighbors.
   The same information they will use to advertise in the sibling
   information option.  LR will also use these path metrics information
   to request traffic-engineered routes optimizing a or set of specific
   network metric(s).

   LRs in the network will use this capability to inform the PCE if they
   can be part of a storing or non-storing or both mode of projected
   routes.  Here the PRC will be part of the DAO message.

   The capability will convey the below information.  The PRC MUST have
   either of the information or both depending upon the node type.If
   originator is BR, then both the information MUST be there.

   I:     Supports projected route for both storing and non-storing
          mode.

   II:    List of supported path metrics that can be used to compute
          projected routes.

   III:   [To Decide] Can we add the PCE address information to this?








Jadhav, et al.         Expires September 12, 2020               [Page 8]


Internet-Draft               RPL Capabilties                  March 2020


5.1.1.  Format of Projected Route Capability

     0                   1                   2                   3
     0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     | Type=0x01     |J|I|G|C|. . . .|     CAPLen    | MOP |  Resvd  |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |       Routing Metric 1        |      Routing Metric 1         |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |       Routing Metric n-1      |      Routing Metric n         |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                 Figure 4: Projected Route Capability TLV

   Type: 0x01.

   Flags: DODAG root MUST set G bit to 1 plus LRs MUST set it to 0.  I
   bit will always be set to 1.

   CAPLen: 8-bit unsigned integer, representing the length in octets of
   the option, not including the Option Type and Length fields.

   MOP: 3-bit field indicating the mode of operation of projected route
   capability.

   Resvd: 5-bit unused fields.They MUST be initialized to zero by the
   sender and MUST be ignored by the receiver.

   Routing Metric: 16 bit unsigned integer representing the routing
   metric to be used for TE path calculation.  There can be n number of
   such routing metric fields.  These fileds are alowed with the PRC
   sent by the DODAG ROOT.  LRs MUST not send routing metric information
   with PRC.

                                   0                   1
                                   0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6
                                   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
                                   | Type=0x01     |     Resvd     |
                                   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                   Figure 5: Routing Metric Information

5.2.  6LoRH Capability

   [RFC8138] introduces a new 6LoWPAN Routing Header (6LoRH) to carry
   IPv6 routing information.  The 6LoRH may contain source routing
   information such as a compressed form of SRH, and other sorts of
   routing information such as the RPI and IP-in-IP encapsulation



Jadhav, et al.         Expires September 12, 2020               [Page 9]


Internet-Draft               RPL Capabilties                  March 2020


   The transition to [RFC8138] in a network can only be done when all
   nodes support the specification.  In a mixed case with both
   RFC8138-capable and non-capable nodes it would not be posssible to
   take advantage of 6LoRH.[I-D.thubert-roll-turnon-rfc8138] defines a
   mechanism to control the use of 6LoRH in a DODAG by using "T" flag
   bit in RPL configuration option.  To assist DODAG root to decide if
   it has to set "T" flag bit in RPL Configuration Option to enable
   6LoRH within its DODAG, all LRs in DODAG MUST inform their support of
   [RFC8138] by adding 6LoRH capability TLV to their advertised
   capability control message option.

   DODAG root MUST use 6LoRH capability TLV to inform all the nodes in
   the DODAG, that DODAG is [RFC8138] compliance. 6LoRH is an optional
   local capability.

   Any LR joining the DODAG MUST add 6LoRH capability TLV to the
   capability control message option in its DAO message to inform BR
   that it supports RFC8138.If received DAO message doesn't have 6LoRH
   capability TLV, DODAG Root MUST conclude the target node doesn't
   support RFC 8138.So if DODAG is still not using 6LoRH, it MUST
   refrain from using the compression and if it is already using it, it
   MUST deny the LR from joining the DODAG with proper error code.
   [TODO- Need to add new Error code].

   6LoRH capability is an optional capability any node that doesn't
   understand or support the 6LoRH can join the DODAG if the "T" flag in
   the RPL Configuration option is not set otherwise it MUST join the
   network as a leaf node.

5.2.1.  Format of 6LoRH Capability

     0                   1                   2                   3
     0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     | Type=0x02     |J|I|G|C|. . . .|           Reserved            |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                      Figure 6: 6LoRH Capability TLV

   Type: 0x02.

   Flags: LRs MUST set it to 0.  I bit will always be set to 0.

   Reserved: 16-bit unsigned integer, they MUST be initialized to zero
   by the sender and MUST be ignored by the receiver..






Jadhav, et al.         Expires September 12, 2020              [Page 10]


Internet-Draft               RPL Capabilties                  March 2020


5.3.  Routing Resource Capability

   Storing mode of operation requires each intermediate router in the
   LLN to maintain routing states' information in the routing table.
   LLN routers typically operate with constraints on processing power,
   memory, and energy (battery power).  Memory limits the number of
   routing states an LR and BR can maintain.  When the routing table of
   an LR or BR is full, it will either reject the new DAO messages
   received or will use some replacement policy to remove a routing
   entry and add the new one.  Rejection of DAO messages will lead to an
   increase in DAO message transmission that impacts the energy and
   network convergence time.  Routing state replacement leads to
   downward path downtime.

   One possible way to solve problems due to routing table size
   constraint is to use this information to add neighbors to the DAO
   parent set.Routing resource capability can be used by LR and BR to
   advertise their current routing table usage details in the network.
   LR or LNs in LLN can use this information in the selection of the DAO
   parent set.  PCE can use this information to select intermediate
   routers for the projected routes.  Routing Resource is an optional
   local capability.

   Routing reource capability TLV can occur multiple times in the
   capability control message option to advertise below possible routing
   table information.

   I:     Master Routing Table Storing

   II:    Storing mode P-DAO Table

   III:   Non-Storing mode P-DAO

   Routing resource capabablity sent in DIO message has link local scope
   and it MUST not be forwarded.

5.3.1.  Format of Routing Resource Capability

     0                   1                   2                   3
     0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     | Type=0x03     |J|I|G|C|. . . .|     CAPLen    | RT  |  Resvd  |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |        Total Capacity         |  Used Per     |   Threshold   |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                 Figure 7: Routing Resource Capability TLV




Jadhav, et al.         Expires September 12, 2020              [Page 11]


Internet-Draft               RPL Capabilties                  March 2020


   Type: 0x03.

   Flags: G bit MUST be set to 0.  I bit will always be set to 1.

   CAPLen: 8-bit unsigned integer, representing the length in octets of
   the option, not including the Option Type and Length fields.

   RT: 3-bit field indicating the routing resource type.  This document
   defines 3 routing resource type.

   I:     Master Routing Table Storing(RT = 1)

   II:    Storing mode P-DAO Table(RT = 2)

   III:   Non-Storing mode P-DAO(RT = 3)

   Resvd: 5-bit unused field.  It MUST be initialized to zero by the
   sender and MUST be ignored by the receiver.

   Total Capacity: 16 bit unsigned integer representing the the routing
   table size.

   Percentage used: 8 bit unsigned integer representing the the
   percentage of routing table space currently in use.

   Threshold: 8 bit unsigned integer representing the maximum routing
   table space that can be used.  If the routing resource type is RT1
   and used Percentage is greater than or equal to a threshold, its
   siblings MUST stop using it as the preferred parent or remove it from
   the parent list.  If the routing resource type is RT2 or RT3 and used
   Percentage is greater than or equal to a threshold, PCE MUST
   recompute some projected routes by excluding this node.

5.4.  Neighbor Cache Capability

   A neighbor cache maintains neighboring one-hop connected nodes
   information such as MAC address, link-local IP address and other
   reachability state information needed for layer two
   communication.Node density has direct implications on the neighbor
   cache.  In the constrained network scenario the size of the neighbor
   cache will be limited.  Thus there are chances that a node may not be
   able to store all the neighboring nodes in its cache and use
   replacement algorithms to evict some of the entries to accommodate
   the new one.  If the replaced neighbor has installed a DAO route on
   it then it can lead to packet loss or additional address resolution
   message exchange.  To avoid unnecessary replacement of neighbor cache
   entries neighbor cache management policy
   [I-D.ietf-lwig-nbr-mgmt-policy] proposes a solution that will put a



Jadhav, et al.         Expires September 12, 2020              [Page 12]


Internet-Draft               RPL Capabilties                  March 2020


   restriction on the connectivity to immediate neighbor depending upon
   the type of neighbor.  But this won't solve the problem unless until
   the availability of neighbor cache is not taken into consideration
   while selecting the DAO parent set.

   Neighbor Cache capability can be used by LR and BR to advertise their
   neighbor cache size information.  This capablity information has only
   link scope and should not be advertised in the entire network.
   [TODO-- As neighbor cache entries category is not yet standardized i
   think we can't use it in capability.  With categories format of the
   TLV is going to chnage.]

5.4.1.  Format of Neighbor Cache Capability

6.  Acknowledgements

   Thanks to Georgios Papadopoulos, Li Zhao for the review and feedback.

7.  IANA Considerations

7.1.  New option: Capabilities

   New entry is required for supporting new Capabilities option in the
   "RPL Control Message Options" space [RFC6550].

                 +-------+--------------+---------------+
                 | Value |   Meaning    |   Reference   |
                 +-------+--------------+---------------+
                 |  TBD1 | Capabilities | This document |
                 +-------+--------------+---------------+

                                New options

7.2.  New Registry for Capabilities Flags

   IANA is requested to create a registry for the Capabilities flags as
   described in Section 2.1 of this document.  This registry should be
   located in TODO.  New Capabilities flags may be allocated only by an
   IETF review.  Currently no flags are defined by this document.  Each
   value is tracked with the following qualities:

   o  Flag

   o  Description

   o  Defining RFC





Jadhav, et al.         Expires September 12, 2020              [Page 13]


Internet-Draft               RPL Capabilties                  March 2020


8.  Security Considerations

   The options defined in this document are carried in the base message
   objects as defined in [RFC6550].  The RPL control message options are
   protected by the same security mechanisms that protect the base
   messages.

   Capabilities flag can reveal that the node has been upgraded or is
   running a old feature set.  This document assumes that the base
   messages that carry these options are protected by RPL security
   mechanisms and thus are not visible to a malicious node.

   [TODO] implications of malicious attack involving setting the
   capability flags.

9.  References

9.1.  Normative References

   [I-D.ietf-roll-dao-projection]
              Thubert, P., Jadhav, R., and M. Gillmore, "Root initiated
              routing state in RPL", draft-ietf-roll-dao-projection-09
              (work in progress), November 2019.

   [I-D.thubert-roll-turnon-rfc8138]
              Thubert, P. and L. Zhao, "Configuration option for RFC
              8138", draft-thubert-roll-turnon-rfc8138-03 (work in
              progress), July 2019.

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

   [RFC8138]  Thubert, P., Ed., Bormann, C., Toutain, L., and R. Cragie,
              "IPv6 over Low-Power Wireless Personal Area Network
              (6LoWPAN) Routing Header", RFC 8138, DOI 10.17487/RFC8138,
              April 2017, <https://www.rfc-editor.org/info/rfc8138>.






Jadhav, et al.         Expires September 12, 2020              [Page 14]


Internet-Draft               RPL Capabilties                  March 2020


9.2.  Informative References

   [I-D.ietf-lwig-nbr-mgmt-policy]
              Jadhav, R., Sahoo, R., Duquennoy, S., and J. Eriksson,
              "Neighbor Management Policy for 6LoWPAN", draft-ietf-lwig-
              nbr-mgmt-policy-03 (work in progress), February 2019.

   [RFC6551]  Vasseur, JP., Ed., Kim, M., Ed., Pister, K., Dejean, N.,
              and D. Barthel, "Routing Metrics Used for Path Calculation
              in Low-Power and Lossy Networks", RFC 6551,
              DOI 10.17487/RFC6551, March 2012,
              <https://www.rfc-editor.org/info/rfc6551>.

Appendix A.  Capability Handshake Example

                   Root          6LR          6LN
                    |             |            |
                    |   DIO(CS1)  |            |
                    |------------>|  DIO(CS1)  |
                    |             |----------->|
                    |             |            |
                    |             |   DAO(CS2) |
                    |             |<-----------|
                    |   DAO(CS2)  |            |
                    |<------------|            |
                    |             |            |
                    CS: Capabilities Set
                    CS1: Capabilities set advertised by root
                    CS2: Capabilities set advertised by node. CS2 is a subset of CS1.

                       Figure 8: Capabilities Option

Authors' Addresses

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

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









Jadhav, et al.         Expires September 12, 2020              [Page 15]


Internet-Draft               RPL Capabilties                  March 2020


   Pascal Thubert
   Cisco Systems, Inc
   Building D
   45 Allee des Ormes - BP1200
   MOUGINS - Sophia Antipolis  06254
   France

   Phone: +33 497 23 26 34
   Email: pthubert@cisco.com


   Michael Richardson
   Sandelman Software Works

   Email: mcr+ietf@sandelman.ca


   Rabi Narayan Sahoo (editor)

   Email: rabinarayans0828@gmail.com































Jadhav, et al.         Expires September 12, 2020              [Page 16]


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