RPL Mode of Operation extension
draft-rahul-mop-ext-00

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 August 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 the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.

Table of Contents

• 1. Introduction
• 1.1. Requirements Language and Terminology
• 2. Requirements for this document
• 3. Extended MOP Control Message Option
• 3.1. Final MOP
• 4. Capabilities
• 4.1. Capability Control Message Option
• 4.2. Capabilities Handshake
• 5. Implementations Consideration
• 6. Acknowledgements
• 7. IANA Considerations
• 8. Security Considerations
• 9. References
• 9.1. Normative References
• 9.2. Informative References
• Appendix A. Capability Handshake Example
• Authors' Addresses

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.

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.

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

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:

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

REQ3:

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.

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 MUST refer to the Extended MOP (MOPex) option in the DIO message. If the MOPex option is absent in the DIO whose MOP is 7, then the DIO message MUST be silently discarded.

        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.

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.

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

7. IANA Considerations

IANA is requested to allocate MOP field value 0x7 in the DIO base object defined in RPL [RFC6550] section 6.3.1 for MOP extension.

TODO

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.

9. References

9.1. Normative References

9.2. Informative References

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

Authors' Addresses