< draft-ietf-roll-nsa-extension-02.txt		draft-ietf-roll-nsa-extension-03.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: December 26, 2019 IMT Atlantique		Expires: December 30, 2019 IMT Atlantique
	P. Thubert		P. Thubert
	Cisco		Cisco
	June 24, 2019		June 28, 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-02		draft-ietf-roll-nsa-extension-03
	Abstract		Abstract
	Implementing Packet Replication and Elimination from / to the RPL		Implementing Packet Replication and Elimination from / to the RPL
	root requires the ability to forward copies of packets over different		root 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 a packet to enable this
	functionality.		functionality.
	skipping to change at page 1, line 39 ¶		skipping to change at page 1, line 39 ¶
	Internet-Drafts are working documents of the Internet Engineering		Internet-Drafts are working documents of the Internet Engineering
	Task Force (IETF). Note that other groups may also distribute		Task Force (IETF). Note that other groups may also distribute
	working documents as Internet-Drafts. The list of current Internet-		working documents as Internet-Drafts. The list of current Internet-
	Drafts is at https://datatracker.ietf.org/drafts/current/.		Drafts is at https://datatracker.ietf.org/drafts/current/.
	Internet-Drafts are draft documents valid for a maximum of six months		Internet-Drafts are draft documents valid for a maximum of six months
	and may be updated, replaced, or obsoleted by other documents at any		and may be updated, replaced, or obsoleted by other documents at any
	time. It is inappropriate to use Internet-Drafts as reference		time. It is inappropriate to use Internet-Drafts as reference
	material or to cite them other than as "work in progress."		material or to cite them other than as "work in progress."
	This Internet-Draft will expire on December 26, 2019.		This Internet-Draft will expire on December 30, 2019.
	Copyright Notice		Copyright Notice
	Copyright (c) 2019 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
	skipping to change at page 2, line 33 ¶		skipping to change at page 2, line 33 ¶
	6. Security Considerations . . . . . . . . . . . . . . . . . . . 9		6. Security Considerations . . . . . . . . . . . . . . . . . . . 9
	7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10		7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10
	8. References . . . . . . . . . . . . . . . . . . . . . . . . . 10		8. References . . . . . . . . . . . . . . . . . . . . . . . . . 10
	8.1. Informative references . . . . . . . . . . . . . . . . . 10		8.1. Informative references . . . . . . . . . . . . . . . . . 10
	8.2. Other Informative References . . . . . . . . . . . . . . 11		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		Network-enabled applications in the industrial context must provide
	reliability and predictability, and typically leverage 1+1		stringent guarantees in terms of reliability and predictability. To
	redundancy, aka Packet Replication and Elimination (PRE)		achieve this they typically leverage 1+1 redundancy, also known as
	[I-D.papadopoulos-6tisch-pre-reqs] to achieve their goal. In order		Packet Replication and Elimination (PRE)
	for wireless networks to be able to be used in such applications, the		[I-D.papadopoulos-6tisch-pre-reqs]. Allowing these kinds of
	principles of Deterministic Networking [I-D.ietf-detnet-architecture]		applications to function over wireless networks requires the
	lead to designs that aim at maximizing packet delivery rate and		application of the principles of Deterministic Networking
	minimizing latency and jitter. Additionally, given that the network		[I-D.ietf-detnet-architecture]. This results in designs which aim at
	nodes often do not have an unlimited power supply, energy consumption		maximizing packet delivery rate and minimizing latency and jitter.
	needs to be minimized as well.		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		As an example, to meet this goal, IEEE Std. 802.15.4
	[IEEE802154-2015] provides Time-Slotted Channel Hopping (TSCH), a		[IEEE802154-2015] provides Time-Slotted Channel Hopping (TSCH), a
	mode of operation which uses a fixed communication schedule to allow		mode of operation which uses a common communication schedule based on
	deterministic medium access as well as channel hopping to work around		timeslots to allow deterministic medium access as well as channel
	radio interference. However, since TSCH uses retransmissions in the		hopping to work around radio interference. However, since TSCH uses
	event of a failed transmission, end-to-end delay and jitter		retransmissions in the event of a failed transmission, end-to-end
	performance can deteriorate.		delay and jitter 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 the issues previously highlighted		Std. 802.15.4-TSCH, has worked on the issues previously highlighted
	and produced the "6TiSCH Architecture" [I-D.ietf-6tisch-architecture]		and produced the "6TiSCH Architecture" [I-D.ietf-6tisch-architecture]
	to address that case. Building on this architecture, "Exploiting		to address that case. Building on this architecture, "Exploiting
	Packet 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), to provide a hard bound to the end-to-
	latency, and limit jitter.		end latency, and 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 a 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
	for this subset to be defined, a RPL parent subset selection		for this subset to be defined, a RPL parent subset selection
	mechanism, which falls within the remit of the RPL Objective Function		mechanism, which is among the responsibilities of the RPL Objective
	(OF), needs to have specific path information. The specification of		Function (OF), needs to have specific path information. This
	the transmission of this information is the focus of this document.		document focuses on the specification of the transmission of this
			specific path information.
	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 of the node. The RPL DIO Control
	Control Message is the canonical way of broadcasting this kind of		Message is the canonical way of broadcasting this kind of information
	information and therefore its DAG Metric Container [RFC6551] field is		and therefore its DAG Metric Container [RFC6551] field is used to
	used to append a Node State and Attribute (NSA) object. The node's		append a Node State and Attribute (NSA) object. The node's parent
	parent address set is stored as an optional TLV within the NSA		address set is stored as an optional TLV within the NSA object. This
	object. This specification defines the type value and structure for		specification defines the type value and structure for the parent
	this TLV.		address set 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:
	Packet Replication and Elimination (PRE): The sending of multiple		Packet Replication and Elimination (PRE): A method which transmits
	copies of a packet using multi-path forwarding over a multi-hop		multiple copies of a packet using multi-path forwarding over a
	network and the consolidation of multiple received packet copies		multi-hop network and which consolidates multiple received packet
	to control flooding. See "Exploiting Packet Replication and		copies to control flooding. See "Exploiting Packet Replication
	Elimination in Complex Tracks in 6TiSCH LLNs"		and Elimination in Complex Tracks in 6TiSCH LLNs"
	[I-D.papadopoulos-6tisch-pre-reqs] for more.		[I-D.papadopoulos-6tisch-pre-reqs] for more details.
	Alternative Parent (AP) Selection: The problem of how to select the		Alternative Parent (AP) Selection: The mechanism for choosing the
	next hop target node for a packet copy to be forwarded to when		next hop node to forward a packet copy when replicating packets.
	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 Preferred Parent (PP) node is defined to be the same as
	Preferred Parent (PP) node. Furthermore, to construct an alternative		the RPL DODAG Preferred Parent node. Furthermore, to construct an
	path toward the root, in addition to the PP node, each node in the		alternative path toward the root, in addition to the PP node, each
	network registers an AP node as well from its Parent Set (PS). There		node in the network registers an AP node as well from its Parent Set
	are multiple alternative methods of selecting the AP node,		(PS). There are multiple alternative methods of selecting the AP
	functionality which is included in the operation of the RPL Objective		node. This functionality is included in the operation of the RPL
	Function (OF). A scheme which allows the two paths to remain		Objective Function (OF). A scheme which allows the two paths to
	correlated is detailed here. More specifically, in this scheme a		remain correlated is detailed here. More specifically, in this
	node will select an AP node close to its PP node to allow the		scheme a node will select an AP node close to its PP node to allow
	operation of overhearing between parents. If multiple potential APs		the operation of overhearing between parents. For more details about
	match this condition, the AP with the lowest rank will be registered.		overhearing and its use in this context see Section 4.3.
			"Promiscuous Overhearing" in "Exploiting Packet Replication and
			Elimination in Complex Tracks in 6TiSCH LLNs"
			[I-D.papadopoulos-6tisch-pre-reqs]. If multiple potential APs match
			this condition, the AP with the lowest rank will be registered.
	There are at least three methods of performing the AP selection based		There are at least three methods of performing the AP selection based
	on common ancestors (CA), named Common Ancestor Strict, Common		on common ancestors (CA), named Common Ancestor Strict, Common
	Ancestor Medium, and Common Ancestor Relaxed, depending on how		Ancestor Medium, and Common Ancestor Relaxed, depending on how
	restrictive the selection process is. A more restrictive method will		restrictive the selection process is. A more restrictive method will
	limit flooding but might fail to select an appropriate AP, while a		limit flooding but might fail to select an appropriate AP, while a
	less restrictive one will more often find an appropriate AP but might		less restrictive one will more often find an appropriate AP but might
	increase flooding.		increase flooding.
	3.1. Common Ancestor Strict		3.1. Common Ancestor Strict
	skipping to change at page 10, line 17 ¶		skipping to change at page 10, line 17 ¶
	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-22 (work		of IEEE 802.15.4", draft-ietf-6tisch-architecture-23 (work
	in progress), June 2019.		in progress), June 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-13 (work in progress), May 2019.		detnet-architecture-13 (work in progress), May 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
	skipping to change at page 13, line 26 ¶		skipping to change at page 13, line 26 ¶
	| Strict | | | |		| Strict | | | |
	| CA | 99.66 | 13.75 | 28.86 |		| CA | 99.66 | 13.75 | 28.86 |
	| Medium | | | |		| 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 TLV, i.e., PS) - currently		o Wireshark dissectors (for the optional PS TLV) - currently merged
	merged / in master [2]		/ in master [2]
	Authors' Addresses		Authors' Addresses
	Remous-Aris Koutsiamanis (editor)		Remous-Aris Koutsiamanis (editor)
	IMT Atlantique		IMT Atlantique
	Office B00 - 126A		Office B00 - 126A
	2 Rue de la Chataigneraie		2 Rue de la Chataigneraie
	Cesson-Sevigne - Rennes 35510		Cesson-Sevigne - Rennes 35510
	FRANCE		FRANCE
End of changes. 15 change blocks.
	55 lines changed or deleted		61 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/