ROLL R. Jadhav, Ed.
Internet-Draft Huawei Tech
Intended status: Standards Track P. Thubert
Expires: October 18, 2020 Cisco
M. Richardson
Sandelman Software Works
R. Sahoo, Ed.
April 16, 2020
RPL Capabilities
draft-ietf-roll-capabilities-03
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 October 18, 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 October 18, 2020 [Page 1]
Internet-Draft RPL Capabilties April 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 . . . . . . . . . . . . . . . . . . . . . . . . 4
3.1. Capability Categories . . . . . . . . . . . . . . . . . . 5
3.2. Capability Control Message Option . . . . . . . . . . . . 5
3.3. Capabilities Handshake . . . . . . . . . . . . . . . . . 6
4. Guidelines for defining new capabilities . . . . . . . . . . 6
4.1. Handling Capability flags . . . . . . . . . . . . . . . . 7
4.1.1. Rules to handle capabilities flag . . . . . . . . . . 7
5. ROLL Capabilities . . . . . . . . . . . . . . . . . . . . . . 7
5.1. Capability Indicators . . . . . . . . . . . . . . . . . . 7
5.1.1. Format of Capability Indicators . . . . . . . . . . . 7
5.2. Routing Resource Capability . . . . . . . . . . . . . . . 8
5.2.1. Format of Routing Resource Capability . . . . . . . . 9
6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 9
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9
7.1. New option: Capabilities . . . . . . . . . . . . . . . . 9
7.2. New Registry for Capabilities Flags . . . . . . . . . . . 10
7.3. New Registry for Capabilities Indicators . . . . . . . . 10
8. Security Considerations . . . . . . . . . . . . . . . . . . . 10
9. References . . . . . . . . . . . . . . . . . . . . . . . . . 10
9.1. Normative References . . . . . . . . . . . . . . . . . . 11
9.2. Informative References . . . . . . . . . . . . . . . . . 11
Appendix A. Capability Handshake Example . . . . . . . . . . . . 12
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 12
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/
features. This document highlights the differences of capabilities
from that of Mode of operation and explains the necessity of it.
Jadhav, et al. Expires October 18, 2020 [Page 2]
Internet-Draft RPL Capabilties April 2020
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.ietf-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
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.
Jadhav, et al. Expires October 18, 2020 [Page 3]
Internet-Draft RPL Capabilties April 2020
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).
3. Capabilities
Handling of Capabilities MUST be supported if the network uses MOPex
[I-D.ietf-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.
Jadhav, et al. Expires October 18, 2020 [Page 4]
Internet-Draft RPL Capabilties April 2020
3.1. Capability Categories
Capabilities can be divided into two broad categories:
Global Capabilities: These include the capabilities supported across
an RPL instance and are advertised by the Root of the DODAG. If a
node in the LLN doesn't support a particular 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 capabilities very specific to
a node in the LLN. Example of such capabilities are NBR Cache
information, Routing table information.
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.
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
Jadhav, et al. Expires October 18, 2020 [Page 5]
Internet-Draft RPL Capabilties April 2020
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
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.
Jadhav, et al. Expires October 18, 2020 [Page 6]
Internet-Draft RPL Capabilties April 2020
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].
Capabilities are used to indicate a feature that is supported by the
node. Capabilities are not meant for configuration management for
e.g., setting a threshold./>.
5. ROLL Capabilities
5.1. Capability Indicators
Capability Indicators indicates the capabilities supported by the
node in the form of simple flags. Capabilities who do not have
additional information to be specified could make use of these flags
to indicate their support.
5.1.1. Format of Capability Indicators
Jadhav, et al. Expires October 18, 2020 [Page 7]
Internet-Draft RPL Capabilties April 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type=0x01 |J|I|G|C|. . . .| Len=3 |. . . . . Indic|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|ators . . . . . . . . . . . .|T|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 4: Capability Indicators TLV
Flags: LRs MUST set it to 0. I bit will always be set to 0.
24-bit Indicators: Currently right most bit is used to indicate 'T'
bit indicating support for 6LoRH. All the unused Indicator bits MUST
be set to zero.
5.2. 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
Jadhav, et al. Expires October 18, 2020 [Page 8]
Internet-Draft RPL Capabilties April 2020
Routing resource capabablity sent in DIO message has link local scope
and it MUST not be forwarded.
5.2.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 | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Total Capacity |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 5: Routing Resource Capability TLV
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.
Resvd: 8-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.
6. Acknowledgements
Thanks to Georgios Papadopoulos, Li Zhao for early 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
Jadhav, et al. Expires October 18, 2020 [Page 9]
Internet-Draft RPL Capabilties April 2020
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
7.3. New Registry for Capabilities Indicators
IANA is requested to create a registry for the Capabilities
Indicators as described in Section 5.1 of this document. This
registry should be located in TODO. New Capabilities indicators may
be allocated only by an IETF review. Each value is tracked with the
following qualities:
o Flag
o Description
o Defining RFC
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
Jadhav, et al. Expires October 18, 2020 [Page 10]
Internet-Draft RPL Capabilties April 2020
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>.
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.
[I-D.ietf-roll-mopex]
Jadhav, R., Thubert, P., and M. Richardson, "Mode of
Operation extension", draft-ietf-roll-mopex-00 (work in
progress), April 2020.
[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>.
Jadhav, et al. Expires October 18, 2020 [Page 11]
Internet-Draft RPL Capabilties April 2020
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 6: 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
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
Jadhav, et al. Expires October 18, 2020 [Page 12]
Internet-Draft RPL Capabilties April 2020
Rabi Narayan Sahoo (editor)
Email: rabinarayans0828@gmail.com
Jadhav, et al. Expires October 18, 2020 [Page 13]