Draft: draft-ietf-roll-capabilities

Commentary: Some questions are embedded as xml comments , have a look before blindly accepting the PR ! Best regards 
 My bad , I overlooked the grayed out XML comment tags and did n't realize there were questions in it . Have handled all the comments .
This document adds a notion of capabilities using which nodes in the
network could inform its peers about its additional capabilities.
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, through which a node in
the network could inform its peers about its additional capabilities.
This document highlights the differences between capabilities and
Mode of Operation and explains the necessity for the former.
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.
NPDAO: No-Path DAO.  A DAO message which has target with lifetime 0.
DAO: DODAG Advertisement Object.  A RPL (pronounced ripple) message
used to advertise the target information in order to establish
routing adjacencies.
DIO: DODAG Information Object.  A RPL message initiated by the root
and is used to advertise the network configuration information.
NPDAO: No-Path DAO.  A DAO message that contains a Transit
Information Option with lifetime equal to 0.
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 an RPL Control
Message Option as defined in Section 6.7 of RFC6550.
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.
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.
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 a RPL Control
Message Option as defined in Section 6.7 of RFC6550.
Capabilities handshake could be optionally added with existing
MOPs.  Capabilities, being optional in nature, could be put to use
with existing MOPs.  Capabilities and MOP-extension are mutually
independent i.e. a DIO can have a capabilities option, MOP-
extension option or both in the same message.
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).
RPL DIO message also carries routing metrics and constraints as
specified in RFC6551.  Metrics and constraints are used in addition
to an objective function to determine a 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 messages other than DIO and can flow in either
direction (upstream and downstream).
Multiple capabilities could be sent in the same message.  The length
field allows the message parser to skip the capability TLV parsing.
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.
Multiple capabilities can be sent in the same message.  The length
field allows the message parser to skip the capability TLV parsing.
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 disseminated with additional information depending on the
scope of the capability indicated by the I bit.
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 Capabilities Option.  This handling is similar to the
Transit Information Option as supported in Section 6.7.8. of RFC6550.
The root node can advertise the set of capabilities it supports in
the DIO message.  A node can take advantage of the knowledge that the
root supports a particular capability.  Similarly a node can
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 can 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 Capabilities Option.  This handling is similar to the
Transit Information Option as supported in Section 6.7.8. of RFC6550.
Nodes may be interested in knowing the capabilities of another node
before taking an action.  For e.g., Consider I-D.ietf-roll-dao-
projection, the Root may want to know the capabilities of the nodes
along a network segment before it initiates a projected DAO to
install the routes along that segment.
Caps can be carried in existing RPL Control messages as Control
Options, however Caps can also be queried explicitly.  This section
provides a way for a node to query capability set of another node.
The capability query and subsequent response messages are directly
addressed between the two peers.
One byte, Sequence number sent by the CAPQ sender which is
reflected back by the responder in the CAPS message.
CAPQ base object may be followed by one or more options.  The
Capability Type List Control Option cap-tlist is used to carry a set
of capability types to query about.
If the sender does not send cap-tlist option, this would indicate
that the node intends to query the capability type list cap-tlist
supported by the target node.
Nodes may be interested in knowing the capabilities of another node
before taking an action.  For example, consider I-D.ietf-roll-dao-
projection, in which the Root may want to know the capabilities of
the nodes along a network segment before it initiates a projected DAO
to install the routes along that segment.
Caps can be carried in existing RPL Control messages as Control
Options, however Caps can also be queried explicitly.  This section
provides a way for a node to query the capability set of another
node.  The capability query and subsequent response messages are
directly addressed between the two peers.
One byte, Sequence number sent by the CAPQ sender and reflected
back by the responder in the CAPS message.
The CAPQ base object may be followed by one or more options.  The
Capability Type List Control Option (see cap-tlist) is used to carry
a set of capability types to query about.
If the sender does not send a Capability Type List Control Option,
this indicates that the node intends to query the Capability Type
List supported by the target node.
If the CAPQ message does not contain any cap-tlist option then the
receiver MUST respond with the cap types it supports using cap-tlist.
If the capability set cannot be transmitted in a single message (for
e.g., because of MTU limitations) then multiple CAPS messages could
be used.  All the CAPS message MUST use the same CAPQSequence number
copied from the corresponding CAPQ message.
If the CAPQ message does not contain any Capability Type List option
then the receiver MUST respond with the cap types it supports using a
Capability Type List Option (see cap-tlist).
If the capability set cannot be transmitted in a single message (for
e.g., because of MTU limitations) then multiple CAPS messages could
be used.  All the CAPS messages MUST use the same CAPQSequence number
copied from the corresponding CAPQ message.
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.
A node MUST drop or discard the message with an unknown capability
with 'D' flag set.  The message MUST be discarded silently.
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
sparingly, as much as possible.
A node MUST drop or discard the message with an unknown capability
with the 'D' flag set.  The message MUST be discarded silently.
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 from its preferred parent which it does not 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.  Alternatively, a node may decide to switch to another
parent with compatible and known capabilities.
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.
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 from its preferred parent which it does not 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.  Alternatively, a node may decide to switch to another
parent with compatible and known capabilities.
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.
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.
Capability Indicators indicate the capabilities supported by the node
in the form of simple flags.  Capabilities that do not need
additional information to be specified can make use of these flags to
indicate their support.
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.
Storing Mode of Operation requires each intermediate router in the
LLN to maintain routing state information in the routing table.  LLN
routers typically operate with constraints on processing power,
memory, and energy (battery power).  Memory limits the size of
routing state 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.