draft-ietf-roll-capabilities-02.txt   draft-ietf-roll-capabilities-03.txt 
ROLL R. Jadhav, Ed. ROLL R. Jadhav, Ed.
Internet-Draft Huawei Tech Internet-Draft Huawei Tech
Intended status: Standards Track P. Thubert Intended status: Standards Track P. Thubert
Expires: September 12, 2020 Cisco Expires: October 18, 2020 Cisco
M. Richardson M. Richardson
Sandelman Software Works Sandelman Software Works
R. Sahoo, Ed. R. Sahoo, Ed.
March 11, 2020 April 16, 2020
RPL Capabilities RPL Capabilities
draft-ietf-roll-capabilities-02 draft-ietf-roll-capabilities-03
Abstract Abstract
This draft enables the discovery, advertisement and query of This draft enables the discovery, advertisement and query of
capabilities for RPL nodes. capabilities for RPL nodes.
Status of This Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
skipping to change at page 1, line 35 skipping to change at page 1, line 35
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/. Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on September 12, 2020. This Internet-Draft will expire on October 18, 2020.
Copyright Notice Copyright Notice
Copyright (c) 2020 IETF Trust and the persons identified as the Copyright (c) 2020 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(https://trustee.ietf.org/license-info) in effect on the date of (https://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
skipping to change at page 2, line 15 skipping to change at page 2, line 15
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
1.1. Requirements Language and Terminology . . . . . . . . . . 3 1.1. Requirements Language and Terminology . . . . . . . . . . 3
1.2. What are Capabilities? . . . . . . . . . . . . . . . . . 3 1.2. What are Capabilities? . . . . . . . . . . . . . . . . . 3
2. Requirements for this document . . . . . . . . . . . . . . . 4 2. Requirements for this document . . . . . . . . . . . . . . . 4
2.1. How are Capabilities different from MOP or DIO 2.1. How are Capabilities different from MOP or DIO
Configuration Option? . . . . . . . . . . . . . . . . . . 4 Configuration Option? . . . . . . . . . . . . . . . . . . 4
3. Capabilities . . . . . . . . . . . . . . . . . . . . . . . . 5 3. Capabilities . . . . . . . . . . . . . . . . . . . . . . . . 4
3.1. Capability Catagories . . . . . . . . . . . . . . . . . . 5 3.1. Capability Categories . . . . . . . . . . . . . . . . . . 5
3.2. Capability Control Message Option . . . . . . . . . . . . 5 3.2. Capability Control Message Option . . . . . . . . . . . . 5
3.3. Capabilities Handshake . . . . . . . . . . . . . . . . . 6 3.3. Capabilities Handshake . . . . . . . . . . . . . . . . . 6
4. Guidelines for defining new capabilities . . . . . . . . . . 7 4. Guidelines for defining new capabilities . . . . . . . . . . 6
4.1. Handling Capability flags . . . . . . . . . . . . . . . . 7 4.1. Handling Capability flags . . . . . . . . . . . . . . . . 7
4.1.1. Rules to handle capabilities flag . . . . . . . . . . 7 4.1.1. Rules to handle capabilities flag . . . . . . . . . . 7
5. ROLL Capabilities . . . . . . . . . . . . . . . . . . . . . . 8 5. ROLL Capabilities . . . . . . . . . . . . . . . . . . . . . . 7
5.1. Projected Route Capability (PRC) . . . . . . . . . . . . 8 5.1. Capability Indicators . . . . . . . . . . . . . . . . . . 7
5.1.1. Format of Projected Route Capability . . . . . . . . 9 5.1.1. Format of Capability Indicators . . . . . . . . . . . 7
5.2. 6LoRH Capability . . . . . . . . . . . . . . . . . . . . 9 5.2. Routing Resource Capability . . . . . . . . . . . . . . . 8
5.2.1. Format of 6LoRH Capability . . . . . . . . . . . . . 10 5.2.1. Format of Routing Resource Capability . . . . . . . . 9
5.3. Routing Resource Capability . . . . . . . . . . . . . . . 11 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 9
5.3.1. Format of Routing Resource Capability . . . . . . . . 11 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9
5.4. Neighbor Cache Capability . . . . . . . . . . . . . . . . 12 7.1. New option: Capabilities . . . . . . . . . . . . . . . . 9
5.4.1. Format of Neighbor Cache Capability . . . . . . . . . 13 7.2. New Registry for Capabilities Flags . . . . . . . . . . . 10
6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 13 7.3. New Registry for Capabilities Indicators . . . . . . . . 10
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13 8. Security Considerations . . . . . . . . . . . . . . . . . . . 10
7.1. New option: Capabilities . . . . . . . . . . . . . . . . 13 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 10
7.2. New Registry for Capabilities Flags . . . . . . . . . . . 13 9.1. Normative References . . . . . . . . . . . . . . . . . . 11
8. Security Considerations . . . . . . . . . . . . . . . . . . . 14 9.2. Informative References . . . . . . . . . . . . . . . . . 11
9. References . . . . . . . . . . . . . . . . . . . . . . . . . 14 Appendix A. Capability Handshake Example . . . . . . . . . . . . 12
9.1. Normative References . . . . . . . . . . . . . . . . . . 14 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 12
9.2. Informative References . . . . . . . . . . . . . . . . . 15
Appendix A. Capability Handshake Example . . . . . . . . . . . . 15
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 15
1. Introduction 1. Introduction
RPL [RFC6550] specifies a proactive distance-vector based routing RPL [RFC6550] specifies a proactive distance-vector based routing
scheme. The protocol creates a DAG-like structure which operates scheme. The protocol creates a DAG-like structure which operates
with a given "Mode of Operation" (MOP) determining the minimal and with a given "Mode of Operation" (MOP) determining the minimal and
mandatory set of primitives to be supported by all the participating mandatory set of primitives to be supported by all the participating
nodes. nodes.
This document adds a notion of capabilities using which the nodes in This document adds a notion of capabilities using which the nodes in
skipping to change at page 3, line 17 skipping to change at page 3, line 15
1.1. Requirements Language and Terminology 1.1. Requirements Language and Terminology
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC 2119 [RFC2119]. document are to be interpreted as described in RFC 2119 [RFC2119].
MOP: Mode of Operation. Identifies the mode of operation of the RPL MOP: Mode of Operation. Identifies the mode of operation of the RPL
Instance as administratively provisioned at and distributed by the Instance as administratively provisioned at and distributed by the
DODAG root. DODAG root.
MOPex: Extended MOP: As defined in [I-D.jadhav-roll-mopex]. MOPex: Extended MOP: As defined in [I-D.ietf-roll-mopex].
Capabilities: Additional features or capabilities which might Capabilities: Additional features or capabilities which might
possibly be optional that are supported by the node. possibly be optional that are supported by the node.
DAO: DODAG Advertisement Object. An RPL message used to advertise DAO: DODAG Advertisement Object. An RPL message used to advertise
the target information in order to establish routing adjacencies. the target information in order to establish routing adjacencies.
DIO: DODAG Information Object. An RPL message initiated by the root DIO: DODAG Information Object. An RPL message initiated by the root
and is used to advertise the network configuration information. and is used to advertise the network configuration information.
skipping to change at page 5, line 8 skipping to change at page 4, line 48
specified in [RFC6551]. Metrics and constraints are used as part of specified in [RFC6551]. Metrics and constraints are used as part of
objective function which aids in node's rank calculation. A router objective function which aids in node's rank calculation. A router
may use capabilities carried in DIO message as additional metrics/ may use capabilities carried in DIO message as additional metrics/
constraints. However, capabilities have a larger scope and may be constraints. However, capabilities have a larger scope and may be
carried in other messages other than DIO and can flow in both the carried in other messages other than DIO and can flow in both the
directions (upstream and downstream). directions (upstream and downstream).
3. Capabilities 3. Capabilities
Handling of Capabilities MUST be supported if the network uses MOPex Handling of Capabilities MUST be supported if the network uses MOPex
[I-D.jadhav-roll-mopex]. [I-D.ietf-roll-mopex].
Note that capabilities and MOPex are mutually exclusive and it is Note that capabilities and MOPex are mutually exclusive and it is
possible for an implementation to support either or both of the possible for an implementation to support either or both of the
options. options.
3.1. Capability Catagories 3.1. Capability Categories
Capabilities can be divided into two broad categories: Capabilities can be divided into two broad categories:
Global Capabilities: It will include the features and capability Global Capabilities: These include the capabilities supported across
supported across an RPL instance. These capabilities can be an RPL instance and are advertised by the Root of the DODAG. If a
advertised by the Root or 6LRs of the DODAG. If a Node in the LLN node in the LLN doesn't support a particular global capability it may
doesn't support a paticular global capability it may have to join the have to join the RPL instance as a leaf node, as indicated by that
RPL instance as a leaf node, as indicated by that individual individual capability option. Example of such capabilities are
capability option. Example of such capabilities are Compression Compression Methods Supported, Support for TE paths (P-DAO).
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.
Note that some capabilities can be either global or local depending Local Capabilities: It will include the capabilities very specific to
upon the context they are used ex.P-DAO [TODO: This is not clear] a node in the LLN. Example of such capabilities are NBR Cache
information, Routing table information.
3.2. Capability Control Message Option 3.2. Capability Control Message Option
0 1 2 3 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 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 | Option Length | Capabilities TLVs | Type = TODO | Option Length | Capabilities TLVs
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 1: Capabilities Option Figure 1: Capabilities Option
skipping to change at page 8, line 4 skipping to change at page 7, line 33
4.1.1. Rules to handle capabilities flag 4.1.1. Rules to handle capabilities flag
On receiving a capability it does not support, the node MUST check On receiving a capability it does not support, the node MUST check
the 'J' flag of the capability before joining the Instance. If the the 'J' flag of the capability before joining the Instance. If the
'J' flag is set then it can only join as a 6LN. 'J' flag is set then it can only join as a 6LN.
If the node is operating as 6LR and subsequently it receives a If the node is operating as 6LR and subsequently it receives a
capability which it doesn't understand with 'J' flag set, then the capability which it doesn't understand with 'J' flag set, then the
node has to switch itself to 6LN mode. During switching the node node has to switch itself to 6LN mode. During switching the node
needs to inform its downstream peers of its changed status by sending needs to inform its downstream peers of its changed status by sending
a DIO with infinite rank as mentioned in [RFC6550]. a DIO with infinite rank as mentioned in [RFC6550].
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./>.
5. ROLL Capabilities 5. ROLL Capabilities
5.1. Projected Route Capability (PRC) 5.1. Capability Indicators
[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.
I: Supports projected route for both storing and non-storing
mode.
II: List of supported path metrics that can be used to compute
projected routes.
III: [To Decide] Can we add the PCE address information to this?
5.1.1. Format of Projected Route Capability
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=0x01 |J|I|G|C|. . . .| CAPLen | MOP | Resvd |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Routing Metric 1 | Routing Metric 1 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Routing Metric n-1 | Routing Metric n |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 4: Projected Route Capability TLV
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.
CAPLen: 8-bit unsigned integer, representing the length in octets of
the option, not including the Option Type and Length fields.
MOP: 3-bit field indicating the mode of operation of projected route
capability.
Resvd: 5-bit unused fields.They MUST be initialized to zero by the
sender and MUST be ignored by the receiver.
Routing Metric: 16 bit unsigned integer representing 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.
0 1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type=0x01 | Resvd |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 5: Routing Metric Information
5.2. 6LoRH Capability
[RFC8138] introduces a new 6LoWPAN Routing Header (6LoRH) to carry
IPv6 routing information. The 6LoRH may contain source routing
information such as a compressed form of SRH, and other sorts of
routing information such as the RPI and IP-in-IP encapsulation
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
[RFC8138] 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.
5.2.1. Format of 6LoRH Capability 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.
5.1.1. Format of Capability Indicators
0 1 2 3 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 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=0x02 |J|I|G|C|. . . .| Reserved | | Type=0x01 |J|I|G|C|. . . .| Len=3 |. . . . . Indic|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|ators . . . . . . . . . . . .|T|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 6: 6LoRH Capability TLV Figure 4: Capability Indicators TLV
Type: 0x02.
Flags: LRs MUST set it to 0. I bit will always be set to 0. 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 24-bit Indicators: Currently right most bit is used to indicate 'T'
by the sender and MUST be ignored by the receiver.. bit indicating support for 6LoRH. All the unused Indicator bits MUST
be set to zero.
5.3. Routing Resource Capability 5.2. Routing Resource Capability
Storing mode of operation requires each intermediate router in the Storing mode of operation requires each intermediate router in the
LLN to maintain routing states' information in the routing table. LLN to maintain routing states' information in the routing table.
LLN routers typically operate with constraints on processing power, LLN routers typically operate with constraints on processing power,
memory, and energy (battery power). Memory limits the number of memory, and energy (battery power). Memory limits the number of
routing states an LR and BR can maintain. When the routing table 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 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 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 entry and add the new one. Rejection of DAO messages will lead to an
increase in DAO message transmission that impacts the energy and increase in DAO message transmission that impacts the energy and
skipping to change at page 11, line 37 skipping to change at page 9, line 4
Routing reource capability TLV can occur multiple times in the Routing reource capability TLV can occur multiple times in the
capability control message option to advertise below possible routing capability control message option to advertise below possible routing
table information. table information.
I: Master Routing Table Storing I: Master Routing Table Storing
II: Storing mode P-DAO Table II: Storing mode P-DAO Table
III: Non-Storing mode P-DAO III: Non-Storing mode P-DAO
Routing resource capabablity sent in DIO message has link local scope Routing resource capabablity sent in DIO message has link local scope
and it MUST not be forwarded. and it MUST not be forwarded.
5.3.1. Format of Routing Resource Capability 5.2.1. Format of Routing Resource Capability
0 1 2 3 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 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=0x03 |J|I|G|C|. . . .| CAPLen | RT | Resvd | | Type=0x03 |J|I|G|C|. . . .| CAPLen | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Total Capacity | Used Per | Threshold |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Total Capacity |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 7: Routing Resource Capability TLV Figure 5: Routing Resource Capability TLV
Type: 0x03. Type: 0x03.
Flags: G bit MUST be set to 0. I bit will always be set to 1. Flags: G bit MUST be set to 0. I bit will always be set to 1.
CAPLen: 8-bit unsigned integer, representing the length in octets of CAPLen: 8-bit unsigned integer, representing the length in octets of
the option, not including the Option Type and Length fields. the option, not including the Option Type and Length fields.
RT: 3-bit field indicating the routing resource type. This document Resvd: 8-bit unused field. It MUST be initialized to zero by the
defines 3 routing resource type.
I: Master Routing Table Storing(RT = 1)
II: Storing mode P-DAO Table(RT = 2)
III: Non-Storing mode P-DAO(RT = 3)
Resvd: 5-bit unused field. It MUST be initialized to zero by the
sender and MUST be ignored by the receiver. sender and MUST be ignored by the receiver.
Total Capacity: 16 bit unsigned integer representing the the routing Total Capacity: 16 bit unsigned integer representing the the routing
table size. table size.
Percentage used: 8 bit unsigned integer representing the the
percentage of routing table space currently in use.
Threshold: 8 bit unsigned integer representing 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.
5.4. Neighbor Cache Capability
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.
Neighbor Cache capability can be used by LR and BR to advertise their
neighbor cache size information. This capablity information has only
link scope and should not be advertised in the entire network.
[TODO-- As neighbor cache entries category is not yet standardized i
think we can't use it in capability. With categories format of the
TLV is going to chnage.]
5.4.1. Format of Neighbor Cache Capability
6. Acknowledgements 6. Acknowledgements
Thanks to Georgios Papadopoulos, Li Zhao for the review and feedback. Thanks to Georgios Papadopoulos, Li Zhao for early review and
feedback.
7. IANA Considerations 7. IANA Considerations
7.1. New option: Capabilities 7.1. New option: Capabilities
New entry is required for supporting new Capabilities option in the New entry is required for supporting new Capabilities option in the
"RPL Control Message Options" space [RFC6550]. "RPL Control Message Options" space [RFC6550].
+-------+--------------+---------------+ +-------+--------------+---------------+
| Value | Meaning | Reference | | Value | Meaning | Reference |
skipping to change at page 14, line 5 skipping to change at page 10, line 19
located in TODO. New Capabilities flags may be allocated only by an located in TODO. New Capabilities flags may be allocated only by an
IETF review. Currently no flags are defined by this document. Each IETF review. Currently no flags are defined by this document. Each
value is tracked with the following qualities: value is tracked with the following qualities:
o Flag o Flag
o Description o Description
o Defining RFC o Defining RFC
7.3. New Registry for Capabilities Indicators
IANA is requested to create a registry for the Capabilities
Indicators as described in Section 5.1 of this document. This
registry should be located in TODO. New Capabilities indicators may
be allocated only by an IETF review. Each value is tracked with the
following qualities:
o Flag
o Description
o Defining RFC
8. Security Considerations 8. Security Considerations
The options defined in this document are carried in the base message The options defined in this document are carried in the base message
objects as defined in [RFC6550]. The RPL control message options are objects as defined in [RFC6550]. The RPL control message options are
protected by the same security mechanisms that protect the base protected by the same security mechanisms that protect the base
messages. messages.
Capabilities flag can reveal that the node has been upgraded or is Capabilities flag can reveal that the node has been upgraded or is
running a old feature set. This document assumes that the base running a old feature set. This document assumes that the base
messages that carry these options are protected by RPL security messages that carry these options are protected by RPL security
skipping to change at page 15, line 12 skipping to change at page 11, line 40
(6LoWPAN) Routing Header", RFC 8138, DOI 10.17487/RFC8138, (6LoWPAN) Routing Header", RFC 8138, DOI 10.17487/RFC8138,
April 2017, <https://www.rfc-editor.org/info/rfc8138>. April 2017, <https://www.rfc-editor.org/info/rfc8138>.
9.2. Informative References 9.2. Informative References
[I-D.ietf-lwig-nbr-mgmt-policy] [I-D.ietf-lwig-nbr-mgmt-policy]
Jadhav, R., Sahoo, R., Duquennoy, S., and J. Eriksson, Jadhav, R., Sahoo, R., Duquennoy, S., and J. Eriksson,
"Neighbor Management Policy for 6LoWPAN", draft-ietf-lwig- "Neighbor Management Policy for 6LoWPAN", draft-ietf-lwig-
nbr-mgmt-policy-03 (work in progress), February 2019. nbr-mgmt-policy-03 (work in progress), February 2019.
[I-D.ietf-roll-mopex]
Jadhav, R., Thubert, P., and M. Richardson, "Mode of
Operation extension", draft-ietf-roll-mopex-00 (work in
progress), April 2020.
[RFC6551] Vasseur, JP., Ed., Kim, M., Ed., Pister, K., Dejean, N., [RFC6551] Vasseur, JP., Ed., Kim, M., Ed., Pister, K., Dejean, N.,
and D. Barthel, "Routing Metrics Used for Path Calculation and D. Barthel, "Routing Metrics Used for Path Calculation
in Low-Power and Lossy Networks", RFC 6551, in Low-Power and Lossy Networks", RFC 6551,
DOI 10.17487/RFC6551, March 2012, DOI 10.17487/RFC6551, March 2012,
<https://www.rfc-editor.org/info/rfc6551>. <https://www.rfc-editor.org/info/rfc6551>.
Appendix A. Capability Handshake Example Appendix A. Capability Handshake Example
Root 6LR 6LN Root 6LR 6LN
| | | | | |
skipping to change at page 15, line 35 skipping to change at page 12, line 22
| | | | | |
| | DAO(CS2) | | | DAO(CS2) |
| |<-----------| | |<-----------|
| DAO(CS2) | | | DAO(CS2) | |
|<------------| | |<------------| |
| | | | | |
CS: Capabilities Set CS: Capabilities Set
CS1: Capabilities set advertised by root CS1: Capabilities set advertised by root
CS2: Capabilities set advertised by node. CS2 is a subset of CS1. CS2: Capabilities set advertised by node. CS2 is a subset of CS1.
Figure 8: Capabilities Option Figure 6: Capabilities Option
Authors' Addresses Authors' Addresses
Rahul Arvind Jadhav (editor) Rahul Arvind Jadhav (editor)
Huawei Tech Huawei Tech
Kundalahalli Village, Whitefield, Kundalahalli Village, Whitefield,
Bangalore, Karnataka 560037 Bangalore, Karnataka 560037
India India
Phone: +91-080-49160700 Phone: +91-080-49160700
 End of changes. 32 change blocks. 
226 lines changed or deleted 80 lines changed or added

This html diff was produced by rfcdiff 1.47. The latest version is available from http://tools.ietf.org/tools/rfcdiff/