rfc9914v1.txt		rfc9914.txt
	Internet Engineering Task Force (IETF) P. Thubert, Ed.		Internet Engineering Task Force (IETF) P. Thubert, Ed.
	Request for Comments: 9914		Request for Comments: 9914 Independent
	Updates: 6550, 6553, 8138 R.A. Jadhav		Updates: 6550, 6553, 8138 R.A. Jadhav
	Category: Standards Track AccuKnox		Category: Standards Track AccuKnox
	ISSN: 2070-1721 M. Richardson		ISSN: 2070-1721 M. Richardson
	Sandelman		Sandelman
	February 2026		March 2026
	Root-Initiated Routing State in the Routing Protocol for Low-Power and		Root-Initiated Routing State in the Routing Protocol for Low-Power and
	Lossy Networks (RPL)		Lossy Networks (RPL)
	Abstract		Abstract
	The Routing Protocol for Low-Power and Lossy Networks (RPL) (RFC		The Routing Protocol for Low-Power and Lossy Networks (RPL) (RFC
	6550) enables data packet routing along a Destination-Oriented		6550) enables data packet routing along a Destination-Oriented
	Directed Acyclic Graph (DODAG). However, the default route		Directed Acyclic Graph (DODAG). However, the default route
	establishment mechanism relies on hop-by-hop forwarding along the		establishment mechanism relies on hop-by-hop forwarding along the
	DODAG, which may not always provide optimal routing efficiency. This		DODAG, which may not always provide optimal routing efficiency. This
	document introduces the concept of Destination Advertisement Object		document introduces the concept of Destination Advertisement Object
	(DAO) Projection, a mechanism that allows a RPL root or an external		(DAO) Projection, a mechanism that allows a RPL Root or an external
	controller to install optimized routes within the RPL domain. DAO		controller to install optimized routes within the RPL domain. DAO
	Projections enable the creation of optimized unicast or multicast		Projections enable the creation of optimized unicast or multicast
	routes that do not strictly follow the DODAG structure, thereby		routes that do not strictly follow the DODAG structure, thereby
	improving routing efficiency, reliability, availability, and resource		improving routing efficiency, reliability, availability, and resource
	utilization in the RPL domain. This document specifies two types of		utilization in the RPL domain. This document specifies two types of
	Projected Routes (P-Routes) -- Storing Mode and Non-Storing Mode --		Projected Routes (P-Routes) -- Storing Mode and Non-Storing Mode --
	and outlines the signaling procedures necessary to establish,		and outlines the signaling procedures necessary to establish,
	maintain, and remove these routes. This document updates RFCs 6550,		maintain, and remove these routes. This document updates RFCs 6550,
	6553, and 8138.		6553, and 8138.
	skipping to change at line 66 ¶		skipping to change at line 66 ¶
	to this document. Code Components extracted from this document must		to this document. Code Components extracted from this document must
	include Revised BSD License text as described in Section 4.e of the		include Revised BSD License text as described in Section 4.e of the
	Trust Legal Provisions and are provided without warranty as described		Trust Legal Provisions and are provided without warranty as described
	in the Revised BSD License.		in the Revised BSD License.
	Table of Contents		Table of Contents
	1. Introduction		1. Introduction
	2. Terminology		2. Terminology
	2.1. Requirements Language		2.1. Requirements Language
	2.2. References		2.2. Terms and Concepts
	2.3. Glossary		2.3. Glossary
	2.4. Domain Terms		2.4. Domain Terms
	2.4.1. Projected Route		2.4.1. Projected Route
	2.4.2. Projected DAO		2.4.2. Projected DAO
	2.4.3. Path		2.4.3. Path
	2.4.4. Routing Stretch		2.4.4. Routing Stretch
	2.4.5. Track		2.4.5. Track
	3. Context and Goal		3. Context and Goal
	3.1. RPL Applicability		3.1. RPL Applicability
	3.2. Multi-Topology Routing and Loop Avoidance		3.2. Multi-Topology Routing and Loop Avoidance
	skipping to change at line 89 ¶		skipping to change at line 89 ¶
	3.3.2. Forward Routes		3.3.2. Forward Routes
	3.4. On Tracks		3.4. On Tracks
	3.4.1. Building Tracks with RPL		3.4.1. Building Tracks with RPL
	3.4.2. Tracks and RPL Instances		3.4.2. Tracks and RPL Instances
	3.5. Path Signaling		3.5. Path Signaling
	3.5.1. Using Storing Mode Segments		3.5.1. Using Storing Mode Segments
	3.5.2. Using Non-Storing Mode Joining Tracks		3.5.2. Using Non-Storing Mode Joining Tracks
	3.6. Complex Tracks		3.6. Complex Tracks
	3.7. Scope and Expectations		3.7. Scope and Expectations
	3.7.1. External Dependencies		3.7.1. External Dependencies
	3.7.2. Positioning Versus Related IETF Standards		3.7.2. Relationship to Other IETF Specifications
	4. Extending Existing RFCs		4. Extending and Amending Existing RFCs
	4.1. Extending RPL RFC 6550		4.1. Extending RFC 6550
	4.1.1. Projected DAO		4.1.1. Projected DAO
	4.1.2. Projected DAO-ACK		4.1.2. Projected DAO-ACK
	4.1.3. Via Information Option		4.1.3. Via Information Option
	4.1.4. Sibling Information Option		4.1.4. Sibling Information Option
	4.1.5. P-DAO Request		4.1.5. P-DAO Request
	4.1.6. Amending the RPI		4.1.6. Amending the RPI
	4.1.7. Additional Flag in the RPL DODAG Configuration Option		4.1.7. Additional Flag in the RPL DODAG Configuration Option
	4.2. Extending RPL RFC 6553		4.2. Extending RFC 6553
	4.3. Extending RPL RFC 8138		4.3. Extending RFC 8138
	5. New RPL Control Messages and Options		5. New RPL Control Messages and Options
	5.1. New P-DAO Request Control Message		5.1. New P-DAO Request Control Message
	5.2. New PDR-ACK Control Message		5.2. New PDR-ACK Control Message
	5.3. Via Information Options		5.3. Via Information Options
	5.4. Sibling Information Option		5.4. Sibling Information Option
	6. Root-Initiated Routing State		6. Root-Initiated Routing State
	6.1. RPL Network Setup		6.1. RPL Network Setup
	6.2. Requesting a Track		6.2. Requesting a Track
	6.3. Identifying a Track		6.3. Identifying a Track
	6.4. Installing a Track		6.4. Installing a Track
	skipping to change at line 156 ¶		skipping to change at line 156 ¶
	12.2. Informative References		12.2. Informative References
	Acknowledgments		Acknowledgments
	Authors' Addresses		Authors' Addresses
	1. Introduction		1. Introduction
	The Routing Protocol for Low-Power and Lossy Networks (RPL) [RPL], is		The Routing Protocol for Low-Power and Lossy Networks (RPL) [RPL], is
	a Distance Vector protocol that is well-suited for application in a		a Distance Vector protocol that is well-suited for application in a
	variety of low-energy Internet of Things (IoT) networks where		variety of low-energy Internet of Things (IoT) networks where
	constrained nodes cannot maintain the full view of the topology and		constrained nodes cannot maintain the full view of the topology and
	stretched P2P paths are acceptable (versus the signaling and state		stretched paths are acceptable (as opposed to the signaling and state
	overhead involved in maintaining the shortest paths across).		overhead involved in maintaining the shortest paths across).
	Additionally, RPL is anisotropic, meaning that its operation depends		Additionally, RPL is anisotropic, meaning that its operation depends
	on the orientation of the links, down from or up towards the Root,		on the orientation of the links, down from or up towards the Root,
	with the default route advertised down and more-specific paths		with the default route advertised down and more-specific paths
	advertised up along a limited set of links.		advertised up along a limited set of links.
	RPL forms Destination-Oriented Directed Acyclic Graphs (DODAGs) in		RPL forms Destination-Oriented Directed Acyclic Graphs (DODAGs) in
	which the Root often acts as the border router to connect the RPL		which the Root often acts as the border router to connect the RPL
	domain to the IP backbone. Routers inside the DODAG route along the		domain to the IP backbone. Routers inside the DODAG route along the
	graph up towards the Root for the default route and down towards		graph up towards the Root for the default route and down towards
	skipping to change at line 220 ¶		skipping to change at line 220 ¶
	The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",		The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
	"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and		"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
	"OPTIONAL" in this document are to be interpreted as described in		"OPTIONAL" in this document are to be interpreted as described in
	BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all		BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all
	capitals, as shown here.		capitals, as shown here.
	In addition, the terms "Extends" and "Amends" are used as per		In addition, the terms "Extends" and "Amends" are used as per
	[NEW-TAGS], Section 3.		[NEW-TAGS], Section 3.
	2.2. References		2.2. Terms and Concepts
	In this document, readers will encounter terms and concepts that are		In this document, readers will encounter terms and concepts that are
	discussed in "RPL: IPv6 Routing Protocol for Low-Power and Lossy		discussed in the following:
	Networks" [RPL]; "An Architecture for IPv6 over the Time-Slotted
	Channel Hopping Mode of IEEE 802.15.4 (6TiSCH)" [RFC9030];		* "RPL: IPv6 Routing Protocol for Low-Power and Lossy Networks"
	"Deterministic Networking Architecture" [RFC8655]; "Using RPI Option		[RPL]
	Type, Routing Header for Source Routes, and IPv6-in-IPv6
	Encapsulation in the RPL Data Plane" [RFC9008]; "Reliable and		* "An Architecture for IPv6 over the Time-Slotted Channel Hopping
	Available Wireless (RAW) Architecture" [RAW-ARCH]; and "Terms Used in		Mode of IEEE 802.15.4 (6TiSCH)" [RFC9030]
	Routing for Low-Power and Lossy Networks" [RFC7102]. The 6TiSCH,
	Deterministic Networking (DetNet), and RAW architectures utilize the		* "Deterministic Networking Architecture" [RFC8655]
	terms "Track" and "recovery graph" to represent the same concept even
	though they are in different environments. This document uses		* "Using RPI Option Type, Routing Header for Source Routes, and
	"Track" to represent that concept and only builds Tracks that are		IPv6-in-IPv6 Encapsulation in the RPL Data Plane" [RFC9008]
	DODAGs, meaning that all links are oriented from Ingress to Egress.
	This specification also utilizes the terms "segment" and "protection		* "Reliable and Available Wireless (RAW) Architecture" [RAW-ARCH]
	path", which are also defined in the RAW architecture.
			* "Terms Used in Routing for Low-Power and Lossy Networks" [RFC7102]
			The 6TiSCH, Deterministic Networking (DetNet), and RAW architectures
			utilize the terms "Track" and "recovery graph" to represent the same
			concept even though they are in different environments. This
			document uses "Track" to represent that concept and only builds
			Tracks that are DODAGs, meaning that all links are oriented from
			ingress to egress. This specification also utilizes the terms
			"segment" and "protection path", which are also defined in the RAW
			architecture.
	As opposed to routing trees, RPL DODAGs are typically constructed to		As opposed to routing trees, RPL DODAGs are typically constructed to
	provide redundancy and dynamically adapt the forwarding operation to		provide redundancy and dynamically adapt the forwarding operation to
	the state of the Low-Power and Lossy Network (LLN) links. Note that		the state of the Low-Power and Lossy Network (LLN) links. Note that
	the plain forwarding operation over DODAGs does not provide		the plain forwarding operation over DODAGs does not provide
	redundancy for all nodes, since at least the node nearest to the Root		redundancy for all nodes, since at least the node nearest to the Root
	does not have an alternate feasible successor.		does not have an alternate feasible successor.
	RAW solves that problem by defining protection paths that can be		RAW solves that problem by defining protection paths that can be
	interleaved to form new paths that can be activated dynamically upon		interleaved to form new paths that can be activated dynamically upon
	failures. This requires additional control to take the routing		failures. This requires additional control in order to make the
	decision early enough along the Track to route around the failure.		routing decision early enough along the Track to route around the
			failure.
	RAW only uses single-ended DODAGs, meaning that they can be reversed		RAW only uses single-ended DODAGs, meaning that they can be reversed
	in another DODAG by reversing all the links. The Ingress of the		in another DODAG by reversing all the links. The ingress of the
	Track is the Root of the DODAG, whereas the Egress is the Root of the		Track is the Root of the DODAG, whereas the egress is the Root of the
	reversed DODAG. From the RAW perspective, single-ended DODAGs are		reversed DODAG. From the RAW perspective, single-ended DODAGs are
	special Tracks that only have forward links, and that can be		special Tracks that only have forward links, and that can be
	leveraged to provide protection services by defining destination-		leveraged to provide protection services by defining destination-
	oriented protection paths within the DODAG.		oriented protection paths within the DODAG.
	2.3. Glossary		2.3. Glossary
	This document often uses the following abbreviations:		This document often uses the following abbreviations:
	6LR: 6LoWPAN Router (e.g., a RPL router in an LLN)
	6LoRH: 6LoWPAN Routing Header		6LoRH: 6LoWPAN Routing Header
	ARQ: Automatic Repeat Request (in other words, retries)		6LR: 6LoWPAN Router (e.g., a RPL router in an LLN)
	FEC: Forward Error Correction
	HARQ: Hybrid Automatic Repeat Request (combines FEC and ARQ)		ARQ: Automatic Repeat Request (in other words, retries)
	CMO: Control Message Option		CMO: Control Message Option
			DAG: Directed Acyclic Graph
	DAO: Destination Advertisement Object		DAO: Destination Advertisement Object
	DAG: Directed Acyclic Graph		DIO: DODAG Information Object
	DODAG: Destination-Oriented Directed Acyclic Graph. A DAG with		DODAG: Destination-Oriented Directed Acyclic Graph. A DAG with
	only one vertex (i.e., node) that has no outgoing edge		only one vertex (i.e., node) that has no outgoing edge
	(i.e., link).		(i.e., link).
			FEC: Forward Error Correction
	GUA: Global Unicast Address		GUA: Global Unicast Address
			HARQ: Hybrid Automatic Repeat Request (combines FEC and ARQ)
	LLN: Low-Power and Lossy Network		LLN: Low-Power and Lossy Network
	MOP: Mode of Operation		MOP: Mode of Operation
			NSM-VIO: Non-Storing Mode Via Information Option. Source-routed
			VIO used in Non-Storing Mode P-DAO messages.
	P-DAO: Projected DAO		P-DAO: Projected DAO
	P-Route: Projected Route		P-Route: Projected Route
	PDR: P-DAO Request
	PCE: Path Computation Element		PCE: Path Computation Element
	PLR: Point of Local Repair		PDAOReq: P-DAO Request
	RAN: RPL-Aware Node (either a RPL router or a RPL-Aware Leaf)		PLR: Point of Local Repair
	RAL: RPL-Aware Leaf		RAL: RPL-Aware Leaf
			RAN: RPL-Aware Node (either a RPL router or a RPL-Aware Leaf)
	RH: Routing Header		RH: Routing Header
	RIB: Routing Information Base (i.e., the routing table)		RIB: Routing Information Base (i.e., the routing table)
	RPI: RPL Packet Information		RPI: RPL Packet Information
	RPL: Routing Protocol for Low-Power and Lossy Networks		RPL: Routing Protocol for Low-Power and Lossy Networks
	RTO: RPL Target Option		RTO: RPL Target Option
	RUL: RPL-Unaware Leaf		RUL: RPL-Unaware Leaf
	SIO: Sibling Information Option		SIO: Sibling Information Option
	ULA: Unique Local Address
	NSM-VIO: Non-Storing Mode Via Information Option. Source-routed
	VIO used in Non-Storing Mode P-DAO messages.
	SLO: Service Level Objective		SLO: Service Level Objective
			SM-VIO: Storing Mode Via Information Option. Strict VIO used in
			Storing Mode P-DAO messages.
	SRH: Source Routing Header (i.e., IPv6 RH type 3); see		SRH: Source Routing Header (i.e., IPv6 RH type 3); see
	Section 2.4.5.7.2.		Section 2.4.5.7.2.
	SRH-6LoRH: Source Routing Header 6LoRH. A compressed form of SRH		SRH-6LoRH: Source Routing Header 6LoRH. A compressed form of SRH
	defined in "IPv6 over Low-Power Wireless Personal Area		defined in "IPv6 over Low-Power Wireless Personal Area
	Network (6LoWPAN) Routing Header" [RFC8138].		Network (6LoWPAN) Routing Header" [RFC8138].
	TIO: Transit Information Option		TIO: Transit Information Option
	SM-VIO: Storing Mode Via Information Option. Strict VIO used in		ULA: Unique Local Address
	Storing Mode P-DAO messages.
	VIO: Via Information Option. It can be an SM-VIO or NSM-VIO.		VIO: Via Information Option. It can be an SM-VIO or NSM-VIO.
	2.4. Domain Terms		2.4. Domain Terms
	This specification uses the terminology defined in the sections that		This specification uses the terminology defined in the sections that
	follow.		follow.
	2.4.1. Projected Route		2.4.1. Projected Route
	skipping to change at line 367 ¶		skipping to change at line 380 ¶
	Quoting (non-normatively) the definition of path in Section 1.3.3 of		Quoting (non-normatively) the definition of path in Section 1.3.3 of
	[INT-ARCH]:		[INT-ARCH]:
	| At a given moment, all the IP datagrams from a particular source		| At a given moment, all the IP datagrams from a particular source
	| host to a particular destination host will typically traverse the		| host to a particular destination host will typically traverse the
	| same sequence of gateways. We use the term "path" for this		| same sequence of gateways. We use the term "path" for this
	| sequence. Note that a path is uni-directional; it is not unusual		| sequence. Note that a path is uni-directional; it is not unusual
	| to have different paths in the two directions between a given host		| to have different paths in the two directions between a given host
	| pair.		| pair.
	Section 2 of [RFC9473] points to a longer, more modern definition of		See Section 3.1.1 of [RAW-ARCH] for a longer, more modern definition
	path:		of path.
	| A sequence of adjacent path elements over which a packet can be
	| transmitted, starting and ending with a node. A path is
	| unidirectional. Paths are time-dependent, i.e., the sequence of
	| path elements over which packets are sent from one node to another
	| may change. A path is defined between two nodes.
	It follows that the general acceptance of a path is a linear sequence		It follows that the general acceptance of a path is a linear sequence
	of nodes, as opposed to a multi-dimensional graph. In the context of		of nodes, as opposed to a multi-dimensional graph. In the context of
	this document, a path is observed by following one copy of a packet		this document, a path is observed by following one copy of a packet
	that is injected in a Track and possibly replicated within.		that is injected in a Track and possibly replicated within.
	2.4.4. Routing Stretch		2.4.4. Routing Stretch
	RPL is anisotropic, meaning that it is directional or, more		RPL is anisotropic, meaning that it is directional or, more
	precisely, polar. RPL does not behave the same way "downwards" (root		precisely, polar. RPL does not behave the same way "downwards" (Root
	towards leaves) with _multicast_ DODAG Information Object (DIO)		towards leaves) with _multicast_ DODAG Information Object (DIO)
	messages that form the DODAG and "upwards" (leaves towards root) with		messages that form the DODAG versus "upwards" (leaves towards Root)
	_unicast_ DAO messages that follow the DODAG. This is in contrast		with _unicast_ DAO messages that follow the DODAG. This is in
	with traditional IGPs that operate the same way in all directions and		contrast with traditional IGPs that operate the same way in all
	are thus called isotropic.		directions and are thus called isotropic.
	The term "routing stretch" denotes the length of a path, in		The term "routing stretch" denotes the length of a path, in
	comparison to the length of the shortest path, which can be an		comparison to the length of the shortest path, which can be an
	abstract concept in RPL when the metrics are statistical and dynamic,		abstract concept in RPL when the metrics are statistical and dynamic,
	and the concept of distance varies with the Objective Function.		and the concept of distance varies with the Objective Function.
	The RPL DODAG optimizes Point-to-Multipoint (P2MP) paths (from the		The RPL DODAG optimizes Point-to-Multipoint (P2MP) paths (from the
	Root) and Multipoint-to-Point (MP2P) paths (towards the Root), but		Root) and Multipoint-to-Point (MP2P) paths (towards the Root), but
	the Point-to-Point (P2P) traffic has to follow the same DODAG.		the Point-to-Point (P2P) traffic has to follow the same DODAG.
	Following the DODAG, the RPL datapath passes via a common parent in		Following the DODAG, the RPL datapath passes via a common parent in
	skipping to change at line 411 ¶		skipping to change at line 418 ¶
	involves more hops and more latency than the minimum possible for a		involves more hops and more latency than the minimum possible for a
	directional (i.e., forward) P2P path that an isotropic protocol would		directional (i.e., forward) P2P path that an isotropic protocol would
	compute. We refer to this elongated path as stretched.		compute. We refer to this elongated path as stretched.
	2.4.5. Track		2.4.5. Track
	The concept of Track is inherited from the 6TiSCH architecture		The concept of Track is inherited from the 6TiSCH architecture
	[RFC9030] and matches that of a protection path in the RAW		[RFC9030] and matches that of a protection path in the RAW
	architecture [RAW-ARCH]. A Track is a networking graph that can be		architecture [RAW-ARCH]. A Track is a networking graph that can be
	followed to transport packets with equivalent treatment; as opposed		followed to transport packets with equivalent treatment; as opposed
	to the definition of a path above, a Track is not necessarily linear.		to other definitions of a path (see Section 1.3.3 of [INT-ARCH] and
	It may contain multiple paths that may fork and rejoin and that may		Section 3.1.1 of [RAW-ARCH], a Track is not necessarily linear. It
			may contain multiple paths that may fork and rejoin and that may
	enable RAW Packet ARQ, Replication, Elimination, and Overhearing		enable RAW Packet ARQ, Replication, Elimination, and Overhearing
	(PAREO) operations.		(PAREO) operations.
	Figure 1 illustrates the mapping of the DODAG with the generic		Figure 1 illustrates the mapping of the DODAG with the generic
	concept of a Track, with the DODAG Root acting as the Ingress for the		concept of a Track, with the DODAG Root acting as the ingress for the
	Track, and the mapping of protection paths and segments, i.e., only		Track, and the mapping of protection paths and segments, i.e., only
	forward segments, meaning that they are directional and progressing		forward segments, meaning that they are directional and progressing
	towards the destination. Note that East is represented on the left		towards the destination. Note that East is represented on the left
	since the packets are forwarded East-West.		since the packets are forwarded East-West.
	North East North West		North East North West
	A ==> B ==> C -=- F ==> G ==> H T1		A ==> B ==> C -=- F ==> G ==> H T1
	/ \ / \ /		/ \ / \ /
	I O E -=- T2		I O E -=- T2
	\ / \ / \		\ / \ / \
	P ==> Q ==> R -=- T ==> U ==> V T3		P ==> Q ==> R -=- T ==> U ==> V T3
	South East South West		South East South West
	I: Ingress		I: ingress
	E: Egress		E: egress
	T1, T2, T3: external targets		T1, T2, T3: external targets
	Figure 1: A Track and Its Components		Figure 1: A Track and Its Components
	Of note:		Of note:
	I ==> A ==> B ==> C: A segment to targets F and O		I ==> A ==> B ==> C: A segment to targets F and O
	I --> F --> E: A protection path to targets T1, T2, T3		I --> F --> E: A protection path to targets T1, T2, T3
	I, A, B, C, F, G, H, E: A path to T1, T2, T3		I, A, B, C, F, G, H, E: A path to T1, T2, T3
	This specification builds Tracks that are DODAGs oriented towards a		This specification builds Tracks that are DODAGs oriented towards a
	Track Ingress, and the forward direction for packets is from the		Track ingress, and the forward direction for packets is from the
	Track Ingress to one of the possible multiple Track Egress Nodes,		Track ingress to one of the possible multiple Track egress nodes,
	which is also down the DODAG.		which is also down the DODAG.
	The Track may be strictly connected, meaning that the vertices are		The Track may be strictly connected, meaning that the vertices are
	adjacent, or loosely connected, meaning that the vertices are		adjacent, or loosely connected, meaning that the vertices are
	connected using segments that are associated to the same Track.		connected using segments that are associated to the same Track.
	2.4.5.1. TrackID		2.4.5.1. TrackID
	A RPLInstanceID (typically of a Local Instance) identifies a Track		A RPLInstanceID (typically of a Local Instance) identifies a Track
	using the namespace owned by the Track Ingress. For Local Instances,		using the namespace owned by the Track ingress. For Local Instances,
	the TrackID is associated with the IPv6 address of the Track Ingress		the TrackID is associated with the IPv6 address of the Track ingress
	that is used as the DODAGID, and together they form a unique		that is used as the DODAGID, and together they form a unique
	identification of the Track (see the definition of DODAGID in		identification of the Track (see the definition of DODAGID in
	Section 2 of [RPL]).		Section 2 of [RPL]).
	2.4.5.2. Namespace		2.4.5.2. Namespace
	The term "namespace" is used to refer to the scope of the TrackID.		The term "namespace" is used to refer to the scope of the TrackID.
	The TrackID is locally significant within its namespace. For Local		The TrackID is locally significant within its namespace. For Local
	Instances, the namespace is identified by the DODAGID for the Track,		Instances, the namespace is identified by the DODAGID for the Track,
	and the tuple (DODAGID, TrackID) is globally unique. For Global		and the tuple (DODAGID, TrackID) is globally unique. For Global
	Instances, the namespace is the whole RPL domain.		Instances, the namespace is the whole RPL domain.
	2.4.5.3. Complex Track		2.4.5.3. Complex Track
	A complex Track is a Track that can be traversed via more than one		A Complex Track is a Track that can be traversed via more than one
	path (e.g., a DODAG).		path (e.g., a DODAG).
	2.4.5.4. Stand Alone		2.4.5.4. Stand Alone
	Stand alone refers to a segment or a protection path that is		Stand alone refers to a segment or a protection path that is
	installed with a single P-DAO that fully defines the path, e.g., a		installed with a single P-DAO that fully defines the path, e.g., a
	stand-alone segment is installed with a single Storing Mode Via		stand-alone segment is installed with a single Storing Mode Via
	Information Option (SM-VIO) all the way between the Ingress and		Information Option (SM-VIO) all the way between the ingress and
	Egress.		egress.
	2.4.5.5. Stitching		2.4.5.5. Stitching
	This specification uses the term "stitching" to indicate that a Track		This specification uses the term "stitching" to indicate that a Track
	is piped to another one, meaning that traffic out of the first Track		is piped to another one, meaning that traffic out of the first Track
	is injected into the other Track.		is injected into the other Track.
	2.4.5.6. Protection Path		2.4.5.6. Protection Path
	The concept of protection path is defined in the RAW architecture		The concept of protection path is defined in the RAW architecture
	[RAW-ARCH] as an end-to-end forward serial path. With this		[RAW-ARCH] as an end-to-end forward serial path. With this
	specification, a protection path is installed by the Root of the main		specification, a protection path is installed by the Root of the main
	DODAG using a Non-Storing Mode P-DAO message, e.g., I --> F --> E in		DODAG using a Non-Storing Mode P-DAO message, e.g., I --> F --> E in
	Figure 1.		Figure 1.
	As the Non-Storing Mode Via Information Option (NSM-VIO) can only		As the Non-Storing Mode Via Information Option (NSM-VIO) can only
	signal sequences of nodes, it takes one Non-Storing Mode P-DAO		signal sequences of nodes, it takes one Non-Storing Mode P-DAO
	message per protection path to signal the structure of a complex		message per protection path to signal the structure of a Complex
	Track.		Track.
	Each NSM-VIO for the same TrackID but with a different Segment ID		Each NSM-VIO for the same TrackID but with a different SegmentID
	signals a different protection path that the Track Ingress adds to		signals a different protection path that the Track ingress adds to
	the topology.		the topology.
	2.4.5.7. Segment		2.4.5.7. Segment
	A segment is a serial path formed by a strict sequence of nodes along		A segment is a serial path formed by a strict sequence of nodes along
	which a P-Route is installed, e.g., I ==> A ==> B ==> C in Figure 1.		which a P-Route is installed, e.g., I ==> A ==> B ==> C in Figure 1.
	With this specification, a segment is typically installed by the Root		With this specification, a segment is typically installed by the Root
	of the main DODAG using Storing Mode P-DAO messages. A segment is		of the main DODAG using Storing Mode P-DAO messages. A segment is
	used as the topological edge of a Track joining the loose steps along		used as the topological edge of a Track joining the loose steps along
	the protection paths that form the structure of a complex Track. The		the protection paths that form the structure of a Complex Track. The
	same segment may be leveraged by more than one protection path where		same segment may be leveraged by more than one protection path where
	the protection paths overlap.		the protection paths overlap.
	Since this specification builds only DODAGs, all segments are		Since this specification builds only DODAGs, all segments are
	oriented from the Ingress (East) to Egress (West), as opposed to the		oriented from the ingress (East) to egress (West), as opposed to the
	general Track model in the RAW architecture [RAW-ARCH], which allows		general Track model in the RAW architecture [RAW-ARCH], which allows
	North/South segments that can be bidirectional as well.		North/South segments that can be bidirectional as well.
	2.4.5.7.1. Section of a Segment		2.4.5.7.1. Section of a Segment
	The section of a segment refers to a continuous subset of a segment		The section of a segment refers to a continuous subset of a segment
	that may be replaced while the segment remains. For instance, in		that may be replaced while the segment remains. For instance, in
	segment A=>B=>C=>D=>E=>F, say that the link C to D might be		segment A=>B=>C=>D=>E=>F, say that the link C to D might be
	misbehaving. The section B=>C=>D=>E in the segment may be replaced		misbehaving. The section B=>C=>D=>E in the segment may be replaced
	by B=>C'=>D'=>E to route around the problem. The segment becomes		by B=>C'=>D'=>E to route around the problem. The segment becomes
	A=>B=>C'=>D'=>E=>F.		A=>B=>C'=>D'=>E=>F.
	2.4.5.7.2. Segment Routing and SRH		2.4.5.7.2. Segment Routing and SRH
	In a Non-Storing Mode RPL domain, the IPv6 RH used for source routing		In a Non-Storing Mode RPL domain, the IPv6 Routing Header used for
	is the (RPL) SRH as defined in [RFC6554]. This specification		source routing is the RPL Source Route Header as defined in
	operates in that context and uses the acronym SRH to mean IPv6 RH		[RFC6554]. This specification operates in that context and uses the
	type 3, as opposed to IPv6 RH type 4 defined in [RFC8754] for Segment		acronym SRH to mean IPv6 RH type 3, as opposed to IPv6 RH type 4
	Routing over IPv6 (SRv6) operation.		defined in [RFC8754] for Segment Routing over IPv6 (SRv6) operation.
	If the network is a 6LoWPAN network, the expectation is that the SRH		If the network is a 6LoWPAN network, the expectation is that the SRH
	is compressed and encoded as a 6LoWPAN Routing Header (6LoRH), as		is compressed and encoded as a 6LoWPAN Routing Header (6LoRH), as
	specified in Section 5 of [RFC8138].		specified in Section 5 of [RFC8138].
	This specification uses the term "Segment Routing" generically to		This specification uses the term "Segment Routing" generically to
	refer to using source routing to hop over segments. As such,		refer to using source routing to hop over segments. As such,
	forwarding along segments as specified hereafter can be seen as a		forwarding along segments as specified hereafter can be seen as a
	form of Segment Routing [RFC8402] that leverages the (RPL) SRH for		form of Segment Routing [RFC8402] that leverages the RPL Source Route
	its operation.		Header for its operation.
	Outside of LLNs, the RPL network may be less constrained and operated		Outside of LLNs, the RPL network may be less constrained and operated
	in Storing Mode, as discussed in Section 7.1. In that case, this		in Storing Mode, as discussed in Section 7.1. In that case, this
	specification could be extended to accommodate the SRv6 RH.		specification could be extended to accommodate the SRv6 RH.
	3. Context and Goal		3. Context and Goal
	3.1. RPL Applicability		3.1. RPL Applicability
	RPL is optimized for situations where the power is scarce, the		RPL is optimized for situations where the power is scarce, the
	bandwidth is constrained, and the transmissions are unreliable. This		bandwidth is constrained, and the transmissions are unreliable. This
	matches the use case of an IoT LLN where RPL is typically used today		matches the use case of an IoT LLN where RPL is typically used today
	and also situations of high relative mobility between the nodes in		and also situations of high relative mobility between the nodes in
	the network (a.k.a. swarming), e.g., within a variable set of		the network (a.k.a. swarming), e.g., within a variable set of
	vehicles with a similar global motion or a platoon of drones. In		vehicles with a similar global motion or a platoon of drones. In
	contrast, this specification only applies when the platoon has a		contrast, this specification only applies when the platoon has a
	relatively stable topology where the segments can be attributed		relatively stable topology where the segments can be attributed
	reliability and availability for a certain lifetime; see [RAW-ARCH].		reliability and availability for a certain lifetime; see [RAW-ARCH].
	To reach this goal, RPL is primarily designed to minimize the control		To reach this goal, RPL is primarily designed to minimize the control
	plane activity, i.e., the relative amount of routing protocol		plane activity (i.e., the relative amount of routing protocol
	exchanges versus data traffic, and the amount of state that is		exchanges versus data traffic) and the amount of state that is
	maintained in each node. RPL does not need to converge, and it		maintained in each node. RPL does not need to converge, and it
	provides connectivity to most nodes most of the time.		provides connectivity to most nodes most of the time.
	RPL may form multiple topologies called instances. Instances can be		RPL may form multiple topologies called Instances. Instances can be
	created to enforce various optimizations through objective functions		created to enforce various optimizations through Objective Functions
	or to reach out through different Root Nodes. The concept of		or to reach out through different Root nodes. The concept of
	objective function allows adapting the activity of the routing		Objective Function allows adapting the activity of the routing
	protocol to the use case, e.g., type, speed, and quality of the LLN		protocol to the use case, e.g., type, speed, and quality of the LLN
	links.		links.
	RPL instances operate in parallel, unaware of one another. Yet, it		RPL Instances operate in parallel, unaware of one another. Yet, it
	is possible to define a model whereby if a route cannot be found in		is possible to define a model whereby if a route cannot be found in
	the current instance A where a packet is being forwarded, then the		the current Instance A where a packet is being forwarded, then the
	router may look up the routing table (i.e., the RIB) in instance B		router may look up the routing table (i.e., the RIB) in Instance B
	and forward along instance B if the route is found there. To avoid		and forward along Instance B if the route is found there. To avoid
	loops, this must happen in such a way that the instances themselves		loops, this must happen in such a way that the Instances themselves
	form a Directed Acyclic Graph (DAG) leading to the last resort		form a Directed Acyclic Graph (DAG) leading to the last resort
	instance, which is the "lowest" instance if instance A is considered		Instance, which is the "lowest" Instance if Instance A is considered
	"higher" then instance B. This specification uses underlay Tracks as		"higher" then Instance B. This specification uses underlay Tracks as
	"lower" instances, with the main instance being the "highest" of all.		"lower" Instances, with the main Instance being the "highest" of all.
	The RPL Root is responsible for selecting the RPL Instance that is		The RPL Root is responsible for selecting the RPL Instance that is
	used to forward a packet coming from the backbone into the RPL domain		used to forward a packet coming from the backbone into the RPL domain
	and for setting the related RPL information in the packets. Each		and for setting the related RPL information in the packets. Each
	Instance creates its own routing table (i.e., a RIB) in participating		Instance creates its own routing table (i.e., a RIB) in participating
	nodes, and the RIB associated to the instance must be used end to end		nodes, and the RIB associated to the Instance must be used end to end
	in the RPL domain. To that effect, RPL tags the packets with the		in the RPL domain. To that effect, RPL tags the packets with the
	Instance ID in a Hop-by-Hop extension header. 6TiSCH leverages RPL		Instance ID in a Hop-by-Hop extension header. 6TiSCH leverages RPL
	for its distributed routing operations.		for its distributed routing operations.
	To reduce the routing exchanges, RPL leverages an anisotropic		To reduce the routing exchanges, RPL leverages an anisotropic
	Distance Vector approach, which does not need global knowledge of the		Distance Vector approach, which does not need global knowledge of the
	topology and only optimizes the routes to and from the RPL Root,		topology and only optimizes the routes to and from the RPL Root,
	allowing P2P paths to be stretched. Although RPL installs its routes		allowing P2P paths to be stretched. Although RPL installs its routes
	proactively, it only maintains them lazily, in reaction to actual		proactively, it only maintains them lazily, in reaction to actual
	traffic or as a slow background activity.		traffic or as a slow background activity.
	skipping to change at line 628 ¶		skipping to change at line 636 ¶
	RAW use cases document [RFC9450], which demand high availability and		RAW use cases document [RFC9450], which demand high availability and
	reliability and, as a consequence, require both short and diverse		reliability and, as a consequence, require both short and diverse
	paths.		paths.
	3.2. Multi-Topology Routing and Loop Avoidance		3.2. Multi-Topology Routing and Loop Avoidance
	RPL first forms a default route in each node towards the Root, and		RPL first forms a default route in each node towards the Root, and
	those routes together coalesce as a DAG oriented upwards. RPL then		those routes together coalesce as a DAG oriented upwards. RPL then
	constructs routes to destinations signaled as Targets in the reverse		constructs routes to destinations signaled as Targets in the reverse
	direction, down the same DODAG. To do so, a RPL Instance can be		direction, down the same DODAG. To do so, a RPL Instance can be
	operated in either RPL Storing Mode or Non-Storing Mode of Operation		operated in either RPL Storing or Non-Storing MOP. The default route
	(MOP). The default route towards the Root is maintained aggressively		towards the Root is maintained aggressively and may change while a
	and may change while a packet progresses without causing loops, so		packet progresses without causing loops, so the packet will still
	the packet will still reach the Root.		reach the Root.
	In Non-Storing Mode, each node advertises itself as a Target directly		In Non-Storing Mode, each node advertises itself as a Target directly
	to the Root, indicating the parents that may be used to reach itself.		to the Root, indicating the parents that may be used to reach itself.
	Recursively, the Root builds and maintains an image of the whole		Recursively, the Root builds and maintains an image of the whole
	DODAG in memory and leverages that abstraction to compute source		DODAG in memory and leverages that abstraction to compute source
	route paths for the packets to their destinations down the DODAG.		route paths for the packets to their destinations down the DODAG.
	When a node changes its point(s) of attachment to the DODAG, it takes		When a node changes its point(s) of attachment to the DODAG, it takes
	a single unicast packet to the Root along the default route to update		a single unicast packet to the Root along the default route to update
	it, and the connectivity to the node is restored immediately; this		it, and the connectivity to the node is restored immediately; this
	mode is preferable for use cases where internet connectivity is		mode is preferable for use cases where internet connectivity is
	dominant or when the Root controls the network activity in the nodes,		dominant or when the Root controls the network activity in the nodes,
	which is the case in this specification.		which is the case in this specification.
	In Storing Mode, the routing information percolates upwards, and each		In Storing Mode, the routing information percolates upwards, and each
	node maintains the routes to the subDAG of its descendants down the		node maintains the routes to the subDAG of its descendants down the
	DODAG. The maintenance is lazy, either reactive upon traffic or as a		DODAG. The maintenance is lazy; it is either reactive upon receiving
	slow background process. Packets flow via the common parent and the		traffic or a slow background process. Packets flow via the common
	routing stretch is reduced, compared to the Non-Storing MOP, for		parent and the routing stretch is reduced, compared to the Non-
	better P2P connectivity. However, a new route takes a longer time to		Storing MOP, for better P2P connectivity. However, a new route takes
	propagate to the Root, since it takes time for the Distance Vector		a longer time to propagate to the Root, since it takes time for the
	protocol to operate hop by hop, and the connectivity from the		Distance Vector protocol to operate hop by hop, and the connectivity
	Internet to the node is restored more slowly upon node movement.		from the Internet to the node is restored more slowly upon node
			movement.
	Either way, the RPL routes are injected by the Target nodes in a		Either way, the RPL routes are injected by the Target nodes in a
	distributed fashion. To complement RPL and eliminate routing		distributed fashion. To complement RPL and eliminate routing
	stretch, this specification introduces a hybrid mode that combines		stretch, this specification introduces a hybrid mode that combines
	Storing and Non-Storing operations to build and project routes onto		Storing and Non-Storing operations to build and project routes onto
	the nodes where they should be installed. This specification uses		the nodes where they should be installed. This specification uses
	the term "P-Route" to refer to those routes.		the term "P-Route" to refer to those routes.
	In the simplest mode of this specification, Storing Mode P-Routes can		In the simplest mode of this specification, Storing Mode P-Routes can
	be deployed to join the dots of a loose SRH in the main DODAG. In		be deployed to complete the path between the hops described in the
	that case, all the routes (source routed and P-Routes) belong to the		loose SRH in the main DODAG. In that case, all the routes (source
	Routing Information Base (RIB) associated with the main Instance.		routed and P-Routes) belong to the Routing Information Base (RIB)
	Storing Mode P-Routes are referred to as segments in this		associated with the main Instance. Storing Mode P-Routes are
	specification.		referred to as segments in this specification.
	A set of P-Routes can also be projected to form a dotted-line		A set of P-Routes can also be projected to form a dotted-line
	underlay of the main Instance and provide Traffic-Engineered paths		underlay of the main Instance and provide Traffic-Engineered paths
	for an application. In that case, the P-Routes are installed in Non-		for an application. In that case, the P-Routes are installed in Non-
	Storing Mode, and the set of P-Routes is called a Track. A Track is		Storing Mode, and the set of P-Routes is called a Track. A Track is
	associated with its own RPL Instance and, as any RPL Instance, with		associated with its own RPL Instance and, as any RPL Instance, with
	its own RIB. As a result, each Track defines a routing topology in		its own RIB. As a result, each Track defines a routing topology in
	the RPL domain. As for the main DODAG, segments associated to the		the RPL domain. As for the main DODAG, segments associated to the
	Track Instance may be deployed to join the dots using Storing Mode		Track Instance may be deployed to establish the complete path between
			loose source routing hops using segments expressed as Storing Mode
	P-Routes.		P-Routes.
	Routing in a multi-topology domain may cause loops unless strict		Routing in a multi-topology domain may cause loops unless strict
	rules are applied. This specification defines two strict orders to		rules are applied. This specification defines two strict orders to
	ensure loop avoidance when P-Routes are used in a RPL domain: one		ensure loop avoidance when P-Routes are used in a RPL domain: one
	between forwarding methods and one between RPL Instances, which are		between forwarding methods and one between RPL Instances, which are
	routing topologies.		routing topologies.
	The first and strict order relates to the forwarding method and, more		The first order is strict and complete and relates to the forwarding
	specifically, the origin of the information used in the next-hop		method and, more specifically, the origin of the information used in
	computation. The possible forwarding methods are: 1) to a direct		the next-hop computation. The possible forwarding methods are: 1) to
	next hop, 2) to an indirect neighbor via a common neighbor, 3) along		a direct next hop, 2) to an indirect neighbor via a common neighbor,
	a segment, and 4) along a nested Track. The methods are strictly		3) along a segment, and 4) along a nested Track. The methods are
	ordered as listed above; see more in Section 6.7. A forwarding		strictly ordered as listed above; see more in Section 6.7. A
	method may leverage any of the lower-order ones, but never one with a		forwarding method may leverage any of the lower-order ones, but never
	higher order; for instance, when forwarding a packet along a segment,		one with a higher order; for instance, when forwarding a packet along
	the router may use direct or indirect neighbors but cannot use a		a segment, the router may use direct or indirect neighbors but cannot
	Track. The lower-order methods have a strict precedence, so the		use a Track. The lower-order methods have a strict precedence, so
	router will always prefer a direct neighbor over an indirect one or a		the router will always prefer a direct neighbor over an indirect one
	segment within the current RPL Instance over another Track.		or a segment within the current RPL Instance over another Track.
	The second strict and partial order is between RPL Instances. It		The second order is strict and partial and applies between RPL
	allows the RPL node to detect an error in the state installed by the		Instances. It allows the RPL node to detect an error in the state
	PCE, e.g., after a desynchronization. That order must be defined by		installed by the PCE, e.g., after a desynchronization. That order
	the administrator for the RPL domain and defines a DODAG of underlays		must be defined by the administrator for the RPL domain and defines a
	with the main Instance as Root. The relation of RPL instances may be		DODAG of underlay RPL Instances with the main Instance as the Root.
	represented as a DODAG of instances where the main instance is the		The relation of RPL Instances may be represented as a DODAG of
	Root. The rule is that a RPL Instance may leverage another RPL		Instances where the main Instance is the Root. The rule is that a
	instance as an underlay if and only if that other Instance is one of		RPL Instance may leverage another RPL Instance as an underlay if and
	its descendants in the graph. Supporting this method is OPTIONAL for		only if that other Instance is one of its descendants in the graph.
	nested Tracks and REQUIRED between a Track instance and the main		Supporting this method is OPTIONAL for nested Tracks and REQUIRED
	instance. It may be done using network management or future		between a Track Instance and the main Instance. It may be done using
	extensions to this specifications. When it is not communicated, the		network management or future extensions to this specifications. When
	RPL nodes consider by default that all Track instances are children		the DODAG of underlay Instances is not provided, the RPL nodes
	of the main instance, and they do not attempt to validate the order		consider by default that all Track Instances are children of the main
	for nested Tracks, trusting the PCE implicitly. As a result, a		Instance, and they do not attempt to validate the order for nested
	packet that is being forwarded along the main Instance may be		Tracks, trusting the PCE implicitly. As a result, a packet that is
	encapsulated in any Track, but a packet that was forwarded along a		being forwarded along the main Instance may be encapsulated in any
	Track MUST NOT be forwarded along the default route of the main		Track, but a packet that was forwarded along a Track MUST NOT be
	Instance.		forwarded along the default route of the main Instance.
	3.3. Requirements		3.3. Requirements
	3.3.1. Loose Source Routing		3.3.1. Loose Source Routing
	A RPL implementation operating in a very constrained LLN typically		A RPL implementation operating in a very constrained LLN typically
	uses the Non-Storing Mode of Operation as represented in Figure 2.		uses the Non-Storing MOP as represented in Figure 2. In that mode, a
	In that mode, a RPL node indicates a parent-child relationship to the		RPL node indicates a parent-child relationship to the Root, using a
	Root, using a Destination Advertisement Object (DAO) that is unicast		Destination Advertisement Object (DAO) that is unicast from the node
	from the node directly to the Root, and the Root typically builds a		directly to the Root, and the Root typically builds a source-routed
	source-routed path to a destination down the DODAG by recursively		path to a destination down the DODAG by recursively concatenating
	concatenating this information.		this information.
	+-----+		+-----+
	| | Border Router		| | Border Router
	| | (RPL Root)		| | (RPL Root)
	+-----+ ^ | |		+-----+ ^ | |
	| | DAO | ACK |		| | DAO | ACK |
	o o o o | | | Strict		o o o o | | | Strict
	o o o o o o o o o | | | Source		o o o o o o o o o | | | Source
	o o o o o o o o o o | | | Route		o o o o o o o o o o | | | Route
	o o o o o o o o o | | |		o o o o o o o o o | | |
	skipping to change at line 758 ¶		skipping to change at line 768 ¶
	structure of the DODAG for which it is the destination. A packet		structure of the DODAG for which it is the destination. A packet
	that is generated within the domain will always reach the Root, which		that is generated within the domain will always reach the Root, which
	can then apply source routing information to reach the destination if		can then apply source routing information to reach the destination if
	the destination is also in the DODAG. Similarly, a packet coming		the destination is also in the DODAG. Similarly, a packet coming
	from the outside of the domain for a destination that is expected to		from the outside of the domain for a destination that is expected to
	be in a RPL domain reaches the Root. This results in the wireless		be in a RPL domain reaches the Root. This results in the wireless
	bandwidth near the Root being the limiting factor for all		bandwidth near the Root being the limiting factor for all
	transmissions towards or within the domain, and the Root is a single		transmissions towards or within the domain, and the Root is a single
	point of failure for all connectivity to nodes within its domain.		point of failure for all connectivity to nodes within its domain.
	The RPL Root must add a source routing header to all downward		The RPL Root must add a Source Routing Header to all downward
	packets. As a network grows, the size of the source routing header		packets. As a network grows, the size of the Source Routing Header
	increases with the depth of the network. In some use cases, a RPL		increases with the depth of the network. In some use cases, a RPL
	network forms long lines along physical structures like streets with		network forms long lines along physical structures like streets with
	lighting. Limiting the packet size is beneficial to the energy		lighting. Limiting the packet size is beneficial to the energy
	budget, directly for the current transmission and also indirectly		budget, directly for the current transmission and also indirectly
	since it reduces the chances of frame loss and energy spent in		since it reduces the chances of frame loss and energy spent in
	retries, e.g., by ARQ over one hop at Layer 2 or end to end at upper		retries, e.g., by ARQ over one hop at Layer 2 or end to end at upper
	layers. Using smaller packets also reduces the chances of packet		layers. Using smaller packets also reduces the chances of packet
	fragmentation, which is highly detrimental to the LLN operation, in		fragmentation, which is highly detrimental to the LLN operation, in
	particular when fragments are forwarded but not recovered; see		particular when fragments are forwarded but not recovered; see
	[RFC8930] compared to [RFC8931] for more details.		[RFC8930] compared to [RFC8931] for more details.
	skipping to change at line 792 ¶		skipping to change at line 802 ¶
	destination, the latency incurred, and the amount of energy and		destination, the latency incurred, and the amount of energy and
	bandwidth that is consumed to reach itself and then back down,		bandwidth that is consumed to reach itself and then back down,
	including possible fragmentation when encapsulating larger packets.		including possible fragmentation when encapsulating larger packets.
	Enabling a shorter path that would not traverse the Root for select		Enabling a shorter path that would not traverse the Root for select
	P2P sources/destinations may improve the latency, lower the		P2P sources/destinations may improve the latency, lower the
	consumption of constrained resources, free bandwidth at the		consumption of constrained resources, free bandwidth at the
	bottleneck near the Root, improve the delivery ratio, and reduce the		bottleneck near the Root, improve the delivery ratio, and reduce the
	latency for those P2P flows; this would be a global benefit for all		latency for those P2P flows; this would be a global benefit for all
	flows by reducing the load at the Root.		flows by reducing the load at the Root.
	To limit the need for source route headers in deep networks, one		To limit the need for RPL Source Route Headers in deep networks, one
	possibility is to store a routing state associated with the main		possibility is to store a routing state associated with the main
	DODAG in select RPL routers down the path. The Root may elide the		DODAG in select RPL routers down the path. The Root may elide the
	sequence of routers that is installed in the network from its source		sequence of routers that is installed in the network from its RPL
	route header, which therefore becomes loose, in contrast to being		Source Route Header, which therefore becomes loose, in contrast to
	strict in [RPL].		being strict in [RPL].
	3.3.2. Forward Routes		3.3.2. Forward Routes
	[RPL] optimizes P2MP routes from the Root, MP2P routes towards the		[RPL] optimizes P2MP routes from the Root, MP2P routes towards the
	Root, and routes from/to the outside of the RPL domain when the Root		Root, and routes from/to the outside of the RPL domain when the Root
	also serves as the border router. All routes are installed North-		also serves as the border router. All routes are installed North-
	South (a.k.a. up/down) along the RPL DODAG. Peer-to-Peer (P2P)		South (a.k.a. up/down) along the RPL DODAG. Peer-to-Peer forward
	forward routes in a RPL network will generally experience elongated		routes in a RPL network will generally experience elongated
	(stretched) paths rather than direct (optimized) paths, since routing		(stretched) paths rather than direct (optimized) paths, since routing
	between two nodes always happens via a common parent, as illustrated		between two nodes always happens via a common parent, as illustrated
	in Figure 3:		in Figure 3:
	------+---------		------+---------
	| Internet		| Internet
	+-----+		+-----+
	| | Border Router		| | Border Router
	| | (RPL Root)		| | (RPL Root)
	+-----+		+-----+
	skipping to change at line 887 ¶		skipping to change at line 897 ¶
	3.4. On Tracks		3.4. On Tracks
	3.4.1. Building Tracks with RPL		3.4.1. Building Tracks with RPL
	The concept of a Track was introduced in the 6TiSCH architecture		The concept of a Track was introduced in the 6TiSCH architecture
	[RFC9030] as a collection of potential paths that leverage redundant		[RFC9030] as a collection of potential paths that leverage redundant
	forwarding solutions along the way. This can be a DODAG or a more		forwarding solutions along the way. This can be a DODAG or a more
	complex structure that is only partially acyclic (e.g., per packet).		complex structure that is only partially acyclic (e.g., per packet).
	With this specification, a Track is shaped as a DODAG, and following		With this specification, a Track is shaped as a DODAG, and following
	the directed edges leads to a Track Ingress. Storing Mode P-DAO		the directed edges leads to a Track ingress. Storing Mode P-DAO
	messages follow the direction of the edges to set up routes for		messages follow the direction of the edges to set up routes for
	traffic that flows the other way, towards the Track Egress(es). If		traffic that flows the other way, towards the Track egress(es). If
	there is a single Track Egress, then the Track is reversible so that		there is a single Track egress, then the Track is reversible so that
	another DODAG may be formed by reversing the direction of each edge.		another DODAG may be formed by reversing the direction of each edge.
	A node at the Ingress of more than one segment in a Track may use one		A node at the ingress of more than one segment in a Track may use one
	or more of these segments to forward a packet inside the Track.		or more of these segments to forward a packet inside the Track.
	A RPL Track is a collection of (one or more) parallel loose source-		A RPL Track is a collection of (one or more) parallel loose source-
	routed sequences of nodes ordered from Ingress to Egress, each		routed sequences of nodes ordered from ingress to egress, each
	forming a protection path. The nodes in a Track are directly		forming a protection path. The nodes in a Track are directly
	connected, reachable via existing Tracks as illustrated in		connected, reachable via existing Tracks as illustrated in
	Section 3.5.2.3 or joined with strict segments of other nodes as		Section 3.5.2.3 or joined with strict segments of other nodes as
	shown in Section 3.5.1.3. The protection paths are expressed in RPL		shown in Section 3.5.1.3. The protection paths are expressed in RPL
	Non-Storing Mode and require an encapsulation to add a Source Route		Non-Storing Mode and require an encapsulation to add a RPL Source
	Header, whereas the segments are expressed in RPL Storing Mode.		Route Header, whereas the segments are expressed in RPL Storing Mode.
	A path provides only one path between the Ingress and Egress. It		A path provides only one path between the ingress and egress. It
	comprises exactly one protection path. A stand-alone segment		comprises exactly one protection path. A stand-alone segment
	implicitly defines a path from its Ingress to Egress.		implicitly defines a path from its ingress to egress.
	A complex Track forms a graph that provides a collection of potential		A Complex Track forms a graph that provides a collection of potential
	paths to provide redundancy for the packets, either as a collection		paths to provide redundancy for the packets, either as a collection
	of protection paths that may be parallel or interleaved at certain		of protection paths that may be parallel or interleaved at certain
	points or as a more generic DODAG.		points or as a more generic DODAG.
	3.4.2. Tracks and RPL Instances		3.4.2. Tracks and RPL Instances
	Section 5.1 of [RPL] describes the RPL Instance and its encoding.		Section 5.1 of [RPL] describes the RPL Instance and its encoding.
	There can be up to 128 Global RPL Instances, for which there can be		There can be up to 128 Global RPL Instances, for which there can be
	one or more DODAGs, and there can be 64 Local RPL Instances, with a		one or more DODAGs, and there can be 64 Local RPL Instances, with a
	namespace that is indexed by a DODAGID, where the DODAGID is a Unique		namespace that is indexed by a DODAGID, where the DODAGID is a Unique
	skipping to change at line 932 ¶		skipping to change at line 942 ¶
	specification expresses the value of the RPLInstanceID as a single		specification expresses the value of the RPLInstanceID as a single
	integer between 128 and 191, representing both the Local		integer between 128 and 191, representing both the Local
	RPLInstanceID in 0..63 in the rightmost bits and bit 0 set.		RPLInstanceID in 0..63 in the rightmost bits and bit 0 set.
	0 1 2 3 4 5 6 7		0 1 2 3 4 5 6 7
	+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+
	|1|D| ID | Local RPLInstanceID in 0..63		|1|D| ID | Local RPLInstanceID in 0..63
	+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+
	| |		| |
	\ \		\ \
	\ Bit 1 is set to 0 in Track IDs		\ Bit 1 is set to 0 in TrackIDs
	Bit 0 set to 1 signals a Local RPLInstanceID		Bit 0 set to 1 signals a Local RPLInstanceID
	Figure 5: Local RPLInstanceID Encoding		Figure 5: Local RPLInstanceID Encoding
	A Track typically forms an underlay to the main Instance and is		A Track typically forms an underlay to the main Instance and is
	associated with a Local RPL Instance from which the RPLInstanceID is		associated with a Local RPL Instance from which the RPLInstanceID is
	used as the TrackID. When a packet is placed on a Track, it is IP-		used as the TrackID. When a packet is placed on a Track, it is IP-
	in-IP encapsulated with a RPL Option containing RPL Packet		in-IP encapsulated with a RPL Option containing RPL Packet
	Information (RPI) that signals the RPLInstanceID. The encapsulating		Information (RPI) that signals the RPLInstanceID. The encapsulating
	source IP address and RPI Instance are set to the Track Ingress IP		source IP address and RPI Instance are set to the Track ingress IP
	address and Local RPLInstanceID, respectively; see more in		address and Local RPLInstanceID, respectively; see more in
	Section 6.3.		Section 6.3.
	A Track typically offers service protection across several protection		A Track typically offers service protection across several protection
	paths. As a degraded form of a Track, a path made of a single		paths. As a degraded form of a Track, a path made of a single
	protection path (i.e., offering no protection) can be used as an		protection path (i.e., offering no protection) can be used as an
	alternative to a segment for forwarding along a RPL Instance. In		alternative to a segment for forwarding along a RPL Instance. In
	that case, instead of following native routes along the instance, the		that case, instead of following native routes along the Instance, the
	packets are encapsulated to signal a more-specific source-routed path		packets are encapsulated to signal a more-specific source-routed path
	between the loose hops in the encapsulated source routing header.		between the loose hops in the encapsulated Source Routing Header.
	If the encapsulated packet follows a global instance, then the		If the encapsulated packet follows a Global Instance, then the
	protection path may be part of that global instance as well, e.g.,		protection path may be part of that Global Instance as well, e.g.,
	the global instance of the main DODAG. This can only be done for		the Global Instance of the main DODAG. This can only be done for
	global instances because the Ingress node that encapsulates the		Global Instances because the ingress node that encapsulates the
	packets over the protection path is not the Root of the instance, so		packets over the protection path is not the Root of the Instance, so
	the source address of the encapsulated packet cannot be used to		the source address of the encapsulated packet cannot be used to
	determine the Track along the way.		determine the Track along the way.
	3.5. Path Signaling		3.5. Path Signaling
	This specification enables setting up a P-Route along either a		This specification enables setting up a P-Route along either a
	protection path or a segment. A P-Route is installed and maintained		protection path or a segment. A P-Route is installed and maintained
	by the Root of the main DODAG using an extended RPL DAO message		by the Root of the main DODAG using an extended RPL DAO message
	called a P-DAO, and a Track is composed of the combination of one or		called a P-DAO, and a Track is composed of the combination of one or
	more P-Routes. In order to clarify the techniques that may be used		more P-Routes. In order to clarify the techniques that may be used
	skipping to change at line 982 ¶		skipping to change at line 992 ¶
	and E as opposed to via the Root:		and E as opposed to via the Root:
	/===> F		/===> F
	A ===> B ===> C ===> D===> E <		A ===> B ===> C ===> D===> E <
	\===> G		\===> G
	Figure 6: Reference Track		Figure 6: Reference Track
	A P-DAO message for a Track signals the TrackID in the RPLInstanceID		A P-DAO message for a Track signals the TrackID in the RPLInstanceID
	field. In the case of a Local RPL Instance, the address of the Track		field. In the case of a Local RPL Instance, the address of the Track
	Ingress is used as the source to encapsulate packets along the Track.		ingress is used as the source to encapsulate packets along the Track.
	The Track is signaled in the DODAGID field of the P-DAO Base Object;		The Track is signaled in the DODAGID field of the P-DAO Base Object;
	see Figure 8.		see Figure 8.
	This specification introduces the Via Information Option (VIO) to		This specification introduces the Via Information Option (VIO) to
	signal a sequence of hops in a protection path or a segment in the		signal a sequence of hops in a protection path or a segment in the
	P-DAO messages, either in Storing Mode (SM-VIO) or in Non-Storing		P-DAO messages, either in Storing Mode (SM-VIO) or in Non-Storing
	Mode (NSM-VIO). One P-DAO message contains a single VIO, which is		Mode (NSM-VIO). One P-DAO message contains a single VIO, which is
	associated to one or more RPL Target Options that signal the		associated to one or more RPL Target Options that signal the
	destination IPv6 addresses that can reached along the Track (see more		destination IPv6 addresses that can reached along the Track (see more
	in Section 5.3).		in Section 5.3).
	Before diving deeper into Track and segment signaling and operation,		Before diving deeper into Track and segment signaling and operation,
	this section provides examples of how route projection works through		this section provides examples of how route projection works through
	variations of a simple example. This simple example illustrates the		variations of a simple example. This simple example illustrates the
	case of host routes, though RPL Targets can also be prefixes.		case of host routes, though RPL Targets can also be prefixes.
	Conventionally, we use ==> to represent a strict hop and --> for a		Conventionally, we use ==> to represent a strict hop and --> for a
	loose hop. We use "-to-", such as in C==>D==>E-to-F, to represent		loose hop. We use "-to-", such as in C==>D==>E-to-F, to represent
	coma-separated Targets, e.g., F is a Target for segment C==>D==>E.		comma-separated Targets, e.g., F is a Target for segment C==>D==>E.
	In the example below, A is the Track Ingress and E is the Track		In the example below, A is the Track ingress and E is the Track
	Egress. C is a stitching point. F and G are "external" Targets for		egress. C is a stitching point. F and G are "external" Targets for
	the Track and become reachable from A via Track A (Ingress) to E		the Track and become reachable from A via Track A (ingress) to E
	(Egress and implicit Target in Non-Storing Mode), leading to F and G		(egress and implicit Target in Non-Storing Mode), leading to F and G
	(explicit Targets).		(explicit Targets).
	In a general manner, the desired outcome is as follows:		In a general manner, the desired outcome is as follows:
	* Targets are E, F, and G		* Targets are E, F, and G
	* P-DAO 1 signals C==>D==>E		* P-DAO 1 signals C==>D==>E
	* P-DAO 2 signals A==>B==>C		* P-DAO 2 signals A==>B==>C
	* P-DAO 3 signals F and G via the A-->E Track		* P-DAO 3 signals F and G via the A-->E Track
	P-DAO 3 may be omitted if P-DAOs 1 and 2 signal F and G as Targets.		P-DAO 3 may be omitted if P-DAOs 1 and 2 signal F and G as Targets.
	Loose sequences of hops are expressed in Non-Storing Mode; this is		Loose sequences of hops are expressed in Non-Storing Mode; this is
	why P-DAO 3 contains an NSM-VIO. With this specification:		why P-DAO 3 contains an NSM-VIO. With this specification:
	* The DODAGID to be used by the Ingress as the source address is		* The DODAGID to be used by the ingress as the source address is
	signaled in the DAO Base Object (see Figure 8).		signaled in the DAO Base Object (see Figure 8).
	* The via list in the VIO is encoded as an SRH-6LoRH (see		* The via list in the VIO is encoded as an SRH-6LoRH (see
	Figure 16), and it starts with the address of the first-hop node		Figure 16), and it starts with the address of the first-hop node
	after the Ingress node in the loose hop sequence.		after the ingress node in the loose hop sequence.
	* The via list ends with the address of the Egress node.		* The via list ends with the address of the egress node.
	| Note 1: The Egress of a Non-Storing Mode P-Route is implicitly		| Note 1: The egress of a Non-Storing Mode P-Route is implicitly
	| a target; it is not listed in the RPL Target Options but is		| a target; it is not listed in the RPL Target Options but is
	| still accounted for as if it was. The only exception is when		| still accounted for as if it was. The only exception is when
	| the Egress is the only address listed in the VIO, in which case		| the egress is the only address listed in the VIO, in which case
	| it would indicate via itself, which would be nonsensical.		| it would indicate via itself, which would be nonsensical.
	| Note 2: By design, the list of nodes in a VIO in Non-Storing		| Note 2: By design, the list of nodes in a VIO in Non-Storing
	| Mode is exactly the list that shows in the encapsulation SRH.		| Mode is exactly the list that shows in the encapsulation SRH.
	| So in the cases detailed below, if the Mode of the P-DAO is		| So in the cases detailed below, if the Mode of the P-DAO is
	| Non-Storing, then the VIO row can be read as indicating the SRH		| Non-Storing, then the VIO row can be read as indicating the SRH
	| as well.		| as well.
	3.5.1. Using Storing Mode Segments		3.5.1. Using Storing Mode Segments
	skipping to change at line 1068 ¶		skipping to change at line 1078 ¶
	* P-DAO 2 signals A==>B==>C-to-F,G		* P-DAO 2 signals A==>B==>C-to-F,G
	Storing Mode P-DAO 1 is sent to E, and when it is successfully		Storing Mode P-DAO 1 is sent to E, and when it is successfully
	acknowledged, Storing Mode P-DAO 2 is sent to C as follows:		acknowledged, Storing Mode P-DAO 2 is sent to C as follows:
	+====================+==============+==============+		+====================+==============+==============+
	| Field | P-DAO 1 to E | P-DAO 2 to C |		| Field | P-DAO 1 to E | P-DAO 2 to C |
	+====================+==============+==============+		+====================+==============+==============+
	| Mode | Storing | Storing |		| Mode | Storing | Storing |
	+====================+--------------+--------------+		+====================+--------------+--------------+
	| Track Ingress | A | A |		| Track ingress | A | A |
	+====================+--------------+--------------+		+====================+--------------+--------------+
	| (DODAGID, TrackID) | (A, 129) | (A, 129) |		| (DODAGID, TrackID) | (A, 129) | (A, 129) |
	+====================+--------------+--------------+		+====================+--------------+--------------+
	| SegmentID | 1 | 2 |		| SegmentID | 1 | 2 |
	+====================+--------------+--------------+		+====================+--------------+--------------+
	| VIO | C, D, E | A, B, C |		| VIO | C, D, E | A, B, C |
	+====================+--------------+--------------+		+====================+--------------+--------------+
	| Targets | F, G | F, G |		| Targets | F, G | F, G |
	+====================+--------------+--------------+		+====================+--------------+--------------+
	skipping to change at line 1162 ¶		skipping to change at line 1172 ¶
	* P-DAO 3 signals F and G via the A-->E-to-F,G Track		* P-DAO 3 signals F and G via the A-->E-to-F,G Track
	Storing Mode P-DAOs 1 and 2 and Non-Storing Mode P-DAO 3 are sent to		Storing Mode P-DAOs 1 and 2 and Non-Storing Mode P-DAO 3 are sent to
	E, C, and A, respectively, as follows:		E, C, and A, respectively, as follows:
	+====================+==============+==============+==============+		+====================+==============+==============+==============+
	| | P-DAO 1 to E | P-DAO 2 to C | P-DAO 3 to A |		| | P-DAO 1 to E | P-DAO 2 to C | P-DAO 3 to A |
	+====================+==============+==============+==============+		+====================+==============+==============+==============+
	| Mode | Storing | Storing | Non-Storing |		| Mode | Storing | Storing | Non-Storing |
	+====================+--------------+--------------+--------------+		+====================+--------------+--------------+--------------+
	| Track Ingress | A | A | A |		| Track ingress | A | A | A |
	+====================+--------------+--------------+--------------+		+====================+--------------+--------------+--------------+
	| (DODAGID, TrackID) | (A, 129) | (A, 129) | (A, 129) |		| (DODAGID, TrackID) | (A, 129) | (A, 129) | (A, 129) |
	+====================+--------------+--------------+--------------+		+====================+--------------+--------------+--------------+
	| SegmentID | 1 | 2 | 3 |		| SegmentID | 1 | 2 | 3 |
	+====================+--------------+--------------+--------------+		+====================+--------------+--------------+--------------+
	| VIO | C, D, E | A, B, C | E |		| VIO | C, D, E | A, B, C | E |
	+====================+--------------+--------------+--------------+		+====================+--------------+--------------+--------------+
	| Targets | E | E | F, G |		| Targets | E | E | F, G |
	+====================+--------------+--------------+--------------+		+====================+--------------+--------------+--------------+
	skipping to change at line 1263 ¶		skipping to change at line 1273 ¶
	* P-DAO 3 signals F and G via the A-->C-->E-to-(E),F,G Track		* P-DAO 3 signals F and G via the A-->C-->E-to-(E),F,G Track
	Storing Mode P-DAOs 1 and 2 and Non-Storing Mode P-DAO 3 are sent to		Storing Mode P-DAOs 1 and 2 and Non-Storing Mode P-DAO 3 are sent to
	E, B, and A, respectively, as follows:		E, B, and A, respectively, as follows:
	+====================+==============+==============+==============+		+====================+==============+==============+==============+
	| | P-DAO 1 to E | P-DAO 2 to B | P-DAO 3 to A |		| | P-DAO 1 to E | P-DAO 2 to B | P-DAO 3 to A |
	+====================+==============+==============+==============+		+====================+==============+==============+==============+
	| Mode | Storing | Storing | Non-Storing |		| Mode | Storing | Storing | Non-Storing |
	+====================+--------------+--------------+--------------+		+====================+--------------+--------------+--------------+
	| Track Ingress | A | A | A |		| Track ingress | A | A | A |
	+====================+--------------+--------------+--------------+		+====================+--------------+--------------+--------------+
	| (DODAGID, TrackID) | (A, 129) | (A, 129) | (A, 129) |		| (DODAGID, TrackID) | (A, 129) | (A, 129) | (A, 129) |
	+====================+--------------+--------------+--------------+		+====================+--------------+--------------+--------------+
	| SegmentID | 1 | 2 | 3 |		| SegmentID | 1 | 2 | 3 |
	+====================+--------------+--------------+--------------+		+====================+--------------+--------------+--------------+
	| VIO | C, D, E | A, B | C, E |		| VIO | C, D, E | A, B | C, E |
	+====================+--------------+--------------+--------------+		+====================+--------------+--------------+--------------+
	| Targets | E | B, C | F, G |		| Targets | E | B, C | F, G |
	+====================+--------------+--------------+--------------+		+====================+--------------+--------------+--------------+
	Table 7: P-DAO Messages		Table 7: P-DAO Messages
	Note in the table above that the segment can terminate at the loose		Note in the table above that the segment can terminate at the loose
	hop as used in the example of P-DAO 1 or at the previous hop as done		hop as used in the example of P-DAO 1 or at the previous hop as done
	with P-DAO 2. Both methods are possible on any segment joined by a		with P-DAO 2. Both methods are possible on any segment joined by a
	loose protection path. P-DAO 1 generates more signaling since E is		loose protection path. P-DAO 1 generates more signaling since E is
	the segment Egress when D could be, but a benefit is that it		the segment egress when D could be, but a benefit is that it
	validates that the connectivity between D and E still exists.		validates that the connectivity between D and E still exists.
	As a result, the RIBs are set as follows:		As a result, the RIBs are set as follows:
	+======+=============+=========+=============+==========+		+======+=============+=========+=============+==========+
	| Node | Destination | Origin | Next Hop(s) | TrackID |		| Node | Destination | Origin | Next Hop(s) | TrackID |
	+======+=============+=========+=============+==========+		+======+=============+=========+=============+==========+
	| E | F, G | P-DAO 1 | Neighbor | (A, 129) |		| E | F, G | P-DAO 1 | Neighbor | (A, 129) |
	+------+-------------+---------+-------------+----------+		+------+-------------+---------+-------------+----------+
	| D | E | P-DAO 1 | Neighbor | (A, 129) |		| D | E | P-DAO 1 | Neighbor | (A, 129) |
	skipping to change at line 1363 ¶		skipping to change at line 1373 ¶
	3.5.2.1. Stitched Tracks		3.5.2.1. Stitched Tracks
	Non-Storing Mode P-DAO 1 and 2 are sent to C and A, respectively, as		Non-Storing Mode P-DAO 1 and 2 are sent to C and A, respectively, as
	follows:		follows:
	+====================+==============+==============+		+====================+==============+==============+
	| | P-DAO 1 to C | P-DAO 2 to A |		| | P-DAO 1 to C | P-DAO 2 to A |
	+====================+==============+==============+		+====================+==============+==============+
	| Mode | Non-Storing | Non-Storing |		| Mode | Non-Storing | Non-Storing |
	+====================+--------------+--------------+		+====================+--------------+--------------+
	| Track Ingress | C | A |		| Track ingress | C | A |
	+====================+--------------+--------------+		+====================+--------------+--------------+
	| (DODAGID, TrackID) | (C, 131) | (A, 131) |		| (DODAGID, TrackID) | (C, 131) | (A, 131) |
	+====================+--------------+--------------+		+====================+--------------+--------------+
	| SegmentID | 1 | 1 |		| SegmentID | 1 | 1 |
	+====================+--------------+--------------+		+====================+--------------+--------------+
	| VIO | D, E | B, C |		| VIO | D, E | B, C |
	+====================+--------------+--------------+		+====================+--------------+--------------+
	| Targets | F, G | E, F, G |		| Targets | F, G | E, F, G |
	+====================+--------------+--------------+		+====================+--------------+--------------+
	skipping to change at line 1405 ¶		skipping to change at line 1415 ¶
	| " | C, E, F, G | P-DAO 2 | B, C | (A, 131) |		| " | C, E, F, G | P-DAO 2 | B, C | (A, 131) |
	+------+-------------+---------+-------------+----------+		+------+-------------+---------+-------------+----------+
	Table 11: RIB Settings		Table 11: RIB Settings
	Packets originated at A to E, F, and G could be generated with the		Packets originated at A to E, F, and G could be generated with the
	RPI and the SRH and no encapsulation. Alternatively, A may generate		RPI and the SRH and no encapsulation. Alternatively, A may generate
	a native packet to the target and then encapsulate it with an RPI and		a native packet to the target and then encapsulate it with an RPI and
	an SRH indicating the source-routed path leading to E, as it would		an SRH indicating the source-routed path leading to E, as it would
	for a packet that it routes coming from another node. This is		for a packet that it routes coming from another node. This is
	effectively the same case as for packets generated by the root in a		effectively the same case as for packets generated by the Root in a
	RPL network in Non-Storing Mode; see Section 8.1.3 of [RFC9008]. The		RPL network in Non-Storing Mode; see Section 8.1.3 of [RFC9008]. The
	latter is often preferred since it leads to a single code path, and		latter is often preferred since it leads to a single code path, and
	when the destination is F or G, it does not need to understand and		when the destination is F or G, it does not need to understand and
	process the RPI or the SRH. Either way, the packets to E, F, or G		process the RPI or the SRH. Either way, the packets to E, F, or G
	carry an SRH via B and C, and when they reach C, C needs to		carry an SRH via B and C, and when they reach C, C needs to
	encapsulate them again to add an SRH via D and E. The encapsulating		encapsulate them again to add an SRH via D and E. The encapsulating
	headers of packets that are forwarded along the Track between C and E		headers of packets that are forwarded along the Track between C and E
	have the following settings:		have the following settings:
	+========+=====================+==========================+=========+		+========+=====================+==========================+=========+
	skipping to change at line 1464 ¶		skipping to change at line 1474 ¶
	* P-DAO 3 signals F and G via the A-->E-to-F,G Track		* P-DAO 3 signals F and G via the A-->E-to-F,G Track
	Non-Storing Mode P-DAO 1 is sent to C, and Non-Storing Mode P-DAOs 2		Non-Storing Mode P-DAO 1 is sent to C, and Non-Storing Mode P-DAOs 2
	and 3 are sent to A, as follows:		and 3 are sent to A, as follows:
	+====================+==============+==============+==============+		+====================+==============+==============+==============+
	| | P-DAO 1 to C | P-DAO 2 to A | P-DAO 3 to A |		| | P-DAO 1 to C | P-DAO 2 to A | P-DAO 3 to A |
	+====================+==============+==============+==============+		+====================+==============+==============+==============+
	| Mode | Non-Storing | Non-Storing | Non-Storing |		| Mode | Non-Storing | Non-Storing | Non-Storing |
	+====================+--------------+--------------+--------------+		+====================+--------------+--------------+--------------+
	| Track Ingress | C | A | A |		| Track ingress | C | A | A |
	+====================+--------------+--------------+--------------+		+====================+--------------+--------------+--------------+
	| (DODAGID, TrackID) | (C, 131) | (A, 129) | (A, 141) |		| (DODAGID, TrackID) | (C, 131) | (A, 129) | (A, 141) |
	+====================+--------------+--------------+--------------+		+====================+--------------+--------------+--------------+
	| SegmentID | 1 | 1 | 1 |		| SegmentID | 1 | 1 | 1 |
	+====================+--------------+--------------+--------------+		+====================+--------------+--------------+--------------+
	| VIO | D, E | B, C | E |		| VIO | D, E | B, C | E |
	+====================+--------------+--------------+--------------+		+====================+--------------+--------------+--------------+
	| Targets | | E | F, G |		| Targets | | E | F, G |
	+====================+--------------+--------------+--------------+		+====================+--------------+--------------+--------------+
	Table 13: P-DAO Messages		Table 13: P-DAO Messages
	Note in the table above that E is an implicit Target in P-DAO 1 and		Note in the table above that E is an implicit Target in P-DAO 1 and
	so is C in P-DAO 2. As Non-Storing Mode Egress node addresses, they		so is C in P-DAO 2. As Non-Storing Mode egress node addresses, they
	are not listed in the respective RTOs.		are not listed in the respective RTOs.
	As a result, the RIBs are set as follows:		As a result, the RIBs are set as follows:
	+======+=============+=========+=============+==========+		+======+=============+=========+=============+==========+
	| Node | Destination | Origin | Next Hop(s) | TrackID |		| Node | Destination | Origin | Next Hop(s) | TrackID |
	+======+=============+=========+=============+==========+		+======+=============+=========+=============+==========+
	| E | F, G | ND | Neighbor | Any |		| E | F, G | ND | Neighbor | Any |
	+------+-------------+---------+-------------+----------+		+------+-------------+---------+-------------+----------+
	| D | E | ND | Neighbor | Any |		| D | E | ND | Neighbor | Any |
	skipping to change at line 1564 ¶		skipping to change at line 1574 ¶
	* P-DAO 3 signals F and G via the A-->C-->E-to-(E),F,G Track		* P-DAO 3 signals F and G via the A-->C-->E-to-(E),F,G Track
	Non-Storing Mode P-DAO 1 is sent to C, and Non-Storing Mode P-DAOs 2		Non-Storing Mode P-DAO 1 is sent to C, and Non-Storing Mode P-DAOs 2
	and 3 are sent to A, as follows:		and 3 are sent to A, as follows:
	+====================+==============+==============+==============+		+====================+==============+==============+==============+
	| | P-DAO 1 to C | P-DAO 2 to A | P-DAO 3 to A |		| | P-DAO 1 to C | P-DAO 2 to A | P-DAO 3 to A |
	+====================+==============+==============+==============+		+====================+==============+==============+==============+
	| Mode | Non-Storing | Non-Storing | Non-Storing |		| Mode | Non-Storing | Non-Storing | Non-Storing |
	+====================+--------------+--------------+--------------+		+====================+--------------+--------------+--------------+
	| Track Ingress | C | A | A |		| Track ingress | C | A | A |
	+====================+--------------+--------------+--------------+		+====================+--------------+--------------+--------------+
	| (DODAGID, TrackID) | (C, 131) | (A, 129) | (A, 141) |		| (DODAGID, TrackID) | (C, 131) | (A, 129) | (A, 141) |
	+====================+--------------+--------------+--------------+		+====================+--------------+--------------+--------------+
	| SegmentID | 1 | 1 | 1 |		| SegmentID | 1 | 1 | 1 |
	+====================+--------------+--------------+--------------+		+====================+--------------+--------------+--------------+
	| VIO | D, E | B | C, E |		| VIO | D, E | B | C, E |
	+====================+--------------+--------------+--------------+		+====================+--------------+--------------+--------------+
	| Targets | | C | F, G |		| Targets | | C | F, G |
	+====================+--------------+--------------+--------------+		+====================+--------------+--------------+--------------+
	skipping to change at line 1678 ¶		skipping to change at line 1688 ¶
	* From P-DAO 1: C encapsulates the packet with a destination of E in		* From P-DAO 1: C encapsulates the packet with a destination of E in
	the Track signaled by P-DAO 1. The outer header has source C,		the Track signaled by P-DAO 1. The outer header has source C,
	destination D, an SRH that indicates E as the next loose hop, and		destination D, an SRH that indicates E as the next loose hop, and
	an RPI indicating a TrackID of 131 from C's namespace. E		an RPI indicating a TrackID of 131 from C's namespace. E
	decapsulates.		decapsulates.
	3.6. Complex Tracks		3.6. Complex Tracks
	To increase the reliability of the P2P transmission, this		To increase the reliability of the P2P transmission, this
	specification enables building a collection of protection paths		specification enables building a collection of protection paths
	between the same Ingress and Egress Nodes and combining them within		between the same ingress and egress Nodes and combining them within
	the same TrackID, as shown in Figure 7. Protection paths may be		the same TrackID, as shown in Figure 7. Protection paths may be
	interleaved at the edges of loose hops or remain parallel.		interleaved at the edges of loose hops or remain parallel.
	The segments that join the loose hops of a protection path are		The segments that join the loose hops of a protection path are
	installed with the same TrackID as the protection path. But each		installed with the same TrackID as the protection path. But each
	individual protection path and segment has its own P-RouteID that		individual protection path and segment has its own P-RouteID that
	allows it to be managed separately. Two protection paths of the same		allows it to be managed separately. Two protection paths of the same
	Track may cross at a common node that participates to a segment of		Track may cross at a common node that is a member of a segment of
	each protection path or that may be joined by additional segments.		each protection path or may be joined by additional segments. The
	The final path of a packet may then be the result of interleaving		final path of a packet may then be the result of interleaving those
	those two (and possibly more) protection paths. In that case, the		two (and possibly more) protection paths. In that case, the common
	common node has more than one next hop in its RIB associated to the		node has more than one next hop in its RIB associated to the Track
	Track but no specific signal in the packet to indicate which segment		but no specific signal in the packet to indicate which segment is
	is being followed. A next hop that can reach the loose hop is		being followed. A next hop that can reach the loose hop is selected.
	selected.
	< Controller Plane Functions >		< Controller Plane Functions >
	Southbound API		Southbound API
	_-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-		_-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-
	_-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-		_-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-
	+----------+		+----------+
	| RPL Root |		| RPL Root |
	skipping to change at line 1738 ¶		skipping to change at line 1747 ¶
	<- Protection path 3 via B, H, E ->		<- Protection path 3 via B, H, E ->
	)		)
	(		(
	( )		( )
	Figure 7: Segments and Tracks		Figure 7: Segments and Tracks
	Note that while this specification enables building both segments		Note that while this specification enables building both segments
	inside a protection path, for instance segment 2 above which is		inside a protection path, for instance, segment 2 above (which is
	within protection path 1, and Inter-protection-path segments (i.e.,		within protection path 1) and Inter-protection-path segments (i.e.,
	North-South), for instance segment 5 above which joins protection		North-South) such as segment 5 above (which joins protection paths 1
	path 1 and protection path 2, it does not signal to the Ingress which		and 2), it does not signal which Inter-protection-path segments are
	Inter-protection-path segments are available, so the use of North-		available to the ingress, so the use of North-South segments and
	South segments and associated path redundancy functions is currently		associated path redundancy functions is currently limited. The only
	limited. The only possibility available at this time is to define		possibility available at this time is to define overlapping
	overlapping protection paths as illustrated in Figure 7, with		protection paths as illustrated in Figure 7, with protection path 3
	protection path 3 that is congruent with protection path 1 until node		that is congruent with protection path 1 until node B and that is
	B and that is congruent with protection path 2 from node H on,		congruent with protection path 2 from node H on, abstracting segment
	abstracting segment 5 as a forward segment.		5 as a forward segment.
	3.7. Scope and Expectations		3.7. Scope and Expectations
	3.7.1. External Dependencies		3.7.1. External Dependencies
	This specification expects that the main DODAG is operated in RPL		This specification expects that the main DODAG is operated in RPL
	Non-Storing Mode to sustain the exchanges with the Root. Based on		Non-Storing Mode to sustain the exchanges with the Root. Based on
	its comprehensive knowledge of the parent-child relationship, the		its comprehensive knowledge of the parent-child relationship, the
	Root can form an abstracted view of the whole DODAG topology. This		Root can form an abstracted view of the whole DODAG topology. This
	document adds the capability for nodes to advertise additional		document adds the capability for nodes to advertise additional
	skipping to change at line 1775 ¶		skipping to change at line 1784 ¶
	each node must be computed to fit within the node's memory, and the		each node must be computed to fit within the node's memory, and the
	amount of rerouted traffic must fit within the capabilities of the		amount of rerouted traffic must fit within the capabilities of the
	transmission links. The methods used to learn the node capabilities		transmission links. The methods used to learn the node capabilities
	and the resources that are available in the devices and in the		and the resources that are available in the devices and in the
	network are out of scope for this document. The method to capture		network are out of scope for this document. The method to capture
	and report the LLN link capacity and reliability statistics are also		and report the LLN link capacity and reliability statistics are also
	out of scope. They may be fetched from the nodes through network		out of scope. They may be fetched from the nodes through network
	management functions or other forms of telemetry such as Operations,		management functions or other forms of telemetry such as Operations,
	Administration, and Maintenance (OAM).		Administration, and Maintenance (OAM).
	3.7.2. Positioning Versus Related IETF Standards		3.7.2. Relationship to Other IETF Specifications
	3.7.2.1. Extending 6TiSCH		3.7.2.1. Extending 6TiSCH
	The 6TiSCH architecture [RFC9030] leverages a centralized model that		The 6TiSCH architecture [RFC9030] leverages a centralized model that
	is similar to that of the DetNet architecture [RFC8655], whereby the		is similar to that of the DetNet architecture [RFC8655], whereby the
	device resources and capabilities are exposed to an external		device resources and capabilities are exposed to an external
	controller that installs routing states into the network based on its		controller that installs routing states into the network based on its
	own objective functions that reside in that external entity.		own Objective Functions that reside in that external entity.
	3.7.2.2. Mapping to DetNet		3.7.2.2. Mapping to DetNet
	DetNet Forwarding Nodes only understand the simple 1-to-1 forwarding		DetNet forwarding nodes only understand the simple 1-to-1 forwarding
	sublayer transport operation along a segment whereas the more		sublayer transport operation along a segment whereas the more
	sophisticated Relay nodes can also provide service sublayer functions		sophisticated relay nodes can also provide service sublayer functions
	such as Replication and Elimination.		such as Replication and Elimination.
	One possible mapping between DetNet and this specification is to		One possible mapping between DetNet and this specification is to
	signal the Relay Nodes as the hops of a protection path and the		signal the relay nodes as the hops of a protection path and the
	forwarding nodes as the hops in a segment that join the Relay nodes		forwarding nodes as the hops in a segment that join the relay nodes
	as illustrated in Figure 7.		as illustrated in Figure 7.
	3.7.2.3. Leveraging PCE		3.7.2.3. Leveraging PCE
	With DetNet and 6TiSCH, the component of the controller that is		With DetNet and 6TiSCH, the component of the controller that is
	responsible for computing routes is a PCE. The PCE computes its		responsible for computing routes is a PCE. The PCE computes its
	routes based on its own objective functions, as described in		routes based on its own Objective Functions, as described in
	[RFC4655], and typically controls the routes using the PCE		[RFC4655], and typically controls the routes using the PCE
	Communication Protocol (PCEP) [RFC5440]. While this specification		Communication Protocol (PCEP) [RFC5440]. While this specification
	expects a PCE, and while PCEP might effectively be used between the		expects a PCE, and while PCEP might effectively be used between the
	Root and the PCE, the control protocol between the PCE and the Root		Root and the PCE, the control protocol between the PCE and the Root
	is out of scope.		is out of scope.
	This specification also expects a single PCE with a full view of the		This specification also expects a single PCE with a full view of the
	network. Distributing the PCE function for a large network is out of		network. Distributing the PCE function for a large network is out of
	scope. This specification uses the RPL Root as a proxy to the PCE.		scope. This specification uses the RPL Root as a proxy to the PCE.
	The PCE may be collocated with the Root or reside in an external		The PCE may be collocated with the Root or may reside in an external
	controller. In that case, the protocol between the Root and the PCE		Controller. In the latter case, the protocol between the Root and
	is out of scope and mapped to RPL inside the DODAG; one possibility		the PCE is out of scope and mapped to RPL inside the DODAG; one
	is for the Root to transmit to the PCEs the information it received		possible control protocol between the Root and external PCE is for
	in RPL DAOs including all the SIOs that detail the parent/child and		the Root to transmit the information it received in the RPL DAOs,
	sibling information.		including all the SIOs that detail the parent/child and sibling
			information, to the PCEs.
	The algorithm to compute the paths, the protocol used by the PCE, and		The algorithm to compute the paths, the protocol used by the PCE, and
	the metrics and link statistics involved in the computation are also		the metrics and link statistics involved in the computation are also
	out of scope. The effectiveness of the route computation by the PCE		out of scope. The effectiveness of the route computation by the PCE
	depends on the quality of the metrics that are reported from the RPL		depends on the quality of the metrics that are reported from the RPL
	network. Which metrics are used and how they are reported are out of		network. Which metrics are used and how they are reported are out of
	scope, but the expectation is that they are mostly of a long-term,		scope, but the expectation is that they are mostly of a long-term,
	statistical nature and provide visibility on link throughput,		statistical nature and provide visibility on link throughput,
	latency, stability, and availability over relatively long periods.		latency, stability, and availability over relatively long periods.
	3.7.2.4. Providing for RAW		3.7.2.4. Providing for RAW
	The RAW architecture [RAW-ARCH] extends the definition of Track, as		The RAW architecture [RAW-ARCH] extends the definition of Track as
	being composed of forward directional segments and North-South		being composed of forward directional segments and North-South
	bidirectional segments, to enable additional path diversity, using		bidirectional segments to enable additional path diversity using
	PAREO functions over the available paths, to provide a dynamic		PREOF functions over the available paths. This provides a dynamic
	balance between the reliability and availability requirements of the		balance between the reliability and availability requirements of the
	flows and the need to conserve energy and spectrum. This		flows and the need to conserve energy and spectrum. This
	specification prepares for RAW by setting up the Tracks, but it only		specification prepares for RAW by setting up the Tracks, but it only
	forms DODAGs, which are composed of aggregated end-to-end loose		forms DODAGs, which are composed of aggregated end-to-end loose
	source-routed protection paths, joined by strict routed segments, all		source-routed protection paths, joined by strict routed segments, all
	oriented forward.		oriented forward.
	The RAW architecture defines a data plane extension of the PCE called		The RAW architecture defines a data plane extension of the PCE called
	the Point of Local Repair (PLR) that adapts the use of the path		the Point of Local Repair (PLR) that adapts the use of the path
	redundancy within a Track to defeat the diverse causes of packet		redundancy within a Track to defeat the diverse causes of packet
	skipping to change at line 1858 ¶		skipping to change at line 1868 ¶
	of the available redundancy is limited to simple load balancing, and		of the available redundancy is limited to simple load balancing, and
	all the segments are forward unidirectional only.		all the segments are forward unidirectional only.
	A Track may be set up to reduce the load around the Root or to enable		A Track may be set up to reduce the load around the Root or to enable
	urgent traffic to flow more directly. This specification does not		urgent traffic to flow more directly. This specification does not
	provide the policies that would decide which flows are routed through		provide the policies that would decide which flows are routed through
	which Track. In a Non-Storing Mode RPL Instance, the main DODAG		which Track. In a Non-Storing Mode RPL Instance, the main DODAG
	provides a default route via the Root, and the Tracks provide more-		provides a default route via the Root, and the Tracks provide more-
	specific routes to the Track Targets.		specific routes to the Track Targets.
	4. Extending Existing RFCs		4. Extending and Amending Existing RFCs
	This section explains which changes are extensions and which are		This section explains which changes are extensions and which are
	amendments to existing specifications. It is expected that		amendments to existing specifications. It is expected that
	extensions to existing specifications will not cause existing code on		extensions to existing specifications will not cause existing code on
	legacy 6LRs to malfunction, as the extensions will simply be ignored.		legacy 6LRs to malfunction, as the extensions will simply be ignored.
	New code is required for an extension. Those 6LRs will be unable to		New code is required for an extension. Those 6LRs will be unable to
	participate in the new mechanisms and may also cause P-DAOs to be		function in the new mechanisms and may also make the P-DAOs
	impossible to install. Amendments to existing specifications are		impossible to install. Amendments to existing specifications are
	situations where there are semantic changes required to existing code		situations where there are semantic changes required to existing code
	and where new unit tests may be required to confirm that legacy		and where new unit tests may be required to confirm that legacy
	operations will continue unaffected.		operations will continue unaffected.
	4.1. Extending RPL RFC 6550		4.1. Extending RFC 6550
	This specification Extends RPL [RPL] to enable the Root to install		This specification Extends RPL [RPL] to enable the Root to install
	forward routes inside a main DODAG that is operated as Non-Storing		forward routes inside a main DODAG that is operated as Non-Storing
	Mode. The Root issues a P-DAO message (see Section 4.1.1) to the		Mode. The Root issues a P-DAO message (see Section 4.1.1) to the
	Track Ingress; the P-DAO message contains a new VIO that installs a		Track ingress; the P-DAO message contains a new VIO that installs a
	strict or a loose sequence of hops to form a Track segment or a		strict or a loose sequence of hops to form a Track segment or a
	protection path, respectively.		protection path, respectively.
	The P-DAO Request (PDR) is a new message detailed in Section 5.1. As		The P-DAO Request (PDAOReq) is a new message detailed in Section 5.1.
	per Section 6 of [RPL], if a node receives this message and it does		As per Section 6 of [RPL], if a node receives this message and it
	not understand this new code, it discards the message. When the Root		does not understand this new code, it discards the message. When the
	initiates communication to a node that it has not communicated with		Root initiates communication to a node that it has not communicated
	before and that it has not ascertained to implement this		with before and that it has not ascertained to implement this
	specification (by means such as capabilities), then the Root SHOULD		specification (by means such as capabilities), then the Root SHOULD
	request a PDR-ACK.		request a P-DAO Request Acknowledgement (PDR-ACK).
	A PDR message enables a Track Ingress to request the Track from the		A PDAOReq message enables a Track ingress to request the Track from
	Root. The resulting Track is also a DODAG for which the Track		the Root. The resulting Track is also a DODAG for which the Track
	Ingress is the Root, and the owner is the address that serves as the		ingress is the Root, and the owner is the address that serves as the
	DODAGID and is authoritative for the associated namespace from which		DODAGID and is authoritative for the associated namespace from which
	the TrackID is selected. In the context of this specification, the		the TrackID is selected. In the context of this specification, the
	installed route appears as a more-specific route to the Track		installed route appears as a more-specific route to the Track
	Targets, and the Track Ingress forwards the packets toward the		Targets, and the Track ingress forwards the packets toward the
	Targets via the Track using normal longest match IP forwarding.		Targets via the Track using normal longest match IP forwarding.
	To ensure that the PDR and P-DAO messages can flow at most times, it		To ensure that the PDAOReq and P-DAO messages can flow at most times,
	is RECOMMENDED that the nodes involved in a Track maintain multiple		it is RECOMMENDED that the nodes involved in a Track maintain
	parents in the main DODAG, advertise them all to the Root, and use		multiple parents in the main DODAG, advertise them all to the Root,
	them in turn to retry similar packets. It is also RECOMMENDED that		and use them in turn to retry similar packets. It is also
	the Root uses diverse source route paths to retry similar messages to		RECOMMENDED that the Root uses diverse source route paths to retry
	the nodes in the Track.		similar messages to the nodes in the Track.
	4.1.1. Projected DAO		4.1.1. Projected DAO
	Section 6 of [RPL] introduces the RPL Control Message Options (CMOs),		Section 6 of [RPL] introduces the RPL Control Message Options (CMOs),
	including the RPL Target Option (RTO) and Transit Information Option		including the RPL Target Option (RTO) and Transit Information Option
	(TIO), which can be placed in RPL messages such as the DAO. A DAO		(TIO), which can be placed in RPL messages such as the DAO. A DAO
	message signals routing information to one or more Targets indicated		message signals routing information to one or more Targets indicated
	in the RTOs and provides one and only one via-node in the TIO, with		in the RTOs and provides one and only one via-node in the TIO, with
	the via-node being the tunnel endpoint to reach the targets.		the via-node being the tunnel endpoint to reach the targets.
	skipping to change at line 1946 ¶		skipping to change at line 1956 ¶
	typically with the Network Control precedence.		typically with the Network Control precedence.
	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
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| TrackID |K|D|P| Flags | Reserved | DAOSequence |		| TrackID |K|D|P| Flags | Reserved | DAOSequence |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| |		| |
	+ +		+ +
	| DODAGID field is set to the |		| DODAGID field is set to the |
	+ IPv6 address of the Track Ingress +		+ IPv6 address of the Track ingress +
	| used to source encapsulated packets |		| used to source encapsulated packets |
	+ +		+ +
	| |		| |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| Option(s)...		| Option(s)...
	+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+
	Figure 8: Projected DAO Base Object		Figure 8: Projected DAO Base Object
	New fields:		New fields:
	TrackID: The Local or Global RPLInstanceID of the DODAG that serves		TrackID: The Local or Global RPLInstanceID of the DODAG that serves
	as the Track (see more in Section 6.3).		as the Track (see more in Section 6.3).
	P: 1-bit flag.		P: 1-bit flag.
	The 'P' flag is set to 1 by the Root to signal a P-DAO; otherwise,		The 'P' flag is set to 1 by the Root to signal a P-DAO; otherwise,
	it is set to 0.		it is set to 0.
	The D flag is set to 1 to signal that the DODAGID field is present.		The 'D' flag is set to 1 to signal that the DODAGID field is present.
	It may be set to 0 if and only if the destination address of the P-		It may be set to 0 if and only if the destination address of the
	DAO-ACK message is set to the IPv6 address that serves as the		Projected DAO-ACK (P-DAO-ACK) message is set to the IPv6 address that
	DODAGID, and it MUST be set to one otherwise, meaning that the		serves as the DODAGID, and it MUST be set to one otherwise, meaning
	DODAGID field MUST then be present.		that the DODAGID field MUST then be present.
	In RPL Non-Storing Mode, the TIO and RTO are combined in a DAO		In RPL Non-Storing Mode, the TIO and RTO are combined in a DAO
	message to inform the DODAG Root of all the edges in the DODAG, which		message to inform the DODAG Root of all the edges in the DODAG, which
	are formed by the directed parent-child relationships. The DAO		are formed by the directed parent-child relationships. The DAO
	message signals to the Root that a given parent can be used to reach		message signals to the Root that a given parent can be used to reach
	a given child. The P-DAO message generalizes the DAO to signal to		a given child. The P-DAO message generalizes the DAO to signal to
	the Track Ingress that a Track for which it is the Root can be used		the Track ingress that a Track, for which the sender is the Root, can
	to reach children and siblings of the Track Egress. In both cases,		be used to reach children and siblings of the Track egress. In both
	options may be factorized and multiple RTOs may be present to signal		cases, options may be factorized and multiple RTOs may be present to
	a collection of children that can be reached through the parent or		signal a collection of children that can be reached through the
	the Track, respectively.		parent or the Track, respectively.
	4.1.2. Projected DAO-ACK		4.1.2. Projected DAO-ACK
	This document also Amends the DAO-ACK message. The new P flag		This document also Amends the DAO-ACK message. The new 'P' flag
	signals the projected form.		signals the projected form.
	The format of the P-DAO-ACK message is thus illustrated in Figure 9:		The format of the P-DAO-ACK message is thus illustrated in Figure 9:
	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
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| TrackID |D|P| Reserved | DAOSequence | Status |		| TrackID |D|P| Reserved | DAOSequence | Status |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| |		| |
	+ +		+ +
	| DODAGID field is set to the |		| DODAGID field is set to the |
	+ IPv6 address of the Track Ingress +		+ IPv6 address of the Track ingress +
	| used to source encapsulated packets |		| used to source encapsulated packets |
	+ +		+ +
	| |		| |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| Option(s)...		| Option(s)...
	+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+
	Figure 9: Projected DAO-ACK Base Object		Figure 9: Projected DAO-ACK Base Object
	New fields:		New fields:
	TrackID: The Local or Global RPLInstanceID of the DODAG that serves		TrackID: The Local or Global RPLInstanceID of the DODAG that serves
	as the Track (see more in Section 6.3).		as the Track (see more in Section 6.3).
	P: 1-bit flag.		P: 1-bit flag.
	The 'P' flag is set to 1 by the Root to signal a P-DAO; otherwise,		The 'P' flag is set to 1 by the Root to signal a P-DAO; otherwise,
	it is set to 0.		it is set to 0.
	The D flag is set to 1 to signal that the DODAGID field is present.		The 'D' flag is set to 1 to signal that the DODAGID field is present.
	It may be set to 0 if and only if the source address of the P-DAO-ACK		It may be set to 0 if and only if the source address of the P-DAO-ACK
	message is set to the IPv6 address that serves as the DODAGID, and it		message is set to the IPv6 address that serves as the DODAGID, and it
	MUST be set to one otherwise, meaning that the DODAGID field MUST		MUST be set to one otherwise, meaning that the DODAGID field MUST
	then be present.		then be present.
	4.1.3. Via Information Option		4.1.3. Via Information Option
	This document Extends the CMO to create new objects called Via		This document Extends the CMO to create new objects called Via
	Information Options (VIOs). The VIOs are the multi-hop alternative		Information Options (VIOs). The VIOs are the multi-hop alternative
	to the TIOs (see more in Section 5.3). One VIO is the stateful		to the TIOs (see more in Section 5.3). One VIO is the stateful
	Storing Mode VIO (SM-VIO); an SM-VIO installs a strict hop-by-hop		Storing Mode VIO (SM-VIO); an SM-VIO installs a strict hop-by-hop
	P-Route called a Track segment. The other is the Non-Storing Mode		P-Route called a Track segment. The other is the Non-Storing Mode
	VIO (NSM-VIO); the NSM-VIO installs a loose source-routed P-Route		VIO (NSM-VIO); the NSM-VIO installs a loose source-routed P-Route
	called a protection path at the Track Ingress, which uses that state		called a protection path at the Track ingress, which uses that state
	to encapsulate an IP-in-IP packet with a new Routing Header (RH) to		to encapsulate an IP-in-IP packet with a new Routing Header (RH) to
	the Track Egress (see more in Section 6.7).		the Track egress (see more in Section 6.7).
	A P-DAO contains one or more RTOs to indicate the Target		A P-DAO contains one or more RTOs to indicate the Target
	(destinations) that can be reached via the P-Route, followed by		(destinations) that can be reached via the P-Route, followed by
	exactly one VIO that signals the sequence of nodes to be followed		exactly one VIO that signals the sequence of nodes to be followed
	(see more in Section 6). There are two modes of operation for the		(see more in Section 6). There are two modes of operation for the
	P-Routes: Storing Mode and Non-Storing Mode (see more in Sections		P-Routes: Storing Mode and Non-Storing Mode (see more in Sections
	6.4.2 and 6.4.3, respectively).		6.4.2 and 6.4.3, respectively).
	4.1.4. Sibling Information Option		4.1.4. Sibling Information Option
	skipping to change at line 2083 ¶		skipping to change at line 2093 ¶
	| 2. The multicast DAO may be used to enable direct and indirect		| 2. The multicast DAO may be used to enable direct and indirect
	| (via a common neighbor) P2P communication without needing the		| (via a common neighbor) P2P communication without needing the
	| DODAG to relay the packets. The multicast DAO exposes the		| DODAG to relay the packets. The multicast DAO exposes the
	| sender's addresses as Targets in RTOs and the sender's		| sender's addresses as Targets in RTOs and the sender's
	| neighbors addresses as siblings in SIOs; this tells the		| neighbors addresses as siblings in SIOs; this tells the
	| sender's neighbors that the sender is willing to act as a		| sender's neighbors that the sender is willing to act as a
	| relay between those of its neighbors that are too far apart.		| relay between those of its neighbors that are too far apart.
	4.1.5. P-DAO Request		4.1.5. P-DAO Request
	The set of RPL Control Messages is Extended to include the PDR and		The set of RPL Control Messages is Extended to include the PDAOReq
	P-DAO Request Acknowledgement (PDR-ACK). These two new RPL Control		and PDR-ACK. These two new RPL Control Messages enable a RAN to
	Messages enable a RAN to request the establishment of a Track between		request the establishment of a Track between itself (as the Track
	itself (as the Track Ingress Node) and a Track Egress. The node		ingress Node) and a Track egress. The node makes its request by
	makes its request by sending a new PDR message to the Root. The Root		sending a new PDAOReq message to the Root. The Root confirms with a
	confirms with a new PDR-ACK message back to the requester RAN; see		new PDR-ACK message back to the requester RAN; see Section 5.1 for
	Section 5.1 for more.		more.
	4.1.6. Amending the RPI		4.1.6. Amending the RPI
	Sending a packet within a RPL Local Instance requires the presence of		Sending a packet within a RPL Local Instance requires the presence of
	the abstract RPI described in Section 11.2 of [RPL] in the outer IPv6		the abstract RPI described in Section 11.2 of [RPL] in the outer IPv6
	header chain (see [RFC9008]). The RPI carries a Local RPLInstanceID		header chain (see [RFC9008]). The RPI carries a Local RPLInstanceID
	that, in association with either the source or the destination		that, in association with either the source or the destination
	address in the IPv6 header, indicates the RPL Instance that the		address in the IPv6 header, indicates the RPL Instance that the
	packet follows.		packet follows.
	skipping to change at line 2138 ¶		skipping to change at line 2148 ¶
	Figure 10: DODAG Configuration Option (Partial View)		Figure 10: DODAG Configuration Option (Partial View)
	This specification Amends [RPL] to define the new "Projected Routes		This specification Amends [RPL] to define the new "Projected Routes
	Support" (D) flag. The 'D' flag is encoded in bit position 0 of the		Support" (D) flag. The 'D' flag is encoded in bit position 0 of the
	reserved Flags in the DODAG Configuration option (this is the most		reserved Flags in the DODAG Configuration option (this is the most
	significant bit). It is set to 0 in legacy implementations as		significant bit). It is set to 0 in legacy implementations as
	specified respectively in Sections 20.14 and 6.7.6 of [RPL].		specified respectively in Sections 20.14 and 6.7.6 of [RPL].
	The 'D' flag is set to 1 to indicate that this specification is		The 'D' flag is set to 1 to indicate that this specification is
	enabled in the network and that the Root will install the requested		enabled in the network and that the Root will install the requested
	Tracks when feasible upon receiving a PDR message.		Tracks when feasible upon receiving a PDAOReq message.
	Section 4.1.2 of [RFC9008] Amends [RPL] to indicate that the		Section 4.1.2 of [RFC9008] Amends [RPL] to indicate that the
	definition of the Flags applies to MOP values from zero (0) to six		definition of the Flags applies to MOP values from zero (0) to six
	(6) only. For a MOP value of 7, the implementation MUST consider		(6) only. For a MOP value of 7, the implementation MUST consider
	that the Root accepts PDR messages and will install P-Routes.		that the Root accepts PDAOReq messages and will install P-Routes.
	The RPL DODAG Configuration option is typically placed in a DIO		The RPL DODAG Configuration option is typically placed in a DIO
	message. The DIO message propagates down the DODAG to form and then		message. The DIO message propagates down the DODAG to form and then
	maintain its structure. The DODAG Configuration option is copied		maintain its structure. The DODAG Configuration option is copied
	unmodified from parents to children.		unmodified from parents to children.
	[RPL] states that:		[RPL] states that:
	| Nodes other than the DODAG root MUST NOT modify this information		| Nodes other than the DODAG root MUST NOT modify this information
	| when propagating the DODAG Configuration option.		| when propagating the DODAG Configuration option.
	Therefore, a legacy parent propagates the 'D' flag as set by the		Therefore, a legacy parent propagates the 'D' flag as set by the
	root, and when the 'D' flag is set to 1, it is transparently flooded		Root, and when the 'D' flag is set to 1, it is transparently flooded
	to all the nodes in the DODAG.		to all the nodes in the DODAG.
	4.2. Extending RPL RFC 6553		4.2. Extending RFC 6553
	"The Routing Protocol for Low-Power and Lossy Networks (RPL) Option		"The Routing Protocol for Low-Power and Lossy Networks (RPL) Option
	for Carrying RPL Information in Data-Plane Datagrams" [RFC6553]		for Carrying RPL Information in Data-Plane Datagrams" [RFC6553]
	describes the RPL Option for use among RPL routers to include the		describes the RPL Option for use among RPL routers to include the
	abstract RPI described in Section 11.2 of [RPL] in data packets.		abstract RPI described in Section 11.2 of [RPL] in data packets.
	The RPL Option is commonly referred to as the RPI even though the RPI		The RPL Option is commonly referred to as the RPI even though the RPI
	is really the abstract information that is transported in the RPL		is really the abstract information that is transported in the RPL
	Option. [RFC9008] updated the Option Type from 0x63 to 0x23.		Option. [RFC9008] updated the Option Type from 0x63 to 0x23.
	skipping to change at line 2190 ¶		skipping to change at line 2200 ¶
	| (sub-TLVs) |		| (sub-TLVs) |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	Figure 11: Amended RPL Option Format		Figure 11: Amended RPL Option Format
	Option Type: 0x23 or 0x63; see [RFC9008].		Option Type: 0x23 or 0x63; see [RFC9008].
	Opt Data Len: See [RFC6553].		Opt Data Len: See [RFC6553].
	'O', 'R', and 'F' flags: See [RFC6553]. These flags MUST be set to		'O', 'R', and 'F' flags: See [RFC6553]. These flags MUST be set to
	0 by the sender and ignored by the receiver if the 'P' flag is		0 by the sender and MUST be ignored by the receiver if the 'P'
	set.		flag is set.
	Projected-Route 'P': 1-bit flag as defined in Section 4.1.6.		Projected-Route 'P': 1-bit flag as defined in Section 4.1.6.
	RPLInstanceID: See [RFC6553]. Indicates the TrackID if the 'P' flag		RPLInstanceID: See [RFC6553]. Indicates the TrackID if the 'P' flag
	is set, as discussed in Section 4.1.1.		is set, as discussed in Section 4.1.1.
	SenderRank: See [RFC6553]. This field MUST be set to 0 by the		SenderRank: See [RFC6553]. This field MUST be set to 0 by the
	sender and ignored by the receiver if the 'P' flag is set.		sender and MUST be ignored by the receiver if the 'P' flag is set.
	4.3. Extending RPL RFC 8138		4.3. Extending RFC 8138
	The 6LoWPAN Routing Header specification [RFC8138] introduces a new		The 6LoWPAN Routing Header specification [RFC8138] introduces a new
	6LoWPAN [RFC6282] dispatch type for use in 6LoWPAN route-over		6LoWPAN [RFC6282] dispatch type for use in 6LoWPAN route-over
	topologies, which initially covers the needs of RPL data packet		topologies, which initially covers the needs of RPL data packet
	compression.		compression.
	Section 4 of [RFC8138] presents the generic formats of the 6LoRH in		Section 4 of [RFC8138] presents the generic formats of the 6LoRH in
	two forms: Elective, which can be ignored and skipped when the router		two forms: Elective, which can be ignored and skipped when the router
	does not understand it, and Critical, which causes the packet to be		does not understand it, and Critical, which causes the packet to be
	dropped when the router cannot process it. The 'E' flag in the 6LoRH		dropped when the router cannot process it. The 'E' flag in the 6LoRH
	indicates its form. In order to skip the Elective 6LoRHs, their		indicates its form. In order to skip the Elective 6LoRHs, their
	format imposes a fixed expression of the size, whereas the size of a		format imposes a fixed expression of the size, whereas the size of a
	Critical 6LoRH may be signaled in variable forms to enable additional		Critical 6LoRH may be signaled in variable forms to enable additional
	optimizations.		optimizations.
	When compression as described in [RFC8138] is used, the Root of the		When compression as described in [RFC8138] is used, the Root of the
	main DODAG that sets up the Track also constructs the compressed		main DODAG that sets up the Track also constructs the compressed
	routing header (SRH-6LoRH) on behalf of the Track Ingress, which		Routing Header (SRH-6LoRH) on behalf of the Track ingress, which
	avoids the complexities of optimizing SRH-6LoRH encoding in		avoids the complexities of optimizing SRH-6LoRH encoding in
	constrained code. The SRH-6LoRH is signaled in the NSM-VIO, in a		constrained code. In that case, the SRH-6LoRH is signaled in the
	fashion that it is ready to be placed as is in the packet		NSM-VIO, and it is expressed in a fashion that can be placed as is in
	encapsulation by the Track Ingress.		the packet encapsulation by the Track ingress.
	Section 6.3 of [RFC8138] presents the formats of the 6LoWPAN RH of		Section 6.3 of [RFC8138] presents the formats of the 6LoWPAN RH of
	type 5 (RPI-6LoRH) that compresses the RPI for normal RPL operation.		type 5 (RPI-6LoRH) that compresses the RPI for normal RPL operation.
	The format of the RPI-6LoRH is not suited for P-Routes since the O,		The format of the RPI-6LoRH is not suited for P-Routes since the 'O',
	R, and F flags are not used and the Rank is unknown and ignored.		'R', and 'F' flags are not used and the Rank is unknown and ignored.
	This specification Extends [RFC8138] to introduce a new 6LoRH, the P-		This specification Extends [RFC8138] to introduce a new 6LoRH, the P-
	RPI-6LoRH, that can be used in either Elective or Critical 6LoRH		RPI-6LoRH, that can be used in either Elective or Critical 6LoRH
	form; see Tables 22 and 23, respectively. The new 6LoRH MUST be used		form; see Tables 22 and 23, respectively. The new 6LoRH MUST be used
	as a Critical 6LoRH, unless an SRH-6LoRH is present and controls the		as a Critical 6LoRH, unless an SRH-6LoRH is present and controls the
	routing decision, in which case it MAY be used in Elective form.		routing decision, in which case it MAY be used in Elective form.
	The P-RPI-6LoRH is designed to compress the RPI along RPL P-Routes.		The P-RPI-6LoRH is designed to compress the RPI along RPL P-Routes.
	Its format is as follows:		Its format is as follows:
	skipping to change at line 2256 ¶		skipping to change at line 2266 ¶
	6LoRH Type: IANA has defined the value 8 for both the Elective and		6LoRH Type: IANA has defined the value 8 for both the Elective and
	Critical forms.		Critical forms.
	Elective 'E': See [RFC8138]. The 'E' flag is set to 1 to indicate		Elective 'E': See [RFC8138]. The 'E' flag is set to 1 to indicate
	an Elective 6LoRH, meaning that it can be ignored when forwarding.		an Elective 6LoRH, meaning that it can be ignored when forwarding.
	RPLInstanceID : In the context of this specification, the		RPLInstanceID : In the context of this specification, the
	RPLInstanceID field signals the TrackID; see Sections 3.4 and 6.3.		RPLInstanceID field signals the TrackID; see Sections 3.4 and 6.3.
	Section 6.8 details how a Track Ingress leverages the P-RPI-6LoRH		Section 6.8 details how a Track ingress leverages the P-RPI-6LoRH
	Header as part of the encapsulation of a packet to place it into a		header as part of the encapsulation of a packet to place it into a
	Track.		Track.
	5. New RPL Control Messages and Options		5. New RPL Control Messages and Options
	5.1. New P-DAO Request Control Message		5.1. New P-DAO Request Control Message
	The PDR message is sent by a node in the main DODAG to the Root. It		The PDAOReq message is sent by a node in the main DODAG to the Root.
	is a request to establish or refresh a Track where the node sending		It is a request to establish or refresh a Track where the node
	the PDR is the Track Ingress, and it signals whether or not an		sending the PDAOReq is the Track ingress, and it signals whether or
	acknowledgment called PDR-ACK is requested. A positive PDR-ACK		not an acknowledgment called PDR-ACK is requested. A positive PDR-
	indicates that the Track was built and that the Root commits to		ACK indicates that the Track was built and that the Root commits to
	maintaining the Track for the negotiated lifetime.		maintaining the Track for the negotiated lifetime.
	The main Root MAY indicate to the Track Ingress that the Track was		The main Root MAY indicate to the Track ingress that the Track was
	terminated before its time; to do so, it MUST use an asynchronous		terminated before its time; to do so, it MUST use an asynchronous
	PDR-ACK with a negative status. A status of "Transient Failure" (see		PDR-ACK with a negative status. A status of "Transient Failure" (see
	Section 11.10) is an indication that the PDR may be retried after a		Section 11.10) is an indication that the PDAOReq may be retried after
	reasonable time that depends on the deployment. Other negative		a reasonable time that depends on the deployment. Other negative
	status values indicate a permanent error; the attempt must be		status values indicate a permanent error; the attempt must be
	abandoned until a corrective action is taken at the application layer		abandoned until a corrective action is taken at the application layer
	or through network management.		or through network management.
	The Track Ingress to be of the requested Track is indicated in the		The Track ingress to be of the requested Track is indicated in the
	source IPv6 address of the PDR, and the TrackID is indicated in the		source IPv6 address of the PDAOReq, and the TrackID is indicated in
	message itself. At least one RPL Target Option MUST be present in		the message itself. At least one RPL Target Option MUST be present
	the message. If more than one RPL Target Option is present, the Root		in the message. If more than one RPL Target Option is present, the
	will provide a Track that reaches the first listed Target and a		Root will provide a Track that reaches the first listed Target and a
	subset of the other Targets; the details of the subset selection are		subset of the other Targets; the details of the subset selection are
	out of scope. The RTO signals the Track Egress (see more in		out of scope. The RTO signals the Track egress (see more in
	Section 6.2).		Section 6.2).
	The RPL Control Code for the PDR is 0x09. The format of the PDR Base		The RPL Control Code for the PDAOReq is 0x09. The format of the
	Object is as follows:		PDAOReq Base Object is as follows:
	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
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| TrackID |K|R| Flags | ReqLifetime | PDRSequence |		| TrackID |K|R| Flags | ReqLifetime |PDAOReqSequence|
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| Option(s)...		| Option(s)...
	+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+
	Figure 13: New P-DAO Request Format		Figure 13: New P-DAO Request Format
	TrackID: 8-bit field. In the context of this specification, the		TrackID: 8-bit field. In the context of this specification, the
	TrackID field signals the RPLInstanceID of the DODAG formed by the		TrackID field signals the RPLInstanceID of the DODAG formed by the
	Track; see Sections 3.4 and 6.3. To allocate a new Track, the		Track; see Sections 3.4 and 6.3. To allocate a new Track, the
	Ingress Node must provide a value that is not in use at this time.		ingress Node must provide a value that is not in use at this time.
	K: The 'K' flag is set to indicate that the recipient is expected to		K: The 'K' flag is set to indicate that the recipient is expected to
	send a PDR-ACK back.		send a PDR-ACK back.
	R: The 'R' flag is set to request a Complex Track for redundancy.		R: The 'R' flag is set to request a Complex Track for redundancy.
	Flags: Reserved. The Flags field MUST be initialized to zero by the		Flags: Reserved. The Flags field MUST be initialized to zero by the
	sender and MUST be ignored by the receiver.		sender and MUST be ignored by the receiver.
	ReqLifetime: 8-bit unsigned integer. The requested lifetime for the		ReqLifetime: 8-bit unsigned integer. The requested lifetime for the
	Track expressed in Lifetime Units (obtained from the DODAG		Track expressed in Lifetime Units (obtained from the DODAG
	Configuration option). The value of 255 (0xFF) represents		Configuration option). The value of 255 (0xFF) represents
	infinity (never time out).		infinity (never time out).
	A PDR with a fresher PDRSequence refreshes the lifetime, and a		A PDAOReq with a fresher PDAOReqSequence refreshes the lifetime,
	PDRLifetime of 0 indicates that the Track MUST be destroyed, e.g.,		and a ReqLifetime of 0 indicates that the Track MUST be destroyed,
	when the application that requested the Track terminates.		e.g., when the application that requested the Track terminates.
	PDRSequence: 8-bit wrapping sequence number, obeying the operation		PDAOReqSequence: 8-bit wrapping sequence number, obeying the
	in Section 7.2 of [RPL]. The PDRSequence is used to correlate a		operation in Section 7.2 of [RPL]. The PDAOReqSequence is used to
	PDR-ACK message with the PDR message that triggered it. It is		correlate a PDR-ACK message with the PDAOReq message that
	incremented at each PDR message and echoed in the PDR-ACK by the		triggered it. It is incremented at each PDAOReq message and
	Root.		echoed in the PDR-ACK by the Root.
	5.2. New PDR-ACK Control Message		5.2. New PDR-ACK Control Message
	The new PDR-ACK is sent as a response to a PDR message with the 'K'		The new PDR-ACK is sent as a response to a PDAOReq message with the
	flag set. The RPL Control Code for the PDR-ACK is 0x0A. Its format		'K' flag set. The RPL Control Code for the PDR-ACK is 0x0A. Its
	is as follows:		format is as follows:
	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
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| TrackID | Flags | Track Lifetime| PDRSequence |		| TrackID | Flags | Track Lifetime|PDAOReqSequence|
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| PDR-ACK Status| Reserved |		| PDR-ACK Status| Reserved |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| Option(s)...		| Option(s)...
	+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+
	Figure 14: New PDR-ACK Control Message Format		Figure 14: New PDR-ACK Control Message Format
	TrackID: Set to the TrackID indicated in the TrackID field of the		TrackID: Set to the TrackID indicated in the TrackID field of the
	PDR messages that this replies to.		PDAOReq messages that this replies to.
	Flags: Reserved. The Flags field MUST be initialized to zero by the		Flags: Reserved. The Flags field MUST be initialized to zero by the
	sender and MUST be ignored by the receiver.		sender and MUST be ignored by the receiver.
	Track Lifetime: Indicates the remaining lifetime for the Track,		Track Lifetime: Indicates the remaining lifetime for the Track,
	expressed in Lifetime Units. The value of 255 (0xFF) represents		expressed in Lifetime Units. The value of 255 (0xFF) represents
	infinity. The value of zero (0x00) indicates that the Track was		infinity. The value of zero (0x00) indicates that the Track was
	destroyed or not created.		destroyed or not created.
	PDRSequence: 8-bit wrapping sequence number. It is incremented at		PDAOReqSequence: 8-bit wrapping sequence number. It is incremented
	each PDR message and echoed in the PDR-ACK.		at each PDAOReq message and echoed in the PDR-ACK.
	PDR-ACK Status: 8-bit field indicating the completion. The PDR-ACK		PDR-ACK Status: 8-bit field indicating the completion. The PDR-ACK
	Status is substructured as indicated in Figure 15:		Status is substructured as indicated in Figure 15:
	0 1 2 3 4 5 6 7		0 1 2 3 4 5 6 7
	+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+
	|E|R| Value |		|E|R| Value |
	+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+
	Figure 15: PDR-ACK Status Format		Figure 15: PDR-ACK Status Format
	E: 1-bit flag. Set to indicate a rejection. When not set, a		E: 1-bit flag. Set to indicate a rejection. When not set, a
	Value field that is set to 0 indicates Success/Unqualified		Value field that is set to 0 indicates Success/Unqualified
	Acceptance, and other values indicate "not an outright		Acceptance, and other values indicate "not an outright
	rejection".		rejection".
	R: 1-bit flag. Reserved; MUST be set to 0 by the sender and		R: 1-bit flag. Reserved; MUST be set to 0 by the sender and MUST
	ignored by the receiver.		be ignored by the receiver.
	Status Value: 6-bit unsigned integer. Values depend on the		Status Value: 6-bit unsigned integer. Values depend on the
	setting of the 'E' flag; see Tables 28 and 29.		setting of the 'E' flag; see Tables 28 and 29.
	Reserved: The Reserved field MUST be initialized to zero by the		Reserved: The Reserved field MUST be initialized to zero by the
	sender and MUST be ignored by the receiver.		sender and MUST be ignored by the receiver.
	5.3. Via Information Options		5.3. Via Information Options
	A VIO signals the ordered list of IPv6 Via Addresses that constitutes		A VIO signals the ordered list of IPv6 Via Addresses that constitutes
	skipping to change at line 2450 ¶		skipping to change at line 2460 ¶
	Option Type: 0x0F for SM-VIO and 0x10 for NSM-VIO (see Table 26).		Option Type: 0x0F for SM-VIO and 0x10 for NSM-VIO (see Table 26).
	Option Length: 8-bit unsigned integer, representing the length in		Option Length: 8-bit unsigned integer, representing the length in
	octets of the option, not including the Option Type and Length		octets of the option, not including the Option Type and Length
	fields (see Section 6.7.1 of [RPL]); the Option Length is		fields (see Section 6.7.1 of [RPL]); the Option Length is
	variable, depending on the number of Via Addresses and the		variable, depending on the number of Via Addresses and the
	compression applied.		compression applied.
	Flags: 8-bit field. No flag is defined in this specification. The		Flags: 8-bit field. No flag is defined in this specification. The
	field MUST be set to 0 by the sender and ignored by the receiver.		field MUST be set to 0 by the sender and MUST be ignored by the
			receiver.
	P-RouteID: 8-bit field that identifies a component of a Track or the		P-RouteID: 8-bit field that identifies a component of a Track or the
	main DODAG as indicated by the TrackID field. The value of 0 is		main DODAG as indicated by the TrackID field. The value of 0 is
	used to signal a path, i.e., made of a single segment/protection		used to signal a path, i.e., made of a single segment/protection
	path. In an SM-VIO, the P-RouteID indicates a Segment ID. In an		path. In an SM-VIO, the P-RouteID indicates a SegmentID. In an
	NSM-VIO, it indicates the ID of a protection path that is added		NSM-VIO, it indicates the ID of a protection path that is added
	(or updated) to the overall topology of the Track.		(or updated) to the overall topology of the Track.
	Segment Sequence: 8-bit unsigned integer. The Segment Sequence		Segment Sequence: 8-bit unsigned integer. The Segment Sequence
	obeys the operation in Section 7.2 of [RPL], and the initial value		obeys the operation in Section 7.2 of [RPL], and the initial value
	is 255.		is 255.
	When the Root of the DODAG needs to refresh or update a segment in		When the Root of the DODAG needs to refresh or update a segment in
	a Track, it increments the Segment Sequence individually for that		a Track, it increments the Segment Sequence individually for that
	segment.		segment.
	The segment information indicated in the VIO deprecates any state		The segment information indicated in the VIO deprecates any state
	for the segment indicated by the P-RouteID within the indicated		for the segment indicated by the P-RouteID within the indicated
	Track and sets up the new information.		Track and provides the new information about the segment.
	A VIO with a Segment Sequence that is not as fresh as the current		A VIO with a Segment Sequence that is not as fresh as the current
	one is ignored.		one is ignored.
	A VIO for a given DODAGID with the same (TrackID, P-RouteID,		A VIO for a given DODAGID with the same (TrackID, P-RouteID,
	Segment Sequence) indicates a retry; it MUST NOT change the		Segment Sequence) indicates a retry; it MUST NOT change the
	segment and MUST be propagated or answered as the first copy.		segment and MUST be propagated or answered as the first copy.
	Segment Lifetime: 8-bit unsigned integer. The length of time in		Segment Lifetime: 8-bit unsigned integer. The length of time in
	Lifetime Units (obtained from the Configuration option) that the		Lifetime Units (obtained from the Configuration option) that the
	segment is usable.		segment is usable.
	The period starts when a new Segment Sequence is seen. The value		The period starts when a new Segment Sequence is seen. The value
	of 255 (0xFF) represents infinity. The value of zero (0x00)		of 255 (0xFF) represents infinity. The value of zero (0x00)
	indicates a loss of reachability.		indicates a loss of reachability.
	SRH-6LoRH head: The first 2 bytes of the (first) SRH-6LoRH as shown		SRH-6LoRH head: The first 2 bytes of the (first) SRH-6LoRH as shown
	in Figure 6 of [RFC8138]. As an example, a 6LoRH Type of 4 means		in Figure 6 of [RFC8138]. As an example, a 6LoRH of type 4 means
	that the Via Addresses are provided in full with no compression.		that the Via Addresses are provided in full with no compression.
	Via Address: An IPv6 ULA or GUA of a node along the segment. The		Via Address: An IPv6 ULA or GUA of a node along the segment. The
	VIO contains one or more IPv6 Via Addresses listed in the datapath		VIO contains one or more IPv6 Via Addresses listed in the datapath
	order from Ingress to Egress. The list is expressed in a		order from ingress to egress. The list is expressed in a
	compressed form as signaled by the preceding SRH-6LoRH header.		compressed form as signaled by the preceding SRH-6LoRH header.
	In a Storing Mode P-DAO that updates or removes a section of an		In a Storing Mode P-DAO that updates or removes a section of an
	already existing segment, the list in the SM-VIO may represent		already existing segment, the list in the SM-VIO may represent
	only the section of the segment that is being updated; at the		only the section of the segment that is being updated; at the
	extreme, the SM-VIO updates only one node, in which case it		extreme, the SM-VIO updates only one node, in which case it
	contains only one IPv6 address. In all other cases, the list in		contains only one IPv6 address. In all other cases, the list in
	the VIO MUST be complete.		the VIO MUST be complete.
	In the case of an SM-VIO, the list indicates a sequential (strict)		In the case of an SM-VIO, the list indicates a sequential (strict)
	path through direct neighbors; the complete list starts at the		path through direct neighbors; the complete list starts at the
	Ingress and ends at the Egress, and the nodes listed in the VIO,		ingress and ends at the egress, and the nodes listed in the VIO,
	including the Egress, MAY be considered as implicit Targets.		including the egress, MAY be considered as implicit Targets.
	In the case of an NSM-VIO, the complete list can be loose and		In the case of an NSM-VIO, the complete list can be loose and
	excludes the Ingress node, starting at the first loose hop and		excludes the ingress node, starting at the first loose hop and
	ending at a Track Egress; the Track Egress MUST be considered as		ending at a Track egress; the Track egress MUST be considered as
	an implicit Target, so it MUST NOT be signaled in a RPL Target		an implicit Target, so it MUST NOT be signaled in a RPL Target
	Option.		Option.
	5.4. Sibling Information Option		5.4. Sibling Information Option
	The Sibling Information Option (SIO) provides information about		The Sibling Information Option (SIO) provides information about
	siblings that could be used by the Root to form P-Routes. One or		siblings that could be used by the Root to form P-Routes. One or
	more SIOs may be placed in the DAO messages that are sent to the Root		more SIOs may be placed in the DAO messages that are sent to the Root
	in Non-Storing Mode.		in Non-Storing Mode.
	To advertise a neighbor node, the router MUST have an active Address		To advertise a neighbor node, the router MUST have an active Address
	Registration from that sibling per [RFC8505] for an address (ULA or		Registration from that sibling per [RFC8505] for an address (ULA or
	GUA) that serves as an identifier for the node. If this router also		GUA) that serves as an identifier for the node. If this router also
	registers an address to that sibling, and the link has similar		registers an address to that sibling, and the link has similar
	properties in both directions, only the router with the lowest		properties in both directions, only the router with the lowest
	Interface ID in its registered address needs to report the SIO, with		Interface ID in its registered address needs to report the SIO, with
	the B flag set, and the Root will assume symmetry.		the 'B' flag set, and the Root will assume symmetry.
	The SIO carries a flag (B) that is set when similar performance can		The SIO carries a flag (B) that is set when similar performance can
	be expected in both directions, so the routing can consider that the		be expected in both directions; this flag indicates to the routing
	information provided for one direction is valid for both. If the SIO		that the information provided for one direction is valid for both.
	is effectively received from both sides, then the B flag MUST be		If the SIO is effectively received from both sides, then the 'B' flag
	ignored. The policy that describes the performance criteria and how		MUST be ignored. The policy that describes the performance criteria
	they are asserted is out of scope. In the absence of an external		and how they are asserted is out of scope. In the absence of an
	protocol to assert the link quality, the flag SHOULD NOT be set.		external protocol to assert the link quality, the flag SHOULD NOT be
			set.
	The format of the SIO is as follows:		The format of the SIO is as follows:
	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
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| Type | Option Length |S|B|Flags|Comp.| Opaque |		| Option Type | Option Length |S|B|Flags|Comp.| Opaque |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| Step in Rank | Reserved |		| Step in Rank | Reserved |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| |		| |
	+ +		+ +
	. .		. .
	. Sibling DODAGID (if the D flag is not set) .		. Sibling DODAGID (if the D flag is not set) .
	. .		. .
	+ +		+ +
	| |		| |
	skipping to change at line 2611 ¶		skipping to change at line 2623 ¶
	[RPL] as computed by the Objective Function between this node and		[RPL] as computed by the Objective Function between this node and
	the sibling, which reflects the abstract Rank increment that would		the sibling, which reflects the abstract Rank increment that would
	be computed by the Objective Function if the sibling was the		be computed by the Objective Function if the sibling was the
	preferred parent.		preferred parent.
	Reserved: The Reserved field MUST be initialized to zero by the		Reserved: The Reserved field MUST be initialized to zero by the
	sender and MUST be ignored by the receiver		sender and MUST be ignored by the receiver
	Sibling DODAGID: 2 to 16 bytes. The DODAGID of the sibling in a		Sibling DODAGID: 2 to 16 bytes. The DODAGID of the sibling in a
	compressed form [RFC8138] as indicated by the Compression Type		compressed form [RFC8138] as indicated by the Compression Type
	field. This field is present if and only if the D flag is not		field. This field is present if and only if the 'D' flag is not
	set.		set.
	Sibling Address: 2 to 16 bytes. An IPv6 address of the sibling with		Sibling Address: 2 to 16 bytes. An IPv6 address of the sibling with
	a scope that MUST make it reachable from the Root, e.g., it cannot		a scope that MUST make it reachable from the Root, e.g., it cannot
	be a Link Local Address. The IPv6 address is encoded in the		be a Link Local Address. The IPv6 address is encoded in the
	compressed form [RFC8138] indicated by the Compression Type field.		compressed form [RFC8138] indicated by the Compression Type field.
	An SIO MAY be immediately followed by a DAG Metric Container. In		An SIO MAY be immediately followed by a DAG Metric Container. In
	that case, the DAG Metric Container provides additional metrics for		that case, the DAG Metric Container provides additional metrics for
	the hop from the Sibling to this node.		the hop from the Sibling to this node.
	skipping to change at line 2642 ¶		skipping to change at line 2654 ¶
	defined for the RPL domain.		defined for the RPL domain.
	Though fragmentation is possible in a 6LoWPAN LLN, e.g., using		Though fragmentation is possible in a 6LoWPAN LLN, e.g., using
	[6LoWPAN], [RFC8930], and/or [RFC8931], it is RECOMMENDED to define		[6LoWPAN], [RFC8930], and/or [RFC8931], it is RECOMMENDED to define
	an MTU that is larger than 1280 between the RPL routers that form the		an MTU that is larger than 1280 between the RPL routers that form the
	main DODAG to allow for the necessary header additions, while still		main DODAG to allow for the necessary header additions, while still
	exposing 1280 to the 6LoWPAN endpoint stacks.		exposing 1280 to the 6LoWPAN endpoint stacks.
	6.2. Requesting a Track		6.2. Requesting a Track
	This specification introduces the PDR message, which is used by an		This specification introduces the PDAOReq message, which is used by
	LLN node to request the formation of a new Track for which the LLN		an LLN node to request the formation of a new Track for which the LLN
	node is the Ingress. Note that the namespace for the TrackID is		node is the ingress. Note that the namespace for the TrackID is
	owned by the Ingress node, and in the absence of a PDR, there must be		owned by the ingress node, and in the absence of a PDAOReq, there
	some procedure for the Root to assign TrackIDs in that namespace		must be some procedure for the Root to assign TrackIDs in that
	while avoiding collisions (see more in Section 6.3).		namespace while avoiding collisions (see more in Section 6.3).
	The PDR signals the desired TrackID and the duration for which the		The PDAOReq signals the desired TrackID and the duration for which
	Track should be established. Upon a PDR, the Root MAY install the		the Track should be established. Upon a PDAOReq, the Root MAY
	Track as requested, in which case it answers with a PDR-ACK		install the Track as requested, in which case it answers with a PDR-
	indicating the granted Track Lifetime. All the segments MUST be of		ACK indicating the granted Track Lifetime. All the segments MUST be
	the same mode, either Storing or Non-Storing. All the segments MUST		of the same mode, either Storing or Non-Storing. All the segments
	be created with the same TrackID and the same DODAGID signaled in the		MUST be created with the same TrackID and the same DODAGID signaled
	P-DAO.		in the P-DAO.
	The Root designs the Track as it sees fit and updates/changes the		The Root designs the Track as it sees fit and updates/changes the
	segments over time to serve the Track as needed. Note that there is		segments over time to serve the Track as needed. Note that there is
	no protocol element to notify the requesting Track Ingress when		no protocol element to notify the requesting Track ingress when
	changes happen deeper down the Track, so they are transparent to the		changes happen deeper down the Track, so they are transparent to the
	Track Ingress. If the main Root cannot maintain an expected service		Track ingress. If the main Root cannot maintain an expected service
	level, then it needs to tear down the Track completely. The Segment		level, then it needs to tear down the Track completely. The Segment
	Lifetime in the P-DAO messages does not need to be aligned to the		Lifetime in the P-DAO messages does not need to be aligned to the
	Requested Lifetime in the PDR or between P-DAO messages for different		Requested Lifetime in the PDAOReq or between P-DAO messages for
	segments. For example, the Root may use shorter lifetimes for the		different segments. For example, the Root may use shorter lifetimes
	segments and renew them or change them during the lifetime of the		for the segments and renew them or change them during the lifetime of
	Track. All the components (protection paths and segments) of a Track		the Track. All the components (protection paths and segments) of a
	MUST be destroyed (or have their lifetime elapsed) before the TrackID		Track MUST be destroyed (or have their lifetime elapsed) before the
	can be reused.		TrackID can be reused.
	When the Track Lifetime is relatively close to elapse -- meaning in		When the Track Lifetime is relatively close to elapse -- meaning in
	the order of the trip time from the node to the Root -- the		the order of the trip time from the node to the Root -- the
	requesting node SHOULD resend a PDR using the TrackID in the PDR-ACK		requesting node SHOULD resend a PDAOReq using the TrackID in the PDR-
	to extend the lifetime of the Track; otherwise, the Track will time		ACK to extend the lifetime of the Track; otherwise, the Track will
	out, and the Root will tear down the whole structure.		time out, and the Root will tear down the whole structure.
	If the Track fails and cannot be restored, the Root notifies the		If the Track fails and cannot be restored, the Root notifies the
	requesting node asynchronously with a PDR-ACK with a Track Lifetime		requesting node asynchronously with a PDR-ACK with a Track Lifetime
	of 0, indicating that the Track has failed, and a PDR-ACK Status,		of 0, indicating that the Track has failed, and a PDR-ACK Status,
	indicating the reason of the fault.		indicating the reason of the fault.
	6.3. Identifying a Track		6.3. Identifying a Track
	RPL defines the concept of an Instance to signal an individual		RPL defines the concept of an Instance to signal an individual
	routing topology, and multiple topologies can coexist in the same		routing topology, and multiple topologies can coexist in the same
	skipping to change at line 2711 ¶		skipping to change at line 2723 ¶
	When adding a P-Route to the RPL main DODAG, the main Root MUST		When adding a P-Route to the RPL main DODAG, the main Root MUST
	set the RPLInstanceID field of the P-DAO Base Object (see		set the RPLInstanceID field of the P-DAO Base Object (see
	Section 6.4.1 of [RPL]) to the RPLInstanceID of the main DODAG,		Section 6.4.1 of [RPL]) to the RPLInstanceID of the main DODAG,
	and it MUST NOT use the DODAGID field. A P-Route provides a		and it MUST NOT use the DODAGID field. A P-Route provides a
	longer match to the Target Address than the default route via the		longer match to the Target Address than the default route via the
	main Root, so it is preferred.		main Root, so it is preferred.
	* The main Root MAY also use P-DAO messages to install a Track as an		* The main Root MAY also use P-DAO messages to install a Track as an
	independent routing topology (say, Traffic Engineered) to achieve		independent routing topology (say, Traffic Engineered) to achieve
	particular routing characteristics from Ingress to Egress		particular routing characteristics from ingress to egress
	endpoints. To achieve this, the main Root MUST set up a Local RPL		endpoints. To achieve this, the main Root MUST set up a Local RPL
	Instance (see Section 5 of [RPL]), and the Local RPLInstanceID		Instance (see Section 5 of [RPL]), and the Local RPLInstanceID
	serves as the TrackID. The TrackID MUST be unique for the IPv6		serves as the TrackID. The TrackID MUST be unique for the IPv6
	ULA or GUA of the Track Ingress that serves as the DODAGID for the		ULA or GUA of the Track ingress that serves as the DODAGID for the
	Track.		Track.
	This way, a Track is uniquely identified by the tuple (DODAGID,		This way, a Track is uniquely identified by the tuple (DODAGID,
	TrackID) where the TrackID is always represented with the D flag		TrackID) where the TrackID is always represented with the 'D' flag
	set to 0 (see also Section 5.1 of [RPL]), indicating that when		set to 0 (see also Section 5.1 of [RPL]), indicating that when
	used in an RPI, the source address of the IPv6 packet signals the		used in an RPI, the source address of the IPv6 packet signals the
	DODAGID.		DODAGID.
	The P-DAO Base Object MUST indicate the tuple (DODAGID, TrackID)		The P-DAO Base Object MUST indicate the tuple (DODAGID, TrackID)
	that identifies the Track as shown in Figure 8, and the P-RouteID		that identifies the Track as shown in Figure 8, and the P-RouteID
	that identifies the P-Route MUST be signaled in the VIO as shown		that identifies the P-Route MUST be signaled in the VIO as shown
	in Figure 16.		in Figure 16.
	The Track Ingress is the Root of the DODAGID formed by the Local		The Track ingress is the Root of the DODAGID formed by the Local
	RPL Instance. It owns the namespace of its TrackIDs, so it can		RPL Instance. It owns the namespace of its TrackIDs, so it can
	pick any unused value to request a new Track with a PDR. In a		pick any unused value to request a new Track with a PDAOReq. In a
	particular deployment where PDRs are not used, a portion of the		particular deployment where PDAOReqs are not used, a portion of
	namespace can be administratively delegated to the main Root,		the namespace can be administratively delegated to the main Root,
	meaning that the main Root is authoritative for assigning the		meaning that the main Root is authoritative for assigning the
	TrackIDs for the Tracks it creates.		TrackIDs for the Tracks it creates.
	With this specification, the main Root is aware of all the active		With this specification, the main Root is aware of all the active
	Tracks, so it can also pick any unused value to form Tracks		Tracks, so it can also pick any unused value to form Tracks
	without a PDR. To avoid a collision of the main Root and the		without a PDAOReq. To avoid a collision of the main Root and the
	Track Ingress picking the same value at the same time, it is		Track ingress picking the same value at the same time, it is
	RECOMMENDED that the Track Ingress starts allocating the ID value		RECOMMENDED that the Track ingress starts allocating the ID value
	of the Local RPLInstanceID (see Section 5.1 of [RPL]) used as		of the Local RPLInstanceID (see Section 5.1 of [RPL]) used as
	TrackIDs with the value 0 incrementing, while the Root starts with		TrackIDs with the value 0 incrementing, while the Root starts with
	63 decrementing.		63 decrementing.
	6.4. Installing a Track		6.4. Installing a Track
	A path can be installed by a single P-Route that signals the sequence		A path can be installed by a single P-Route that signals the sequence
	of consecutive nodes either in Storing Mode as a single-segment Track		of consecutive nodes either in Storing Mode as a single-segment Track
	or in Non-Storing Mode as a single-protection-path Track. A single-		or in Non-Storing Mode as a single-protection-path Track. A single-
	protection-path Track can be installed as a loose Non-Storing Mode		protection-path Track can be installed as a loose Non-Storing Mode
	P-Route, in which case the next loose entry must recursively be		P-Route, in which case the next loose entry must recursively be
	reached over a path.		reached over a path.
	A Complex Track can be installed as a collection of P-Routes with the		A Complex Track can be installed as a collection of P-Routes with the
	same DODAGID and Track ID. The Ingress of a Non-Storing Mode P-Route		same DODAGID and TrackID. The ingress of a Non-Storing Mode P-Route
	is the owner and Root of the DODAGID. The Ingress of a Storing Mode		is the owner and Root of the DODAGID. The ingress of a Storing Mode
	P-Route must be either the owner of the DODAGID or a hop of a		P-Route must be either the owner of the DODAGID or a hop of a
	protection path of the same Track. In the latter case, the Targets		protection path of the same Track. In the latter case, the Targets
	of the P-Route must include the next hop of the protection path if		of the P-Route must include the next hop of the protection path if
	there is one to ensure forwarding continuity. In the case of a		there is one to ensure forwarding continuity. In the case of a
	Complex Track, each segment is maintained independently and		Complex Track, each segment is maintained independently and
	asynchronously by the Root, with its own lifetime that may be		asynchronously by the Root, with its own lifetime that may be
	shorter, the same, or longer than that of the Track.		shorter, the same, or longer than that of the Track.
	A route along a Track for which the TrackID is not the RPLInstanceID		A route along a Track for which the TrackID is not the RPLInstanceID
	of the main DODAG MUST be installed with a higher precedence than the		of the main DODAG MUST be installed with a higher precedence than the
	routes along the main DODAG, meaning that:		routes along the main DODAG, meaning that:
	* The longest match MUST be the prime comparison for routing.		* The longest match MUST be the prime comparison for routing.
	* For an equal-length match, the route along the Track MUST be		* For an equal-length match, the route along the Track MUST be
	preferred over the one along the main DODAG.		preferred over the one along the main DODAG.
	* There SHOULD NOT be two different Tracks leading to the same		* There SHOULD NOT be two different Tracks leading to the same
	Target from same Ingress node, unless there's a policy for		Target from same ingress node, unless there's a policy for
	selecting which packets use which Track; such a policy is out of		selecting which packets use which Track; such a policy is out of
	scope.		scope.
	* A packet that was routed along a Track MUST NOT be routed along		* A packet that was routed along a Track MUST NOT be routed along
	the main DODAG again; if the destination is not reachable as a		the main DODAG again; if the destination is not reachable as a
	neighbor by the node where the packet exits the Track, then the		neighbor by the node where the packet exits the Track, then the
	packet MUST be dropped.		packet MUST be dropped.
	6.4.1. Signaling a Projected Route		6.4.1. Signaling a Projected Route
	skipping to change at line 2810 ¶		skipping to change at line 2822 ¶
	A P-DAO message MUST be sent from the address of the Root that serves		A P-DAO message MUST be sent from the address of the Root that serves
	as the DODAGID for the main DODAG. It MUST contain either exactly		as the DODAGID for the main DODAG. It MUST contain either exactly
	one sequence of one or more RTOs followed by one VIO or any number of		one sequence of one or more RTOs followed by one VIO or any number of
	sequences of one or more RTOs followed by one or more TIOs. The		sequences of one or more RTOs followed by one or more TIOs. The
	former is the normal expression for this specification, whereas the		former is the normal expression for this specification, whereas the
	latter corresponds to the variation for less-constrained environments		latter corresponds to the variation for less-constrained environments
	described in Section 7.2.		described in Section 7.2.
	A P-DAO that creates or updates a protection path MUST be sent to a		A P-DAO that creates or updates a protection path MUST be sent to a
	GUA or a ULA of the Ingress of the protection path; it MUST contain		GUA or a ULA of the ingress of the protection path; it MUST contain
	the full list of hops in the protection path unless the protection		the full list of hops in the protection path unless the protection
	path is being removed. A P-DAO that creates a new Track segment MUST		path is being removed. A P-DAO that creates a new Track segment MUST
	be sent to a GUA or a ULA of the segment Egress and MUST signal the		be sent to a GUA or a ULA of the segment egress and MUST signal the
	full list of hops in a segment; a P-DAO that updates (including		full list of hops in a segment; a P-DAO that updates (including
	deletes) a section of a segment MUST be sent to the first node after		deletes) a section of a segment MUST be sent to the first node after
	the modified segment and signal the full list of hops in the section		the modified segment and MUST signal the full list of hops in the
	starting at the node that immediately precedes the modified section.		section starting at the node that immediately precedes the modified
			section.
	In Non-Storing Mode, as discussed in Section 6.4.3, the Root sends		In Non-Storing Mode, as discussed in Section 6.4.3, the Root sends
	the P-DAO to the Track Ingress where the source routing state is		the P-DAO to the Track ingress where the source routing state is
	applied, whereas in Storing Mode, the P-DAO is sent to the last node		applied, whereas in Storing Mode, the P-DAO is sent to the last node
	on the installed path and forwarded in the reverse direction,		on the installed path and forwarded in the reverse direction,
	installing a Storing Mode state at each hop, as discussed in		installing a Storing Mode state at each hop, as discussed in
	Section 6.4.2. In both cases, the Track Ingress is the owner of the		Section 6.4.2. In both cases, the Track ingress is the owner of the
	Track, and it generates the P-DAO-ACK when the installation is		Track, and it generates the P-DAO-ACK when the installation is
	successful.		successful.
	If the 'K' flag is present in the P-DAO, the P-DAO MUST be		If the 'K' flag is present in the P-DAO, the P-DAO MUST be
	acknowledged using a DAO-ACK that is sent back to the address of the		acknowledged using a P-DAO-ACK that is sent back to the address of
	Root from which the P-DAO was received. In most cases, the first		the Root from which the P-DAO was received. In most cases, the first
	node of the protection path, segment, or updated section of the		node of the protection path, segment, or updated section of the
	segment is the node that sends the acknowledgment. The exception to		segment is the node that sends the acknowledgment. The exception to
	the rule is when an intermediate node in a segment fails to forward a		the rule is when an intermediate node in a segment fails to forward a
	Storing Mode P-DAO to the previous node in the SM-VIO.		Storing Mode P-DAO to the previous node in the SM-VIO.
	In a No-Path Non-Storing Mode P-DAO, the SRH-6LoRH MUST NOT be		In a No-Path Non-Storing Mode P-DAO, the SRH-6LoRH MUST NOT be
	present in the NSM-VIO; the state in the Ingress is erased		present in the NSM-VIO; the state in the ingress is erased
	regardless. In all other cases, a VIO MUST contain at least one Via		regardless. In all other cases, a VIO MUST contain at least one Via
	Address, and a Via Address MUST NOT be present more than once, which		Address, and a Via Address MUST NOT be present more than once, which
	would create a loop.		would create a loop.
	A node that processes a VIO MAY verify whether any of these		A node that processes a VIO MAY verify whether any of these
	conditions happen, and when one does, it MUST ignore the P-DAO and		conditions happen, and when one does, it MUST ignore the P-DAO and
	reject it with a RPL Rejection Status of "Error in VIO" in the DAO-		reject it with a RPL rejection status of "Error in VIO" in the DAO-
	ACK; see Section 11.16.		ACK; see Section 11.16.
	Errors, other than those discussed explicitly, that prevent the		Errors, other than those discussed explicitly, that prevent the
	installation of the route are acknowledged with a RPL Rejection		installation of the route are acknowledged with a RPL rejection
	Status of "Unqualified Rejection" in the DAO-ACK.		status of "Unqualified Rejection" in the P-DAO-ACK.
	6.4.2. Installing a Track Segment with a Storing Mode P-Route		6.4.2. Installing a Track Segment with a Storing Mode P-Route
	As illustrated in Figure 18, a Storing Mode P-DAO installs a route		As illustrated in Figure 18, a Storing Mode P-DAO installs a route
	along the segment signaled by the SM-VIO towards the Targets		along the segment signaled by the SM-VIO towards the Targets
	indicated in the Target Options. The segment is to be included in a		indicated in the Target Options. The segment is to be included in a
	DODAG indicated by the P-DAO Base Object, which may be the one formed		DODAG indicated by the P-DAO Base Object, which may be the one formed
	by the main DODAG, or a Track associated with a Local RPL Instance.		by the main DODAG, or a Track associated with a Local RPL Instance.
	------+---------		------+---------
	skipping to change at line 2879 ¶		skipping to change at line 2892 ¶
	o o o o o \\ o o o | | DAO | Route .		o o o o o \\ o o o | | DAO | Route .
	o o o o \\ o o o o | ^ | .		o o o o \\ o o o o | ^ | .
	o o o o o Egress o o v | DAO v .		o o o o o Egress o o v | DAO v .
	o o LLN o o o |		o o LLN o o o |
	o o o o o Loose Source Route Path |		o o o o o Loose Source Route Path |
	o o o o v		o o o o v
	Figure 18: Projecting a Route		Figure 18: Projecting a Route
	In order to install the relevant routing state along the segment, the		In order to install the relevant routing state along the segment, the
	Root sends a unicast P-DAO message to the Track Egress router of the		Root sends a unicast P-DAO message to the Track egress router of the
	routing segment that is being installed. The P-DAO message contains		routing segment that is being installed. The P-DAO message contains
	an SM-VIO with a strict sequence of Via Addresses. The SM-VIO		an SM-VIO with a strict sequence of Via Addresses. The SM-VIO
	follows one or more RTOs indicating the Targets to which the Track		follows one or more RTOs indicating the Targets to which the Track
	leads. The SM-VIO contains a Segment Lifetime for which the state is		leads. The SM-VIO contains a Segment Lifetime for which the state is
	to be maintained.		to be maintained.
	The Root sends the P-DAO directly to the Egress node of the segment.		The Root sends the P-DAO directly to the egress node of the segment.
	In that P-DAO, the destination IP address matches the last Via		In that P-DAO, the destination IP address matches the last Via
	Address in the SM-VIO. This is how the Egress recognizes its role.		Address in the SM-VIO. This is how the egress recognizes its role.
	In a similar fashion, the segment Ingress node recognizes its role		In a similar fashion, the segment ingress node recognizes its role
	because it matches the first Via Address in the SM-VIO.		because it matches the first Via Address in the SM-VIO.
	The Egress node of the segment is the only node in the path that does		The egress node of the segment is the only node in the path that does
	not install a route in response to the P-DAO; it is expected to be		not install a route in response to the P-DAO; it is expected to be
	already able to route to the Target(s) based on its existing tables.		already able to route to the Target(s) based on its existing tables.
	If one of the Targets is not known, the node MUST answer to the Root		If one of the Targets is not known, the node MUST answer to the Root
	with a DAO-ACK listing the unreachable Target(s) in an RTO and a		with a P-DAO-ACK listing the unreachable Target(s) in an RTO and a
	rejection status of "Unreachable Target".		rejection status of "Unreachable Target".
	If the Egress node can reach all the Targets, it forwards the P-DAO		If the egress node can reach all the Targets, it forwards the P-DAO
	with unchanged content to its predecessor in the segment as indicated		with unchanged content to its predecessor in the segment as indicated
	in the list of VIOs, and the message is recursively propagated		in the list of VIOs, and the message is recursively propagated
	unchanged along the sequence of routers indicated in the P-DAO, but		unchanged along the sequence of routers indicated in the P-DAO, but
	in the reverse order, from Egress to Ingress.		in the reverse order, from egress to ingress.
	The address of the predecessor to be used as the destination of the		The address of the predecessor to be used as the destination of the
	propagated DAO message is found in the Via Address list at the		propagated DAO message is found in the Via Address list at the
	position preceding the one that contains the address of the		position preceding the one that contains the address of the
	propagating node, which is used as the source of the message.		propagating node, which is used as the source of the message.
	Upon receiving a propagated DAO, all except the Egress router MUST		Upon receiving a propagated DAO, all except the egress router MUST
	install a route towards the DAO Target(s) via their successor in the		install a route towards the DAO Target(s) via their successor in the
	SM-VIO. A router that cannot store the routes to all the Targets in		SM-VIO. A router that cannot store the routes to all the Targets in
	a P-DAO MUST reject the P-DAO by sending a DAO-ACK to the Root with a		a P-DAO MUST reject the P-DAO by sending a P-DAO-ACK to the Root with
	Rejection Status of "Out of Resources" as opposed to forwarding the		a rejection status of "Out of Resources" as opposed to forwarding the
	DAO to its predecessor in the list. The router MAY install		DAO to its predecessor in the list. The router MAY install
	additional routes towards the Via Addresses that appear in the SM-VIO		additional routes towards the Via Addresses that appear in the SM-VIO
	after its own address, if any, but in case of a conflict or a lack of		after its own address, if any, but in case of a conflict or a lack of
	resource, the route(s) to the Target(s) MUST be installed in		resource, the route(s) to the Target(s) MUST be installed in
	priority.		priority.
	If a router cannot reach its predecessor in the SM-VIO, the router		If a router cannot reach its predecessor in the SM-VIO, the router
	MUST send the DAO-ACK to the Root with a Rejection Status of		MUST send the P-DAO-ACK to the Root with a rejection status of
	"Predecessor Unreachable".		"Predecessor Unreachable".
	The process continues until the P-DAO is propagated to the Ingress		The process continues until the P-DAO is propagated to the ingress
	router of the segment, which answers with a DAO-ACK to the Root. The		router of the segment, which answers with a P-DAO-ACK to the Root.
	Root always expects a DAO-ACK, either from the Track Ingress with a		The Root always expects a P-DAO-ACK, either from the Track ingress
	positive status or from any node along the segment with a negative		with a positive status or from any node along the segment with a
	status. If the DAO-ACK is not received, the Root may retry the DAO		negative status. If the P-DAO-ACK is not received, the Root may
	with the same TID or tear down the route.		retry the DAO with the same TrackID or tear down the route.
	6.4.3. Installing a Protection Path with a Non-Storing Mode P-Route		6.4.3. Installing a Protection Path with a Non-Storing Mode P-Route
	As illustrated in Figure 19, a Non-Storing Mode P-DAO installs a		As illustrated in Figure 19, a Non-Storing Mode P-DAO installs a
	source-routed path within the Track indicated by the P-DAO Base		source-routed path within the Track indicated by the P-DAO Base
	Object towards the Targets indicated in the Target Options. The		Object towards the Targets indicated in the Target Options. The
	source-routed path requires a Source Routing Header, which implies an		source-routed path requires a Source Routing Header, which implies an
	IP-in-IP encapsulation is needed to add the SRH to an existing		IP-in-IP encapsulation is needed to add the SRH to an existing
	packet. It is sent to the Track Ingress, which creates a tunnel		packet. It is sent to the Track ingress, which creates a tunnel
	associated with the Track and connected routes over the tunnel to the		associated with the Track and connected routes over the tunnel to the
	Targets in the RTO. The tunnel encapsulation MUST incorporate a		Targets in the RTO. The tunnel encapsulation MUST incorporate a
	routing header via the list addresses listed in the VIO in the same		Routing Header via the list addresses listed in the VIO in the same
	order. The content of the NSM-VIO starting at the first SRH-6LoRH		order. The content of the NSM-VIO starting at the first SRH-6LoRH
	header MUST be used verbatim by the Track Ingress when it		header MUST be used verbatim by the Track ingress when it
	encapsulates a packet to forward it over the Track.		encapsulates a packet to forward it over the Track.
	------+---------		------+---------
	| Internet		| Internet
	|		|
	+-----+		+-----+
	| | Border Router		| | Border Router
	| | (RPL Root)		| | (RPL Root)
	+-----+ | P ^ ACK		+-----+ | P ^ ACK
	| Track | DAO |		| Track | DAO |
	o o o o Ingress X V | X		o o o o Ingress X V | X
	o o o o o o o X o X Source-		o o o o o o o X o X Source-
	o o o o o o o o X o o X Routed		o o o o o o o o X o o X Routed
	o o ° o o o o X o X Segment		o o o o o o o X o X Segment
	o o o o o o o o X Egress X		o o o o o o o o X Egress X
	o o o o o |		o o o o o |
	Target		Target
	o o LLN o o		o o LLN o o
	o o o o		o o o o
	Figure 19: Projecting a Non-Storing Route		Figure 19: Projecting a Non-Storing Route
	The next entry in the source-routed path must be either a neighbor of		The next entry in the source-routed path must be either a neighbor of
	the previous entry or reachable as a Target via another P-Route,		the previous entry or reachable as a Target via another P-Route,
	either Storing or Non-Storing, which implies that the nested P-Route		either Storing or Non-Storing, which implies that the nested P-Route
	has to be installed before the loose sequence is and that P-Routes		has to be installed before the loose sequence is and that P-Routes
	must be installed from the last to the first along the datapath. For		must be installed from the last to the first along the datapath. For
	instance, a segment of a Track must be installed before the		instance, a segment of a Track must be installed before the
	protection path(s) of the same Track that uses it, and stitched		protection path(s) of the same Track that uses it, and stitched
	segments must be installed in order from the last to the first to		segments must be installed in order from the last to the first to
	reach the Targets.		reach the Targets.
	If the next entry in the loose sequence is reachable over a Storing		If the next entry in the loose sequence is reachable over a Storing
	Mode P-Route, it MUST be the Target of a segment and the Ingress of a		Mode P-Route, it MUST be the Target of a segment and the ingress of a
	next segment, which are both already set up; the segments are		next segment, which are both already set up; the segments are
	associated with the same Track, which avoids needing an additional		associated with the same Track, which avoids needing an additional
	encapsulation. For instance, in Section 3.5.1.3, segments A==>B-to-C		encapsulation. For instance, in Section 3.5.1.3, segments A==>B-to-C
	and C==>D==>E-to-F must be installed with Storing Mode P-DAO messages		and C==>D==>E-to-F must be installed with Storing Mode P-DAO messages
	1 and 2 before the Track A-->C-->E-to-F that joins them can be		1 and 2 before the Track A-->C-->E-to-F that joins them can be
	installed with Non-Storing Mode P-DAO 3.		installed with Non-Storing Mode P-DAO 3.
	Conversely, if it is reachable over a Non-Storing Mode P-Route, the		Conversely, if it is reachable over a Non-Storing Mode P-Route, the
	next loose source-routed hop of the inner Track is a Target of a		next loose source-routed hop of the inner Track is a Target of a
	previously installed Track and the Ingress of a next Track, which		previously installed Track and the ingress of a next Track, which
	requires de- and re-encapsulation when switching the outer Tracks		requires de- and re-encapsulation when switching the outer Tracks
	that join the loose hops. This is exemplified in Section 3.5.2.3		that join the loose hops. This is exemplified in Section 3.5.2.3
	where Non-Storing Mode P-DAOs 1 and 2 install strict Tracks that Non-		where Non-Storing Mode P-DAOs 1 and 2 install strict Tracks that Non-
	Storing Mode P-DAO 3 joins as a super Track. In such a case, packets		Storing Mode P-DAO 3 joins as a super Track. In such a case, packets
	are subject to double IP-in-IP encapsulation.		are subject to double IP-in-IP encapsulation.
	6.5. Tearing Down a P-Route		6.5. Tearing Down a P-Route
	A P-DAO with a lifetime of 0 is interpreted as a No-Path DAO and		A P-DAO with a lifetime of 0 is interpreted as a No-Path DAO. Its
	results in cleaning up existing state as opposed to refreshing an		function is to clean up an existing state as opposed to refreshing it
	existing one or installing a new one. To tear down a Track, the Root		or installing a new one. To tear down a Track, the Root must tear
	must tear down all the Track segments and protection paths that		down all the Track segments and protection paths that compose it one
	compose it one by one.		by one.
	Since the protection path state of a Track is located only on the		Since the protection path state of a Track is located only on the
	Ingress Node, the Root cleans up the protection path by sending an		ingress Node, the Root cleans up the protection path by sending an
	NSM-VIO to the Ingress to indicate the TrackID and the P-RouteID of		NSM-VIO to the ingress to indicate the TrackID and the P-RouteID of
	the protection path being removed, a Segment Lifetime of 0, and a		the protection path being removed, a Segment Lifetime of 0, and a
	newer Segment Sequence. The SRH-6LoRH with Via Addresses in the NSM-		newer Segment Sequence. The SRH-6LoRH with Via Addresses in the NSM-
	VIO is not needed; it SHOULD NOT be placed in the message and MUST be		VIO is not needed; it SHOULD NOT be placed in the message and MUST be
	ignored by the receiver. Upon that NSM-VIO, the Ingress node removes		ignored by the receiver. Upon that NSM-VIO, the ingress node removes
	all state for that Track, if any, and replies positively anyway.		all state for that Track, if any, and replies positively anyway.
	The Root cleans up a section of a segment by sending an SM-VIO to the		The Root cleans up a section of a segment by sending an SM-VIO to the
	last node of the segment with an updated TrackID and P-RouteID, a		last node of the segment with an updated TrackID and P-RouteID, a
	Segment Lifetime of 0, and a newer Segment Sequence. The Via		Segment Lifetime of 0, and a newer Segment Sequence. The Via
	Addresses in the SM-VIO indicate the section of the segment being		Addresses in the SM-VIO indicate the section of the segment being
	modified, from the first to the last node that is impacted. This can		modified, from the first to the last node that is impacted. This can
	be the whole segment if it is totally removed or a sequence of one or		be the whole segment if it is totally removed or a sequence of one or
	more nodes that have been bypassed by a segment update.		more nodes that have been bypassed by a segment update.
	skipping to change at line 3045 ¶		skipping to change at line 3058 ¶
	to the operation itself. This is ensured by installing the new		to the operation itself. This is ensured by installing the new
	section from its last node to the first, so when an intermediate node		section from its last node to the first, so when an intermediate node
	installs a route along the new section, all the downstream nodes in		installs a route along the new section, all the downstream nodes in
	the section have already installed their own. The disabled section		the section have already installed their own. The disabled section
	is removed as well when the in-flight packets are forwarded along the		is removed as well when the in-flight packets are forwarded along the
	new section.		new section.
	6.6.1. Maintaining a Track Segment		6.6.1. Maintaining a Track Segment
	To modify a section of a segment between the first node and a second		To modify a section of a segment between the first node and a second
	downstream node (which can be the Ingress and Egress, respectively)		downstream node (which can be the ingress and egress, respectively)
	while retaining those nodes in the segment, the Root sends an SM-VIO		while retaining those nodes in the segment, the Root sends an SM-VIO
	to the second node indicating the sequence of nodes in the new		to the second node indicating the sequence of nodes in the new
	section of the segment. The SM-VIO indicates the TrackID and the		section of the segment. The SM-VIO indicates the TrackID and the
	P-RouteID of the segment being updated and a newer Segment Sequence.		P-RouteID of the segment being updated and a newer Segment Sequence.
	The P-DAO is propagated from the second to the first node, and on the		The P-DAO is propagated from the second to the first node, and on the
	way, it updates the state on the nodes that are common to the old and		way, it updates the state on the nodes that are common to the old and
	new section of the segment and creates a state in the new nodes.		new section of the segment and creates a state in the new nodes.
	When the state is updated in an intermediate node, that node might		When the state is updated in an intermediate node, that node might
	still receive packets that were in flight from the Ingress to self		still receive packets that were in flight from the ingress to self
	over the old section of the segment. Since the remainder of the		over the old section of the segment. Since the remainder of the
	segment is already updated, the packets are forwarded along the new		segment is already updated, the packets are forwarded along the new
	version of the segment from that node on.		version of the segment from that node on.
	After a reasonable amount of time, the Root tears down the remaining		After a reasonable amount of time, the Root tears down the remaining
	section(s) of the old segments as described in Section 6.5 to enable		section(s) of the old segments as described in Section 6.5 to enable
	the deprecated sections to drain their traffic.		the deprecated sections to drain their traffic.
	6.6.2. Maintaining a Protection Path		6.6.2. Maintaining a Protection Path
	This specification allows the Root to add protection paths to a Track		This specification allows the Root to add protection paths to a Track
	by sending a Non-Storing Mode P-DAO to the Ingress associated to the		by sending a Non-Storing Mode P-DAO to the ingress associated to the
	same TrackID and a new Segment ID. If the protection path is loose,		same TrackID and a new SegmentID. If the protection path is loose,
	then the segments that join the hops must be created first. It makes		then the segments that join the hops must be created first. It makes
	sense to add a new protection path before removing one that is		sense to add a new protection path before removing one that is
	becoming excessively lossy and switch to the new protection path		becoming excessively lossy and switch to the new protection path
	before removing the old. Dropping a Track before the new one is		before removing the old. Dropping a Track before the new one is
	installed would reroute the traffic via the root; this may increase		installed would reroute the traffic via the Root; this may increase
	the latency beyond acceptable thresholds and overload the network		the latency beyond acceptable thresholds and overload the network
	near the root. This may also cause loops in the case of stitched		near the Root. This may also cause loops in the case of stitched
	Tracks: The packets that cannot be injected in the second Track might		Tracks: The packets that cannot be injected in the second Track might
	be routed back and reinjected at the Ingress of the first Track.		be routed back and reinjected at the ingress of the first Track.
	It is also possible to update a protection path by sending a Non-		It is also possible to update a protection path by sending a Non-
	Storing Mode P-DAO to the Ingress with the same Segment ID, an		Storing Mode P-DAO to the ingress with the same SegmentID, an
	incremented Segment Sequence, and the new complete list of hops in		incremented Segment Sequence, and the new complete list of hops in
	the NSM-VIO. Updating a live protection path means changing one or		the NSM-VIO. Updating a live protection path means changing one or
	more of the intermediate loose hops, and it involves laying out new		more of the intermediate loose hops, and it involves laying out new
	segments from and to the new loose hops before the NSM-VIO is issued		segments from and to the new loose hops before the NSM-VIO is issued
	for the new protection path.		for the new protection path.
	Packets that are in flight over the old version of the protection		Packets that are in flight over the old version of the protection
	path still follow the old source route path over the old segments.		path still follow the old source route path over the old segments.
	After a reasonable time, the Root tears down those segments as		After a reasonable time, the Root tears down those segments as
	described in Section 6.5 to enable the deprecated segments to drain		described in Section 6.5 to enable the deprecated segments to drain
	their traffic.		their traffic.
	6.7. Encapsulating and Forwarding Along a Track		6.7. Encapsulating and Forwarding Along a Track
	When injecting a packet in a Track, the Ingress router must		When injecting a packet in a Track, the ingress router must
	encapsulate the packet using IP-in-IP to add the Source Routing		encapsulate the packet using IP-in-IP to add the Source Routing
	Header with the final destination set to the Track Egress.		Header with the final destination set to the Track egress.
	All properties of a Track's operations are inherited from the main		All properties of a Track's operations are inherited from the main
	Instance that is used to install the Track. For instance, the use of		Instance that is used to install the Track. For instance, the use of
	compression per [RFC8138] is determined by whether it is used in the		compression per [RFC8138] is determined by whether it is used in the
	RPL main DODAG, e.g., by setting the 'T' flag [RFC9035] in the RPL		RPL main DODAG, e.g., by setting the 'T' flag [RFC9035] in the RPL
	configuration option.		Configuration option.
	When the Track Ingress places a packet in a Track, it encapsulates it		When the Track ingress places a packet in a Track, it encapsulates it
	with an additional IPv6 header, a Routing Header, and an IPv6 Hop-by-		with an additional IPv6 header, a Routing Header, and an IPv6 Hop-by-
	Hop Option Header that contains the RPI as follows:		Hop Option Header that contains the RPI as follows:
	* In the uncompressed form, the source of the packet is the address		* In the uncompressed form, the source of the packet is the address
	that this router uses as the DODAGID for the Track, the		that this router uses as the DODAGID for the Track, the
	destination is the first Via Address in the NSM-VIO, and the RH is		destination is the first Via Address in the NSM-VIO, and the RH is
	an SRH [RFC6554] that contains the list of the remaining Via		an SRH [RFC6554] that contains the list of the remaining Via
	Addresses, ending with the Track Egress.		Addresses, ending with the Track egress.
	* To compress RPL artifacts in data packets as indicated in		* In a network where 6LoWPAN header compression [RFC6282] is in use,
	[RFC8138], the preferred alternative in a network where 6LoWPAN		it is preferred to implement "IPv6 over Low-Power Wireless
	header compression [RFC6282] is used is to implement "IPv6 over		Personal Area Network (6LoWPAN) Paging Dispatch" [RFC8025] and
	Low-Power Wireless Personal Area Network (6LoWPAN) Paging		compress the RPL artifacts as indicated in [RFC8138].
	Dispatch" [RFC8025].
	In that case, the source-routed header is the exact copy of the		In that case, the RPL Source Route Header is the exact copy of the
	(chain of) SRH-6LoRH found in the NSM-VIO, also ending with the		(chain of) SRH-6LoRH found in the NSM-VIO, also ending with the
	Track Egress. The RPI-6LoRH is appended next, followed by an IP-		Track egress. The RPI-6LoRH is appended next, followed by an IP-
	in-IP 6LoRH Header that indicates the Ingress router in the		in-IP 6LoRH header that indicates the ingress router in the
	Encapsulator Address field; see a similar case in Figure 20 of		Encapsulator Address field; see a similar case in Figure 20 of
	[RFC8138].		[RFC8138].
	To signal the Track in the packet, this specification leverages the		To signal the Track in the packet, this specification leverages the
	RPL Forwarding model as follows:		RPL forwarding model as follows:
	* In the data packets, the Track DODAGID and the TrackID MUST be		* In the data packets, the Track DODAGID and the TrackID MUST be
	respectively signaled as the IPv6 source address, and the		respectively signaled as the IPv6 source address, and the
	RPLInstanceID field of the RPI MUST be placed in the outer chain		RPLInstanceID field of the RPI MUST be placed in the outer chain
	of IPv6 headers.		of IPv6 headers.
	The RPI carries a Local RPLInstanceID called the TrackID, which,		The RPI carries a Local RPLInstanceID called the TrackID, which,
	in association with the DODAGID, indicates the Track along which		in association with the DODAGID, indicates the Track along which
	the packet is forwarded.		the packet is forwarded.
	The D flag in the RPLInstanceID MUST be set to 0 to indicate that		The 'D' flag in the RPLInstanceID MUST be set to 0 to indicate
	the source address in the IPv6 header is set to the DODAGID (see		that the source address in the IPv6 header is set to the DODAGID
	more in Section 6.3).		(see more in Section 6.3).
	* This specification conforms to the principles of [RFC9008] with		* This specification conforms to the principles of [RFC9008] with
	regard to packet forwarding and encapsulation along a Track as		regard to packet forwarding and encapsulation along a Track as
	follows:		follows:
	- With this specification, the Track is a RPL DODAG. From the		- With this specification, the Track is a RPL DODAG. From the
	perspective of that DODAG, the Track Ingress is the Root, the		perspective of that DODAG, the Track ingress is the Root, the
	Track Egress is a RPL-Aware 6LR, and neighbors of the Track		Track egress is a RPL-Aware 6LR, and neighbors of the Track
	Egress that can be reached via the Track, but are external to		egress that can be reached via the Track, but are external to
	it, are external destinations and treated as RPL-Unaware Leaves		it, are external destinations and treated as RPL-Unaware Leaves
	(RULs). The encapsulation rules in [RFC9008] apply.		(RULs). The encapsulation rules in [RFC9008] apply.
	- If the Track Ingress is the originator of the packet and the		- If the Track ingress is the originator of the packet and the
	Track Egress is the destination of the packet, there is no need		Track egress is the destination of the packet, there is no need
	for an encapsulation.		for an encapsulation.
	- Thus, the Track Ingress must encapsulate the traffic that it		- Thus, the Track ingress must encapsulate the traffic that it
	did not originate, and it must include an RPI in the		did not originate, and it must include an RPI in the
	encapsulation to signal the TrackID.		encapsulation to signal the TrackID.
	A packet that is being routed over the RPL Instance associated to		A packet that is being routed over the RPL Instance associated to
	a first Non-Storing Mode Track MAY be placed recursively in a		a first Non-Storing Mode Track MAY be placed recursively in a
	second Track to cover one loose hop of the first Track, as		second Track to cover one loose hop of the first Track, as
	discussed in more detail in Section 3.5.2.3. On the other hand, a		discussed in more detail in Section 3.5.2.3. On the other hand, a
	Storing Mode segment must be strict, and a packet that it placed		Storing Mode segment must be strict, and a packet that it placed
	in a Storing Mode segment MUST follow that segment till the		in a Storing Mode segment MUST follow that segment till the
	segment Egress.		segment egress.
	It is known that a packet is forwarded along a Track by the source		It is known that a packet is forwarded along a Track by the source
	address and the RPI in the encapsulation. The Track ID is used to		address and the RPI in the encapsulation. The TrackID is used to
	identify the RIB entries associated to that Track, which, in		identify the RIB entries associated to that Track, which, in
	intermediate nodes, correspond to the P-Routes for the segments of		intermediate nodes, correspond to the P-Routes for the segments of
	the Track that the forwarding router is aware of. The packet		the Track that the forwarding router is aware of. Packet processing
	processing uses a precedence that favors self-delivery or routing		uses the following precedence: 1) self-delivery or Routing Header
	header handling when one is present, then delivery to direct		handling when one is present, 2) delivery to direct neighbors, 3)
	neighbors, then to indirect neighbors, then routing along a segment		delivery to indirect neighbors, 4) routing along a segment along the
	along the Track, and finally as a last resort injecting the packet in		Track, and 5) injecting the packet in another Track, as a last
	another Track.		resort.
	To achieve this, the packet handling logic MUST happen in the		To achieve this, the packet handling logic MUST happen in the
	following order:		following order:
	* If the destination of the packet is self:		* If the destination of the packet is self:
	1. If the header chain contains a RPL Source Route Header that is		1. If the header chain contains a RPL Source Route Header that is
	not fully consumed, then the packet is forwarded along the		not fully consumed, then the packet is forwarded along the
	Track as prescribed by [RFC6554], meaning that the next entry		Track as prescribed by [RFC6554], meaning that the next entry
	in the routing header becomes the destination.		in the Routing Header becomes the destination.
	2. Otherwise, if the packet was encapsulated, then the packet is		2. Otherwise, if the packet was encapsulated, then the packet is
	decapsulated and the forwarding process recurses; else, the		decapsulated and the forwarding process recurses; else, the
	packet is delivered to the stack.		packet is delivered to the stack.
	* Otherwise, the packet is forwarded as follows:		* Otherwise, the packet is forwarded as follows:
	1. If the destination of the packet is a direct neighbor, e.g.,		1. If the destination of the packet is a direct neighbor, e.g.,
	installed by IPv6 Neighbor Discovery, then the packet MUST be		installed by IPv6 Neighbor Discovery, then the packet MUST be
	forwarded to that neighbor.		forwarded to that neighbor.
	skipping to change at line 3224 ¶		skipping to change at line 3236 ¶
	as the target), then the packet is encapsulated to be		as the target), then the packet is encapsulated to be
	forwarded along that Track and the forwarding process		forwarded along that Track and the forwarding process
	recurses; otherwise, the packet is dropped.		recurses; otherwise, the packet is dropped.
	5. To avoid loops, and as opposed to packets that were not		5. To avoid loops, and as opposed to packets that were not
	encapsulated, a packet that was decapsulated from a Track MUST		encapsulated, a packet that was decapsulated from a Track MUST
	NOT be routed along the default route of the main DODAG; this		NOT be routed along the default route of the main DODAG; this
	would mean that the end-to-end path is uncontrolled. The node		would mean that the end-to-end path is uncontrolled. The node
	that discovers the fault MUST discard the packet.		that discovers the fault MUST discard the packet.
	The node that drops a packet for either of the reasons above MUST		The node that drops a packet in any of the steps above MUST send an
	send an ICMPv6 error message [RFC4443] to the Root, with the new code		ICMPv6 error message [RFC4443] to the Root, with a new code "Error in
	"Error in P-Route" (see Section 11.15). The Root can then repair by		P-Route" (see Section 11.15). The Root can then repair by updating
	updating the broken segment and/or Tracks, and in the case of a		the broken segment and/or Tracks. In the case of a broken segment,
	broken segment, remove the leftover sections of the segment using SM-		the Root removes the leftover sections of the segment using SM-VIOs
	VIOs with a lifetime of 0 indicating the section to one or more nodes		with a lifetime of 0, indicating the section where one or more nodes
	being removed (see Section 6.6).		are being removed (see Section 6.6).
	In case of a permanent forwarding error along a source route path,		In case of a permanent forwarding error along a source route path,
	the node that fails to forward SHOULD send an ICMP error with the		the node that fails to forward SHOULD send an ICMP error with the
	code "Error in Source Routing Header" back to the source of the		code "Error in Source Routing Header" back to the source of the
	packet, as described in Section 11.2.2.3 of [RPL]. Upon receiving		packet, as described in Section 11.2.2.3 of [RPL]. Upon receiving
	this message, the encapsulating node SHOULD stop using the source		this message, the encapsulating node SHOULD stop using the source
	route path for a reasonable period of time, which depends on the		route path for a reasonable period of time, which depends on the
	deployment, and it SHOULD send an ICMP message with the code "Error		deployment, and it SHOULD send an ICMP message with the code "Error
	in P-Route" to the Root. Failure to follow these steps may result in		in P-Route" to the Root. Failure to follow these steps may result in
	packet loss and wasted resources along the source route path that is		packet loss and wasted resources along the source route path that is
	skipping to change at line 3258 ¶		skipping to change at line 3270 ¶
	The portion of the invoking packet that is sent back in the ICMP		The portion of the invoking packet that is sent back in the ICMP
	message SHOULD record at least up to the RH if one is present, and		message SHOULD record at least up to the RH if one is present, and
	the hop of the RH SHOULD be consumed by this node so that the		the hop of the RH SHOULD be consumed by this node so that the
	destination in the IPv6 header is the next hop that this node could		destination in the IPv6 header is the next hop that this node could
	not reach. If a 6LoRH [RFC8138] is used to carry the IPv6 routing		not reach. If a 6LoRH [RFC8138] is used to carry the IPv6 routing
	information in the outer header, then the whole 6LoRH information		information in the outer header, then the whole 6LoRH information
	SHOULD be present in the ICMP message.		SHOULD be present in the ICMP message.
	6.8. Compression of RPL Artifacts		6.8. Compression of RPL Artifacts
	When using [RFC8138] in the main DODAG operated in Non-Storing Mode		When the main DODAG in a 6LoWPAN LLN is operated in Non-Storing Mode
	in a 6LoWPAN LLN, a typical packet that circulates in the main DODAG		and the data packets are compressed using [RFC8138], a typical packet
	is formatted as shown in Figure 20, representing the case where an		that circulates in the main DODAG is formatted as shown in Figure 20,
	IP-in-IP encapsulation is needed (see Table 19 of [RFC9008]):		representing the case where an IP-in-IP encapsulation is needed (see
			Table 19 of [RFC9008]):
	+-+ ... -+- ... -+- ... -+-+- ... +-+-+-+ ... +-+-+ ... -+ ... +-...		+-+ ... -+- ... -+- ... -+-+- ... +-+-+-+ ... +-+-+ ... -+ ... +-...
	|11110001| SRH- | RPI- | IP-in-IP | NH=1 |11110CPP| UDP | UDP		|11110001| SRH- | RPI- | IP-in-IP | NH=1 |11110CPP| UDP | UDP
	| Page 1 | 6LoRH | 6LoRH | 6LoRH |LOWPAN_IPHC| UDP | hdr |Payld		| Page 1 | 6LoRH | 6LoRH | 6LoRH |LOWPAN_IPHC| UDP | hdr |Payld
	+-+ ... -+- ... -+- ... -+-+- ... +-+-+-+ ... +-+-+ ... -+ ... +-...		+-+ ... -+- ... -+- ... -+-+- ... +-+-+-+ ... +-+-+ ... -+ ... +-...
	<= RFC 6282 =>		<= RFC 6282 =>
	<================ Inner packet ==================== = =		<================ Inner packet ==================== = =
	Figure 20: A Packet as Forwarded Along the Main DODAG		Figure 20: A Packet as Forwarded Along the Main DODAG
	Since there is no page switch between the encapsulated packet and the		Since there is no page switch between the encapsulated packet and the
	encapsulation, the first octet of the compressed packet that acts as		encapsulation, the first octet of the compressed packet that acts as
	the page selector is actually removed at encapsulation; therefore,		the page selector is actually removed at encapsulation; therefore,
	the inner packet used in the descriptions below starts with the SRH-		the inner packet used in the descriptions below starts with the SRH-
	6LoRH and is exactly the packet represented in Figure 20, from the		6LoRH and is exactly the packet represented in Figure 20, from the
	second octet onward.		second octet onward.
	When encapsulating the inner packet to place in the Track, the first		When encapsulating the inner packet to place in the Track, the first
	header that the Ingress appends at the head of the inner packet is an		header that the ingress appends at the head of the inner packet is an
	IP-in-IP 6LoRH Header; in that header, the encapsulator address,		IP-in-IP 6LoRH header; in that header, the encapsulator address,
	which maps to the IPv6 source address in the uncompressed form,		which maps to the IPv6 source address in the uncompressed form,
	contains a GUA or ULA IPv6 address of the Ingress node that serves as		contains a GUA or ULA IPv6 address of the ingress node that serves as
	the DODAGID for the Track, expressed in a compressed form using the		the DODAGID for the Track, expressed in a compressed form using the
	DODAGID of the main DODAG as a reference for the compression. If the		DODAGID of the main DODAG as a reference for the compression. If the
	address is compressed to 2 bytes, the resulting value for the Length		address is compressed to 2 bytes, the resulting value for the Length
	field (shown in Figure 21) is 3, meaning that the SRH-6LoRH as a		field (shown in Figure 21) is 3, meaning that the SRH-6LoRH as a
	whole is 5 octets long.		whole is 5 octets long.
	0 1 2		0 1 2
	0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 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
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- ... -+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- ... -+
	|1|0|1| Length | 6LoRH Type 6 | Hop Limit | Track DODAGID |		|1|0|1| Length | 6LoRH Type 6 | Hop Limit | Track DODAGID |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- ... -+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- ... -+
	Figure 21: The IP-in-IP 6LoRH Header		Figure 21: The IP-in-IP 6LoRH Header
	At the head of the resulting sequence of bytes, the Track Ingress		At the head of the resulting sequence of bytes, the Track ingress
	then adds the RPI that carries the TrackID as RPLInstanceID as a P-		then adds a P-RPI-6LoRH header to transport the RPI in its compressed
	RPI-6LoRH Header, as illustrated in Figure 12, using the TrackID as		form as illustrated in Figure 12. The RPI carries the TrackID as
	RPLInstanceID. Combined with the IP-in-IP 6LoRH Header, this allows		RPLInstanceID. Combined with the IP-in-IP 6LoRH header, this allows
	identifying the Track without ambiguity.		identifying the Track without ambiguity.
	The SRH-6LoRH is then added at the head of the resulting sequence of		The SRH-6LoRH is then added at the head of the resulting sequence of
	bytes as a verbatim copy of the content of the SM-VIO that signaled		bytes as a verbatim copy of the content of the SM-VIO that signaled
	the selected protection path.		the selected protection path.
	0 1		0 1
	0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 .. .. ..		0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 .. .. ..
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- -+- -+ ... +- -+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- -+- -+ ... +- -+
	|1|0|0| Size |6LoRH Type 0..4| Hop1 | Hop2 | | HopN |		|1|0|0| Size |6LoRH Type 0..4| Hop1 | Hop2 | | HopN |
	skipping to change at line 3355 ¶		skipping to change at line 3368 ¶
	* When the main DODAG is operated in Non-Storing Mode, P-Routes		* When the main DODAG is operated in Non-Storing Mode, P-Routes
	enable loose source routing, which is only an advantage in that		enable loose source routing, which is only an advantage in that
	mode. Storing Mode does not use Source Routing Headers and does		mode. Storing Mode does not use Source Routing Headers and does
	not derive the same benefits from this capability.		not derive the same benefits from this capability.
	On the other hand, since RPL is a Layer 3 routing protocol, its		On the other hand, since RPL is a Layer 3 routing protocol, its
	applicability extends beyond LLNs to a generic IP network. RPL		applicability extends beyond LLNs to a generic IP network. RPL
	requires fewer resources than alternative IGPs such as OSPF, IS-IS,		requires fewer resources than alternative IGPs such as OSPF, IS-IS,
	the Enhanced Interior Gateway Routing Protocol (EIGRP), BABEL, or RIP		the Enhanced Interior Gateway Routing Protocol (EIGRP), BABEL, or RIP
	at the expense of a route stretch versus the shortest path routes to		when using routing stretch rather than the shortest path routes to a
	a destination that those protocols compute. P-Routes add the		destination that those protocols compute. P-Routes add the
	capability to install the shortest and/or constrained routes to		capability to install the shortest and/or constrained routes to
	special destinations as discussed in Appendix A.9.4 of the ANIMA ACP		special destinations as discussed in Appendix A.9.4 of "An Autonomic
	[RFC8994].		Control Plane (ACP)" [RFC8994].
	In a powered and wired network, when enough memory to store the		In a powered and wired network, when enough memory to store the
	needed routes is available, the RPL Storing Mode proposes a better		needed routes is available, the RPL Storing Mode proposes a better
	trade-off than the Non-Storing Mode, as it reduces the route stretch		trade-off than the Non-Storing Mode, as it reduces the routing
	and lowers the load on the Root. In that case, the control path		stretch and lowers the load on the Root. In that case, the control
	between the Root and the RPL nodes can be maintained more		path between the Root and the RPL nodes can be maintained more
	aggressively and with more redundancy than in LLNs, and the nodes can		aggressively and with more redundancy than in LLNs, and the nodes can
	be reached to maintain the P-Routes at most times for a finer and		be reached to maintain the P-Routes at most times for a finer and
	more reactive control.		more reactive control.
	This section specifies the additions that are needed to support		This section specifies the additions that are needed to support
	P-Routes when the main DODAG is operated in Storing Mode. As long as		P-Routes when the main DODAG is operated in Storing Mode. As long as
	the RPI can be processed adequately by the data plane, the changes in		the RPI can be processed adequately by the data plane, the changes in
	this specification are limited to the DAO message. The Track		this specification are limited to the DAO message. The Track
	structure, routes, and forwarding operations remain the same. Since		structure, routes, and forwarding operations remain the same. Since
	there is no capability negotiation, the expectation is that all the		there is no capability negotiation, the expectation is that all the
	skipping to change at line 3413 ¶		skipping to change at line 3426 ¶
	[RFC9010]. Having similar values in all nodes allows factorizing		[RFC9010]. Having similar values in all nodes allows factorizing
	the TIO for multiple SIOs as done in [RPL].		the TIO for multiple SIOs as done in [RPL].
	* The TIO is followed by one or more SIOs that provide an address		* The TIO is followed by one or more SIOs that provide an address
	(ULA or GUA) of the advertised neighbor node.		(ULA or GUA) of the advertised neighbor node.
	However, the RPL routing information headers may not be supported on		However, the RPL routing information headers may not be supported on
	all types of routed network infrastructures, especially not in high-		all types of routed network infrastructures, especially not in high-
	speed routers. When the RPI is not supported in the data plane,		speed routers. When the RPI is not supported in the data plane,
	there cannot be Local RPL Instances and RPL can only operate as a		there cannot be Local RPL Instances and RPL can only operate as a
	single topology (the main DODAG). The RPL Instance is that of the		single topology (the main DODAG). The RPL Instance is the one that
	main DODAG, and the Ingress node that encapsulates is not the Root.		runs the main DODAG, and the ingress node that encapsulates the RPL
	The routes along the Tracks are alternate routes to those available		Instance is not the Root. The routes along the Tracks are alternate
	along the main DODAG. They MAY conflict with routes to children and		routes to those available along the main DODAG. They MAY conflict
	MUST take precedence in the routing table. The Targets MUST be		with routes to children and MUST take precedence in the routing
	adjacent to the Track Egress to avoid loops that may form if the		table. The Targets MUST be adjacent to the Track egress to avoid
	packet is reinjected in the main DODAG.		loops that may form if the packet is reinjected in the main DODAG.
	7.2. A Track as a Full DODAG		7.2. A Track as a Full DODAG
	This specification builds Tracks with parallel or interleaved		This specification builds Tracks with parallel or interleaved
	protection paths as opposed to a more complex DODAG with		protection paths as opposed to a more complex DODAG with
	interconnections at any place desirable. The reason for that		interconnections at any place desirable. The reason for that
	limitation is related to constrained node operations and the		limitation is related to constrained node operations and the
	capability to store a large amount of topological information and		capability to store a large amount of topological information and
	compute complex paths:		compute complex paths:
	skipping to change at line 3441 ¶		skipping to change at line 3454 ¶
	awareness and does not need to maintain dynamic information about		awareness and does not need to maintain dynamic information about
	the link quality and availability.		the link quality and availability.
	* The Root has complete topological information and statistical		* The Root has complete topological information and statistical
	metrics that allow it, or its PCE, to perform a global		metrics that allow it, or its PCE, to perform a global
	optimization of all Tracks in its DODAG. Based on that		optimization of all Tracks in its DODAG. Based on that
	information, the Root computes the protection path and produces		information, the Root computes the protection path and produces
	the source route paths.		the source route paths.
	* The node merely selects one of the proposed paths and applies the		* The node merely selects one of the proposed paths and applies the
	associated pre-computed routing header in the encapsulation. This		associated pre-computed Routing Header in the encapsulation. This
	alleviates both the complexity of computing a path and the		alleviates both the complexity of computing a path and the
	compressed form of the routing header.		compressed form of the Routing Header.
	The RAW architecture [RAW-ARCH] actually expects the PLR at the Track		The RAW architecture [RAW-ARCH] actually expects the PLR at the Track
	Ingress to react to changes in the forwarding conditions along the		ingress to react to changes in the forwarding conditions along the
	Track and reroute packets to maintain the required degree of		Track and reroute packets to maintain the required degree of
	reliability. To achieve this, the PLR needs the full richness of a		reliability. To achieve this, the PLR needs the full richness of a
	DODAG to form any path that could meet the SLO.		DODAG to form any path that could meet the SLO.
	This section specifies the additions that are needed to turn the		This section specifies the additions that are needed to turn the
	Track into a full DODAG and enable the main Root to provide the		Track into a full DODAG and enable the main Root to provide the
	necessary topological information to the Track Ingress. The		necessary topological information to the Track ingress. The
	expectation is that the metrics that the PLR uses are of an order		expectation is that the PLR's metrics will be in a different order
	other than that of the PCE, because of the difference of timescale		than the PCE's metrics because of the difference in the timescale
	between routing and forwarding; see more in [RAW-ARCH]. It follows		between routing and forwarding; see more in [RAW-ARCH]. It follows
	that the PLR will learn the metrics it needs from an alternate		that the PLR will learn the metrics it needs from an alternate
	source, e.g., OAM frames.		source, e.g., OAM frames.
	To pass the topological information to the Ingress, the Root uses a		To pass the topological information to the ingress, the Root uses a
	P-DAO message that contains sequences of Targets and TIOs that		P-DAO message that contains sequences of Targets and TIOs that
	collectively represent the Track, expressed in the same fashion as in		collectively represent the Track, expressed in the same fashion as in
	classical Non-Storing Mode. The difference is that the Root is the		classical Non-Storing Mode. The difference is that the Root is the
	source as opposed to the destination, and the Root can report		source as opposed to the destination, and the Root can report
	information on many Targets, possibly the full Track, with one P-DAO.		information on many Targets, possibly the full Track, with one P-DAO.
	Note that the Path Sequence and Lifetime in the TIO are selected by		Note that the Path Sequence and Lifetime in the TIO are selected by
	the Root and that the Target/Transit information tuples in the P-DAO		the Root and that the Target/Transit information tuples in the P-DAO
	are not those received by the Root in the DAO messages about the said		are not those received by the Root in the DAO messages about the said
	Targets. The Track may follow sibling routes and does not need to be		Targets. The Track may follow sibling routes and does not need to be
	congruent with the main DODAG.		congruent with the main DODAG.
	8. Profiles		8. Profiles
	This document provides a set of tools that may or may not be needed		This document provides a set of tools that may or may not be needed
	by an implementation depending on the type of application it serves.		by an implementation depending on the type of application it serves.
	This section describes profiles that can be implemented separately		This section describes profiles that can be implemented separately,
	and can be used to discriminate what an implementation can and cannot		e.g., using only a portion of this specification to meet a particular
	do. This section describes profiles that enable implementing only a		use case, and can be used to discriminate what an implementation can
	portion of this specification to meet a particular use case.		and cannot do.
	Profiles 0 to 2 operate in the main Instance and do not require the		Profiles 0 to 2 operate in the main Instance and do not require the
	support of Local RPL Instances or the indication of the RPL Instance		support of Local RPL Instances or the indication of the RPL Instance
	in the data plane. Profile 3 and above leverage Local RPL Instances		in the data plane. Profile 3 and above leverage Local RPL Instances
	to build arbitrary Tracks rooted at the Track Ingress and using its		to build arbitrary Tracks rooted at the Track ingress, using the
	namespace for the TrackID.		namespace of the Track ingress for the TrackID.
	Profiles 0 and 1 are REQUIRED by all implementations that may be used		Profiles 0 and 1 are REQUIRED by all implementations that may be used
	in LLNs; Profile 1 leverages Storing Mode to reduce the size of the		in LLNs; Profile 1 leverages Storing Mode to reduce the size of the
	Source Route Header in the most common LLN deployments. Profile 2 is		RPL Source Route Header in the most common LLN deployments. Profile
	RECOMMENDED in a high-speed or wired environment to enable Traffic		2 is RECOMMENDED in a high-speed (e.g., wired) environment to enable
	Engineering and network automation. All the other profile/		Traffic Engineering and network automation. All the other profile/
	environment combinations are OPTIONAL.		environment combinations are OPTIONAL.
	Profile 0:		Profile 0:
	Profile 0 is the legacy support of [RPL] Non-Storing Mode, with		Profile 0 is the legacy support of [RPL] Non-Storing Mode, with
	default routing Northwards (up) and strict source routing		default routing Northwards (up) and strict source routing
	Southwards (down the main DODAG). It provides the minimal common		Southwards (down the main DODAG). It provides the minimal common
	functionality that must be implemented as a prerequisite to all		functionality that must be implemented as a prerequisite to all
	the Track-supporting profiles. The other profiles extend Profile		the Track-supporting profiles. The other profiles extend Profile
	0 with selected capabilities that this specification introduces on		0 with selected capabilities that this specification introduces.
	top.
	Profile 1 (Storing Mode P-Route segments along the main DODAG):		Profile 1 (Storing Mode P-Route segments along the main DODAG):
	Profile 1 does not create new paths; compared to Profile 0, it		Profile 1 does not create new paths; compared to Profile 0, it
	combines Storing and Non-Storing Modes to balance the size of the		combines Storing and Non-Storing Modes to balance the size of the
	Routing Header in the packet and the amount of state in the		Routing Header in the packet and the amount of state in the
	intermediate routers in a Non-Storing Mode RPL DODAG.		intermediate routers in a Non-Storing Mode RPL DODAG.
	Profile 2 (Non-Storing Mode P-Route segments along the main		Profile 2 (Non-Storing Mode P-Route segments along the main
	DODAG):		DODAG):
	Profile 2 extends Profile 0 with strict source routing Non-Storing		Profile 2 extends Profile 0 with strict source-routed Non-Storing
	Mode P-Routes along the main DODAG, which is the same as Profile 1		Mode P-Routes along the main DODAG, which is the same as Profile 1
	but using NSM-VIOs as opposed to SM-VIOs. Profile 2 provides the		but using NSM-VIOs as opposed to SM-VIOs. Profile 2 provides the
	same capability to compress the SRH in packets down the main DODAG		same capability to compress the SRH in packets down the main DODAG
	as Profile 1, but it requires an encapsulation in order to insert		as Profile 1, but it requires an encapsulation in order to insert
	an additional SRH between the loose source routing hops. With		an additional SRH between the loose source routing hops. With
	Profile 2, the Tracks MUST be installed as subTracks of the main		Profile 2, the Tracks MUST be installed as subTracks of the main
	DODAG, and the main Instance MUST be used as the TrackID. Note		DODAG, and the main Instance MUST be used as the TrackID. Note
	that the Ingress node encapsulates but is not the Root, as it does		that the ingress node encapsulates but is not the Root, as it does
	not own the DODAGID.		not own the DODAGID.
	Profile 3:		Profile 3:
	In order to form the best path possible, this profile requires the		In order to form the best path possible, this profile requires the
	support of an SIO to inform the Root of additional possible hops.		support of an SIO to inform the Root of additional possible hops.
	Profile 3 extends Profile 1 with additional Storing Mode P-Routes		Profile 3 extends Profile 1 with additional Storing Mode P-Routes
	that install segments that do not follow the main DODAG. If the		that install segments that do not follow the main DODAG. If the
	segment Ingress (in the SM-VIO) is the same as the IPv6 address of		segment ingress (in the SM-VIO) is the same as the IPv6 address of
	the Track Ingress (in the Projected DAO Base Object), the P-DAO		the Track ingress (in the Projected DAO Base Object), the P-DAO
	creates an implicit Track between the segment Ingress and the		creates an implicit Track between the segment ingress and the
	segment Egress.		segment egress.
	Profile 4:		Profile 4:
	Profile 4 extends Profile 2 with strict source routing Non-Storing		Profile 4 extends Profile 2 with strict source-routed Non-Storing
	Mode P-Routes to form forward Tracks that are inside the main		Mode P-Routes to form forward Tracks that are inside the main
	DODAG but do not necessarily follow it. A Track is formed as one		DODAG but do not necessarily follow it. A Track is formed as one
	or more strict source-routed paths between the Root that is the		or more strict source-routed paths between the Root that is the
	Track Ingress and the Track Egress that is the last node.		Track ingress and the Track egress that is the last node.
	Profile 5:		Profile 5:
	Profile 5 combines Profile 4 with Profile 1 and enables loose		Profile 5 combines Profile 4 with Profile 1 and enables loose
	source routing between the Ingress and the Egress of the Track.		source routing between the ingress and the egress of the Track.
	As in Profile 1, Storing Mode P-Routes form the connections in the		As in Profile 1, Storing Mode P-Routes form the connections in the
	loose source route.		loose source route.
	Profile 6:		Profile 6:
	Profile 6 combines Profile 4 with Profile 2 and enables loose		Profile 6 combines Profile 4 with Profile 2 and enables loose
	source routing between the Ingress and the Egress of the Track.		source routing between the ingress and the egress of the Track.
	Profile 7:		Profile 7:
	Profile 7 implements Profile 5 in a main DODAG that is operated in		Profile 7 implements Profile 5 in a main DODAG that is operated in
	Storing Mode as presented in Section 7.1. As in Profiles 1 and 2,		Storing Mode as presented in Section 7.1. As in Profiles 1 and 2,
	the TrackID is the RPLInstanceID of the main DODAG. Longest match		the TrackID is the RPLInstanceID of the main DODAG. Longest match
	rules decide whether a packet is sent along the main DODAG or		rules decide whether a packet is sent along the main DODAG or
	rerouted in a Track.		rerouted in a Track.
	Profile 8:		Profile 8:
	Profile 8 is offered in preparation of the RAW work and for use		Profile 8 is offered in preparation of the RAW work and for use
	cases where an arbitrary node in the network can afford the same		cases where an arbitrary node in the network can afford the same
	code complexity as the RPL Root in a traditional deployment. It		code complexity as the RPL Root in a traditional deployment. It
	offers a full DODAG visibility to the Track Ingress, as specified		offers a full DODAG visibility to the Track ingress, as specified
	in Section 7.2, in a Non-Storing Mode main DODAG.		in Section 7.2, in a Non-Storing Mode main DODAG.
	Profile 9:		Profile 9:
	Profile 9 combines Profiles 7 and 8, operating the Track as a full		Profile 9 combines Profiles 7 and 8, operating the Track as a full
	DODAG within a Storing Mode main DODAG, using only the main DODAG		DODAG within a Storing Mode main DODAG, using only the main DODAG
	RPLInstanceID as the TrackID.		RPLInstanceID as the TrackID.
	9. Backwards Compatibility		9. Backwards Compatibility
	This specification can operate in a mixed network where some nodes		This specification can operate in a mixed network where some nodes
	support it and some do not. There are restrictions, though. All		support it and some do not. There are restrictions, though. All
	nodes that need to process a P-DAO MUST support this specification.		nodes that need to process a P-DAO MUST support this specification.
	As discussed in Section 3.7.1, how the root knows the node		As discussed in Section 3.7.1, how the Root knows the node
	capabilities and whether they support this specification are out of		capabilities and whether they support this specification are out of
	scope.		scope.
	This specification defines the 'D' flag in the RPL DODAG		This specification defines the 'D' flag in the RPL DODAG
	Configuration option (see Section 4.1.7) to signal that the RPL nodes		Configuration option (see Section 4.1.7) to signal that the RPL nodes
	can request the creation of Tracks. The requester may not know		can request the creation of Tracks. The requester may not know
	whether the Track can effectively be constructed or whether enough		whether the Track can effectively be constructed or whether enough
	nodes along the preferred paths support this specification.		nodes along the preferred paths support this specification.
	Therefore, it makes sense to only set the 'D' flags in the DIO when		Therefore, it makes sense to only set the 'D' flags in the DIO when
	the conditions for success are in place, in particular when all the		the conditions for success are in place, in particular when all the
	skipping to change at line 3612 ¶		skipping to change at line 3624 ¶
	In a general manner, the Security Considerations in [RPL] and		In a general manner, the Security Considerations in [RPL] and
	[RFC7416] apply to this specification as well. In particular, link-		[RFC7416] apply to this specification as well. In particular, link-
	layer security is needed to prevent denial-of-service attacks,		layer security is needed to prevent denial-of-service attacks,
	whereby a rogue router creates a high churn in the RPL network by		whereby a rogue router creates a high churn in the RPL network by
	constantly injecting forged P-DAO messages and using up all the		constantly injecting forged P-DAO messages and using up all the
	available storage in the attacked routers.		available storage in the attacked routers.
	When applied to radio LLNs such as IEEE Std 802.15.4, the lower-layer		When applied to radio LLNs such as IEEE Std 802.15.4, the lower-layer
	frame protection can be leveraged with an appropriate join protocol.		frame protection can be leveraged with an appropriate join protocol.
	6TiSCH defined [RFC9031] with the RPL Root acting as 6LBR. The join		The 6TiSCH Constrained Join Protocol (CoJP) [RFC9031] uses the RPL
	protocol could be extended to provide additional key material for		Root as 6LBR. The join protocol could be extended to provide
	pledges to 6LBR communication when additional end-to-end security is		additional key material for pledges to 6LBR communication when
	desired beyond the hop-by-hop security from the lower layer.		additional end-to-end security is desired beyond the hop-by-hop
			security from the lower layer.
	With this specification, the Root MAY generate P-DAO messages but		With this specification, the Root MAY generate P-DAO messages but
	other nodes MUST NOT do so. PDR messages MUST be sent to the Root.		other nodes MUST NOT do so. PDAOReq messages MUST be sent to the
	This specification expects that the communication with the Root is		Root. This specification expects that the communication with the
	authenticated but does not enforce which method is used.		Root is authenticated but does not enforce which method is used.
	Additionally, the trust model could include a role validation (e.g.,		Additionally, the trust model could include a role validation (e.g.,
	using a role-based authorization) to ensure that the node that claims		using a role-based authorization) to ensure that the node that claims
	to be a RPL Root is entitled to do so. That trust should propagate		to be a RPL Root is entitled to do so. That trust should propagate
	from Egress to Ingress in the case of a Storing Mode P-DAO.		from egress to ingress in the case of a Storing Mode P-DAO.
	This specification suggests some validation of the VIO to prevent		This specification suggests some validation of the VIO to prevent
	basic loops by avoiding that a node appears twice. But that is only		basic loops, i.e., by avoiding a node that appears twice. But that
	a minimal protection. Arguably, an attacker that can inject P-DAOs		is only a minimal protection. Arguably, an attacker that can inject
	can reroute any traffic and rapidly deplete critical resources such		P-DAOs can reroute any traffic and rapidly deplete critical resources
	as the spectrum and battery in the LLN.		such as the spectrum and battery in the LLN.
	11. IANA Considerations		11. IANA Considerations
	11.1. RPL DODAG Configuration Option Flag		11.1. RPL DODAG Configuration Option Flag
	IANA has assigned a flag in the "DODAG Configuration Option Flags for		IANA has assigned a flag in the "DODAG Configuration Option Flags for
	MOP 0..6" registry [RFC9008] under the "Routing Protocol for Low		MOP 0..6" registry [RFC9008] under the "Routing Protocol for Low
	Power and Lossy Networks (RPL)" registry group [IANA-RPL] as follows:		Power and Lossy Networks (RPL)" registry group [IANA-RPL] as follows:
	+============+==============================+===========+		+============+==============================+===========+
	skipping to change at line 3714 ¶		skipping to change at line 3727 ¶
	+------------+----------------------+-----------+		+------------+----------------------+-----------+
	| 1 | Rank-Error (R) | [RFC6553] |		| 1 | Rank-Error (R) | [RFC6553] |
	+------------+----------------------+-----------+		+------------+----------------------+-----------+
	| 2 | Forwarding-Error (F) | [RFC6553] |		| 2 | Forwarding-Error (F) | [RFC6553] |
	+------------+----------------------+-----------+		+------------+----------------------+-----------+
	| 3 | Projected-Route (P) | RFC 9914 |		| 3 | Projected-Route (P) | RFC 9914 |
	+------------+----------------------+-----------+		+------------+----------------------+-----------+
	| 4..255 | Unassigned | |		| 4..255 | Unassigned | |
	+------------+----------------------+-----------+		+------------+----------------------+-----------+
	Table 24: Initial PDR Flags		Table 24: Initial PDAOReq Flags
	11.5. RPL Control Codes		11.5. RPL Control Codes
	IANA has updated the "RPL Control Codes" registry under the "Routing		IANA has updated the "RPL Control Codes" registry under the "Routing
	Protocol for Low Power and Lossy Networks (RPL)" registry group		Protocol for Low Power and Lossy Networks (RPL)" registry group
	[IANA-RPL] as indicated in Table 25:		[IANA-RPL] as indicated in Table 25:
	+======+=============================+===========+		+======+=================================+===========+
	| Code | Description | Reference |		| Code | Description | Reference |
	+======+=============================+===========+		+======+=================================+===========+
	| 0x09 | Projected DAO Request (PDR) | RFC 9914 |		| 0x09 | Projected DAO Request (PDAOReq) | RFC 9914 |
	+------+-----------------------------+-----------+		+------+---------------------------------+-----------+
	| 0x0A | PDR-ACK | RFC 9914 |		| 0x0A | PDR-ACK | RFC 9914 |
	+------+-----------------------------+-----------+		+------+---------------------------------+-----------+
	Table 25: New RPL Control Codes		Table 25: New RPL Control Codes
	11.6. RPL Control Message Options		11.6. RPL Control Message Options
	IANA has updated the "RPL Control Message Options" registry under the		IANA has updated the "RPL Control Message Options" registry under the
	"Routing Protocol for Low Power and Lossy Networks (RPL)" registry		"Routing Protocol for Low Power and Lossy Networks (RPL)" registry
	group [IANA-RPL] as indicated in Table 26:		group [IANA-RPL] as indicated in Table 26:
	+=======+==================================+===========+		+=======+==============================================+===========+
	| Value | Meaning | Reference |		| Value | Meaning | Reference |
	+=======+==================================+===========+		+=======+==============================================+===========+
	| 0x0F | Stateful VIO (SM-VIO) | RFC 9914 |		| 0x0F | Stateful Storing Mode VIO (SM-VIO) | RFC 9914 |
	+-------+----------------------------------+-----------+		+-------+----------------------------------------------+-----------+
	| 0x10 | Source-Routed VIO (NSM-VIO) | RFC 9914 |		| 0x10 | Source-Routed Non-Storing Mode VIO (NSM-VIO) | RFC 9914 |
	+-------+----------------------------------+-----------+		+-------+----------------------------------------------+-----------+
	| 0x11 | Sibling Information Option (SIO) | RFC 9914 |		| 0x11 | Sibling Information Option (SIO) | RFC 9914 |
	+-------+----------------------------------+-----------+		+-------+----------------------------------------------+-----------+
	Table 26: RPL Control Message Options		Table 26: RPL Control Message Options
	11.7. Registry for Projected DAO Request Flags		11.7. Registry for Projected DAO Request Flags
	IANA has created the "Projected DAO Request (PDR) Flags" registry		IANA has created the "Projected DAO Request (PDAOReq) Flags" registry
	under the "Routing Protocol for Low Power and Lossy Networks (RPL)"		under the "Routing Protocol for Low Power and Lossy Networks (RPL)"
	registry group [IANA-RPL]. The bits are indexed from 0 (leftmost) to		registry group [IANA-RPL]. The bits are indexed from 0 (leftmost) to
	7. Each bit is tracked with the following qualities:		7. Each bit is tracked with the following qualities:
	* Bit number (counting from bit 0 as the most significant bit)		* Bit number (counting from bit 0 as the most significant bit)
	* Capability description		* Capability description
	* Reference		* Reference
	The registration procedure is Standards Action [RFC8126]. The		The registration procedure is Standards Action [RFC8126]. The
	initial allocation is as indicated in Table 27:		initial allocation is as indicated in Table 27:
	+============+========================================+===========+		+============+========================================+===========+
	| Bit Number | Capability Description | Reference |		| Bit Number | Capability Description | Reference |
	+============+========================================+===========+		+============+========================================+===========+
	| 0 | PDR-ACK request (K) | RFC 9914 |		| 0 | PDR-ACK requested (K) | RFC 9914 |
	+------------+----------------------------------------+-----------+		+------------+----------------------------------------+-----------+
	| 1 | Requested path should be redundant (R) | RFC 9914 |		| 1 | Requested path should be redundant (R) | RFC 9914 |
	+------------+----------------------------------------+-----------+		+------------+----------------------------------------+-----------+
	| 2..255 | Unassigned | |		| 2..255 | Unassigned | |
	+------------+----------------------------------------+-----------+		+------------+----------------------------------------+-----------+
	Table 27: Initial PDR Flags		Table 27: Initial PDAOReq Flags
	11.8. Registry for PDR-ACK Flags		11.8. Registry for PDR-ACK Flags
	IANA has created the "PDR-ACK Flags" registry under the "Routing		IANA has created the "PDR-ACK Flags" registry under the "Routing
	Protocol for Low Power and Lossy Networks (RPL)" registry group		Protocol for Low Power and Lossy Networks (RPL)" registry group
	[IANA-RPL]. The bits are indexed from 0 (leftmost) to 7. Each bit		[IANA-RPL]. The bits are indexed from 0 (leftmost) to 7. Each bit
	is tracked with the following qualities:		is tracked with the following qualities:
	* Bit number (counting from bit 0 as the most significant bit)		* Bit number (counting from bit 0 as the most significant bit)
	skipping to change at line 4143 ¶		skipping to change at line 4156 ¶
	Directed Acyclic Graph (DODAG) Configuration Option for		Directed Acyclic Graph (DODAG) Configuration Option for
	the 6LoWPAN Routing Header", RFC 9035,		the 6LoWPAN Routing Header", RFC 9035,
	DOI 10.17487/RFC9035, April 2021,		DOI 10.17487/RFC9035, April 2021,
	<https://www.rfc-editor.org/info/rfc9035>.		<https://www.rfc-editor.org/info/rfc9035>.
	[RFC9450] Bernardos, CJ., Ed., Papadopoulos, G., Thubert, P., and F.		[RFC9450] Bernardos, CJ., Ed., Papadopoulos, G., Thubert, P., and F.
	Theoleyre, "Reliable and Available Wireless (RAW) Use		Theoleyre, "Reliable and Available Wireless (RAW) Use
	Cases", RFC 9450, DOI 10.17487/RFC9450, August 2023,		Cases", RFC 9450, DOI 10.17487/RFC9450, August 2023,
	<https://www.rfc-editor.org/info/rfc9450>.		<https://www.rfc-editor.org/info/rfc9450>.
	[RFC9473] Enghardt, R. and C. Krähenbühl, "A Vocabulary of Path
	Properties", RFC 9473, DOI 10.17487/RFC9473, September
	2023, <https://www.rfc-editor.org/info/rfc9473>.
	[NEW-TAGS] Kühlewind, M. and S. Krishnan, "Definition of new tags for		[NEW-TAGS] Kühlewind, M. and S. Krishnan, "Definition of new tags for
	relations between RFCs", Work in Progress, Internet-Draft,		relations between RFCs", Work in Progress, Internet-Draft,
	draft-kuehlewind-rswg-updates-tag-02, 8 July 2024,		draft-kuehlewind-rswg-updates-tag-02, 8 July 2024,
	<https://datatracker.ietf.org/doc/html/draft-kuehlewind-		<https://datatracker.ietf.org/doc/html/draft-kuehlewind-
	rswg-updates-tag-02>.		rswg-updates-tag-02>.
	[IANA-6LO] IANA, "IPv6 Low Power Personal Area Network Parameters",		[IANA-6LO] IANA, "IPv6 Low Power Personal Area Network Parameters",
	<https://www.iana.org/assignments/_6lowpan-parameters>.		<https://www.iana.org/assignments/_6lowpan-parameters>.
	[IANA-RPL] IANA, "Routing Protocol for Low Power and Lossy Networks		[IANA-RPL] IANA, "Routing Protocol for Low Power and Lossy Networks
	skipping to change at line 4185 ¶		skipping to change at line 4194 ¶
	his review during WG Last Call and to Maria Ines Robles for her		his review during WG Last Call and to Maria Ines Robles for her
	thorough shepherd review. Many thanks to Warren Kumari, Ran Chen,		thorough shepherd review. Many thanks to Warren Kumari, Ran Chen,
	Murray Kucherawy, Roman Danyliw, Klaas Wierenga, Deb Cooley, Éric		Murray Kucherawy, Roman Danyliw, Klaas Wierenga, Deb Cooley, Éric
	Vyncke, Gunter Van de Velde, Sue Hares, and John Scudder for their		Vyncke, Gunter Van de Velde, Sue Hares, and John Scudder for their
	comments and suggestions during the IETF Last Call and IESG review		comments and suggestions during the IETF Last Call and IESG review
	cycle.		cycle.
	Authors' Addresses		Authors' Addresses
	Pascal Thubert (editor)		Pascal Thubert (editor)
			Independent
	06330 Roquefort-les-Pins		06330 Roquefort-les-Pins
	France		France
	Email: pascal.thubert@gmail.com		Email: pascal.thubert@gmail.com
	Rahul Arvind Jadhav		Rahul Arvind Jadhav
	AccuKnox		AccuKnox
	Kundalahalli Village, Whitefield		Kundalahalli Village, Whitefield
	Bangalore 560037		Bangalore 560037
	Karnataka		Karnataka
	India		India
End of changes. 261 change blocks.
	568 lines changed or deleted		578 lines changed or added
This html diff was produced by rfcdiff 1.48.