Internet DRAFT - draft-rahul-roll-mop-ext
draft-rahul-roll-mop-ext
ROLL R. Jadhav, Ed.
Internet-Draft Huawei Tech
Intended status: Standards Track P. Thubert
Expires: December 11, 2019 Cisco
June 9, 2019
RPL Mode of Operation extension
draft-rahul-roll-mop-ext-01
Abstract
RPL allows different mode of operations which allows nodes to have a
consensus on the basic primitives that must be supported to join the
network. The MOP field in RFC6550 is of 3 bits and is fast
depleting. This document extends the MOP field specification and
adds a notion of capabilities using which the nodes can further
advertise their support for, possibly optional, capabilities.
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 December 11, 2019.
Copyright Notice
Copyright (c) 2019 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 & Thubert Expires December 11, 2019 [Page 1]
Internet-Draft MOP extension June 2019
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
2. Requirements for this document . . . . . . . . . . . . . . . 3
3. Extended MOP Control Message Option . . . . . . . . . . . . . 4
3.1. Final MOP . . . . . . . . . . . . . . . . . . . . . . . . 4
3.2. Handling MOPex . . . . . . . . . . . . . . . . . . . . . 5
4. Capabilities . . . . . . . . . . . . . . . . . . . . . . . . 5
4.1. Capability Control Message Option . . . . . . . . . . . . 5
4.2. Capabilities Handshake . . . . . . . . . . . . . . . . . 5
5. Implementations Consideration . . . . . . . . . . . . . . . . 6
6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 6
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6
7.1. Mode of operation: MOPex . . . . . . . . . . . . . . . . 6
7.2. New options: MOPex and Capabilities . . . . . . . . . . . 7
7.3. New Registry for Extended-MOP-value . . . . . . . . . . . 7
7.4. New Registry for Capabilities Flags . . . . . . . . . . . 7
8. Security Considerations . . . . . . . . . . . . . . . . . . . 7
9. References . . . . . . . . . . . . . . . . . . . . . . . . . 8
9.1. Normative References . . . . . . . . . . . . . . . . . . 8
9.2. Informative References . . . . . . . . . . . . . . . . . 8
Appendix A. Capability Handshake Example . . . . . . . . . . . . 8
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 9
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.
MOP as per [RFC6550] is a 3-bit value carried in DIO messages and is
specific to the RPL Instance. The receipient of the DIO message can
join the specified network as a router only when it can support the
primitives as required by the mode of operation value. For example,
in case of MOP=3 (Storing MOP with multicast support) the nodes can
join the network as routers only when they can handle the DAO
advertisements from the peers and manage routing tables. The 3-bit
value is already exhausted and requires replenishment. This document
introduces a mechanism to extend mode of operation values.
This document further adds a notion of capabilities using which the
nodes in the network could inform its peers about its additional
Jadhav & Thubert Expires December 11, 2019 [Page 2]
Internet-Draft MOP extension June 2019
capabilities/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: This document extends the MOP values over a
bigger range. This extension of MOP is called 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.
This document uses terminology described in [RFC6550]. For the sake
of readability all the known relevant terms are repeated in this
section.
2. Requirements for this document
Following are the requirements considered for this documents:
REQ1: MOP extension. Current MOP of 3-bit is fast depleting. An
MOP extension needs to extend the possibility of adding new
MOPs in the future.
REQ2: 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.
Jadhav & Thubert Expires December 11, 2019 [Page 3]
Internet-Draft MOP extension June 2019
REQ3: Optional capabilities handshake. Capabilities are features,
possibly optional, which could be handshaked between the nodes
and the root within an RPL Instance.
REQ4: 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.
3. Extended MOP Control Message Option
This document reserves existing MOP value 7 to be used as an
extender. DIO messages with MOP value of 7 may refer to the Extended
MOP (MOPex) option in the DIO message.
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 | Extended-MOP-value |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 1: Extended MOP Option
3.1. Final MOP
An implementation supporting this document MUST calculate the final
MOP value as the sum of base MOP (as supported in Section 6.3.1. of
[RFC6550]) plus the MOPex value. Thus if the MOPex value is 0, it
means the final MOP is 7 since the base MOP in this case will be set
to 7.
+----------+-------+-----------+
| Base MOP | MOPex | Final MOP |
+----------+-------+-----------+
| 0 | NA | 0 |
| 1 | NA | 1 |
| : | : | : |
| 6 | NA | 6 |
| 7 | 0 | 7 |
| 7 | 1 | 8 |
| 7 | 2 | 9 |
| : | : | : |
+----------+-------+-----------+
Table 1: Final MOP calculation
Jadhav & Thubert Expires December 11, 2019 [Page 4]
Internet-Draft MOP extension June 2019
3.2. Handling MOPex
If the MOPex option is absent in the DIO whose MOP is 7, then the
MOPex value can be assumed to be zero (thus the final MOP in this
case will be 7). The MOPex value should be referred only if the base
MOP value is 7 and if the MOPex option is present. In case the base
MOP is 7 and if the MOPex option is present, then the implementation
MUST calculate the final MOP after considering the value in MOPex.
Note that [RFC6550] allows the node who does not support the received
MOP to still join the network as a leaf node. This semantic
continues to be true even in case of MOPex.
4. 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. The Mode of Operation field in
RPL mandates the operational requirement and does not allow loose
coupling of additional capabilities. This document defines
Capabilities as additional features 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.
Note that capabilities and MOPex are mutually exclusive and it is
possible for an implementation to support either or both of the
options.
4.1. 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 | Capabilities Flags |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 2: Capabilities Option
There are no capability flags defined by this document.
4.2. 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
Jadhav & Thubert Expires December 11, 2019 [Page 5]
Internet-Draft MOP extension June 2019
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. 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].
5. Implementations Consideration
The MOP-extension could cause 3-byte increase in memory in the RPL-
Instance. The MOP field in the RPL-Instance needs to be upgraded to
a 32 bit integer.
[RFC6550], it was possible to discard an unsupported DIO-MOP just by
inspecting the base message. With this document, the MOPex is a
different control message option and thus the discarding of the DIO
message could happen after inspecting the message options.
A node in storing MOP could independently construct a DAO message
with target options containing its child/sub-childs. Thus with
capabilities it needs to reconstruct the capabilities field as well.
This may result in increase in the memory requirement on per routing-
entry basis.
6. Acknowledgements
Thanks to Georgios Papadopoulos for the review and feedback.
7. IANA Considerations
7.1. Mode of operation: MOPex
IANA is requested to assign a new Mode of Operation, named "MOPex"
for MOP extension under the RPL registry. The value of 7 is to be
assigned from the "Mode of Operation" space [RFC6550]
+-------+-------------+---------------+
| Value | Description | Reference |
+-------+-------------+---------------+
| 7 | MOPex | This document |
+-------+-------------+---------------+
Mode of Operation
Jadhav & Thubert Expires December 11, 2019 [Page 6]
Internet-Draft MOP extension June 2019
7.2. New options: MOPex and Capabilities
Two new entries are required for new supporting new options "MOPex",
"Capabilities" from the "RPL Control Message Options" space
[RFC6550].
+-------+--------------+---------------+
| Value | Meaning | Reference |
+-------+--------------+---------------+
| TBD1 | MOPex | This document |
| TBD2 | Capabilities | This document |
+-------+--------------+---------------+
New options
7.3. New Registry for Extended-MOP-value
IANA is requested to create a registry for the extended-MOP-value
(MOPex). This registry should be located in TODO. New MOPex values
may be allocated only by an IETF review. Currently no values are
defined by this document. Each value is tracked with the following
qualities:
o MOPex value
o Description
o Defining RFC
7.4. New Registry for Capabilities Flags
IANA is requested to create a registry for the Capabilities flags as
described in Section 4 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
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
Jadhav & Thubert Expires December 11, 2019 [Page 7]
Internet-Draft MOP extension June 2019
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.
9. References
9.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>.
9.2. Informative References
[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>.
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 3: Capabilities Option
Jadhav & Thubert Expires December 11, 2019 [Page 8]
Internet-Draft MOP extension June 2019
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
Jadhav & Thubert Expires December 11, 2019 [Page 9]
