< draft-ietf-roll-dao-projection-24.txt   draft-ietf-roll-dao-projection-25.txt >
ROLL P. Thubert, Ed. ROLL P. Thubert, Ed.
Internet-Draft Cisco Systems Internet-Draft Cisco Systems
Intended status: Standards Track R.A. Jadhav Intended status: Standards Track R.A. Jadhav
Expires: 29 August 2022 Huawei Tech Expires: 24 September 2022 Huawei Tech
M. Richardson M. Richardson
Sandelman Sandelman
25 February 2022 23 March 2022
Root initiated routing state in RPL Root initiated routing state in RPL
draft-ietf-roll-dao-projection-24 draft-ietf-roll-dao-projection-25
Abstract Abstract
This document extends RFC 6550, RFC 6553, and RFC 8138 to enable a THIS RFC extends RFC 6550, RFC 6553, and RFC 8138 to enable a RPL
RPL Root to install and maintain Projected Routes within its DODAG, Root to install and maintain Projected Routes within its DODAG, along
along a selected set of nodes that may or may not include self, for a a selected set of nodes that may or may not include self, for a
chosen duration. This potentially enables routes that are more chosen duration. This potentially enables routes that are more
optimized or resilient than those obtained with the classical optimized or resilient than those obtained with the classical
distributed operation of RPL, either in terms of the size of a distributed operation of RPL, either in terms of the size of a
Routing Header or in terms of path length, which impacts both the Routing Header or in terms of path length, which impacts both the
latency and the packet delivery ratio. latency and the packet delivery ratio.
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.
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 29 August 2022. This Internet-Draft will expire on 24 September 2022.
Copyright Notice Copyright Notice
Copyright (c) 2022 IETF Trust and the persons identified as the Copyright (c) 2022 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 25 skipping to change at page 2, line 25
2.1. Requirements Language . . . . . . . . . . . . . . . . . . 4 2.1. Requirements Language . . . . . . . . . . . . . . . . . . 4
2.2. References . . . . . . . . . . . . . . . . . . . . . . . 5 2.2. References . . . . . . . . . . . . . . . . . . . . . . . 5
2.3. Glossary . . . . . . . . . . . . . . . . . . . . . . . . 5 2.3. Glossary . . . . . . . . . . . . . . . . . . . . . . . . 5
2.4. Domain Terms . . . . . . . . . . . . . . . . . . . . . . 5 2.4. Domain Terms . . . . . . . . . . . . . . . . . . . . . . 5
2.4.1. Projected Route . . . . . . . . . . . . . . . . . . . 6 2.4.1. Projected Route . . . . . . . . . . . . . . . . . . . 6
2.4.2. Projected DAO . . . . . . . . . . . . . . . . . . . . 6 2.4.2. Projected DAO . . . . . . . . . . . . . . . . . . . . 6
2.4.3. Path . . . . . . . . . . . . . . . . . . . . . . . . 6 2.4.3. Path . . . . . . . . . . . . . . . . . . . . . . . . 6
2.4.4. Routing Stretch . . . . . . . . . . . . . . . . . . . 6 2.4.4. Routing Stretch . . . . . . . . . . . . . . . . . . . 6
2.4.5. Track . . . . . . . . . . . . . . . . . . . . . . . . 7 2.4.5. Track . . . . . . . . . . . . . . . . . . . . . . . . 7
3. Context and Goal . . . . . . . . . . . . . . . . . . . . . . 9 3. Context and Goal . . . . . . . . . . . . . . . . . . . . . . 9
3.1. RPL Applicability . . . . . . . . . . . . . . . . . . . . 9 3.1. RPL Applicability . . . . . . . . . . . . . . . . . . . . 10
3.2. RPL Routing Modes . . . . . . . . . . . . . . . . . . . . 10 3.2. RPL Routing Modes . . . . . . . . . . . . . . . . . . . . 11
3.3. Requirements . . . . . . . . . . . . . . . . . . . . . . 11 3.3. Requirements . . . . . . . . . . . . . . . . . . . . . . 12
3.3.1. Loose Source Routing . . . . . . . . . . . . . . . . 11 3.3.1. Loose Source Routing . . . . . . . . . . . . . . . . 12
3.3.2. East-West Routes . . . . . . . . . . . . . . . . . . 13 3.3.2. East-West Routes . . . . . . . . . . . . . . . . . . 13
3.4. On Tracks . . . . . . . . . . . . . . . . . . . . . . . . 14 3.4. On Tracks . . . . . . . . . . . . . . . . . . . . . . . . 15
3.4.1. Building Tracks With RPL . . . . . . . . . . . . . . 15 3.4.1. Building Tracks With RPL . . . . . . . . . . . . . . 15
3.4.2. Tracks and RPL Instances . . . . . . . . . . . . . . 15 3.4.2. Tracks and RPL Instances . . . . . . . . . . . . . . 16
3.5. Serial Track Signaling . . . . . . . . . . . . . . . . . 16 3.5. Serial Track Signaling . . . . . . . . . . . . . . . . . 16
3.5.1. Using Storing Mode Segments . . . . . . . . . . . . . 17 3.5.1. Using Storing Mode Segments . . . . . . . . . . . . . 18
3.5.2. Using Non-Storing Mode joining Tracks . . . . . . . . 24 3.5.2. Using Non-Storing Mode joining Tracks . . . . . . . . 24
3.6. Complex Tracks . . . . . . . . . . . . . . . . . . . . . 31 3.6. Complex Tracks . . . . . . . . . . . . . . . . . . . . . 31
3.7. Scope and Expectations . . . . . . . . . . . . . . . . . 33 3.7. Scope and Expectations . . . . . . . . . . . . . . . . . 33
3.7.1. External Dependencies . . . . . . . . . . . . . . . . 33 3.7.1. External Dependencies . . . . . . . . . . . . . . . . 33
3.7.2. Positioning vs. Related IETF Standards . . . . . . . 33 3.7.2. Positioning vs. Related IETF Standards . . . . . . . 33
4. Extending existing RFCs . . . . . . . . . . . . . . . . . . . 35 4. Extending existing RFCs . . . . . . . . . . . . . . . . . . . 35
4.1. Extending RFC 6550 . . . . . . . . . . . . . . . . . . . 35 4.1. Extending RFC 6550 . . . . . . . . . . . . . . . . . . . 35
4.1.1. Projected DAO . . . . . . . . . . . . . . . . . . . . 36 4.1.1. Projected DAO . . . . . . . . . . . . . . . . . . . . 36
4.1.2. Projected DAO-ACK . . . . . . . . . . . . . . . . . . 38 4.1.2. Projected DAO-ACK . . . . . . . . . . . . . . . . . . 38
4.1.3. Via Information Option . . . . . . . . . . . . . . . 39 4.1.3. Via Information Option . . . . . . . . . . . . . . . 39
skipping to change at page 3, line 41 skipping to change at page 3, line 41
11.1. RPL DODAG Configuration Option Flag . . . . . . . . . . 72 11.1. RPL DODAG Configuration Option Flag . . . . . . . . . . 72
11.2. Elective 6LoWPAN Routing Header Type . . . . . . . . . . 73 11.2. Elective 6LoWPAN Routing Header Type . . . . . . . . . . 73
11.3. Critical 6LoWPAN Routing Header Type . . . . . . . . . . 73 11.3. Critical 6LoWPAN Routing Header Type . . . . . . . . . . 73
11.4. Subregistry For The RPL Option Flags . . . . . . . . . . 73 11.4. Subregistry For The RPL Option Flags . . . . . . . . . . 73
11.5. RPL Control Codes . . . . . . . . . . . . . . . . . . . 74 11.5. RPL Control Codes . . . . . . . . . . . . . . . . . . . 74
11.6. RPL Control Message Options . . . . . . . . . . . . . . 74 11.6. RPL Control Message Options . . . . . . . . . . . . . . 74
11.7. SubRegistry for the Projected DAO Request Flags . . . . 75 11.7. SubRegistry for the Projected DAO Request Flags . . . . 75
11.8. SubRegistry for the PDR-ACK Flags . . . . . . . . . . . 75 11.8. SubRegistry for the PDR-ACK Flags . . . . . . . . . . . 75
11.9. Subregistry for the PDR-ACK Acceptance Status Values . . 76 11.9. Subregistry for the PDR-ACK Acceptance Status Values . . 76
11.10. Subregistry for the PDR-ACK Rejection Status Values . . 76 11.10. Subregistry for the PDR-ACK Rejection Status Values . . 76
11.11. SubRegistry for the Via Information Options Flags . . . 76 11.11. SubRegistry for the Via Information Options Flags . . . 77
11.12. SubRegistry for the Sibling Information Option Flags . . 77 11.12. SubRegistry for the Sibling Information Option Flags . . 77
11.13. Destination Advertisement Object Flag . . . . . . . . . 77 11.13. Destination Advertisement Object Flag . . . . . . . . . 77
11.14. Destination Advertisement Object Acknowledgment Flag . . 78 11.14. Destination Advertisement Object Acknowledgment Flag . . 78
11.15. New ICMPv6 Error Code . . . . . . . . . . . . . . . . . 78 11.15. New ICMPv6 Error Code . . . . . . . . . . . . . . . . . 78
11.16. RPL Rejection Status values . . . . . . . . . . . . . . 78 11.16. RPL Rejection Status values . . . . . . . . . . . . . . 78
12. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 79 12. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 79
13. Normative References . . . . . . . . . . . . . . . . . . . . 79 13. Normative References . . . . . . . . . . . . . . . . . . . . 79
14. Informative References . . . . . . . . . . . . . . . . . . . 81 14. Informative References . . . . . . . . . . . . . . . . . . . 81
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 83 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 83
skipping to change at page 4, line 44 skipping to change at page 4, line 44
extensions that enable the Root to translates the computed paths into extensions that enable the Root to translates the computed paths into
RPL and install them as Projected Routes (aka P-Routes) inside the RPL and install them as Projected Routes (aka P-Routes) inside the
DODAG on behalf of a PCE. DODAG on behalf of a PCE.
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 RFC are to be interpreted as described in BCP 14
14 [RFC2119][RFC8174] when, and only when, they appear in all [RFC2119][RFC8174] when, and only when, they appear in all capitals,
capitals, as shown here. as shown here.
In addition, the terms "Extends" and "Amends" are used as per In addition, the terms "Extends" and "Amends" are used as per
[I-D.kuehlewind-update-tag] section 3. [I-D.kuehlewind-update-tag] section 3.
2.2. References 2.2. References
In this document, readers will encounter terms and concepts that are In THIS RFC, 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], the "6TiSCH Architecture" [RFC9030], the "Deterministic [RPL], the "6TiSCH Architecture" [RFC9030], the "Deterministic
Networking Architecture" [RFC8655], the "Reliable and Available Networking Architecture" [RFC8655], the "Reliable and Available
Wireless (RAW) Architecture" [RAW-ARCHI], and "Terminology in Low Wireless (RAW) Architecture" [RAW-ARCHI], and "Terminology in Low
power And Lossy Networks" [RFC7102]. power And Lossy Networks" [RFC7102].
2.3. Glossary 2.3. Glossary
This document often uses the following acronyms: THIS RFC often uses the following acronyms:
CMO: Control Message Option CMO: Control Message Option
DAO: destination Advertisement Object DAO: destination Advertisement Object
DAG: Directed Acyclic Graph DAG: Directed Acyclic Graph
DODAG: destination-Oriented Directed Acyclic Graph; A DAG with only DODAG: destination-Oriented Directed Acyclic Graph; A DAG with only
one vertex (i.e., node) that has no outgoing edge (i.e., link) one vertex (i.e., node) that has no outgoing edge (i.e., link)
GUA: IPv6 Global Unicast Address GUA: IPv6 Global Unicast Address
LLN: Low-Power and Lossy Network LLN: Low-Power and Lossy Network
MOP: RPL Mode of Operation MOP: RPL Mode of Operation
P-DAO: Projected DAO P-DAO: Projected DAO
skipping to change at page 8, line 27 skipping to change at page 8, line 27
A single P-DAO that fully defines a Track, e.g., a Serial Track A single P-DAO that fully defines a Track, e.g., a Serial Track
installed with a single Storing Mode Via Information option (SM-VIO). installed with a single Storing Mode Via Information option (SM-VIO).
2.4.5.5. Stitching 2.4.5.5. Stitching
This specification using the term stitching to indicate that a track This specification using the term stitching to indicate that a track
is piped to another one, meaning that traffic out of the first is is piped to another one, meaning that traffic out of the first is
injected in the other. injected in the other.
2.4.5.6. subTrack 2.4.5.6. Leg
A Track within a Track. As the Non-Storing Mode Via Information An end-to-end East-West serial path. A leg can be a serial Track by
option (NSM-VIO) can only signal a loose sequence of nodes, it takes itself or a subTrack of a complex Track with the same Ingress and
a number of them to signal a complex Track. Each NSM-VIO for the Egress Nodes. With this specification, a Leg is is installed by the
same TrackId but a different Segment ID signals a different subTracks Root of the main DODAG using a Non-Storing Mode P-DAO message, and it
that the Track Ingress adds to the topology. is expressed as a loose sequence of nodes that are joined by Track
Segments.
2.4.5.7. Leg As the Non-Storing Mode Via Information option (NSM-VIO) can only
signal sequences of nodes, it takes one Non-Storing Mode P-DAO
message per Leg to signal the structure of a complex Track.
An end-to-end East-West serial path that can be a Track by itself or Each NSM-VIO for the same TrackId but a different Segment ID signals
a subTrack of a complex Track. With this specification, a Leg is is a different leg that the Track Ingress adds to the topology.
installed by the Root of the main DODAG using Non-Storing Mode P-DAO
messages, and it is expressed as a loose sequence of nodes that are 2.4.5.7. subTrack
joined by Track Segments.
A Track within a Track, formed by a non-empty collection of Legs of
the Track.
2.4.5.8. Segment 2.4.5.8. Segment
A serial path formed by a strict sequence of nodes, along which a A serial path formed by a strict sequence of nodes, along which a
P-Route is installed. With this specification, a Segment is P-Route is installed. With this specification, a Segment is
typically installed by the Root of the main DODAG using Storing Mode typically installed by the Root of the main DODAG using Storing Mode
P-DAO messages. A Segment used as the topological edge of a Track. P-DAO messages. A Segment is used as the topological edge of a Track
joining the loose steps along the Legs that form the structure of a
complex Track. The same segment may be leveraged by more than one
Leg where the Legs overlap.
Since this specification builds only DODAGs, all Segments are Since this specification builds only DODAGs, all Segments are
oriented from Ingress (East) to Egress (West), as opposed to the oriented from Ingress (East) to Egress (West), as opposed to the
general RAW model, which allows North/South Segments that can be general Track model in the RAW Architecture [RAW-ARCHI], which allows
bidirectional. North/South Segments that can be bidirectional as well.
2.4.5.8.1. Section of a Segment 2.4.5.8.1. Section of a Segment
A continuous subset of a segment that may be replaced while the A continuous subset of a segment that may be replaced while the
segment remains. for instance, in segment A=>B=>C=>D=>E=>F, say that segment remains. for instance, in segment A=>B=>C=>D=>E=>F, say that
the link C to D might be misbehaving. The section B=>C=>D=>E in the the link C to D might be misbehaving. The section B=>C=>D=>E in the
segment may be replaced by B=>C'=>D'=>E to route around the problem. segment may be replaced by B=>C'=>D'=>E to route around the problem.
The segment becomes A=>B=>C'=>D'=>E=>F. The segment becomes A=>B=>C'=>D'=>E=>F.
2.4.5.8.2. Segment Routing and SRH 2.4.5.8.2. Segment Routing and SRH
skipping to change at page 33, line 15 skipping to change at page 33, line 15
till node B and congruent with Leg 2 from node H on, abstracting till node B and congruent with Leg 2 from node H on, abstracting
Segment 5 as an East-West Segment. Segment 5 as an East-West Segment.
3.7. Scope and Expectations 3.7. Scope and Expectations
3.7.1. External Dependencies 3.7.1. External Dependencies
This specification expects that the RPL Main DODAG is operated in RPL This specification expects that the RPL Main DODAG is operated in RPL
Non-Storing Mode to sustain the exchanges with the Root. Based on Non-Storing Mode to sustain the exchanges with the Root. Based on
its comprehensive knowledge of the parent-child relationship, the its comprehensive knowledge of the parent-child relationship, the
Root can form an abstracted view of the whole DODAG topology. This Root can form an abstracted view of the whole DODAG topology. THIS
document adds the capability for nodes to advertise additional RFC adds the capability for nodes to advertise additional sibling
sibling information to complement the topological awareness of the information to complement the topological awareness of the Root to be
Root to be passed on to the PCE, and enable the PCE to build more / passed on to the PCE, and enable the PCE to build more / better paths
better paths that traverse those siblings. that traverse those siblings.
P-Routes require resources such as routing table space in the routers P-Routes require resources such as routing table space in the routers
and bandwidth on the links; the amount of state that is installed in and bandwidth on the links; the amount of state that is installed in
each node must be computed to fit within the node's memory, and the each node must be computed to fit within the node's memory, and the
amount of rerouted traffic must fit within the capabilities of the amount of rerouted traffic must fit within the capabilities of the
transmission links. The methods used to learn the node capabilities transmission links. The methods used to learn the node capabilities
and the resources that are available in the devices and in the and the resources that are available in the devices and in the
network are out of scope for this document. The method to capture network are out of scope for THIS RFC. The method to capture and
and report the LLN link capacity and reliability statistics are also report the LLN link capacity and reliability statistics are also out
out of scope. They may be fetched from the nodes through network of scope. They may be fetched from the nodes through network
management functions or other forms of telemetry such as OAM. management functions or other forms of telemetry such as OAM.
3.7.2. Positioning vs. Related IETF Standards 3.7.2. Positioning vs. Related IETF Standards
3.7.2.1. Extending 6TiSCH 3.7.2.1. Extending 6TiSCH
The "6TiSCH Architecture" [RFC9030] leverages a centralized model The "6TiSCH Architecture" [RFC9030] leverages a centralized model
that is similar to that of "Deterministic Networking Architecture" that is similar to that of "Deterministic Networking Architecture"
[RFC8655], whereby the device resources and capabilities are exposed [RFC8655], whereby the device resources and capabilities are exposed
to an external controller which installs routing states into the to an external controller which installs routing states into the
skipping to change at page 36, line 30 skipping to change at page 36, line 30
4.1.1. Projected DAO 4.1.1. Projected DAO
Section 6 of [RPL] introduces the RPL Control Message Options (CMO), Section 6 of [RPL] introduces the RPL Control Message Options (CMO),
including the RPL Target Option (RTO) and Transit Information Option including the RPL Target Option (RTO) and Transit Information Option
(TIO), which can be placed in RPL messages such as the destination (TIO), which can be placed in RPL messages such as the destination
Advertisement Object (DAO). A DAO message signals routing Advertisement Object (DAO). A DAO message signals routing
information to one or more Targets indicated in RTOs, providing one information to one or more Targets indicated in RTOs, providing one
hop information at a time in the TIO. hop information at a time in the TIO.
This document Amends the specification of the DAO to create the P-DAO THIS RFC Amends the specification of the DAO to create the P-DAO
message. This Amended DAO is signaled with a new "Projected DAO" (P) message. This Amended DAO is signaled with a new "Projected DAO" (P)
flag, see Figure 8. flag, see Figure 8.
A Projected DAO (P-DAO) is a special DAO message generated by the A Projected DAO (P-DAO) is a special DAO message generated by the
Root to install a P-Route formed of multiple hops in its DODAG. This Root to install a P-Route formed of multiple hops in its DODAG. This
provides a RPL-based method to install the Tracks as expected by the provides a RPL-based method to install the Tracks as expected by the
6TiSCH Architecture [RFC9030] as a collection of multiple P-Routes. 6TiSCH Architecture [RFC9030] as a collection of multiple P-Routes.
The Root MUST source the P-DAO message with its address that serves The Root MUST source the P-DAO message with its address that serves
as DODAGID for the main DODAG. The receiver MUST NOT accept a P-DAO as DODAGID for the main DODAG. The receiver MUST NOT accept a P-DAO
skipping to change at page 38, line 18 skipping to change at page 38, line 18
message signals to the Root that a given parent can be used to reach message signals to the Root that a given parent can be used to reach
a given child. The P-DAO message generalizes the DAO to signal to a given child. The P-DAO message generalizes the DAO to signal to
the Track Ingress that a Track for which it is Root can be used to the Track Ingress that a Track for which it is Root can be used to
reach children and siblings of the Track Egress. In both cases, reach children and siblings of the Track Egress. In both cases,
options may be factorized and multiple RTOs may be present to signal options may be factorized and multiple RTOs may be present to signal
a collection of children that can be reached through the parent or a collection of children that can be reached through the parent or
the Track, respectively. the Track, respectively.
4.1.2. Projected DAO-ACK 4.1.2. Projected DAO-ACK
This document also Amends the DAO-ACK message. The new P flag THIS RFC also Amends the DAO-ACK message. The new P flag signals the
signals the projected form. projected form.
The format of the P-DAO-ACK message is thus as illustrated in The format of the P-DAO-ACK message is thus as illustrated in
Figure 9: Figure 9:
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| TrackID |D|P| Reserved | DAOSequence | Status | | TrackID |D|P| Reserved | DAOSequence | Status |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
skipping to change at page 39, line 13 skipping to change at page 39, line 13
and it is set to 0 otherwise. and it is set to 0 otherwise.
The D flag is set to one to signal that the DODAGID field is present. The D flag is set to one to signal that the DODAGID field is present.
It may be set to zero if and only if the source address of the P-DAO- It may be set to zero if and only if the source address of the P-DAO-
ACK message is set to the IPv6 address that serves as DODAGID and it ACK message is set to the IPv6 address that serves as DODAGID and it
MUST be set to one otherwise, meaning that the DODAGID field MUST MUST be set to one otherwise, meaning that the DODAGID field MUST
then be present. then be present.
4.1.3. Via Information Option 4.1.3. Via Information Option
This document Extends the CMO to create new objects called the Via THIS RFC Extends the CMO to create new objects called the Via
Information Options (VIO). The VIOs are the multihop alternative to Information Options (VIO). The VIOs are the multihop alternative to
the TIO, more in Section 5.3. One VIO is the stateful Storing Mode the TIO, more in Section 5.3. One VIO is the stateful Storing Mode
VIO (SM-VIO); an SM-VIO installs a strict hop-by-hop P-Route called a VIO (SM-VIO); an SM-VIO installs a strict hop-by-hop P-Route called a
Track Segment. The other is the Non-Storing Mode VIO (NSM-VIO); the Track Segment. The other is the Non-Storing Mode VIO (NSM-VIO); the
NSM-VIO installs a loose source-routed P-Route called a Track Leg at NSM-VIO installs a loose source-routed P-Route called a Track Leg at
the Track Ingress, which uses that state to encapsulate a packet the Track Ingress, which uses that state to encapsulate a packet
IPv6_in_IPv6 with a new Routing Header (RH) to the Track Egress, more IPv6_in_IPv6 with a new Routing Header (RH) to the Track Egress, more
in Section 6.7. in Section 6.7.
A P-DAO contains one or more RTOs to indicate the Target A P-DAO contains one or more RTOs to indicate the Target
skipping to change at page 69, line 37 skipping to change at page 69, line 37
P-DAO. P-DAO.
Note that the Path Sequence and Lifetime in the TIO are selected by Note that the Path Sequence and Lifetime in the TIO are selected by
the Root, and that the Target/Transit information tupples in the the Root, and that the Target/Transit information tupples in the
P-DAO are not those received by the Root in the DAO messages about P-DAO are not those received by the Root in the DAO messages about
the said Targets. The Track may follow sibling routes and does not the said Targets. The Track may follow sibling routes and does not
need to be congruent with the Main DODAG. need to be congruent with the Main DODAG.
8. Profiles 8. Profiles
This document provides a set of tools that may or may not be needed THIS RFC provides a set of tools that may or may not be needed by an
by an implementation depending on the type of application it serves. implementation depending on the type of application it serves. This
This sections described profiles that can be implemented separately sections described profiles that can be implemented separately and
and can be used to discriminate what an implementation can and cannot can be used to discriminate what an implementation can and cannot do.
do. This section describes profiles that enable to implement only a This section describes profiles that enable to implement only a
portion of this specification to meet a particular use case. portion of this specification to meet a particular use case.
Profiles 0 to 2 operate in the Main RPL Instance and do not require Profiles 0 to 2 operate in the Main RPL Instance and do not require
the support of local RPL Instances or the indication of the RPL the support of local RPL Instances or the indication of the RPL
Instance in the data plane. Profile 3 and above leverage Local RPL Instance in the data plane. Profile 3 and above leverage Local RPL
Instances to build arbitrary Tracks Rooted at the Track Ingress and Instances to build arbitrary Tracks Rooted at the Track Ingress and
using its namespace for TrackID. using its namespace for TrackID.
Profiles 0 and 1 are REQUIRED by all implementations that may be used Profiles 0 and 1 are REQUIRED by all implementations that may be used
in LLNs; Profiles 1 leverages Storing Mode to reduce the size of the in LLNs; Profiles 1 leverages Storing Mode to reduce the size of the
skipping to change at page 73, line 18 skipping to change at page 73, line 18
| 0 (suggested) | Projected Routes Support (D) | THIS RFC | | 0 (suggested) | Projected Routes Support (D) | THIS RFC |
+---------------+------------------------------+-----------+ +---------------+------------------------------+-----------+
Table 21: New DODAG Configuration Option Flag Table 21: New DODAG Configuration Option Flag
IANA is requested to add [THIS RFC] as a reference for MOP 7 in the IANA is requested to add [THIS RFC] as a reference for MOP 7 in the
RPL Mode of Operation registry. RPL Mode of Operation registry.
11.2. Elective 6LoWPAN Routing Header Type 11.2. Elective 6LoWPAN Routing Header Type
This document updates the IANA registry titled "Elective 6LoWPAN THIS RFC updates the IANA registry titled "Elective 6LoWPAN Routing
Routing Header Type" that was created for [RFC8138] and assigns the Header Type" that was created for [RFC8138] and assigns the following
following value: value:
+===============+=============+===============+ +===============+=============+===========+
| Value | Description | Reference | | Value | Description | Reference |
+===============+=============+===============+ +===============+=============+===========+
| 8 (Suggested) | P-RPI-6LoRH | This document | | 8 (Suggested) | P-RPI-6LoRH | THIS RFC |
+---------------+-------------+---------------+ +---------------+-------------+-----------+
Table 22: New Elective 6LoWPAN Routing Table 22: New Elective 6LoWPAN Routing
Header Type Header Type
11.3. Critical 6LoWPAN Routing Header Type 11.3. Critical 6LoWPAN Routing Header Type
This document updates the IANA registry titled "Critical 6LoWPAN THIS RFC updates the IANA registry titled "Critical 6LoWPAN Routing
Routing Header Type" that was created for [RFC8138] and assigns the Header Type" that was created for [RFC8138] and assigns the following
following value: value:
+===============+=============+===============+ +===============+=============+===========+
| Value | Description | Reference | | Value | Description | Reference |
+===============+=============+===============+ +===============+=============+===========+
| 8 (Suggested) | P-RPI-6LoRH | This document | | 8 (Suggested) | P-RPI-6LoRH | THIS RFC |
+---------------+-------------+---------------+ +---------------+-------------+-----------+
Table 23: New Critical 6LoWPAN Routing Table 23: New Critical 6LoWPAN Routing
Header Type Header Type
11.4. Subregistry For The RPL Option Flags 11.4. Subregistry For The RPL Option Flags
IANA is required to create a subregistry for the 8-bit RPL Option IANA is required to create a subregistry for the 8-bit RPL Option
Flags field, as detailed in Figure 11, under the "Routing Protocol Flags field, as detailed in Figure 11, under the "Routing Protocol
for Low Power and Lossy Networks (RPL)" registry. The bits are for Low Power and Lossy Networks (RPL)" registry. The bits are
indexed from 0 (leftmost) to 7. Each bit is Tracked with the indexed from 0 (leftmost) to 7. Each bit is Tracked with the
skipping to change at page 74, line 14 skipping to change at page 74, line 14
* Bit number (counting from bit 0 as the most significant bit) * Bit number (counting from bit 0 as the most significant bit)
* Indication When Set * Indication When Set
* Reference * Reference
Registration procedure is "Standards Action" [RFC8126]. The initial Registration procedure is "Standards Action" [RFC8126]. The initial
allocation is as indicated in Table 27: allocation is as indicated in Table 27:
+===============+======================+===============+ +===============+======================+===========+
| Bit number | Indication When Set | Reference | | Bit number | Indication When Set | Reference |
+===============+======================+===============+ +===============+======================+===========+
| 0 | Down 'O' | [RFC6553] | | 0 | Down 'O' | [RFC6553] |
+---------------+----------------------+---------------+ +---------------+----------------------+-----------+
| 1 | Rank-Error (R) | [RFC6553] | | 1 | Rank-Error (R) | [RFC6553] |
+---------------+----------------------+---------------+ +---------------+----------------------+-----------+
| 2 | Forwarding-Error (F) | [RFC6553] | | 2 | Forwarding-Error (F) | [RFC6553] |
+---------------+----------------------+---------------+ +---------------+----------------------+-----------+
| 3 (Suggested) | Projected-Route (P) | This document | | 3 (Suggested) | Projected-Route (P) | THIS RFC |
+---------------+----------------------+---------------+ +---------------+----------------------+-----------+
Table 24: Initial PDR Flags Table 24: Initial PDR Flags
11.5. RPL Control Codes 11.5. RPL Control Codes
This document extends the IANA Subregistry created by RFC 6550 for THIS RFC extends the IANA Subregistry created by RFC 6550 for RPL
RPL Control Codes as indicated in Table 25: Control Codes as indicated in Table 25:
+==================+=============================+===============+ +==================+=============================+===========+
| Code | Description | Reference | | Code | Description | Reference |
+==================+=============================+===============+ +==================+=============================+===========+
| 0x09 (Suggested) | Projected DAO Request (PDR) | This document | | 0x09 (Suggested) | Projected DAO Request (PDR) | THIS RFC |
+------------------+-----------------------------+---------------+ +------------------+-----------------------------+-----------+
| 0x0A (Suggested) | PDR-ACK | This document | | 0x0A (Suggested) | PDR-ACK | THIS RFC |
+------------------+-----------------------------+---------------+ +------------------+-----------------------------+-----------+
Table 25: New RPL Control Codes Table 25: New RPL Control Codes
11.6. RPL Control Message Options 11.6. RPL Control Message Options
This document extends the IANA Subregistry created by RFC 6550 for THIS RFC extends the IANA Subregistry created by RFC 6550 for RPL
RPL Control Message Options as indicated in Table 26: Control Message Options as indicated in Table 26:
+==================+=============================+===============+ +==================+=============================+===========+
| Value | Meaning | Reference | | Value | Meaning | Reference |
+==================+=============================+===============+ +==================+=============================+===========+
| 0x0E (Suggested) | Stateful VIO (SM-VIO) | This document | | 0x0E (Suggested) | Stateful VIO (SM-VIO) | THIS RFC |
+------------------+-----------------------------+---------------+ +------------------+-----------------------------+-----------+
| 0x0F (Suggested) | Source-Routed VIO (NSM-VIO) | This document | | 0x0F (Suggested) | Source-Routed VIO (NSM-VIO) | THIS RFC |
+------------------+-----------------------------+---------------+ +------------------+-----------------------------+-----------+
| 0x10 (Suggested) | Sibling Information option | This document | | 0x10 (Suggested) | Sibling Information option | THIS RFC |
+------------------+-----------------------------+---------------+ +------------------+-----------------------------+-----------+
Table 26: RPL Control Message Options Table 26: RPL Control Message Options
11.7. SubRegistry for the Projected DAO Request Flags 11.7. 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
Registration procedure is "Standards Action" [RFC8126]. The initial Registration procedure is "Standards Action" [RFC8126]. The initial
allocation is as indicated in Table 27: allocation is as indicated in Table 27:
+============+========================+===============+ +============+========================================+===========+
| Bit number | Capability description | Reference | | Bit number | Capability description | Reference |
+============+========================+===============+ +============+========================================+===========+
| 0 | PDR-ACK request (K) | This document | | 0 | PDR-ACK request (K) | THIS RFC |
+------------+------------------------+---------------+ +------------+----------------------------------------+-----------+
| 1 | Requested path should | This document | | 1 | Requested path should be redundant (R) | THIS RFC |
| | be redundant (R) | | +------------+----------------------------------------+-----------+
+------------+------------------------+---------------+
Table 27: Initial PDR Flags Table 27: Initial PDR Flags
11.8. SubRegistry for the PDR-ACK Flags 11.8. 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)
skipping to change at page 76, line 18 skipping to change at page 76, line 18
IANA is requested to create a Subregistry for the PDR-ACK Acceptance IANA is requested to create a Subregistry for the PDR-ACK 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 28: * Initial allocation is as indicated in Table 28:
+-------+------------------------+---------------+ +-------+------------------------+-----------+
| Value | Meaning | Reference | | Value | Meaning | Reference |
+-------+------------------------+---------------+ +-------+------------------------+-----------+
| 0 | Unqualified Acceptance | This document | | 0 | Unqualified Acceptance | THIS RFC |
+-------+------------------------+---------------+ +-------+------------------------+-----------+
Table 28: Acceptance values of the PDR-ACK Status Table 28: Acceptance values of the PDR-ACK
Status
11.10. Subregistry for the PDR-ACK Rejection Status Values 11.10. Subregistry for the PDR-ACK Rejection Status Values
IANA is requested to create a Subregistry for the PDR-ACK Rejection IANA is requested to create a Subregistry for the PDR-ACK 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 29: * Initial allocation is as indicated in Table 29:
+-------+-----------------------+---------------+ +-------+-----------------------+-----------+
| Value | Meaning | Reference | | Value | Meaning | Reference |
+-------+-----------------------+---------------+ +-------+-----------------------+-----------+
| 0 | Unqualified Rejection | This document | | 0 | Unqualified Rejection | THIS RFC |
+-------+-----------------------+---------------+ +-------+-----------------------+-----------+
| 1 | Transient Failure | This document | | 1 | Transient Failure | THIS RFC |
+-------+-----------------------+---------------+ +-------+-----------------------+-----------+
Table 29: Rejection values of the PDR-ACK Status Table 29: Rejection values of the PDR-ACK
Status
11.11. SubRegistry for the Via Information Options Flags 11.11. SubRegistry for the Via Information Options Flags
IANA is requested to create a Subregistry for the 5-bit Via IANA is requested to create a Subregistry for the 5-bit Via
Information Options (Via Information Option) Flags field. Each bit Information Options (Via Information Option) Flags field. Each bit
is Tracked with the following qualities: is Tracked with the following qualities:
* Bit number (counting from bit 0 as the most significant bit) * Bit number (counting from bit 0 as the most significant bit)
* Capability description * Capability description
skipping to change at page 77, line 33 skipping to change at page 77, line 39
* Capability description * Capability description
* Reference * Reference
Registration procedure is "Standards Action" [RFC8126]. The initial Registration procedure is "Standards Action" [RFC8126]. The initial
allocation is as indicated in Table 30: allocation is as indicated in Table 30:
+===============+========================+===========+ +===============+========================+===========+
| Bit number | Capability description | Reference | | Bit number | Capability description | Reference |
+===============+========================+===========+ +===============+========================+===========+
| 0 (Suggested) | "S" flag: Sibling in | This | | 0 (Suggested) | "S" flag: Sibling in | THIS RFC |
| | same DODAG as Self | document | | | same DODAG as Self | |
+---------------+------------------------+-----------+ +---------------+------------------------+-----------+
Table 30: Initial SIO Flags Table 30: Initial SIO Flags
11.13. Destination Advertisement Object Flag 11.13. Destination Advertisement Object Flag
This document modifies the "Destination Advertisement Object (DAO) THIS RFC modifies the "Destination Advertisement Object (DAO) Flags"
Flags" registry initially created in Section 20.11 of [RPL] . registry initially created in Section 20.11 of [RPL] .
Section 4.1.1 also defines one new entry in the Registry as follows: Section 4.1.1 also defines one new entry in the Registry as follows:
+---------------+------------------------+-----------+ +---------------+------------------------+-----------+
| Bit Number | Capability Description | Reference | | Bit Number | Capability Description | Reference |
+---------------+------------------------+-----------+ +---------------+------------------------+-----------+
| 2 (Suggested) | Projected DAO (P) | THIS RFC | | 2 (Suggested) | Projected DAO (P) | THIS RFC |
+---------------+------------------------+-----------+ +---------------+------------------------+-----------+
Table 31: New Destination Advertisement Object Table 31: New Destination Advertisement Object
(DAO) Flag (DAO) Flag
11.14. Destination Advertisement Object Acknowledgment Flag 11.14. Destination Advertisement Object Acknowledgment Flag
This document modifies the "Destination Advertisement Object (DAO) THIS RFC modifies the "Destination Advertisement Object (DAO)
Acknowledgment Flags" registry initially created in Section 20.12 of Acknowledgment Flags" registry initially created in Section 20.12 of
[RPL] . [RPL] .
Section 4.1.2 also defines one new entry in the Registry as follows: Section 4.1.2 also defines one new entry in the Registry as follows:
+---------------+------------------------+-----------+ +---------------+------------------------+-----------+
| Bit Number | Capability Description | Reference | | Bit Number | Capability Description | Reference |
+---------------+------------------------+-----------+ +---------------+------------------------+-----------+
| 1 (Suggested) | Projected DAO-ACK (P) | THIS RFC | | 1 (Suggested) | Projected DAO-ACK (P) | THIS RFC |
+---------------+------------------------+-----------+ +---------------+------------------------+-----------+
skipping to change at page 79, line 26 skipping to change at page 79, line 26
| 6..63 | Unassigned | | | 6..63 | Unassigned | |
+---------------+-------------------------+-----------+ +---------------+-------------------------+-----------+
Table 33: Rejection values of the RPL Status Table 33: Rejection values of the RPL Status
12. Acknowledgments 12. Acknowledgments
The authors wish to acknowledge JP Vasseur, Remy Liubing, James The authors wish to acknowledge JP Vasseur, Remy Liubing, James
Pylakutty, and Patrick Wetterwald for their contributions to the Pylakutty, and Patrick Wetterwald for their contributions to the
ideas developed here. Many thanks to Dominique Barthel and SVR Anand ideas developed here. Many thanks to Dominique Barthel and SVR Anand
for their global contribution to 6TiSCH, RAW and this document, as for their global contribution to 6TiSCH, RAW and this RFC, as well as
well as text suggestions that were incorporated. Also special thanks text suggestions that were incorporated. Also special thanks Li Zhao
Toerless Eckert for his deep review, with many excellent suggestions and Toerless Eckert for their in-depth reviews, with many excellent
that improved the readability and well as the content of the suggestions that improved the readability and well as the content of
specification. Many thanks to Remous-Aris Koutsiamanis for his the specification. Many thanks to Remous-Aris Koutsiamanis for his
review during WGLC. review during WGLC.
13. Normative References 13. Normative References
[INT-ARCHI] [INT-ARCHI]
Braden, R., Ed., "Requirements for Internet Hosts - Braden, R., Ed., "Requirements for Internet Hosts -
Communication Layers", STD 3, RFC 1122, Communication Layers", STD 3, RFC 1122,
DOI 10.17487/RFC1122, October 1989, DOI 10.17487/RFC1122, October 1989,
<https://www.rfc-editor.org/info/rfc1122>. <https://www.rfc-editor.org/info/rfc1122>.
skipping to change at page 83, line 8 skipping to change at page 83, line 8
[RFC9035] Thubert, P., Ed. and L. Zhao, "A Routing Protocol for Low- [RFC9035] Thubert, P., Ed. and L. Zhao, "A Routing Protocol for Low-
Power and Lossy Networks (RPL) Destination-Oriented Power and Lossy Networks (RPL) Destination-Oriented
Directed Acyclic Graph (DODAG) Configuration Option for Directed Acyclic Graph (DODAG) Configuration Option for
the 6LoWPAN Routing Header", RFC 9035, the 6LoWPAN Routing Header", RFC 9035,
DOI 10.17487/RFC9035, April 2021, DOI 10.17487/RFC9035, April 2021,
<https://www.rfc-editor.org/info/rfc9035>. <https://www.rfc-editor.org/info/rfc9035>.
[RAW-ARCHI] [RAW-ARCHI]
Thubert, P. and G. Z. Papadopoulos, "Reliable and Thubert, P. and G. Z. Papadopoulos, "Reliable and
Available Wireless Architecture", Work in Progress, Available Wireless Architecture", Work in Progress,
Internet-Draft, draft-ietf-raw-architecture-03, 14 January Internet-Draft, draft-ietf-raw-architecture-04, 4 March
2022, <https://datatracker.ietf.org/doc/html/draft-ietf- 2022, <https://datatracker.ietf.org/doc/html/draft-ietf-
raw-architecture-03>. raw-architecture-04>.
[USE-CASES] [USE-CASES]
Bernardos, C. J., Papadopoulos, G. Z., Thubert, P., and F. Bernardos, C. J., Papadopoulos, G. Z., Thubert, P., and F.
Theoleyre, "RAW use-cases", Work in Progress, Internet- Theoleyre, "RAW use-cases", Work in Progress, Internet-
Draft, draft-ietf-raw-use-cases-05, 23 February 2022, Draft, draft-ietf-raw-use-cases-05, 23 February 2022,
<https://datatracker.ietf.org/doc/html/draft-ietf-raw-use- <https://datatracker.ietf.org/doc/html/draft-ietf-raw-use-
cases-05>. cases-05>.
[I-D.kuehlewind-update-tag] [I-D.kuehlewind-update-tag]
Kuehlewind, M. and S. Krishnan, "Definition of new tags Kuehlewind, M. and S. Krishnan, "Definition of new tags
for relations between RFCs", Work in Progress, Internet- for relations between RFCs", Work in Progress, Internet-
Draft, draft-kuehlewind-update-tag-04, 12 July 2021, Draft, draft-kuehlewind-update-tag-04, 12 July 2021,
<https://datatracker.ietf.org/doc/html/draft-kuehlewind- <https://datatracker.ietf.org/doc/html/draft-kuehlewind-
update-tag-04>. update-tag-04>.
[I-D.irtf-panrg-path-properties] [I-D.irtf-panrg-path-properties]
Enghardt, T. and C. Kraehenbuehl, "A Vocabulary of Path Enghardt, T. and C. Krähenbühl, "A Vocabulary of Path
Properties", Work in Progress, Internet-Draft, draft-irtf- Properties", Work in Progress, Internet-Draft, draft-irtf-
panrg-path-properties-04, 25 October 2021, panrg-path-properties-05, 7 March 2022,
<https://datatracker.ietf.org/doc/html/draft-irtf-panrg- <https://datatracker.ietf.org/doc/html/draft-irtf-panrg-
path-properties-04>. path-properties-05>.
[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/>.
Authors' Addresses Authors' Addresses
Pascal Thubert (editor) Pascal Thubert (editor)
Cisco Systems, Inc Cisco Systems, Inc
Building D Building D
45 Allee des Ormes - BP1200 45 Allee des Ormes - BP1200
 End of changes. 48 change blocks. 
136 lines changed or deleted 146 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/