< draft-ietf-roll-capabilities-06.txt		draft-ietf-roll-capabilities-07.txt >
	ROLL R. Jadhav, Ed.		ROLL R. Jadhav, Ed.
	Internet-Draft Huawei		Internet-Draft
	Intended status: Standards Track P. Thubert		Intended status: Standards Track P. Thubert
	Expires: December 5, 2020 Cisco		Expires: March 21, 2021 Cisco
	M. Richardson		M. Richardson
	Sandelman Software Works		Sandelman Software Works
	R. Sahoo		R. Sahoo
	Juniper		Juniper
	June 3, 2020		September 17, 2020
	RPL Capabilities		RPL Capabilities
	draft-ietf-roll-capabilities-06		draft-ietf-roll-capabilities-07
	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 36 ¶		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 December 5, 2020.		This Internet-Draft will expire on March 21, 2021.
	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 3, line 13 ¶		skipping to change at page 3, line 13 ¶
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 16		Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 16
	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 nodes in the		This document adds a notion of capabilities, through which a node in
	network could inform its peers about its additional capabilities.		the network could inform its peers about its additional capabilities.
	This document highlights the differences of capabilities from that of		This document highlights the differences between capabilities and
	Mode of operation and explains the necessity of it.		Mode of Operation and explains the necessity for the former.
	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 MOP of the RPL Instance as		MOP: Mode of Operation. Identifies the MOP of the RPL Instance as
	administratively provisioned at and distributed by the DODAG root.		administratively provisioned at and distributed by the DODAG root.
	MOPex: Extended MOP: As defined in [I-D.ietf-roll-mopex].		MOPex: Extended MOP: As defined in [I-D.ietf-roll-mopex].
	Capabilities: Additional features or capabilities that are supported		Capabilities: Additional features or capabilities that are supported
	by the node.		by the node.
	Cap: Abbreviated term used for Capability.		Cap: Abbreviated term used for Capability.
	Caps: Abbreviated term used for Capabilities.		Caps: Abbreviated term used for Capabilities.
	DAO: DODAG Advertisement Object. An RPL message used to advertise		DAO: DODAG Advertisement Object. A RPL (pronounced ripple) message
	the target information in order to establish routing adjacencies.		used to advertise the target information in order to establish
			routing adjacencies.
	DIO: DODAG Information Object. An RPL message initiated by the root		DIO: DODAG Information Object. A RPL message initiated by the root
	and is used to advertise the network configuration information.		and is used to advertise the network configuration information.
	Current parent: Parent 6LR node before switching to the new path.		Current parent: Parent 6LR node before switching to the new path.
	NPDAO: No-Path DAO. A DAO message which has target with lifetime 0.		NPDAO: No-Path DAO. A DAO message that contains a Transit
			Information Option with lifetime equal to 0.
	Upstream path/direction: Path or direction from the node to the Root		Upstream path/direction: Path or direction from the node to the Root
	in a DAG.		in a DAG.
	Downstream path/direction: Path or direction to the node from the		Downstream path/direction: Path or direction to the node from the
	Root in a DAG.		Root in a DAG.
	This document uses terminology described in [RFC6550]. For the sake		This document uses terminology described in [RFC6550]. For the sake
	of readability all the known relevant terms are repeated in this		of readability all the known relevant terms are repeated in this
	section.		section.
	1.2. What are Capabilities?		1.2. What are Capabilities?
	Currently RPL specification does not have a mechanism whereby a node		Currently RPL specification does not have a mechanism whereby a node
	can signal the set of features that are available on its end. Such a		can signal the set of features that are available on its end. Such a
	mechanism could help the root to advertise its capabilities and in		mechanism could help the root to advertise its capabilities and in
	response also determine some advanced information about the		response also determine some advanced information about the
	capabilities of the joining nodes. This document defines		capabilities of the joining nodes. This document defines
	Capabilities which could be supported by the nodes and handshaked as		Capabilities which could be supported by the nodes and handshaked as
	part of RPL signaling. Capabilities are embedded as an RPL Control		part of RPL signaling. Capabilities are embedded as a RPL Control
	Message Option as defined in Section 6.7 of [RFC6550].		Message Option as defined in Section 6.7 of [RFC6550].
	2. Requirements for this document		2. Requirements for this document
	Following are the requirements considered for this documents:		Following are the requirements considered for this documents:
	REQ1: Backwards compatibility. The new options and new fields in		REQ1: Optional capabilities handshake. Capabilities are features,
	the DIO message should be backward compatible i.e. if there
	are nodes which support old MOPs they could still operate in
	their own instances.
	REQ2: Optional capabilities handshake. Capabilities are features,
	possibly optional, which could be handshaked between the nodes		possibly optional, which could be handshaked between the nodes
	and the root within an RPL Instance.		and the root within an RPL Instance.
	REQ3: Capabilities handshake could be optionally added with existing		REQ2: Capabilities handshake could be optionally added with existing
	MOPs. Capabilities been optional in nature could be put to		MOPs. Capabilities, being optional in nature, could be put to
	use with existing MOPs. Capabilities and MOP-extension is		use with existing MOPs. Capabilities and MOP-extension are
	mutually independent i.e. a DIO can have a capabilities		mutually independent i.e. a DIO can have a capabilities
	option, MOP-extension option or both in the same message.		option, MOP-extension option or both in the same message.
	REQ4: Capabilities could be explicitly queried.		REQ3: Capabilities could be explicitly queried.
	2.1. How are Capabilities different from existing RPL primitives?		2.1. How are Capabilities different from existing RPL primitives?
	The Mode of Operation (MOP) field in RPL mandates the operational		The Mode of Operation (MOP) field in RPL mandates the operational
	requirement for the nodes joining as routers. MOP and DIO		requirement for the nodes joining as routers. MOP and DIO
	Configuration Option is strictly controlled by the Root node in RPL.		Configuration Option is strictly controlled by the Root node in RPL.
	Intermediate 6LRs cannot modify these fields. Also, the MOP never		Intermediate 6LRs cannot modify these fields. Also, the MOP never
	changes for the lifetime of the RPL Instance. Changes in DIO		changes for the lifetime of the RPL Instance. Changes in DIO
	Configuration Option are possible but are rare. Capabilities, on the		Configuration Option are possible but are rare. Capabilities, on the
	other hand, might change more dynamically.		other hand, might change more dynamically.
	RPL DIO message also carries routing metrics and constraints as		RPL DIO message also carries routing metrics and constraints as
	specified in [RFC6551]. Metrics and constraints are used as part of		specified in [RFC6551]. Metrics and constraints are used in addition
	objective function which aids in node's rank calculation. A router		to an objective function to determine a node's rank calculation. A
	may use capabilities carried in DIO message as additional metrics/		router may use capabilities carried in DIO message as additional
	constraints. However, capabilities have a larger scope and may be		metrics/constraints. However, capabilities have a larger scope and
	carried in other messages other than DIO and can flow in both the		may be carried in messages other than DIO and can flow in either
	directions (upstream and downstream).		direction (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.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 Control Message Option		3.1. 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 can 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 | Len |J|I|C| Flags | ...		| 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 disseminated with additional information depending on the
	of the capability indicated by the I bit.		scope of the capability indicated by the I bit.
	Len: 8-bit unsigned integer, representing the length in octets of the		Len: 8-bit unsigned integer, representing the length in octets of the
	TLV, not including the CapType, Length and Flags fields.		TLV, not including the CapType, Length and Flags fields.
	J = Join only as leaf if capability not understood.		J = Join only as leaf if capability not understood.
	I = Ignore the message if this capability is not understood.		I = Ignore the message if this capability is not understood.
	C = Flag indicating that the capability MUST be copied in the		C = Flag indicating that the capability MUST be copied in the
	downstream message.		downstream message.
	3.2. Capabilities Handshake		3.2. Capabilities Handshake
	The root node could advertise the set of capabilities it supports in		The root node can 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 can take advantage of the knowledge that the
	the root supports a particular capability. Similarly a node could		root supports a particular capability. Similarly a node can
	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 can 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 Capabilities 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. Querying Capabilities		4. Querying Capabilities
	Nodes may be interested in knowing the capabilities of another node		Nodes may be interested in knowing the capabilities of another node
	before taking an action. For e.g., Consider		before taking an action. For example, consider
	[I-D.ietf-roll-dao-projection], the Root may want to know the		[I-D.ietf-roll-dao-projection], in which the Root may want to know
	capabilities of the nodes along a network segment before it initiates		the capabilities of the nodes along a network segment before it
	a projected DAO to install the routes along that segment.		initiates a projected DAO to install the routes along that segment.
	Caps can be carried in existing RPL Control messages as Control		Caps can be carried in existing RPL Control messages as Control
	Options, however Caps can also be queried explicitly. This section		Options, however Caps can also be queried explicitly. This section
	provides a way for a node to query capability set of another node.		provides a way for a node to query the capability set of another
	The capability query and subsequent response messages are directly		node. The capability query and subsequent response messages are
	addressed between the two peers.		directly addressed between the two peers.
	4.1. Capability Query (CAPQ)		4.1. Capability Query (CAPQ)
	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
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| RPLInstanceID | Flags | reserved | CAPQSequence |		| RPLInstanceID | Flags | reserved | CAPQSequence |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| Option(s)...		| Option(s)...
	+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+
	Figure 3: CAPQ base object		Figure 3: CAPQ base object
	CAPQSequence: One byte, Sequence number sent by the CAPQ sender		CAPQSequence: One byte, Sequence number sent by the CAPQ sender and
	which is reflected back by the responder in the CAPS message.		reflected back by the responder in the CAPS message.
	Flags: One byte, set to zero by sender, ignored by receiver.		Flags: One byte, set to zero by sender, ignored by receiver.
	reserved: One byte, set to zero by sender, ignored by receiver.		reserved: One byte, set to zero by sender, ignored by receiver.
	CAPQ base object may be followed by one or more options. The		The CAPQ base object may be followed by one or more options. The
	Capability Type List Control Option Figure 4 is used to carry a set		Capability Type List Control Option (see Figure 4) is used to carry a
	of capability types to query about.		set of capability types to query about.
	If the sender does not send Figure 4 option, this would indicate that		If the sender does not send a Capability Type List Control Option,
	the node intends to query the capability type list Figure 4 supported		this indicates that the node intends to query the Capability Type
	by the target node.		List supported by the target node.
	4.1.1. Capability Type List Control Option		4.1.1. Capability Type List Control 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 | CapType1 | CapType2 |		| Type = TODO | Option Length | CapType1 | CapType2 |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| CapType3 | .....		| CapType3 | .....
	+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+
	skipping to change at page 8, line 11 ¶		skipping to change at page 8, line 9 ¶
	Figure 5: CAPS base object		Figure 5: CAPS base object
	Flags: One byte, set to zero by sender, ignored by receiver.		Flags: One byte, set to zero by sender, ignored by receiver.
	reserved: One byte, set to zero by sender, ignored by receiver.		reserved: One byte, set to zero by sender, ignored by receiver.
	CAPQSequence: One byte, Sequence number copied from CAPQSequence		CAPQSequence: One byte, Sequence number copied from CAPQSequence
	received in the CAPQ message.		received in the CAPQ message.
	CAPS message SHOULD contain the capability set Figure 1 queried by		CAPS message SHOULD contain the capability set Figure 1 queried by
	the CAPQ sender. If the target node does not support subset of the		the CAPQ sender. If the target node does not support a subset of the
	queried capabilities then the Figure 4 option with the unsupported		queried capabilities then the Capability Type List with the
	cap-types SHOULD be sent back indicating the queried capabilities		unsupported cap-types SHOULD be sent back indicating the queried
	not-supported by the target node. For an example, check Appendix A.3		capabilities not-supported by the target node. For an example, check
			Appendix A.3
	If the CAPQ message does not contain any Figure 4 option then the		If the CAPQ message does not contain any Capability Type List option
	receiver MUST respond with the cap types it supports using Figure 4.		then the receiver MUST respond with the cap types it supports using a
			Capability Type List Option (see Figure 4).
	If the capability set cannot be transmitted in a single message (for		If the capability set cannot be transmitted in a single message (for
	e.g., because of MTU limitations) then multiple CAPS messages could		e.g., because of MTU limitations) then multiple CAPS messages could
	be used. All the CAPS message MUST use the same CAPQSequence number		be used. All the CAPS messages MUST use the same CAPQSequence number
	copied from the corresponding CAPQ message.		copied from the corresponding CAPQ message.
	4.2.1. Secure CAPS		4.2.1. Secure CAPS
	A Secure CAPS message follows the format in [RFC6550] Figure 7, where		A Secure CAPS message follows the format in [RFC6550] Figure 7, where
	the base message format is the CAPS message shown in Figure 5.		the base message format is the CAPS message shown in Figure 5.
	5. Guidelines for defining new capabilities		5. 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.		sparingly, as much as possible.
	5.1. Handling Capability flags		5.1. Handling Capability flags
	A node MUST drop or discard the message with an unknown capability		A node MUST drop or discard the message with an unknown capability
	with 'D' flag set. The message MUST be discarded silently.		with the 'D' flag set. The message MUST be discarded silently.
	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
	capabilities MUST be copied downstream by the node even if the node		capabilities MUST be copied downstream by the node even if the node
	does not understand the capability.		does not understand the capability.
	5.1.1. Rules to handle capabilities flag		5.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 from its preferred parent which it does not understand		capability from its preferred parent which it does not understand
	with 'J' flag set, then the node has to switch itself to 6LN mode.		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		During switching, the node needs to inform its downstream peers of
	changed status by sending a DIO with infinite rank as mentioned in		its changed status by sending a DIO with infinite rank as mentioned
	RFC6550. Alternatively, a node may decide to switch to another		in RFC6550. Alternatively, a node may decide to switch to another
	parent with compatible and known capabilities.		parent with compatible and known capabilities.
	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.
	6. Node Capabilities		6. Node Capabilities
	6.1. Capability Indicators		6.1. Capability Indicators
	Capability Indicators indicates the capabilities supported by the		Capability Indicators indicate the capabilities supported by the node
	node in the form of simple flags. Capabilities who do not have		in the form of simple flags. Capabilities that do not need
	additional information to be specified could make use of these flags		additional information to be specified can make use of these flags to
	to indicate their support.		indicate their support.
	6.1.1. Format of Capability Indicators		6.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
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| CapType=0x01 | Len |J|I|C| Flags |T|..Indicators..		| CapType=0x01 | Len |J|I|C| Flags |T|..Indicators..
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	Figure 6: Capability Indicators TLV		Figure 6: 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.
	T flag (Bit 1): Indicates whether the node supports 6LoRH [RFC8138].		T flag (Bit 1): Indicates whether the node supports 6LoRH [RFC8138].
	6.2. Routing Resource Capability		6.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 state information in the routing table. LLN
	LLN routers typically operate with constraints on processing power,		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 size of
	routing states an LR and BR can maintain. When the routing table of		routing state 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
	skipping to change at page 13, line 27 ¶		skipping to change at page 13, line 27 ¶
	[TODO] implications of malicious attack involving setting the		[TODO] implications of malicious attack involving setting the
	capability flags.		capability flags.
	10. References		10. References
	10.1. Normative References		10.1. Normative References
	[I-D.ietf-roll-mopex]		[I-D.ietf-roll-mopex]
	Jadhav, R., Thubert, P., and M. Richardson, "Mode of		Jadhav, R., Thubert, P., and M. Richardson, "Mode of
	Operation extension", draft-ietf-roll-mopex-00 (work in		Operation extension", draft-ietf-roll-mopex-01 (work in
	progress), April 2020.		progress), June 2020.
	[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>.
	[RFC6550] Winter, T., Ed., Thubert, P., Ed., Brandt, A., Hui, J.,		[RFC6550] Winter, T., Ed., Thubert, P., Ed., Brandt, A., Hui, J.,
	Kelsey, R., Levis, P., Pister, K., Struik, R., Vasseur,		Kelsey, R., Levis, P., Pister, K., Struik, R., Vasseur,
	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,
	skipping to change at page 14, line 12 ¶		skipping to change at page 14, line 12 ¶
	10.2. Informative References		10.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-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-10		routing state in RPL", draft-ietf-roll-dao-projection-11
	(work in progress), May 2020.		(work in progress), September 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.
	[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,
	skipping to change at page 16, line 8 ¶		skipping to change at page 16, line 8 ¶
	Assume that Root queries for capabilities {Cap1, Cap2, Cap3, Cap4}		Assume that Root queries for capabilities {Cap1, Cap2, Cap3, Cap4}
	from the peer node. However the peer node does not support or does		from the peer node. However the peer node does not support or does
	not understand capability {cap1, cap4}. In this case the peer node		not understand capability {cap1, cap4}. In this case the peer node
	will respond back with value of Cap2 and Cap3 (which it understands)		will respond back with value of Cap2 and Cap3 (which it understands)
	and set the CapTypeList option with {Cap1, Cap4} type.		and set the CapTypeList option with {Cap1, Cap4} type.
	Authors' Addresses		Authors' Addresses
	Rahul Arvind Jadhav (editor)		Rahul Arvind Jadhav (editor)
	Huawei		Marathahalli
	Kundalahalli Village, Whitefield,
	Bangalore, Karnataka 560037		Bangalore, Karnataka 560037
	India		India
	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
	45 Allee des Ormes - BP1200		45 Allee des Ormes - BP1200
	MOUGINS - Sophia Antipolis 06254		MOUGINS - Sophia Antipolis 06254
	France		France
	Phone: +33 497 23 26 34		Phone: +33 497 23 26 34
End of changes. 35 change blocks.
	80 lines changed or deleted		77 lines changed or added
This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/