< draft-ietf-roll-nsa-extension-08.txt		draft-ietf-roll-nsa-extension-09.txt >
	ROLL R.-A. Koutsiamanis, Ed.		ROLL R.-A. Koutsiamanis, Ed.
	Internet-Draft G.Z. Papadopoulos		Internet-Draft G.Z. Papadopoulos
	Intended status: Standards Track N. Montavont		Intended status: Standards Track N. Montavont
	Expires: 28 September 2020 IMT Atlantique		Expires: 30 March 2021 IMT Atlantique
	P. Thubert		P. Thubert
	Cisco		Cisco
	27 March 2020		26 September 2020
	Common Ancestor Objective Function and Parent Set DAG Metric Container		Common Ancestor Objective Function and Parent Set DAG Metric Container
	Extension		Extension
	draft-ietf-roll-nsa-extension-08		draft-ietf-roll-nsa-extension-09
	Abstract		Abstract
	Packet Replication and Elimination is a method in which several		Packet Replication and Elimination is a method in which several
	copies of a data packet are sent in the network in order to achieve		copies of a data packet are sent in the network in order to achieve
	high reliability and low jitter. This document details how to apply		high reliability and low jitter. This document details how to apply
	Packet Replication and Elimination in RPL, especially how to exchange		Packet Replication and Elimination in RPL, especially how to exchange
	information within RPL control packets to let a node better select		information within RPL control packets to let a node better select
	the different parents that will be used to forward the multiple		the different parents that will be used to forward the multiple
	copies of a packet. This document also describes the Objective		copies of a packet. This document also describes the Objective
	skipping to change at page 1, line 42 ¶		skipping to change at page 1, line 42 ¶
	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 28 September 2020.		This Internet-Draft will expire on 30 March 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 (https://trustee.ietf.org/		Provisions Relating to IETF Documents (https://trustee.ietf.org/
	license-info) in effect on the date of publication of this document.		license-info) in effect on the date of publication of this document.
	Please review these documents carefully, as they describe your rights		Please review these documents carefully, as they describe your rights
	skipping to change at page 2, line 23 ¶		skipping to change at page 2, line 23 ¶
	Table of Contents		Table of Contents
	1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2		1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
	2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4		2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4
	3. Common Ancestor AP Selection Policies . . . . . . . . . . . . 4		3. Common Ancestor AP Selection Policies . . . . . . . . . . . . 4
	3.1. Common Ancestor Strict . . . . . . . . . . . . . . . . . 5		3.1. Common Ancestor Strict . . . . . . . . . . . . . . . . . 5
	3.2. Common Ancestor Medium . . . . . . . . . . . . . . . . . 6		3.2. Common Ancestor Medium . . . . . . . . . . . . . . . . . 6
	3.3. Common Ancestor Relaxed . . . . . . . . . . . . . . . . . 6		3.3. Common Ancestor Relaxed . . . . . . . . . . . . . . . . . 6
	4. Common Ancestor Objective Function . . . . . . . . . . . . . 6		4. Common Ancestor Objective Function . . . . . . . . . . . . . 6
	4.1. Usage . . . . . . . . . . . . . . . . . . . . . . . . . . 8		4.1. Usage . . . . . . . . . . . . . . . . . . . . . . . . . . 9
	5. Node State and Attribute (NSA) object type extension . . . . 9		5. Node State and Attribute (NSA) object type extension . . . . 9
	5.1. Usage . . . . . . . . . . . . . . . . . . . . . . . . . . 11		5.1. Usage . . . . . . . . . . . . . . . . . . . . . . . . . . 11
	6. Controlling PRE . . . . . . . . . . . . . . . . . . . . . . . 12		6. Controlling PRE . . . . . . . . . . . . . . . . . . . . . . . 12
	7. Security Considerations . . . . . . . . . . . . . . . . . . . 12		7. Security Considerations . . . . . . . . . . . . . . . . . . . 12
	8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12		8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12
	9. References . . . . . . . . . . . . . . . . . . . . . . . . . 12		9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 13
	9.1. Informative references . . . . . . . . . . . . . . . . . 12		10. References . . . . . . . . . . . . . . . . . . . . . . . . . 13
	9.2. Other Informative References . . . . . . . . . . . . . . 14		10.1. Informative references . . . . . . . . . . . . . . . . . 13
	Appendix A. Implementation Status . . . . . . . . . . . . . . . 14		Appendix A. Implementation Status . . . . . . . . . . . . . . . 14
	Appendix B. Choosing an AP selection policy . . . . . . . . . . 16		Appendix B. Choosing an AP selection policy . . . . . . . . . . 16
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 17		Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 17
	1. Introduction		1. Introduction
	Networks in the industrial context must provide stringent guarantees		Networks in the industrial context must provide stringent guarantees
	in terms of reliability and predictability, with this domain being		in terms of reliability and predictability, with this domain being
	one of main ones addressed by Deterministic Networking [RFC8557].		one of main ones addressed by Deterministic Networking [RFC8557].
	Packet Replication and Elimination (PRE)		Packet Replication and Elimination (PRE) (Section 4.5.3 of
	[I-D.papadopoulos-raw-pareo-reqs] is a technique which allows		[I-D.ietf-6tisch-architecture]) is a technique which allows redundant
	redundant paths in the network to be utilized for traffic requiring		paths in the network to be utilized for traffic requiring higher
	higher reliability. Allowing industrial applications to function		reliability. Allowing industrial applications to function over
	over wireless networks requires the application of the principles and		wireless networks requires the application of the principles and
	architecture of Deterministic Networking [RFC8655]. This results in		architecture of Deterministic Networking [RFC8655]. This results in
	designs which aim at optimizing packet delivery rate and bounding		designs which aim at optimizing packet delivery rate and bounding
	latency. Additionally, nodes operating on battery need to minimize		latency. Additionally, nodes operating on battery need to minimize
	their energy consumption.		their energy consumption.
	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 latency and jitter		in the event of a failed transmission, end-to-end latency 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
	Std. 802.15.4-TSCH, has worked on these issues and produced the		Std. 802.15.4-TSCH, has worked on these issues and produced the
	"6TiSCH Architecture" [I-D.ietf-6tisch-architecture] to address that		"6TiSCH Architecture" [I-D.ietf-6tisch-architecture] to address that
	case. Building on this architecture, "Exploiting Packet Replication		case.
	and Elimination in Complex Tracks in LLNs"
	[I-D.papadopoulos-raw-pareo-reqs] leverages PRE to improve the Packet
	Delivery Ratio (PDR), to provide a hard bound to the end-to-end
	latency, and thus to limit jitter.
	PRE is a general method of maximizing packet delivery rate and		PRE is a general method of maximizing packet delivery rate and
	potentially minimizing latency and jitter, not limited to 6TiSCH.		potentially minimizing latency and jitter, not limited to 6TiSCH.
	More specifically, PRE achieves controlled redundancy by laying		More specifically, PRE achieves controlled redundancy by laying
	multiple forwarding paths through the network and using them in		multiple forwarding paths through the network and using them in
	parallel for different copies of a same packet. PRE can follow the		parallel for different copies of a same packet. PRE can follow the
	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
	skipping to change at page 4, line 16 ¶		skipping to change at page 4, line 16 ¶
	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:
	Packet Replication and Elimination (PRE): A method which consists of		Packet Replication and Elimination (PRE): A method which consists of
	transmitting multiple copies of a packet using multi-path		transmitting multiple copies of a packet using multi-path
	forwarding over a multi-hop network and which consolidates		forwarding over a multi-hop network and which consolidates
	multiple received packet copies to control flooding. See		multiple received packet copies to control flooding. See "Complex
	"Exploiting Packet Replication and Elimination in Complex Tracks		Track with Replication and Elimination" in Section 4.5.3 of
	in LLNs" [I-D.papadopoulos-raw-pareo-reqs] for more details.		[I-D.ietf-6tisch-architecture] for more details.
	Parent Set (PS): Given a RPL node, the set of its neighbor nodes		Parent Set (PS): Given a RPL node, the set of its neighbor nodes
	which participate in the same RPL DODAG and which can potentially		which participate in the same RPL DODAG and which can potentially
	take the role of the node's preferred parent.		take the role of the node's preferred parent.
	Alternative Parent (AP): A RPL parent in the parent set of a node		Alternative Parent (AP): A RPL parent in the parent set of a node
	which is used to forward a packet copy when replicating packets.		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.
	skipping to change at page 5, line 32 ¶		skipping to change at page 5, line 32 ¶
	| \ // | \ // || \ / || PS(B) = {W, X, Y}		| \ // | \ // || \ / || PS(B) = {W, X, Y}
	| // | // || / || PP(B) = Y		| // | // || / || PP(B) = Y
	| // \ | // \ || / \ ||		| // \ | // \ || / \ ||
	| // \ | // \ || / \ || PS(C) = {X, Y, Z}		| // \ | // \ || / \ || PS(C) = {X, Y, Z}
	( A ) ( B ) ( C ) ( D ) PP(C) = Y		( A ) ( B ) ( C ) ( D ) PP(C) = Y
	^ ^ ^^ ^		^ ^ ^^ ^
	\ \ || / 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 Alt. Parent
	Figure 1: Example Common Ancestor Strict Alternative Parent		Figure 1: Example Common Ancestor Strict Alternative Parent
	Selection policy		Selection policy
	For example, in Figure 1, the source node S must know its grandparent		For example, in Figure 1, the source node S must know its grandparent
	sets through nodes A, B, C, and D. The Parent Sets (PS) and the		sets through nodes A, B, C, and D. The Parent Sets (PS) and the
	Preferred Parents (PS) of nodes A, B, C, and D are shown on the side		Preferred Parents (PS) of nodes A, B, C, and D are shown on the side
	of the figure. The CA Strict parent selection policy will select an		of the figure. The CA Strict parent selection policy will select an
	AP for node S for which PP(PP(S)) = PP(AP). Given that PP(PP(S)) =		AP for node S for which PP(PP(S)) = PP(AP). Given that PP(PP(S)) =
	Y:		Y:
	skipping to change at page 6, line 46 ¶		skipping to change at page 6, line 46 ¶
	* Node D: PS(D) = {Y, Z} and the common nodes are {Y, Z}		* 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.
	4. Common Ancestor Objective Function		4. Common Ancestor Objective Function
	An OF which allows the multiple paths to remain correlated is		An OF which allows the multiple paths to remain correlated is
	detailed here. More specifically, when using this OF a node will		detailed here. More specifically, when using this OF a node will
	select an AP node close to its PP node to allow the operation of		select an AP node close to its PP node to allow the operation of
	overhearing between parents. For more details about overhearing and		overhearing between parents. For more details about overhearing and
	its use in this context see the "Promiscuous Overhearing" Section 4.3		its use in this context see the "Complex Track with Replication and
	of [I-D.papadopoulos-raw-pareo-reqs]. If multiple potential APs		Elimination" in Section 4.5.3 of [I-D.ietf-6tisch-architecture]. If
	match this condition, the AP with the lowest rank will be registered.		multiple potential APs match this condition, the AP with the lowest
			rank will be registered.
	The OF described here is an extension of The Minimum Rank with		The OF described here is an extension of The Minimum Rank with
	Hysteresis Objective Function [MRHOF]. In general, this OF extends		Hysteresis Objective Function [MRHOF]. In general, this OF extends
	MRHOF by specifying how an AP is selected. Importantly, the		MRHOF by specifying how an AP is selected. Importantly, the
	calculation of the rank of the node through each candidate neighbor		calculation of the rank of the node through each candidate neighbor
	and the selection of the PP is kept the same as in MRHOF.		and the selection of the PP is kept the same as in MRHOF.
	The ways in which the CA OF modifies 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:
	skipping to change at page 10, line 41 ¶		skipping to change at page 10, line 41 ¶
	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
	[RPL]. The DAG Metric Container option length (DAGMC Length in		[RPL]. 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)|
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| Res | Flags |A|O| PS type | PS Length | |		| Res | Flags |A|O| PS type | PS Length |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |NSA		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| PS IPv6 address(es) ... |		| 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
	skipping to change at page 12, line 46 ¶		skipping to change at page 13, line 5 ¶
	8. IANA Considerations		8. 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.		for Low Power and Lossy Networks (RPL)" registry.
	This proposal also requests the allocation of a new value TBD2 for		This proposal also requests the allocation of a new value TBD2 for
	the "Parent Set" TLV from the Routing Metric/Constraint TLVs sub-		the "Parent Set" TLV from the Routing Metric/Constraint TLVs sub-
	registry from IANA.		registry from IANA.
	9. References		9. Acknowledgments
	9.1. Informative references		We are very grateful to Dominique Barthel, Rahul Jadhav, Fabrice
			Theoleyre, Diego Dujovne, Derek Jianqiang Hou, and Michael Richardson
			for their comments, feedback, and support which lead to many
			improvements to this document. We would also like to thank Tomas
			Lagos Jenschke very much for helping in the implementation and
			evaluation of the proposals of this document.
			10. References
			10.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", Work in Progress, Internet-Draft,		of IEEE 802.15.4", Work in Progress, Internet-Draft,
	draft-ietf-6tisch-architecture-28, 29 October 2019,		draft-ietf-6tisch-architecture-29, 27 August 2020,
	<https://tools.ietf.org/html/draft-ietf-6tisch-		<https://tools.ietf.org/html/draft-ietf-6tisch-
	architecture-28>.		architecture-29>.
	[I-D.papadopoulos-raw-pareo-reqs]		[IEEE802154]
	Papadopoulos, G., Koutsiamanis, R., Montavont, N., and P.		IEEE standard for Information Technology, "IEEE Std.
	Thubert, "Exploiting Packet Replication and Elimination in		802.15.4, Part. 15.4: Wireless Medium Access Control (MAC)
	Complex Tracks in LLNs", Work in Progress, Internet-Draft,		and Physical Layer (PHY) Specifications for Low-Rate
	draft-papadopoulos-raw-pareo-reqs-01, 2 January 2020,		Wireless Personal Area Networks", December 2015,
	<https://tools.ietf.org/html/draft-papadopoulos-raw-pareo-		<http://standards.ieee.org/findstds/
	reqs-01>.		standard/802.15.4-2015.html>.
	[MRHOF] Gnawali, O. and P. Levis, "The Minimum Rank with		[MRHOF] Gnawali, O. and P. Levis, "The Minimum Rank with
	Hysteresis Objective Function", RFC 6719,		Hysteresis Objective Function", RFC 6719,
	DOI 10.17487/RFC6719, September 2012,		DOI 10.17487/RFC6719, September 2012,
	<https://www.rfc-editor.org/info/rfc6719>.		<https://www.rfc-editor.org/info/rfc6719>.
	[OF0] Thubert, P., Ed., "Objective Function Zero for the Routing		[OF0] Thubert, P., Ed., "Objective Function Zero for the Routing
	Protocol for Low-Power and Lossy Networks (RPL)",		Protocol for Low-Power and Lossy Networks (RPL)",
	RFC 6552, DOI 10.17487/RFC6552, March 2012,		RFC 6552, DOI 10.17487/RFC6552, March 2012,
	<https://www.rfc-editor.org/info/rfc6552>.		<https://www.rfc-editor.org/info/rfc6552>.
	skipping to change at page 14, line 5 ¶		skipping to change at page 14, line 21 ¶
	DOI 10.17487/RFC8655, October 2019,		DOI 10.17487/RFC8655, October 2019,
	<https://www.rfc-editor.org/info/rfc8655>.		<https://www.rfc-editor.org/info/rfc8655>.
	[RPL] Winter, T., Ed., Thubert, P., Ed., Brandt, A., Hui, J.,		[RPL] 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,
	DOI 10.17487/RFC6550, March 2012,		DOI 10.17487/RFC6550, March 2012,
	<https://www.rfc-editor.org/info/rfc6550>.		<https://www.rfc-editor.org/info/rfc6550>.
	9.2. Other Informative References
	[IEEE802154]
	IEEE standard for Information Technology, "IEEE Std
	802.15.4 Standard for Low-Rate Wireless Personal Area
	Networks (WPANs)", December 2015.
	Appendix A. Implementation Status		Appendix A. Implementation Status
	A research-stage implementation of the PRE mechanism using the		A research-stage implementation of the PRE mechanism using the
	proposed extension as part of a 6TiSCH IOT use case was developed at		proposed extension as part of a 6TiSCH IOT use case was developed at
	IMT Atlantique, France by Tomas Lagos Jenschke and Remous-Aris		IMT Atlantique, France by Tomas Lagos Jenschke and Remous-Aris
	Koutsiamanis. It was implemented on the open-source Contiki OS and		Koutsiamanis. It was implemented on the open-source Contiki OS and
	tested with the Cooja simulator. The DIO DAGMC NSA extension is		tested with the Cooja simulator. The DIO DAGMC NSA extension is
	implemented with a configurable number of parents from the parent set		implemented with a configurable number of parents from the parent set
	of a node to be reported.		of a node to be reported.
	skipping to change at page 15, line 27 ¶		skipping to change at page 15, line 37 ¶
	Radio Links: Every 60 s, a new Packet Delivery Rate is randomly		Radio Links: Every 60 s, a new Packet Delivery Rate is randomly
	drawn for each link, with a uniform distribution spanning the 70%		drawn for each link, with a uniform distribution spanning the 70%
	to 100% interval.		to 100% interval.
	Traffic Pattern: CBR, S sends one non-fragmented UDP packet every 5		Traffic Pattern: CBR, S sends one non-fragmented UDP packet every 5
	seconds to R.		seconds to R.
	PS extension size: 3 parents.		PS extension size: 3 parents.
	Routing Methods: * RPL: The default RPL non-PRE implementation in		Routing Methods:
	Contiki OS.		* RPL: The default RPL non-PRE implementation in Contiki OS.
	* 2nd ETX: PRE with a parent selection method		* 2nd ETX: PRE with a parent selection method which picks as AP
	which picks as AP the 2nd best parent in the parent set based		the 2nd best parent in the parent set based on ETX.
	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 Packet | Average Traversed | Average |		| Routing | Average Packet | Average Traversed | Average |
	| Method | Delivery Rate (%) | Nodes/packet (#) | Duplications/ |		| Method | Delivery Rate (%) | Nodes/packet (#) | Duplications/ |
	| | | | packet (#) |		| | | | 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 | 97.32 | 9.86 | 18.23 |
	| Strict | | | |		| Strict | | | |
	skipping to change at page 17, line 9 ¶		skipping to change at page 17, line 9 ¶
	may be increased jitter.		may be increased jitter.
	Finally, a network configurator may provide the CA policies with a		Finally, a network configurator may provide the CA policies with a
	preference order of Strict > Medium > Relaxed as a means of falling		preference order of Strict > Medium > Relaxed as a means of falling
	back to more flood-prone policies to maintain reliability.		back to more flood-prone policies to maintain reliability.
	Authors' Addresses		Authors' Addresses
	Remous-Aris Koutsiamanis (editor)		Remous-Aris Koutsiamanis (editor)
	IMT Atlantique		IMT Atlantique
	Office B00 - 126A		Office B215
	2 Rue de la Chataigneraie		4 rue Alfred Kastler, BP 20722
	35510 Cesson-Sevigne - Rennes		44307 Nantes Cedex 3
	France		France
	Phone: +33 299 12 70 49
	Email: aris@ariskou.com		Email: aris@ariskou.com
	Georgios Papadopoulos		Georgios Papadopoulos
	IMT Atlantique		IMT Atlantique
	Office B00 - 114A		Office B00 - 114A
	2 Rue de la Chataigneraie		2 Rue de la Chataigneraie
	35510 Cesson-Sevigne - Rennes		35510 Cesson-Sevigne - Rennes
	France		France
	Phone: +33 299 12 70 04		Phone: +33 299 12 70 04
End of changes. 24 change blocks.
	57 lines changed or deleted		54 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/