< draft-ietf-roll-nsa-extension-05.txt		draft-ietf-roll-nsa-extension-06.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: May 7, 2020 IMT Atlantique		Expires: August 13, 2020 IMT Atlantique
	P. Thubert		P. Thubert
	Cisco		Cisco
	November 4, 2019		February 10, 2020
	Common Ancestor Objective Functions and Parent Set DAG Metric Container		Common Ancestor Objective Function and Parent Set DAG Metric Container
	Extension		Extension
	draft-ietf-roll-nsa-extension-05		draft-ietf-roll-nsa-extension-06
	Abstract		Abstract
	Implementing Packet Replication and Elimination from / to the RPL		Implementing Packet Replication and Elimination from/to the RPL root
	root requires the ability to forward copies of packets over different		requires the ability to forward copies of packets over different
	paths via different RPL parents. Selecting the appropriate parents		paths via different RPL parents. Selecting the appropriate parents
	to achieve ultra-low latency and jitter requires information about a		to achieve ultra-low latency and jitter requires information about a
	node's parents. This document details what information needs to be		node's parents. This document details what information needs to be
	transmitted and how it is encoded within a packet to enable this		transmitted and how it is encoded within RPL control packets to
	functionality. This document also describes Objective Functions		enable this functionality. This document also describes Objective
	which take advantage of this information to implement multi-path		Function which take advantage of this information to implement multi-
	routing.		path routing.
	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 May 7, 2020.		This Internet-Draft will expire on August 13, 2020.
	Copyright Notice		Copyright Notice
	Copyright (c) 2019 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
	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 . . . . . . . . . . . . . . . . . . . . . . . . . 4		2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4
	3. Common Ancestor Objective Functions . . . . . . . . . . . . . 4		3. Common Ancestor Objective Function . . . . . . . . . . . . . 4
	3.1. Common Ancestor Strict . . . . . . . . . . . . . . . . . 6		3.1. Common Ancestor Strict . . . . . . . . . . . . . . . . . 6
	3.2. Common Ancestor Medium . . . . . . . . . . . . . . . . . 7		3.2. Common Ancestor Medium . . . . . . . . . . . . . . . . . 7
	3.3. Common Ancestor Relaxed . . . . . . . . . . . . . . . . . 8		3.3. Common Ancestor Relaxed . . . . . . . . . . . . . . . . . 8
	3.4. Usage . . . . . . . . . . . . . . . . . . . . . . . . . . 8		3.4. Usage . . . . . . . . . . . . . . . . . . . . . . . . . . 8
	4. Node State and Attribute (NSA) object type extension . . . . 8		4. Node State and Attribute (NSA) object type extension . . . . 8
	4.1. Usage . . . . . . . . . . . . . . . . . . . . . . . . . . 10		4.1. Usage . . . . . . . . . . . . . . . . . . . . . . . . . . 10
	5. Controlling PRE . . . . . . . . . . . . . . . . . . . . . . . 10		5. Controlling PRE . . . . . . . . . . . . . . . . . . . . . . . 11
	6. Security Considerations . . . . . . . . . . . . . . . . . . . 11		6. Security Considerations . . . . . . . . . . . . . . . . . . . 11
	7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11		7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11
	8. References . . . . . . . . . . . . . . . . . . . . . . . . . 11		8. References . . . . . . . . . . . . . . . . . . . . . . . . . 11
	8.1. Informative references . . . . . . . . . . . . . . . . . 11		8.1. Informative references . . . . . . . . . . . . . . . . . 11
	8.2. Other Informative References . . . . . . . . . . . . . . 12		8.2. Other Informative References . . . . . . . . . . . . . . 12
	Appendix A. Implementation Status . . . . . . . . . . . . . . . 12		Appendix A. Implementation Status . . . . . . . . . . . . . . . 13
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 14		Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 15
	1. Introduction		1. Introduction
	Network-enabled applications in the industrial context must provide		Network-enabled applications in the industrial context must provide
	stringent guarantees in terms of reliability and predictability. To		stringent guarantees in terms of reliability and predictability.
	achieve this they typically leverage 1+1 redundancy, also known as
	Packet Replication and Elimination (PRE)		Packet Replication and Elimination (PRE)
	[I-D.papadopoulos-6tisch-pre-reqs]. Allowing these kinds of		[I-D.papadopoulos-6tisch-pre-reqs] is a technique which allows
	applications to function over wireless networks requires the		redundant paths in the network to be utilized for traffic requiring
	application of the principles of Deterministic Networking		higher reliability. Allowing these kinds of applications to function
	[I-D.ietf-detnet-architecture]. This results in designs which aim at		over wireless networks requires the application of the principles of
	optimizing packet delivery rate and bounding latency. Additionally,		Deterministic Networking [I-D.ietf-detnet-architecture]. This
	given that the network nodes often do not have an unlimited power		results in designs which aim at optimizing packet delivery rate and
	supply, energy consumption needs to be minimized as well.		bounding latency. Additionally, given that the network nodes often
			do not have an unlimited power supply, energy consumption needs to be
			minimized as well.
	As an example, to meet this goal, IEEE Std. 802.15.4 [IEEE802154]		As an example, to meet this goal, IEEE Std. 802.15.4 [IEEE802154]
	provides Time-Slotted Channel Hopping (TSCH), a mode of operation		provides Time-Slotted Channel Hopping (TSCH), a mode of operation
	which uses a common communication schedule based on timeslots to		which uses a common communication schedule based on timeslots to
	allow deterministic medium access as well as channel hopping to work		allow deterministic medium access as well as channel hopping to work
	around radio interference. However, since TSCH uses retransmissions		around radio interference. However, since TSCH uses retransmissions
	in the event of a failed transmission, end-to-end delay and jitter		in the event of a failed transmission, end-to-end delay and jitter
	performance can deteriorate.		performance can deteriorate.
	Furthermore, the 6TiSCH working group, focusing on IPv6 over IEEE		Furthermore, the 6TiSCH working group, focusing on IPv6 over IEEE
	skipping to change at page 3, line 32 ¶		skipping to change at page 3, line 33 ¶
	Destination-Oriented Directed Acyclic Graph (DODAG) formed by RPL		Destination-Oriented Directed Acyclic Graph (DODAG) formed by RPL
	from a node to the root. Building a multi-path DODAG can be achieved		from a node to the root. Building a multi-path DODAG can be achieved
	based on the RPL capability of having multiple parents for each node		based on the RPL capability of having multiple parents for each node
	in a network, a subset of which is used to forward packets. In order		in a network, a subset of which is used to forward packets. In order
	for this subset to be defined, a RPL parent subset selection		for this subset to be defined, a RPL parent subset selection
	mechanism, which is among the responsibilities of the RPL Objective		mechanism, which is among the responsibilities of the RPL Objective
	Function (OF), needs to have specific path information. This		Function (OF), needs to have specific path information. This
	document describes OFs which implement multi-path routing for PRE and		document describes OFs which implement multi-path routing for PRE and
	specifies the transmission of this specific path information.		specifies the transmission of this specific path information.
	For the OFs, this document specifies a group of OFs called Common		This document describes a new objective function (OF) called the
	Ancestor (CA) OFs. A detailed description is made of how the path		Common Ancestor (CA) OF. A detailed description is given of how the
	information is used within the CA OF and how the subset of parents		path information is used within the CA OF and how the subset of
	for forwarding packets is selected. This specification defines a new		parents for forwarding packets is selected. This specification
	shared Objective Code Point (OCP) for these CA OFs.		defines a new Objective Code Point (OCP) for the CA OF.
	For the path information, this specification focuses on the		For the path information, this specification focuses on the
	extensions to the DAG Metric Container [RFC6551] required for		extensions to the DAG Metric Container [RFC6551] required for
	providing the PRE mechanism a part of the information it needs to		providing the PRE mechanism a part of the information it needs to
	operate. This information is the RPL [RFC6550] parent address set of		operate. This information is the RPL [RFC6550] parent address set of
	a node and it must be sent to potential children of the node. The		a node and it must be sent to potential children of the node. The
	RPL DIO Control Message is the canonical way of broadcasting this		RPL DIO Control Message is the canonical way of broadcasting this
	kind of information and therefore its DAG Metric Container [RFC6551]		kind of information and therefore its DAG Metric Container [RFC6551]
	field is used to append a Node State and Attribute (NSA) object. The		field is 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		node's parent address set is stored as an optional TLV within the NSA
	skipping to change at page 4, line 20 ¶		skipping to change at page 4, line 20 ¶
	The draft uses the following Terminology:		The draft uses the following Terminology:
	Packet Replication and Elimination (PRE): A method which transmits		Packet Replication and Elimination (PRE): A method which transmits
	multiple copies of a packet using multi-path forwarding over a		multiple copies of a packet using multi-path forwarding over a
	multi-hop network and which consolidates multiple received packet		multi-hop network and which consolidates multiple received packet
	copies to control flooding. See "Exploiting Packet Replication		copies to control flooding. See "Exploiting Packet Replication
	and Elimination in Complex Tracks in 6TiSCH LLNs"		and Elimination in Complex Tracks in 6TiSCH LLNs"
	[I-D.papadopoulos-6tisch-pre-reqs] for more details.		[I-D.papadopoulos-6tisch-pre-reqs] for more details.
			Parent Set (PS): Given a RPL node, the set of its neighbor nodes
			which participate in the same RPL DODAG and which can potentially
			take the role of the node's preferred parent.
			Alternative Parent (AP): A RPL parent in the parent set of a node
			which is used to forward a packet copy when replicating packets.
	Alternative Parent (AP) Selection: The mechanism for choosing the		Alternative Parent (AP) Selection: The mechanism for choosing the
	next hop node to forward a packet copy when replicating packets.		next hop node to forward a packet copy when replicating packets.
	3. Common Ancestor Objective Functions		Preferred Grand Parent (PGP): The preferred parent of the preferred
			parent of a node.
			3. Common Ancestor Objective Function
	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 Preferred Parent (PP) node is defined to be the same as		For PRE, the Preferred Parent (PP) node is defined to be the same as
	the RPL DODAG Preferred Parent node. Furthermore, to construct an		the RPL DODAG Preferred Parent node. Furthermore, to construct an
	alternative path toward the root, in addition to the PP node, each		alternative path toward the root, in addition to the PP node, each
	node in the network registers an AP node as well from its Parent Set		node in the network registers an AP node as well from its Parent Set
	(PS).		(PS).
	There are multiple alternative methods of selecting the AP node.		There are multiple alternative methods of selecting the AP node.
	This functionality is included in the operation of the RPL Objective		This functionality is included in the operation of the RPL Objective
	Function (OF). A group of OFs which allow the two paths to remain		Function (OF). An OF which allows the two paths to remain correlated
	correlated is detailed here. More specifically, when using these OFs		is detailed here. More specifically, when using this OF a node will
	a node will select an AP node close to its PP node to allow the		select an AP node close to its PP node to allow the operation of
	operation of overhearing between parents. For more details about		overhearing between parents. For more details about overhearing and
	overhearing and its use in this context see Section 4.3.		its use in this context see Section 4.3. "Promiscuous Overhearing"
	"Promiscuous Overhearing" in "Exploiting Packet Replication and		in "Exploiting Packet Replication and Elimination in Complex Tracks
	Elimination in Complex Tracks in 6TiSCH LLNs"		in 6TiSCH LLNs" [I-D.papadopoulos-6tisch-pre-reqs]. If multiple
	[I-D.papadopoulos-6tisch-pre-reqs]. If multiple potential APs match		potential APs match this condition, the AP with the lowest rank will
	this condition, the AP with the lowest rank will be registered.		be registered.
	The OFs described here are an extension of the The Minimum Rank with		The OF described here is an extension of the The Minimum Rank with
	Hysteresis Objective Function [RFC6719] (MRHOF) OF. In general,		Hysteresis Objective Function [RFC6719] (MRHOF). In general, this OF
	these OFs extend MRHOF by specifying how an AP is selected.		extends MRHOF by specifying how an AP is selected. Importantly, the
	Importantly, the calculation of the rank of the node though each		calculation of the rank of the node through each candidate neighbor
	candidate neighbor and the selection of the PP is kept the same as in		and the selection of the PP is kept the same as in MRHOF.
	MRHOF.
	The ways in which the CA OFs modify MRHOF in a section-by-section		The ways in which the CA OF modifies MRHOF in a section-by-section
	manner follows in detail:		manner follows in detail:
	3. The Minimum Rank with Hysteresis Objective Function: Same as		3. The Minimum Rank with Hysteresis Objective Function:
	MRHOF extended to AP selection. Minimum Rank path selection and		Same as MRHOF extended to AP selection. Minimum Rank path
	switching applies correspondingly to the AP with the extra CA		selection and switching applies correspondingly to the AP with the
	requirement of having some match between ancestors, depending on		extra CA requirement of having some match between ancestors.
	the specific variant of CA OF used.
	3.1. Computing the Path Cost: Same as MRHOF extended to AP		3.1. Computing the Path Cost: Same as MRHOF extended to AP
	selection. If a candidate neighbor does not fulfill the CA		selection. If a candidate neighbor does not fulfill the CA
	requirement then the path through that neighbor SHOULD be set to		requirement then the path through that neighbor SHOULD be set to
	MAX_PATH_COST. As a result, the node MUST NOT select the		MAX_PATH_COST, the same value used by MRHOF. As a result, the
	candidate neighbor as its AP.		node MUST NOT select the candidate neighbor as its AP.
	3.2. Parent Selection: Same as MRHOF extended to AP selection. To		3.2. Parent Selection: Same as MRHOF extended to AP selection. To
	allow hysteresis, AP selection maintains a variable,		allow hysteresis, AP selection maintains a variable,
	cur_ap_min_path_cost, which is the path cost of the current AP.		cur_ap_min_path_cost, which is the path cost of the current AP.
	3.2.1. When Parent Selection Runs: Same as MRHOF.		3.2.1. When Parent Selection Runs: Same as MRHOF.
	3.2.2. Parent Selection Algorithm: Same as MRHOF extended to AP		3.2.2. Parent Selection Algorithm: Same as MRHOF extended to AP
	selection. If the smallest path cost for paths through the		selection. If the smallest path cost for paths through the
	candidate neighbors is smaller than cur_ap_min_path_cost by less		candidate neighbors is smaller than cur_ap_min_path_cost by less
	than PARENT_SWITCH_THRESHOLD, the node MAY continue to use the		than PARENT_SWITCH_THRESHOLD (the same variable as MRHOF uses),
	current AP. Additionally, if there is no PP selected, there MUST		the node MAY continue to use the current AP. Additionally, if
	NOT be any AP selected as well. Finally, as with MRHOF, a node		there is no PP selected, there MUST NOT be any AP selected as
	MAY include up to PARENT_SET_SIZE-1 additional candidate neighbors		well. Finally, as with MRHOF, a node MAY include up to
	in its alternative parent set.		PARENT_SET_SIZE-1 additional candidate neighbors in its
			alternative parent set. The value of PARENT_SET_SIZE is the same
			as in MRHOF.
	3.3. Computing Rank: Same as MRHOF.		3.3. Computing Rank: Same as MRHOF.
	3.4. Advertising the Path Cost: Same as MRHOF.		3.4. Advertising the Path Cost: Same as MRHOF.
	3.5. Working without Metric Containers: It is not possible to work		3.5. Working without Metric Containers: It is not possible to work
	without metric containers, since CA AP selection requires		without metric containers, since CA AP selection requires
	information from parents regarding their parent sets, which is		information from parents regarding their parent sets, which is
	transmitted via the NSA object in the DIO Mectric Container.		transmitted via the NSA object in the DIO Mectric Container.
	skipping to change at page 8, line 35 ¶		skipping to change at page 8, line 35 ¶
	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}
	node S can decide to use node A, B or D as its AP node.		node S can decide to use node A, B or D as its AP node.
	3.4. Usage		3.4. Usage
	The PS information can be used by any of the described AP selection		The PS information can be used by any of the described AP selection
	methods or other ones not described here, depending on requirements.		methods or other ones not described here, depending on requirements.
	It is optional for all nodes to use the same AP selection method, and		It is optional for all nodes to use the same AP selection method.
	because the CA OFs share the same OCP, they can do that withing the		Different nodes may use different AP selection methods, since the
	same RPL Instance. Different nodes may use different AP selection		selection method is local to each node. For example, using different
	methods, since the selection method is local to each node. For		methods can be used to vary the transmission reliability in each hop.
	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, nodes need to be aware of their		In order to select their AP node, nodes need to be aware of their
	grandparent node sets. Within RPL [RFC6550], the nodes use the DODAG		grandparent node sets. Within RPL [RFC6550], the nodes use the DODAG
	Information Object (DIO) Control Message to broadcast information		Information Object (DIO) Control Message to broadcast information
	about themselves to potential children. However, RPL [RFC6550], does		about themselves to potential children. However, RPL [RFC6550], does
	not define how to propagate parent set related information, which is		not define how to propagate parent set related information, which is
	what this document addresses.		what this document addresses.
	skipping to change at page 10, line 30 ¶		skipping to change at page 10, line 30 ¶
	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 TBD2.		PS type: The type of the Parent Set TLV. The value is TBD2.
	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. The length is an integral multiple of
			16, the number of bytes in an IPv6 address.
			PS IPv6 address(es) One or more 128-bit IPv6 address(es) without any
			separator between them. The field consists of one IPv6 address
			per parent in the parent set. The parent addresses are listed
			in decreasing order of preference and not all parents in the
			parent set need to be included. The selection of how many
			parents from the parent set are to be included is left to the
			implementation. The number of parent addresses in the PS IPv6
			address(es) field can be deduced by dividing the length of the
			PS IPv6 address(es) field in bytes by 16, the number of bytes
			in an IPv6 address.
	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 AP selection, since it can help the alternative path to		especially in AP selection, since it can help the alternative path to
	not significantly deviate from the preferred path. The Parent Set is		not significantly deviate from the preferred path. The Parent Set is
	information local to the node that broadcasts it.		information local to the node that broadcasts it.
	The PS is used only within NSA objects configured as constraints and		The PS is used only within NSA objects configured as constraints and
	is used as per [RFC6551]. As a result, the PS does not affect the		is used as per [RFC6551]. As a result, the PS does not affect the
	calculation of the rank through candidate neighbors. It is only used		calculation of the rank through candidate neighbors. It is only used
	with the CA OFs to remove nodes which do not fulfill the CA OF		with the CA OF to remove nodes which do not fulfill the CA OF
	criteria from the candidate neighbor list.		criteria from the candidate neighbor list.
	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 path, however its use creates additional traffic as part of		certain path, however its use creates additional traffic as part of
	the replication process. It is conceivable that not all paths 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 path'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
	behavior per flow type as described in Deterministic Networking		behavior 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.
	7. IANA Considerations		7. IANA Considerations
	This proposal requests the allocation of a new value TBD1 from the		This proposal requests the allocation of a new value TBD1 from the
	"Objective Code Point (OCP)" sub-registry of the "Routing Protocol		"Objective Code Point (OCP)" sub-registry of the "Routing Protocol
	for Low Power and Lossy Networks (RPL)" registry. This proposal also		for Low Power and Lossy Networks (RPL)" registry.
	requests the allocation of a new value TBD2 for the "Parent Set" TLV
	from the Routing Metric/Constraint TLVs sub-registry from IANA.		This proposal also requests the allocation of a new value TBD2 for
			the "Parent Set" TLV from the Routing Metric/Constraint TLVs sub-
			registry 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-28 (work		of IEEE 802.15.4", draft-ietf-6tisch-architecture-28 (work
	in progress), October 2019.		in progress), October 2019.
	skipping to change at page 14, line 23 ¶		skipping to change at page 14, line 35 ¶
	* 2nd ETX: PRE with a parent selection method which picks as AP		* 2nd ETX: PRE with a parent selection method which picks as AP
	the 2nd best parent in the parent set based on ETX.		the 2nd best parent in the parent set based on ETX.
	* CA Strict: As described in Section 3.1.		* CA Strict: As described in Section 3.1.
	* CA Medium: As described in Section 3.2.		* CA Medium: As described in Section 3.2.
	Simulation results:		Simulation results:
	+----------+---------------+------------------+---------------------+		+-----------+---------------+-----------------+---------------------+
	| Routing | Average | Average | Average |		| Routing | Average | Average | Average |
	| Method | Packet | Traversed | Duplications/packet |		| Method | Packet | Traversed | Duplications/packet |
	| | Delivery Rate | Nodes/packet (#) | (#) |		| | Delivery Rate | Nodes/packet | (#) |
	| | (%) | | |		| | (%) | (#) | |
	+----------+---------------+------------------+---------------------+		+-----------+---------------+-----------------+---------------------+
	| RPL | 82.70 | 5.56 | 7.02 |		| RPL | 82.70 | 5.56 | 7.02 |
	| 2nd ETX | 99.38 | 14.43 | 31.29 |		| 2nd ETX | 99.38 | 14.43 | 31.29 |
	| CA | 97.32 | 9.86 | 18.23 |		| CA Strict | 97.32 | 9.86 | 18.23 |
	| Strict | | | |		| CA Medium | 99.66 | 13.75 | 28.86 |
	| CA | 99.66 | 13.75 | 28.86 |		+-----------+---------------+-----------------+---------------------+
	| Medium | | | |
	+----------+---------------+------------------+---------------------+
	Links:		Links:
	o Contiki OS DIO DAGMC NSA extension (draft-koutsiamanis-roll-nsa-		o Contiki OS DIO DAGMC NSA extension (draft-koutsiamanis-roll-nsa-
	extension branch) [1]		extension branch) [1]
	o Wireshark dissectors (for the optional PS TLV) - currently merged		o Wireshark dissectors (for the optional PS TLV) - currently merged
	/ in master [2]		/ in master [2]
	Authors' Addresses		Authors' Addresses
End of changes. 28 change blocks.
	84 lines changed or deleted		104 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/