draft-ietf-roll-capabilities-00.txt		draft-ietf-roll-capabilities-01.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: August 13, 2020 Cisco		Expires: September 10, 2020 Cisco
	M. Richardson		M. Richardson
	Sandelman Software Works		Sandelman Software Works
	R. Sahoo, Ed.		R. Sahoo, Ed.
	February 10, 2020		March 9, 2020
	RPL Capabilities		RPL Capabilities
	draft-ietf-roll-capabilities-00		draft-ietf-roll-capabilities-01
	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 August 13, 2020.		This Internet-Draft will expire on September 10, 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 . . . . . . . . . . . . . . . . . . . . . . . . 4		3. Capabilities . . . . . . . . . . . . . . . . . . . . . . . . 5
	3.1. Capability Catagories . . . . . . . . . . . . . . . . . . 5		3.1. Capability Catagories . . . . . . . . . . . . . . . . . . 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
	3.4. ROLL Capabilities . . . . . . . . . . . . . . . . . . . . 6		4. Guidelines for defining new capabilities . . . . . . . . . . 7
	3.4.1. Projected Route Capability . . . . . . . . . . . . . 6		4.1. Handling Capability flags . . . . . . . . . . . . . . . . 7
	3.4.1.1. Format of Projected Route Capability . . . . . . 7		4.1.1. Rules to handle capabilities flag . . . . . . . . . . 7
	3.4.2. 6LoRH Capability . . . . . . . . . . . . . . . . . . 8		5. ROLL Capabilities . . . . . . . . . . . . . . . . . . . . . . 7
	3.4.2.1. Format of 6LoRH Capability . . . . . . . . . . . 9		5.1. Projected Route Capability (PRC) . . . . . . . . . . . . 8
	3.4.3. Routing Resource Capability . . . . . . . . . . . . . 9		5.1.1. Format of Projected Route Capability . . . . . . . . 8
	3.4.3.1. Format of Routing Resource Capability . . . . . . 10		5.2. 6LoRH Capability . . . . . . . . . . . . . . . . . . . . 9
	3.4.4. Neighbor Cache Capability . . . . . . . . . . . . . . 11		5.2.1. Format of 6LoRH Capability . . . . . . . . . . . . . 10
	3.4.4.1. Format of Neighbor Cache Capability . . . . . . . 12		5.3. Routing Resource Capability . . . . . . . . . . . . . . . 11
	4. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 12		5.3.1. Format of Routing Resource Capability . . . . . . . . 11
	5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12		5.4. Neighbor Cache Capability . . . . . . . . . . . . . . . . 12
	5.1. New option: Capabilities . . . . . . . . . . . . . . . . 12		5.4.1. Format of Neighbor Cache Capability . . . . . . . . . 13
	5.2. New Registry for Capabilities Flags . . . . . . . . . . . 12		6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 13
	6. Security Considerations . . . . . . . . . . . . . . . . . . . 12		7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13
	7. References . . . . . . . . . . . . . . . . . . . . . . . . . 13		7.1. New option: Capabilities . . . . . . . . . . . . . . . . 13
	7.1. Normative References . . . . . . . . . . . . . . . . . . 13		7.2. New Registry for Capabilities Flags . . . . . . . . . . . 13
	7.2. Informative References . . . . . . . . . . . . . . . . . 13		8. Security Considerations . . . . . . . . . . . . . . . . . . . 14
	Appendix A. Capability Handshake Example . . . . . . . . . . . . 14		9. References . . . . . . . . . . . . . . . . . . . . . . . . . 14
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 14		9.1. Normative References . . . . . . . . . . . . . . . . . . 14
			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 5, line 40 ¶		skipping to change at page 6, line 8 ¶
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	Figure 1: Capabilities Option		Figure 1: Capabilities Option
	Multiple capabilities could be sent in the same message. The length		Multiple capabilities could be sent in the same message. The length
	field allows the message parser to skip the capability TLV parsing.		field allows the message parser to skip the capability TLV parsing.
	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
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| CAPType |G|I|. . . . . .| CAPInfo(Opt)		| CAPType |J|I|G|.|.|.|.|.| CAPInfo(Opt)
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	Figure 2: Capabilities TLV		Figure 2: Capabilities TLV
	Every capability is identified by its type and it may have an		Every capability is identified by its type and it may have an
	optional Capability Info. Note that a given capability may or may		optional Capability Info. Note that a given capability may or may
	not be diseminated with additional information depending on the scope		not be diseminated with additional information depending on the scope
	of the capability indicated by the G bit. The first Bit of the		of the capability indicated by the I bit.
	CAPType indicates if the capability is mandatory or optional Value of
	1 indicates its a mandatory capability and 0 indicates its an		J = Join only as leaf if capability not understood
	optional capability
			I = Capability Info present
	G = If set indicates a Global Capability else its a local. For a		G = If set indicates a Global Capability else its a local. For a
	capability if it's mandatory and global bit is set then node those		capability if it's mandatory and global bit is set then node those
	either doesn't understand the capability or doesn't have this		either doesn't understand the capability or doesn't have this
	capability should not join the DODAG as a router. All the global		capability should not join the DODAG as a router. All the global
	capablities MUST be diseminated across the network.		capablities MUST be diseminated across the network. 6LRs in the
			network MUST copy the global capabilities in their DIOs.
	I = Cap Info present
	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
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| CAPLen | Cap Info(format decided by individual cap spec)		| CAPLen | Cap Info(format decided by individual cap spec)
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	Figure 3: Capabilities Info		Figure 3: Capabilities Info
	Capability Information provides additional information for the given		Capability Information provides additional information for the given
	skipping to change at page 6, line 43 ¶		skipping to change at page 7, line 12 ¶
	advertised by non-root nodes are strictly a subset of the		advertised by non-root nodes are strictly a subset of the
	capabilities advertised by the root.		capabilities advertised by the root.
	In storing MOP, the DAO message from the 6LR could contain multiple		In storing MOP, the DAO message from the 6LR could contain multiple
	target options because of the DAO-Aggregation. The targets of the		target options because of the DAO-Aggregation. The targets of the
	capabilities option are indicated by one or more Target options that		capabilities option are indicated by one or more Target options that
	precede the Capabilties Option. This handling is similar to the		precede the Capabilties Option. This handling is similar to the
	Transit Information Option as supported in Section 6.7.8. of		Transit Information Option as supported in Section 6.7.8. of
	[RFC6550].		[RFC6550].
	3.4. ROLL Capabilities		4. Guidelines for defining new capabilities
	3.4.1. Projected Route Capability		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.
			4.1. Handling Capability flags
			The 'G' (global) flag indicating global capability should be set only
			by the root. However, it is not mandatory for the root to set this
			flag for all capabilities it indicates. It should set this flag only
			for those capabilities which the 6LRs downstream must propagate
			further downstream.
			The 'I' (information) flag is set only when there is additional
			information to be set in context to the capability.
			The 'J' (join) flag can be set in context to a capability either by a
			6LR or the root. The 'J' flag indicates that if the capability is
			not supported by a node then it can join the instance only as a 6LN
			(or do not join as 6LR).
			The 'C' (copy) flag is set by the node indicating that the
			capabilities MUST be copied downstream by the node.
			4.1.1. Rules to handle capabilities flag
			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 which it doesn't 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].
			5. ROLL Capabilities
			5.1. Projected Route Capability (PRC)
	[I-D.ietf-roll-dao-projection] proposes mechanisms to compute and		[I-D.ietf-roll-dao-projection] proposes mechanisms to compute and
	install traffic engineered paths in the RPL network. It enables an		install traffic engineered paths in the RPL network. It enables an
	RPL Root to install and maintain Projected Routes based on requested		RPL Root to install and maintain Projected Routes based on requested
	path metric, within its DODAG, along with a selected set of nodes		path metric, within its DODAG, along with a selected set of nodes
	that may or may not include self, for a chosen duration. Projected		that may or may not include self, for a chosen duration. Projected
	Route Capability will be used to enable this TE path calculation.		Route Capability will be used to enable this TE path calculation.
	PRC will be an optional global capability. Any node that does not		PRC will be an optional global capability. Any node that does not
	understand or support the projected route functions can still act as		understand or support the projected route functions can still act as
	an LR.		an LR.
	skipping to change at page 7, line 34 ¶		skipping to change at page 8, line 41 ¶
	can be part of a storing or non-storing or both mode of projected		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.		routes. Here the PRC will be part of the DAO message.
	The capability will convey the below information. The PRC MUST have		The capability will convey the below information. The PRC MUST have
	either of the information or both depending upon the node type.If		either of the information or both depending upon the node type.If
	originator is BR, then both the information MUST be there.		originator is BR, then both the information MUST be there.
	I: Supports projected route for both storing and non-storing		I: Supports projected route for both storing and non-storing
	mode.		mode.
	II: List of supported path metrics that supported that can be used		II: List of supported path metrics that can be used to compute
	to compute projected routes		projected routes.
	III: [To Decide] Can we add the PCE address information to this?		III: [To Decide] Can we add the PCE address information to this?
	3.4.1.1. Format of Projected Route Capability		5.1.1. Format of Projected Route 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=0x01 |J|I|G|. . . . .| CAPLen | MOP | Resvd |
	| Type=0x01 |G|I|. . . . . .| CAPLen | MOP | Resvd |		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		| Routing Metric 1 | Routing Metric 1 |
	| Routing Metric 1 | Routing Metric 1 |		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		| Routing Metric n-1 | Routing Metric n |
	| Routing Metric n-1 | Routing Metric n |		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	Figure 4: Projected Route Capability TLV		Figure 4: Projected Route Capability TLV
	Type: 0x01.		Type: 0x01.
	Flags: DODAG root MUST set G bit to 1 plus LRs MUST set it to 0. I		Flags: DODAG root MUST set G bit to 1 plus LRs MUST set it to 0. I
	bit will always be set to 1.		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.
	MOP: 3-bit field indicating the mode of operation of projected route		MOP: 3-bit field indicating the mode of operation of projected route
	capability.		capability.
	Resvd: 5-bit unused fields.They MUST be initialized to zero by the		Resvd: 5-bit unused fields.They MUST be initialized to zero by the
	sender and MUST be ignored by the receiver.		sender and MUST be ignored by the receiver.
	Routing Merric: 16 bit unsigned integer represetning the the routing		Routing Metric: 16 bit unsigned integer represetning the routing
	metric to be used for TE path calculation. There can be n number of		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		such routing metric fields. These fileds are alowed with the PRC
	sent by the DODAG ROOT. LRs MUST not send routing metric information		sent by the DODAG ROOT. LRs MUST not send routing metric information
	with PRC.		with PRC.
	0 1		0 1
	0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6		0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| Type=0x01 | Resvd |		| Type=0x01 | Resvd |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	Figure 5: Routing Metric Information		Figure 5: Routing Metric Information
	3.4.2. 6LoRH Capability		5.2. 6LoRH Capability
	[RFC8138] introduces a new 6LoWPAN Routing Header (6LoRH) to carry		[RFC8138] introduces a new 6LoWPAN Routing Header (6LoRH) to carry
	IPv6 routing information. The 6LoRH may contain source routing		IPv6 routing information. The 6LoRH may contain source routing
	information such as a compressed form of SRH, and other sorts of		information such as a compressed form of SRH, and other sorts of
	routing information such as the RPI and IP-in-IP encapsulation		routing information such as the RPI and IP-in-IP encapsulation
	The transition to [RFC8138] in a network can only be done when all		The transition to [RFC8138] in a network can only be done when all
	nodes support the specification. In a mixed case with both		nodes support the specification. In a mixed case with both
	RFC8138-capable and non-capable nodes it would not be posssible to		RFC8138-capable and non-capable nodes it would not be posssible to
	take advantage of 6LoRH.[I-D.thubert-roll-turnon-rfc8138] defines a		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		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		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		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		6LoRH within its DODAG, all LRs in DODAG MUST inform their support of
	[RFC8138] by adding 6LoRH capability TLV to their advertised		[RFC8138] by adding 6LoRH capability TLV to their advertised
	capability control message option.		capability control message option.
	skipping to change at page 9, line 23 ¶		skipping to change at page 10, line 33 ¶
	support RFC 8138.So if DODAG is still not using 6LoRH, it MUST		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		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.		MUST deny the LR from joining the DODAG with proper error code.
	[TODO- Need to add new Error code].		[TODO- Need to add new Error code].
	6LoRH capability is an optional capability any node that doesn't		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		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		the RPL Configuration option is not set otherwise it MUST join the
	network as a leaf node.		network as a leaf node.
	3.4.2.1. Format of 6LoRH Capability		5.2.1. Format of 6LoRH 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=0x02 |G|I|. . . . . .| Reserved |		| Type=0x02 |J|I|G|. . . . .| Reserved |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	Figure 6: 6LoRH Capability TLV		Figure 6: 6LoRH Capability TLV
	Type: 0x02.		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		Reserved: 16-bit unsigned integer, they MUST be initialized to zero
	by the sender and MUST be ignored by the receiver..		by the sender and MUST be ignored by the receiver..
	3.4.3. Routing Resource Capability		5.3. 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 10, line 27 ¶		skipping to change at page 11, line 41 ¶
	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.
	3.4.3.1. Format of Routing Resource Capability		5.3.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 |G|I|. . . . . .| CAPLen | RT | Resvd |		| Type=0x03 |J|I|G|. . . . .| CAPLen | RT | Resvd |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| Total Capacity | Used Per | Threshold |		| Total Capacity | Used Per | Threshold |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	Figure 7: Routing Resource Capability TLV		Figure 7: 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.
	skipping to change at page 11, line 23 ¶		skipping to change at page 12, line 38 ¶
	percentage of routing table space currently in use.		percentage of routing table space currently in use.
	Threshold: 8 bit unsigned integer representing the maximum routing		Threshold: 8 bit unsigned integer representing the maximum routing
	table space that can be used. If the routing resource type is RT1		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		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		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		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		Percentage is greater than or equal to a threshold, PCE MUST
	recompute some projected routes by excluding this node.		recompute some projected routes by excluding this node.
	3.4.4. Neighbor Cache Capability		5.4. Neighbor Cache Capability
	A neighbor cache maintains neighboring one-hop connected nodes		A neighbor cache maintains neighboring one-hop connected nodes
	information such as MAC address, link-local IP address and other		information such as MAC address, link-local IP address and other
	reachability state information needed for layer two		reachability state information needed for layer two
	communication.Node density has direct implications on the neighbor		communication.Node density has direct implications on the neighbor
	cache. In the constrained network scenario the size of 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		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		able to store all the neighboring nodes in its cache and use
	replacement algorithms to evict some of the entries to accommodate		replacement algorithms to evict some of the entries to accommodate
	the new one. If the replaced neighbor has installed a DAO route on		the new one. If the replaced neighbor has installed a DAO route on
	skipping to change at page 12, line 5 ¶		skipping to change at page 13, line 16 ¶
	the availability of neighbor cache is not taken into consideration		the availability of neighbor cache is not taken into consideration
	while selecting the DAO parent set.		while selecting the DAO parent set.
	Neighbor Cache capability can be used by LR and BR to advertise their		Neighbor Cache capability can be used by LR and BR to advertise their
	neighbor cache size information. This capablity information has only		neighbor cache size information. This capablity information has only
	link scope and should not be advertised in the entire network.		link scope and should not be advertised in the entire network.
	[TODO-- As neighbor cache entries category is not yet standardized i		[TODO-- As neighbor cache entries category is not yet standardized i
	think we can't use it in capability. With categories format of the		think we can't use it in capability. With categories format of the
	TLV is going to chnage.]		TLV is going to chnage.]
	3.4.4.1. Format of Neighbor Cache Capability		5.4.1. Format of Neighbor Cache Capability
	4. Acknowledgements		6. Acknowledgements
	Thanks to Georgios Papadopoulos, Li Zhao for the review and feedback.		Thanks to Georgios Papadopoulos, Li Zhao for the review and feedback.
	5. IANA Considerations		7. IANA Considerations
	5.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 |
	+-------+--------------+---------------+		+-------+--------------+---------------+
	| TBD1 | Capabilities | This document |		| TBD1 | Capabilities | This document |
	+-------+--------------+---------------+		+-------+--------------+---------------+
	New options		New options
	5.2. New Registry for Capabilities Flags		7.2. New Registry for Capabilities Flags
	IANA is requested to create a registry for the Capabilities flags as		IANA is requested to create a registry for the Capabilities flags as
	described in Section 2.1 of this document. This registry should be		described in Section 2.1 of this document. This registry should be
	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
	6. 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
	mechanisms and thus are not visible to a malicious node.		mechanisms and thus are not visible to a malicious node.
	7. References		[TODO] implications of malicious attack involving setting the
			capability flags.
	7.1. Normative References		9. References
			9.1. Normative 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-dao-projection]		[I-D.ietf-roll-dao-projection]
	Thubert, P., Jadhav, R., and M. Gillmore, "Root initiated		Thubert, P., Jadhav, R., and M. Gillmore, "Root initiated
	routing state in RPL", draft-ietf-roll-dao-projection-09		routing state in RPL", draft-ietf-roll-dao-projection-09
	(work in progress), November 2019.		(work in progress), November 2019.
	skipping to change at page 13, line 41 ¶		skipping to change at page 15, line 10 ¶
	JP., and R. Alexander, "RPL: IPv6 Routing Protocol for		JP., and R. Alexander, "RPL: IPv6 Routing Protocol for
	Low-Power and Lossy Networks", RFC 6550,		Low-Power and Lossy Networks", RFC 6550,
	DOI 10.17487/RFC6550, March 2012,		DOI 10.17487/RFC6550, March 2012,
	<https://www.rfc-editor.org/info/rfc6550>.		<https://www.rfc-editor.org/info/rfc6550>.
	[RFC8138] Thubert, P., Ed., Bormann, C., Toutain, L., and R. Cragie,		[RFC8138] Thubert, P., Ed., Bormann, C., Toutain, L., and R. Cragie,
	"IPv6 over Low-Power Wireless Personal Area Network		"IPv6 over Low-Power Wireless Personal Area Network
	(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>.
	7.2. Informative References		9.2. Informative References
	[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
End of changes. 32 change blocks.
	80 lines changed or deleted		120 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/