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/