< draft-ietf-roll-dao-projection-11.txt		draft-ietf-roll-dao-projection-12.txt >
	ROLL P. Thubert, Ed.		ROLL P. Thubert, Ed.
	Internet-Draft Cisco Systems		Internet-Draft Cisco Systems
	Updates: 6550 (if approved) R.A. Jadhav		Updates: 6550 (if approved) R.A. Jadhav
	Intended status: Standards Track Huawei Tech		Intended status: Standards Track Huawei Tech
	Expires: March 15, 2021 M. Gillmore		Expires: 25 March 2021 M. Gillmore
	Itron		Itron
	September 11, 2020		21 September 2020
	Root initiated routing state in RPL		Root initiated routing state in RPL
	draft-ietf-roll-dao-projection-11		draft-ietf-roll-dao-projection-12
	Abstract		Abstract
	This document enables a RPL Root to install and maintain Projected		This document enables a RPL Root to install and maintain Projected
	Routes within its DODAG, along a selected set of nodes that may or		Routes within its DODAG, along a selected set of nodes that may or
	may not include self, for a chosen duration. This potentially		may not include self, for a chosen duration. This potentially
	enables routes that are more optimized or resilient than those		enables routes that are more optimized or resilient than those
	obtained with the classical distributed operation of RPL, either in		obtained with the classical distributed operation of RPL, either in
	terms of the size of a source-route header or in terms of path		terms of the size of a source-route header or in terms of path
	length, which impacts both the latency and the packet delivery ratio.		length, which impacts both the latency and the packet delivery ratio.
	Projected Routes may be installed in either Storing and Non-Storing
	Modes Instances of the classical RPL operation, resulting in
	potentially hybrid situations where the mode of some Projected Routes
	is different from that of the other routes in the RPL Instance.
	Status of This Memo		Status of This Memo
	This Internet-Draft is submitted in full conformance with the		This Internet-Draft is submitted in full conformance with the
	provisions of BCP 78 and BCP 79.		provisions of BCP 78 and BCP 79.
	Internet-Drafts are working documents of the Internet Engineering		Internet-Drafts are working documents of the Internet Engineering
	Task Force (IETF). Note that other groups may also distribute		Task Force (IETF). Note that other groups may also distribute
	working documents as Internet-Drafts. The list of current Internet-		working documents as Internet-Drafts. The list of current Internet-
	Drafts is at https://datatracker.ietf.org/drafts/current/.		Drafts is at https://datatracker.ietf.org/drafts/current/.
	Internet-Drafts are draft documents valid for a maximum of six months		Internet-Drafts are draft documents valid for a maximum of six months
	and may be updated, replaced, or obsoleted by other documents at any		and may be updated, replaced, or obsoleted by other documents at any
	time. It is inappropriate to use Internet-Drafts as reference		time. It is inappropriate to use Internet-Drafts as reference
	material or to cite them other than as "work in progress."		material or to cite them other than as "work in progress."
	This Internet-Draft will expire on March 15, 2021.		This Internet-Draft will expire on 25 March 2021.
	Copyright Notice		Copyright Notice
	Copyright (c) 2020 IETF Trust and the persons identified as the		Copyright (c) 2020 IETF Trust and the persons identified as the
	document authors. All rights reserved.		document authors. All rights reserved.
	This document is subject to BCP 78 and the IETF Trust's Legal		This document is subject to BCP 78 and the IETF Trust's Legal
	Provisions Relating to IETF Documents (https://trustee.ietf.org/		Provisions Relating to IETF Documents (https://trustee.ietf.org/
	license-info) in effect on the date of publication of this document.		license-info) in effect on the date of publication of this document.
	Please review these documents carefully, as they describe your rights		Please review these documents carefully, as they describe your rights
	and restrictions with respect to this document. Code Components		and restrictions with respect to this document. Code Components
	extracted from this document must include Simplified BSD License text		extracted from this document must include Simplified BSD License text
	as described in Section 4.e of the Trust Legal Provisions and are		as described in Section 4.e of the Trust Legal Provisions and are
	provided without warranty as described in the Simplified BSD License.		provided without warranty as described in the Simplified BSD License.
	Table of Contents		Table of Contents
	1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3		1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
	2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5		2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5
	2.1. Requirements Language . . . . . . . . . . . . . . . . . . 5		2.1. Requirements Language . . . . . . . . . . . . . . . . . . 5
	2.2. References . . . . . . . . . . . . . . . . . . . . . . . 5		2.2. Glossary . . . . . . . . . . . . . . . . . . . . . . . . 5
	2.3. Glossary . . . . . . . . . . . . . . . . . . . . . . . . 5		2.3. Other Terms . . . . . . . . . . . . . . . . . . . . . . . 5
	2.4. Other Terms . . . . . . . . . . . . . . . . . . . . . . . 6		2.4. References . . . . . . . . . . . . . . . . . . . . . . . 6
	3. Updating RFC 6550 . . . . . . . . . . . . . . . . . . . . . . 6		3. Updating RFC 6550 . . . . . . . . . . . . . . . . . . . . . . 6
	4. Identifying a Path . . . . . . . . . . . . . . . . . . . . . 7		4. Identifying a Path . . . . . . . . . . . . . . . . . . . . . 7
	5. New RPL Control Messages and Options . . . . . . . . . . . . 8		5. New RPL Control Messages and Options . . . . . . . . . . . . 8
	5.1. New P-DAO Request Control Message . . . . . . . . . . . . 8		5.1. New P-DAO Request Control Message . . . . . . . . . . . . 8
	5.2. New PDR-ACK Control Message . . . . . . . . . . . . . . . 9		5.2. New PDR-ACK Control Message . . . . . . . . . . . . . . . 9
	5.3. Route Projection Options . . . . . . . . . . . . . . . . 10		5.3. Route Projection Options . . . . . . . . . . . . . . . . 10
	5.4. Sibling Information Option . . . . . . . . . . . . . . . 12		5.4. Sibling Information Option . . . . . . . . . . . . . . . 13
	6. Projected DAO . . . . . . . . . . . . . . . . . . . . . . . . 14		6. Projected DAO . . . . . . . . . . . . . . . . . . . . . . . . 14
	6.1. Non-Storing Mode Projected Route . . . . . . . . . . . . 15		6.1. Requesting a Track . . . . . . . . . . . . . . . . . . . 16
	6.2. Storing-Mode Projected Route . . . . . . . . . . . . . . 17		6.2. Routing over a Track . . . . . . . . . . . . . . . . . . 16
	7. Security Considerations . . . . . . . . . . . . . . . . . . . 19		6.3. Non-Storing Mode Projected Route . . . . . . . . . . . . 17
	8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 19		6.4. Storing-Mode Projected Route . . . . . . . . . . . . . . 18
	8.1. New RPL Control Codes . . . . . . . . . . . . . . . . . . 19		7. Security Considerations . . . . . . . . . . . . . . . . . . . 21
	8.2. New RPL Control Message Options . . . . . . . . . . . . . 19		8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 21
	8.3. New SubRegistry for the Projected DAO Request (PDR)		8.1. New RPL Control Codes . . . . . . . . . . . . . . . . . . 21
	Flags . . . . . . . . . . . . . . . . . . . . . . . . . . 20		8.2. New RPL Control Message Options . . . . . . . . . . . . . 21
	8.4. New SubRegistry for the PDR-ACK Flags . . . . . . . . . . 20		8.3. SubRegistry for the Projected DAO Request Flags . . . . . 22
	8.5. New Subregistry for the PDR-ACK Acceptance Status		8.4. SubRegistry for the PDR-ACK Flags . . . . . . . . . . . . 22
	values . . . . . . . . . . . . . . . . . . . . . . . . . 21		8.5. Subregistry for the PDR-ACK Acceptance Status Values . . 22
	8.6. New Subregistry for the PDR-ACK Rejection Status		8.6. Subregistry for the PDR-ACK Rejection Status Values . . . 23
	values . . . . . . . . . . . . . . . . . . . . . . . . . 21		8.7. SubRegistry for the Route Projection Options Flags . . . 23
	8.7. New SubRegistry for the Route Projection Options (RPO)		8.8. SubRegistry for the Sibling Information Option Flags . . 24
	Flags . . . . . . . . . . . . . . . . . . . . . . . . . . 21		8.9. Error in Projected Route ICMPv6 Code . . . . . . . . . . 24
	8.8. New SubRegistry for the Sibling Information Option (SIO)		9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 24
	Flags . . . . . . . . . . . . . . . . . . . . . . . . . . 22		10. Normative References . . . . . . . . . . . . . . . . . . . . 24
	8.9. Error in Projected Route ICMPv6 Code . . . . . . . . . . 22		11. Informative References . . . . . . . . . . . . . . . . . . . 25
	9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 22		Appendix A. Applications . . . . . . . . . . . . . . . . . . . . 26
	10. Normative References . . . . . . . . . . . . . . . . . . . . 23		A.1. Loose Source Routing . . . . . . . . . . . . . . . . . . 27
	11. Informative References . . . . . . . . . . . . . . . . . . . 23		A.2. Transversal Routes . . . . . . . . . . . . . . . . . . . 28
	Appendix A. Applications . . . . . . . . . . . . . . . . . . . . 24		Appendix B. Examples . . . . . . . . . . . . . . . . . . . . . . 30
	A.1. Loose Source Routing in Non-storing Mode . . . . . . . . 25		B.1. Using Storing Mode P-DAO in Non-Storing Mode MOP . . . . 30
	A.2. Transversal Routes in storing and non-storing modes . . . 26		B.2. Projecting a storing-mode transversal route . . . . . . . 31
	Appendix B. Examples . . . . . . . . . . . . . . . . . . . . . . 28		Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 33
	B.1. Using storing mode P-DAO in non-storing mode MOP . . . . 28
	B.2. Projecting a storing-mode transversal route . . . . . . . 29
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 31
	1. Introduction		1. Introduction
	RPL, the "Routing Protocol for Low Power and Lossy Networks" [RPL]		RPL, the "Routing Protocol for Low Power and Lossy Networks" [RPL]
	(LLNs), is a generic Distance Vector protocol that is well suited for		(LLNs), is a generic Distance Vector protocol that is well suited for
	application in a variety of low energy Internet of Things (IoT)		application in a variety of low energy Internet of Things (IoT)
	networks. RPL forms Destination Oriented Directed Acyclic Graphs		networks. RPL forms Destination Oriented Directed Acyclic Graphs
	(DODAGs) in which the Root often acts as the Border Router to connect		(DODAGs) in which the Root often acts as the Border Router to connect
	the RPL domain to the Internet. The Root is responsible to select		the RPL domain to the Internet. The Root is responsible to select
	the RPL Instance that is used to forward a packet coming from the		the RPL Instance that is used to forward a packet coming from the
	skipping to change at page 3, line 40 ¶		skipping to change at page 3, line 35 ¶
	Based on heuristics of usage, path length, and knowledge of device		Based on heuristics of usage, path length, and knowledge of device
	capacity and available resources such as battery levels and		capacity and available resources such as battery levels and
	reservable buffers, a PCE with a global visibility on the system can		reservable buffers, a PCE with a global visibility on the system can
	compute P2P routes that are more optimized for the current needs as		compute P2P routes that are more optimized for the current needs as
	expressed by the objective function.		expressed by the objective function.
	This draft proposes protocol extensions to RPL that enable the Root		This draft proposes protocol extensions to RPL that enable the Root
	to install a limited amount of centrally-computed routes in a RPL		to install a limited amount of centrally-computed routes in a RPL
	graph, on behalf of a PCE that may be collocated or separated from		graph, on behalf of a PCE that may be collocated or separated from
	the Root. Those extensions enable loose source routing down in RPL		the Root. Those extensions enable loose source routing down and
	Non-Storing Mode and transversal routes inside the DODAG regardless		transversal routes inside the main DODAG running a base RPL Instance.
	of the RPL Mode of Operation (MOP).
			This specification expects that the base RPL Instance is operated in
			RPL Non-Storing Mode of Operation (MOP) to sustain the exchanges with
			the Root. In that Mode, the Root has enough information to build a
			basic DODAG topology based on parents and children, but lacks the
			knowledge of siblings. This document adds the capability for nodes
			to advertise sibling information in order to improve the topological
			awareness of the Root.
	As opposed to the classical RPL operations where routes are injected		As opposed to the classical RPL operations where routes are injected
	by the Target nodes, the protocol extensions enable the Root of a		by the Target nodes, the protocol extensions enable the Root of a
	DODAG to project the routes that are needed onto the nodes where they		DODAG to project the routes that are needed onto the nodes where they
	should be installed. This specification uses the term Projected		should be installed. This specification uses the term Projected
	Route to refer to those routes. A Projected Route may be a stand-		Route to refer to those routes.
	alone end-to-end path to a Target or a segment in a more complex
	forwarding graph called a Track.		A Projected Route may be installed in either Storing and Non-Storing
			Mode, potentially resulting in hybrid situations where the Mode of
			the Projected Route is different from that of the main RPL Instance.
			A Projected Route may be a stand-alone end-to-end path to a Target or
			a Segment in a more complex forwarding graph called a Track.
	The concept of a Track was introduced in the 6TiSCH architecture, as		The concept of a Track was introduced in the 6TiSCH architecture, as
	a complex path with redundant forwarding solutions along the way. A		a complex path to a Target destination with redundant forwarding
	node that is present on more than one segment in a Track may be able		solutions along the way. A node at the ingress of more than one
	to use either of the Track segments to forward a packet towards the		Segment in a Track may use any combination of those Segments to
	Target.		forward a packet towards the Target.
	The "Reliable and Available Wireless (RAW) Architecture/Framework"		The "Reliable and Available Wireless (RAW) Architecture/Framework"
	[RAW-ARCHI] extends the the forward plane to leverage that redundancy		[RAW-ARCHI] enables a dynamic path selection within the Track to
	with the Packet ARQ, Replication, Elimination, and Overhearing		increase the transmission diversity and combat diverse causes of
	(PAREO) functions.		packet loss.
	The RAW Architecture also discusses the dynamic selection of the best		To that effect, RAW defines the Path Selection Engine (PSE) as a
	path for a packet within a Track at forwarding time. To that effect,		complement of the PCE operating in the dataplane. The PSE controls
	it defines the Path Selection Engine (PSE), which is the counter-part		the use of the Packet ARQ, Replication, Elimination, and Overhearing
	of the PCE to perform rapid local adjustments of the forwarding		(PAREO) functions over the Track segments.
	tables within the path diversity that the PCE has selected for the
	Track.
	RAW differentiates the time scale at which the PCE computes the Track		While the time scale at which the PCE (re)computes the Track can be
	(slow, globally optimized, based on statistical metrics) and the time		long, for an operation based on long-term statistical metrics to
	scale at which the PSE makes the forwarding decision for a packet or		perform global optimizations at the scale of the whole network, the
	a small collection of packets (fast, but with a scope limited to the		PSE makes forwarding decision at the time scale of one or a small
	Track). This provides a dynamic balance between the reliability and		collection of packets, using a knowledge that is changing rapidly but
	availability requirements of the flows and the need to conserve		limited in scope of the Track itself. This way, the PSE can provide
	energy and spectrum.		a dynamic balance between the reliability and availability
			requirements of the flows and the need to conserve energy and
			spectrum.
	Projected Routes must be used with the parsimony to limit the amount		Projected Routes must be used with the parsimony to limit the amount
	of state that is installed in each device to fit within the device		of state that is installed in each device to fit within the device
	resources, and to maintain the amount of rerouted traffic within the		resources, and to maintain the amount of rerouted traffic within the
	capabilities of the transmission links. The methods used to learn		capabilities of the transmission links. The methods used to learn
	the node capabilities and the resources that are available in the		the node capabilities and the resources that are available in the
	devices and in the network are out of scope for this document.		devices and in the network are out of scope for this document.
	This specification expects that a base RPL Instance is operated in
	RPL Non-Storing Mode to sustain the exchanges with the Root. In that
	Mode, the Root has enough information to build a basic DODAG topology
	based on parents and children, but lacks the knowledge of siblings.
	This document adds the capability for nodes to advertise sibling
	information in order to improve the topological awareness of the
	Root.
	This specification uses the RPL Root as a proxy to the PCE. The PCE		This specification uses the RPL Root as a proxy to the PCE. The PCE
	may be collocated with the Root, or may reside in an external		may be collocated with the Root, or may reside in an external
	Controller. In that case, the PCE exchanges control messages with		Controller. In that case, the PCE exchanges control messages with
	the Root over a Southbound API, that is out of scope for this		the Root over a Southbound API, that is out of scope for this
	specification. The algorithm to compute the paths and the protocol		specification. The algorithm to compute the paths and the protocol
	used by an external PCE to obtain the topology of the network from		used by an external PCE to obtain the topology of the network from
	the Root are also out of scope.		the Root are also out of scope.
	2. Terminology		2. Terminology
	2.1. Requirements Language		2.1. Requirements Language
	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 BCP		"OPTIONAL" in this document are to be interpreted as described in BCP
	14 [RFC2119][RFC8174] when, and only when, they appear in all		14 [RFC2119][RFC8174] when, and only when, they appear in all
	capitals, as shown here.		capitals, as shown here.
	2.2. References		2.2. Glossary
	In this document, readers will encounter terms and concepts that are
	discussed in the "Routing Protocol for Low Power and Lossy Networks"
	[RPL] and "Terminology in Low power And Lossy Networks" [RFC7102].
	2.3. Glossary
	This document often uses the following acronyms:		This document often uses the following acronyms:
	6BBR: 6LoWPAN Backbone Router
	6LBR: 6LoWPAN Border Router
	6LN: 6LoWPAN Node
	6LR: 6LoWPAN Router
	CMO: Control Message Option		CMO: Control Message Option
	DAO: Destination Advertisement Object		DAO: Destination Advertisement Object
	DODAG: Destination-Oriented Directed Acyclic Graph		DAG: Directed Acyclic Graph
			DODAG: Destination-Oriented Directed Acyclic Graph; A DAG with only
			one vertice (i.e., node) that has no outgoing edge (i.e., link)
	LLN: Low-Power and Lossy Network		LLN: Low-Power and Lossy Network
	MOP: RPL Mode of Operation		MOP: RPL Mode of Operation
	NA: Neighbor Advertisement		P-DAO: Projected DAO
	NCE: Neighbor Cache Entry		PDR: P-DAO Request
	ND: Neighbor Discovery		RAN: RPL-Aware Node (either a RPL Router or a RPL-Aware Leaf)
	NDP: Neighbor Discovery Protocol		RAL: RPL-Aware Leaf
	NS: Neighbor Solicitation		RPI: RPL Packet Information
	P-DAO: A Projected DAO is a DAO message sent by the RPL Root to
	install a Projected Route.
	PDR P-DAO Request
	RA: Router Advertisement
	RAN: RPL-Aware Node
	RS: Router Solicitation
	RPL: IPv6 Routing Protocol for LLNs [RPL]		RPL: IPv6 Routing Protocol for LLNs [RPL]
	RPO: A Route Projection Option; it can be a VIO or an SRVIO.		RPO: A Route Projection Option; it can be a VIO or an SRVIO.
	RTO: RPL Target Option		RTO: RPL Target Option
			RUL: RPL-Unaware Leaf
	SIO: RPL Sibling Information Option		SIO: RPL Sibling Information Option
	SRVIO: A Source-Routed Via Information Option, used in Non-Storing		SRVIO: A Source-Routed Via Information Option, used in Non-Storing
	Mode P-DAO messages.		Mode P-DAO messages.
			SubDAG: A DODAG rooted at a node which is a child of that node and a
			subset of a larger DAG
	TIO: RPL Transit Information Option		TIO: RPL Transit Information Option
	VIO: A Via Information Option, used in Storing Mode P-DAO messages.		VIO: A Via Information Option, used in Storing Mode P-DAO messages.
	2.4. Other Terms		2.3. Other Terms
	Projected Route: A Projected Route is a serial path or path segment		Projected Route: A Projected Route is a serial path that is
	that is computed, installed and maintained remotely by a RPL Root.		computed, installed and maintained remotely by a RPL Root.
	Track: The term Track is used in this document to refer to a complex		Projected DAO: A DAO message used to install a Projected Route.
	path, e.g., a DODAG, that incorporates redundant Projected Routes		Track: A complex path with redundant Segments to a destination.
	towards a destination using diversity to increase the reliability.		TrackID: A RPL Local InstanceID with the 'D' bit set. The TrackId
			is associated with a Target address that is the Track destination.
			2.4. References
			In this document, readers will encounter terms and concepts that are
			discussed in the "Routing Protocol for Low Power and Lossy Networks"
			[RPL] and "Terminology in Low power And Lossy Networks" [RFC7102].
	3. Updating RFC 6550		3. Updating RFC 6550
	This specification introduces two new RPL Control Messages to enable		This specification introduces two new RPL Control Messages to enable
	a RPL Aware Node (RAN) to request the establisment of a Track from		a RPL Aware Node (RAN) to request the establisment of a Track from
	self to a Target. The RAN makes its request by sending a new P-DAO		self to a Target. The RAN makes its request by sending a new P-DAO
	Request (PDR) Message to the Root. The Root confirms with a new PDR-		Request (PDR) Message to the Root. The Root confirms with a new PDR-
	ACK message back to the requester RAN, see Section 5.1 for more.		ACK message back to the requester RAN, see Section 5.1 for more.
	Section 6.7 of [RPL] specifies the RPL Control Message Options (CMO)		Section 6.7 of [RPL] specifies the RPL Control Message Options (CMO)
	skipping to change at page 7, line 21 ¶		skipping to change at page 7, line 21 ¶
	routing information within one routing topology.		routing information within one routing topology.
	This draft conforms the Instance model as follows:		This draft conforms the Instance model as follows:
	* If the PCE needs to influence a particular Instance to add better		* If the PCE needs to influence a particular Instance to add better
	routes in conformance with the routing objectives in that		routes in conformance with the routing objectives in that
	Instance, it may do so as long as it does not create a loop. A		Instance, it may do so as long as it does not create a loop. A
	Projected Route is always preferred over a route that is learned		Projected Route is always preferred over a route that is learned
	via RPL.		via RPL.
	* A PCE that installs a more specific (say, Traffic Engineered) and		* The PCE may use P-DAOs to install a specific (say, Traffic
	possibly complex path (i.e., a Track) towards a particular Target		Engineered) and possibly complex path, that we refer to as a
	MUST use a Local RPL Instance (see section 5 of [RPL]) associated		Track, towards a particular Target. In that case it MUST use a
	to that Target to identify the path.		Local RPL Instance (see section 5 of [RPL]) associated to that
			Target to identify the Track.
	We refer to that Local RPLInstanceID as TrackID. A TrackID MUST		We refer to the local RPLInstanceID as TrackID. The TrackID MUST
	be unique for a particular Target address. A Track is uniquely		be unique for a particular Target IPv6 address. The Track is
	identified within the RPL domain by the tuple (Target address,		uniquely identified within the RPL domain by the tuple (Target
	TrackID).		address, TrackID) where the TrackID is always represented with the
			'D' flag set.
	When packet is placed on a Track, a RPL Packet Information (RPI)		The Track where a packet is placed is signaled by a RPL Packet
	is added with the TrackID as RPLInstanceID. The RPLInstanceID has		Information (RPI) (see [USEofRPLinfo]) in the outer chain of IPv6
	the 'D' flag set, indicating that the destination address in the		Headers. The RPI contains the TrackID as RPLInstanceID and the
	IPv6 header is the Target that is used to identify the Track.		'D' flag is set to indicate that the destination address in the
			IPv6 header is the Target that is used to identify the Track, more
			in Section 6.2.
			* The PCE may also install a projected Route as a complement to the
			main DODAG, e.g., using the Storing-Mode Mode along a Source-
			Routed path in order to enable loose source routing and reduce the
			Routing Header. In that case, the global RPLInstanceID of the
			main DODAG is signaled in place of the TrackId on the P-DAO, and
			the RPI in the packet indicates the global RPLInstanceID, more in
			Appendix A.1.
	* A packet that is routed over the RPL Instance associated to a		* A packet that is routed over the RPL Instance associated to a
	Track MUST NOT be placed over a different RPL Instance again.		Track MUST NOT be placed over a different RPL Instance again.
	Conversely, a packet that is placed on a Global Instance MAY be		Conversely, a packet that is placed on a Global Instance MAY be
	injected in a Local Instance based on a network policy and the		injected in a Local Instance based on a network policy and the
	Local Instance configuration.		Local Instance configuration.
	A Projected Route is a serial path that may represent the end-to-end		A Projected Route is a serial path that may represent the end-to-end
	route or only a segment in a complex Track, in which case multiple		route or only a Segment in a complex Track, in which case multiple
	Projected Routes are installed with the same tuple (Target address,		Projected Routes are installed with the same tuple (Target address,
	TrackID) and a different segment ID each.		TrackID) and a different Segment ID each.
	All properties of a Track operations are inherited form the main		All properties of a Track operations are inherited form 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
	main instance, e.g., by setting the "T" flag [TURN-ON_RFC8138] in the		main instance, e.g., by setting the "T" flag [TURN-ON_RFC8138] in the
	RPL configuration option.		RPL configuration option.
	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 P-DAO Request (PDR) message is sent to the Root to request a new		The P-DAO Request (PDR) message is sent to the Root to request a new
	that the PCE establishes a new a projected route as a full path of a		that the PCE establishes a new a projected route from self ot the
	collection of segments in a Track. Exactly one Target Options MUST		Target indicated in the Target Option as a full path of a collection
	be present.		of Segments in a Track. Exactly one Target Option MUST be present,
			more in Section 6.1.
			The RPL Control Code for the PDR is 0x09, to be confirmed by IANA.
	The format of PDR Base Object is as follows:		The format of PDR 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 | PDRLifetime | PDRSequence |		| TrackID |K|R| Flags | ReqLifetime | PDRSequence |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| Option(s)...		| Option(s)...
	+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+
	Figure 1: New P-DAO Request Format		Figure 1: New P-DAO Request Format
	TrackID: 8-bit field indicating the RPLInstanceID associated with		TrackID: 8-bit field indicating the RPLInstanceID associated with
	the Track. It is set to zero upon the first request for a new		the Track. It is set to zero upon the first request for a new
	Track and then to the TrackID once the Track was created, to		Track and then to the TrackID once the Track was created, to
	either renew it of destroy it.		either renew it of destroy it.
	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 indicate that the Requested path should be		R: The 'R' flag is set to indicate that the Requested path should be
	redundant.		redundant.
	PDRLifetime: 8-bit unsigned integer.		Flags: Reserved. The Flags field MUST initialized to zero by the
			sender and MUST be ignored by the receiver
			ReqLifetime: 8-bit unsigned integer.
	The requested lifetime for the Track expressed in Lifetime Units		The requested lifetime for the Track expressed in Lifetime Units
	(obtained from the DODAG Configuration option).		(obtained from the DODAG Configuration option).
	A PDR with a fresher PDRSequence refreshes the lifetime, and a		A PDR with a fresher PDRSequence refreshes the lifetime, and a
	PDRLifetime of 0 indicates that the track should be destroyed.		PDRLifetime of 0 indicates that the track should be destroyed.
	PDRSequence: 8-bit wrapping sequence number, obeying the operation		PDRSequence: 8-bit wrapping sequence number, obeying the operation
	in section 7.2 of [RPL].		in section 7.2 of [RPL].
	The PDRSequence is used to correlate a PDR-ACK message with the		The PDRSequence is used to correlate a PDR-ACK message with the
	PDR message that triggeted it. It is incremented at each PDR		PDR message that triggeted it. It is incremented at each PDR
	message and echoed in the PDR-ACK by the Root.		message and 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 PDR message with the 'K'
	flag set. Its format is as follows:		flag set. The RPL Control Code for the PDR-ACK is 0x0A, to be
			confirmed by IANA. Its 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| PDRSequence |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| PDR-ACK Status| Reserved |		| PDR-ACK Status| Reserved |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| Option(s)...		| Option(s)...
	+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+
	Figure 2: New PDR-ACK Control Message Format		Figure 2: New PDR-ACK Control Message Format
	TrackID: The RPLInstanceID of the Track that was created. Set to 0		TrackID: The RPLInstanceID of the Track that was created. The value
	when no Track is created.		of 0x00 is used to when no Track was created.
	Track Lifetime: Indicates that remaining Lifetime for the Track, 0		Flags: Reserved. The Flags field MUST initialized to zero by the
	if the Track was destroyed or not created.		sender and MUST be ignored by the receiver
			Track Lifetime: Indicates that remaining Lifetime for the Track,
			expressed in Lifetime Units; a value of zero (0x00) indicates that
			the Track was destroyed or not created.
	PDRSequence: 8-bit wrapping sequence number. It is incremented at		PDRSequence: 8-bit wrapping sequence number. It is incremented at
	each PDR message and echoed in the PDR-ACK.		each PDR message and echoed in the PDR-ACK.
	PDR-ACK Status: 8-bit field indicating the completion.		PDR-ACK Status: 8-bit field indicating the completion.
	The PDR-ACK Status is further substructured as indicated in		The PDR-ACK Status is substructured as indicated in Figure 3:
	Figure 3.
	0 1 2 3 4 5 6 7		0 1 2 3 4 5 6 7
	+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+
	|E|R| Value |		|E|R| Value |
	+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+
	Figure 3: PDR-ACK status Format		Figure 3: PDR-ACK status Format
	E: 1-bit flag. Set to indicate a rejection. When not set, a value		E: 1-bit flag. Set to indicate a rejection. When not set, a
	of 0 indicates Success/Unqualified acceptance and other values		value of 0 indicates Success/Unqualified acceptance and other
	indicate "not an outright rejection".		values indicate "not an outright rejection".
	R: 1-bit flag. Reserved, MUST be set to 0 by the sender and ignored		R: 1-bit flag. Reserved, MUST be set to 0 by the sender and
	by the receiver.		ignored by the receiver.
	Status Value: 6-bit unsigned integer. Values depending on the		Status Value: 6-bit unsigned integer. Values depending on the
	setting of the 'E' flag as indicated respectively in Table 4 and		setting of the 'E' flag as indicated respectively in Table 4
	Table 5.		and Table 5.
			Reserved: The Reserved field MUST initialized to zero by the sender
			and MUST be ignored by the receiver
	5.3. Route Projection Options		5.3. Route Projection Options
	The RPOs indicate a series of IPv6 addresses that can be compressed		The RPOs indicate a series of IPv6 addresses that can be compressed
	using the method defined in the "6LoWPAN Routing Header" [RFC8138]		using the method defined in the "6LoWPAN Routing Header" [RFC8138]
	specification using the address of the Root found in the DODAGID		specification using the address of the Root found in the DODAGID
	field of DIO messages as Compression Reference.		field of DIO messages as Compression Reference.
	An RPO indicates a Projected Route that can be a serial Track in full		An RPO indicates a Projected Route that can be a serial Track in full
	or a segment of a more complex Track. In Non-Storing Mode, multiple		or a Segment of a more complex Track. In Non-Storing Mode, multiple
	RPO may be placed after a same Target Option to reflect different		RPO may be placed after a same Target Option to reflect different
	segments originated at this node. The Track is identified by a		Segments originated at this node. The Track is identified by a
	TrackID that is a Local RPLInstanceID to the Target of the Track.		TrackID that is a Local RPLInstanceID to the Target of the Track.
	The format of RPOs is as follows:		The format of RPOs 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 |C| Flags | Reserved |		| Type | Option Length |C| Flags | Reserved |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| TrackID | SegmentID |Segm. Sequence | Seg. Lifetime |		| TrackID | SegmentID |Segm. Sequence | Seg. Lifetime |
	skipping to change at page 10, line 48 ¶		skipping to change at page 11, line 33 ¶
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| |		| |
	+ +		+ +
	. .		. .
	. Via Address n .		. Via Address n .
	. .		. .
	+ +		+ +
	| |		| |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	Figure 4: Via Information option format (uncompressed form)		Figure 4: Route Projection Option format (uncompressed form)
			Option Type: 0x0B for VIO, 0x0C for SRVIO (to be confirmed by IANA)
	Option Type: 0x0A for VIO, 0x0B for SRVIO (to be confirmed by IANA)
	Option Length: In bytes; variable, depending on the number of Via		Option Length: In bytes; variable, depending on the number of Via
	Addresses.		Addresses.
	C: 1-bit flag. Set to indicate that the following Via Addresses are		C: 1-bit flag. Set to indicate that the following Via Addresses are
	expressed as one or more SRH-6LoRH as defined in section 5.1 of		expressed as one or more SRH-6LoRH as defined in section 5.1 of
	[RFC8138]. Figure 4 illustrates the case where the "C" flag is		[RFC8138]. Figure 4 illustrates the case where the "C" flag is
	not set, meaning that the Via Addresses are expressed in full 128		not set, meaning that the Via Addresses are expressed in 128 bits.
	bits.
	TrackID: 8-bit field indicating the topology Instance associated		Flags: Reserved. The Flags field MUST initialized to zero by the
	with the Track. The tuple (Target Address, TrackID) forms a		sender and MUST be ignored by the receiver
	unique ID of the Track in the RPL domain.
	Track Sequence: 8-bit unsigned integer. The Track Sequence obeys		Reserved: The Reserved field MUST initialized to zero by the sender
	the operation in section 7.2 of [RPL] and the lollipop starts at		and MUST be ignored by the receiver
	255. The Track Sequence is set by the Root and incremented each
	time the Root refreshes that Track globally. A Track Sequence
	that is fresher than the current on deprecates any state for the
	Track. A Track Sequence that is current adds to any state that
	was learned for that Track Sequence. A RTO with a Track Sequence
	that is not as fresh as the current one is ignored.
	Track Lifetime: 8-bit unsigned integer. The length of time in		TrackID: 8-bit field indicating the topology Instance associated
	Lifetime Units (obtained from the Configuration option) that the		with the Track. This field carries either a TrackID, such that
	Track is usable. The period starts when a new Track Sequence is		the tuple (Target Address, TrackID) forms a unique ID of the Track
	seen. A value of 255 (0xFF) represents infinity. A value of zero		in the RPL domain, or the glocal InstanceID of the main DODAG, in
	(0x00) indicates a loss of reachability. A DAO message that		which case the RPO adds a route to the main DODAG as an individual
	contains a Via Information option with a Path Lifetime of zero for		Segment.
	a Target is referred as a No-Path (for that Target) in this
	document.
	SegmentID: 8-bit field that identifies a segment within a Track. A		SegmentID: 8-bit field that identifies a Segment within a Track or
	Value of 0 is used to signal a serial Track.		the main DODAG as indicated by the TrackId field. A Value of 0 is
			used to signal a serial path, i.e., made of a single segment.
	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 lollipop		obeys the operation in section 7.2 of [RPL] and the lollipop
	starts at 255. When the Root of the DODAG needs to update a		starts at 255. When the Root of the DODAG needs to refresh or
	single segment in a Track, but does not need to modify the rest of		update a Segment in a Track, it increments the Segment Sequence
	the Track, it increments the Segment Sequence but not the Track		individually for that Segment. The Segment information indicated
	Sequence. The segment information indicated in the RTO deprecates		in the RTO deprecates any state for the Segment indicated by the
	any state for the segment indicated by the SegmentID within the		SegmentID within the indicated Track and sets up the new
	indicated Track and sets up the new information. A RTO with a		information. A RTO with a Segment Sequence that is not as fresh
	Segment Sequence that is not as fresh as the current one is		as the current one is ignored. a RTO for a given target with the
	ignored. a RTO for a given target with the same (TrackID, Track		same (TrackID, SegmentID, Segment Sequence) indicates a retry; it
	Sequence, SegmentID, Segment Sequence) indicates a retry; it MUST		MUST NOT change the Segment and MUST be propagated or answered as
	NOT change the segment and MUST be propagated or answered as the		the first copy.
	first copy.
	Via Address: The collection of Via Addresses along one segment,		Segment Lifetime: 8-bit unsigned integer. The length of time in
			Lifetime Units (obtained from the Configuration option) that the
			Segment is usable. The period starts when a new Segment Sequence
			is seen. A value of 255 (0xFF) represents infinity. A value of
			zero (0x00) indicates a loss of reachability. A DAO message that
			contains a Via Information option with a Segment Lifetime of zero
			for a Target is referred as a No-Path (for that Target) in this
			document.
			Via Address: The collection of Via Addresses along one Segment,
	indicated in the order of the path from the ingress to the egress		indicated in the order of the path from the ingress to the egress
	nodes. If the "C" flag is set, the fields Via Address 1 .. Via		nodes. If the "C" flag is set, the fields Via Address 1 .. Via
	Address n in Figure 4 are replaced by one or more of the headers		Address n in Figure 4 are replaced by one or more of the headers
	illustrated in Fig. 6 of [RFC8138]. More than one SRH-6LoRH is		illustrated in Fig. 6 of [RFC8138]. In the case of a VIO, or if
	needed if the compression of the addresses change inside the		[RFC8138] is turned off, then the Root MUST use only one SRH-
	segment and different SRH-6LoRH Types are used.		6LoRH, and the compression is the same for all addresses. If
			[RFC8138] is turned on, then the Root SHOULD optimize the size of
			the SRVIO; in that case, more than one SRH-6LoRH are needed if the
			compression of the addresses change inside the Segment and
			different SRH-6LoRH Types are used.
	An RPO MUST contain at least one Via Address, and a Via Address MUST		An RPO MUST contain at least one Via Address, and a Via Address MUST
	NOT be present more than once, otherwise the RPO MUST be ignored.		NOT be present more than once, otherwise the RPO MUST be ignored.
	5.4. Sibling Information Option		5.4. Sibling Information Option
	The Sibling Information Option (SIO) provides indication on siblings		The Sibling Information Option (SIO) provides indication on siblings
	that could be used by the Root to form Projected Routes. The format		that could be used by the Root to form Projected Routes. The format
	of SIOs is as follows:		of SIOs 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 |Comp.|B|D|Flags| Opaque |		| Type | Option Length |Comp.|B|D|Flags| Opaque |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| Step of Rank | Sibling Rank |		| Step of Rank | Reserved |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| |		| |
	+ +		+ +
	. .		. .
	. Sibling DODAGID (if 'D' flag not set) .		. Sibling DODAGID (if 'D' flag not set) .
	. .		. .
	+ +		+ +
	| |		| |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| |		| |
	+ +		+ +
	. .		. .
	. Sibling Address .		. Sibling Address .
	. .		. .
	+ +		+ +
	| |		| |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	Figure 5: Sibling Information Option Format		Figure 5: Sibling Information Option Format
	Option Type: 0x0C (to be confirmed by IANA)		Option Type: 0x0D (to be confirmed by IANA)
	Option Length: In bytes; variable, depending on the number of Via		Option Length: In bytes; variable, depending on the number of Via
	Addresses.		Addresses.
	Compression Type: 3-bit unsigned integer. This is the SRH-6LoRH		Compression Type: 3-bit unsigned integer. This is the SRH-6LoRH
	Type as defined in figure 7 in section 5.1 of [RFC8138] that		Type as defined in figure 7 in section 5.1 of [RFC8138] that
	corresponds to the compression used for the Sibling Address.		corresponds to the compression used for the Sibling Address.
	Reserved for Flags: MUST be set to zero by the sender and MUST be		Reserved for Flags: MUST be set to zero by the sender and MUST be
	ignored by the receiver.		ignored by the receiver.
	skipping to change at page 13, line 22 ¶		skipping to change at page 14, line 13 ¶
	B: 1-bit flag that is set to indicate that the connectivity to the		B: 1-bit flag that is set to indicate that the connectivity to the
	sibling is bidirectional and roughly symmetrical. In that case,		sibling is bidirectional and roughly symmetrical. In that case,
	only one of the siblings may report the SIO for the hop. If 'B'		only one of the siblings may report the SIO for the hop. If 'B'
	is not set then the SIO only indicates connectivity from the		is not set then the SIO only indicates connectivity from the
	sibling to this node, and does not provide information on the hop		sibling to this node, and does not provide information on the hop
	from this node to the sibling.		from this node to the sibling.
	D: 1-bit flag that is set to indicate that sibling belongs to the		D: 1-bit flag that is set to indicate that sibling belongs to the
	same DODAG. When not set, the Sibling DODAGID is indicated.		same DODAG. When not set, the Sibling DODAGID is indicated.
			Flags: Reserved. The Flags field MUST initialized to zero by the
			sender and MUST be ignored by the receiver
	Opaque: MAY be used to carry information that the node and the Root		Opaque: MAY be used to carry information that the node and the Root
	understand, e.g., a particular representation of the Link		understand, e.g., a particular representation of the Link
	properties such as a proprietary Link Quality Information for		properties such as a proprietary Link Quality Information for
	packets received from the sibling. An industraial Alliance that		packets received from the sibling. An industraial Alliance that
	uses RPL for a particular use / environment MAY redefine the use		uses RPL for a particular use / environment MAY redefine the use
	of this field to fit its needs.		of this field to fit its needs.
	Step of Rank: 16-bit unsigned integer. This is the Step of Rank		Step of Rank: 16-bit unsigned integer. This is the Step of Rank
	[RPL] as computed by the Objective Function between this node and		[RPL] as computed by the Objective Function between this node and
	the sibling.		the sibling.
	Sibling Rank: 16-bit unsigned integer. When non-zero, this is the		Reserved: The Reserved field MUST initialized to zero by the sender
	Rank [RPL] as exposed by the sibling in DIO messages.		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
	[RFC8138] compressed form as indicated by the Compression Type		[RFC8138] compressed form as indicated by the Compression Type
	field. This field is present when the 'D' flag is not set.		field. This field is present when the 'D' flag is not set.
	Sibling Address: 2 to 16 bytes, the IPv6 Address of the sibling in a		Sibling Address: 2 to 16 bytes, the IPv6 Address of the sibling in a
	[RFC8138] compressed form as indicated by the Compression Type		[RFC8138] compressed form as indicated by the Compression Type
	field.		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
	skipping to change at page 14, line 24 ¶		skipping to change at page 15, line 15 ¶
	A P-DAO is sent from a global address of the Root to a global address		A P-DAO is sent from a global address of the Root to a global address
	of the recipient, and MUST be confirmed by a DAO-ACK, which is sent		of the recipient, and MUST be confirmed by a DAO-ACK, which is sent
	back to a global address of the Root.		back to a global address of the Root.
	A P-DAO message MUST contain exactly one RTO and either one VIO or		A P-DAO message MUST contain exactly one RTO and either one VIO or
	one or more SRVIOs following it. There can be at most one such		one or more SRVIOs following it. There can be at most one such
	sequence of RTOs and then RPOs.		sequence of RTOs and then RPOs.
	Like a classical DAO message, a P-DAO causes a change of state only		Like a classical DAO message, a P-DAO causes a change of state only
	if it is "new" per section 9.2.2. "Generation of DAO Messages" of		if it is "new" per section 9.2.2. "Generation of DAO Messages" of
	the RPL specification [RPL]; this is determined using the Track		the RPL specification [RPL]; this is determined using the Segment
	Sequence and the Segment Sequence information from the RPO as opposed		Sequence information from the RPO as opposed to the Path Sequence
	to the Path Sequence from a TIO. Also, a Path Lifetime of 0 in an		from a TIO. Also, a Segment Lifetime of 0 in an RPO indicates that
	RPO indicates that a route is to be removed.		the projected route associated to the Segment is to be removed.
	There are two kinds of operation for the Projected Routes, the		There are two kinds of operation for the Projected Routes, the
	Storing Mode and the Non-Storing Mode.		Storing Mode and the Non-Storing Mode.
	* The Non-Storing Mode is discussed in Section 6.1. It uses an		* The Non-Storing Mode is discussed in Section 6.3. It uses an
	SRVIO that carries a list of Via Addresses to be used as a source-		SRVIO that carries a list of Via Addresses to be used as a source-
	routed path to the Target. The recipient of the P-DAO is the		routed path to the Target. The recipient of the P-DAO is the
	ingress router of the source-routed path. Upon a Non-Storing Mode		ingress router of the source-routed path. Upon a Non-Storing Mode
	P-DAO, the ingress router installs a source-routed state to the		P-DAO, the ingress router installs a source-routed state to the
	Target and replies to the Root directly with a DAO-ACK message.		Target and replies to the Root directly with a DAO-ACK message.
	* The Storing Mode is discussed in Section 6.2. It uses a VIO with		* The Storing Mode is discussed in Section 6.4. It uses a VIO with
	one Via Address per consecutive hop, from the ingress to the		one Via Address per consecutive hop, from the ingress to the
	egress of the path, including the list of all intermediate routers		egress of the path, including the list of all intermediate routers
	in the data path order. The Via Addresses indicate the routers in		in the data path order. The Via Addresses indicate the routers in
	which the routing state to the Target have to be installed via the		which the routing state to the Target have to be installed via the
	next Via Address in the VIO. In normal operations, the P-DAO is		next Via Address in the VIO. In normal operations, the P-DAO is
	propagated along the chain of Via Routers from the egress router		propagated along the chain of Via Routers from the egress router
	of the path till the ingress one, which confirms the installation		of the path till the ingress one, which confirms the installation
	to the Root with a DAO-ACK message. Note that the Root may be the		to the Root with a DAO-ACK message. Note that the Root may be the
	ingress and it may be the egress of the path, that it can also be		ingress and it may be the egress of the path, that it can also be
	neither but it cannot be both.		neither but it cannot be both.
	skipping to change at page 15, line 15 ¶		skipping to change at page 16, line 4 ¶
	In case of a forwarding error along a Projected Route, an ICMP error		In case of a forwarding error along a Projected Route, an ICMP error
	is sent to the Root with a new Code "Error in Projected Route" (See		is sent to the Root with a new Code "Error in Projected Route" (See
	Section 8.9). The Root can then modify or remove the Projected		Section 8.9). The Root can then modify or remove the Projected
	Route. The "Error in Projected Route" message has the same format as		Route. The "Error in Projected Route" message has the same format as
	the "Destination Unreachable Message", as specified in RFC 4443		the "Destination Unreachable Message", as specified in RFC 4443
	[RFC4443]. The portion of the invoking packet that is sent back in		[RFC4443]. The portion of the invoking packet that is sent back in
	the ICMP message SHOULD record at least up to the routing header if		the ICMP message SHOULD record at least up to the routing header if
	one is present, and the routing header SHOULD be consumed by this		one is present, and the routing header SHOULD be consumed by this
	node so that the destination in the IPv6 header is the next hop that		node so that the destination in the IPv6 header is the next hop that
	this node could not reach. if a 6LoWPAN Routing Header (6LoRH)		this node could not reach. if a 6LoWPAN Routing Header (6LoRH)
	[RFC8138] is used to carry the IPv6 routing information in the outter		[RFC8138] is used to carry the IPv6 routing information in the outter
	header then that whole 6LoRH information SHOULD be present in the		header then that whole 6LoRH information SHOULD be present in the
	ICMP message. The sender and exact operation depend on the Mode and		ICMP message. The sender and exact operation depend on the Mode and
	is described in Section 6.1 and Section 6.2 respectively.		is described in Section 6.3 and Section 6.4 respectively.
	6.1. Non-Storing Mode Projected Route		6.1. Requesting a Track
			A Node is free to ask the Root for a new Track with a PDR message,
			for a duration indicated in a Requested Lifetime field. Upon that
			Request, the Root install the necessary Segments and answers with a
			PDR-ACK indicated the granted Track Lifetime. When the Track
			Lifetime returned in the PDR-ACK is close to elapse, the resquesting
			Node needs to resend a PDR using the TrackID in the PDR-ACK to get
			the lifetime of the Track prolonged, else the Track will time out and
			the Root will tear down the whole structure.
			The Segment 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 Segments. The Root may use shorter lifetimes
			for the Segments and renew them faster than the Track is, or longer
			lifetimes in which case it will need to tear down the Segments if the
			Track is not renewed.
			The Root is free to install which ever Segments it wants, and change
			them overtime, to serve the Track as needed, without notifying the
			resquesting Node. If the Track fails and cannot be reestablished,
			the Root notifies the resquesting Node asynchronously with a PDR-ACK
			with a Track Lifetime of 0, indicating that the Track has failed, and
			a PDR-ACK Status indicating the reason of the fault.
			All the Segments MUST be of a same mode, either Storing or Non-
			Storing. All the Segments MUST be created with the same TrackId and
			Target in the P-DAO.
			6.2. Routing over a Track
			Sending a packet over a Track implies the addition of a RPI to
			indicate the Track, in association with the IPv6 destination. In
			case of a Non-Storing Mode Projected Route, a Source Routing Header
			is needed as well.
			The Destination IPv6 Address of a packet that is place in a Track
			MUST be that of the Target of Track. The outer header of the packet
			MUST contain an RPI that indicates the TrackId as RPL Instance ID.
			If the Track Ingress is the originator of the packet and the Track
			Egress (i.e., the Target) is the destination of the packet, there is
			no need of an encapsulation. Else, i.e., if the Track Ingress is
			forwarding a packet into the Track, or if the the final destination
			is reached via is not the Target, but reached over the Track via the
			Track Egress, then an IP-in-IP encapsulation is needed.
			6.3. Non-Storing Mode Projected Route
	As illustrated in Figure 6, a P-DAO that carries an SRVIO enables the		As illustrated in Figure 6, a P-DAO that carries an SRVIO enables the
	Root to install a source-routed path towards a Target in any		Root to install a source-routed path towards a Target in any
	particular router; with this path information the router can add a		particular router; with this path information the router can add a
	source routed header reflecting the Projected Route to any packet for		source routed header reflecting the Projected Route to any packet for
	which the current destination either is the said Target or can be		which the current destination either is the said Target or can be
	reached via the Target.		reached via the Target.
	------+---------		------+---------
	| Internet		| Internet
	skipping to change at page 16, line 20 ¶		skipping to change at page 18, line 9 ¶
	Route does not have a connected route (a direct adjacency) to the		Route does not have a connected route (a direct adjacency) to the
	next soure routed hop and fails to locate it as a neighbor or a		next soure routed hop and fails to locate it as a neighbor or a
	neighbor of a neighbor, then it MUST ensure that it has another		neighbor of a neighbor, then it MUST ensure that it has another
	Projected Route to the next loose hop under the control of the same		Projected Route to the next loose hop under the control of the same
	route computation system, otherwise the P-DAO is rejected.		route computation system, otherwise the P-DAO is rejected.
	When forwarding a packet to a destination for which the router		When forwarding a packet to a destination for which the router
	determines that routing happens via the Target, the router inserts		determines that routing happens via the Target, the router inserts
	the source routing header in the packet to reach the Target. In		the source routing header in the packet to reach the Target. In
	order to add a source-routing header, the router encapsulates the		order to add a source-routing header, the router encapsulates the
	packet with an IP-in-IP header and a non-storing mode source routing		packet with an IP-in-IP header and a Non-Storing Mode source routing
	header (SRH) [RFC6554]. In the uncompressed form the source of the		header (SRH) [RFC6554]. In the uncompressed form the source of the
	packet would be self, the destination would be the first Via Address		packet would be self, the destination would be the first Via Address
	in the SRVIO, and the SRH would contain the list of the remaining Via		in the SRVIO, and the SRH would contain the list of the remaining Via
	Addresses and then the Target.		Addresses and then the Target.
	In the case of a loose source-routed path, there MUST be either a		In the case of a loose source-routed path, there MUST be either a
	neighbor that is adjacent to the loose next hop, on which case the		neighbor that is adjacent to the loose next hop, on which case the
	packet is forwarded to that neighbor, or a source-routed path to the		packet is forwarded to that neighbor, or a source-routed path to the
	loose next hop; in the latter case, another encapsulation takes place		loose next hop; in the latter case, another encapsulation takes place
	and the process possibly recurses; otherwise the packet is dropped.		and the process possibly recurses; otherwise the packet is dropped.
	skipping to change at page 17, line 5 ¶		skipping to change at page 18, line 37 ¶
	In case of a forwarding error along a Source Route path, the node		In case of a forwarding error along a Source Route path, the node
	that fails to forward SHOULD send an ICMP error with a code "Error in		that fails to forward SHOULD send an ICMP error with a code "Error in
	Source Routing Header" back to the source of the packet, as described		Source Routing Header" back to the source of the packet, as described
	in section 11.2.2.3. of [RPL]. Upon this message, the encapsulating		in section 11.2.2.3. of [RPL]. Upon this message, the encapsulating
	node SHOULD stop using the source route path for a period of time and		node SHOULD stop using the source route path for a period of time and
	it SHOULD send an ICMP message with a Code "Error in Projected Route"		it SHOULD send an ICMP message with a Code "Error in Projected Route"
	to the Root. Failure to follow these steps may result in packet loss		to the Root. Failure to follow these steps may result in packet loss
	and wasted resources along the source route path that is broken.		and wasted resources along the source route path that is broken.
	6.2. Storing-Mode Projected Route		6.4. Storing-Mode Projected Route
	As illustrated in Figure 7, the Storing Mode route projection is used		As illustrated in Figure 7, the Storing Mode route projection is used
	by the Root to install a routing state towards a Target in the		by the Root to install a routing state towards a Target in the
	routers along a segment between an ingress and an egress router; this		routers along a Segment between an ingress and an egress router; this
	enables the routers to forward along that segment any packet for		enables the routers to forward along that Segment any packet for
	which the next loose hop is the said Target, for Instance a loose		which the next loose hop is the said Target, for Instance a loose
	source routed packet for which the next loose hop is the Target, or a		source routed packet for which the next loose hop is the Target, or a
	packet for which the router has a routing state to the final		packet for which the router has a routing state to the final
	destination via the Target.		destination via the Target.
	------+---------		------+---------
	| Internet		| Internet
	|		|
	+-----+		+-----+
	| | Border Router		| | Border Router
	skipping to change at page 17, line 35 ¶		skipping to change at page 19, line 24 ¶
	o o o o o o o o o | ^ | Projected .		o o o o o o o o o | ^ | Projected .
	o o o o o o o o o o | | DAO | Route .		o o 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 o o o o o v | DAO v .		o o o o o o 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 From Root To Destination v		o o o o From Root To Destination v
	Figure 7: Projecting a route		Figure 7: Projecting a route
	In order to install the relevant routing state along the segment		In order to install the relevant routing state along the Segment
	between an ingress and an egress routers, the Root sends a unicast		between an ingress and an egress routers, the Root sends a unicast
	P-DAO message to the egress router of the routing segment that must		P-DAO message to the egress router of the routing Segment that must
	be installed. The P-DAO message contains the ordered list of hops		be installed. The P-DAO message contains the ordered list of hops
	along the segment as a direct sequence of Via Information options		along the Segment as a direct sequence of Via Information options
	that are preceded by one or more RPL Target options to which they		that are preceded by one or more RPL Target options to which they
	relate. Each Via Information option contains a Path Lifetime for		relate. Each Via Information option contains a Segment Lifetime for
	which the state is to be maintained.		which the state is 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 Via Address in		In that P-DAO, the destination IP address matches the Via Address in
	the last VIO. This is how the egress recognizes its role. In a		the last VIO. This is how the egress recognizes its role. In a
	similar fashion, the ingress node recognizes its role as it matches		similar fashion, the ingress node recognizes its role as it matches
	Via Address in the first VIO.		Via Address in the first 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) on its own. It may either be		already able to route to the Target(s) on its own. It may either be
	the Target, or may have some existing information to reach the		the Target, or may have some existing information to reach the
	Target(s), such as a connected route or an already installed		Target(s), such as a connected route or an already installed
	Projected Route. If one of the Targets cannot be located, the node		Projected Route. If one of the Targets cannot be located, the node
	MUST answer to the Root with a negative DAO-ACK listing the Target(s)		MUST answer to the Root with a negative DAO-ACK listing the Target(s)
	that could not be located (suggested status 10 to be confirmed by		that could not be located (suggested status 10 to be confirmed by
	IANA).		IANA).
	If the egress node can reach all the Targets, then it forwards the		If the egress node can reach all the Targets, then it forwards the
	P-DAO with unchanged content to its loose predecessor in the segment		P-DAO with unchanged content to its loose predecessor in the Segment
	as indicated in the list of Via Information options, and recursively		as indicated in the list of Via Information options, and recursively
	the message is propagated unchanged along the sequence of routers		the message is propagated unchanged along the sequence of routers
	indicated in the P-DAO, but in the reverse order, from egress to		indicated in the P-DAO, but in the reverse order, from egress to
	ingress.		ingress.
	The address of the predecessor to be used as destination of the		The address of the predecessor to be used as destination of the
	propagated DAO message is found in the Via Information option the		propagated DAO message is found in the Via Information option the
	precedes the one that contain the address of the propagating node,		precedes the one that contain the address of the propagating node,
	which is used as source of the packet.		which is used as source of the packet.
	Upon receiving a propagated DAO, an intermediate router as well as		Upon receiving a propagated DAO, an intermediate router as well as
	the ingress router install a route towards the DAO Target(s) via its		the ingress router install a route towards the DAO Target(s) via its
	successor in the P-DAO; the router locates the VIO that contains its		successor in the P-DAO; the router locates the VIO that contains its
	address, and uses as next hop the address found in the Via Address		address, and uses as next hop the address found in the Via Address
	field in the following VIO. The router MAY install additional routes		field in the following VIO. The router MAY install additional routes
	towards the addresses that are located in VIOs that are after the		towards the addresses that are located in VIOs that are after the
	next one, if any, but in case of a conflict or a lack of resource, a		next one, if any, but in case of a conflict or a lack of resource, a
	route to a Target installed by the Root has precedence.		route to a Target installed by the Root has precedence.
	The process recurses till the P-DAO is propagated to ingress router		The process recurses till the P-DAO is propagated to ingress router
	of the segment, which answers with a DAO-ACK to the Root.		of the Segment, which answers with a DAO-ACK to the Root.
	Also, the path indicated in a P-DAO may be loose, in which case the		Also, the path indicated in a P-DAO may be loose, in which case the
	reachability to the next hop has to be asserted. Each router along		reachability to the next hop has to be asserted. Each router along
	the path indicated in a P-DAO is expected to be able to reach its		the path indicated in a P-DAO is expected to be able to reach its
	successor, either with a connected route (direct neighbor), or by		successor, either with a connected route (direct neighbor), or by
	routing, for Instance following a route installed previously by a DAO		routing, for Instance following a route installed previously by a DAO
	or a P-DAO message. If that route is not connected then a recursive		or a P-DAO message. If that route is not connected then a recursive
	lookup may take place at packet forwarding time to find the next hop		lookup may take place at packet forwarding time to find the next hop
	to reach the Target(s). If it does not and cannot reach the next		to reach the Target(s). If it does not and cannot reach the next
	router in the P-DAO, the router MUST answer to the Root with a		router in the P-DAO, the router MUST answer to the Root with a
	negative DAO-ACK indicating the successor that is unreachable		negative DAO-ACK indicating the successor that is unreachable
	(suggested status 11 to be confirmed by IANA).		(suggested status 11 to be confirmed by IANA).
	A Path Lifetime of 0 in a Via Information option is used to clean up		A Segment Lifetime of 0 in a Via Information option is used to clean
	the state. The P-DAO is forwarded as described above, but the DAO is		up the state. The P-DAO is forwarded as described above, but the DAO
	interpreted as a No-Path DAO and results in cleaning up existing		is interpreted as a No-Path DAO and results in cleaning up existing
	state as opposed to refreshing an existing one or installing a new		state as opposed to refreshing an existing one or installing a new
	one.		one.
	In case of a forwarding error along a Storing Mode Projected Route,		In case of a forwarding error along a Storing Mode Projected Route,
	the node that fails to forward SHOULD send an ICMP error with a code		the node that fails to forward SHOULD send an ICMP error with a code
	"Error in Projected Route" to the Root. Failure to do so may result		"Error in Projected Route" to the Root. Failure to do so may result
	in packet loss and wasted resources along the Projected Route that is		in packet loss and wasted resources along the Projected Route that is
	broken.		broken.
	7. Security Considerations		7. Security Considerations
	skipping to change at page 20, line 17 ¶		skipping to change at page 22, line 5 ¶
	+=======+======================================+===============+		+=======+======================================+===============+
	| 0x0B | Via Information option | This document |		| 0x0B | Via Information option | This document |
	+-------+--------------------------------------+---------------+		+-------+--------------------------------------+---------------+
	| 0x0C | Source-Routed Via Information option | This document |		| 0x0C | Source-Routed Via Information option | This document |
	+-------+--------------------------------------+---------------+		+-------+--------------------------------------+---------------+
	| 0x0D | Sibling Information option | This document |		| 0x0D | Sibling Information option | This document |
	+-------+--------------------------------------+---------------+		+-------+--------------------------------------+---------------+
	Table 2: RPL Control Message Options		Table 2: RPL Control Message Options
	8.3. New SubRegistry for the Projected DAO Request (PDR) Flags		8.3. SubRegistry for the Projected DAO Request Flags
	IANA is required to create a registry for the 8-bit Projected DAO		IANA is required to create a registry for the 8-bit Projected DAO
	Request (PDR) Flags field. Each bit is tracked with the following		Request (PDR) Flags field. Each bit is tracked with the following
	qualities:		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
	skipping to change at page 20, line 43 ¶		skipping to change at page 22, line 31 ¶
	| Bit number | Capability description | Reference |		| Bit number | Capability description | Reference |
	+============+========================+===============+		+============+========================+===============+
	| 0 | PDR-ACK request (K) | This document |		| 0 | PDR-ACK request (K) | This document |
	+------------+------------------------+---------------+		+------------+------------------------+---------------+
	| 1 | Requested path should | This document |		| 1 | Requested path should | This document |
	| | be redundant (R) | |		| | be redundant (R) | |
	+------------+------------------------+---------------+		+------------+------------------------+---------------+
	Table 3: Initial PDR Flags		Table 3: Initial PDR Flags
	8.4. New SubRegistry for the PDR-ACK Flags		8.4. SubRegistry for the PDR-ACK Flags
	IANA is required to create an subregistry for the 8-bit PDR-ACK Flags		IANA is required to create an subregistry for the 8-bit PDR-ACK Flags
	field. Each bit is tracked with the following qualities:		field. 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
	Registration procedure is "Standards Action" [RFC8126]. No bit is		Registration procedure is "Standards Action" [RFC8126]. No bit is
	currently defined for the PDR-ACK Flags.		currently defined for the PDR-ACK Flags.
	8.5. New Subregistry for the PDR-ACK Acceptance Status values		8.5. Subregistry for the PDR-ACK Acceptance Status Values
	IANA is requested to create a new subregistry for the PDR-ACK		IANA is requested to create a Subregistry for the PDR-ACK Acceptance
	Acceptance Status values.		Status values.
	* Possible values are 6-bit unsigned integers (0..63).		* Possible values are 6-bit unsigned integers (0..63).
	* Registration procedure is "Standards Action" [RFC8126].		* Registration procedure is "Standards Action" [RFC8126].
	* Initial allocation is as indicated in Table 4:		* Initial allocation is as indicated in Table 4:
	+-------+------------------------+---------------+		+-------+------------------------+---------------+
	| Value | Meaning | Reference |		| Value | Meaning | Reference |
	+-------+------------------------+---------------+		+-------+------------------------+---------------+
	| 0 | Unqualified acceptance | This document |		| 0 | Unqualified acceptance | This document |
	+-------+------------------------+---------------+		+-------+------------------------+---------------+
	Table 4: Acceptance values of the PDR-ACK Status		Table 4: Acceptance values of the PDR-ACK Status
	8.6. New Subregistry for the PDR-ACK Rejection Status values		8.6. Subregistry for the PDR-ACK Rejection Status Values
	IANA is requested to create a new subregistry for the PDR-ACK		IANA is requested to create a Subregistry for the PDR-ACK Rejection
	Rejection Status values.		Status values.
	* Possible values are 6-bit unsigned integers (0..63).		* Possible values are 6-bit unsigned integers (0..63).
	* Registration procedure is "Standards Action" [RFC8126].		* Registration procedure is "Standards Action" [RFC8126].
	* Initial allocation is as indicated in Table 5:		* Initial allocation is as indicated in Table 5:
	+-------+-----------------------+---------------+		+-------+-----------------------+---------------+
	| Value | Meaning | Reference |		| Value | Meaning | Reference |
	+-------+-----------------------+---------------+		+-------+-----------------------+---------------+
	| 0 | Unqualified rejection | This document |		| 0 | Unqualified rejection | This document |
	+-------+-----------------------+---------------+		+-------+-----------------------+---------------+
	Table 5: Rejection values of the PDR-ACK Status		Table 5: Rejection values of the PDR-ACK Status
	8.7. New SubRegistry for the Route Projection Options (RPO) Flags		8.7. SubRegistry for the Route Projection Options Flags
	IANA is requested to create a new subregistry for the 5-bit Route		IANA is requested to create a Subregistry for the 5-bit Route
	Projection Options (RPO) Flags field. Each bit is tracked with the		Projection Options (RPO) Flags field. Each bit is tracked with the
	following qualities:		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
	Registration procedure is "Standards Action" [RFC8126]. No bit is		Registration procedure is "Standards Action" [RFC8126]. No bit is
	currently defined for the Route Projection Options (RPO) Flags.		currently defined for the Route Projection Options (RPO) Flags.
	8.8. New SubRegistry for the Sibling Information Option (SIO) Flags		8.8. SubRegistry for the Sibling Information Option Flags
	IANA is required to create a registry for the 5-bit Sibling		IANA is required to create a registry for the 5-bit Sibling
	Information Option (SIO) Flags field. Each bit is tracked with the		Information Option (SIO) Flags field. Each bit is tracked with the
	following qualities:		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
	skipping to change at page 24, line 8 ¶		skipping to change at page 25, line 48 ¶
	[RFC6997] Goyal, M., Ed., Baccelli, E., Philipp, M., Brandt, A., and		[RFC6997] Goyal, M., Ed., Baccelli, E., Philipp, M., Brandt, A., and
	J. Martocci, "Reactive Discovery of Point-to-Point Routes		J. Martocci, "Reactive Discovery of Point-to-Point Routes
	in Low-Power and Lossy Networks", RFC 6997,		in Low-Power and Lossy Networks", RFC 6997,
	DOI 10.17487/RFC6997, August 2013,		DOI 10.17487/RFC6997, August 2013,
	<https://www.rfc-editor.org/info/rfc6997>.		<https://www.rfc-editor.org/info/rfc6997>.
	[6TiSCH-ARCHI]		[6TiSCH-ARCHI]
	Thubert, P., "An Architecture for IPv6 over the TSCH mode		Thubert, P., "An Architecture for IPv6 over the TSCH mode
	of IEEE 802.15.4", Work in Progress, Internet-Draft,		of IEEE 802.15.4", Work in Progress, Internet-Draft,
	draft-ietf-6tisch-architecture-29, August 27, 2020,		draft-ietf-6tisch-architecture-29, 27 August 2020,
	<https://tools.ietf.org/html/draft-ietf-6tisch-		<https://tools.ietf.org/html/draft-ietf-6tisch-
	architecture-29>.		architecture-29>.
	[RAW-ARCHI]		[RAW-ARCHI]
	Thubert, P., Papadopoulos, G., and R. Buddenberg,		Thubert, P., Papadopoulos, G., and R. Buddenberg,
	"Reliable and Available Wireless Architecture/Framework",		"Reliable and Available Wireless Architecture/Framework",
	Work in Progress, Internet-Draft, draft-pthubert-raw-		Work in Progress, Internet-Draft, draft-pthubert-raw-
	architecture-04, July 6, 2020,		architecture-04, 6 July 2020,
	<https://tools.ietf.org/html/draft-pthubert-raw-		<https://tools.ietf.org/html/draft-pthubert-raw-
	architecture-04>.		architecture-04>.
	[TURN-ON_RFC8138]		[TURN-ON_RFC8138]
	Thubert, P. and L. Zhao, "Configuration option for RFC		Thubert, P. and L. Zhao, "Configuration option for RFC
	8138", Work in Progress, Internet-Draft, draft-thubert-		8138", Work in Progress, Internet-Draft, draft-thubert-
	roll-turnon-rfc8138-03, July 8, 2019,		roll-turnon-rfc8138-03, 8 July 2019,
	<https://tools.ietf.org/html/draft-thubert-roll-turnon-		<https://tools.ietf.org/html/draft-thubert-roll-turnon-
	rfc8138-03>.		rfc8138-03>.
	[RFC8655] Finn, N., Thubert, P., Varga, B., and J. Farkas,		[RFC8655] Finn, N., Thubert, P., Varga, B., and J. Farkas,
	"Deterministic Networking Architecture", RFC 8655,		"Deterministic Networking Architecture", RFC 8655,
	DOI 10.17487/RFC8655, October 2019,		DOI 10.17487/RFC8655, October 2019,
	<https://www.rfc-editor.org/info/rfc8655>.		<https://www.rfc-editor.org/info/rfc8655>.
	[RFC8025] Thubert, P., Ed. and R. Cragie, "IPv6 over Low-Power		[RFC8025] Thubert, P., Ed. and R. Cragie, "IPv6 over Low-Power
	Wireless Personal Area Network (6LoWPAN) Paging Dispatch",		Wireless Personal Area Network (6LoWPAN) Paging Dispatch",
	RFC 8025, DOI 10.17487/RFC8025, November 2016,		RFC 8025, DOI 10.17487/RFC8025, November 2016,
	<https://www.rfc-editor.org/info/rfc8025>.		<https://www.rfc-editor.org/info/rfc8025>.
	[RFC8138] Thubert, P., Ed., Bormann, C., Toutain, L., and R. Cragie,		[RFC8138] Thubert, P., Ed., Bormann, C., Toutain, L., and R. Cragie,
	"IPv6 over Low-Power Wireless Personal Area Network		"IPv6 over Low-Power Wireless Personal Area Network
	(6LoWPAN) Routing Header", RFC 8138, DOI 10.17487/RFC8138,		(6LoWPAN) Routing Header", RFC 8138, DOI 10.17487/RFC8138,
	April 2017, <https://www.rfc-editor.org/info/rfc8138>.		April 2017, <https://www.rfc-editor.org/info/rfc8138>.
			[USEofRPLinfo]
			Robles, I., Richardson, M., and P. Thubert, "Using RPI
			Option Type, Routing Header for Source Routes and IPv6-in-
			IPv6 encapsulation in the RPL Data Plane", Work in
			Progress, Internet-Draft, draft-ietf-roll-useofrplinfo-40,
			25 June 2020, <https://tools.ietf.org/html/draft-ietf-
			roll-useofrplinfo-40>.
	[PCE] IETF, "Path Computation Element",		[PCE] IETF, "Path Computation Element",
	<https://datatracker.ietf.org/doc/charter-ietf-pce/>.		<https://datatracker.ietf.org/doc/charter-ietf-pce/>.
	Appendix A. Applications		Appendix A. Applications
	A.1. Loose Source Routing in Non-storing Mode		A.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 8.		uses the Non-Storing Mode of Operation as represented in Figure 8.
	In that mode, a RPL node indicates a parent-child relationship to the		In that mode, a RPL node indicates a parent-child relationship to the
	Root, using a Destination Advertisement Object (DAO) that is unicast		Root, using a Destination Advertisement Object (DAO) that is unicast
	from the node directly to the Root, and the Root typically builds a		from the node directly to the Root, and the Root typically builds a
	source routed path to a destination down the DODAG by recursively		source routed path to a destination down the DODAG by recursively
	concatenating this information.		concatenating this information.
	------+---------		------+---------
	skipping to change at page 25, line 30 ¶		skipping to change at page 27, line 30 ¶
	+-----+ ^ | |		+-----+ ^ | |
	| | 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 | | |
	o o o o o o o o | v v		o o o o o o o o | v v
	o o o o		o o o o
	LLN		LLN
	Figure 8: RPL non-storing mode of operation		Figure 8: RPL Non-Storing Mode of operation
	Based on the parent-children relationships expressed in the non-		Based on the parent-children relationships expressed in the non-
	storing DAO messages,the Root possesses topological information about		storing DAO messages,the Root possesses topological information about
	the whole network, though this information is limited to the		the whole network, though this information is limited to the
	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 a source routing information to reach the destination		can then apply a source routing information to reach the destination
	if the destination is also in the DODAG. Similarly, a packet coming		if 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.		be in a RPL domain reaches the Root.
	skipping to change at page 26, line 19 ¶		skipping to change at page 28, line 19 ¶
	would allow to make the source routing operation loose as opposed to		would allow to make the source routing operation loose as opposed to
	strict, and save packet size. Limiting the packet size is directly		strict, and save packet size. Limiting the packet size is directly
	beneficial to the energy budget, but, mostly, it reduces the chances		beneficial to the energy budget, but, mostly, it reduces the chances
	of frame loss and/or packet fragmentation, which is highly		of frame loss and/or packet fragmentation, which is highly
	detrimental to the LLN operation. Because the capability to store a		detrimental to the LLN operation. Because the capability to store a
	routing state in every node is limited, the decision of which route		routing state in every node is limited, the decision of which route
	is installed where can only be optimized with a global knowledge of		is installed where can only be optimized with a global knowledge of
	the system, a knowledge that the Root or an associated PCE may		the system, a knowledge that the Root or an associated PCE may
	possess by means that are outside of the scope of this specification.		possess by means that are outside of the scope of this specification.
	This specification enables to store source-routed or storing mode		This specification enables to store source-routed or Storing Mode
	state in intermediate routers, which enables to limit the excursion		state in intermediate routers, which enables to limit the excursion
	of the source route headers in deep networks. Once a P-DAO exchange		of the source route headers in deep networks. Once a P-DAO exchange
	has taken place for a given Target, if the Root operates in non		has taken place for a given Target, if the Root operates in non
	storing mode, then it may elide the sequence of routers that is		Storing Mode, then it may elide the sequence of routers that is
	installed in the network from its source route headers to destination		installed in the network from its source route headers to destination
	that are reachable via that Target, and the source route headers		that are reachable via that Target, and the source route headers
	effectively become loose.		effectively become loose.
	A.2. Transversal Routes in storing and non-storing modes		A.2. Transversal Routes
	RPL is optimized for Point-to-Multipoint (P2MP) and Multipoint-to-		RPL is optimized for Point-to-Multipoint (P2MP) and Multipoint-to-
	Point (MP2P), whereby routes are always installed along the RPL DODAG		Point (MP2P), whereby routes are always installed along the RPL DODAG
	respectively from and towards the DODAG Root. Transversal Peer to		respectively from and towards the DODAG Root. Transversal Peer to
	Peer (P2P) routes in a RPL network will generally suffer from some		Peer (P2P) routes in a RPL network will generally suffer from some
	elongated (stretched) path versus the best possible path, since		elongated (stretched) path versus the best possible path, since
	routing between 2 nodes always happens via a common parent, as		routing between 2 nodes always happens via a common parent, as
	illustrated in Figure 9:		illustrated in Figure 9:
	* in non-storing mode, all packets routed within the DODAG flow all		* In Storing Mode, unless the destination is a child of the source,
	the way up to the Root of the DODAG. If the destination is in the
	same DODAG, the Root must encapsulate the packet to place a
	Routing Header that has the strict source route information down
	the DODAG to the destination. This will be the case even if the
	destination is relatively close to the source and the Root is
	relatively far off.
	* In storing mode, unless the destination is a child of the source,
	the packets will follow the default route up the DODAG as well.		the packets will follow the default route up the DODAG as well.
	If the destination is in the same DODAG, they will eventually		If the destination is in the same DODAG, they will eventually
	reach a common parent that has a route to the destination; at		reach a common parent that has a route to the destination; at
	worse, the common parent may also be the Root. From that common		worse, the common parent may also be the Root. From that common
	parent, the packet will follow a path down the DODAG that is		parent, the packet will follow a path down the DODAG that is
	optimized for the Objective Function that was used to build the		optimized for the Objective Function that was used to build the
	DODAG.		DODAG.
			* in Non-Storing Mode, all packets routed within the DODAG flow all
			the way up to the Root of the DODAG. If the destination is in the
			same DODAG, the Root must encapsulate the packet to place a
			Routing Header that has the strict source route information down
			the DODAG to the destination. This will be the case even if the
			destination is relatively close to the source and the Root is
			relatively far off.
	------+---------		------+---------
	| Internet		| Internet
	|		|
	+-----+		+-----+
	| | Border Router		| | Border Router
	| | (RPL Root)		| | (RPL Root)
	+-----+		+-----+
	X		X
	^ v o o		^ v o o
	^ o o v o o o o o		^ o o v o o o o o
	^ o o o v o o o o o		^ o o o v o o o o o
	^ o o v o o o o o		^ o o v o o o o o
	S o o o D o o o		S o o o D o o o
	o o o o		o o o o
	LLN		LLN
	Figure 9: Routing Stretch between S and D via common parent X		Figure 9: Routing Stretch between S and D via common parent X
	It results that it is often beneficial to enable transversal P2P		It results that it is often beneficial to enable transversal P2P
	routes, either if the RPL route presents a stretch from shortest		routes, either if the RPL route presents a stretch from shortest
	path, or if the new route is engineered with a different objective.		path, or if the new route is engineered with a different objective,
	For that reason, earlier work at the IETF introduced the "Reactive		and that it is even more critical in Non-Storing Mode than it is in
	Discovery of Point-to-Point Routes in Low Power and Lossy Networks"		Storing Mode, because the routing stretch is wider. For that reason,
	[RFC6997], which specifies a distributed method for establishing		earlier work at the IETF introduced the "Reactive Discovery of
	optimized P2P routes. This draft proposes an alternate based on a		Point-to-Point Routes in Low Power and Lossy Networks" [RFC6997],
	centralized route computation.		which specifies a distributed method for establishing optimized P2P
			routes. This draft proposes an alternate based on a centralized
			route computation.
	------+---------		------+---------
	| Internet		| Internet
	|		|
	+-----+		+-----+
	| | Border Router		| | Border Router
	| | (RPL Root)		| | (RPL Root)
	+-----+		+-----+
	|		|
	o o o o		o o o o
	o o o o o o o o o		o o o o o o o o o
	o o o o o o o o o o		o o o o o o o o o o
	o o o o o o o o o		o o o o o o o o o
	S>>A>>>B>>C>>>D o o o		S>>A>>>B>>C>>>D o o o
	o o o o		o o o o
	LLN		LLN
	Figure 10: Projected Transversal Route		Figure 10: Projected Transversal Route
	This specification enables to store source-routed or storing mode		This specification enables to store source-routed or Storing Mode
	state in intermediate routers, which enables to limit the stretch of		state in intermediate routers, which enables to limit the stretch of
	a P2P route and maintain the characteristics within a given SLA. An		a P2P route and maintain the characteristics within a given SLA. An
	example of service using this mechanism oculd be a control loop that		example of service using this mechanism oculd be a control loop that
	would be installed in a network that uses classical RPL for		would be installed in a network that uses classical RPL for
	asynchronous data collection. In that case, the P2P path may be		asynchronous data collection. In that case, the P2P path may be
	installed in a different RPL Instance, with a different objective		installed in a different RPL Instance, with a different objective
	function.		function.
	Appendix B. Examples		Appendix B. Examples
	B.1. Using storing mode P-DAO in non-storing mode MOP		B.1. Using Storing Mode P-DAO in Non-Storing Mode MOP
	In non-storing mode, the DAG Root maintains the knowledge of the		In Non-Storing Mode, the DAG Root maintains the knowledge of the
	whole DODAG topology, so when both the source and the destination of		whole DODAG topology, so when both the source and the destination of
	a packet are in the DODAG, the Root can determine the common parent		a packet are in the DODAG, the Root can determine the common parent
	that would have been used in storing mode, and thus the list of nodes		that would have been used in Storing Mode, and thus the list of nodes
	in the path between the common parent and the destination. For		in the path between the common parent and the destination. For
	Instance in the diagram shown in Figure 11, if the source is node 41		Instance in the diagram shown in Figure 11, if the source is node 41
	and the destination is node 52, then the common parent is node 22.		and the destination is node 52, then the common parent is node 22.
	------+---------		------+---------
	| Internet		| Internet
	|		|
	+-----+		+-----+
	| | Border Router		| | Border Router
	| | (RPL Root)		| | (RPL Root)
	skipping to change at page 29, line 28 ¶		skipping to change at page 31, line 28 ¶
	o 31 o 32 o o o 35		o 31 o 32 o o o 35
	/ / | \ | \		/ / | \ | \
	o 41 o 42 o o o 45 o 46		o 41 o 42 o o o 45 o 46
	| | | | \ |		| | | | \ |
	o 51 o 52 o 53 o o 55 o 56		o 51 o 52 o 53 o o 55 o 56
	LLN		LLN
	Figure 11: Example DODAG forming a logical tree topology		Figure 11: Example DODAG forming a logical tree topology
	With this draft, the Root can install a storing mode routing states		With this draft, the Root can install a Storing Mode routing states
	along a segment that is either from itself to the destination, or		along a Segment that is either from itself to the destination, or
	from one or more common parents for a particular source/destination		from one or more common parents for a particular source/destination
	pair towards that destination (in this particular example, this would		pair towards that destination (in this particular example, this would
	be the segment made of nodes 22, 32, 42).		be the Segment made of nodes 22, 32, 42).
	In the example below, say that there is a lot of traffic to nodes 55		In the example below, say that there is a lot of traffic to nodes 55
	and 56 and the Root decides to reduce the size of routing headers to		and 56 and the Root decides to reduce the size of routing headers to
	those destinations. The Root can first send a DAO to node 45		those destinations. The Root can first send a DAO to node 45
	indicating Target 55 and a Via segment (35, 45), as well as another		indicating Target 55 and a Via Segment (35, 45), as well as another
	DAO to node 46 indicating Target 56 and a Via segment (35, 46). This		DAO to node 46 indicating Target 56 and a Via Segment (35, 46). This
	will save one entry in the routing header on both sides. The Root		will save one entry in the routing header on both sides. The Root
	may then send a DAO to node 35 indicating Targets 55 and 56 a Via		may then send a DAO to node 35 indicating Targets 55 and 56 a Via
	segment (13, 24, 35) to fully optimize that path.		Segment (13, 24, 35) to fully optimize that path.
	Alternatively, the Root may send a DAO to node 45 indicating Target		Alternatively, the Root may send a DAO to node 45 indicating Target
	55 and a Via segment (13, 24, 35, 45) and then a DAO to node 46		55 and a Via Segment (13, 24, 35, 45) and then a DAO to node 46
	indicating Target 56 and a Via segment (13, 24, 35, 46), indicating		indicating Target 56 and a Via Segment (13, 24, 35, 46), indicating
	the same DAO Sequence.		the same DAO Sequence.
	B.2. Projecting a storing-mode transversal route		B.2. Projecting a storing-mode transversal route
	In this example, say that a PCE determines that a path must be		In this example, say that a PCE determines that a path must be
	installed between node S and node D via routers A, B and C, in order		installed between node S and node D via routers A, B and C, in order
	to serve the needs of a particular application.		to serve the needs of a particular application.
	The Root sends a P-DAO with a Target option indicating the		The Root sends a P-DAO with a Target option indicating the
	destination D and a sequence Via Information option, one for S, which		destination D and a sequence Via Information option, one for S, which
	is the ingress router of the segment, one for A and then for B, which		is the ingress router of the Segment, one for A and then for B, which
	are an intermediate routers, and one for C, which is the egress		are an intermediate routers, and one for C, which is the egress
	router.		router.
	------+---------		------+---------
	| Internet		| Internet
	|		|
	+-----+		+-----+
	| | Border Router		| | Border Router
	| | (RPL Root)		| | (RPL Root)
	+-----+		+-----+
	skipping to change at page 30, line 37 ¶		skipping to change at page 32, line 37 ¶
	Figure 12: P-DAO from Root		Figure 12: P-DAO from Root
	Upon reception of the P-DAO, C validates that it can reach D, e.g.		Upon reception of the P-DAO, C validates that it can reach D, e.g.
	using IPv6 Neighbor Discovery, and if so, propagates the P-DAO		using IPv6 Neighbor Discovery, and if so, propagates the P-DAO
	unchanged to B.		unchanged to B.
	B checks that it can reach C and of so, installs a route towards D		B checks that it can reach C and of so, installs a route towards D
	via C. Then it propagates the P-DAO to A.		via C. Then it propagates the P-DAO to A.
	The process recurses till the P-DAO reaches S, the ingress of the		The process recurses till the P-DAO reaches S, the ingress of the
	segment, which installs a route to D via A and sends a DAO-ACK to the		Segment, which installs a route to D via A and sends a DAO-ACK to the
	Root.		Root.
	------+---------		------+---------
	| Internet		| Internet
	|		|
	+-----+		+-----+
	| | Border Router		| | Border Router
	| | (RPL Root)		| | (RPL Root)
	+-----+		+-----+
	^ P-DAO-ACK from S		^ P-DAO-ACK from S
End of changes. 109 change blocks.
	259 lines changed or deleted		342 lines changed or added
This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/