draft-ietf-roll-capabilities-03.txt		draft-ietf-roll-capabilities-04.txt
	ROLL R. Jadhav, Ed.		ROLL R. Jadhav, Ed.
	Internet-Draft Huawei Tech		Internet-Draft Huawei
	Intended status: Standards Track P. Thubert		Intended status: Standards Track P. Thubert
	Expires: October 18, 2020 Cisco		Expires: November 17, 2020 Cisco
	M. Richardson		M. Richardson
	Sandelman Software Works		Sandelman Software Works
	R. Sahoo, Ed.		R. Sahoo
	April 16, 2020		Juniper
			May 16, 2020
	RPL Capabilities		RPL Capabilities
	draft-ietf-roll-capabilities-03		draft-ietf-roll-capabilities-04
	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 36 ¶
	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 October 18, 2020.		This Internet-Draft will expire on November 17, 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 16 ¶		skipping to change at page 2, line 16 ¶
	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 . . . . . . . . . . . . . . . . . . . . . . . . 4
	3.1. Capability Categories . . . . . . . . . . . . . . . . . . 5		3.1. Capability Control Message Option . . . . . . . . . . . . 5
	3.2. Capability Control Message Option . . . . . . . . . . . . 5		3.2. Capabilities Handshake . . . . . . . . . . . . . . . . . 5
	3.3. Capabilities Handshake . . . . . . . . . . . . . . . . . 6
	4. Guidelines for defining new capabilities . . . . . . . . . . 6		4. Guidelines for defining new capabilities . . . . . . . . . . 6
	4.1. Handling Capability flags . . . . . . . . . . . . . . . . 7		4.1. Handling Capability flags . . . . . . . . . . . . . . . . 6
	4.1.1. Rules to handle capabilities flag . . . . . . . . . . 7		4.1.1. Rules to handle capabilities flag . . . . . . . . . . 6
	5. ROLL Capabilities . . . . . . . . . . . . . . . . . . . . . . 7		5. Node Capabilities . . . . . . . . . . . . . . . . . . . . . . 6
	5.1. Capability Indicators . . . . . . . . . . . . . . . . . . 7		5.1. Capability Indicators . . . . . . . . . . . . . . . . . . 7
	5.1.1. Format of Capability Indicators . . . . . . . . . . . 7		5.1.1. Format of Capability Indicators . . . . . . . . . . . 7
	5.2. Routing Resource Capability . . . . . . . . . . . . . . . 8		5.2. Routing Resource Capability . . . . . . . . . . . . . . . 7
	5.2.1. Format of Routing Resource Capability . . . . . . . . 9		5.2.1. Format of Routing Resource Capability . . . . . . . . 8
	6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 9		6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 8
	7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9		7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8
	7.1. New option: Capabilities . . . . . . . . . . . . . . . . 9		7.1. New option: Capabilities . . . . . . . . . . . . . . . . 8
	7.2. New Registry for Capabilities Flags . . . . . . . . . . . 10		7.2. New Registry for Capabilities Flags . . . . . . . . . . . 9
	7.3. New Registry for Capabilities Indicators . . . . . . . . 10		7.3. New Registry for Capabilities Indicators . . . . . . . . 9
	8. Security Considerations . . . . . . . . . . . . . . . . . . . 10		8. Security Considerations . . . . . . . . . . . . . . . . . . . 9
	9. References . . . . . . . . . . . . . . . . . . . . . . . . . 10		9. References . . . . . . . . . . . . . . . . . . . . . . . . . 9
	9.1. Normative References . . . . . . . . . . . . . . . . . . 11		9.1. Normative References . . . . . . . . . . . . . . . . . . 10
	9.2. Informative References . . . . . . . . . . . . . . . . . 11		9.2. Informative References . . . . . . . . . . . . . . . . . 10
	Appendix A. Capability Handshake Example . . . . . . . . . . . . 12		Appendix A. Capability Handshake Example . . . . . . . . . . . . 11
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 12		Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 11
	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 5 ¶		skipping to change at page 5, line 5 ¶
	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.ietf-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 Categories		3.1. Capability Control Message Option
	Capabilities can be divided into two broad categories:
	Global Capabilities: These include the capabilities supported across
	an RPL instance and are advertised by the Root of the DODAG. If a
	node in the LLN doesn't support a particular global capability it may
	have to join the RPL instance as a leaf node, as indicated by that
	individual capability option. Example of such capabilities are
	Compression Methods Supported, Support for TE paths (P-DAO).
	Local Capabilities: It will include the capabilities very specific to
	a node in the LLN. Example of such capabilities are NBR Cache
	information, Routing table information.
	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
	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 |J|I|G|C|.|.|.|.| CAPInfo(Opt)		| CapType | Len |J|I|C| Flags | ...
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	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 I bit.		of the capability indicated by the I bit.
	J = Join only as leaf if capability not understood		Len: 8-bit unsigned integer, representing the length in octets of the
			TLV, not including the CapType, Length and Flags fields.
	I = Capability Info present
	C = Flag indicating that the capability MUST be copied in the
	downstream messages
	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
	either doesn't understand the capability or doesn't have this
	capability should not join the DODAG as a router. All the global
	capablities MUST be diseminated across the network. 6LRs in the
	network MUST copy the global capabilities in their DIOs.
	0 1 2 3		J = Join only as leaf if capability not understood.
	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)
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	Figure 3: Capabilities Info		I = Ignore the message if this capability is not understood.
	Capability Information provides additional information for the given		C = Flag indicating that the capability MUST be copied in the
	capability. The format of this field should be defined as part the		downstream message.
	individual capability specification and is beyond the scope of this
	document. This document provides a container format for carrying the
	capability and its context information.
	3.3. Capabilities Handshake		3.2. Capabilities Handshake
	The root node could advertise the set of capabilities it supports in		The root node could advertise the set of capabilities it supports in
	the DIO message. A node could take advantage of the knowledge that		the DIO message. A node could take advantage of the knowledge that
	the root supports a particular capability. Similarly a node could		the root supports a particular capability. Similarly a node could
	advertise its capabilities in the DAO message using the capability		advertise its capabilities in the DAO message using the capability
	control message option defined in this document. Capabilities		control message option defined in this document. Capabilities
	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 Capabilities 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].
	4. Guidelines for defining new capabilities		4. Guidelines for defining new capabilities
	This section provides guidelines/recommendations towards defining new		This section provides guidelines/recommendations towards defining new
	capabilities. Note that the capabilities might be carried as part of		capabilities. Note that the capabilities might be carried as part of
	the multicast messaging such as DIO and hence the set should be used		the multicast messaging such as DIO and hence the set should be used
	in restrictive manner as far as possible.		in restrictive manner as far as possible.
	4.1. Handling Capability flags		4.1. Handling Capability flags
	The 'G' (global) flag indicating global capability should be set only		A node MUST drop or discard the message silently having an unknown
	by the root. However, it is not mandatory for the root to set this		capability with 'D' (discard) flag set.
	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		The 'I' (information) flag is set only when there is additional
	information to be set in context to the capability.		information to be set in context to the capability.
	The 'J' (join) flag can be set in context to a capability either by a		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		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		not supported by a node then it can join the instance only as a 6LN
	(or do not join as 6LR).		(or do not join as 6LR).
	The 'C' (copy) flag is set by the node indicating that the		The 'C' (copy) flag is set by the node indicating that the
	skipping to change at page 7, line 37 ¶		skipping to change at page 6, line 48 ¶
	'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		Capabilities are used to indicate a feature that is supported by the
	node. Capabilities are not meant for configuration management for		node. Capabilities are not meant for configuration management for
	e.g., setting a threshold./>.		e.g., setting a threshold./>.
	5. ROLL Capabilities		5. Node Capabilities
	5.1. Capability Indicators		5.1. Capability Indicators
	Capability Indicators indicates the capabilities supported by the		Capability Indicators indicates the capabilities supported by the
	node in the form of simple flags. Capabilities who do not have		node in the form of simple flags. Capabilities who do not have
	additional information to be specified could make use of these flags		additional information to be specified could make use of these flags
	to indicate their support.		to indicate their support.
	5.1.1. Format of Capability Indicators		5.1.1. Format of Capability Indicators
	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
			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|. . . .| Len=3 |. . . . . Indic|		| CapType=0x01 | Len |J|I|C| Flags |T|..Indicators..
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	|ators . . . . . . . . . . . .|T|
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	Figure 4: Capability Indicators TLV		Figure 3: Capability Indicators TLV
	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.
	24-bit Indicators: Currently right most bit is used to indicate 'T'		T flag (Bit 1): Indicates whether the node supports 6LoRH [RFC8138].
	bit indicating support for 6LoRH. All the unused Indicator bits MUST
	be set to zero.
	5.2. 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
	network convergence time. Routing state replacement leads to		network convergence time. Routing state replacement leads to
	downward path downtime.		downward path downtime.
	One possible way to solve problems due to routing table size		One possible way to solve problems due to routing table size
	constraint is to use this information to add neighbors to the DAO		constraint is to use this information to add neighbors to the DAO
	parent set.Routing resource capability can be used by LR and BR to		parent set. Routing resource capability can be used by LR and BR to
	advertise their current routing table usage details in the network.		advertise their current routing table usage details in the network.
	LR or LNs in LLN can use this information in the selection of the DAO		LR or LNs in LLN can use this information in the selection of the DAO
	parent set. PCE can use this information to select intermediate		parent set. PCE can use this information to select intermediate
	routers for the projected routes. Routing Resource is an optional		routers for the projected routes. Routing Resource is an optional
	local capability.		capability.
	Routing reource capability TLV can occur multiple times in the
	capability control message option to advertise below possible routing
	table information.
	I: Master Routing Table Storing
	II: Storing mode P-DAO Table
	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. The 'C' bit of this capability MUST be
			set to 0.
	5.2.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 | Reserved |		| CapType=0x02 | Len=3 |J|I|C| Flags | Reserved |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| Total Capacity |		| Total Capacity |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	Figure 5: Routing Resource Capability TLV		Figure 4: Routing Resource Capability TLV
	Type: 0x03.		Type: 0x02.
	Flags: G bit MUST be set to 0. I bit will always be set to 1.		Flags: I bit MUST be set to 0. C bit MUST be set to 0.
	CAPLen: 8-bit unsigned integer, representing the length in octets of		Len: 8-bit unsigned integer, representing the length in octets of the
	the option, not including the Option Type and Length fields.		option, not including the Option Type and Length/flags fields.
	Resvd: 8-bit unused field. It MUST be initialized to zero by the		Resvd: 8-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 routing
	table size.		table size.
	6. Acknowledgements		6. Acknowledgements
	Thanks to Georgios Papadopoulos, Li Zhao for early review and		Thanks to Georgios Papadopoulos, Li Zhao for early review and
	feedback.		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 |
	+-------+--------------+---------------+		+-------+-----------------------------+---------------+
	| TBD1 | Capabilities | This document |		| 0x01 | Capability Indicators | This document |
	+-------+--------------+---------------+		| 0x02 | Routing Resource Capability | This document |
			+-------+-----------------------------+---------------+
	New options		New options
	7.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:
	skipping to change at page 11, line 8 ¶		skipping to change at page 10, line 8 ¶
	mechanisms and thus are not visible to a malicious node.		mechanisms and thus are not visible to a malicious node.
	[TODO] implications of malicious attack involving setting the		[TODO] implications of malicious attack involving setting the
	capability flags.		capability flags.
	9. References		9. References
	9.1. Normative References		9.1. Normative References
	[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-10
	(work in progress), November 2019.		(work in progress), May 2020.
	[I-D.thubert-roll-turnon-rfc8138]		[I-D.thubert-roll-turnon-rfc8138]
	Thubert, P. and L. Zhao, "Configuration option for RFC		Thubert, P. and L. Zhao, "Configuration option for RFC
	8138", draft-thubert-roll-turnon-rfc8138-03 (work in		8138", draft-thubert-roll-turnon-rfc8138-03 (work in
	progress), July 2019.		progress), July 2019.
	[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate		[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
	Requirement Levels", BCP 14, RFC 2119,		Requirement Levels", BCP 14, RFC 2119,
	DOI 10.17487/RFC2119, March 1997,		DOI 10.17487/RFC2119, March 1997,
	<https://www.rfc-editor.org/info/rfc2119>.		<https://www.rfc-editor.org/info/rfc2119>.
	skipping to change at page 12, line 22 ¶		skipping to change at page 11, 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 6: Capabilities Option		Figure 5: Capabilities Option
	Authors' Addresses		Authors' Addresses
	Rahul Arvind Jadhav (editor)		Rahul Arvind Jadhav (editor)
	Huawei Tech		Huawei
	Kundalahalli Village, Whitefield,		Kundalahalli Village, Whitefield,
	Bangalore, Karnataka 560037		Bangalore, Karnataka 560037
	India		India
	Phone: +91-080-49160700		Phone: +91-080-49160700
	Email: rahul.ietf@gmail.com		Email: rahul.ietf@gmail.com
	Pascal Thubert		Pascal Thubert
	Cisco Systems, Inc		Cisco Systems, Inc
	Building D		Building D
	skipping to change at page 13, line 4 ¶		skipping to change at page 12, line 4 ¶
	MOUGINS - Sophia Antipolis 06254		MOUGINS - Sophia Antipolis 06254
	France		France
	Phone: +33 497 23 26 34		Phone: +33 497 23 26 34
	Email: pthubert@cisco.com		Email: pthubert@cisco.com
	Michael Richardson		Michael Richardson
	Sandelman Software Works		Sandelman Software Works
	Email: mcr+ietf@sandelman.ca		Email: mcr+ietf@sandelman.ca
	Rabi Narayan Sahoo (editor)		Rabi Narayan Sahoo
			Juniper
	Email: rabinarayans0828@gmail.com		Email: rabinarayans0828@gmail.com
End of changes. 39 change blocks.
	114 lines changed or deleted		69 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/