< draft-ietf-roll-nsa-extension-00.txt		draft-ietf-roll-nsa-extension-01.txt >
	ROLL R. Koutsiamanis, Ed.		ROLL R. Koutsiamanis, Ed.
	Internet-Draft G. Papadopoulos		Internet-Draft G. Papadopoulos
	Intended status: Standards Track N. Montavont		Intended status: Standards Track N. Montavont
	Expires: June 21, 2019 IMT Atlantique		Expires: September 12, 2019 IMT Atlantique
	P. Thubert		P. Thubert
	Cisco		Cisco
	December 18, 2018		March 11, 2019
	RPL DAG Metric Container Node State and Attribute object type extension		RPL DAG Metric Container Node State and Attribute object type extension
	draft-ietf-roll-nsa-extension-00		draft-ietf-roll-nsa-extension-01
	Abstract		Abstract
	Implementing 6TiSCH Packet Replication and Elimination from / to the		Implementing Packet Replication and Elimination from / to the RPL
	RPL root requires the ability to forward copies of packets over		root requires the ability to forward copies of packets over different
	different paths via different RPL parents. Selecting the appropriate		paths via different RPL parents. Selecting the appropriate parents
	parents to achieve ultra-low latency and jitter requires information		to achieve ultra-low latency and jitter requires information about a
	about a node's parents. This document details what information needs		node's parents. This document details what information needs to be
	to be transmitted and how it is encoded within a packet to enable		transmitted and how it is encoded within a packet to enable this
	this functionality.		functionality.
	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.
	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 June 21, 2019.		This Internet-Draft will expire on September 12, 2019.
	Copyright Notice		Copyright Notice
	Copyright (c) 2018 IETF Trust and the persons identified as the		Copyright (c) 2019 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
	carefully, as they describe your rights and restrictions with respect		carefully, as they describe your rights and restrictions with respect
	to this document. Code Components extracted from this document must		to this document. Code Components extracted from this document must
	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
	2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3		2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3
	3. Alternative Parent Selection . . . . . . . . . . . . . . . . 4		3. Alternative Parent Selection . . . . . . . . . . . . . . . . 4
	3.1. Common Ancestor Strict . . . . . . . . . . . . . . . . . 4		3.1. Common Ancestor Strict . . . . . . . . . . . . . . . . . 4
	3.2. Common Ancestor Medium . . . . . . . . . . . . . . . . . 5		3.2. Common Ancestor Medium . . . . . . . . . . . . . . . . . 5
	3.3. Common Ancestor Relaxed . . . . . . . . . . . . . . . . . 5		3.3. Common Ancestor Relaxed . . . . . . . . . . . . . . . . . 5
			3.4. Usage . . . . . . . . . . . . . . . . . . . . . . . . . . 6
	4. Node State and Attribute (NSA) object type extension . . . . 6		4. Node State and Attribute (NSA) object type extension . . . . 6
	4.1. Usage . . . . . . . . . . . . . . . . . . . . . . . . . . 8		4.1. Usage . . . . . . . . . . . . . . . . . . . . . . . . . . 8
	4.1.1. DAG Metric Container fields . . . . . . . . . . . . . 8		4.1.1. DAG Metric Container fields . . . . . . . . . . . . . 9
	4.1.2. Node State and Attribute fields . . . . . . . . . . . 9		4.1.2. Node State and Attribute fields . . . . . . . . . . . 9
	4.2. Compression . . . . . . . . . . . . . . . . . . . . . . . 9		4.2. Compression . . . . . . . . . . . . . . . . . . . . . . . 9
	5. Controlling PRE . . . . . . . . . . . . . . . . . . . . . . . 9		5. Controlling PRE . . . . . . . . . . . . . . . . . . . . . . . 9
	6. Security Considerations . . . . . . . . . . . . . . . . . . . 9		6. Security Considerations . . . . . . . . . . . . . . . . . . . 10
	7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9		7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10
	8. References . . . . . . . . . . . . . . . . . . . . . . . . . 9		8. References . . . . . . . . . . . . . . . . . . . . . . . . . 10
	8.1. Informative references . . . . . . . . . . . . . . . . . 10		8.1. Informative references . . . . . . . . . . . . . . . . . 10
	8.2. Other Informative References . . . . . . . . . . . . . . 10		8.2. Other Informative References . . . . . . . . . . . . . . 11
	Appendix A. Implementation Status . . . . . . . . . . . . . . . 11		Appendix A. Implementation Status . . . . . . . . . . . . . . . 11
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 13		Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 13
	1. Introduction		1. Introduction
	Industrial network applications have stringent requirements on		Industrial network applications have stringent requirements on
	reliability and predictability, and typically leverage 1+1		reliability and predictability, and typically leverage 1+1
	redundancy, aka Packet Replication and Elimination (PRE)		redundancy, aka Packet Replication and Elimination (PRE)
	[I-D.papadopoulos-6tisch-pre-reqs] to achieve their goal. In order		[I-D.papadopoulos-6tisch-pre-reqs] to achieve their goal. In order
	for wireless networks to be able to be used in such applications, the		for wireless networks to be able to be used in such applications, the
	principles of Deterministic Networking [I-D.ietf-detnet-architecture]		principles of Deterministic Networking [I-D.ietf-detnet-architecture]
	lead to designs that aim at maximizing packet delivery rate and		lead to designs that aim at maximizing packet delivery rate and
	minimizing latency and jitter. Additionally, given that the network		minimizing latency and jitter. Additionally, given that the network
	nodes often do not have an unlimited power supply, energy consumption		nodes often do not have an unlimited power supply, energy consumption
	needs to be minimized as well.		needs to be minimized as well.
	To meet this goal, IEEE Std. 802.15.4 [IEEE802154-2015] provides		As an example, to meet this goal, IEEE Std. 802.15.4
	Time-Slotted Channel Hopping (TSCH), a mode of operation which uses a		[IEEE802154-2015] provides Time-Slotted Channel Hopping (TSCH), a
	fixed communication schedule to allow deterministic medium access as		mode of operation which uses a fixed communication schedule to allow
	well as channel hopping to work around radio interference. However,		deterministic medium access as well as channel hopping to work around
	since TSCH uses retransmissions in the event of a failed		radio interference. However, since TSCH uses retransmissions in the
	transmission, end-to-end delay and jitter performance can		event of a failed transmission, end-to-end delay and jitter
	deteriorate.		performance can deteriorate.
	The 6TiSCH working group, focusing on IPv6 over IEEE Std.		Furthermore, the 6TiSCH working group, focusing on IPv6 over IEEE
	802.15.4-TSCH, has worked on the issues previously highlighted and		Std. 802.15.4-TSCH, has worked on the issues previously highlighted
	produced the "6TiSCH Architecture" [I-D.ietf-6tisch-architecture] to		and produced the "6TiSCH Architecture" [I-D.ietf-6tisch-architecture]
	address that case. Building on this architecture, "Exploiting Packet		to address that case. Building on this architecture, "Exploiting
	Replication and Elimination in Complex Tracks in 6TiSCH LLNs"		Packet Replication and Elimination in Complex Tracks in 6TiSCH LLNs"
	[I-D.papadopoulos-6tisch-pre-reqs] leverages PRE to improve the		[I-D.papadopoulos-6tisch-pre-reqs] leverages PRE to improve the
	Packet Delivery Ratio (PDR), provide a hard bound to the end-to-end		Packet Delivery Ratio (PDR), provide a hard bound to the end-to-end
	latency, and limit jitter.		latency, and limit jitter.
	PRE achieves a controlled redundancy by laying multiple forwarding		PRE is a general method of maximizing packet delivery rate and
	paths through the network and using them in parallel for different		potentially minimizing latency and jitter, not limited to 6TiSCH.
	copies of a same packet. PRE can follow the Destination-Oriented		More specifically, PRE achieves a controlled redundancy by laying
	Directed Acyclic Graph (DODAG) formed by RPL from a node to the root.		multiple forwarding paths through the network and using them in
	Building a multi-path DODAG can be achieved based on the RPL		parallel for different copies of a same packet. PRE can follow the
	capability of having multiple parents for each node in a network, a		Destination-Oriented Directed Acyclic Graph (DODAG) formed by RPL
	subset of which is used to forward packets. In order for this subset		from a node to the root. Building a multi-path DODAG can be achieved
	to be defined, a RPL parent subset selection mechanism, which falls		based on the RPL capability of having multiple parents for each node
	within the remit of the RPL Objective Function (OF), needs to have		in a network, a subset of which is used to forward packets. In order
	specific path information. The specification of the transmission of		for this subset to be defined, a RPL parent subset selection
	this information is the focus of this document.		mechanism, which falls within the remit of the RPL Objective Function
			(OF), needs to have specific path information. The specification of
			the transmission of this information is the focus of this document.
	More concretely, this specification focuses on the extensions to the		More concretely, this specification focuses on the extensions to the
	DAG Metric Container [RFC6551] required for providing the PRE		DAG Metric Container [RFC6551] required for providing the PRE
	mechanism a part of the information it needs to operate. This		mechanism a part of the information it needs to operate. This
	information is the RPL [RFC6550] parent address set of a node and it		information is the RPL [RFC6550] parent address set of a node and it
	must be sent to potential children nodes of the node. The RPL DIO		must be sent to potential children nodes of the node. The RPL DIO
	Control Message is the canonical way of broadcasting this kind of		Control Message is the canonical way of broadcasting this kind of
	information and therefore its DAG Metric Container [RFC6551] field is		information and therefore its DAG Metric Container [RFC6551] field is
	used to append a Node State and Attribute (NSA) object. The node's		used to append a Node State and Attribute (NSA) object. The node's
	parent address set is stored as an optional TLV within the NSA		parent address set is stored as an optional TLV within the NSA
	skipping to change at page 3, line 46 ¶		skipping to change at page 3, line 50 ¶
	this TLV.		this TLV.
	2. Terminology		2. 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 [RFC2119].		document are to be interpreted as described in [RFC2119].
	The draft uses the following Terminology:		The draft uses the following Terminology:
	Track A sequence of 6TiSCH schedule resources to support a single-
	path multi-hop transmission of a packet. See "6TiSCH
	Architecture" [I-D.ietf-6tisch-architecture] for more.
	Complex Track A Track which supports a multi-path multi-hop
	transmission of a packet. See "6TiSCH Architecture"
	[I-D.ietf-6tisch-architecture] for more.
	Packet Replication and Elimination (PRE) The sending of multiple		Packet Replication and Elimination (PRE) The sending of multiple
	copies of a packet using multi-path forwarding over a multi-hop		copies of a packet using multi-path forwarding over a multi-hop
	network and the consolidation of multiple received packet copies		network and the consolidation of multiple received packet copies
	to control flooding. See "Exploiting Packet Replication and		to control flooding. See "Exploiting Packet Replication and
	Elimination in Complex Tracks in 6TiSCH LLNs"		Elimination in Complex Tracks in 6TiSCH LLNs"
	[I-D.papadopoulos-6tisch-pre-reqs] for more.		[I-D.papadopoulos-6tisch-pre-reqs] for more.
	Alternative Parent (AP) Selection The problem of how to select the		Alternative Parent (AP) Selection The problem of how to select the
	next hop target node for a packet copy to be forwarded to when		next hop target node for a packet copy to be forwarded to when
	performing packet replication.		performing packet replication.
	3. Alternative Parent Selection		3. Alternative Parent Selection
	In the RPL protocol, each node maintains a list of potential parents.		In the RPL protocol, each node maintains a list of potential parents.
	For PRE, the PP node is defined to be the same as the RPL DODAG		For PRE, the PP node is defined to be the same as the RPL DODAG
	Preferred Parent (PP) node. Furthermore, to construct an alternative		Preferred Parent (PP) node. Furthermore, to construct an alternative
	path toward the root, in addition to the PP node, each 6TiSCH node in		path toward the root, in addition to the PP node, each node in the
	the network registers an AP node as well from its Parent Set (PS).		network registers an AP node as well from its Parent Set (PS). There
	There are multiple alternative methods of selecting the AP node,		are multiple alternative methods of selecting the AP node,
	functionality which is included in operation of the RPL Objective		functionality which is included in operation of the RPL Objective
	Function (OF). A scheme which allows the two paths to remain		Function (OF). A scheme which allows the two paths to remain
	correlated is detailed here. More specifically, in this scheme a		correlated is detailed here. More specifically, in this scheme a
	6TiSCH node will select an alternative parent node close to its PP		node will select an alternative parent node close to its PP node to
	node to allow the operation of overhearing between parents. If		allow the operation of overhearing between parents. If multiple
	multiple potential APs match this condition, the AP with the lowest		potential APs match this condition, the AP with the lowest rank will
	rank will be registered.		be registered.
	There are at least three methods of performing the alternative parent		There are at least three methods of performing the alternative parent
	selection based on common ancestors (CA), named Common Ancestor		selection based on common ancestors (CA), named Common Ancestor
	Strict, Common Ancestor Medium, and Common Ancestor Relaxed,		Strict, Common Ancestor Medium, and Common Ancestor Relaxed,
	depending on how restrictive the selection process is. A more		depending on how restrictive the selection process is. A more
	restrictive method will limit flooding but might fail to select an		restrictive method will limit flooding but might fail to select an
	appropriate alternative parent, while a less restrictive one will		appropriate alternative parent, while a less restrictive one will
	more often find an appropriate alterantive parent but might increase		more often find an appropriate alterantive parent but might increase
	flooding.		flooding.
	skipping to change at page 5, line 28 ¶		skipping to change at page 5, line 28 ¶
	^ ^ ^^ ^		^ ^ ^^ ^
	\ \ || / PS(D) = {Y, Z}		\ \ || / PS(D) = {Y, Z}
	\ \ || / PP(D) = Z		\ \ || / PP(D) = Z
	\ \ || /		\ \ || /
	\----\\ || / || Preferred Parent		\----\\ || / || Preferred Parent
	( S ) source | Potential Alternative Parent		( S ) source | Potential Alternative Parent
	Figure 1: Example Common Ancestor Strict Alternative Parent Selection		Figure 1: Example Common Ancestor Strict Alternative Parent Selection
	method		method
	For example, in Figure 1, the source 6TiSCH node S must know its		For example, in Figure 1, the source node S must know its grandparent
	grandparent sets both through nodes A, B, C, and D. The Parent Sets		sets both through nodes A, B, C, and D. The Parent Sets (PS) and the
	(PS) and the Preferred Parents (PS) of nodes A, B, C, and D are shown		Preferred Parents (PS) of nodes A, B, C, and D are shown on the side
	on the side of the figure. The CA Strict parent selection method		of the figure. The CA Strict parent selection method will select an
	will select an AP for node S for which PP(PP(S)) = PP(AP).		AP for node S for which PP(PP(S)) = PP(AP). Therefore, node S can
	Therefore, node S can decide to use node B as its AP node, since		decide to use node B as its AP node, since PP(PP(S)) = Y = PP(B).
	PP(PP(S)) = Y = PP(B).
	3.2. Common Ancestor Medium		3.2. Common Ancestor Medium
	In CA Medium, the node will check if its Preferred Grand Parent		In CA Medium, the node will check if its Preferred Grand Parent
	(PGP), the PP of its PP, is contained in the PS of the potential AP.		(PGP), the PP of its PP, is contained in the PS of the potential AP.
	Using the same example, in Figure 1, the CA Medium parent selection		Using the same example, in Figure 1, the CA Medium parent selection
	method will select an AP for node S for which PP(PP(S)) in PS(AP).		method will select an AP for node S for which PP(PP(S)) in PS(AP).
	Therefore, node S can decide to use node B or D as its AP node, since		Therefore, node S can decide to use node B or D as its AP node, since
	given that PP(PP(S)) = Y, for node B PS(B) = {W, X, Y} and for node D		given that PP(PP(S)) = Y, for node B PS(B) = {W, X, Y} and for node D
	skipping to change at page 6, line 17 ¶		skipping to change at page 6, line 17 ¶
	empty intersection with PS(AP). Therefore, node S can decide to use		empty intersection with PS(AP). Therefore, node S can decide to use
	node A, B or D as its AP node. Given that PS(PP(S)) = {X, Y, Z} the		node A, B or D as its AP node. Given that PS(PP(S)) = {X, Y, Z} the
	alternative parent selection process evaluates the nodes:		alternative parent selection process evaluates the nodes:
	o Node A: PS(A) = {W, X} and the common nodes are {X}		o Node A: PS(A) = {W, X} and the common nodes are {X}
	o Node B: PS(B) = {W, X, Y} and the common nodes are {X, Y}		o Node B: PS(B) = {W, X, Y} and the common nodes are {X, Y}
	o Node D: PS(D) = {Y, Z} and the common nodes are {Y, Z}		o Node D: PS(D) = {Y, Z} and the common nodes are {Y, Z}
			3.4. Usage
			The PS information can be used by any of the described Alternative
			Parent selection methods or other ones not described here, depending
			on requirements. This document does not suggest a specific AP
			selection method. Additionally, it is OPTIONAL for all nodes to use
			the same AP selection method. Different nodes MAY use different AP
			selection methods, since the selection method is local to each node.
			For example, using different methods can be used to vary the
			transmission reliability in each hop.
	4. Node State and Attribute (NSA) object type extension		4. Node State and Attribute (NSA) object type extension
	In order to select their AP node, 6TiSCH nodes need to be aware of		In order to select their AP node, nodes need to be aware of their
	their grandparent node sets. Within RPL [RFC6550], the nodes use the		grandparent node sets. Within RPL [RFC6550], the nodes use the DODAG
	DODAG Information Object (DIO) Control Message to broadcast		Information Object (DIO) Control Message to broadcast information
	information about themselves to potential children. However, RPL		about themselves to potential children. However, RPL [RFC6550], does
	[RFC6550], does not define how to propagate parent set related		not define how to propagate parent set related information, which is
	information, which is what this document addresses.		what this document addresses.
	DIO messages can carry multiple options, out of which the DAG Metric		DIO messages can carry multiple options, out of which the DAG Metric
	Container option [RFC6551] is the most suitable structurally and		Container option [RFC6551] is the most suitable structurally and
	semantically for the purpose of carrying the parent set. The DAG		semantically for the purpose of carrying the parent set. The DAG
	Metric Container option itself can carry different nested objects,		Metric Container option itself can carry different nested objects,
	out of which the Node State and Attribute (NSA) [RFC6551] is		out of which the Node State and Attribute (NSA) [RFC6551] is
	appropriate for transferring generic node state data. Within the		appropriate for transferring generic node state data. Within the
	Node State and Attribute it is possible to store optional TLVs		Node State and Attribute it is possible to store optional TLVs
	representing various node characteristics. As per the Node State and		representing various node characteristics. As per the Node State and
	Attribute (NSA) [RFC6551] description, no TLV has been defined for		Attribute (NSA) [RFC6551] description, no TLV has been defined for
	skipping to change at page 7, line 38 ¶		skipping to change at page 7, line 38 ¶
	Figure 2 shows the structure of the DIO Control Message when a DAG		Figure 2 shows the structure of the DIO Control Message when a DAG
	Metric Container option is included. The DAG Metric Container option		Metric Container option is included. The DAG Metric Container option
	type (DAGMC Type in Figure 2) has the value 0x02 as per the IANA		type (DAGMC Type in Figure 2) has the value 0x02 as per the IANA
	registry for the RPL Control Message Options, and is defined in		registry for the RPL Control Message Options, and is defined in
	[RFC6550]. The DAG Metric Container option length (DAGMC Length in		[RFC6550]. The DAG Metric Container option length (DAGMC Length in
	Figure 2) expresses the DAG Metric Container length in bytes. DAG		Figure 2) expresses the DAG Metric Container length in bytes. DAG
	Metric Container data holds the actual data and is shown expanded in		Metric Container data holds the actual data and is shown expanded in
	Figure 3.		Figure 3.
	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
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	|Routing-MC-Type|Res Flags|P|C|O|R| A | Prec | Length (bytes)| |=>MC		|Routing-MC-Type|Res Flags|P|C|O|R| A | Prec | Length (bytes)| |MC
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| Res | Flags |A|O| PS type | PS Length | |		| Res | Flags |A|O| PS type | PS Length | |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |=>NSA		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |NSA
	| PS IPv6 address(es) ... |		| 6LoRH type | 6LoRH-compressed PS IPv6 address(es) ... |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	Figure 3: DAG Metric Container (MC) data with Node State and		Figure 3: DAG Metric Container (MC) data with Node State and
	Attribute (NSA) object body and a TLV		Attribute (NSA) object body and a TLV
	The structure of the DAG Metric Container data in the form of a Node		The structure of the DAG Metric Container data in the form of a Node
	State and Attribute (NSA) object with a TLV in the NSA Optional TLVs		State and Attribute (NSA) object with a TLV in the NSA Optional TLVs
	field is shown in Figure 3. The first 32 bits comprise the DAG		field is shown in Figure 3. The first 32 bits comprise the DAG
	Metric Container header and all the following bits are part of the		Metric Container header and all the following bits are part of the
	Node State and Attribute object body, as defined in [RFC6551]. This		Node State and Attribute object body, as defined in [RFC6551]. This
	document defines a new TLV, which CAN be carried in the Node State		document defines a new TLV, which CAN be carried in the Node State
	and Attribute (NSA) object Optional TLVs field. The TLV is named		and Attribute (NSA) object Optional TLVs field. The TLV is named
	Parent Set and is abbreviated as PS in Figure 3.		Parent Set and is abbreviated as PS in Figure 3.
	PS type: The type of the Parent Set TLV. The value is TBD1.		PS type: The type of the Parent Set TLV. The value is TBD1.
	PS Length: The total length of the TLV value field (PS IPv6		PS Length: The total length of the TLV value field (PS IPv6
	address(es)) in bytes.		address(es)) in bytes.
	PS IPv6 address(es): A sequence of zero or more IPv6 addresses		6LoRH type: The type of 6LoRH compression applied to the PS IPv6
	belonging to a node's parent set. Each address requires 16		addresses.https://tools.ietf.org/html/rfc8138#section-5.1 For
	bytes. The order of the parents in the parent set is in		detailed usage see Section 5.1 of [RFC8138]. As an overview,
	decreasing preference based on the Objective Function [RFC6550]		the compressed size of each IPv6 address in the "6LoRH-
	used by the node.		compressed PS IPv6 address(es)" field depending on the value of
			"6LoRH type" is shown in Figure 4.
			+-----------+----------------------+
			| 6LoRH | Length of compressed |
			| Type | IPv6 address (bytes) |
			+-----------+----------------------+
			| 0 | 1 |
			| 1 | 2 |
			| 2 | 4 |
			| 3 | 8 |
			| 4 | 16 |
			+-----------+----------------------+
			Figure 4: The SRH-6LoRH Types
			6LoRH-compressed PS IPv6 address(es): A sequence of zero or more
			IPv6 addresses belonging to a node's parent set. Each address
			requires 16 bytes. The order of the parents in the parent set
			is in decreasing preference based on the Objective Function
			[RFC6550] used by the node.
	4.1. Usage		4.1. Usage
	The PS SHOULD be used in the process of parent selection, and		The PS SHOULD be used in the process of parent selection, and
	especially in alternative parent selection, since it can help the		especially in alternative parent selection, since it can help the
	alternative path from significantly deviating from the preferred		alternative path from significantly deviating from the preferred
	path. The Parent Set is information local to the node that		path. The Parent Set is information local to the node that
	broadcasts it.		broadcasts it.
	4.1.1. DAG Metric Container fields		4.1.1. DAG Metric Container fields
	skipping to change at page 9, line 28 ¶		skipping to change at page 9, line 48 ¶
	to nodes in the same RPL DODAG and are stored in the form of a list		to nodes in the same RPL DODAG and are stored in the form of a list
	of addresses. This makes this field a good candidate for the use of		of addresses. This makes this field a good candidate for the use of
	the same compression as in Source Routing Header 6LoRH (SRH-6LoRH),		the same compression as in Source Routing Header 6LoRH (SRH-6LoRH),
	achieving efficiency and implementation reuse. Therefore, the PS		achieving efficiency and implementation reuse. Therefore, the PS
	IPv6 address(es) field SHOULD be compressed using the compression		IPv6 address(es) field SHOULD be compressed using the compression
	method for Source Routing Header 6LoRH (SRH-6LoRH) [RFC8138].		method for Source Routing Header 6LoRH (SRH-6LoRH) [RFC8138].
	5. Controlling PRE		5. Controlling PRE
	PRE is very helpful when the aim is to increase reliability for a		PRE is very helpful when the aim is to increase reliability for a
	certain track, however it's use creates additional traffic as part of		certain path, however it's use creates additional traffic as part of
	the replication process. It is conceivable that not all tracks have		the replication process. It is conceivable that not all paths have
	stringent reliability requirements. Therefore, a way to control		stringent reliability requirements. Therefore, a way to control
	whether PRE is applied to a track's packets SHOULD be implemented.		whether PRE is applied to a path's packets SHOULD be implemented.
	For example, a traffic class label can be used to determine this		For example, a traffic class label can be used to determine this
	behaviour per flow type as described in Deterministic Networking		behaviour per flow type as described in Deterministic Networking
	Architecture [I-D.ietf-detnet-architecture].		Architecture [I-D.ietf-detnet-architecture].
	6. Security Considerations		6. Security Considerations
	The structure of the DIO control message is extended, within the pre-		The structure of the DIO control message is extended, within the pre-
	defined DIO options. Therefore, the security mechanisms defined in		defined DIO options. Therefore, the security mechanisms defined in
	RPL [RFC6550] apply to this proposed extension.		RPL [RFC6550] apply to this proposed extension.
	skipping to change at page 10, line 4 ¶		skipping to change at page 10, line 20 ¶
	defined DIO options. Therefore, the security mechanisms defined in		defined DIO options. Therefore, the security mechanisms defined in
	RPL [RFC6550] apply to this proposed extension.		RPL [RFC6550] apply to this proposed extension.
	7. IANA Considerations		7. IANA Considerations
	This proposal requests the allocation of a new value TBD1 for the		This proposal requests the allocation of a new value TBD1 for the
	"Parent Set" TLV in the Routing Metric/Constraint TLVs sub-registry		"Parent Set" TLV in the Routing Metric/Constraint TLVs sub-registry
	from IANA.		from IANA.
	8. References		8. References
	8.1. Informative references		8.1. Informative references
	[I-D.ietf-6tisch-architecture]		[I-D.ietf-6tisch-architecture]
	Thubert, P., "An Architecture for IPv6 over the TSCH mode		Thubert, P., "An Architecture for IPv6 over the TSCH mode
	of IEEE 802.15.4", draft-ietf-6tisch-architecture-19 (work		of IEEE 802.15.4", draft-ietf-6tisch-architecture-20 (work
	in progress), December 2018.		in progress), March 2019.
	[I-D.ietf-detnet-architecture]		[I-D.ietf-detnet-architecture]
	Finn, N., Thubert, P., Varga, B., and J. Farkas,		Finn, N., Thubert, P., Varga, B., and J. Farkas,
	"Deterministic Networking Architecture", draft-ietf-		"Deterministic Networking Architecture", draft-ietf-
	detnet-architecture-09 (work in progress), October 2018.		detnet-architecture-12 (work in progress), March 2019.
	[I-D.papadopoulos-6tisch-pre-reqs]		[I-D.papadopoulos-6tisch-pre-reqs]
	Papadopoulos, G., Montavont, N., and P. Thubert,		Papadopoulos, G., Montavont, N., and P. Thubert,
	"Exploiting Packet Replication and Elimination in Complex		"Exploiting Packet Replication and Elimination in Complex
	Tracks in 6TiSCH LLNs", draft-papadopoulos-6tisch-pre-		Tracks in 6TiSCH LLNs", draft-papadopoulos-6tisch-pre-
	reqs-02 (work in progress), July 2018.		reqs-02 (work in progress), July 2018.
	[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,
	skipping to change at page 11, line 37 ¶		skipping to change at page 12, line 19 ¶
	(21) (22) (23) (24) (25) (26)		(21) (22) (23) (24) (25) (26)
	(31) (32) (33) (34) (35) (36)		(31) (32) (33) (34) (35) (36)
	(41) (42) (43) (44) (45) (46)		(41) (42) (43) (44) (45) (46)
	(51) (52) (53) (54) (55) (56)		(51) (52) (53) (54) (55) (56)
	( S )		( S )
	Figure 4: Simulation Topology		Figure 5: Simulation Topology
	The simulation setup is:		The simulation setup is:
	Topology: 32 nodes structured in regular grid as show in Figure 4.		Topology: 32 nodes structured in regular grid as show in Figure 5.
	Node S (source) is the only data packet sender, and send data to		Node S (source) is the only data packet sender, and send data to
	node R (root). The parent set of each node (except R) is all the		node R (root). The parent set of each node (except R) is all the
	nodes in the immediatelly higher row, the immediatelly above 6		nodes in the immediatelly higher row, the immediatelly above 6
	nodes. For example, each node in {51, 52, 53, 54, 55, 56} is		nodes. For example, each node in {51, 52, 53, 54, 55, 56} is
	connected to all of {41, 42, 43, 44, 45, 46}. Node 11, 12, 13,		connected to all of {41, 42, 43, 44, 45, 46}. Node 11, 12, 13,
	14, 15, 16 have a single upwards link to R.		14, 15, 16 have a single upwards link to R.
	MAC: TSCH with 1 retransmission		MAC: TSCH with 1 retransmission
	Platform: Cooja		Platform: Cooja
End of changes. 28 change blocks.
	90 lines changed or deleted		116 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/