Change:
splitup with mopex differencess with DIO config option, MOP and routing metrics/constraints (fixes for ) sections reliagnment refs updated
The draft should clarify the differences and clearly state when to use when citing examples.
handled in Section 2.1

Discussion:
<del> Mode of Operation extension and Capabilities draft-ietf-roll-mopex-cap-latest </del> <ins> RPL Capabilities draft-ietf-roll-capabilities-latest </ins> Abstract <del> 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. </del> <ins> This draft enables the discovery, advertisement and query of capabilities for RPL nodes. </ins> 1.

mandatory set of primitives to be supported by all the participating nodes. <del> 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 capabilities/features.  This document highlights the differences of capabilities from that of Mode of operation and explains the necessity of it. </del> <ins> 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. </ins> 1.1.

Instance as administratively provisioned at and distributed by the DODAG root. <del> MOPex: Extended MOP: This document extends the MOP values over a bigger range.  This extension of MOP is called MOPex. </del> <ins> MOPex: Extended MOP: As defined in [I-D.jadhav-roll-mopex]. </ins> Capabilities: Additional features or capabilities which might possibly be optional that are supported by the node.

MOPex: MOP extension as defined in this document. <ins> 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. </ins> This document uses terminology described in RFC6550.  For the sake of readability all the known relevant terms are repeated in this section. <ins> 1.2. 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. </ins> 2. Following are the requirements considered for this documents: <del> 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. </del> 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

independent i.e. a DIO can have a capabilities option, MOP- extension option or both in the same message. <del> 3. 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. </del> <ins> Capabilities could be explicitly queried. </ins> <del> 3.1. 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. </del> <ins> 2.1. </ins> <del> 3.2. </del> <ins> 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. </ins> <del> 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. </del> <ins> 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). </ins> <del> 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. </del> <ins> 3. </ins> <del> 4. </del> <ins> Handling of Capabilities MUST be supported if the network uses MOPex [I-D.jadhav-roll-mopex]. </ins> <del> 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. </del> <ins> 3.1. </ins> Multiple capabilities could be sent in the same message.  The length field allows the message parser to skip the capability TLV parsing.

document.  This document provides a container format for carrying the capability and its context information. <del> 4.2. </del> <ins> 3.2. </ins> The root node could advertise the set of capabilities it supports in the DIO message.  A node could take advantage of the knowledge that

This handling is similar to the Transit Information Option as supported in Section 6.7.8. of RFC6550. <del> 5. 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. 6.1. 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 6.2. Two new entries are required for new supporting new options "MOPex", "Capabilities" from the "RPL Control Message Options" space RFC6550. 6.3. 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: MOPex value </del> <ins> 4. </ins> <del> Description </del> <ins> 4.1. </ins> <del> Defining RFC </del> <ins> New entry is required for supporting new Capabilities option in the "RPL Control Message Options" space RFC6550. </ins> <del> 6.4. </del> <ins> 4.2. </ins> IANA is requested to create a registry for the Capabilities flags as described in cap-why of this document.  This registry should be

Defining RFC <del> 7. </del> <ins> 5. </ins> The options defined in this document are carried in the base message objects as defined in RFC6550.  The RPL control message options are