< draft-ietf-roll-dao-projection-23.txt   draft-ietf-roll-dao-projection-24.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: 17 July 2022 Huawei Tech Expires: 29 August 2022 Huawei Tech
13 January 2022 M. Richardson
Sandelman
25 February 2022
Root initiated routing state in RPL Root initiated routing state in RPL
draft-ietf-roll-dao-projection-23 draft-ietf-roll-dao-projection-24
Abstract Abstract
This document extends RFC 6550, RFC 6553, and RFC 8138 to enable a This document extends RFC 6550, RFC 6553, and RFC 8138 to enable a
RPL Root to install and maintain Projected Routes within its DODAG, RPL Root to install and maintain Projected Routes within its DODAG,
along a selected set of nodes that may or may not include self, for a along 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
skipping to change at page 1, line 38 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 17 July 2022. This Internet-Draft will expire on 29 August 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.
Please review these documents carefully, as they describe your rights Please review these documents carefully, as they describe your rights
and restrictions with respect to this document. Code Components and restrictions with respect to this document. Code Components
extracted from this document must include Revised BSD License text as extracted from this document must include Revised BSD License text as
described in Section 4.e of the Trust Legal Provisions and are described in Section 4.e of the Trust Legal Provisions and are
provided without warranty as described in the Revised BSD License. provided without warranty as described in the Revised BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 4 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 4
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4
skipping to change at page 2, line 40 skipping to change at page 2, line 43
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 . . . . . . . . . . . . . 17
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 . . . . . . . . . . . . . . . . . . 37 4.1.2. Projected DAO-ACK . . . . . . . . . . . . . . . . . . 38
4.1.3. Via Information Option . . . . . . . . . . . . . . . 38 4.1.3. Via Information Option . . . . . . . . . . . . . . . 39
4.1.4. Sibling Information Option . . . . . . . . . . . . . 39 4.1.4. Sibling Information Option . . . . . . . . . . . . . 39
4.1.5. P-DAO Request . . . . . . . . . . . . . . . . . . . . 39 4.1.5. P-DAO Request . . . . . . . . . . . . . . . . . . . . 39
4.1.6. Extending the RPI . . . . . . . . . . . . . . . . . . 39 4.1.6. Amending the RPI . . . . . . . . . . . . . . . . . . 40
4.1.7. Additional Flag in the RPL DODAG Configuration 4.1.7. Additional Flag in the RPL DODAG Configuration
Option . . . . . . . . . . . . . . . . . . . . . . . 40 Option . . . . . . . . . . . . . . . . . . . . . . . 40
4.2. Extending RFC 6553 . . . . . . . . . . . . . . . . . . . 41 4.2. Extending RFC 6553 . . . . . . . . . . . . . . . . . . . 41
4.3. Extending RFC 8138 . . . . . . . . . . . . . . . . . . . 41 4.3. Extending RFC 8138 . . . . . . . . . . . . . . . . . . . 42
5. New RPL Control Messages and Options . . . . . . . . . . . . 43 5. New RPL Control Messages and Options . . . . . . . . . . . . 43
5.1. New P-DAO Request Control Message . . . . . . . . . . . . 43 5.1. New P-DAO Request Control Message . . . . . . . . . . . . 43
5.2. New PDR-ACK Control Message . . . . . . . . . . . . . . . 44 5.2. New PDR-ACK Control Message . . . . . . . . . . . . . . . 45
5.3. Via Information Options . . . . . . . . . . . . . . . . . 45 5.3. Via Information Options . . . . . . . . . . . . . . . . . 46
5.4. Sibling Information Option . . . . . . . . . . . . . . . 48 5.4. Sibling Information Option . . . . . . . . . . . . . . . 49
6. Root Initiated Routing State . . . . . . . . . . . . . . . . 50 6. Root Initiated Routing State . . . . . . . . . . . . . . . . 51
6.1. RPL Network Setup . . . . . . . . . . . . . . . . . . . . 50 6.1. RPL Network Setup . . . . . . . . . . . . . . . . . . . . 51
6.2. Requesting a Track . . . . . . . . . . . . . . . . . . . 51 6.2. Requesting a Track . . . . . . . . . . . . . . . . . . . 52
6.3. Identifying a Track . . . . . . . . . . . . . . . . . . . 52 6.3. Identifying a Track . . . . . . . . . . . . . . . . . . . 53
6.4. Installing a Track . . . . . . . . . . . . . . . . . . . 53 6.4. Installing a Track . . . . . . . . . . . . . . . . . . . 54
6.4.1. Signaling a Projected Route . . . . . . . . . . . . . 54 6.4.1. Signaling a Projected Route . . . . . . . . . . . . . 55
6.4.2. Installing a Track Segment with a Storing Mode 6.4.2. Installing a Track Segment with a Storing Mode
P-Route . . . . . . . . . . . . . . . . . . . . . . . 55 P-Route . . . . . . . . . . . . . . . . . . . . . . . 56
6.4.3. Installing a Track Leg with a Non-Storing Mode 6.4.3. Installing a Track Leg with a Non-Storing Mode
P-Route . . . . . . . . . . . . . . . . . . . . . . . 57 P-Route . . . . . . . . . . . . . . . . . . . . . . . 58
6.5. Tearing Down a P-Route . . . . . . . . . . . . . . . . . 59 6.5. Tearing Down a P-Route . . . . . . . . . . . . . . . . . 60
6.6. Maintaining a Track . . . . . . . . . . . . . . . . . . . 59 6.6. Maintaining a Track . . . . . . . . . . . . . . . . . . . 60
6.6.1. Maintaining a Track Segment . . . . . . . . . . . . . 60 6.6.1. Maintaining a Track Segment . . . . . . . . . . . . . 61
6.6.2. Maintaining a Track Leg . . . . . . . . . . . . . . . 60 6.6.2. Maintaining a Track Leg . . . . . . . . . . . . . . . 61
6.7. Encapsulating and Forwarding Along a Track . . . . . . . 61 6.7. Encapsulating and Forwarding Along a Track . . . . . . . 62
6.8. Compression of the RPL Artifacts . . . . . . . . . . . . 63 6.8. Compression of the RPL Artifacts . . . . . . . . . . . . 64
7. Lesser Constrained Variations . . . . . . . . . . . . . . . . 65 7. Lesser Constrained Variations . . . . . . . . . . . . . . . . 66
7.1. Storing Mode Main DODAG . . . . . . . . . . . . . . . . . 65 7.1. Storing Mode Main DODAG . . . . . . . . . . . . . . . . . 66
7.2. A Track as a Full DODAG . . . . . . . . . . . . . . . . . 67 7.2. A Track as a Full DODAG . . . . . . . . . . . . . . . . . 68
8. Profiles . . . . . . . . . . . . . . . . . . . . . . . . . . 68 8. Profiles . . . . . . . . . . . . . . . . . . . . . . . . . . 69
9. Backwards Compatibility . . . . . . . . . . . . . . . . . . . 70 9. Backwards Compatibility . . . . . . . . . . . . . . . . . . . 71
10. Security Considerations . . . . . . . . . . . . . . . . . . . 71 10. Security Considerations . . . . . . . . . . . . . . . . . . . 72
11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 71 11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 72
11.1. RPL DODAG Configuration Option Flag . . . . . . . . . . 71 11.1. RPL DODAG Configuration Option Flag . . . . . . . . . . 72
11.2. Elective 6LoWPAN Routing Header Type . . . . . . . . . . 72 11.2. Elective 6LoWPAN Routing Header Type . . . . . . . . . . 73
11.3. Critical 6LoWPAN Routing Header Type . . . . . . . . . . 72 11.3. Critical 6LoWPAN Routing Header Type . . . . . . . . . . 73
11.4. Subregistry For The RPL Option Flags . . . . . . . . . . 72 11.4. Subregistry For The RPL Option Flags . . . . . . . . . . 73
11.5. RPL Control Codes . . . . . . . . . . . . . . . . . . . 73 11.5. RPL Control Codes . . . . . . . . . . . . . . . . . . . 74
11.6. RPL Control Message Options . . . . . . . . . . . . . . 73 11.6. RPL Control Message Options . . . . . . . . . . . . . . 74
11.7. SubRegistry for the Projected DAO Request Flags . . . . 74 11.7. SubRegistry for the Projected DAO Request Flags . . . . 75
11.8. SubRegistry for the PDR-ACK Flags . . . . . . . . . . . 74 11.8. SubRegistry for the PDR-ACK Flags . . . . . . . . . . . 75
11.9. Subregistry for the PDR-ACK Acceptance Status Values . . 75 11.9. Subregistry for the PDR-ACK Acceptance Status Values . . 76
11.10. Subregistry for the PDR-ACK Rejection Status Values . . 75 11.10. Subregistry for the PDR-ACK Rejection Status Values . . 76
11.11. SubRegistry for the Via Information Options Flags . . . 75 11.11. SubRegistry for the Via Information Options Flags . . . 76
11.12. SubRegistry for the Sibling Information Option Flags . . 76 11.12. SubRegistry for the Sibling Information Option Flags . . 77
11.13. Destination Advertisement Object Flag . . . . . . . . . 76 11.13. Destination Advertisement Object Flag . . . . . . . . . 77
11.14. Destination Advertisement Object Acknowledgment Flag . . 77 11.14. Destination Advertisement Object Acknowledgment Flag . . 78
11.15. New ICMPv6 Error Code . . . . . . . . . . . . . . . . . 77 11.15. New ICMPv6 Error Code . . . . . . . . . . . . . . . . . 78
11.16. RPL Rejection Status values . . . . . . . . . . . . . . 77 11.16. RPL Rejection Status values . . . . . . . . . . . . . . 78
12. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 78 12. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 79
13. Normative References . . . . . . . . . . . . . . . . . . . . 78 13. Normative References . . . . . . . . . . . . . . . . . . . . 79
14. Informative References . . . . . . . . . . . . . . . . . . . 80 14. Informative References . . . . . . . . . . . . . . . . . . . 81
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 82 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 83
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 an anisotropic Distance Vector protocol that is well- (LLNs), is an anisotropic Distance Vector protocol that is well-
suited for application in a variety of low energy Internet of Things suited for application in a variety of low energy Internet of Things
(IoT) networks where stretched P2P paths are acceptable vs. the (IoT) networks where stretched P2P paths are acceptable vs. the
signaling and state overhead involved in maintaining shortest paths signaling and state overhead involved in maintaining shortest paths
across. across.
skipping to change at page 5, line 5 skipping to change at page 4, line 48
2. Terminology 2. Terminology
2.1. Requirements Language 2.1. Requirements Language
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described in BCP "OPTIONAL" in this document are to be interpreted as described in BCP
14 [RFC2119][RFC8174] when, and only when, they appear in all 14 [RFC2119][RFC8174] when, and only when, they appear in all
capitals, as shown here. capitals, as shown here.
In addition, the terms "Extends" and "Amends" are used as per
[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 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], the "6TiSCH Architecture" [6TiSCH-ARCHI], 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/Framework" [RAW-ARCHI], and "Terminology Wireless (RAW) Architecture" [RAW-ARCHI], and "Terminology in Low
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 document 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)
skipping to change at page 15, line 7 skipping to change at page 15, line 7
The requirement is to install additional routes in the RPL routers, The requirement is to install additional routes in the RPL routers,
to reduce the stretch of some P2P routes and maintain the to reduce the stretch of some P2P routes and maintain the
characteristics within a given SLO, e.g., in terms of latency and/or characteristics within a given SLO, e.g., in terms of latency and/or
reliability. reliability.
3.4. On Tracks 3.4. On Tracks
3.4.1. Building Tracks With RPL 3.4.1. Building Tracks With RPL
The concept of a Track was introduced in the "6TiSCH Architecture" The concept of a Track was introduced in the "6TiSCH Architecture"
[6TiSCH-ARCHI], as a collection of potential paths that leverage [RFC9030], as a collection of potential paths that leverage redundant
redundant forwarding solutions along the way. This can be a DODAG or forwarding solutions along the way. This can be a DODAG or a more
a more complex structure that is only partially acyclic (e.g., per complex structure that is only partially acyclic (e.g., per packet).
packet).
With this specification, a Track is shaped as a DODAG, and following With this specification, a Track is shaped as a DODAG, and following
the directed edges leads to a Track Ingress. Storing Mode P-DAO the directed edges leads to a Track Ingress. Storing Mode P-DAO
messages follow the direction of the edges to set up routes for messages follow the direction of the edges to set up routes for
traffic that flows the other way, towards the Track Egress(es). If traffic that flows the other way, towards the Track Egress(es). If
there is a single Track Egress, then the Track is reversible to form there is a single Track Egress, then the Track is reversible to form
another DODAG by reversing the direction of each edge. A node at the another DODAG by reversing the direction of each edge. A node at the
Ingress of more than one Segment in a Track may use one or more of Ingress of more than one Segment in a Track may use one or more of
these Segments to forward a packet inside the Track. these Segments to forward a packet inside the Track.
skipping to change at page 33, line 36 skipping to change at page 33, line 36
and the resources that are available in the devices and in the and the resources that are available in the devices and in the
network are out of scope for this document. The method to capture network are out of scope for this document. The method to capture
and report the LLN link capacity and reliability statistics are also and report the LLN link capacity and reliability statistics are also
out of scope. They may be fetched from the nodes through network out of scope. They may be fetched from the nodes through network
management functions or other forms of telemetry such as 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" [6TiSCH-ARCHI] leverages a centralized The "6TiSCH Architecture" [RFC9030] leverages a centralized model
model that is similar to that of "Deterministic Networking that is similar to that of "Deterministic Networking Architecture"
Architecture" [RFC8655], whereby the device resources and [RFC8655], whereby the device resources and capabilities are exposed
capabilities are exposed to an external controller which installs to an external controller which installs routing states into the
routing states into the network based on its own objective functions network based on its own objective functions that reside in that
that reside in that external entity. external entity.
3.7.2.2. Mapping to DetNet 3.7.2.2. Mapping to DetNet
DetNet Forwarding Nodes only understand the simple 1-to-1 forwarding DetNet Forwarding Nodes only understand the simple 1-to-1 forwarding
sublayer transport operation along a segment whereas the more sublayer transport operation along a segment whereas the more
sophisticated Relay nodes can also provide service sublayer functions sophisticated Relay nodes can also provide service sublayer functions
such as Replication and Elimination. such as Replication and Elimination.
One possible mapping between DetNet and this specification is to One possible mapping between DetNet and this specification is to
signal the Relay Nodes as the hops of a Leg and the forwarding Nodes signal the Relay Nodes as the hops of a Leg and the forwarding Nodes
skipping to change at page 34, line 40 skipping to change at page 34, line 40
and the metrics and link statistics involved in the computation are and the metrics and link statistics involved in the computation are
also out of scope. The effectiveness of the route computation by the also out of scope. The effectiveness of the route computation by the
PCE depends on the quality of the metrics that are reported from the PCE depends on the quality of the metrics that are reported from the
RPL network. Which metrics are used and how they are reported is out RPL network. Which metrics are used and how they are reported is out
of scope, but the expectation is that they are mostly of long-term, of scope, but the expectation is that they are mostly of long-term,
statistical nature, and provide visibility on link throughput, statistical nature, and provide visibility on link throughput,
latency, stability and availability over relatively long periods. latency, stability and availability over relatively long periods.
3.7.2.4. Providing for RAW 3.7.2.4. Providing for RAW
The "Reliable and Available Wireless (RAW) Architecture/Framework" The RAW Architecture [RAW-ARCHI] extends the definition of Track, as
[RAW-ARCHI] extends the definition of Track, as being composed of being composed of East-West directional segments and North-South
East-West directional segments and North-South bidirectional bidirectional segments, to enable additional path diversity, using
segments, to enable additional path diversity, using Packet ARQ, Packet ARQ, Replication, Elimination, and Overhearing (PAREO)
Replication, Elimination, and Overhearing (PAREO) functions over the functions over the available paths, to provide a dynamic balance
available paths, to provide a dynamic balance between the reliability between the reliability and availability requirements of the flows
and availability requirements of the flows and the need to conserve and the need to conserve energy and spectrum. This specification
energy and spectrum. This specification prepares for RAW by setting prepares for RAW by setting up the Tracks, but only forms DODAGs,
up the Tracks, but only forms DODAGs, which are composed of which are composed of aggregated end-to-end loose source routed Legs,
aggregated end-to-end loose source routed Legs, joined by strict joined by strict routed Segments, all oriented East-West.
routed Segments, all oriented East-West.
The RAW Architecture defines a dataplane extension of the PCE called The RAW Architecture defines a dataplane extension of the PCE called
the Path Selection Engine (PSE), that adapts the use of the path the Path Selection Engine (PSE), that adapts the use of the path
redundancy within a Track to defeat the diverse causes of packet redundancy within a Track to defeat the diverse causes of packet
loss. The PSE controls the forwarding operation of the packets loss. The PSE controls the forwarding operation of the packets
within a Track This specification can use but does not impose a PSE within a Track This specification can use but does not impose a PSE
and does not provide the policies that wouldselect which packets are and does not provide the policies that wouldselect which packets are
routed through which path within a Track, IOW, how the PSE may use routed through which path within a Track, IOW, how the PSE may use
the path redundancy within the Track. By default, the use of the the path redundancy within the Track. By default, the use of the
available redundancy is limited to simple load balancing, and all the available redundancy is limited to simple load balancing, and all the
skipping to change at page 35, line 25 skipping to change at page 35, line 25
A Track may be set up to reduce the load around the Root, or to A Track may be set up to reduce the load around the Root, or to
enable urgent traffic to flow more directly. This specification does enable urgent traffic to flow more directly. This specification does
not provide the policies that would decide which flows are routed not provide the policies that would decide which flows are routed
through which Track. In a Non-Storing Mode RPL Instance, the Main through which Track. In a Non-Storing Mode RPL Instance, the Main
DODAG provides a default route via the Root, and the Tracks provide DODAG provides a default route via the Root, and the Tracks provide
more specific routes to the Track Targets. more specific routes to the Track Targets.
4. Extending existing RFCs 4. Extending existing RFCs
This section explains which changes are extensions to existing
specifications, and which changes are amendments to existing
specification. It is expected that extensions to existing
specifications do not cause existing code on legacy 6LRs to
malfunction, as the extensions will simply be ignored. New code is
required for an extension. Those 6LRs will be unable to participate
in the new mechanisms, but may also cause projected DAOs to be
impossible to install. Amendments to existing specifications are
situations where there are semantic changes required to existing
code, and which may require new unit tests to confirm that legacy
operations will continue unaffected.
4.1. Extending RFC 6550 4.1. Extending RFC 6550
This specification extends RPL [RPL] to enable the Root to install This specification Extends RPL [RPL] to enable the Root to install
East-West routes inside a Main DODAG that is operated as Non-Storing East-West routes inside a Main DODAG that is operated as Non-Storing
Mode. The Root issues a Projected DAO (P-DAO) message (see Mode. The Root issues a Projected DAO (P-DAO) message (see
Section 4.1.1) to the Track Ingress; the P-DAO message contains a new Section 4.1.1) to the Track Ingress; the P-DAO message contains a new
Via Information Option (VIO) that installs a strict or a loose Via Information Option (VIO) that installs a strict or a loose
sequence of hops to form respectively a Track Segment or a Track Leg. sequence of hops to form respectively a Track Segment or a Track Leg.
A new P-DAO Request (PDR) message (see Section 5.1) enables a Track The new P-DAO Request (PDR) is a new message detailed in Section 5.1.
Ingress to request the Track from the Root. The resulting Track is As per [RPL] section 6, if a node receives this message and it does
also a DODAG for which the Track Ingress is the Root, the owner the not understand this new Code, then discards the message. When the
address that serves as DODAGID and authoritative for the associated root initiates to a node that it has not communicated with before,
namespace from which the TrackID is selected. In the context of this and to which it does not know if this specification has been
specification, the installed route appears as a more specific route implemented (by means such as capabilities), then the root SHOULD
to the Track Targets, and the Track Ingress routes the packets request a PDR-ACK.
towards the Targets via the Track using the longest match as usual.
A P-DAO Request (PDR) message enables a Track Ingress to request the
Track from the Root. The resulting Track is also a DODAG for which
the Track Ingress is the Root, the owner the address that serves as
DODAGID and authoritative for the associated namespace from which the
TrackID is selected. In the context of this specification, the
installed route appears as a more specific route to the Track
Targets, and the Track Ingress routes the packets towards the Targets
via the Track using the longest match as usual.
To ensure that the PDR and P-DAO messages can flow at most times, it To ensure that the PDR and P-DAO messages can flow at most times, it
is RECOMMENDED that the nodes involved in a Track maintain multiple is RECOMMENDED that the nodes involved in a Track maintain multiple
parents in the Main DODAG, advertise them all to the Root, and use parents in the Main DODAG, advertise them all to the Root, and use
them in turn to retry similar packets. It is also RECOMMENDED that them in turn to retry similar packets. It is also RECOMMENDED that
the Root uses diverse source route paths to retry similar messages to the Root uses diverse source route paths to retry similar messages to
the nodes in the Track. the nodes in the Track.
4.1.1. Projected DAO 4.1.1. Projected DAO
Section 6 of [RPL] introduces the RPL Control Message Options (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. A Projected DAO (P-DAO) is a hop information at a time in the TIO.
special DAO message generated by the Root to install a P-Route formed
of multiple hops in its DODAG. This provides a RPL-based method to This document Amends the specification of the DAO to create the P-DAO
install the Tracks as expected by the 6TiSCH Architecture message. This Amended DAO is signaled with a new "Projected DAO" (P)
[6TiSCH-ARCHI] as a collection of multiple P-Routes. flag, see Figure 8.
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
provides a RPL-based method to install the Tracks as expected by the
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
message that is not sent by the Root of its DODAG and MUST ignore message that is not sent by the Root of its DODAG and MUST ignore
such message silently. such message silently.
The P-DAO is signaled with a new "Projected DAO" (P) flag, see The 'P' flag is encoded in bit position 2 (to be confirmed by IANA)
Figure 8. The 'P' flag is encoded in bit position 2 (to be confirmed of the Flags field in the DAO Base Object. The Root MUST set it to 1
by IANA) of the Flags field in the DAO Base Object. The Root MUST in a Projected DAO message. Otherwise it MUST be set to 0. It is
set it to 1 in a Projected DAO message. Otherwise it MUST be set to set to 0 in Legacy implementations as specified respectively in
0. It is set to 0 in Legacy implementations as specified Sections 20.11 and 6.4 of [RPL].
respectively in Sections 20.11 and 6.4 of [RPL].
The P-DAO is control plane signaling and should not be stuck behind The P-DAO is control plane signaling and should not be stuck behind
high traffic levels. The expectation is that the P-DAO message is high traffic levels. The expectation is that the P-DAO message is
sent as high QoS level, above that of data traffic, typically with sent as high QoS level, above that of data traffic, typically with
the Network Control precedence. the Network Control precedence.
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| TrackID |K|D|P| Flags | Reserved | DAOSequence | | TrackID |K|D|P| Flags | Reserved | DAOSequence |
skipping to change at page 37, line 34 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
The changes in the P-DAO messages are reflected on the P-DAO-ACK This document also Amends the DAO-ACK message. The new P flag
message that is used to acknowledge a P-DAO, with the new P flag that signals the projected form.
signal the 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 38, line 41 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
New CMOs called the Via Information Options (VIO) are introduced for This document Extends the CMO to create new objects called the Via
use in P-DAO messages as a multihop alternative to the TIO, more in Information Options (VIO). The VIOs are the multihop alternative to
Section 5.3. One VIO is the stateful Storing Mode VIO (SM-VIO); an the TIO, more in Section 5.3. One VIO is the stateful Storing Mode
SM-VIO installs a strict hop-by-hop P-Route called a Track Segment. VIO (SM-VIO); an SM-VIO installs a strict hop-by-hop P-Route called a
The other is the Non-Storing Mode VIO (NSM-VIO); the NSM-VIO installs Track Segment. The other is the Non-Storing Mode VIO (NSM-VIO); the
a loose source-routed P-Route called a Track Leg at the Track NSM-VIO installs a loose source-routed P-Route called a Track Leg at
Ingress, which uses that state to encapsulate a packet IPv6_in_IPv6 the Track Ingress, which uses that state to encapsulate a packet
with a new Routing Header (RH) to the Track Egress, more in IPv6_in_IPv6 with a new Routing Header (RH) to the Track Egress, more
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
(destinations) that can be reached via the P-Route, followed by (destinations) that can be reached via the P-Route, followed by
exactly one VIO that signals the sequence of nodes to be followed, exactly one VIO that signals the sequence of nodes to be followed,
more in Section 6. There are two modes of operation for the more in Section 6. There are two modes of operation for the
P-Routes, the Storing Mode and the Non-Storing Mode, see P-Routes, the Storing Mode and the Non-Storing Mode, see
Section 6.4.2 and Section 6.4.3 respectively for more. Section 6.4.2 and Section 6.4.3 respectively for more.
4.1.4. Sibling Information Option 4.1.4. Sibling Information Option
This specification adds another CMO called the Sibling Information This specification Extends the CMO to create the Sibling Information
Option (SIO) that is used by a RPL Aware Node (RAN) to advertise a Option (SIO). The SIO is used by a RPL Aware Node (RAN) to advertise
selection of its candidate neighbors as siblings to the Root, more in a selection of its candidate neighbors as siblings to the Root, more
Section 5.4. The SIO is placed in DAO messages that are sent in Section 5.4. The SIO is placed in DAO messages that are sent
directly to the Root of the main DODAG. directly to the Root of the main DODAG.
4.1.5. P-DAO Request 4.1.5. P-DAO Request
Two new RPL Control Messages are also introduced, to enable a RPL- The set of RPL Control Messages is Extended to include the P-DAO
Aware Node to request the establishment of a Track between self as Request (PDR) and P-DAO Request Acknowledgement (PDR-ACK). These two
the Track Ingress Node and a Track Egress. The node makes its new RPL Control Messages enable an RPL-Aware Node to request the
request by sending a new P-DAO Request (PDR) Message to the Root. establishment of a Track between itself as the Track Ingress Node and
The Root confirms with a new PDR-ACK message back to the requester a Track Egress. The node makes its request by sending a new P-DAO
RAN, see Section 5.1 for more. Request (PDR) Message to the Root. The Root confirms with a new PDR-
ACK message back to the requester RAN, see Section 5.1 for more.
4.1.6. Extending the RPI 4.1.6. Amending the RPI
Sending a Packet within a RPL Local Instance requires the presence of Sending a Packet within a RPL Local Instance requires the presence of
the abstract RPL Packet Information (RPI) described in section 11.2. the abstract RPL Packet Information (RPI) described in section 11.2.
of [RPL] in the outer IPv6 Header chain (see [RFC9008]). The RPI of [RPL] in the outer IPv6 Header chain (see [RFC9008]). The RPI
carries a local RPLInstanceID which, in association with either the carries a local RPLInstanceID which, in association with either the
source or the destination address in the IPv6 Header, indicates the source or the destination address in the IPv6 Header, indicates the
RPL Instance that the packet follows. RPL Instance that the packet follows.
This specification extends [RPL] to create a new flag that signals This specification Amends [RPL] to create a new flag that signals
that a packet is forwarded along a P-Route. that a packet is forwarded along a P-Route.
Projected-Route 'P': 1-bit flag. It is set to 1 in the RPI that is Projected-Route 'P': 1-bit flag. It is set to 1 in the RPI that is
added in the encapsulation when a packet is sent over a Track. It added in the encapsulation when a packet is sent over a Track. It
is set to 0 when a packet is forwarded along the main Track, is set to 0 when a packet is forwarded along the main Track,
including when the packet follows a Segment that joins loose hops including when the packet follows a Segment that joins loose hops
of the Main DODAG. The flag is not mutable en-route. of the Main DODAG. The flag is not mutable en-route.
The encoding of the 'P' flag in native format is shown in Section 4.2 The encoding of the 'P' flag in native format is shown in Section 4.2
while the compressed format is indicated in Section 4.3. while the compressed format is indicated in Section 4.3.
skipping to change at page 40, line 23 skipping to change at page 40, line 44
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 = 0x04 |Opt Length = 14|D| | | |A| ... | | Type = 0x04 |Opt Length = 14|D| | | |A| ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +
|4 bits | |4 bits |
Figure 10: DODAG Configuration Option (Partial View) Figure 10: DODAG Configuration Option (Partial View)
This specification defines a new flag "Projected Routes Support" (D). This specification Amends the specification to define a new flag
The 'D' flag is encoded in bit position 0 of the reserved Flags in "Projected Routes Support" (D). The 'D' flag is encoded in bit
the DODAG Configuration Option (this is the most significant bit)(to position 0 of the reserved Flags in the DODAG Configuration Option
be confirmed by IANA but there's little choice). It is set to 0 in (this is the most significant bit)(to be confirmed by IANA but
legacy implementations as specified respectively in Sections 20.14 there's little choice). It is set to 0 in legacy implementations as
and 6.7.6 of [RPL]. specified respectively in Sections 20.14 and 6.7.6 of [RPL].
The 'D' flag is set to 1 to indicate that this specification is The 'D' flag is set to 1 to indicate that this specification is
enabled in the network and that the Root will install the requested enabled in the network and that the Root will install the requested
Tracks when feasible upon a PDR message. Tracks when feasible upon a PDR message.
Section 4.1.2. of [RFC9008] updates [RPL] to indicate that the Section 4.1.2. of [RFC9008] updates [RPL] to indicate that the
definition of the Flags applies to Mode of Operation values from zero definition of the Flags applies to Mode of Operation values from zero
(0) to six (6) only. For a MOP value of 7, the implementation MUST (0) to six (6) only. For a MOP value of 7, the implementation MUST
consider that the Root accepts PDR messages and will install consider that the Root accepts PDR messages and will install
Projected Routes. Projected Routes.
skipping to change at page 41, line 16 skipping to change at page 41, line 40
"The RPL Option for Carrying RPL Information in Data-Plane Datagrams" "The RPL Option for Carrying RPL Information in Data-Plane Datagrams"
[RFC6553]describes the RPL Option for use among RPL routers to [RFC6553]describes the RPL Option for use among RPL routers to
include the abstract RPL Packet Information (RPI) described in include the abstract RPL Packet Information (RPI) described in
section 11.2. of [RPL] in data packets. section 11.2. of [RPL] in data packets.
The RPL Option is commonly referred to as the RPI though the RPI is The RPL Option is commonly referred to as the RPI though the RPI is
really the abstract information that is transported in the RPL really the abstract information that is transported in the RPL
Option. [RFC9008] updated the Option Type from 0x63 to 0x23. Option. [RFC9008] updated the Option Type from 0x63 to 0x23.
This specification modifies the RPL Option to encode the 'P' flag as This specification Amends the RPL Option to encode the 'P' flag as
follows: 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Option Type | Opt Data Len | | Option Type | Opt Data Len |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|O|R|F|P|0|0|0|0| RPLInstanceID | SenderRank | |O|R|F|P|0|0|0|0| RPLInstanceID | SenderRank |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| (sub-TLVs) | | (sub-TLVs) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 11: Amended RPL Option Format
Figure 11: Extended RPL Option Format
Option Type: 0x23 or 0x63, see [RFC9008] Option Type: 0x23 or 0x63, see [RFC9008]
Opt Data Len: See [RFC6553] Opt Data Len: See [RFC6553]
'O', 'R' and 'F' flags: See [RFC6553]. Those flags MUST be set to 0 'O', 'R' and 'F' flags: See [RFC6553]. Those flags MUST be set to 0
by the sender and ignored by the receiver if the 'P' flag is set. by the sender and ignored by the receiver if the 'P' flag is set.
Projected-Route 'P': 1-bit flag as defined in Section 4.1.6. Projected-Route 'P': 1-bit flag as defined in Section 4.1.6.
skipping to change at page 42, line 28 skipping to change at page 43, line 5
code. The SRH-6LoRH is signaled in the NSM-VIO, in a fashion that it code. The SRH-6LoRH is signaled in the NSM-VIO, in a fashion that it
is ready to be placed as is in the packet encapsulation by the Track is ready to be placed as is in the packet encapsulation by the Track
Ingress. Ingress.
Section 6.3 of [RFC8138] presents the formats of the 6LoWPAN Routing Section 6.3 of [RFC8138] presents the formats of the 6LoWPAN Routing
Header of type 5 (RPI-6LoRH) that compresses the RPI for normal RPL Header of type 5 (RPI-6LoRH) that compresses the RPI for normal RPL
operation. The format of the RPI-6LoRH is not suited for P-Routes operation. The format of the RPI-6LoRH is not suited for P-Routes
since the O,R,F flags are not used and the Rank is unknown and since the O,R,F flags are not used and the Rank is unknown and
ignored. ignored.
This specification introduces a new 6LoRH, the P-RPI-6LoRH that can This specification extends [RFC8138] to introduce a new 6LoRH, the P-
be used in either Elective or Critical 6LoRH form, see Table 22 and RPI-6LoRH that can be used in either Elective or Critical 6LoRH form,
Table 23 respectively. The new 6LoRH MUST be used as a Critical see Table 22 and Table 23 respectively. The new 6LoRH MUST be used
6LoRH, unless an SRH-6LoRH is present and controls the routing as a Critical 6LoRH, unless an SRH-6LoRH is present and controls the
decision, in which case it MAY be used in Elective form. routing decision, in which case it MAY be used in Elective form.
The P-RPI-6LoRH is designed to compress the RPI along RPL P-Routes. The P-RPI-6LoRH is designed to compress the RPI along RPL P-Routes.
Its format is as follows: Its format is as follows:
0 1 2 0 1 2
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|1|0|E| Length | 6LoRH Type | RPLInstanceID | |1|0|E| Length | 6LoRH Type | RPLInstanceID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
skipping to change at page 43, line 33 skipping to change at page 44, line 10
terminated before its time and to do so, it MUST uses an asynchronous terminated before its time and to do so, it MUST uses an asynchronous
PDR-ACK with an negative status. A status of "Transient Failure" PDR-ACK with an negative status. A status of "Transient Failure"
(see Section 11.10) is an indication that the PDR may be retried (see Section 11.10) is an indication that the PDR may be retried
after a reasonable time that depends on the deployment. Other after a reasonable time that depends on the deployment. Other
negative status values indicate a permanent error; the tentative must negative status values indicate a permanent error; the tentative must
be abandoned until a corrective action is taken at the application be abandoned until a corrective action is taken at the application
layer or through network management. layer or through network management.
The source IPv6 address of the PDR signals the Track Ingress to-be of The source IPv6 address of the PDR signals the Track Ingress to-be of
the requested Track, and the TrackID is indicated in the message the requested Track, and the TrackID is indicated in the message
itself. One and only one RPL Target Option MUST be present in the itself. At least one RPL Target Option MUST be present in the
message. The RTO signals the Track Egress, more in Section 6.2. message. If more than one RPL Target Option is present, the Root
will provide a Track that reaches the first listed Target and a
subset of the other Targets; the details of the subset selection are
out of scope. The RTO signals the Track Egress, more in Section 6.2.
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)...
skipping to change at page 48, line 38 skipping to change at page 49, line 26
Storing Mode. Storing Mode.
To advertise a neighbor node, the router MUST have an active Address To advertise a neighbor node, the router MUST have an active Address
Registration from that sibling using [RFC8505], for an address (ULA Registration from that sibling using [RFC8505], for an address (ULA
or GUA) that serves as identifier for the node. If this router also or GUA) that serves as identifier for the node. If this router also
registers an address to that sibling, and the link has similar registers an address to that sibling, and the link has similar
properties in both directions, only the router with the lowest properties in both directions, only the router with the lowest
Interface ID in its registered address needs report the SIO, with the Interface ID in its registered address needs report the SIO, with the
B flag set, and the Root will assume symmetry. B flag set, and the Root will assume symmetry.
The SIO carries a flag (B) that is set when similar performances can
be expected both directions, so the routing can consider that the
information provided for one direction is valid for both. If the SIO
is effectively received from both sides then the B flag MUST be
ignored. The policy that describes the performance criteria, and how
they are asserted is out of scope. In the absence of an external
protocol to assert the link quality, the flag SHOULD NOT be set.
The format of the SIO is as follows: The format of the SIO is as follows:
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Option Length |S|B|Flags|Comp.| Opaque | | Type | Option Length |S|B|Flags|Comp.| Opaque |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Step in Rank | Reserved | | Step in Rank | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
skipping to change at page 61, line 14 skipping to change at page 62, line 14
6.7. Encapsulating and Forwarding Along a Track 6.7. Encapsulating and Forwarding Along a Track
When injecting a packet in a Track, the Ingress router must When injecting a packet in a Track, the Ingress router must
encapsulate the packet using IP-in-IP to add the Source Routing encapsulate the packet using IP-in-IP to add the Source Routing
Header with the final destination set to the Track Egress. Header with the final destination set to the Track Egress.
All properties of a Track operations are inherited form the main RPL All properties of a Track operations are inherited form the main RPL
Instance that is used to install the Track. For instance, the use of Instance that is used to install the Track. For instance, the use of
compression per [RFC8138] is determined by whether it is used in the compression per [RFC8138] is determined by whether it is used in the
RPL Main DODAG, e.g., by setting the "T" flag [TURN-ON_RFC8138] in RPL Main DODAG, e.g., by setting the "T" flag [RFC9035] in the RPL
the RPL configuration option. configuration option.
The Track Ingress that places a packet in a Track encapsulates it The Track Ingress that places a packet in a Track encapsulates it
with an IP-in-IP header, a Routing Header, and an IPv6 Hop-by-Hop with an IP-in-IP header, a Routing Header, and an IPv6 Hop-by-Hop
Option Header that contains the RPL Packet Information (RPI) as Option Header that contains the RPL Packet Information (RPI) as
follows: follows:
* In the uncompressed form the source of the packet is the address * In the uncompressed form the source of the packet is the address
that this router uses as DODAGID for the Track, the destination is that this router uses as DODAGID for the Track, the destination is
the first Via Address in the NSM-VIO, and the RH is a Source the first Via Address in the NSM-VIO, and the RH is a Source
Routing Header (SRH) [RFC6554] that contains the list of the Routing Header (SRH) [RFC6554] that contains the list of the
skipping to change at page 61, line 38 skipping to change at page 62, line 38
* The preferred alternate in a network where 6LoWPAN Header * The preferred alternate in a network where 6LoWPAN Header
Compression [RFC6282] is used is to leverage "IPv6 over Low-Power Compression [RFC6282] is used is to leverage "IPv6 over Low-Power
Wireless Personal Area Network (6LoWPAN) Paging Dispatch" Wireless Personal Area Network (6LoWPAN) Paging Dispatch"
[RFC8025] to compress the RPL artifacts as indicated in [RFC8138]. [RFC8025] to compress the RPL artifacts as indicated in [RFC8138].
In that case, the source routed header is the exact copy of the In that case, the source routed header is the exact copy of the
(chain of) SRH-6LoRH found in the NSM-VIO, also terminating by the (chain of) SRH-6LoRH found in the NSM-VIO, also terminating by the
Track Egress. The RPI-6LoRH is appended next, followed by an IP- Track Egress. The RPI-6LoRH is appended next, followed by an IP-
in-IP 6LoRH Header that indicates the Ingress router in the in-IP 6LoRH Header that indicates the Ingress router in the
Encapsulator Address field, see as a similar case Figure 20 of Encapsulator Address field, see as a similar case Figure 20 of
[TURN-ON_RFC8138]. [RFC9035].
To signal the Track in the packet, this specification leverages the To signal the Track in the packet, this specification leverages the
RPL Forwarding model follows: RPL Forwarding model follows:
* In the data packets, the Track DODAGID and the TrackID MUST be * In the data packets, the Track DODAGID and the TrackID MUST be
respectively signaled as the IPv6 Source Address and the respectively signaled as the IPv6 Source Address and the
RPLInstanceID field of the RPI 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,
skipping to change at page 68, line 5 skipping to change at page 69, line 5
* The Root has a complete topological information and statistical * The Root has a complete topological information and statistical
metrics that allow it or its PCE to perform a global optimization metrics that allow it or its PCE to perform a global optimization
of all Tracks in its DODAG. Based on that information, the Root of all Tracks in its DODAG. Based on that information, the Root
computes the Track Leg and predigest the source route paths. computes the Track Leg and predigest the source route paths.
* The node merely selects one of the proposed paths and applies the * The node merely selects one of the proposed paths and applies the
associated pre-computed routing header in the encapsulation. This associated pre-computed routing header in the encapsulation. This
alleviates both the complexity of computing a path and the alleviates both the complexity of computing a path and the
compressed form of the routing header. compressed form of the routing header.
The "Reliable and Available Wireless (RAW) Architecture/Framework" The RAW Architecture [RAW-ARCHI] actually expects the PSE at the
[RAW-ARCHI] actually expects the PSE at the Track Ingress to react to Track Ingress to react to changes in the forwarding conditions along
changes in the forwarding conditions along the Track, and reroute the Track, and reroute packets to maintain the required degree of
packets to maintain the required degree of reliability. To achieve reliability. To achieve this, the PSE need the full richness of a
this, the PSE need the full richness of a DODAG to form any path that DODAG to form any path that could make meet the Service Level
could make meet the Service Level Objective (SLO). Objective (SLO).
This section specifies the additions that are needed to turn the This section specifies the additions that are needed to turn the
Track into a full DODAG and enable the main Root to provide the Track into a full DODAG and enable the main Root to provide the
necessary topological information to the Track Ingress. The necessary topological information to the Track Ingress. The
expectation is that the metrics that the PSE uses are of an order expectation is that the metrics that the PSE uses are of an order
other than that of the PCE, because of the difference of time scale other than that of the PCE, because of the difference of time scale
between routing and forwarding, mor e in [RAW-ARCHI]. It follows between routing and forwarding, mor e in [RAW-ARCHI]. It follows
that the PSE will learn the metrics it needs from an alternate that the PSE will learn the metrics it needs from an alternate
source, e.g., OAM frames. source, e.g., OAM frames.
skipping to change at page 71, line 41 skipping to change at page 72, line 41
expects that the communication with the Root is authenticated but expects that the communication with the Root is authenticated but
does enforce which method is used. does enforce which method is used.
Additionally, the trust model could include a role validation (e.g., Additionally, the trust model could include a role validation (e.g.,
using a role-based authorization) to ensure that the node that claims using a role-based authorization) to ensure that the node that claims
to be a RPL Root is entitled to do so. That trust should propagate to be a RPL Root is entitled to do so. That trust should propagate
from Egress to Ingress in the case of a Storing Mode P-DAO. from Egress to Ingress in the case of a Storing Mode P-DAO.
This specification suggests some validation of the VIO to prevent This specification suggests some validation of the VIO to prevent
basic loops by avoiding that a node appears twice. But that is only basic loops by avoiding that a node appears twice. But that is only
a minimal protection. Arguably, an attacker tha can inject P-DAOs a minimal protection. Arguably, an attacker that can inject P-DAOs
can reroute any traffic and deplete critical resources such as can reroute any traffic and deplete critical resources such as
spectrum and battery in the LLN rapidly. spectrum and battery in the LLN rapidly.
11. IANA Considerations 11. IANA Considerations
11.1. RPL DODAG Configuration Option Flag 11.1. RPL DODAG Configuration Option Flag
IANA is requested to assign a flag from the "DODAG Configuration IANA is requested to assign a flag from the "DODAG Configuration
Option Flags for MOP 0..6" [RFC9010] registry as follows: Option Flags for MOP 0..6" [RFC9010] registry as follows:
skipping to change at page 78, line 27 skipping to change at page 79, line 27
+---------------+-------------------------+-----------+ +---------------+-------------------------+-----------+
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 document, as
well as text suggestions that were incorporated, and to Michael well as text suggestions that were incorporated. Also special thanks
Richardson for his useful recommendations based on his global view of Toerless Eckert for his deep review, with many excellent suggestions
the system all along the developement of this specification. Also that improved the readability and well as the content of the
special thanks Toerless Eckert for his deep review, with many specification. Many thanks to Remous-Aris Koutsiamanis for his
excellent suggestions that improved the readability and well as the review during WGLC.
content of the specification. Many thanks to Remous-Aris
Koutsiamanis for his 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>.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
skipping to change at page 79, line 10 skipping to change at page 80, line 10
Control Message Protocol (ICMPv6) for the Internet Control Message Protocol (ICMPv6) for the Internet
Protocol Version 6 (IPv6) Specification", STD 89, Protocol Version 6 (IPv6) Specification", STD 89,
RFC 4443, DOI 10.17487/RFC4443, March 2006, RFC 4443, DOI 10.17487/RFC4443, March 2006,
<https://www.rfc-editor.org/info/rfc4443>. <https://www.rfc-editor.org/info/rfc4443>.
[RFC4655] Farrel, A., Vasseur, J.-P., and J. Ash, "A Path [RFC4655] Farrel, A., Vasseur, J.-P., and J. Ash, "A Path
Computation Element (PCE)-Based Architecture", RFC 4655, Computation Element (PCE)-Based Architecture", RFC 4655,
DOI 10.17487/RFC4655, August 2006, DOI 10.17487/RFC4655, August 2006,
<https://www.rfc-editor.org/info/rfc4655>. <https://www.rfc-editor.org/info/rfc4655>.
[RFC5440] Vasseur, JP., Ed. and JL. Le Roux, Ed., "Path Computation
Element (PCE) Communication Protocol (PCEP)", RFC 5440,
DOI 10.17487/RFC5440, March 2009,
<https://www.rfc-editor.org/info/rfc5440>.
[RFC6282] Hui, J., Ed. and P. Thubert, "Compression Format for IPv6 [RFC6282] Hui, J., Ed. and P. Thubert, "Compression Format for IPv6
Datagrams over IEEE 802.15.4-Based Networks", RFC 6282, Datagrams over IEEE 802.15.4-Based Networks", RFC 6282,
DOI 10.17487/RFC6282, September 2011, DOI 10.17487/RFC6282, September 2011,
<https://www.rfc-editor.org/info/rfc6282>. <https://www.rfc-editor.org/info/rfc6282>.
[RPL] Winter, T., Ed., Thubert, P., Ed., Brandt, A., Hui, J., [RPL] Winter, T., Ed., Thubert, P., Ed., Brandt, A., Hui, J.,
Kelsey, R., Levis, P., Pister, K., Struik, R., Vasseur, Kelsey, R., Levis, P., Pister, K., Struik, R., Vasseur,
JP., and R. Alexander, "RPL: IPv6 Routing Protocol for JP., and R. Alexander, "RPL: IPv6 Routing Protocol for
Low-Power and Lossy Networks", RFC 6550, Low-Power and Lossy Networks", RFC 6550,
DOI 10.17487/RFC6550, March 2012, DOI 10.17487/RFC6550, March 2012,
skipping to change at page 79, line 39 skipping to change at page 80, line 34
Information in Data-Plane Datagrams", RFC 6553, Information in Data-Plane Datagrams", RFC 6553,
DOI 10.17487/RFC6553, March 2012, DOI 10.17487/RFC6553, March 2012,
<https://www.rfc-editor.org/info/rfc6553>. <https://www.rfc-editor.org/info/rfc6553>.
[RFC6554] Hui, J., Vasseur, JP., Culler, D., and V. Manral, "An IPv6 [RFC6554] Hui, J., Vasseur, JP., Culler, D., and V. Manral, "An IPv6
Routing Header for Source Routes with the Routing Protocol Routing Header for Source Routes with the Routing Protocol
for Low-Power and Lossy Networks (RPL)", RFC 6554, for Low-Power and Lossy Networks (RPL)", RFC 6554,
DOI 10.17487/RFC6554, March 2012, DOI 10.17487/RFC6554, March 2012,
<https://www.rfc-editor.org/info/rfc6554>. <https://www.rfc-editor.org/info/rfc6554>.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
May 2017, <https://www.rfc-editor.org/info/rfc8174>.
[RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for [RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for
Writing an IANA Considerations Section in RFCs", BCP 26, Writing an IANA Considerations Section in RFCs", BCP 26,
RFC 8126, DOI 10.17487/RFC8126, June 2017, RFC 8126, DOI 10.17487/RFC8126, June 2017,
<https://www.rfc-editor.org/info/rfc8126>. <https://www.rfc-editor.org/info/rfc8126>.
[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>.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
May 2017, <https://www.rfc-editor.org/info/rfc8174>.
[RFC8754] Filsfils, C., Ed., Dukes, D., Ed., Previdi, S., Leddy, J., [RFC8754] Filsfils, C., Ed., Dukes, D., Ed., Previdi, S., Leddy, J.,
Matsushima, S., and D. Voyer, "IPv6 Segment Routing Header Matsushima, S., and D. Voyer, "IPv6 Segment Routing Header
(SRH)", RFC 8754, DOI 10.17487/RFC8754, March 2020, (SRH)", RFC 8754, DOI 10.17487/RFC8754, March 2020,
<https://www.rfc-editor.org/info/rfc8754>. <https://www.rfc-editor.org/info/rfc8754>.
[RFC9008] Robles, M.I., Richardson, M., and P. Thubert, "Using RPI
Option Type, Routing Header for Source Routes, and IPv6-
in-IPv6 Encapsulation in the RPL Data Plane", RFC 9008,
DOI 10.17487/RFC9008, April 2021,
<https://www.rfc-editor.org/info/rfc9008>.
14. Informative References 14. Informative References
[6LoWPAN] Montenegro, G., Kushalnagar, N., Hui, J., and D. Culler, [6LoWPAN] Montenegro, G., Kushalnagar, N., Hui, J., and D. Culler,
"Transmission of IPv6 Packets over IEEE 802.15.4 "Transmission of IPv6 Packets over IEEE 802.15.4
Networks", RFC 4944, DOI 10.17487/RFC4944, September 2007, Networks", RFC 4944, DOI 10.17487/RFC4944, September 2007,
<https://www.rfc-editor.org/info/rfc4944>. <https://www.rfc-editor.org/info/rfc4944>.
[RFC7102] Vasseur, JP., "Terms Used in Routing for Low-Power and [RFC5440] Vasseur, JP., Ed. and JL. Le Roux, Ed., "Path Computation
Lossy Networks", RFC 7102, DOI 10.17487/RFC7102, January Element (PCE) Communication Protocol (PCEP)", RFC 5440,
2014, <https://www.rfc-editor.org/info/rfc7102>. DOI 10.17487/RFC5440, March 2009,
<https://www.rfc-editor.org/info/rfc5440>.
[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>.
[RFC7102] Vasseur, JP., "Terms Used in Routing for Low-Power and
Lossy Networks", RFC 7102, DOI 10.17487/RFC7102, January
2014, <https://www.rfc-editor.org/info/rfc7102>.
[RFC7416] Tsao, T., Alexander, R., Dohler, M., Daza, V., Lozano, A., [RFC7416] Tsao, T., Alexander, R., Dohler, M., Daza, V., Lozano, A.,
and M. Richardson, Ed., "A Security Threat Analysis for and M. Richardson, Ed., "A Security Threat Analysis for
the Routing Protocol for Low-Power and Lossy Networks the Routing Protocol for Low-Power and Lossy Networks
(RPLs)", RFC 7416, DOI 10.17487/RFC7416, January 2015, (RPLs)", RFC 7416, DOI 10.17487/RFC7416, January 2015,
<https://www.rfc-editor.org/info/rfc7416>. <https://www.rfc-editor.org/info/rfc7416>.
[6TiSCH-ARCHI]
Thubert, P., Ed., "An Architecture for IPv6 over the Time-
Slotted Channel Hopping Mode of IEEE 802.15.4 (6TiSCH)",
RFC 9030, DOI 10.17487/RFC9030, May 2021,
<https://www.rfc-editor.org/info/rfc9030>.
[RAW-ARCHI]
Thubert, P. and G. Z. Papadopoulos, "Reliable and
Available Wireless Architecture", Work in Progress,
Internet-Draft, draft-ietf-raw-architecture-02, 29
November 2021, <https://datatracker.ietf.org/doc/html/
draft-ietf-raw-architecture-02>.
[USE-CASES]
Papadopoulos, G. Z., Thubert, P., Theoleyre, F., and C. J.
Bernardos, "RAW use cases", Work in Progress, Internet-
Draft, draft-ietf-raw-use-cases-03, 20 October 2021,
<https://datatracker.ietf.org/doc/html/draft-ietf-raw-use-
cases-03>.
[TURN-ON_RFC8138]
Thubert, P., Ed. and L. Zhao, "A Routing Protocol for Low-
Power and Lossy Networks (RPL) Destination-Oriented
Directed Acyclic Graph (DODAG) Configuration Option for
the 6LoWPAN Routing Header", RFC 9035,
DOI 10.17487/RFC9035, April 2021,
<https://www.rfc-editor.org/info/rfc9035>.
[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>.
[RFC8402] Filsfils, C., Ed., Previdi, S., Ed., Ginsberg, L.,
Decraene, B., Litkowski, S., and R. Shakir, "Segment
Routing Architecture", RFC 8402, DOI 10.17487/RFC8402,
July 2018, <https://www.rfc-editor.org/info/rfc8402>.
[RFC8505] Thubert, P., Ed., Nordmark, E., Chakrabarti, S., and C. [RFC8505] Thubert, P., Ed., Nordmark, E., Chakrabarti, S., and C.
Perkins, "Registration Extensions for IPv6 over Low-Power Perkins, "Registration Extensions for IPv6 over Low-Power
Wireless Personal Area Network (6LoWPAN) Neighbor Wireless Personal Area Network (6LoWPAN) Neighbor
Discovery", RFC 8505, DOI 10.17487/RFC8505, November 2018, Discovery", RFC 8505, DOI 10.17487/RFC8505, November 2018,
<https://www.rfc-editor.org/info/rfc8505>. <https://www.rfc-editor.org/info/rfc8505>.
[RFC8402] Filsfils, C., Ed., Previdi, S., Ed., Ginsberg, L.,
Decraene, B., Litkowski, S., and R. Shakir, "Segment
Routing Architecture", RFC 8402, DOI 10.17487/RFC8402,
July 2018, <https://www.rfc-editor.org/info/rfc8402>.
[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>.
[RFC8930] Watteyne, T., Ed., Thubert, P., Ed., and C. Bormann, "On [RFC8930] Watteyne, T., Ed., Thubert, P., Ed., and C. Bormann, "On
Forwarding 6LoWPAN Fragments over a Multi-Hop IPv6 Forwarding 6LoWPAN Fragments over a Multi-Hop IPv6
Network", RFC 8930, DOI 10.17487/RFC8930, November 2020, Network", RFC 8930, DOI 10.17487/RFC8930, November 2020,
<https://www.rfc-editor.org/info/rfc8930>. <https://www.rfc-editor.org/info/rfc8930>.
[RFC8931] Thubert, P., Ed., "IPv6 over Low-Power Wireless Personal [RFC8931] Thubert, P., Ed., "IPv6 over Low-Power Wireless Personal
Area Network (6LoWPAN) Selective Fragment Recovery", Area Network (6LoWPAN) Selective Fragment Recovery",
RFC 8931, DOI 10.17487/RFC8931, November 2020, RFC 8931, DOI 10.17487/RFC8931, November 2020,
<https://www.rfc-editor.org/info/rfc8931>. <https://www.rfc-editor.org/info/rfc8931>.
[RFC8994] Eckert, T., Ed., Behringer, M., Ed., and S. Bjarnason, "An [RFC8994] Eckert, T., Ed., Behringer, M., Ed., and S. Bjarnason, "An
Autonomic Control Plane (ACP)", RFC 8994, Autonomic Control Plane (ACP)", RFC 8994,
DOI 10.17487/RFC8994, May 2021, DOI 10.17487/RFC8994, May 2021,
<https://www.rfc-editor.org/info/rfc8994>. <https://www.rfc-editor.org/info/rfc8994>.
[RFC9008] Robles, M.I., Richardson, M., and P. Thubert, "Using RPI
Option Type, Routing Header for Source Routes, and IPv6-
in-IPv6 Encapsulation in the RPL Data Plane", RFC 9008,
DOI 10.17487/RFC9008, April 2021,
<https://www.rfc-editor.org/info/rfc9008>.
[RFC9010] Thubert, P., Ed. and M. Richardson, "Routing for RPL [RFC9010] Thubert, P., Ed. and M. Richardson, "Routing for RPL
(Routing Protocol for Low-Power and Lossy Networks) (Routing Protocol for Low-Power and Lossy Networks)
Leaves", RFC 9010, DOI 10.17487/RFC9010, April 2021, Leaves", RFC 9010, DOI 10.17487/RFC9010, April 2021,
<https://www.rfc-editor.org/info/rfc9010>. <https://www.rfc-editor.org/info/rfc9010>.
[RFC9030] Thubert, P., Ed., "An Architecture for IPv6 over the Time-
Slotted Channel Hopping Mode of IEEE 802.15.4 (6TiSCH)",
RFC 9030, DOI 10.17487/RFC9030, May 2021,
<https://www.rfc-editor.org/info/rfc9030>.
[RFC9035] Thubert, P., Ed. and L. Zhao, "A Routing Protocol for Low-
Power and Lossy Networks (RPL) Destination-Oriented
Directed Acyclic Graph (DODAG) Configuration Option for
the 6LoWPAN Routing Header", RFC 9035,
DOI 10.17487/RFC9035, April 2021,
<https://www.rfc-editor.org/info/rfc9035>.
[RAW-ARCHI]
Thubert, P. and G. Z. Papadopoulos, "Reliable and
Available Wireless Architecture", Work in Progress,
Internet-Draft, draft-ietf-raw-architecture-03, 14 January
2022, <https://datatracker.ietf.org/doc/html/draft-ietf-
raw-architecture-03>.
[USE-CASES]
Bernardos, C. J., Papadopoulos, G. Z., Thubert, P., and F.
Theoleyre, "RAW use-cases", Work in Progress, Internet-
Draft, draft-ietf-raw-use-cases-05, 23 February 2022,
<https://datatracker.ietf.org/doc/html/draft-ietf-raw-use-
cases-05>.
[I-D.kuehlewind-update-tag]
Kuehlewind, M. and S. Krishnan, "Definition of new tags
for relations between RFCs", Work in Progress, Internet-
Draft, draft-kuehlewind-update-tag-04, 12 July 2021,
<https://datatracker.ietf.org/doc/html/draft-kuehlewind-
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. Kraehenbuehl, "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-04, 25 October 2021,
<https://datatracker.ietf.org/doc/html/draft-irtf-panrg- <https://datatracker.ietf.org/doc/html/draft-irtf-panrg-
path-properties-04>. path-properties-04>.
[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/>.
skipping to change at page 82, line 34 skipping to change at page 83, line 44
<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
06254 Mougins - Sophia Antipolis 06254 Mougins - Sophia Antipolis
France France
Phone: +33 497 23 26 34 Phone: +33 497 23 26 34
Email: pthubert@cisco.com Email: pthubert@cisco.com
Rahul Arvind Jadhav Rahul Arvind Jadhav
Huawei Tech Huawei Tech
Kundalahalli Village, Whitefield, Kundalahalli Village, Whitefield,
Bangalore 560037 Bangalore 560037
Karnataka Karnataka
India India
Phone: +91-080-49160700 Phone: +91-080-49160700
Email: rahul.ietf@gmail.com Email: rahul.ietf@gmail.com
Michael C. Richardson
Sandelman Software Works
Email: mcr+ietf@sandelman.ca
URI: http://www.sandelman.ca/
 End of changes. 53 change blocks. 
207 lines changed or deleted 245 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/