< draft-pthubert-detnet-ipv6-hbh-04.txt		draft-pthubert-detnet-ipv6-hbh-05.txt >
	DetNet P. Thubert, Ed.		DetNet P. Thubert, Ed.
	Internet-Draft Cisco Systems		Internet-Draft Cisco Systems
	Intended status: Standards Track 21 June 2021		Intended status: Standards Track 12 August 2021
	Expires: 23 December 2021		Expires: 13 February 2022
	IPv6 Hop-by-Hop Options for DetNet		IPv6 Options for DetNet
	draft-pthubert-detnet-ipv6-hbh-04		draft-pthubert-detnet-ipv6-hbh-05
	Abstract		Abstract
	RFC 8938, the Deterministic Networking Data Plane Framework relies on		RFC 8938, the Deterministic Networking Data Plane Framework relies on
	the 6-tuple to identify an IPv6 flow. But the full DetNet operations		the 6-tuple to identify an IPv6 flow. But the full DetNet operations
	require also the capabilities to signal meta-information such as a		require also the capabilities to signal meta-information such as a
	sequence within that flow, and to transport different types of		sequence within that flow, and to transport different types of
	packets along the same path with the same treatment, e.g.,		packets along the same path with the same treatment, e.g.,
	Operations, Administration, and Maintenance packets and/or multiple		Operations, Administration, and Maintenance packets and/or multiple
	flows with fate and resource sharing. This document introduces new		flows with fate and resource sharing. This document introduces new
	IPv6 Hop-by-Hop options that signal that path and redundancy		IPv6 options that signal that path and redundancy information to the
	information to the intermediate DetNet relays.		intermediate DetNet relay and forwarding nodes.
	Status of This Memo		Status of This Memo
	This Internet-Draft is submitted in full conformance with the		This Internet-Draft is submitted in full conformance with the
	provisions of BCP 78 and BCP 79.		provisions of BCP 78 and BCP 79.
	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 23 December 2021.		This Internet-Draft will expire on 13 February 2022.
	Copyright Notice		Copyright Notice
	Copyright (c) 2021 IETF Trust and the persons identified as the		Copyright (c) 2021 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
	and restrictions with respect to this document. Code Components		and restrictions with respect to this document. Code Components
	extracted from this document must include Simplified BSD License text		extracted from this document must include Simplified BSD License text
	as described in Section 4.e of the Trust Legal Provisions and are		as described in Section 4.e of the Trust Legal Provisions and are
	provided without warranty as described in the Simplified BSD License.		provided without warranty as 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. Applicability . . . . . . . . . . . . . . . . . . . . . . . . 4		3. Applicability . . . . . . . . . . . . . . . . . . . . . . . . 4
	4. The DetNet Options . . . . . . . . . . . . . . . . . . . . . 5		4. The DetNet Options . . . . . . . . . . . . . . . . . . . . . 6
	4.1. DetNet Redundancy Information Option . . . . . . . . . . 6		4.1. DetNet Redundancy Information Option . . . . . . . . . . 6
	4.2. DetNet Path Options . . . . . . . . . . . . . . . . . . . 9		4.2. DetNet Path Options . . . . . . . . . . . . . . . . . . . 10
	4.2.1. DetNet Strict Path Option . . . . . . . . . . . . . . 9		4.2.1. DetNet Strict Path Option . . . . . . . . . . . . . . 10
	4.2.2. DetNet Loose Path Option . . . . . . . . . . . . . . 11		4.2.2. DetNet Loose Path Option . . . . . . . . . . . . . . 12
	4.3. RPL Packet Information . . . . . . . . . . . . . . . . . 12		4.3. RPL Packet Information . . . . . . . . . . . . . . . . . 13
	5. Security Considerations . . . . . . . . . . . . . . . . . . . 12		5. Security Considerations . . . . . . . . . . . . . . . . . . . 13
	6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12		6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13
	6.1. New Subregistry for the Redundancy Type . . . . . . . . . 12		6.1. New Subregistry for the Redundancy Type . . . . . . . . . 13
	6.2. New Hop-by-Hop Options . . . . . . . . . . . . . . . . . 13		6.2. New Hop-by-Hop Options . . . . . . . . . . . . . . . . . 14
	7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 13		7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 14
	8. References . . . . . . . . . . . . . . . . . . . . . . . . . 13		8. References . . . . . . . . . . . . . . . . . . . . . . . . . 14
	8.1. Normative References . . . . . . . . . . . . . . . . . . 14		8.1. Normative References . . . . . . . . . . . . . . . . . . 14
	8.2. Informative References . . . . . . . . . . . . . . . . . 15		8.2. Informative References . . . . . . . . . . . . . . . . . 15
	Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 16		Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 17
	1. Introduction		1. Introduction
	Section 2 of the Deterministic Networking Problem Statement		Section 2 of the Deterministic Networking Problem Statement
	[DetNet-PBST] introduces the concept of Deterministic Networking		[DetNet-PBST] introduces the concept of Deterministic Networking
	(DetNet) to the IETF. DetNet extends the reach of lower layer		(DetNet) to the IETF. DetNet extends the reach of lower layer
	technologies such as Time-Sensitive Networking (TSN) [IEEE 802.1 TSN]		technologies such as Time-Sensitive Networking (TSN) [IEEE 802.1 TSN]
	and Timeslotted Channel Hopping (TSCH) [IEEE Std. 802.15.4] over IPv6		and Timeslotted Channel Hopping (TSCH) [IEEE Std. 802.15.4] over IPv6
	and MPLS [RFC8938], to provide bounded latency and reliability		and MPLS [RFC8938], to provide bounded latency and reliability
	guarantees over an end-to-end layer-3 nailed-down path.		guarantees over an end-to-end layer-3 nailed-down path.
	skipping to change at page 2, line 51 ¶		skipping to change at page 2, line 51 ¶
	Application (User) Plane, the Controller Plane, and the Network		Application (User) Plane, the Controller Plane, and the Network
	Plane. [DetNet-ARCH] places an emphasis on the centralized model		Plane. [DetNet-ARCH] places an emphasis on the centralized model
	whereby a controller instantiates a DetNet state in the routers that		whereby a controller instantiates a DetNet state in the routers that
	is located based on matching information in the packet. For IPv6		is located based on matching information in the packet. For IPv6
	flows, this document proposes a layer-3 signaling to index that		flows, this document proposes a layer-3 signaling to index that
	state, using an IPv6 Extension Header (EH).		state, using an IPv6 Extension Header (EH).
	The "6TiSCH Architecture" [6TiSCH-ARCH] leverages RPL, the "Routing		The "6TiSCH Architecture" [6TiSCH-ARCH] leverages RPL, the "Routing
	Protocol for Low Power and Lossy Networks" [RPL] and introduces		Protocol for Low Power and Lossy Networks" [RPL] and introduces
	concept of a Track as a highly redundant RPL Destination Oriented		concept of a Track as a highly redundant RPL Destination Oriented
	Directed Acyclic Graph (DODAG) rooted at the Track Ingress. A Track		Directed Acyclic Graph (DODAG) rooted at the Track Ingress.
	may for instance be installed using RPL route projection [RPL-PDAO].
	In that case, the TrackId is an index from a namespace associated to		A Track may for instance be installed using RPL route projection
	one IPv6 address of the Track Ingress node, and the Track that an		[RPL-PDAO]. In that case, the TrackId is an index from a namespace
	IPv6 packet follows is signaled by the combination of the source		associated to one IPv6 address of the Track Ingress node, and the
	address (of the Track Ingress node), and the TrackID placed in a RPL		Track that an IPv6 packet follows is signaled by the combination of
	Option [RFC6553] located in an IPv6 Hop-by-Hop (HbH) Options Header		the source address (of the Track Ingress node), and the TrackID
	[IPv6] in the IPv6 packet.		placed in a RPL Option [RFC6553] located in an IPv6 Hop-by-Hop (HbH)
			Options Header [IPv6] in the IPv6 packet.
	The "Reliable and Available Wireless (RAW) Architecture/Framework"		The "Reliable and Available Wireless (RAW) Architecture/Framework"
	[RAW-ARCH], extends the DetNet Network Plane to accomodate one or		[RAW-ARCH], extends the DetNet Network Plane to accomodate one or
	multiple hops of homogeneous or heterogeneous wireless technologies,		multiple hops of homogeneous or heterogeneous wireless technologies,
	e.g. a Wi-Fi6 Mesh or parallel radio access links combining Wi-Fi and		e.g. a Wi-Fi6 Mesh or parallel radio access links combining Wi-Fi and
	5G. The RAW Architecture reuses the concept of Track and introduces		5G. The RAW Architecture reuses the concept of Track and introduces
	a new dataplane component, the Path Selection Engine (PSE), to		a new dataplane component, the Path Selection Engine (PSE), to
	dynamically select a subpath and maintain the required quality of		dynamically select a subpath and maintain the required quality of
	service within a Track in the face of the rapid evolution of the		service within a Track in the face of the rapid evolution of the
	medium properties.		medium properties.
	skipping to change at page 4, line 5 ¶		skipping to change at page 4, line 5 ¶
	The "Deterministic Networking Data Plane Framework" [RFC8938] relies		The "Deterministic Networking Data Plane Framework" [RFC8938] relies
	on the 6-tuple to identify an IPv6 flow. But the full DetNet		on the 6-tuple to identify an IPv6 flow. But the full DetNet
	operations require also the capabilities to signal meta-information		operations require also the capabilities to signal meta-information
	such as a sequence within that flow, and to transport different types		such as a sequence within that flow, and to transport different types
	of packets along the same path with the same treatment. For		of packets along the same path with the same treatment. For
	instance, it is required that Operations, Administration, and		instance, it is required that Operations, Administration, and
	Maintenance (OAM) [RFC6291] packets and/or multiple flows share the		Maintenance (OAM) [RFC6291] packets and/or multiple flows share the
	same fate and resource sharing over the same Track or the same		same fate and resource sharing over the same Track or the same
	Traffic Engineered (TE) [RFC3272] DetNet path.		Traffic Engineered (TE) [RFC3272] DetNet path.
	This document introduces new IPv6 Hop-by-Hop options that signal the		As opposed to the HbH EH, the Destination Option Header (DOH) is only
	needful DetNet path and redundancy information to the intermediate		read by the destination of the packet, which can be one at a time the
	relays in an abstract form that is pure layer-3 and agnostic of the		collection of nodes listed in a Routing Extension Header (RH) if the
	transport layer.		DOH is placed before the RH.
			This document introduces new IPv6 Options, the DetNet Redundancy
			Information Option and the DetNet Path Options, that signal the
			DetNet information to the intermediate DetNet nodes in an abstract
			form, that is pure layer-3 and agnostic of the transport layer. The
			options are placed in either a HbH EH or in a DOH, which happens when
			the next node that needs to process the option is the IPv6
			destination in the IPv6 header.
	This pure layer-3 technique alines DetNet with the IPv6 architecture		This pure layer-3 technique alines DetNet with the IPv6 architecture
	and opens to the progress / extensions done elsewhere for IPv6; e.g.,		and opens to the progress / extensions done elsewhere for IPv6; e.g.,
	if the DetNet path leverages Segment routing (SRv6) [RFC8402] for		if the DetNet path leverages Segment routing (SRv6) [RFC8402] for
	some reason - there are plausible ones in RAW -, the Source Route		some reason - there are plausible ones in RAW -, the Segment Routing
	Header (SRH) will be inserted after the HbH EH by the PE and both are		Header (SRH) [RFC8754] is inserted after the HbH and/or DOH by the PE
	readily accessible for the on-path routers without the need of a		and both are readily accessible for the on-path routers without the
	deeper inspection of the packet (up to and beyond the transport		need of a deeper inspection of the packet (up to and beyond the
	header).		transport header).
			For instance, the DetNet Redundancy Information Option may be placed
			in a DOH EH before an SRH that signals the exhaustive list of the
			Detnet relays along the path of the packet, so every relay can
			process the redundancy information therein, while the DetNet Strict
			Path Option would be placed in an HbH EH to be read by every DeNet
			fowarding node, and intercepted should it strays away from its path.
	2. Terminology		2. Terminology
	Timestamp semantics and timestamp formats used in this document are		Timestamp semantics and timestamp formats used in this document are
	defined in "Guidelines for Defining Packet Timestamps" [RFC8877].		defined in "Guidelines for Defining Packet Timestamps" [RFC8877].
	The Deterministic Networking terms used in this document are defined		The Deterministic Networking terms used in this document are defined
	in the "Deterministic Networking Architecture" [DetNet-ARCH].		in the "Deterministic Networking Architecture" [DetNet-ARCH].
	The terms Track and TrackID are defined in the "6TiSCH Architecture"		The terms Track and TrackID are defined in the "6TiSCH Architecture"
	skipping to change at page 6, line 4 ¶		skipping to change at page 6, line 25 ¶
	an information that plays the same role at another layer, in which		an information that plays the same role at another layer, in which
	case the format of the information is opaque.		case the format of the information is opaque.
	The reliability information may be inherited from another layer as		The reliability information may be inherited from another layer as
	long as the value is guaranteed to be unique within a reasonable set		long as the value is guaranteed to be unique within a reasonable set
	of sequential packet so all packets with the same value are		of sequential packet so all packets with the same value are
	redundant. Timestamping can be used as an alternate sequencing		redundant. Timestamping can be used as an alternate sequencing
	technique, that avoids maintaining per-path state at the path		technique, that avoids maintaining per-path state at the path
	ingress, which is feasible for nodes that maintain a very precise		ingress, which is feasible for nodes that maintain a very precise
	sense of time (e.g., from GPS or PTP) for their DetNet operations.		sense of time (e.g., from GPS or PTP) for their DetNet operations.
	As long as the time granularity is in the order of a few bytes		As long as the time granularity is in the order of a few bytes
	transmission, the system timestamp provides an absolute sense of		transmission, the system timestamp provides an absolute sense of
	ordering over a very long period across all paths for which this node		ordering over a very long period across all paths for which this node
	is ingress, and thus within any of those. Alternatively, the draft		is ingress, and thus within any of those. Alternatively, the draft
	allows to combine a rough time stamp (e.g., from a system clock		allows to combine a rough time stamp (e.g., from a system clock
	synchronized by NTP) and a sequence counter that differntiates the		synchronized by NTP) and a sequence counter that differntiates the
	packets that are stamped within the timer resolution.		packets that are stamped within the timer resolution.
	If a DetNet Path option (see Section 4.2), including the RPL Option,		If a DetNet Path option (see Section 4.2), including the RPL Option,
	is present in the same HbH Option Header as a DetNet Redundancy		is present in the same HbH Option Header as a DetNet Redundancy
	Information option (see Section 4.1), then the redundancy information		Information option (see Section 4.1), then the redundancy information
	applies to the signaled path across all flows that traverse that		applies to the signaled path across all flows that traverse that
	path; else the redundancy information applies to the flow indicated		path; else the redundancy information applies to the flow indicated
	by the 6-tuple [RFC8938].		by the 6-tuple [RFC8938].
	4.1. DetNet Redundancy Information Option		4.1. DetNet Redundancy Information Option
	The DetNet Redundancy Information Option helps discriminate copies of		The DetNet Redundancy Information Option helps discriminate copies of
	a same packet vs. different packets, and is useful for service-		a same packet vs. different packets, and is useful for service-
	sublayer Packet Replication Elimination and Ordering Functions		sublayer Packet Replication Elimination and Ordering Functions
	(PREOF). The typical expression redundancy information is a sequence		(PREOF). The option may be placed either in an HbH or a DoH EH,
	counter, but it is not the only way to identify a packet. It is also		e.g., prior to a Segment Routing Header (SRH) [RFC8754] that lists
	possible that a packet is divided in elements such as network-coded		the DetNet relays. A sequence counter is probably the most typical
	fragments. In that case, the pieces are discriminated with an opaque		expression of the redundancy information, but it is not the only way
	8-bit fragment tag.		to identify a packet and/or enable reordering, e.g., a timestamp can
			be seen as a large sequence counter with gaps.
			It is also possible that a packet is divided in elements such as
			network-coded fragments. In that case, the pieces are discriminated
			with an opaque 8-bit fragment tag. The goal is to retain one copy of
			each fragment but not reorder them.
	A packet sequence can be expressed uniquely as a wrapping counter,		A packet sequence can be expressed uniquely as a wrapping counter,
	represented as an unsigned integer in the option. In that case, the		represented as an unsigned integer in the option. In that case, the
	size of the representation MUST be large enough to cover at least 3		size of the representation MUST be large enough to cover at least 3
	times the upper bound on out-of-order packet delivery in terms of		times the upper bound on out-of-order packet delivery in terms of
	number of packets. The sequence counter may be copied from a field		number of packets. The sequence counter may be copied from a field
	in another protocol, and it is possible that the value 0 is reserved		in another protocol, and it is possible that the value 0 is reserved
	when wrapping, to the option offers both possibilities, wrapping to		when wrapping, to the option offers both possibilities, wrapping to
	either 0 or to 1.		either 0 or to 1.
	skipping to change at page 9, line 38 ¶		skipping to change at page 10, line 36 ¶
	DetNet state does not exist then the packet cannot be forwarded.		DetNet state does not exist then the packet cannot be forwarded.
	4.2.1. DetNet Strict Path Option		4.2.1. DetNet Strict Path Option
	In complement to the RPL option, this specification defines a		In complement to the RPL option, this specification defines a
	protocol-independent Strict Path Identifier, which is also taken from		protocol-independent Strict Path Identifier, which is also taken from
	a namespace indicated by the IPv6 source address of the packet.		a namespace indicated by the IPv6 source address of the packet.
	The DetNet Strict Path Option is to be used in a limited domain and		The DetNet Strict Path Option is to be used in a limited domain and
	all routers along the path are expected to support the option. The		all routers along the path are expected to support the option. The
			option is placed in an HbH EH to be seen by all routers on path. The
	path indicated therein may also be used by the service sublayer, to		path indicated therein may also be used by the service sublayer, to
	signal the scope where the redundancy information is unique across a		signal the scope where the redundancy information is unique across a
	number of packets large enough to ensure that a forwarding node never		number of packets large enough to ensure that a forwarding node never
	has to handle different packets with the same redundancy information,		has to handle different packets with the same redundancy information,
	though the same value may be found for packets with a different path		though the same value may be found for packets with a different path
	information.		information.
	The typical DetNet path is typically contained under a single		The typical DetNet path is typically contained under a single
	administrative control or within a closed group of administrative		administrative control or within a closed group of administrative
	control; these include campus-wide networks and private WANs		control; these include campus-wide networks and private WANs
	skipping to change at page 11, line 17 ¶		skipping to change at page 12, line 11 ¶
	Strict Path ID: 16-bit identifier of the DetNet Path, taken from a		Strict Path ID: 16-bit identifier of the DetNet Path, taken from a
	local namespace associated with the IPv6 source address of the		local namespace associated with the IPv6 source address of the
	packet.		packet.
	4.2.2. DetNet Loose Path Option		4.2.2. DetNet Loose Path Option
	The DetNet Loose Path Option transports a Loose Path identifier which		The DetNet Loose Path Option transports a Loose Path identifier which
	is taken from a namespace indicated by the Origin Autonomous System		is taken from a namespace indicated by the Origin Autonomous System
	(AS). When the DetNet path is contained within a single AS, the		(AS). When the DetNet path is contained within a single AS, the
	Origin Autonomous System field can be left to 0 indicating local AS.		Origin Autonomous System field can be left to 0 indicating local AS.
			The option may be placed either in an HbH or a DoH EH, but the
			preferred method is a DOH that precedes an RH such as SRH.
	The DetNet Loose Path Option is to be used to signal a path that may		The DetNet Loose Path Option is to be used to signal a path that may
	be loose and may exceed the boundaries of a local domain; a portion		be loose and may exceed the boundaries of a local domain; a portion
	of the hops may traverse routers in the wider internet that will not		of the hops may traverse routers in the wider internet that will not
	leverage the option and are expected to ignore it.		leverage the option and are expected to ignore it.
	An intermediate router that supports the DetNet Loose Path Option but		An intermediate router that supports the DetNet Loose Path Option but
	is missing the necessary state to forward along the indicated path		is missing the necessary state to forward along the indicated path
	must ignore the DetNet Loose Path Option.		must ignore the DetNet Loose Path Option.
	skipping to change at page 14, line 36 ¶		skipping to change at page 15, line 17 ¶
	RFC 8126, DOI 10.17487/RFC8126, June 2017,		RFC 8126, DOI 10.17487/RFC8126, June 2017,
	<https://www.rfc-editor.org/info/rfc8126>.		<https://www.rfc-editor.org/info/rfc8126>.
	[RFC8877] Mizrahi, T., Fabini, J., and A. Morton, "Guidelines for		[RFC8877] Mizrahi, T., Fabini, J., and A. Morton, "Guidelines for
	Defining Packet Timestamps", RFC 8877,		Defining Packet Timestamps", RFC 8877,
	DOI 10.17487/RFC8877, September 2020,		DOI 10.17487/RFC8877, September 2020,
	<https://www.rfc-editor.org/info/rfc8877>.		<https://www.rfc-editor.org/info/rfc8877>.
	[HbH-UPDT] Hinden, R. M. and G. Fairhurst, "IPv6 Hop-by-Hop Options		[HbH-UPDT] Hinden, R. M. and G. Fairhurst, "IPv6 Hop-by-Hop Options
	Processing Procedures", Work in Progress, Internet-Draft,		Processing Procedures", Work in Progress, Internet-Draft,
	draft-hinden-6man-hbh-processing-00, 3 December 2020,		draft-hinden-6man-hbh-processing-01, 2 June 2021,
	<https://tools.ietf.org/html/draft-hinden-6man-hbh-		<https://datatracker.ietf.org/doc/html/draft-hinden-6man-
	processing-00>.		hbh-processing-01>.
	[DetNet-ARCH]		[DetNet-ARCH]
	Finn, N., Thubert, P., Varga, B., and J. Farkas,		Finn, N., Thubert, P., Varga, B., and J. Farkas,
	"Deterministic Networking Architecture", RFC 8655,		"Deterministic Networking Architecture", RFC 8655,
	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>.
	[RFC9008] Robles, M.I., Richardson, M., and P. Thubert, "Using RPI		[RFC9008] Robles, M.I., Richardson, M., and P. Thubert, "Using RPI
	Option Type, Routing Header for Source Routes, and IPv6-		Option Type, Routing Header for Source Routes, and IPv6-
	in-IPv6 Encapsulation in the RPL Data Plane", RFC 9008,		in-IPv6 Encapsulation in the RPL Data Plane", RFC 9008,
	DOI 10.17487/RFC9008, April 2021,		DOI 10.17487/RFC9008, April 2021,
	<https://www.rfc-editor.org/info/rfc9008>.		<https://www.rfc-editor.org/info/rfc9008>.
	[6TiSCH-ARCH]		[6TiSCH-ARCH]
	Thubert, P., Ed., "An Architecture for IPv6 over the Time-		Thubert, P., Ed., "An Architecture for IPv6 over the Time-
	Slotted Channel Hopping Mode of IEEE 802.15.4 (6TiSCH)",		Slotted Channel Hopping Mode of IEEE 802.15.4 (6TiSCH)",
	RFC 9030, DOI 10.17487/RFC9030, May 2021,		RFC 9030, DOI 10.17487/RFC9030, May 2021,
	<https://www.rfc-editor.org/info/rfc9030>.		<https://www.rfc-editor.org/info/rfc9030>.
	[RAW-ARCH] Thubert, P., Papadopoulos, G. Z., and R. Buddenberg,		[RAW-ARCH] Thubert, P., Papadopoulos, G. Z., and L. Berger, "Reliable
	"Reliable and Available Wireless Architecture/Framework",		and Available Wireless Architecture/Framework", Work in
	Work in Progress, Internet-Draft, draft-pthubert-raw-		Progress, Internet-Draft, draft-pthubert-raw-architecture-
	architecture-05, 15 November 2020,		09, 7 July 2021, <https://datatracker.ietf.org/doc/html/
	<https://tools.ietf.org/html/draft-pthubert-raw-		draft-pthubert-raw-architecture-09>.
	architecture-05>.
	8.2. Informative References		8.2. Informative References
	[RPL-PDAO] Thubert, P., Jadhav, R. A., and M. Gillmore, "Root		[RPL-PDAO] Thubert, P., Jadhav, R. A., and M. Gillmore, "Root
	initiated routing state in RPL", Work in Progress,		initiated routing state in RPL", Work in Progress,
	Internet-Draft, draft-ietf-roll-dao-projection-16, 15		Internet-Draft, draft-ietf-roll-dao-projection-19, 27 July
	January 2021, <https://tools.ietf.org/html/draft-ietf-		2021, <https://datatracker.ietf.org/doc/html/draft-ietf-
	roll-dao-projection-16>.		roll-dao-projection-19>.
			[RFC3272] Awduche, D., Chiu, A., Elwalid, A., Widjaja, I., and X.
			Xiao, "Overview and Principles of Internet Traffic
			Engineering", RFC 3272, DOI 10.17487/RFC3272, May 2002,
			<https://www.rfc-editor.org/info/rfc3272>.
	[RFC6291] Andersson, L., van Helvoort, H., Bonica, R., Romascanu,		[RFC6291] Andersson, L., van Helvoort, H., Bonica, R., Romascanu,
	D., and S. Mansfield, "Guidelines for the Use of the "OAM"		D., and S. Mansfield, "Guidelines for the Use of the "OAM"
	Acronym in the IETF", BCP 161, RFC 6291,		Acronym in the IETF", BCP 161, RFC 6291,
	DOI 10.17487/RFC6291, June 2011,		DOI 10.17487/RFC6291, June 2011,
	<https://www.rfc-editor.org/info/rfc6291>.		<https://www.rfc-editor.org/info/rfc6291>.
	[RFC5905] Mills, D., Martin, J., Ed., Burbank, J., and W. Kasch,		[RFC5905] Mills, D., Martin, J., Ed., Burbank, J., and W. Kasch,
	"Network Time Protocol Version 4: Protocol and Algorithms		"Network Time Protocol Version 4: Protocol and Algorithms
	Specification", RFC 5905, DOI 10.17487/RFC5905, June 2010,		Specification", RFC 5905, DOI 10.17487/RFC5905, June 2010,
	skipping to change at page 15, line 47 ¶		skipping to change at page 16, line 31 ¶
	[RFC8402] Filsfils, C., Ed., Previdi, S., Ed., Ginsberg, L.,		[RFC8402] Filsfils, C., Ed., Previdi, S., Ed., Ginsberg, L.,
	Decraene, B., Litkowski, S., and R. Shakir, "Segment		Decraene, B., Litkowski, S., and R. Shakir, "Segment
	Routing Architecture", RFC 8402, DOI 10.17487/RFC8402,		Routing Architecture", RFC 8402, DOI 10.17487/RFC8402,
	July 2018, <https://www.rfc-editor.org/info/rfc8402>.		July 2018, <https://www.rfc-editor.org/info/rfc8402>.
	[DetNet-PBST]		[DetNet-PBST]
	Finn, N. and P. Thubert, "Deterministic Networking Problem		Finn, N. and P. Thubert, "Deterministic Networking Problem
	Statement", RFC 8557, DOI 10.17487/RFC8557, May 2019,		Statement", RFC 8557, DOI 10.17487/RFC8557, May 2019,
	<https://www.rfc-editor.org/info/rfc8557>.		<https://www.rfc-editor.org/info/rfc8557>.
	[RFC3272] Awduche, D., Chiu, A., Elwalid, A., Widjaja, I., and X.		[RFC8754] Filsfils, C., Ed., Dukes, D., Ed., Previdi, S., Leddy, J.,
	Xiao, "Overview and Principles of Internet Traffic		Matsushima, S., and D. Voyer, "IPv6 Segment Routing Header
	Engineering", RFC 3272, DOI 10.17487/RFC3272, May 2002,		(SRH)", RFC 8754, DOI 10.17487/RFC8754, March 2020,
	<https://www.rfc-editor.org/info/rfc3272>.		<https://www.rfc-editor.org/info/rfc8754>.
	[RFC8938] Varga, B., Ed., Farkas, J., Berger, L., Malis, A., and S.		[RFC8938] Varga, B., Ed., Farkas, J., Berger, L., Malis, A., and S.
	Bryant, "Deterministic Networking (DetNet) Data Plane		Bryant, "Deterministic Networking (DetNet) Data Plane
	Framework", RFC 8938, DOI 10.17487/RFC8938, November 2020,		Framework", RFC 8938, DOI 10.17487/RFC8938, November 2020,
	<https://www.rfc-editor.org/info/rfc8938>.		<https://www.rfc-editor.org/info/rfc8938>.
	[IEEE Std. 802.15.4]		[IEEE Std. 802.15.4]
	IEEE standard for Information Technology, "IEEE Std.		IEEE standard for Information Technology, "IEEE Std.
	802.15.4, Part. 15.4: Wireless Medium Access Control (MAC)		802.15.4, Part. 15.4: Wireless Medium Access Control (MAC)
	and Physical Layer (PHY) Specifications for Low-Rate		and Physical Layer (PHY) Specifications for Low-Rate
End of changes. 18 change blocks.
	58 lines changed or deleted		86 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/