Draft: draft-ietf-roll-mopex-cap

Commentary: Modified Capabilities section . 
 - the complete file seems to be changed ! Is it because of the ^M issue ? Better you can close this PR and raise another one only with the changes . Thanks 
 Comments for the PR .
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 'I'
flag.
Note that capabilities and MOPex are mutually exclusive and it is
possible for an implementation to support either or both of the
options.
Global Capabilities: It will include the features and capability
supported across an RPL instance.  These capabilities can be
advertised by the Root or 6LRs of the DODAG.  If a Node in the LLN
doesn't support a paticular global capability it may have to join the
RPL instance as a leaf node, as indicated by that individual
capability option.  Example of such capabilities are Compression
Methods Supported, Support for TE paths (P-DAO).
Local Capabilities: It will include the cpabilities very specific to
a Node in the LLN.  Example of such capabilities are NBR Cache
information, Routing Table Information.
G = If set indicates a Global Capability/Feature else its a local.
For a capability if it's mandatory and global bit is set then node
thoes either doesn't understand the capability or doesn't have this
capability should not join the DODAG as LR.  All the global
capablities MUST be desiminated across the network.
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.
In storing MOP, the DAO message from the 6LR could contain multiple
target options beacuse of the DAO-Aggregation.  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.
I-D.ietf-roll-dao-projection proposes mechanisms to compute and
install traffic engineered paths in the RPL network.  It enables an
RPL Root to install and maintain Projected Routes based on requested
path metric, within its DODAG, along with a selected set of nodes
that may or may not include self, for a chosen duration.  Projected
Route Capability will be used to enable this TE path calculation.
PRC will be an optional global capability.  Any node that does not
understand or support the projected route functions can still act as
an LR.
The DODAG root will use projected routes capability to advertise the
support of projected routes with the possible mode of operations and
set of path metrics it can use to calculate a projected route.  DODAG
root will add the PRC to DIO message so that it can disseminate the
information in entire DODAG.  Router nodes in the LLN receiving DIOs
with PRC MUST forward the same into their sub-DODAG without any
change even though they don't understand or support the projected
route feature.LR will use the path metric information advertised by
the DODAG root to learn these metrics from the network and neighbors.
The same information they will use to advertise in the sibling
information option.  LR will also use these path metrics information
to request traffic-engineered routes optimizing a or set of specific
network metric(s).
LRs in the network will use this capability to inform the PCE if they
can be part of a storing or non-storing or both mode of projected
routes.  Here the PRC will be part of the DAO message.
The capability will convey the below information.  The PRC MUST have
either of the information or both depending upon the node type.If
originator is BR, then both the information MUST be there.
Supports projected route for both storing and non-storing mode.
Type: 0x01.
Flags: DODAG root MUST set G bit to 1 plus LRs MUST set it to 0.  I
bit will always be set to 1.
MOP: 3-bit field indicating the mode of operation of projected route
capability.
Routing Merric: 16 bit unsigned integer represetning the the routing
metric to be used for TE path calculation.  There can be n number of
such routing metric fields.  These fileds are alowed with the PRC
sent by the DODAG ROOT.  LRs MUST not send routing metric information
with PRC.
The transition to RFC8138 in a network can only be done when all
nodes support the specification.  In a mixed case with both
RFC8138-capable and non-capable nodes it would not be posssible to
take advantage of 6LoRH.I-D.thubert-roll-turnon-rfc8138 defines a
mechanism to control the use of 6LoRH in a DODAG by using "T" flag
bit in RPL configuration option.  To assist DODAG root to decide if
it has to set "T" flag bit in RPL Configuration Option to enable
6LoRH within its DODAG, all LRs in DODAG MUST inform their support of
RFC 8138 by adding 6LoRH capability TLV to their advertised
capability control message option.
DODAG root MUST use 6LoRH capability TLV to inform all the nodes in
the DODAG, that DODAG is RFC8138 compliance. 6LoRH is an optional
local capability.
Any LR joining the DODAG MUST add 6LoRH capability TLV to the
capability control message option in its DAO message to inform BR
that it supports RFC8138.If received DAO message doesn't have 6LoRH
capability TLV, DODAG Root MUST conclude the target node doesn't
support RFC 8138.So if DODAG is still not using 6LoRH, it MUST
refrain from using the compression and if it is already using it, it
MUST deny the LR from joining the DODAG with proper error code.
[TODO- Need to add new Error code].
6LoRH capability is an optional capability any node that doesn't
understand or support the 6LoRH can join the DODAG if the "T" flag in
the RPL Configuration option is not set otherwise it MUST join the
network as a leaf node.
Type: 0x02.
Flags: LRs MUST set it to 0.  I bit will always be set to 0.
Reserved: 16-bit unsigned integer, they MUST be initialized to zero
by the sender and MUST be ignored by the receiver..
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.
One possible way to solve problems due to routing table size
constraint is to use this information to add neighbors to the DAO
parent set.Routing resource capability can be used by LR and BR to
advertise their current routing table usage details in the network.
LR or LNs in LLN can use this information in the selection of the DAO
parent set.  PCE can use this information to select intermediate
routers for the projected routes.  Routing Resource is an optional
local capability.
Routing reource capability TLV can occur multiple times in the
capability control message option to advertise below possible routing
table information.
Routing resource capabablity sent in DIO message has link local scope
and it MUST not be forwarded.
Type: 0x03.
Flags: G bit MUST be set to 0.  I bit will always be set to 1.
RT: 3-bit field indicating the routing resource type.  This document
defines 3 routing resource type.
Total Capacity: 16 bit unsigned integer represetning the the routing
table size.
Percentage used: 8 bit unsigned integer represetning the the
percentage of routing table space currently in use.
Threshold: 8 bit unsigned integer represetning the maximum routing
table space that can be used.  If the routing resource type is RT1
and used Percentage is greater than or equal to a threshold, its
siblings MUST stop using it as the preferred parent or remove it from
the parent list.  If the routing resource type is RT2 or RT3 and used
Percentage is greater than or equal to a threshold, PCE MUST
recompute some projected routes by excluding this node.
A neighbor cache maintains neighboring one-hop connected nodes
information such as MAC address, link-local IP address and other
reachability state information needed for layer two
communication.Node density has direct implications on the neighbor
cache.  In the constrained network scenario the size of the neighbor
cache will be limited.  Thus there are chances that a node may not be
able to store all the neighboring nodes in its cache and use
replacement algorithms to evict some of the entries to accommodate
the new one.  If the replaced neighbor has installed a DAO route on
it then it can lead to packet loss or additional address resolution
message exchange.  To avoid unnecessary replacement of neighbor cache
entries neighbor cache management policy I-D.ietf-lwig-nbr-mgmt-
policy proposes a solution that will put a restriction on the
connectivity to immediate neighbor depending upon the type of
neighbor.  But this won't solve the problem unless until the
availability of neighbor cache is not taken into consideration while
selecting the DAO parent set.