< draft-ietf-roll-dao-projection-16.txt		draft-ietf-roll-dao-projection-17.txt >
	ROLL P. Thubert, Ed.		ROLL P. Thubert, Ed.
	Internet-Draft Cisco Systems		Internet-Draft Cisco Systems
	Updates: 6554 (if approved) R.A. Jadhav		Updates: 6554 (if approved) R.A. Jadhav
	Intended status: Standards Track Huawei Tech		Intended status: Standards Track Huawei Tech
	Expires: 19 July 2021 M. Gillmore		Expires: 5 December 2021 M. Gillmore
	Itron		Itron
	15 January 2021		3 June 2021
	Root initiated routing state in RPL		Root initiated routing state in RPL
	draft-ietf-roll-dao-projection-16		draft-ietf-roll-dao-projection-17
	Abstract		Abstract
	This document extends RFC 6550 and RFC 6553 to enable a RPL Root to		This document extends RFC 6550 and RFC 6553 to enable a RPL Root to
	install and maintain Projected Routes within its DODAG, along a		install and maintain Projected Routes within its DODAG, along a
	selected set of nodes that may or may not include self, for a chosen		selected set of nodes that may or may not include self, for a chosen
	duration. This potentially enables routes that are more optimized or		duration. This potentially enables routes that are more optimized or
	resilient than those obtained with the classical distributed		resilient than those obtained with the classical distributed
	operation of RPL, either in terms of the size of a Routing Header or		operation of RPL, either in terms of the size of a Routing Header or
	in terms of path length, which impacts both the latency and the		in terms of path length, which impacts both the latency and the
	skipping to change at page 1, line 40 ¶		skipping to change at page 1, line 40 ¶
	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 19 July 2021.		This Internet-Draft will expire on 5 December 2021.
	Copyright Notice		Copyright Notice
	Copyright (c) 2021 IETF Trust and the persons identified as the		Copyright (c) 2021 IETF Trust and the persons identified as the
	document authors. All rights reserved.		document authors. All rights reserved.
	This document is subject to BCP 78 and the IETF Trust's Legal		This document is subject to BCP 78 and the IETF Trust's Legal
	Provisions Relating to IETF Documents (https://trustee.ietf.org/		Provisions Relating to IETF Documents (https://trustee.ietf.org/
	license-info) in effect on the date of publication of this document.		license-info) in effect on the date of publication of this document.
	skipping to change at page 2, line 27 ¶		skipping to change at page 2, line 27 ¶
	2.3. Other Terms . . . . . . . . . . . . . . . . . . . . . . . 6		2.3. Other Terms . . . . . . . . . . . . . . . . . . . . . . . 6
	2.4. References . . . . . . . . . . . . . . . . . . . . . . . 6		2.4. References . . . . . . . . . . . . . . . . . . . . . . . 6
	3. Extending RFC 6550 . . . . . . . . . . . . . . . . . . . . . 6		3. Extending RFC 6550 . . . . . . . . . . . . . . . . . . . . . 6
	3.1. Projected DAO . . . . . . . . . . . . . . . . . . . . . . 6		3.1. Projected DAO . . . . . . . . . . . . . . . . . . . . . . 6
	3.2. Sibling Information Option . . . . . . . . . . . . . . . 8		3.2. Sibling Information Option . . . . . . . . . . . . . . . 8
	3.3. P-DAO Request . . . . . . . . . . . . . . . . . . . . . . 8		3.3. P-DAO Request . . . . . . . . . . . . . . . . . . . . . . 8
	3.4. Extending the RPI . . . . . . . . . . . . . . . . . . . . 9		3.4. Extending the RPI . . . . . . . . . . . . . . . . . . . . 9
	4. Extending RFC 6553 . . . . . . . . . . . . . . . . . . . . . 9		4. Extending RFC 6553 . . . . . . . . . . . . . . . . . . . . . 9
	5. Extending RFC 8138 . . . . . . . . . . . . . . . . . . . . . 10		5. Extending RFC 8138 . . . . . . . . . . . . . . . . . . . . . 10
	6. New RPL Control Messages and Options . . . . . . . . . . . . 10		6. New RPL Control Messages and Options . . . . . . . . . . . . 10
	6.1. New P-DAO Request Control Message . . . . . . . . . . . . 10		6.1. New P-DAO Request Control Message . . . . . . . . . . . . 11
	6.2. New PDR-ACK Control Message . . . . . . . . . . . . . . . 11		6.2. New PDR-ACK Control Message . . . . . . . . . . . . . . . 12
	6.3. Via Information Options . . . . . . . . . . . . . . . . . 13		6.3. Via Information Options . . . . . . . . . . . . . . . . . 13
	6.4. Sibling Information Option . . . . . . . . . . . . . . . 15		6.4. Sibling Information Option . . . . . . . . . . . . . . . 15
	7. Projected DAO . . . . . . . . . . . . . . . . . . . . . . . . 17		7. Projected DAO . . . . . . . . . . . . . . . . . . . . . . . . 17
	7.1. Requesting a Track . . . . . . . . . . . . . . . . . . . 18		7.1. Requesting a Track . . . . . . . . . . . . . . . . . . . 19
	7.2. Identifying a Track . . . . . . . . . . . . . . . . . . . 19		7.2. Identifying a Track . . . . . . . . . . . . . . . . . . . 19
	7.3. Installing a Track . . . . . . . . . . . . . . . . . . . 20		7.3. Installing a Track . . . . . . . . . . . . . . . . . . . 21
	7.3.1. Storing-Mode P-Route . . . . . . . . . . . . . . . . 21		7.3.1. Storing-Mode P-Route . . . . . . . . . . . . . . . . 22
	7.3.2. Non-Storing-Mode P-Route . . . . . . . . . . . . . . 23		7.3.2. Non-Storing-Mode P-Route . . . . . . . . . . . . . . 24
	7.4. Forwarding Along a Track . . . . . . . . . . . . . . . . 24		7.4. Forwarding Along a Track . . . . . . . . . . . . . . . . 25
	8. Profiles . . . . . . . . . . . . . . . . . . . . . . . . . . 25		8. Profiles . . . . . . . . . . . . . . . . . . . . . . . . . . 26
	9. Example Track Signaling . . . . . . . . . . . . . . . . . . . 26		9. Example Track Signaling . . . . . . . . . . . . . . . . . . . 27
	9.1. Using Storing-Mode Segments . . . . . . . . . . . . . . . 27		9.1. Using Storing-Mode Segments . . . . . . . . . . . . . . . 28
	9.1.1. Stitched Segments . . . . . . . . . . . . . . . . . . 27		9.1.1. Stitched Segments . . . . . . . . . . . . . . . . . . 28
	9.1.2. External routes . . . . . . . . . . . . . . . . . . . 29		9.1.2. External routes . . . . . . . . . . . . . . . . . . . 30
	9.1.3. Segment Routing . . . . . . . . . . . . . . . . . . . 30		9.1.3. Segment Routing . . . . . . . . . . . . . . . . . . . 31
	9.2. Using Non-Storing-Mode joining Tracks . . . . . . . . . . 32		9.2. Using Non-Storing-Mode joining Tracks . . . . . . . . . . 33
	9.2.1. Stitched Tracks . . . . . . . . . . . . . . . . . . . 32		9.2.1. Stitched Tracks . . . . . . . . . . . . . . . . . . . 33
	9.2.2. External routes . . . . . . . . . . . . . . . . . . . 34		9.2.2. External routes . . . . . . . . . . . . . . . . . . . 35
	9.2.3. Segment Routing . . . . . . . . . . . . . . . . . . . 36		9.2.3. Segment Routing . . . . . . . . . . . . . . . . . . . 37
	10. Security Considerations . . . . . . . . . . . . . . . . . . . 39		10. Security Considerations . . . . . . . . . . . . . . . . . . . 40
	11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 39		11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 40
	11.1. New Elective 6LoWPAN Routing Header Type . . . . . . . . 39		11.1. New Elective 6LoWPAN Routing Header Type . . . . . . . . 40
	11.2. New Critical 6LoWPAN Routing Header Type . . . . . . . . 39		11.2. New Critical 6LoWPAN Routing Header Type . . . . . . . . 40
	11.3. New Subregistry For The RPL Option Flags . . . . . . . . 40		11.3. New Subregistry For The RPL Option Flags . . . . . . . . 41
	11.4. New RPL Control Codes . . . . . . . . . . . . . . . . . 40		11.4. New RPL Control Codes . . . . . . . . . . . . . . . . . 41
	11.5. New RPL Control Message Options . . . . . . . . . . . . 41		11.5. New RPL Control Message Options . . . . . . . . . . . . 42
	11.6. SubRegistry for the Projected DAO Request Flags . . . . 41		11.6. SubRegistry for the Projected DAO Request Flags . . . . 42
	11.7. SubRegistry for the PDR-ACK Flags . . . . . . . . . . . 41		11.7. SubRegistry for the PDR-ACK Flags . . . . . . . . . . . 42
	11.8. Subregistry for the PDR-ACK Acceptance Status Values . . 42		11.8. Subregistry for the PDR-ACK Acceptance Status Values . . 43
	11.9. Subregistry for the PDR-ACK Rejection Status Values . . 42		11.9. Subregistry for the PDR-ACK Rejection Status Values . . 43
	11.10. SubRegistry for the Via Information Options Flags . . . 43		11.10. SubRegistry for the Via Information Options Flags . . . 44
	11.11. SubRegistry for the Sibling Information Option Flags . . 43		11.11. SubRegistry for the Sibling Information Option Flags . . 44
	11.12. New Destination Advertisement Object Flag . . . . . . . 43		11.12. New Destination Advertisement Object Flag . . . . . . . 44
	11.13. Error in Projected Route ICMPv6 Code . . . . . . . . . . 44		11.13. Error in Projected Route ICMPv6 Code . . . . . . . . . . 45
	12. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 44		12. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 45
	13. Normative References . . . . . . . . . . . . . . . . . . . . 44		13. Normative References . . . . . . . . . . . . . . . . . . . . 45
	14. Informative References . . . . . . . . . . . . . . . . . . . 45		14. Informative References . . . . . . . . . . . . . . . . . . . 46
	Appendix A. Applications . . . . . . . . . . . . . . . . . . . . 46		Appendix A. Applications . . . . . . . . . . . . . . . . . . . . 48
	A.1. Loose Source Routing . . . . . . . . . . . . . . . . . . 47		A.1. Loose Source Routing . . . . . . . . . . . . . . . . . . 48
	A.2. Transversal Routes . . . . . . . . . . . . . . . . . . . 48		A.2. Transversal Routes . . . . . . . . . . . . . . . . . . . 49
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 50		Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 51
	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 6, line 25 ¶		skipping to change at page 6, line 25 ¶
	2.3. Other Terms		2.3. Other Terms
	Projected Route: A RPL Projected Route is a RPL route that is		Projected Route: A RPL Projected Route is a RPL route that is
	computed remotely by a PCE, and installed and maintained by a RPL		computed remotely by a PCE, and installed and maintained by a RPL
	Root on behalf of the PCE.		Root on behalf of the PCE.
	Projected DAO: A DAO message used to install a Projected Route.		Projected DAO: A DAO message used to install a Projected Route.
	Track: A DODAG that provides a complex path from or to a Root that		Track: A DODAG that provides a complex path from or to a Root that
	is the destination of the DODAG. The Root is the Track Ingress,		is the destination of the DODAG. The Root is the Track Ingress,
	and the forward direction for packets is down the DODAG, from the		and the forward direction for packets is down the DODAG, from the
	Track Ingress to one of the possibly multiple Track Egress Nodes.		Track Ingress to one of the possibly multiple Track Egress Nodes.
	TrackID: A RPL Local InstanceID with the 'D' bit set to 0. The		TrackID: A RPL Local InstanceID with the D bit set to 0. The
	TrackID is associated with the IPv6 Address of the Track Ingress		TrackID is associated with the IPv6 Address of the Track Ingress
	that is used to signal the DODAG Root.		that is used to signal the DODAG Root. The owner of the namespace
			is the Track Ingress.
	2.4. References		2.4. References
	In this document, readers will encounter terms and concepts that are		In this document, readers will encounter terms and concepts that are
	discussed in the "Routing Protocol for Low Power and Lossy Networks"		discussed in the "Routing Protocol for Low Power and Lossy Networks"
	[RPL] and "Terminology in Low power And Lossy Networks" [RFC7102].		[RPL] and "Terminology in Low power And Lossy Networks" [RFC7102].
	3. Extending RFC 6550		3. Extending RFC 6550
	3.1. Projected DAO		3.1. Projected DAO
	skipping to change at page 8, line 34 ¶		skipping to change at page 8, line 34 ¶
	Track Egress and forwarded along the Segment in the reverse		Track Egress and forwarded along the Segment in the reverse
	direction, installing a Storing Mode state to the Track Egress at		direction, installing a Storing Mode state to the Track Egress at
	each hop. In both cases the Track Ingress is the owner of the Track,		each hop. In both cases the Track Ingress is the owner of the Track,
	and it generates the P-DAO-ACK when the installation is successful.		and it generates the P-DAO-ACK when the installation is successful.
	3.2. Sibling Information Option		3.2. Sibling Information Option
	This specification adds another CMO called the Sibling Information		This specification adds another CMO called the Sibling Information
	Option (SIO) that is used by a RPL Aware Node (RAN) to advertise a		Option (SIO) that is used by a RPL Aware Node (RAN) to advertise a
	selection of its candidate neighbors as siblings to the Root, more in		selection of its candidate neighbors as siblings to the Root, more in
	Section 6.4. The sibling selection process is out of scope.		Section 6.4. The sibling selection process is out of scope. The
			expectation is that a node reports a Sibling Address in a SIO based
			on an active address registration [RFC8505] from that sibling for
			that address with the 'R' flag not set in the EARO. The node may
			assess the liveliness of the sibling at any time by performing a
			registration for one of its own addresses, either a link local or a
			global one, depending on whether the node expects the sibling to
			perform a matching advertisement in its own SIO.
	3.3. P-DAO Request		3.3. P-DAO Request
	Two new RPL Control Messages are also introduced, to enable a RAN to		Two new RPL Control Messages are also introduced, to enable a RAN to
	request the establishment of a Track between self as the Track		request the establishment of a Track between self as the Track
	Ingress Node and a Track Egress. The RAN makes its request by		Ingress Node and a Track Egress. The RAN makes its request by
	sending a new P-DAO Request (PDR) Message to the Root. The Root		sending a new P-DAO Request (PDR) Message to the Root. The Root
	confirms with a new PDR-ACK message back to the requester RAN, see		confirms with a new PDR-ACK message back to the requester RAN, see
	Section 6.1 for more. A positive PDR-ACK indicates that the Track		Section 6.1 for more. A positive PDR-ACK indicates that the Track
	was built and that the Roots commits to maintain the Track for the		was built and that the Roots commits to maintain the Track for the
	skipping to change at page 10, line 41 ¶		skipping to change at page 11, line 4 ¶
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	|1|0|E| Length | 6LoRH Type 7 | RPLInstanceID |		|1|0|E| Length | 6LoRH Type 7 | RPLInstanceID |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	Figure 3: P-RPI-6LoRH Format		Figure 3: P-RPI-6LoRH Format
	Elective 'E': See [RFC8138]. The 'E' flag is set to 1 to indicate		Elective 'E': See [RFC8138]. The 'E' flag is set to 1 to indicate
	an Elective 6LoRH, meaning that it can be ignored when forwarding.		an Elective 6LoRH, meaning that it can be ignored when forwarding.
	6. New RPL Control Messages and Options		6. New RPL Control Messages and Options
	6.1. New P-DAO Request Control Message		6.1. New P-DAO Request Control Message
	The P-DAO Request (PDR) message is sent by a Node in the main DODAG		The P-DAO Request (PDR) message is sent by a Node in the main DODAG
	to the Root. It is a request to establish or refresh a Track.		to the Root. It is a request to establish or refresh a Track where
	Exactly one RTO MUST be present in a PDR. The RTO signals the Track		this node is Track Ingress. The source IPv6 address of the PDR
	Egress, more in Section 7.1.		signals the Track Ingress of the requested Track, and the TrackID is
			indicated in the message itself. One and only one RPL Target Option
			MUST be present in the message. The RTO signals the Track Egress,
			more in Section 7.1.
	The RPL Control Code for the PDR is 0x09, to be confirmed by IANA.		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 | ReqLifetime | PDRSequence |		| TrackID |K|R| Flags | ReqLifetime | PDRSequence |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| Option(s)...		| Option(s)...
	+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+
	Figure 4: New P-DAO Request Format		Figure 4: 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.
	Track and then to the TrackID once the Track was created, to
	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 request a Complex Track for redundancy.		R: The 'R' flag is set to request a Complex Track for redundancy.
	Flags: Reserved. The Flags field MUST initialized to zero by the		Flags: Reserved. The Flags field MUST initialized to zero by the
	sender and MUST be ignored by the receiver		sender and MUST be ignored by the receiver
	ReqLifetime: 8-bit unsigned integer. The requested lifetime for the		ReqLifetime: 8-bit unsigned integer. The requested lifetime for the
	skipping to change at page 14, line 39 ¶		skipping to change at page 14, line 43 ¶
	of 255 (0xFF) represents infinity. The value of zero (0x00)		of 255 (0xFF) represents infinity. The value of zero (0x00)
	indicates a loss of reachability.		indicates a loss of reachability.
	A P-DAO message that contains a VIOwith a Segment Lifetime of zero		A P-DAO message that contains a VIOwith a Segment Lifetime of zero
	is referred as a No-Path P-DAO in this document.		is referred as a No-Path P-DAO in this document.
	SRH-6LoRH header: The first 2 bytes of the (first) SRH-6LoRH as		SRH-6LoRH header: The first 2 bytes of the (first) SRH-6LoRH as
	shown in Figure 6 of [RFC8138]. A 6LoRH Type of 4 means that the		shown in Figure 6 of [RFC8138]. A 6LoRH Type of 4 means that the
	VIA Addresses are provided in full with no compression.		VIA Addresses are provided in full with no compression.
	Via Address: An IPv6 addresse along the Segment.		Via Address: An IPv6 address along the Segment.
	In a SF-VIO, the list is a strict path between direct neighbors,		In a SF-VIO, the list is a strict path between direct neighbors,
	from the segment ingress to egress, both included. In an SR-VIO,		from the Segment Ingress to Egress, both included. The router
	the list starts at the first hop and ends at a Track Egress. The		that processes an SF-VIO MAY create additional routing state
	list in an SR-VIO may be loose, provided that each listed node has		towards the nodes after self via the node immediatelt after self
	a path to the next listed node, e.g., via a segment or another		in the SF-VIO, but in case of memory shortage the routes to the
	Track.		Targets have precedence since they are the ones that the router
			commits to store.
			In an SR-VIO, the list starts at the first hop and ends at a Track
			Egress. In that case, the Track Egress MUST be considered as an
			implicit Target, so it MUST NOT be listed it in a RPL Target
			Option. The list in an SR-VIO may be loose, provided that each
			listed node has a path to the next listed node, e.g., via a
			segment or another Track.
	In the case of a SF-VIO, or if [RFC8138] is not used in the data		In the case of a SF-VIO, or if [RFC8138] is not used in the data
	packets, then the Root MUST use only one SRH-6LoRH per Via		packets, then the Root MUST use only one SRH-6LoRH per Via
	Information Option, and the compression is the same for all the		Information Option, and the compression is the same for all the
	addresses, as shown in Figure 7.		addresses, as shown in Figure 7.
	In case of an SR-VIO, and if [RFC8138] is in use in the main		In case of an SR-VIO, and if [RFC8138] is in use in the main
	DODAG, then the Root SHOULD optimize the size of the SR-VIO; more		DODAG, then the Root SHOULD optimize the size of the SR-VIO; more
	than one SRH-6LoRH may be present, e.g., if the compression level		than one SRH-6LoRH may be present, e.g., if the compression level
	changes inside the Segment and different SRH-6LoRH Types are		changes inside the Segment and different SRH-6LoRH Types are
	skipping to change at page 15, line 32 ¶		skipping to change at page 16, line 15 ¶
	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 | Reserved |		| Step of Rank | Reserved |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| |		| |
	+ +		+ +
	. .		. .
	. Sibling DODAGID (if 'D' flag not set) .		. Sibling DODAGID (if the D flag not set) .
	. .		. .
	+ +		+ +
	| |		| |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| |		| |
	+ +		+ +
	. .		. .
	. Sibling Address .		. Sibling Address .
	. .		. .
	+ +		+ +
	skipping to change at page 16, line 6 ¶		skipping to change at page 16, line 38 ¶
	Figure 8: Sibling Information Option Format		Figure 8: Sibling Information Option Format
	Option Type: 0x0D (to be confirmed by IANA)		Option Type: 0x0D (to be confirmed by IANA)
	Option Length: In bytes, the size of the option.		Option Length: In bytes, the size of the option.
	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 and		corresponds to the compression used for the Sibling Address and
	its DODAGID if resent. The Compression refernce is the Root of		its DODAGID if resent. The Compression reference is the Root of
	the main DODAG.		the main DODAG.
	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.
	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
	skipping to change at page 16, line 41 ¶		skipping to change at page 17, line 24 ¶
	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.
	Reserved: The Reserved field MUST initialized to zero by the sender		Reserved: The Reserved field MUST initialized to zero by the sender
	and MUST be ignored by the receiver		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 if and only if 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, an IPv6 Address of the sibling, with
	[RFC8138] compressed form as indicated by the Compression Type		a scope that MUST be make it reachable from the Root, e.g., it
			cannot be a Link Local Address. The IPv6 address is encoded in
			the [RFC8138] compressed form 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
	that case the DAG Metric Container provides additional metrics for		that case the DAG Metric Container provides additional metrics for
	the hop from the Sibling to this node.		the hop from the Sibling to this node.
	7. Projected DAO		7. Projected DAO
	This draft adds a capability to RPL whereby the Root of a main DODAG		This draft adds a capability to RPL whereby the Root of a main DODAG
	installs a Track as a collection of Projected Routes, using a		installs a Track as a collection of Projected Routes, using a
	skipping to change at page 18, line 25 ¶		skipping to change at page 19, line 10 ¶
	destination in the IPv6 header is the next hop that this node could		destination in the IPv6 header is the next hop that this node could
	not reach. if a 6LoWPAN Routing Header (6LoRH) [RFC8138] is used to		not reach. if a 6LoWPAN Routing Header (6LoRH) [RFC8138] is used to
	carry the IPv6 routing information in the outer header then that		carry the IPv6 routing information in the outer header then that
	whole 6LoRH information SHOULD be present in the ICMP message.		whole 6LoRH information SHOULD be present in the ICMP message.
	The sender and exact operation depend on the Mode and is described in		The sender and exact operation depend on the Mode and is described in
	Section 7.3.2 and Section 7.3.1 respectively.		Section 7.3.2 and Section 7.3.1 respectively.
	7.1. Requesting a Track		7.1. Requesting a Track
	A Node is free to ask the Root for a new Track at any time. This is		A Node is free to ask the Root for a new Track for which it will be
	done with a PDR message, that indicates in the Requested Lifetime		Ingress at any time. This is done with a PDR message, that indicates
	field the duration for which the Track should be established. Upon a		the desired TrackID and the duration for which the Track should be
	PDR, the Root MAY install the necessary Segments, in which case it		established. Upon a PDR, the Root MAY install the necessary
	answers with a PDR-ACK indicating the granted Track Lifetime. All		Segments, in which case it answers with a PDR-ACK indicating the
	the Segments MUST be of a same mode, either Storing or Non-Storing.		granted Track Lifetime. All the Segments MUST be of a same mode,
	All the Segments MUST be created with the same TrackID and the same		either Storing or Non-Storing. All the Segments MUST be created with
	DODAGID signaled in the P-DAO.		the same TrackID and the same DODAGID signaled in the P-DAO.
	The Root is free to design the Track as it wishes, and to change the		The Root is free to design the Track as it wishes, and to change the
	Segments overtime to serve the Track as needed, without notifying the		Segments overtime to serve the Track as needed, without notifying the
	resquesting Node. The Segment Lifetime in the P-DAO messages does		resquesting Node. The Segment Lifetime in the P-DAO messages does
	not need to be aligned to the Requested Lifetime in the PDR, or		not need to be aligned to the Requested Lifetime in the PDR, or
	between P-DAO messages for different Segments. The Root may use		between P-DAO messages for different Segments. The Root may use
	shorter lifetimes for the Segments and renew them faster than the		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		Track is, or longer lifetimes in which case it will need to tear down
	the Segments if the Track is not renewed.		the Segments if the Track is not renewed.
	skipping to change at page 19, line 38 ¶		skipping to change at page 20, line 28 ¶
	Once the Projected Route is installed, the intermediate nodes		Once the Projected Route is installed, the intermediate nodes
	listed in the SF-VIO after first one (i.e. The ingress) can be		listed in the SF-VIO after first one (i.e. The ingress) can be
	elided from the RH in packets sent along the Segment signaled in		elided from the RH in packets sent along the Segment signaled in
	the P-DAO. The resulting loose source routing header indicates		the P-DAO. The resulting loose source routing header indicates
	(one of) the Target(s) as the next entry after the ingress.		(one of) the Target(s) as the next entry after the ingress.
	* The Root MAY also use P-DAO messages to install a specific (say,		* The Root MAY also use P-DAO messages to install a specific (say,
	Traffic Engineered) path as a Serial or as a Complex Track, to a		Traffic Engineered) path as a Serial or as a Complex Track, to a
	particular endpoint that is the Track Egress. In that case, the		particular endpoint that is the Track Egress. In that case, the
	Root MUST install a Local RPL Instance (see section 5 of [RPL]).		Root MUST install a Local RPL Instance (see section 5 of [RPL]),
			and the Local RPLInstanceID is called TrackID.
	In a that case, the TrackID MUST be unique for the Global Unique		In that case, the TrackID MUST be unique for the Global Unique
	IPv6 Address (GUA) or Unique-Local Address (ULA) of the Track		IPv6 Address (GUA) or Unique-Local Address (ULA) of the Track
	Ingress that serves as DODAGID for the Track. This way, a Track		Ingress that serves as DODAGID for the Track. The Track Ingress
	is uniquely identified by the tuple (DODAGID, TrackID) where the		owns the namespace of its TrackIDs, so it can pick any unused
	TrackID is always represented with the 'D' flag set to 0.		value to request a new Track with a PDR. The Root is aware of all
			the active Tracks, so it can also pick any unused value to form
			Tracks without a PDR. To avoid a collision of the Root and the
			Track Ingress picking the same value at the same time, it is
			RECOMMENDED that the Track Ingress starts allocating the ID value
			of the Local RPLInstanceID (see section 5.1. of [RPL]) used as
			TrackIDs with the value 0 incrementing, while the Root starts with
			63 decrementing.
			This way, a Track is uniquely identified by the tuple (DODAGID,
			TrackID) where the TrackID is always represented with the D flag
			set to 0.
	The Track Egress Address and the TrackID MUST be signaled in the		The Track Egress Address and the TrackID MUST be signaled in the
	P-DAO message as shown in Figure 1.		P-DAO message as shown in Figure 1.
	7.3. Installing a Track		7.3. Installing a Track
	A Storing-Mode P-DAO contains an SF-VIO that signals the strict		A Storing-Mode P-DAO contains an SF-VIO that signals the strict
	sequence of consecutive nodes to form a segment between a segment		sequence of consecutive nodes to form a segment between a segment
	ingress and a segment egress (both included). It installs a route of		ingress and a segment egress (both included). It installs a route of
	a higher precedence along the segment towards the Targets indicated		a higher precedence along the segment towards the Targets indicated
	skipping to change at page 24, line 41 ¶		skipping to change at page 25, line 41 ¶
	* In the data packets, the Track DODAGID and the TrackID MUST be		* In the data packets, the Track DODAGID and the TrackID MUST be
	respectively signaled as the IPv6 Source Address and the		respectively signaled as the IPv6 Source Address and the
	RPLInstanceID field of the RPI that MUST be placed in the outer		RPLInstanceID field of the RPI that MUST be placed in the outer
	chain of IPv6 Headers.		chain of IPv6 Headers.
	The RPI carries a local RPLInstanceID called the TrackID, which,		The RPI carries a local RPLInstanceID called the TrackID, which,
	in association with the DODAGID, indicates the Track along which		in association with the DODAGID, indicates the Track along which
	the packet is forwarded.		the packet is forwarded.
	The 'D' flag in the RPLInstanceID MUST be set to 0 to indicate		The D flag in the RPLInstanceID MUST be set to 0 to indicate that
	that the source address in the IPv6 header is set ot the DODAGID,		the source address in the IPv6 header is set ot the DODAGID, more
	more in Section 7.4.		in Section 7.4.
	* This draft conforms the principles of [USEofRPLinfo] with regards		* This draft conforms the principles of [USEofRPLinfo] with regards
	to packet forwarding and encapsulation along a Track.		to packet forwarding and encapsulation along a Track.
	- In that case, the Track is the DODAG, the Track Ingress is the		- In that case, the Track is the DODAG, the Track Ingress is the
	Root, and the Track Egress is a RAL, and neighbors of the Track		Root, and the Track Egress is a RAL, and neighbors of the Track
	Egress that can be reached via the Track are RULs. The		Egress that can be reached via the Track are RULs. The
	encapsulation rules in [USEofRPLinfo] apply.		encapsulation rules in [USEofRPLinfo] apply.
	- If the Track Ingress is the originator of the packet and the		- If the Track Ingress is the originator of the packet and the
	skipping to change at page 26, line 15 ¶		skipping to change at page 27, line 15 ¶
	Mode Projected Routes along the main DODAG. Profile 2 provides		Mode Projected Routes along the main DODAG. Profile 2 provides
	the same capability to compress the SRH in packets down the main		the same capability to compress the SRH in packets down the main
	DODAG as Profile 1, but it require an encapsulation, in order to		DODAG as Profile 1, but it require an encapsulation, in order to
	insert an additional SRH between the loose source routing hops.		insert an additional SRH between the loose source routing hops.
	Profile 3 Profile 3 and above build Tracks that do not necessarily		Profile 3 Profile 3 and above build Tracks that do not necessarily
	follow the main DODAG. In order to form the best path possible,		follow the main DODAG. In order to form the best path possible,
	those Profiles require the support of Sibling Information Option		those Profiles require the support of Sibling Information Option
	to inform the Root of additional possible hops. Profile 3 extends		to inform the Root of additional possible hops. Profile 3 extends
	Profile 1 with additional Storing-Mode Projected Routes that		Profile 1 with additional Storing-Mode Projected Routes that
	install segments that do not follow the main DODAG. Segments can		install segments that do not follow the main DODAG. If the
	be associated in a Track rooted at an Ingress node, but there is		Segment Ingress (in the SF-VIO) is the same as the IPv6 Address of
	no explicit Egress node, and no source routing operation.		the Track Ingress (in the projected DAO base Object), the P-DAO
			creates an implicit Track between the Segment Ingress and the
			Segment Egress.
	Profile 4 Profile 4 extends Profile 2 with Strict Source-Routing		Profile 4 Profile 4 extends Profile 2 with Strict Source-Routing
	Non-Storing-Mode Projected Routes to form Tracks inside the main		Non-Storing-Mode Projected Routes to form Tracks inside the main
	DODAG. A Track is formed as one or more strict source source		DODAG. A Track is formed as one or more strict source source
	routed paths between the Root that is the Track Ingress, and the		routed paths between the Root that is the Track Ingress, and the
	Track Egress that is the last node		Track Egress that is the last node
	Profile 5 Profile 5 Combines Profile 4 with Profile 1 and enables to		Profile 5 Profile 5 Combines Profile 4 with Profile 1 and enables to
	loose source routing between the Ingress and the Egress of the		loose source routing between the Ingress and the Egress of the
	Track. As in Profile 1, Storing-Mode Projected Routes connect the		Track. As in Profile 1, Storing-Mode Projected Routes connect the
	skipping to change at page 45, line 46 ¶		skipping to change at page 46, line 46 ¶
	Lossy Networks", RFC 7102, DOI 10.17487/RFC7102, January		Lossy Networks", RFC 7102, DOI 10.17487/RFC7102, January
	2014, <https://www.rfc-editor.org/info/rfc7102>.		2014, <https://www.rfc-editor.org/info/rfc7102>.
	[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., Ed., "An Architecture for IPv6 over the Time-
	of IEEE 802.15.4", Work in Progress, Internet-Draft,		Slotted Channel Hopping Mode of IEEE 802.15.4 (6TiSCH)",
	draft-ietf-6tisch-architecture-30, 26 November 2020,		RFC 9030, DOI 10.17487/RFC9030, May 2021,
	<https://tools.ietf.org/html/draft-ietf-6tisch-		<https://www.rfc-editor.org/info/rfc9030>.
	architecture-30>.
	[RAW-ARCHI]		[RAW-ARCHI]
	Thubert, P., Papadopoulos, G., and R. Buddenberg,		Thubert, P., Papadopoulos, G. Z., 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-05, 15 November 2020,		architecture-05, 15 November 2020,
	<https://tools.ietf.org/html/draft-pthubert-raw-		<https://tools.ietf.org/html/draft-pthubert-raw-
	architecture-05>.		architecture-05>.
	[TURN-ON_RFC8138]		[TURN-ON_RFC8138]
	Thubert, P. and L. Zhao, "A RPL DODAG Configuration Option		Thubert, P., Ed. and L. Zhao, "A Routing Protocol for Low-
	for the 6LoWPAN Routing Header", Work in Progress,		Power and Lossy Networks (RPL) Destination-Oriented
	Internet-Draft, draft-ietf-roll-turnon-rfc8138-18, 18		Directed Acyclic Graph (DODAG) Configuration Option for
	December 2020, <https://tools.ietf.org/html/draft-ietf-		the 6LoWPAN Routing Header", RFC 9035,
	roll-turnon-rfc8138-18>.		DOI 10.17487/RFC9035, April 2021,
			<https://www.rfc-editor.org/info/rfc9035>.
	[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>.
			[RFC8505] Thubert, P., Ed., Nordmark, E., Chakrabarti, S., and C.
			Perkins, "Registration Extensions for IPv6 over Low-Power
			Wireless Personal Area Network (6LoWPAN) Neighbor
			Discovery", RFC 8505, DOI 10.17487/RFC8505, November 2018,
			<https://www.rfc-editor.org/info/rfc8505>.
	[USEofRPLinfo]		[USEofRPLinfo]
	Robles, I., Richardson, M., and P. Thubert, "Using RPI		Robles, M.I., Richardson, M., and P. Thubert, "Using RPI
	Option Type, Routing Header for Source Routes and IPv6-in-		Option Type, Routing Header for Source Routes, and IPv6-
	IPv6 encapsulation in the RPL Data Plane", Work in		in-IPv6 Encapsulation in the RPL Data Plane", RFC 9008,
	Progress, Internet-Draft, draft-ietf-roll-useofrplinfo-43,		DOI 10.17487/RFC9008, April 2021,
	10 January 2021, <https://tools.ietf.org/html/draft-ietf-		<https://www.rfc-editor.org/info/rfc9008>.
	roll-useofrplinfo-43>.
	[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		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 12.		uses the Non-Storing Mode of Operation as represented in Figure 12.
	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.
End of changes. 31 change blocks.
	100 lines changed or deleted		139 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/