Draft: draft-ietf-roll-mopex-cap

Commentary: 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
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.
This draft enables the discovery, advertisement and query of
capabilities for RPL 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
capabilities/features.  This document highlights the differences of
capabilities from that of Mode of operation and explains the
necessity of it.
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.
MOPex: Extended MOP: This document extends the MOP values over a
bigger range.  This extension of MOP is called MOPex.
MOPex: Extended MOP: As defined in [I-D.jadhav-roll-mopex].
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.
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.
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.
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.
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.
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.
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.
Capabilities could be explicitly queried.
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).
Handling of Capabilities MUST be supported if the network uses MOPex
[I-D.jadhav-roll-mopex].
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.
Two new entries are required for new supporting new options "MOPex",
"Capabilities" from the "RPL Control Message Options" space RFC6550.
New entry is required for supporting new Capabilities option in the
"RPL Control Message Options" space RFC6550.