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/