draft-ietf-roll-capabilities-04.txt		draft-ietf-roll-capabilities-05.txt
	ROLL R. Jadhav, Ed.		ROLL R. Jadhav, Ed.
	Internet-Draft Huawei		Internet-Draft Huawei
	Intended status: Standards Track P. Thubert		Intended status: Standards Track P. Thubert
	Expires: November 17, 2020 Cisco		Expires: November 22, 2020 Cisco
	M. Richardson		M. Richardson
	Sandelman Software Works		Sandelman Software Works
	R. Sahoo		R. Sahoo
	Juniper		Juniper
	May 16, 2020		May 21, 2020
	RPL Capabilities		RPL Capabilities
	draft-ietf-roll-capabilities-04		draft-ietf-roll-capabilities-05
	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 November 17, 2020.		This Internet-Draft will expire on November 22, 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 13 ¶		skipping to change at page 2, line 13 ¶
	include Simplified BSD License text as described in Section 4.e of		include Simplified BSD License text as described in Section 4.e of
	the Trust Legal Provisions and are provided without warranty as		the Trust Legal Provisions and are provided without warranty as
	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 existing RPL
	Configuration Option? . . . . . . . . . . . . . . . . . . 4		primitives? . . . . . . . . . . . . . . . . . . . . . . . 4
	3. Capabilities . . . . . . . . . . . . . . . . . . . . . . . . 4		3. Capabilities . . . . . . . . . . . . . . . . . . . . . . . . 4
	3.1. Capability Control Message Option . . . . . . . . . . . . 5		3.1. Capability Control Message Option . . . . . . . . . . . . 5
	3.2. Capabilities Handshake . . . . . . . . . . . . . . . . . 5		3.2. Capabilities Handshake . . . . . . . . . . . . . . . . . 5
	4. Guidelines for defining new capabilities . . . . . . . . . . 6		4. Guidelines for defining new capabilities . . . . . . . . . . 6
	4.1. Handling Capability flags . . . . . . . . . . . . . . . . 6		4.1. Handling Capability flags . . . . . . . . . . . . . . . . 6
	4.1.1. Rules to handle capabilities flag . . . . . . . . . . 6		4.1.1. Rules to handle capabilities flag . . . . . . . . . . 6
	5. Node Capabilities . . . . . . . . . . . . . . . . . . . . . . 6		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 . . . . . . . . . . . . . . . 7		5.2. Routing Resource Capability . . . . . . . . . . . . . . . 7
	skipping to change at page 2, line 46 ¶		skipping to change at page 2, line 46 ¶
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 11		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 nodes in the
	the network could inform its peers about its additional capabilities/		network could inform its peers about its additional capabilities.
	features. This document highlights the differences of capabilities		This document highlights the differences of capabilities from that of
	from that of Mode of operation and explains the necessity of it.		Mode of operation and explains the necessity of it.
	1.1. Requirements Language and Terminology		1.1. Requirements Language and Terminology
	The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",		The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
	"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this		"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
	document are to be interpreted as described in RFC 2119 [RFC2119].		document are to be interpreted as described in RFC 2119 [RFC2119].
	MOP: Mode of Operation. Identifies the mode of operation of the RPL		MOP: Mode of Operation. Identifies the MOP of the RPL Instance as
	Instance as administratively provisioned at and distributed by the		administratively provisioned at and distributed by the DODAG root.
	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 which might		Capabilities: Additional features or capabilities that are supported
	possibly be optional that are supported by the node.		by the node.
	DAO: DODAG Advertisement Object. An RPL message used to advertise		DAO: DODAG Advertisement Object. An RPL message used to advertise
	the target information in order to establish routing adjacencies.		the target information in order to establish routing adjacencies.
	DIO: DODAG Information Object. An RPL message initiated by the root		DIO: DODAG Information Object. An RPL message initiated by the root
	and is used to advertise the network configuration information.		and is used to advertise the network configuration information.
	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 which has target with lifetime 0.
	MOPex: MOP extension as defined in this document.
	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.
	skipping to change at page 4, line 26 ¶		skipping to change at page 4, line 26 ¶
	and the root within an RPL Instance.		and the root within an RPL Instance.
	REQ3: Capabilities handshake could be optionally added with existing		REQ3: Capabilities handshake could be optionally added with existing
	MOPs. Capabilities been optional in nature could be put to		MOPs. Capabilities been optional in nature could be put to
	use with existing MOPs. Capabilities and MOP-extension is		use with existing MOPs. Capabilities and MOP-extension is
	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.		REQ4: Capabilities could be explicitly queried.
	2.1. How are Capabilities different from MOP or DIO Configuration		2.1. How are Capabilities different from existing RPL primitives?
	Option?
	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 could not modify the values. 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 very rare. Capabilities,		Configuration Option are possible but are rare. Capabilities, on the
	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 as part of
	objective function which aids in node's rank calculation. A router		objective function which aids in node's rank calculation. A router
	may use capabilities carried in DIO message as additional metrics/		may use capabilities carried in DIO message as additional metrics/
	constraints. However, capabilities have a larger scope and may be		constraints. However, capabilities have a larger scope and may be
	carried in other messages other than DIO and can flow in both the		carried in other messages other than DIO and can flow in both the
	directions (upstream and downstream).		directions (upstream and downstream).
	3. Capabilities		3. Capabilities
	skipping to change at page 6, line 21 ¶		skipping to change at page 6, line 21 ¶
	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
	A node MUST drop or discard the message silently having an unknown		A node MUST drop or discard the message with an unknown capability
	capability with 'D' (discard) flag set.		with 'D' flag set. The message MUST be discarded silently.
	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		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.		capabilities MUST be copied downstream by the node even if the node
			does not understand the capability.
	4.1.1. Rules to handle capabilities flag		4.1.1. Rules to handle capabilities flag
	On receiving a capability it does not support, the node MUST check		On receiving a capability it does not support, the node MUST check
	the 'J' flag of the capability before joining the Instance. If the		the 'J' flag of the capability before joining the Instance. If the
	'J' flag is set then it can only join as a 6LN.		'J' flag is set then it can only join as a 6LN.
	If the node is operating as 6LR and subsequently it receives a		If the node is operating as 6LR and subsequently it receives a
	capability which it doesn't understand with 'J' flag set, then the		capability from its preferred parent which it does not understand
	node has to switch itself to 6LN mode. During switching the node		with 'J' flag set, then the node has to switch itself to 6LN mode.
	needs to inform its downstream peers of its changed status by sending		During switching the node needs to inform its downstream peers of its
	a DIO with infinite rank as mentioned in [RFC6550].		changed status by sending a DIO with infinite rank as mentioned in
			RFC6550. Alternatively, a node may decide to switch to another
			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.
	5. Node 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
	skipping to change at page 10, line 6 ¶		skipping to change at page 10, line 6 ¶
	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.
	[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-mopex]
	Thubert, P., Jadhav, R., and M. Gillmore, "Root initiated		Jadhav, R., Thubert, P., and M. Richardson, "Mode of
	routing state in RPL", draft-ietf-roll-dao-projection-10		Operation extension", draft-ietf-roll-mopex-00 (work in
	(work in progress), May 2020.		progress), April 2020.
	[I-D.thubert-roll-turnon-rfc8138]
	Thubert, P. and L. Zhao, "Configuration option for RFC
	8138", draft-thubert-roll-turnon-rfc8138-03 (work in
	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>.
	[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 10, line 40 ¶		skipping to change at page 10, line 35 ¶
	(6LoWPAN) Routing Header", RFC 8138, DOI 10.17487/RFC8138,		(6LoWPAN) Routing Header", RFC 8138, DOI 10.17487/RFC8138,
	April 2017, <https://www.rfc-editor.org/info/rfc8138>.		April 2017, <https://www.rfc-editor.org/info/rfc8138>.
	9.2. Informative References		9.2. Informative References
	[I-D.ietf-lwig-nbr-mgmt-policy]		[I-D.ietf-lwig-nbr-mgmt-policy]
	Jadhav, R., Sahoo, R., Duquennoy, S., and J. Eriksson,		Jadhav, R., Sahoo, R., Duquennoy, S., and J. Eriksson,
	"Neighbor Management Policy for 6LoWPAN", draft-ietf-lwig-		"Neighbor Management Policy for 6LoWPAN", draft-ietf-lwig-
	nbr-mgmt-policy-03 (work in progress), February 2019.		nbr-mgmt-policy-03 (work in progress), February 2019.
	[I-D.ietf-roll-mopex]		[I-D.ietf-roll-dao-projection]
	Jadhav, R., Thubert, P., and M. Richardson, "Mode of		Thubert, P., Jadhav, R., and M. Gillmore, "Root initiated
	Operation extension", draft-ietf-roll-mopex-00 (work in		routing state in RPL", draft-ietf-roll-dao-projection-10
	progress), April 2020.		(work in progress), May 2020.
			[I-D.thubert-roll-turnon-rfc8138]
			Thubert, P. and L. Zhao, "Configuration option for RFC
			8138", draft-thubert-roll-turnon-rfc8138-03 (work in
			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,
	<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. 18 change blocks.
	46 lines changed or deleted		42 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/