rfc9914.original   rfc9914.txt 
ROLL P. Thubert, Ed. Internet Engineering Task Force (IETF) P. Thubert, Ed.
Internet-Draft Request for Comments: 9914
Updates: 6550, 6553, 8138 (if approved) R.A. Jadhav Updates: 6550, 6553, 8138 R.A. Jadhav
Intended status: Standards Track AccuKnox Category: Standards Track AccuKnox
Expires: 11 September 2025 M. Richardson ISSN: 2070-1721 M. Richardson
Sandelman Sandelman
10 March 2025 February 2026
Root-initiated Routing State in RPL Root-Initiated Routing State in the Routing Protocol for Low-Power and
draft-ietf-roll-dao-projection-40 Lossy Networks (RPL)
Abstract Abstract
The Routing Protocol for Low-Power and Lossy Networks (RPL, RFC 6550) The Routing Protocol for Low-Power and Lossy Networks (RPL) (RFC
enables data packet routing along a Destination-Oriented Directed 6550) enables data packet routing along a Destination-Oriented
Acyclic Graph . However, the default route establishment mechanism Directed Acyclic Graph (DODAG). However, the default route
relies on hop-by-hop forwarding along the DODAG, which may not always establishment mechanism relies on hop-by-hop forwarding along the
provide optimal routing efficiency. This document introduces the DODAG, which may not always provide optimal routing efficiency. This
concept of DAO Projection, a mechanism that allows a RPL root or an document introduces the concept of Destination Advertisement Object
external controller to install optimized routes within the RPL (DAO) Projection, a mechanism that allows a RPL root or an external
domain. DAO Projections enable the creation of optimized unicast or controller to install optimized routes within the RPL domain. DAO
multicast routes that do not strictly follow the DODAG structure, Projections enable the creation of optimized unicast or multicast
thereby improving routing efficiency, reliability, availability, and routes that do not strictly follow the DODAG structure, thereby
resource utilization in the RPL domain. The document specifies two improving routing efficiency, reliability, availability, and resource
types of projected routes—storing mode and non-storing mode utilization in the RPL domain. This document specifies two types of
projections—and outlines the signaling procedures necessary to Projected Routes (P-Routes) -- Storing Mode and Non-Storing Mode --
establish, maintain, and remove these routes. This document extends and outlines the signaling procedures necessary to establish,
RFC 6550, RFC 6553, and RFC 8138. maintain, and remove these routes. This document updates RFCs 6550,
6553, and 8138.
Status of This Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This is an Internet Standards Track document.
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months This document is a product of the Internet Engineering Task Force
and may be updated, replaced, or obsoleted by other documents at any (IETF). It represents the consensus of the IETF community. It has
time. It is inappropriate to use Internet-Drafts as reference received public review and has been approved for publication by the
material or to cite them other than as "work in progress." Internet Engineering Steering Group (IESG). Further information on
Internet Standards is available in Section 2 of RFC 7841.
This Internet-Draft will expire on 11 September 2025. Information about the current status of this document, any errata,
and how to provide feedback on it may be obtained at
https://www.rfc-editor.org/info/rfc9914.
Copyright Notice Copyright Notice
Copyright (c) 2025 IETF Trust and the persons identified as the Copyright (c) 2026 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
license-info) in effect on the date of publication of this document. (https://trustee.ietf.org/license-info) in effect on the date of
Please review these documents carefully, as they describe your rights publication of this document. Please review these documents
and restrictions with respect to this document. Code Components carefully, as they describe your rights and restrictions with respect
extracted from this document must include Revised BSD License text as to this document. Code Components extracted from this document must
described in Section 4.e of the Trust Legal Provisions and are include Revised BSD License text as described in Section 4.e of the
provided without warranty as described in the Revised BSD License. Trust Legal Provisions and are provided without warranty as described
in the Revised BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 4 1. Introduction
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5 2. Terminology
2.1. Requirements Language . . . . . . . . . . . . . . . . . . 5 2.1. Requirements Language
2.2. References . . . . . . . . . . . . . . . . . . . . . . . 5 2.2. References
2.3. Glossary . . . . . . . . . . . . . . . . . . . . . . . . 6 2.3. Glossary
2.4. Domain Terms . . . . . . . . . . . . . . . . . . . . . . 7 2.4. Domain Terms
2.4.1. Projected Route . . . . . . . . . . . . . . . . . . . 7 2.4.1. Projected Route
2.4.2. Projected DAO . . . . . . . . . . . . . . . . . . . . 7 2.4.2. Projected DAO
2.4.3. Path . . . . . . . . . . . . . . . . . . . . . . . . 7 2.4.3. Path
2.4.4. Routing Stretch . . . . . . . . . . . . . . . . . . . 8 2.4.4. Routing Stretch
2.4.5. Track . . . . . . . . . . . . . . . . . . . . . . . . 8 2.4.5. Track
3. Context and Goal . . . . . . . . . . . . . . . . . . . . . . 11 3. Context and Goal
3.1. RPL Applicability . . . . . . . . . . . . . . . . . . . . 12 3.1. RPL Applicability
3.2. Multi-Topology Routing and Loop Avoidance . . . . . . . . 13 3.2. Multi-Topology Routing and Loop Avoidance
3.3. Requirements . . . . . . . . . . . . . . . . . . . . . . 15 3.3. Requirements
3.3.1. Loose Source Routing . . . . . . . . . . . . . . . . 15 3.3.1. Loose Source Routing
3.3.2. forward Routes . . . . . . . . . . . . . . . . . . . 17 3.3.2. Forward Routes
3.4. On Tracks . . . . . . . . . . . . . . . . . . . . . . . . 18 3.4. On Tracks
3.4.1. Building Tracks with RPL . . . . . . . . . . . . . . 18 3.4.1. Building Tracks with RPL
3.4.2. Tracks and RPL Instances . . . . . . . . . . . . . . 19 3.4.2. Tracks and RPL Instances
3.5. path Signaling . . . . . . . . . . . . . . . . . . . . . 20 3.5. Path Signaling
3.5.1. Using Storing Mode Segments . . . . . . . . . . . . . 22 3.5.1. Using Storing Mode Segments
3.5.2. Using Non-Storing Mode joining Tracks . . . . . . . . 29 3.5.2. Using Non-Storing Mode Joining Tracks
3.6. Complex Tracks . . . . . . . . . . . . . . . . . . . . . 36 3.6. Complex Tracks
3.7. Scope and Expectations . . . . . . . . . . . . . . . . . 38 3.7. Scope and Expectations
3.7.1. External Dependencies . . . . . . . . . . . . . . . . 38 3.7.1. External Dependencies
3.7.2. Positioning vs. Related IETF Standards . . . . . . . 38 3.7.2. Positioning Versus Related IETF Standards
4. Extending existing RFCs . . . . . . . . . . . . . . . . . . . 40 4. Extending Existing RFCs
4.1. Extending RPL RFC 6550 . . . . . . . . . . . . . . . . . 41 4.1. Extending RPL RFC 6550
4.1.1. Projected DAO . . . . . . . . . . . . . . . . . . . . 41 4.1.1. Projected DAO
4.1.2. Projected DAO-ACK . . . . . . . . . . . . . . . . . . 43 4.1.2. Projected DAO-ACK
4.1.3. Via Information Option . . . . . . . . . . . . . . . 44 4.1.3. Via Information Option
4.1.4. Sibling Information Option . . . . . . . . . . . . . 44 4.1.4. Sibling Information Option
4.1.5. P-DAO Request . . . . . . . . . . . . . . . . . . . . 45 4.1.5. P-DAO Request
4.1.6. Amending the RPI . . . . . . . . . . . . . . . . . . 45 4.1.6. Amending the RPI
4.1.7. Additional Flag in the RPL DODAG Configuration 4.1.7. Additional Flag in the RPL DODAG Configuration Option
Option . . . . . . . . . . . . . . . . . . . . . . . 46 4.2. Extending RPL RFC 6553
4.2. Extending RPL RFC 6553 . . . . . . . . . . . . . . . . . 47 4.3. Extending RPL RFC 8138
4.3. Extending RPL RFC 8138 . . . . . . . . . . . . . . . . . 48 5. New RPL Control Messages and Options
5. New RPL Control Messages and Options . . . . . . . . . . . . 49 5.1. New P-DAO Request Control Message
5.1. New P-DAO Request Control Message . . . . . . . . . . . . 49 5.2. New PDR-ACK Control Message
5.2. New PDR-ACK Control Message . . . . . . . . . . . . . . . 50 5.3. Via Information Options
5.3. Via Information Options . . . . . . . . . . . . . . . . . 52 5.4. Sibling Information Option
5.4. Sibling Information Option . . . . . . . . . . . . . . . 55 6. Root-Initiated Routing State
6. Root Initiated Routing State . . . . . . . . . . . . . . . . 57 6.1. RPL Network Setup
6.1. RPL Network Setup . . . . . . . . . . . . . . . . . . . . 57 6.2. Requesting a Track
6.2. Requesting a Track . . . . . . . . . . . . . . . . . . . 58 6.3. Identifying a Track
6.3. Identifying a Track . . . . . . . . . . . . . . . . . . . 59 6.4. Installing a Track
6.4. Installing a Track . . . . . . . . . . . . . . . . . . . 60 6.4.1. Signaling a Projected Route
6.4.1. Signaling a Projected Route . . . . . . . . . . . . . 61 6.4.2. Installing a Track Segment with a Storing Mode P-Route
6.4.2. Installing a Track Segment with a Storing Mode 6.4.3. Installing a Protection Path with a Non-Storing Mode
P-Route . . . . . . . . . . . . . . . . . . . . . . . 62 P-Route
6.4.3. Installing a protection path with a Non-Storing Mode 6.5. Tearing Down a P-Route
P-Route . . . . . . . . . . . . . . . . . . . . . . . 64 6.6. Maintaining a Track
6.5. Tearing Down a P-Route . . . . . . . . . . . . . . . . . 66 6.6.1. Maintaining a Track Segment
6.6. Maintaining a Track . . . . . . . . . . . . . . . . . . . 66 6.6.2. Maintaining a Protection Path
6.6.1. Maintaining a Track Segment . . . . . . . . . . . . . 67 6.7. Encapsulating and Forwarding Along a Track
6.6.2. Maintaining a protection path . . . . . . . . . . . . 67 6.8. Compression of RPL Artifacts
6.7. Encapsulating and Forwarding Along a Track . . . . . . . 68 7. Less-Constrained Variations
6.8. Compression of the RPL Artifacts . . . . . . . . . . . . 71 7.1. Storing Mode Main DODAG
7. Less-Constrained Variations . . . . . . . . . . . . . . . . . 73 7.2. A Track as a Full DODAG
7.1. Storing Mode main DODAG . . . . . . . . . . . . . . . . . 73 8. Profiles
7.2. A Track as a Full DODAG . . . . . . . . . . . . . . . . . 75 9. Backwards Compatibility
8. Profiles . . . . . . . . . . . . . . . . . . . . . . . . . . 76 10. Security Considerations
9. Backwards Compatibility . . . . . . . . . . . . . . . . . . . 78 11. IANA Considerations
10. Security Considerations . . . . . . . . . . . . . . . . . . . 78 11.1. RPL DODAG Configuration Option Flag
11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 79 11.2. Elective 6LoWPAN Routing Header Type
11.1. RPL DODAG Configuration Option Flag . . . . . . . . . . 79 11.3. Critical 6LoWPAN Routing Header Type
11.2. Elective 6LoWPAN Routing Header Type . . . . . . . . . . 80 11.4. Registry for RPL Option Flags
11.3. Critical 6LoWPAN Routing Header Type . . . . . . . . . . 80 11.5. RPL Control Codes
11.4. Registry For The RPL Option Flags . . . . . . . . . . . 80 11.6. RPL Control Message Options
11.5. RPL Control Codes . . . . . . . . . . . . . . . . . . . 81 11.7. Registry for Projected DAO Request Flags
11.6. RPL Control Message Options . . . . . . . . . . . . . . 81 11.8. Registry for PDR-ACK Flags
11.7. SubRegistry for the Projected DAO Request Flags . . . . 82 11.9. Registry for PDR-ACK Acceptance Status Values
11.8. SubRegistry for the PDR-ACK Flags . . . . . . . . . . . 82 11.10. Registry for PDR-ACK Rejection Status Values
11.9. Registry for the PDR-ACK Acceptance Status Values . . . 83 11.11. Registry for Via Information Options Flags
11.10. Registry for the PDR-ACK Rejection Status Values . . . . 83 11.12. Registry for Sibling Information Option Flags
11.11. SubRegistry for the Via Information Options Flags . . . 84 11.13. Destination Advertisement Object Flag
11.12. SubRegistry for the Sibling Information Option Flags . . 84 11.14. Destination Advertisement Object Acknowledgment Flag
11.13. Destination Advertisement Object Flag . . . . . . . . . 85 11.15. ICMPv6 Error Code
11.14. Destination Advertisement Object Acknowledgment Flag . . 85 11.16. RPL Rejection Status Values
11.15. New ICMPv6 Error Code . . . . . . . . . . . . . . . . . 86 12. References
11.16. RPL Rejection Status values . . . . . . . . . . . . . . 86 12.1. Normative References
12. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 86 12.2. Informative References
13. Normative References . . . . . . . . . . . . . . . . . . . . 87 Acknowledgments
14. Informative References . . . . . . . . . . . . . . . . . . . 88 Authors' Addresses
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 91
1. Introduction 1. Introduction
RPL, the "Routing Protocol for Low Power and Lossy Networks" [RPL] The Routing Protocol for Low-Power and Lossy Networks (RPL) [RPL], is
(LLNs), is a Distance Vector protocol, which is well-suited for a Distance Vector protocol that is well-suited for application in a
application in a variety of low energy Internet of Things (IoT) variety of low-energy Internet of Things (IoT) networks where
networks where constrained nodes cannot maintain the full view of the constrained nodes cannot maintain the full view of the topology and
topology, and stretched P2P paths are acceptable vs. the signaling stretched P2P paths are acceptable (versus the signaling and state
and state overhead involved in maintaining the shortest paths across. overhead involved in maintaining the shortest paths across).
Additionally, RPL is anisotropic, meaning that its operation depends Additionally, RPL is anisotropic, meaning that its operation depends
on the orientation of the links, down from or up towards the Root, on the orientation of the links, down from or up towards the Root,
with the default route advertised down and more specific paths with the default route advertised down and more-specific paths
advertised up along a limited set of links. advertised up along a limited set of links.
RPL forms Destination Oriented Directed Acyclic Graphs (DODAGs) in RPL forms Destination-Oriented Directed Acyclic Graphs (DODAGs) in
which the Root often acts as the Border router to connect the RPL which the Root often acts as the border router to connect the RPL
domain to the IP backbone. Routers inside the DODAG route along that domain to the IP backbone. Routers inside the DODAG route along the
graph up towards the Root for the default route and down towards graph up towards the Root for the default route and down towards
destinations in the RPL domain for more specific routes. This destinations in the RPL domain for more-specific routes. As a
specification expects as a pre-requisite a pre-existing RPL Instance prerequisite, this specification expects a pre-existing RPL Instance
with an associated DODAG and RPL Root, which are referred to as main with an associated DODAG and RPL Root, which are referred to as the
Instance, main DODAG and main Root respectively. The main Instance main Instance, main DODAG, and main Root, respectively. The main
is operated in RPL Non-Storing Mode of Operation (MOP). Instance is operated in RPL Non-Storing Mode of Operation (MOP).
With this specification, an abstract routing function called a Path With this specification, an abstract routing function called a Path
Computation Element (PCE) (e.g., located in a central controller or Computation Element (PCE) (e.g., located in a central controller or
collocated with the main Root) interacts with the main Root to collocated with the main Root) interacts with the main Root to
compute additional paths between nodes in the main Instance. In Non- compute additional paths between nodes in the main Instance. In Non-
Storing Mode, the base topological information to be passed to the Storing Mode, the base topological information to be passed to the
PCE, that is the knowledge of the main DODAG, is already available at PCE, i.e., the knowledge of the main DODAG, is already available at
the Root. This specification introduces protocol extensions that the Root. This specification introduces protocol extensions that
enrich the topological information available to the Root with sibling enrich the topological information available to the Root with sibling
relationships that are usable but not leveraged to form the main relationships that are usable but not leveraged to form the main
DODAG. DODAG.
Based on usage, path length, and knowledge of available resources Based on usage, path length, and knowledge of available resources
such as battery levels and reservable buffers in the nodes, the PCE such as battery levels and reservable buffers in the nodes, the PCE,
with a global visibility of the system can optimize the computed which has a global visibility of the system, can optimize the
routes for the application needs, including the capability to provide computed routes for application needs, including the capability to
path redundancy. This specification also introduces protocol provide path redundancy. This specification also introduces protocol
extensions that enable the Root to project (i.e., advertise from a extensions that enable the Root to project (i.e., advertise from a
remote location) the computed paths in the RPL domain as Projected remote location) the computed paths in the RPL domain as Projected
Routes (a.k.a. P-Routes) on behalf of the PCE. Routes (a.k.a. P-Routes) on behalf of the PCE.
A P-Route may be installed in either Storing or Non-Storing Mode, A P-Route may be installed in either Storing or Non-Storing Mode,
potentially resulting in hybrid situations where the Mode in which potentially resulting in hybrid situations where the Mode in which
the P-Route operates is different from that of the RPL main Instance. the P-Route operates is different from that of the RPL main Instance.
P-Routes can be used as stand-alone segments meant to reduce the size P-Routes can be used as stand-alone segments meant to reduce the size
of the source routing headers, leveraging loose source routing of the Source Routing Headers (SRHs), leveraging loose source routing
operations down the main RPL DODAG. A P-Route can also be used as a operations down the main RPL DODAG. A P-Route can also be used as a
protection path, and it can be combined and interleaved with other protection path, and it can be combined and interleaved with other
P-Routes to form a Recovery Graph called a Track. A Track is P-Routes to form a recovery graph called a Track. A Track is
signaled as a separate RPL Instance that is associated with a main signaled as a separate RPL Instance that is associated with a main
RPL Instance, such that the RPL routers that form the Track are also RPL Instance such that the RPL routers that form the Track are also
members of the main DODAG. The Track provides underlay shortcuts members of the main DODAG. The Track provides underlay shortcuts
using its own RIB, that is separate from the RIB of the main Instance using its own RIB, which is separate from the RIB of the main
and has a higher precedence. Instance and has a higher precedence.
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
14 [RFC2119][RFC8174] when, and only when, they appear in all BCP 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 In addition, the terms "Extends" and "Amends" are used as per
[I-D.kuehlewind-update-tag] section 3. [NEW-TAGS], 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 "RPL: IPv6 Routing Protocol for Low-Power and Lossy
[RPL], the "6TiSCH Architecture" [RFC9030], the "Deterministic Networks" [RPL]; "An Architecture for IPv6 over the Time-Slotted
Networking Architecture" [RFC8655], the "Using RPI Option Type, Channel Hopping Mode of IEEE 802.15.4 (6TiSCH)" [RFC9030];
Routing Header for Source Routes, and IP-in-IP Encapsulation in the "Deterministic Networking Architecture" [RFC8655]; "Using RPI Option
RPL Data Plane" [RFC9008], the "Reliable and Available Wireless (RAW) Type, Routing Header for Source Routes, and IPv6-in-IPv6
Architecture" [RAW-ARCHI], and "Terminology in Low power And Lossy Encapsulation in the RPL Data Plane" [RFC9008]; "Reliable and
Networks" [RFC7102]. The 6TiSCH and DetNet/RAW architectures utilize Available Wireless (RAW) Architecture" [RAW-ARCH]; and "Terms Used in
the terms "Track" and "Recovery Graph" to represent the same concept Routing for Low-Power and Lossy Networks" [RFC7102]. The 6TiSCH,
though in different environments. This document uses "Track" to Deterministic Networking (DetNet), and RAW architectures utilize the
represent that concept, and only builds Tracks that are DODAGs, terms "Track" and "recovery graph" to represent the same concept even
meaning that all links are oriented from Ingress to Egress. This though they are in different environments. This document uses
specification also utilizes the terms segment and protection path "Track" to represent that concept and only builds Tracks that are
that are also defined in the RAW Architecture. DODAGs, meaning that all links are oriented from Ingress to Egress.
This specification also utilizes the terms "segment" and "protection
path", which are also defined in the RAW architecture.
As opposed to routing trees, RPL DODAGs are typically constructed to As opposed to routing trees, RPL DODAGs are typically constructed to
provide redundancy and dynamically adapt the forwarding operation to provide redundancy and dynamically adapt the forwarding operation to
the state of the LLN links. Note that the plain forwarding operation the state of the Low-Power and Lossy Network (LLN) links. Note that
over DODAGs does not provide redundancy for all nodes, since at least the plain forwarding operation over DODAGs does not provide
the node nearest to the Root does not have an alternate feasible redundancy for all nodes, since at least the node nearest to the Root
successor. does not have an alternate feasible successor.
RAW solves that problem by defining Protection Paths that can be RAW solves that problem by defining protection paths that can be
interleaved to form new paths that can be activated dynamically upon interleaved to form new paths that can be activated dynamically upon
failures. This requires additional control to take the routing failures. This requires additional control to take the routing
decision early enough along the Track to route around the failure. decision early enough along the Track to route around the failure.
RAW only uses single-ended DODAGs, meaning that they can be reversed RAW only uses single-ended DODAGs, meaning that they can be reversed
in another DODAG by reversing all the links. The Ingress of the in another DODAG by reversing all the links. The Ingress of the
Track is the Root of the DODAG, whereas the Egress is the Root of the Track is the Root of the DODAG, whereas the Egress is the Root of the
reversed DODAG. From the RAW perspective, single-ended DODAGs are reversed DODAG. From the RAW perspective, single-ended DODAGs are
special Tracks that only have forward links, and that can be special Tracks that only have forward links, and that can be
leveraged to provide Protection services by defining destination- leveraged to provide protection services by defining destination-
oriented Protection Paths within the DODAG. oriented protection paths within the DODAG.
2.3. Glossary 2.3. Glossary
This document often uses the following abbreviations: This document often uses the following abbreviations:
6LR: 6LoWPAN Router , e.g., a RPL router in an LLN 6LR: 6LoWPAN Router (e.g., a RPL router in an LLN)
6LoRH: 6LoWPAN Routing Header
ARQ: Automatic Repeat Request, in other words retries 6LoRH: 6LoWPAN Routing Header
FEC: Forward Error Correction
HARQ: Hybrid Automatic Repeat Request, combining FEC and ARQ ARQ: Automatic Repeat Request (in other words, retries)
CMO: Control Message Option
DAO: Destination Advertisement Object FEC: Forward Error Correction
DAG: Directed Acyclic Graph
DODAG: Destination-Oriented Directed Acyclic Graph; A DAG with only HARQ: Hybrid Automatic Repeat Request (combines FEC and ARQ)
one vertex (i.e., node) that has no outgoing edge (i.e., link)
GUA: IPv6 Global Unicast Address CMO: Control Message Option
LLN: Low-Power and Lossy Network
MOP: RPL Mode of Operation DAO: Destination Advertisement Object
P-DAO: Projected DAO
P-Route: Projected Route DAG: Directed Acyclic Graph
PDR: P-DAO Request
PCE: Path Computation Element DODAG: Destination-Oriented Directed Acyclic Graph. A DAG with
PLR: Point of Local Repair only one vertex (i.e., node) that has no outgoing edge
RAN: RPL-Aware Node (either a RPL router or a RPL-Aware Leaf) (i.e., link).
RAL: RPL-Aware Leaf
RH: Routing Header GUA: Global Unicast Address
RIB: Routing Information Base, i.e., the routing table.
RPI: RPL Packet Information LLN: Low-Power and Lossy Network
RPL: IPv6 Routing Protocol for Low-Power and Lossy Networks
RTO: RPL Target Option MOP: Mode of Operation
RUL: RPL-Unaware Leaf
SIO: RPL Sibling Information Option P-DAO: Projected DAO
ULA: IPv6 Unique Local Address
NSM-VIO: A Source-Routed Via Information Option, used in Non-Storing P-Route: Projected Route
Mode P-DAO messages
SLO: Service Level Objective PDR: P-DAO Request
SRH: Source Routing Header, i.e., the IPv6 RH type 3, see
Section 2.4.5.7.2 PCE: Path Computation Element
SRH-6loRH: Source Routing Header 6LoRH, a compressed form of SRH
defined in " IPv6 over Low-Power Wireless Personal Area Network PLR: Point of Local Repair
(6LoWPAN) Routing Header" [RFC8138]
TIO: RPL Transit Information Option RAN: RPL-Aware Node (either a RPL router or a RPL-Aware Leaf)
SM-VIO: A strict Via Information Option, used in Storing Mode P-DAO
messages RAL: RPL-Aware Leaf
VIO: A Via Information Option; it can be an SM-VIO or a NSM-VIO
RH: Routing Header
RIB: Routing Information Base (i.e., the routing table)
RPI: RPL Packet Information
RPL: Routing Protocol for Low-Power and Lossy Networks
RTO: RPL Target Option
RUL: RPL-Unaware Leaf
SIO: Sibling Information Option
ULA: Unique Local Address
NSM-VIO: Non-Storing Mode Via Information Option. Source-routed
VIO used in Non-Storing Mode P-DAO messages.
SLO: Service Level Objective
SRH: Source Routing Header (i.e., IPv6 RH type 3); see
Section 2.4.5.7.2.
SRH-6LoRH: Source Routing Header 6LoRH. A compressed form of SRH
defined in "IPv6 over Low-Power Wireless Personal Area
Network (6LoWPAN) Routing Header" [RFC8138].
TIO: Transit Information Option
SM-VIO: Storing Mode Via Information Option. Strict VIO used in
Storing Mode P-DAO messages.
VIO: Via Information Option. It can be an SM-VIO or NSM-VIO.
2.4. Domain Terms 2.4. Domain Terms
This specification uses the following terminology: This specification uses the terminology defined in the sections that
follow.
2.4.1. Projected Route 2.4.1. Projected Route
A RPL P-Route is a RPL route that is computed remotely by a PCE, and A RPL P-Route is a RPL route that is computed remotely by a PCE and
installed and maintained by a RPL Root on behalf of the PCE. It is installed and maintained by a RPL Root on behalf of the PCE. It is
installed as a state that signals that destinations (i.e., Targets) installed as a state that signals that destinations (i.e., Targets)
are reachable via or along a sequence of nodes. are reachable via or along a sequence of nodes.
2.4.2. Projected DAO 2.4.2. Projected DAO
A DAO message used to install a P-Route. A Projected DAO (P-DAO) is a DAO message that is used to install a
P-Route.
2.4.3. Path 2.4.3. Path
Quoting (non-normatively) section 1.1.3 of [INT-ARCHI]: Quoting (non-normatively) the definition of path in Section 1.3.3 of
[INT-ARCH]:
| At a given moment, all the IP datagrams from a particular source | At a given moment, all the IP datagrams from a particular source
| host to a particular destination host will typically traverse the | host to a particular destination host will typically traverse the
| same sequence of gateways. We use the term "path" for this | same sequence of gateways. We use the term "path" for this
| sequence. Note that a path is uni-directional; it is not unusual | sequence. Note that a path is uni-directional; it is not unusual
| to have different paths in the two directions between a given host | to have different paths in the two directions between a given host
| pair. | pair.
Section 2 of [I-D.irtf-panrg-path-properties] points to a longer, Section 2 of [RFC9473] points to a longer, more modern definition of
more modern definition of path, which begins as follows: path:
| A sequence of adjacent path elements over which a packet can be | A sequence of adjacent path elements over which a packet can be
| transmitted, starting and ending with a node. A path is | transmitted, starting and ending with a node. A path is
| unidirectional. Paths are time-dependent, i.e., the sequence of | unidirectional. Paths are time-dependent, i.e., the sequence of
| path elements over which packets are sent from one node to another | path elements over which packets are sent from one node to another
| may change. A path is defined between two nodes. | may change. A path is defined between two nodes.
It follows that the general acceptance of a path is a linear sequence It follows that the general acceptance of a path is a linear sequence
of nodes, as opposed to a multi-dimensional graph. In the context of of nodes, as opposed to a multi-dimensional graph. In the context of
this document, a path is observed by following one copy of a packet this document, a path is observed by following one copy of a packet
that is injected in a Track and possibly replicated within. that is injected in a Track and possibly replicated within.
2.4.4. Routing Stretch 2.4.4. Routing Stretch
RPL is anisotropic, meaning that it is directional, or more exactly RPL is anisotropic, meaning that it is directional or, more
polar. RPL does not behave the same way "downwards" (root towards precisely, polar. RPL does not behave the same way "downwards" (root
leaves) with _multicast_ DIO messages that form the DODAG and towards leaves) with _multicast_ DODAG Information Object (DIO)
"upwards" (leaves towards root) with _unicast_ DAO messages that messages that form the DODAG and "upwards" (leaves towards root) with
follow the DODAG. This is in contrast with traditional IGPs that _unicast_ DAO messages that follow the DODAG. This is in contrast
operate the same way in all directions and are thus called isotropic. with traditional IGPs that operate the same way in all directions and
are thus called isotropic.
The term Routing Stretch denotes the length of a path, in comparison The term "routing stretch" denotes the length of a path, in
to the length of the shortest path, which can be an abstract concept comparison to the length of the shortest path, which can be an
in RPL when the metrics are statistical and dynamic, and the concept abstract concept in RPL when the metrics are statistical and dynamic,
of distance varies with the Objective Function. and the concept of distance varies with the Objective Function.
The RPL DODAG optimizes the P2MP (Point-to-Multipoint) (from the The RPL DODAG optimizes Point-to-Multipoint (P2MP) paths (from the
Root) and MP2P (Multipoint-to-Point) (towards the Root) paths, but Root) and Multipoint-to-Point (MP2P) paths (towards the Root), but
the P2P (Point-to-Point) traffic has to follow the same DODAG. the Point-to-Point (P2P) traffic has to follow the same DODAG.
Following the DODAG, the RPL datapath passes via a common parent in Following the DODAG, the RPL datapath passes via a common parent in
Storing Mode and via the Root in Non-Storing Mode. This typically Storing Mode and via the Root in Non-Storing Mode. This typically
involves more hops and more latency than the minimum possible for a involves more hops and more latency than the minimum possible for a
directional (i.e., forward) P2P path that an isotropic protocol would directional (i.e., forward) P2P path that an isotropic protocol would
compute. We refer to this elongated path as stretched. compute. We refer to this elongated path as stretched.
2.4.5. Track 2.4.5. Track
The concept of Track is inherited from the "6TiSCH Architecture" The concept of Track is inherited from the 6TiSCH architecture
[RFC9030] and matches that of a Protection Path in the RAW [RFC9030] and matches that of a protection path in the RAW
Architecture" [RAW-ARCHI]. A Track is a networking graph that can be architecture [RAW-ARCH]. A Track is a networking graph that can be
followed to transport packets with equivalent treatment; as opposed followed to transport packets with equivalent treatment; as opposed
to the definition of a path above, a Track is not necessarily linear. to the definition of a path above, a Track is not necessarily linear.
It may contain multiple paths that may fork and rejoin, and may It may contain multiple paths that may fork and rejoin and that may
enable the RAW Packet ARQ, Replication, Elimination, and Overhearing enable RAW Packet ARQ, Replication, Elimination, and Overhearing
(PAREO) operations. (PAREO) operations.
Figure 1 illustrates the mapping of the DODAG with the generic Figure 1 illustrates the mapping of the DODAG with the generic
concept of a Track, with the DODAG Root acting as Ingress for the concept of a Track, with the DODAG Root acting as the Ingress for the
Track, and the mapping of protection paths and segments, and only Track, and the mapping of protection paths and segments, i.e., only
forward segments, meaning that they are directional and progressing forward segments, meaning that they are directional and progressing
towards the destination. Note that East is represented on the left towards the destination. Note that East is represented on the left
since the packets are forwarded East-West. since the packets are forwarded East-West.
North East North West North East North West
A ==> B ==> C -=- F ==> G ==> H T1 I: Ingress A ==> B ==> C -=- F ==> G ==> H T1
/ \ / \ / E: Egress / \ / \ /
I O E -=- T2 T1, T2, T3: I O E -=- T2
\ / \ / \ External \ / \ / \
P ==> Q ==> R -=- T ==> U ==> V T3 Targets P ==> Q ==> R -=- T ==> U ==> V T3
South East South West South East South West
I ==> A ==> B ==> C : a Segment to targets F and O I: Ingress
E: Egress
T1, T2, T3: external targets
I --> F --> E : a protection path to targets T1, T2, T3 Figure 1: A Track and Its Components
I, A, B, C, F, G, H, E : a path to T1, T2, T3 Of note:
Figure 1: A Track and its Components I ==> A ==> B ==> C: A segment to targets F and O
I --> F --> E: A protection path to targets T1, T2, T3
I, A, B, C, F, G, H, E: A path to T1, T2, T3
This specification builds Tracks that are DODAGs oriented towards a This specification builds Tracks that are DODAGs oriented towards a
Track Ingress, and the forward direction for packets is from the Track Ingress, and the forward direction for packets is from the
Track Ingress to one of the possibly multiple Track Egress Nodes, Track Ingress to one of the possible multiple Track Egress Nodes,
which is also down the DODAG. which is also down the DODAG.
The Track may be strictly connected, meaning that the vertices are The Track may be strictly connected, meaning that the vertices are
adjacent, or loosely connected, meaning that the vertices are adjacent, or loosely connected, meaning that the vertices are
connected using segments that are associated to the same Track. connected using segments that are associated to the same Track.
2.4.5.1. TrackID 2.4.5.1. TrackID
A RPL InstanceID (typically of a Local Instance) that identifies a A RPLInstanceID (typically of a Local Instance) identifies a Track
Track using the namespace owned by the Track Ingress. For Local using the namespace owned by the Track Ingress. For Local Instances,
Instances, the TrackID is associated with the IPv6 Address of the the TrackID is associated with the IPv6 address of the Track Ingress
Track Ingress that is used as DODAGID, and together they form a that is used as the DODAGID, and together they form a unique
unique identification of the Track (see the definition of DODAGID in identification of the Track (see the definition of DODAGID in
section 2 of [RPL]. Section 2 of [RPL]).
2.4.5.2. Namespace 2.4.5.2. Namespace
The term namespace is used to refer to the scope of the TrackID. The The term "namespace" is used to refer to the scope of the TrackID.
TrackID is locally significant within its namespace. For Local The TrackID is locally significant within its namespace. For Local
Instances, the namespace is identified by the DODAGID for the Track Instances, the namespace is identified by the DODAGID for the Track,
and the tuple (DODAGID, TrackID) is globally unique. For Global and the tuple (DODAGID, TrackID) is globally unique. For Global
Instances, the namespace is the whole RPL domain. Instances, the namespace is the whole RPL domain.
2.4.5.3. Complex Track 2.4.5.3. Complex Track
A Track that can be traversed via more than one path (e.g., a DODAG). A complex Track is a Track that can be traversed via more than one
path (e.g., a DODAG).
2.4.5.4. Stand-Alone 2.4.5.4. Stand Alone
Refers to a segment or a protection path that is installed with a Stand alone refers to a segment or a protection path that is
single P-DAO that fully defines the path, e.g., a stand-alone segment installed with a single P-DAO that fully defines the path, e.g., a
is installed with a single Storing Mode Via Information option (SM- stand-alone segment is installed with a single Storing Mode Via
VIO) all the way between Ingress and Egress. Information Option (SM-VIO) all the way between the Ingress and
Egress.
2.4.5.5. Stitching 2.4.5.5. Stitching
This specification uses the term stitching to indicate that a track This specification uses the term "stitching" to indicate that a Track
is piped to another one, meaning that traffic out of the first track is piped to another one, meaning that traffic out of the first Track
is injected into the other track. is injected into the other Track.
2.4.5.6. Protection Path 2.4.5.6. Protection Path
The concept of protection path is defined in the RAW Architecture" The concept of protection path is defined in the RAW architecture
[RAW-ARCHI] as an end-to-end forward serial path. With this [RAW-ARCH] as an end-to-end forward serial path. With this
specification, a protection path is installed by the Root of the main specification, a protection path is installed by the Root of the main
DODAG using a Non-Storing Mode P-DAO message, e.g., I --> F --> E in DODAG using a Non-Storing Mode P-DAO message, e.g., I --> F --> E in
Figure 1. Figure 1.
As the Non-Storing Mode Via Information option (NSM-VIO) can only As the Non-Storing Mode Via Information Option (NSM-VIO) can only
signal sequences of nodes, it takes one Non-Storing Mode P-DAO signal sequences of nodes, it takes one Non-Storing Mode P-DAO
message per protection path to signal the structure of a complex message per protection path to signal the structure of a complex
Track. Track.
Each NSM-VIO for the same TrackID but with a different Segment ID Each NSM-VIO for the same TrackID but with a different Segment ID
signals a different protection path that the Track Ingress adds to signals a different protection path that the Track Ingress adds to
the topology. the topology.
2.4.5.7. Segment 2.4.5.7. Segment
A serial path formed by a strict sequence of nodes, along which a A segment is a serial path formed by a strict sequence of nodes along
P-Route is installed, e.g., I ==> A ==> B ==> C in Figure 1. With which a P-Route is installed, e.g., I ==> A ==> B ==> C in Figure 1.
this specification, a segment is typically installed by the Root of With this specification, a segment is typically installed by the Root
the main DODAG using Storing Mode P-DAO messages. A segment is used of the main DODAG using Storing Mode P-DAO messages. A segment is
as the topological edge of a Track joining the loose steps along the used as the topological edge of a Track joining the loose steps along
protection paths that form the structure of a complex Track. The the protection paths that form the structure of a complex Track. The
same segment may be leveraged by more than one protection path where same segment may be leveraged by more than one protection path where
the protection paths overlap. the protection paths 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 the Ingress (East) to Egress (West), as opposed to the
general Track model in the RAW Architecture [RAW-ARCHI], which allows general Track model in the RAW architecture [RAW-ARCH], which allows
North/South segments that can be bidirectional as well. North/South segments that can be bidirectional as well.
2.4.5.7.1. Section of a Segment 2.4.5.7.1. Section of a Segment
A continuous subset of a segment that may be replaced while the The section of a segment refers to a continuous subset of a segment
segment remains. For instance, in segment A=>B=>C=>D=>E=>F, say that that may be replaced while the segment remains. For instance, in
the link C to D might be misbehaving. The section B=>C=>D=>E in the segment A=>B=>C=>D=>E=>F, say that the link C to D might be
segment may be replaced by B=>C’=>D’=>E to route around the problem. misbehaving. The section B=>C=>D=>E in the segment may be replaced
The segment becomes A=>B=>C’=>D’=>E=>F. by B=>C'=>D'=>E to route around the problem. The segment becomes
A=>B=>C'=>D'=>E=>F.
2.4.5.7.2. Segment Routing and SRH 2.4.5.7.2. Segment Routing and SRH
In a Non-Storing mode RPL domain, the IPv6 RH used for source-routing In a Non-Storing Mode RPL domain, the IPv6 RH used for source routing
is the (RPL) SRH as defined in [RFC6554]. This specification is the (RPL) SRH as defined in [RFC6554]. This specification
operates in that context and uses the acronym SRH to mean the IPv6 RH operates in that context and uses the acronym SRH to mean IPv6 RH
type 3 as opposed to the IPv6 RH type 4 defined in [RFC8754] for the type 3, as opposed to IPv6 RH type 4 defined in [RFC8754] for Segment
Segment Routing (SRv6) operation. Routing over IPv6 (SRv6) operation.
If the network is a 6LoWPAN Network, the expectation is that the SRH If the network is a 6LoWPAN network, the expectation is that the SRH
is compressed and encoded as a 6LoWPAN Routing Header (6LoRH), as is compressed and encoded as a 6LoWPAN Routing Header (6LoRH), as
specified in section 5 of [RFC8138]. specified in Section 5 of [RFC8138].
This specification uses the term "Segment Routing" generically, to This specification uses the term "Segment Routing" generically to
refer to using source-routing to hop over segments. As such, refer to using source routing to hop over segments. As such,
forwarding along segments as specified hereafter can be seen as a forwarding along segments as specified hereafter can be seen as a
form of Segment Routing [RFC8402], but leveraging the (RPL) SRH for form of Segment Routing [RFC8402] that leverages the (RPL) SRH for
its operation. its operation.
Outside of LLNs, the RPL Network may be less constrained and operated Outside of LLNs, the RPL network may be less constrained and operated
in Storing Mode, as discussed in Section 7.1. In that case, this in Storing Mode, as discussed in Section 7.1. In that case, this
specification could be extended to accommodate the SRv6 RH. specification could be extended to accommodate the SRv6 RH.
3. Context and Goal 3. Context and Goal
3.1. RPL Applicability 3.1. RPL Applicability
RPL is optimized for situations where the power is scarce, the RPL is optimized for situations where the power is scarce, the
bandwidth is constrained and the transmissions are unreliable. This bandwidth is constrained, and the transmissions are unreliable. This
matches the use case of an IoT LLN where RPL is typically used today, matches the use case of an IoT LLN where RPL is typically used today
but also situations of high relative mobility between the nodes in and also situations of high relative mobility between the nodes in
the network (a.k.a. swarming), e.g., within a variable set of the network (a.k.a. swarming), e.g., within a variable set of
vehicles with a similar global motion, or a platoon of drones. In vehicles with a similar global motion or a platoon of drones. In
contrast, this specification only applies when the platoon has a contrast, this specification only applies when the platoon has a
relatively stable topology where the segments can be attributed a relatively stable topology where the segments can be attributed
reliability and availability for a certain lifetime, see [RAW-ARCHI]. reliability and availability for a certain lifetime; see [RAW-ARCH].
To reach this goal, RPL is primarily designed to minimize the control To reach this goal, RPL is primarily designed to minimize the control
plane activity, that is the relative amount of routing protocol plane activity, i.e., the relative amount of routing protocol
exchanges vs. data traffic, and the amount of state that is exchanges versus data traffic, and the amount of state that is
maintained in each node. RPL does not need to converge, and provides maintained in each node. RPL does not need to converge, and it
connectivity to most nodes most of the time. provides connectivity to most nodes most of the time.
RPL may form multiple topologies called instances. Instances can be RPL may form multiple topologies called instances. Instances can be
created to enforce various optimizations through objective functions, created to enforce various optimizations through objective functions
or to reach out through different Root Nodes. The concept of or to reach out through different Root Nodes. The concept of
objective function allows to adapt the activity of the routing objective function allows adapting the activity of the routing
protocol to the use case, e.g., type, speed, and quality of the LLN protocol to the use case, e.g., type, speed, and quality of the LLN
links. links.
RPL instances operate in parallel, unaware of one another. Yet, it RPL instances operate in parallel, unaware of one another. Yet, it
is possible to define a model whereby if a route cannot be found in is possible to define a model whereby if a route cannot be found in
the current instance A where a packet is being forwarded, then the the current instance A where a packet is being forwarded, then the
router may lookup the routing table (RIB) in an instance B and router may look up the routing table (i.e., the RIB) in instance B
forward along instance B if the route is found there. To avoid and forward along instance B if the route is found there. To avoid
loops, this must happen in such a way that the instances themselves loops, this must happen in such a way that the instances themselves
form a directed acyclic graph (DAG) leading to the last resort form a Directed Acyclic Graph (DAG) leading to the last resort
instance that is the "lowest" instance if instance A is considered instance, which is the "lowest" instance if instance A is considered
"higher" then instance B. This specification uses underlay Tracks as "higher" then instance B. This specification uses underlay Tracks as
"lower" instances, the main instance being the "highest" of all. "lower" instances, with the main instance being the "highest" of all.
The RPL Root is responsible for selecting the RPL Instance that is The RPL Root is responsible for selecting the RPL Instance that is
used to forward a packet coming from the Backbone into the RPL domain used to forward a packet coming from the backbone into the RPL domain
and for setting the related RPL information in the packets. Each and for setting the related RPL information in the packets. Each
Instance creates its own routing table (RIB) in participating nodes, Instance creates its own routing table (i.e., a RIB) in participating
and the RIB associated to the instance must be used end to end in the nodes, and the RIB associated to the instance must be used end to end
RPL domain. To that effect, RPL tags the packets with the Instance in the RPL domain. To that effect, RPL tags the packets with the
ID in a Hop-by-Hop extension Header. 6TiSCH leverages RPL for its Instance ID in a Hop-by-Hop extension header. 6TiSCH leverages RPL
distributed routing operations. for its distributed routing operations.
To reduce the routing exchanges, RPL leverages an anisotropic To reduce the routing exchanges, RPL leverages an anisotropic
Distance Vector approach, which does not need a global knowledge of Distance Vector approach, which does not need global knowledge of the
the topology, and only optimizes the routes to and from the RPL Root, topology and only optimizes the routes to and from the RPL Root,
allowing P2P paths to be stretched. Although RPL installs its routes allowing P2P paths to be stretched. Although RPL installs its routes
proactively, it only maintains them lazily, in reaction to actual proactively, it only maintains them lazily, in reaction to actual
traffic, or as a slow background activity. traffic or as a slow background activity.
This is simple and efficient in situations where the traffic is This is simple and efficient in situations where the traffic is
mostly directed from or to a central node, such as the control mostly directed from or to a central node, such as the control
traffic between routers and a controller of a Software Defined traffic between routers and a controller of a Software-Defined
Networking (SDN) infrastructure or an Autonomic Control Plane (ACP). Networking (SDN) infrastructure or an Autonomic Control Plane (ACP).
But stretch in P2P routing is counter-productive to both reliability But stretch in P2P routing is counter-productive to both reliability
and latency as it introduces additional delay and chances of loss. and latency as it introduces additional delay and chances of loss.
As a result, [RPL] is not a good fit for the use cases listed in the As a result, [RPL] is not a good fit for the use cases listed in the
RAW use cases document [RFC9450], which demand high availability and RAW use cases document [RFC9450], which demand high availability and
reliability, and as a consequence require both short and diverse reliability and, as a consequence, require both short and diverse
paths. paths.
3.2. Multi-Topology Routing and Loop Avoidance 3.2. Multi-Topology Routing and Loop Avoidance
RPL first forms a default route in each node towards the Root, and RPL first forms a default route in each node towards the Root, and
those routes together coalesce as a Directed Acyclic Graph oriented those routes together coalesce as a DAG oriented upwards. RPL then
upwards. RPL then constructs routes to destinations signaled as constructs routes to destinations signaled as Targets in the reverse
Targets in the reverse direction, down the same DODAG. To do so, a direction, down the same DODAG. To do so, a RPL Instance can be
RPL Instance can be operated either in RPL Storing or Non-Storing operated in either RPL Storing Mode or Non-Storing Mode of Operation
Mode of Operation (MOP). The default route towards the Root is (MOP). The default route towards the Root is maintained aggressively
maintained aggressively and may change while a packet progresses and may change while a packet progresses without causing loops, so
without causing loops, so the packet will still reach the Root. the packet will still reach the Root.
In Non-Storing Mode, each node advertises itself as a Target directly In Non-Storing Mode, each node advertises itself as a Target directly
to the Root, indicating the parents that may be used to reach itself. to the Root, indicating the parents that may be used to reach itself.
Recursively, the Root builds and maintains an image of the whole Recursively, the Root builds and maintains an image of the whole
DODAG in memory, and leverages that abstraction to compute source DODAG in memory and leverages that abstraction to compute source
route paths for the packets to their destinations down the DODAG. route paths for the packets to their destinations down the DODAG.
When a node changes its point(s) of attachment to the DODAG, it takes When a node changes its point(s) of attachment to the DODAG, it takes
a single unicast packet to the Root along the default route to update a single unicast packet to the Root along the default route to update
it, and the connectivity to the node is restored immediately; this it, and the connectivity to the node is restored immediately; this
mode is preferable for use cases where internet connectivity is mode is preferable for use cases where internet connectivity is
dominant, or when the Root controls the network activity in the dominant or when the Root controls the network activity in the nodes,
nodes, which is the case of this specification. which is the case in this specification.
In Storing Mode, the routing information percolates upwards, and each In Storing Mode, the routing information percolates upwards, and each
node maintains the routes to the subDAG of its descendants down the node maintains the routes to the subDAG of its descendants down the
DODAG. The maintenance is lazy, either reactive upon traffic or as a DODAG. The maintenance is lazy, either reactive upon traffic or as a
slow background process. Packets flow via the common parent and the slow background process. Packets flow via the common parent and the
routing stretch is reduced compared to Non-Storing MOP, for better routing stretch is reduced, compared to the Non-Storing MOP, for
P2P connectivity. However, a new route takes a longer time to better P2P connectivity. However, a new route takes a longer time to
propagate to the Root, since it takes time for the Distance-Vector propagate to the Root, since it takes time for the Distance Vector
protocol to operate hop-by-hop, and the connectivity from the protocol to operate hop by hop, and the connectivity from the
internet to the node is restored more slowly upon node movement. Internet to the node is restored more slowly upon node movement.
Either way, the RPL routes are injected by the Target nodes, in a Either way, the RPL routes are injected by the Target nodes in a
distributed fashion. To complement RPL and eliminate routing distributed fashion. To complement RPL and eliminate routing
stretch, this specification introduces a hybrid mode that combines stretch, this specification introduces a hybrid mode that combines
Storing and Non-Storing operations to build and project routes onto Storing and Non-Storing operations to build and project routes onto
the nodes where they should be installed. This specification uses the nodes where they should be installed. This specification uses
the term Projected Route (P-Route) to refer to those routes. the term "P-Route" to refer to those routes.
In the simplest mode of this specification, Storing-Mode P-Routes can In the simplest mode of this specification, Storing Mode P-Routes can
be deployed to join the dots of a loose source routing header (SRH) be deployed to join the dots of a loose SRH in the main DODAG. In
in the main DODAG. In that case, all the routes (source routed and that case, all the routes (source routed and P-Routes) belong to the
P-Routes) belong to the Routing Information base (RIB) associated Routing Information Base (RIB) associated with the main Instance.
with the main Instance. Storing-Mode P-Routes are referred to as Storing Mode P-Routes are referred to as segments in this
segments in this specification. specification.
A set of P-Routes can also be projected to form a dotted-line A set of P-Routes can also be projected to form a dotted-line
underlay of the main Instance and provide Traffic Engineered paths underlay of the main Instance and provide Traffic-Engineered paths
for an application. In that case, the P-Routes are installed in Non- for an application. In that case, the P-Routes are installed in Non-
Storing Mode and the set of P-Routes is called a Track. A Track is Storing Mode, and the set of P-Routes is called a Track. A Track is
associated with its own RPL Instance, and, as any RPL Instance, with associated with its own RPL Instance and, as any RPL Instance, with
its own Routing Information base (RIB). As a result, each Track its own RIB. As a result, each Track defines a routing topology in
defines a routing topology in the RPL domain. As for the main DODAG, the RPL domain. As for the main DODAG, segments associated to the
segments associated to the Track Instance may be deployed to join the Track Instance may be deployed to join the dots using Storing Mode
dots using Storing-Mode P-Routes. P-Routes.
Routing in a multi-topology domain may cause loops unless strict Routing in a multi-topology domain may cause loops unless strict
rules are applied. This specification defines two strict orders to rules are applied. This specification defines two strict orders to
ensure loop avoidance when projected routes are used in a RPL domain, ensure loop avoidance when P-Routes are used in a RPL domain: one
one between forwarding methods and one between RPL Instances, seen as between forwarding methods and one between RPL Instances, which are
routing topologies. routing topologies.
The first and strict order relates to the forwarding method and the The first and strict order relates to the forwarding method and, more
more specifically the origin of the information used in the next-hop specifically, the origin of the information used in the next-hop
computation. The possible forwarding methods are: 1) to a direct computation. The possible forwarding methods are: 1) to a direct
next hop, 2) to an indirect neighbor via a common neighbor, 3) along next hop, 2) to an indirect neighbor via a common neighbor, 3) along
a segment, and 4) along a nested Track. The methods are strictly a segment, and 4) along a nested Track. The methods are strictly
ordered as listed above, more in Section 6.7. A forwarding method ordered as listed above; see more in Section 6.7. A forwarding
may leverage any of the lower order ones, but never one with a higher method may leverage any of the lower-order ones, but never one with a
order; for instance, when forwarding a packet along a segment, the higher order; for instance, when forwarding a packet along a segment,
router may use direct or indirect neighbors but cannot use a Track. the router may use direct or indirect neighbors but cannot use a
The lower order methods have a strict precedence, so the router will Track. The lower-order methods have a strict precedence, so the
always prefer a direct neighbor over an indirect one, or a segment router will always prefer a direct neighbor over an indirect one or a
within the current RPL Instance vs. another Track. segment within the current RPL Instance over another Track.
The second strict and partial order is between RPL Instances. It The second strict and partial order is between RPL Instances. It
allows the RPL node to detect an error in the state installed by the allows the RPL node to detect an error in the state installed by the
PCE, e.g., after a desynchronization. That order must be defined by PCE, e.g., after a desynchronization. That order must be defined by
the administrator for the RPL domain and defines a DODAG of underlays the administrator for the RPL domain and defines a DODAG of underlays
with the main Instance as Root. The relation of RPL instances may be with the main Instance as Root. The relation of RPL instances may be
represented as a DODAG of instances where the main instance is Root. represented as a DODAG of instances where the main instance is the
The rule is that a RPL Instance may leverage another RPL instance as Root. The rule is that a RPL Instance may leverage another RPL
underlay if and only if that other Instance is one of its descendants instance as an underlay if and only if that other Instance is one of
in the graph. Supporting this method is OPTIONAL for nested Tracks its descendants in the graph. Supporting this method is OPTIONAL for
and REQUIRED between a Track instance and the main instance. It may nested Tracks and REQUIRED between a Track instance and the main
be done using network management, or future extensions to this instance. It may be done using network management or future
specifications. When it is not communicated, then the RPL nodes extensions to this specifications. When it is not communicated, the
consider by default that all Track instances are children of the main RPL nodes consider by default that all Track instances are children
instance, and do not attempt to validate the order for nested Tracks, of the main instance, and they do not attempt to validate the order
trusting the PCE implicitly. As a result, a packet that is being for nested Tracks, trusting the PCE implicitly. As a result, a
forwarded along the main Instance may be encapsulated in any Track, packet that is being forwarded along the main Instance may be
but a packet that was forwarded along a Track MUST NOT be forwarded encapsulated in any Track, but a packet that was forwarded along a
along the default route of main Instance. Track MUST NOT be forwarded along the default route of the main
Instance.
3.3. Requirements 3.3. Requirements
3.3.1. Loose Source Routing 3.3.1. Loose Source Routing
A RPL implementation operating in a very constrained LLN typically A RPL implementation operating in a very constrained LLN typically
uses the Non-Storing Mode of Operation as represented in Figure 2. uses the Non-Storing Mode of Operation as represented in Figure 2.
In that mode, a RPL node indicates a parent-child relationship to the In that mode, a RPL node indicates a parent-child relationship to the
Root, using a destination Advertisement Object (DAO) that is unicast Root, using a Destination Advertisement Object (DAO) that is unicast
from the node directly to the Root, and the Root typically builds a from the node directly to the Root, and the Root typically builds a
source routed path to a destination down the DODAG by recursively source-routed path to a destination down the DODAG by recursively
concatenating this information. concatenating this information.
+-----+ +-----+
| | Border router | | Border Router
| | (RPL Root) | | (RPL Root)
+-----+ ^ | | +-----+ ^ | |
| | DAO | ACK | | | DAO | ACK |
o o o o | | | Strict o o o o | | | Strict
o o o o o o o o o | | | Source o o o o o o o o o | | | Source
o o o o o o o o o o | | | Route o o o o o o o o o o | | | Route
o o o o o o o o o | | | o o o o o o o o o | | |
o o o o o o o o | v v o o o o o o o o | v v
o o o o o o o o
LLN LLN
Figure 2: RPL Non-Storing Mode of operation Figure 2: RPL Non-Storing Mode of Operation
Based on the parent-children relationships expressed in the Non- Based on the parent-children relationships expressed in the Non-
Storing DAO messages, the Root possesses topological information Storing DAO messages, the Root possesses topological information
about the whole network, though this information is limited to the about the whole network, though this information is limited to the
structure of the DODAG for which it is the destination. A packet structure of the DODAG for which it is the destination. A packet
that is generated within the domain will always reach the Root, which that is generated within the domain will always reach the Root, which
can then apply a source routing information to reach the destination can then apply source routing information to reach the destination if
if the destination is also in the DODAG. Similarly, a packet coming the destination is also in the DODAG. Similarly, a packet coming
from the outside of the domain for a destination that is expected to from the outside of the domain for a destination that is expected to
be in a RPL domain reaches the Root. This results in the wireless be in a RPL domain reaches the Root. This results in the wireless
bandwidth near the Root being the limiting factor for all bandwidth near the Root being the limiting factor for all
transmissions towards or within the domain, and that the Root is a transmissions towards or within the domain, and the Root is a single
single point of failure for all connectivity to nodes within its point of failure for all connectivity to nodes within its domain.
domain.
The RPL Root must add a source routing header to all downward The RPL Root must add a source routing header to all downward
packets. As a network grows, the size of the source routing header packets. As a network grows, the size of the source routing header
increases with the depth of the network. In some use cases, a RPL increases with the depth of the network. In some use cases, a RPL
network forms long lines along physical structures such as streets network forms long lines along physical structures like streets with
for lighting. Limiting the packet size is beneficial to the energy lighting. Limiting the packet size is beneficial to the energy
budget, directly for the current transmission, but also indirectly budget, directly for the current transmission and also indirectly
since it reduces the chances of frame loss and energy spent in since it reduces the chances of frame loss and energy spent in
retries, e.g., by ARQ over one hop at Layer-2, or end-to-end at upper retries, e.g., by ARQ over one hop at Layer 2 or end to end at upper
layers. Using smaller packets also reduces the chances of packet layers. Using smaller packets also reduces the chances of packet
fragmentation, which is highly detrimental to the LLN operation, in fragmentation, which is highly detrimental to the LLN operation, in
particular when fragments are forwarded but not recovered, see particular when fragments are forwarded but not recovered; see
[RFC8930] vs. [RFC8931] for more. [RFC8930] compared to [RFC8931] for more details.
A limited amount of well-targeted routing state would allow the A limited amount of well-targeted routing state would allow the
source routing operation to be loose as opposed to strict, and reduce source routing operation to be loose as opposed to strict and would
the overhead of routing information in packets. Because the reduce the overhead of routing information in packets. Because the
capability to store routing state in every node is limited, the capability to store routing state in every node is limited, the
decision of which route is installed where can only be optimized with decision of which route is installed where can only be optimized with
global knowledge of the system, knowledge that the Root or an global knowledge of the system, knowledge that the Root or an
associated PCE may possess by means that are outside the scope of associated PCE may possess by means that are outside the scope of
this specification. this specification.
Being on-path for all packets in Non-Storing mode, the Root may Being on path for all packets in Non-Storing Mode, the Root may
determine the number of P2P packets in its RPL domain per source and determine the number of P2P packets in its RPL domain per source and
destination, the latency incurred, and the amount of energy and destination, the latency incurred, and the amount of energy and
bandwidth that is consumed to reach itself and then back down, bandwidth that is consumed to reach itself and then back down,
including possible fragmentation when encapsulating larger packets. including possible fragmentation when encapsulating larger packets.
Enabling a shorter path that would not traverse the Root for select Enabling a shorter path that would not traverse the Root for select
P2P source/destinations may improve the latency, lower the P2P sources/destinations may improve the latency, lower the
consumption of constrained resources, free bandwidth at the consumption of constrained resources, free bandwidth at the
bottleneck near the Root, improve the delivery ratio and reduce the bottleneck near the Root, improve the delivery ratio, and reduce the
latency for those P2P flows with a global benefit for all flows by latency for those P2P flows; this would be a global benefit for all
reducing the load at the Root. flows by reducing the load at the Root.
To limit the need for source route headers in deep networks, one To limit the need for source route headers in deep networks, one
possibility is to store a routing state associated with the main possibility is to store a routing state associated with the main
DODAG in select RPL routers down the path. The Root may elide the DODAG in select RPL routers down the path. The Root may elide the
sequence of routers that is installed in the network from its source sequence of routers that is installed in the network from its source
route header, which therefore becomes loose, in contrast to being route header, which therefore becomes loose, in contrast to being
strict in [RPL]. strict in [RPL].
3.3.2. forward Routes 3.3.2. Forward Routes
[RPL] optimizes P2MP routes from the Root, MP2P routes towards the [RPL] optimizes P2MP routes from the Root, MP2P routes towards the
Root, and as a consequence routes from/to the outside of the RPL Root, and routes from/to the outside of the RPL domain when the Root
domain when the Root also serves as Border Router. All routes are also serves as the border router. All routes are installed North-
installed North-South (a.k.a. up/down) along the RPL DODAG. Peer to South (a.k.a. up/down) along the RPL DODAG. Peer-to-Peer (P2P)
Peer (P2P) forward routes in a RPL network will generally experience forward routes in a RPL network will generally experience elongated
elongated (stretched) paths versus direct (optimized) paths, since (stretched) paths rather than direct (optimized) paths, since routing
routing between two nodes always happens via a common parent, as between two nodes always happens via a common parent, as illustrated
illustrated in Figure 3: in Figure 3:
------+--------- ------+---------
| Internet | Internet
+-----+ +-----+
| | Border router | | Border Router
| | (RPL Root) | | (RPL Root)
+-----+ +-----+
X X
^ v o o ^ v o o
^ o o v o o o o o ^ o o v o o o o o
^ o o o v o o o o o ^ o o o v o o o o o
^ o o v o o o o o ^ o o v o o o o o
S o o o D o o o S o o o D o o o
o o o o o o o o
LLN LLN
Figure 3: Routing Stretch between S and D via common parent X Figure 3: Routing Stretch Between S and D via Common Parent X
along North-South Paths Along North-South Paths
As described in [RFC9008], the amount of stretch depends on the Mode As described in [RFC9008], the amount of stretch depends on the MOP:
of Operation:
* in Non-Storing Mode, all packets routed within the DODAG flow all * In Non-Storing Mode, all packets routed within the DODAG flow all
the way up to the Root of the DODAG. If the destination is in the the way up to the Root of the DODAG. If the destination is in the
same DODAG, the Root must encapsulate the packet to place an RH same DODAG, the Root must encapsulate the packet to place an RH
that has the strict source route information down the DODAG to the that has the strict source route information down the DODAG to the
destination. This will be the case even if the destination is destination. This will be the case even if the destination is
relatively close to the source and the Root is relatively far off. relatively close to the source and the Root is relatively far off.
* In Storing Mode, unless the destination is a child of the source, * In Storing Mode, unless the destination is a child of the source,
the packets will follow the default route up the DODAG as well. the packets will follow the default route up the DODAG as well.
If the destination is in the same DODAG, they will eventually If the destination is in the same DODAG, they will eventually
reach a common parent that has a route to the destination; at reach a common parent that has a route to the destination; at
worse, the common parent may also be the Root. From that common worst, the common parent may also be the Root. From that common
parent, the packet will follow a path down the DODAG that is parent, the packet will follow a path down the DODAG that is
optimized for the Objective Function that was used to build the optimized for the Objective Function that was used to build the
DODAG. DODAG.
It turns out that it is often beneficial to enable direct P2P routes, It turns out that it is often beneficial to enable direct P2P routes
either if the RPL route presents a stretch from the shortest path, or if either the RPL route presents a stretch from the shortest path or
if the new route is engineered with a different objective, and this the new route is engineered with a different objective, and this is
is even more critical in Non-Storing Mode than it is in Storing Mode, even more critical in Non-Storing Mode than it is in Storing Mode
because the routing stretch is wider. For that reason, earlier work because the routing stretch is wider. For that reason, earlier work
at the IETF introduced the "Reactive Discovery of Point-to-Point within the IETF was introduced: the "Reactive Discovery of
Routes in Low Power and Lossy Networks" [RFC6997], which specifies a Point-to-Point Routes in Low-Power and Lossy Networks" [RFC6997],
distributed method for establishing optimized P2P routes. This which specifies a distributed method for establishing optimized P2P
specification proposes an alternative based on centralized route routes. This specification proposes an alternative based on
computation. centralized route computation.
+-----+ +-----+
| | Border router | | Border Router
| | (RPL Root) | | (RPL Root)
+-----+ +-----+
| |
o o o o o o o o
o o o o o o o o o o o o o o o o o o
o o o o o o o o o o o o o o o o o o o o
o o o o o o o o o o o o o o o o o o
S>>A>>>B>>C>>>D o o o S>>A>>>B>>C>>>D o o o
o o o o o o o o
LLN LLN
Figure 4: More direct forward Route between S and D Figure 4: More Direct Forward Route Between S and D
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 Service Level Objective (SLO), e.g.,
reliability. in terms of latency and/or 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
[RFC9030], as a collection of potential paths that leverage redundant [RFC9030] as a collection of potential paths that leverage redundant
forwarding solutions along the way. This can be a DODAG or a more forwarding solutions along the way. This can be a DODAG or a more
complex structure that is only partially acyclic (e.g., per packet). complex structure that is only partially acyclic (e.g., per 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 so that
another DODAG by reversing the direction of each edge. A node at the another DODAG may be formed by reversing the direction of each edge.
Ingress of more than one segment in a Track may use one or more of A node at the Ingress of more than one segment in a Track may use one
these segments to forward a packet inside the Track. or more of these segments to forward a packet inside the Track.
A RPL Track is a collection of (one or more) parallel loose source A RPL Track is a collection of (one or more) parallel loose source-
routed sequences of nodes ordered from Ingress to Egress, each routed sequences of nodes ordered from Ingress to Egress, each
forming a protection path. The nodes in a Track are directly forming a protection path. The nodes in a Track are directly
connected, reachable via existing Tracks as illustrated in connected, reachable via existing Tracks as illustrated in
Section 3.5.2.3 or joined with strict segments of other nodes as Section 3.5.2.3 or joined with strict segments of other nodes as
shown in Section 3.5.1.3. The protection paths are expressed in RPL shown in Section 3.5.1.3. The protection paths are expressed in RPL
Non-Storing Mode and require an encapsulation to add a Source Route Non-Storing Mode and require an encapsulation to add a Source Route
Header, whereas the segments are expressed in RPL Storing Mode. Header, whereas the segments are expressed in RPL Storing Mode.
A path provides only one path between Ingress and Egress. It A path provides only one path between the Ingress and Egress. It
comprises exactly one protection path. A Stand-Alone segment comprises exactly one protection path. A stand-alone segment
implicitly defines a path from its Ingress to Egress. implicitly defines a path from its Ingress to Egress.
A complex Track forms a graph that provides a collection of potential A complex Track forms a graph that provides a collection of potential
paths to provide redundancy for the packets, either as a collection paths to provide redundancy for the packets, either as a collection
of protection paths that may be parallel or interleaved at certain of protection paths that may be parallel or interleaved at certain
points, or as a more generic DODAG. points or as a more generic DODAG.
3.4.2. Tracks and RPL Instances 3.4.2. Tracks and RPL Instances
Section 5.1. of [RPL] describes the RPL Instance and its encoding. Section 5.1 of [RPL] describes the RPL Instance and its encoding.
There can be up to 128 Global RPL Instances, for which there can be There can be up to 128 Global RPL Instances, for which there can be
one or more DODAGs, and there can be 64 local RPL Instances, with a one or more DODAGs, and there can be 64 Local RPL Instances, with a
namespace that is indexed by a DODAGID, where the DODAGID is a Unique namespace that is indexed by a DODAGID, where the DODAGID is a Unique
Local Address (ULA) or a Global Unicast Address (GUA) of the Root of Local Address (ULA) or a Global Unicast Address (GUA) of the Root of
the DODAG. Bit 0 (most significant) is set to 1 to signal a Local the DODAG. Bit 0 (most significant) is set to 1 to signal a Local
RPLInstanceID, as shown in Figure 5. By extension, this RPLInstanceID, as shown in Figure 5. By extension, this
specification expresses the value of the RPLInstanceID as a single specification expresses the value of the RPLInstanceID as a single
integer between 128 and 191, representing both the Local integer between 128 and 191, representing both the Local
RPLInstanceID in 0..63 in the rightmost bits and Bit 0 set. RPLInstanceID in 0..63 in the rightmost bits and bit 0 set.
0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7
+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+
|1|D| ID | Local RPLInstanceID in 0..63 |1|D| ID | Local RPLInstanceID in 0..63
+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+
| | | |
\ \ \ \
\ Bit 1 is set to 0 in Track IDs \ Bit 1 is set to 0 in Track IDs
Bit 0 set to 1 signals a local RPLInstanceID Bit 0 set to 1 signals a Local RPLInstanceID
Figure 5: Local RPLInstanceID Encoding Figure 5: Local RPLInstanceID Encoding
A Track typically forms an underlay to the main Instance, and is A Track typically forms an underlay to the main Instance and is
associated with a Local RPL Instance from which the RPLInstanceID is associated with a Local RPL Instance from which the RPLInstanceID is
used as the TrackID. When a packet is placed on a Track, it is used as the TrackID. When a packet is placed on a Track, it is IP-
encapsulated IP-in-IP with a RPL Option containing a RPI which in-IP encapsulated with a RPL Option containing RPL Packet
signals the RPLInstanceID. The encapsulating source IP address and Information (RPI) that signals the RPLInstanceID. The encapsulating
RPI Instance are set to the Track Ingress IP address and local source IP address and RPI Instance are set to the Track Ingress IP
RPLInstanceID, respectively, more in Section 6.3. address and Local RPLInstanceID, respectively; see more in
Section 6.3.
A Track typically offers service protection across several protection A Track typically offers service protection across several protection
paths. As a degraded form of a Track, a path made of a single paths. As a degraded form of a Track, a path made of a single
protection path (i.e., offering no protection) can be used as an protection path (i.e., offering no protection) can be used as an
alternative to a segment for forwarding along a RPL Instance. In alternative to a segment for forwarding along a RPL Instance. In
that case, instead of following native routes along the instance, the that case, instead of following native routes along the instance, the
packets are encapsulated to signal a more specific source-routed path packets are encapsulated to signal a more-specific source-routed path
between the loose hops in the encapsulated source routing header. between the loose hops in the encapsulated source routing header.
If the encapsulated packet follows a global instance, then the If the encapsulated packet follows a global instance, then the
protection path may be part of that global instance as well, for protection path may be part of that global instance as well, e.g.,
instance the global instance of the main DODAG. This can only be the global instance of the main DODAG. This can only be done for
done for global instances because the Ingress node that encapsulates global instances because the Ingress node that encapsulates the
the packets over the protection path is not the Root of the instance, packets over the protection path is not the Root of the instance, so
so the source address of the encapsulated packet cannot be used to the source address of the encapsulated packet cannot be used to
determine the Track along the way. determine the Track along the way.
3.5. path Signaling 3.5. Path Signaling
This specification enables setting up a P-Route along either a This specification enables setting up a P-Route along either a
protection path or a segment. A P-Route is installed and maintained protection path or a segment. A P-Route is installed and maintained
by the Root of the main DODAG using an extended RPL DAO message by the Root of the main DODAG using an extended RPL DAO message
called a Projected DAO (P-DAO), and a Track is composed of the called a P-DAO, and a Track is composed of the combination of one or
combination of one or more P-Routes. In order to clarify the more P-Routes. In order to clarify the techniques that may be used
techniques that may be used to install a P-Route, this section takes to install a P-Route, this section uses the simple case of the path
the simple case of the path illustrated in Figure 6. So the goal is illustrated in Figure 6. Thus, the goal is to build a path from node
to build a path from node A to E for packets towards E's neighbors F A to E for packets towards E's neighbors F and G along A, B, C, D,
and G along A, B, C, D and E as opposed to via the Root: and E as opposed to via the Root:
/===> F /===> F
A ===> B ===> C ===> D===> E < A ===> B ===> C ===> D===> E <
\===> G \===> G
Figure 6: Reference Track Figure 6: Reference Track
A P-DAO message for a Track signals the TrackID in the RPLInstanceID A P-DAO message for a Track signals the TrackID in the RPLInstanceID
field. In the case of a local RPL Instance, the address of the Track field. In the case of a Local RPL Instance, the address of the Track
Ingress is used as source to encapsulate packets along the Track. Ingress is used as the source to encapsulate packets along the Track.
The Track is signaled in the DODAGID field of the Projected DAO Base The Track is signaled in the DODAGID field of the P-DAO Base Object;
Object, see Figure 8. see Figure 8.
This specification introduces the Via Information Option (VIO) to This specification introduces the Via Information Option (VIO) to
signal a sequence of hops in a protection path or a segment in the signal a sequence of hops in a protection path or a segment in the
P-DAO messages, either in Storing Mode (SM-VIO) or Non-Storing Mode P-DAO messages, either in Storing Mode (SM-VIO) or in Non-Storing
(NSM-VIO). One P-DAO message contains a single VIO, associated to Mode (NSM-VIO). One P-DAO message contains a single VIO, which is
one or more RPL Target Options that signal the destination IPv6 associated to one or more RPL Target Options that signal the
addresses that can reached along the Track (more in Section 5.3). destination IPv6 addresses that can reached along the Track (see more
in Section 5.3).
Before diving deeper into Track and segment signaling and operation, Before diving deeper into Track and segment signaling and operation,
this section provides examples of how route projection works through this section provides examples of how route projection works through
variations of a simple example. This simple example illustrates the variations of a simple example. This simple example illustrates the
case of host routes, though RPL Targets can also be prefixes. case of host routes, though RPL Targets can also be prefixes.
Conventionally we use ==> to represent a strict hop and --> for a Conventionally, we use ==> to represent a strict hop and --> for a
loose hop. We use "-to-", such as in C==>D==>E-to-F to represent loose hop. We use "-to-", such as in C==>D==>E-to-F, to represent
coma-separated Targets, e.g., F is a Target for segment C==>D==>E. coma-separated Targets, e.g., F is a Target for segment C==>D==>E.
In this example, A is the Track Ingress and E is the Track Egress. C In the example below, A is the Track Ingress and E is the Track
is a stitching point. F and G are "external” Targets for the Track, Egress. C is a stitching point. F and G are "external" Targets for
and become reachable from A via the Track A (Ingress) to E (Egress the Track and become reachable from A via Track A (Ingress) to E
and implicit Target in Non-Storing Mode) leading to F and G (explicit (Egress and implicit Target in Non-Storing Mode), leading to F and G
Targets). (explicit Targets).
In a general manner the desired outcome is as follows: In a general manner, the desired outcome is as follows:
* Targets are E, F, and G * Targets are E, F, and G
* P-DAO 1 signals C==>D==>E * P-DAO 1 signals C==>D==>E
* P-DAO 2 signals A==>B==>C * P-DAO 2 signals A==>B==>C
* P-DAO 3 signals F and G via the A-->E Track * P-DAO 3 signals F and G via the A-->E Track
P-DAO 3 may be omitted if P-DAO 1 and 2 signal F and G as Targets. P-DAO 3 may be omitted if P-DAOs 1 and 2 signal F and G as Targets.
Loose sequences of hops are expressed in Non-Storing Mode; this is Loose sequences of hops are expressed in Non-Storing Mode; this is
why P-DAO 3 contains a NSM-VIO. With this specification: why P-DAO 3 contains an NSM-VIO. With this specification:
* the DODAGID to be used by the Ingress as source address is * The DODAGID to be used by the Ingress as the source address is
signaled in the DAO base object (see Figure 8) . signaled in the DAO Base Object (see Figure 8).
* the via list in the VIO is encoded as an SRH-6LoRH (see * The via list in the VIO is encoded as an SRH-6LoRH (see
Figure 16), and it starts with the address of the first hop node Figure 16), and it starts with the address of the first-hop node
after the Ingress node in the loose hop sequence. after the Ingress node in the loose hop sequence.
* the via list ends with the address of the Egress node. * The via list ends with the address of the Egress node.
Note well:
| The Egress of a Non-Storing Mode P-Route is implicitly a target;
| it is not listed in the RPL Target Options but still accounted for
| as if it was. The only exception is when the Egress is the only
| address listed in the VIO, in which case it would indicate via
| itself which would be non-sensical.
Also: | Note 1: The Egress of a Non-Storing Mode P-Route is implicitly
| a target; it is not listed in the RPL Target Options but is
| still accounted for as if it was. The only exception is when
| the Egress is the only address listed in the VIO, in which case
| it would indicate via itself, which would be nonsensical.
| By design, the list of nodes in a VIO in Non-Storing Mode is | Note 2: By design, the list of nodes in a VIO in Non-Storing
| exactly the list that shows in the encapsulation SRH. So in the | Mode is exactly the list that shows in the encapsulation SRH.
| cases detailed below, if the Mode of the P-DAO is Non-Storing, | So in the cases detailed below, if the Mode of the P-DAO is
| then the VIO row can be read as indicating the SRH as well. | Non-Storing, then the VIO row can be read as indicating the SRH
| as well.
3.5.1. Using Storing Mode Segments 3.5.1. Using Storing Mode Segments
A==>B==>C and C==>D==>E are segments of the same Track. Note that A==>B==>C and C==>D==>E are segments of the same Track. Note that
the Storing Mode signaling imposes strict continuity in a segment, the Storing Mode signaling imposes strict continuity in a segment,
since the P-DAO is passed hop by hop, as a classical DAO is, along since the P-DAO is passed hop by hop, as a classical DAO is, along
the reverse datapath that it signals. One benefit of strict routing the reverse datapath that it signals. One benefit of strict routing
is that loops are avoided along the Track. is that loops are avoided along the Track.
3.5.1.1. Stitched Segments 3.5.1.1. Stitched Segments
In this formulation: In this formulation:
* P-DAO 1 signals C==>D==>E-to-F,G * P-DAO 1 signals C==>D==>E-to-F,G
* P-DAO 2 signals A==>B==>C-to-F,G * P-DAO 2 signals A==>B==>C-to-F,G
Storing Mode P-DAO 1 is sent to E and when it is successfully Storing Mode P-DAO 1 is sent to E, and when it is successfully
acknowledged, Storing Mode P-DAO 2 is sent to C, as follows: acknowledged, Storing Mode P-DAO 2 is sent to C as follows:
+====================+==============+==============+ +====================+==============+==============+
| Field | P-DAO 1 to E | P-DAO 2 to C | | Field | P-DAO 1 to E | P-DAO 2 to C |
+====================+==============+==============+ +====================+==============+==============+
| Mode | Storing | Storing | | Mode | Storing | Storing |
+--------------------+--------------+--------------+ +====================+--------------+--------------+
| Track Ingress | A | A | | Track Ingress | A | A |
+--------------------+--------------+--------------+ +====================+--------------+--------------+
| (DODAGID, TrackID) | (A, 129) | (A, 129) | | (DODAGID, TrackID) | (A, 129) | (A, 129) |
+--------------------+--------------+--------------+ +====================+--------------+--------------+
| SegmentID | 1 | 2 | | SegmentID | 1 | 2 |
+--------------------+--------------+--------------+ +====================+--------------+--------------+
| VIO | C, D, E | A, B, C | | VIO | C, D, E | A, B, C |
+--------------------+--------------+--------------+ +====================+--------------+--------------+
| Targets | F, G | F, G | | Targets | F, G | F, G |
+--------------------+--------------+--------------+ +====================+--------------+--------------+
Table 1: P-DAO Messages Table 1: P-DAO Messages
As a result the RIBs are set as follows: As a result, the RIBs are set as follows:
+======+=============+=========+=============+==========+ +======+=============+=========+=============+==========+
| Node | Destination | Origin | Next Hop(s) | TrackID | | Node | Destination | Origin | Next Hop(s) | TrackID |
+======+=============+=========+=============+==========+ +======+=============+=========+=============+==========+
| E | F, G | P-DAO 1 | Neighbor | (A, 129) | | E | F, G | P-DAO 1 | Neighbor | (A, 129) |
+------+-------------+---------+-------------+----------+ +------+-------------+---------+-------------+----------+
| D | E | P-DAO 1 | Neighbor | (A, 129) | | D | E | P-DAO 1 | Neighbor | (A, 129) |
+------+-------------+---------+-------------+----------+ +------+-------------+---------+-------------+----------+
| " | F, G | P-DAO 1 | E | (A, 129) | | " | F, G | P-DAO 1 | E | (A, 129) |
+------+-------------+---------+-------------+----------+ +------+-------------+---------+-------------+----------+
| C | D | P-DAO 1 | Neighbor | (A, 129) | | C | D | P-DAO 1 | Neighbor | (A, 129) |
+------+-------------+---------+-------------+----------+ +------+-------------+---------+-------------+----------+
| " | F, G | P-DAO 1 | D | (A, 129) | | " | F, G | P-DAO 1 | D | (A, 129) |
+------+-------------+---------+-------------+----------+ +------+-------------+---------+-------------+----------+
| B | C | P-DAO 2 | Neighbor | (A, 129) | | B | C | P-DAO 2 | Neighbor | (A, 129) |
+------+-------------+---------+-------------+----------+ +------+-------------+---------+-------------+----------+
| " | F, G | P-DAO 2 | C | (A, 129) | | " | F, G | P-DAO 2 | C | (A, 129) |
+------+-------------+---------+-------------+----------+ +------+-------------+---------+-------------+----------+
| A | B | P-DAO 2 | Neighbor | (A, 129) | | A | B | P-DAO 2 | Neighbor | (A, 129) |
+------+-------------+---------+-------------+----------+ +------+-------------+---------+-------------+----------+
| " | F, G | P-DAO 2 | B | (A, 129) | | " | F, G | P-DAO 2 | B | (A, 129) |
+------+-------------+---------+-------------+----------+ +------+-------------+---------+-------------+----------+
Table 2: RIB setting Table 2: RIB Settings
Note:
| the " sign is used throughout those tables to indicate the same | Note: The " sign is used throughout the tables in this document
| value as in the row above. | to indicate the same value as in the row above.
Packets originating at A going to F or G do not require encapsulation Packets originating at A and going to F or G do not require
as the RPI can be placed in the native header chain. For packets encapsulation as the RPI can be placed in the native header chain.
that it routes, A must encapsulate to add the RPI that signals the For packets that it routes, A must encapsulate to add the RPI that
TrackID; the outer headers of the packets that are forwarded along signals the TrackID; the outer headers of the packets that are
the Track have the following settings: forwarded along the Track have the following settings:
+========+===================+===================+================+ +========+=====================+==========================+=========+
| Header | IPv6 Source Addr. | IPv6 Dest. Addr. | TrackID in RPI | | Header | IPv6 Source Address | IPv6 Destination | TrackID |
+========+===================+===================+================+ | | | Address | in RPI |
| Outer | A | F or G | (A, 129) | +========+=====================+==========================+=========+
+--------+-------------------+-------------------+----------------+ | Outer | A | F or G | (A, |
| Inner | Any but A | F or G | N/A | | | | | 129) |
+--------+-------------------+-------------------+----------------+ +--------+---------------------+--------------------------+---------+
| Inner | Any but A | F or G | N/A |
+--------+---------------------+--------------------------+---------+
Table 3: Packet Header Settings Table 3: Packet Header Settings
As an example, say that A has a packet for F. Using the RIB in As an example, say that A has a packet for F. Using the RIB in
Table 2: Table 2:
* From P-DAO 2: A forwards to B and B forwards to C. * From P-DAO 2: A forwards to B, and B forwards to C.
* From P-DAO 1: C forwards to D and D forwards to E. * From P-DAO 1: C forwards to D, and D forwards to E.
* From Neighbor Cache Entry: E delivers the packet to F. * From Neighbor Cache Entry: E delivers the packet to F.
3.5.1.2. External Routes 3.5.1.2. External Routes
In this example, we consider F and G as destinations that are In this example, we consider F and G as destinations that are
external to the Track as a DODAG, as discussed in section 4.1.1. of external to the Track as a DODAG, as discussed in Section 4.1.1 of
[RFC9008]. We then apply the directives for encapsulating in that [RFC9008]. We then apply the directives for encapsulating in that
case (more in Section 6.7). case (see more in Section 6.7).
In this formulation, we set up the protection path explicitly, which In this formulation, we set up the protection path explicitly, which
creates less routing state in intermediate hops at the expense of creates less routing state in intermediate hops at the expense of
larger packets to accommodate source routing: larger packets to accommodate source routing:
* P-DAO 1 signals C==>D==>E-to-E * P-DAO 1 signals C==>D==>E-to-E
* P-DAO 2 signals A==>B==>C-to-E * P-DAO 2 signals A==>B==>C-to-E
* P-DAO 3 signals F and G via the A-->E-to-F,G Track * P-DAO 3 signals F and G via the A-->E-to-F,G Track
Storing Mode P-DAO 1 and 2, and Non-Storing Mode P-DAO 3, are sent to Storing Mode P-DAOs 1 and 2 and Non-Storing Mode P-DAO 3 are sent to
E, C and A, respectively, as follows: E, C, and A, respectively, as follows:
+====================+==============+==============+==============+ +====================+==============+==============+==============+
| | P-DAO 1 to E | P-DAO 2 to C | P-DAO 3 to A | | | P-DAO 1 to E | P-DAO 2 to C | P-DAO 3 to A |
+====================+==============+==============+==============+ +====================+==============+==============+==============+
| Mode | Storing | Storing | Non-Storing | | Mode | Storing | Storing | Non-Storing |
+--------------------+--------------+--------------+--------------+ +====================+--------------+--------------+--------------+
| Track Ingress | A | A | A | | Track Ingress | A | A | A |
+--------------------+--------------+--------------+--------------+ +====================+--------------+--------------+--------------+
| (DODAGID, TrackID) | (A, 129) | (A, 129) | (A, 129) | | (DODAGID, TrackID) | (A, 129) | (A, 129) | (A, 129) |
+--------------------+--------------+--------------+--------------+ +====================+--------------+--------------+--------------+
| SegmentID | 1 | 2 | 3 | | SegmentID | 1 | 2 | 3 |
+--------------------+--------------+--------------+--------------+ +====================+--------------+--------------+--------------+
| VIO | C, D, E | A, B, C | E | | VIO | C, D, E | A, B, C | E |
+--------------------+--------------+--------------+--------------+ +====================+--------------+--------------+--------------+
| Targets | E | E | F, G | | Targets | E | E | F, G |
+--------------------+--------------+--------------+--------------+ +====================+--------------+--------------+--------------+
Table 4: P-DAO Messages Table 4: P-DAO Messages
Note in the above that E is not an implicit Target in Storing mode, Note in the above that E is not an implicit Target in Storing Mode,
so it must be added in the RTO for P-DAO 1 and 2. E is not an so it must be added in the RPL Target Option (RTO) for P-DAOs 1 and
implicit Target for P-DAO 3 either, since E is the only entry in the 2. E is not an implicit Target for P-DAO 3 either, since E is the
VIO. only entry in the VIO.
As a result the RIBs are set as follows: As a result, the RIBs are set as follows:
+======+=============+=========+=============+==========+ +======+=============+=========+=============+==========+
| Node | Destination | Origin | Next Hop(s) | TrackID | | Node | Destination | Origin | Next Hop(s) | TrackID |
+======+=============+=========+=============+==========+ +======+=============+=========+=============+==========+
| E | F, G | P-DAO 1 | Neighbor | (A, 129) | | E | F, G | P-DAO 1 | Neighbor | (A, 129) |
+------+-------------+---------+-------------+----------+ +------+-------------+---------+-------------+----------+
| D | E | P-DAO 1 | Neighbor | (A, 129) | | D | E | P-DAO 1 | Neighbor | (A, 129) |
+------+-------------+---------+-------------+----------+ +------+-------------+---------+-------------+----------+
| C | D | P-DAO 1 | Neighbor | (A, 129) | | C | D | P-DAO 1 | Neighbor | (A, 129) |
+------+-------------+---------+-------------+----------+ +------+-------------+---------+-------------+----------+
| " | E | P-DAO 1 | D | (A, 129) | | " | E | P-DAO 1 | D | (A, 129) |
+------+-------------+---------+-------------+----------+ +------+-------------+---------+-------------+----------+
| B | C | P-DAO 2 | Neighbor | (A, 129) | | B | C | P-DAO 2 | Neighbor | (A, 129) |
+------+-------------+---------+-------------+----------+ +------+-------------+---------+-------------+----------+
| " | E | P-DAO 2 | C | (A, 129) | | " | E | P-DAO 2 | C | (A, 129) |
+------+-------------+---------+-------------+----------+ +------+-------------+---------+-------------+----------+
| A | B | P-DAO 2 | Neighbor | (A, 129) | | A | B | P-DAO 2 | Neighbor | (A, 129) |
+------+-------------+---------+-------------+----------+ +------+-------------+---------+-------------+----------+
| " | E | P-DAO 2 | B | (A, 129) | | " | E | P-DAO 2 | B | (A, 129) |
+------+-------------+---------+-------------+----------+ +------+-------------+---------+-------------+----------+
| " | F, G | P-DAO 3 | E | (A, 129) | | " | F, G | P-DAO 3 | E | (A, 129) |
+------+-------------+---------+-------------+----------+ +------+-------------+---------+-------------+----------+
Table 5: RIB setting Table 5: RIB Settings
Packets from A to E do not require an encapsulation. This is why in Packets from A to E do not require an encapsulation. In the tables
the tables below, E may show as IPv6 Destination Address only if the below, this is why E may show as an IPv6 destination address only if
IPv6 Source Address X is different from A. Conversely, the the IPv6 source address X is different from A. Conversely, the
encapsulation is always done when the IPv6 Destination Address is F encapsulation is always done when the IPv6 destination address is F
or G. Other destination addresses do not match this P-Route and are or G. Other destination addresses do not match this P-Route and are
not subject to encapsulation. not subject to encapsulation.
The outer headers of the packets that are forwarded along the Track The outer headers of the packets that are forwarded along the Track
have the following settings: have the following settings:
+========+===================+===========================+=========+ +========+=====================+==========================+=========+
| Header | IPv6 Source Addr. | IPv6 Dest. Addr. | TrackID | | Header | IPv6 Source | IPv6 Destination Address | TrackID |
| | | | in RPI | | | Address | | in RPI |
+========+===================+===========================+=========+ +========+=====================+==========================+=========+
| Outer | A | E | (A, | | Outer | A | E | (A, |
| | | | 129) | | | | | 129) |
+--------+-------------------+---------------------------+---------+ +--------+---------------------+--------------------------+---------+
| Inner | X | Either F or G. If X!=A, | N/A | | Inner | X | Either F or G. If X!=A, | N/A |
| | | then E is also permitted. | | | | | E is also permitted. | |
+--------+-------------------+---------------------------+---------+ +--------+---------------------+--------------------------+---------+
Table 6: Packet Header Settings Table 6: Packet Header Settings
As an example, say that A has a packet for F. Using the RIB in As an example, say that A has a packet for F. Using the RIB in
Table 5: Table 5:
* From P-DAO 3: A encapsulates the packet and sends it down the * From P-DAO 3: A encapsulates the packet and sends it down the
Track signaled by P-DAO 3, with the outer header above. Now the Track signaled by P-DAO 3, with the outer header above. Now the
packet destination is E. packet destination is E.
* From P-DAO 2: A forwards to B and B forwards to C. * From P-DAO 2: A forwards to B, and B forwards to C.
* From P-DAO 1: C forwards to D and D forwards to E; E decapsulates * From P-DAO 1: C forwards to D, and D forwards to E; E decapsulates
the packet. the packet.
* From Neighbor Cache Entry: E delivers packets to F or G. * From Neighbor Cache Entry: E delivers packets to F or G.
3.5.1.3. Segment Routing 3.5.1.3. Segment Routing
In this formulation protection paths are leveraged to combine In this formulation, protection paths are leveraged to combine
segments and form a Graph. The packets are source routed from a segments and form a graph. The packets are source routed from a
segment to the next to adapt the path: segment to the next to adapt the path:
* P-DAO 1 signals C==>D==>E-to-E * P-DAO 1 signals C==>D==>E-to-E
* P-DAO 2 signals A==>B-to-B,C * P-DAO 2 signals A==>B-to-B,C
* P-DAO 3 signals F and G via the A-->C-->E-to-(E),F,G Track * P-DAO 3 signals F and G via the A-->C-->E-to-(E),F,G Track
Storing Mode P-DAO 1 and 2, and Non-Storing Mode P-DAO 3, are sent to
E, B and A, respectively, as follows: Storing Mode P-DAOs 1 and 2 and Non-Storing Mode P-DAO 3 are sent to
E, B, and A, respectively, as follows:
+====================+==============+==============+==============+ +====================+==============+==============+==============+
| | P-DAO 1 to E | P-DAO 2 to B | P-DAO 3 to A | | | P-DAO 1 to E | P-DAO 2 to B | P-DAO 3 to A |
+====================+==============+==============+==============+ +====================+==============+==============+==============+
| Mode | Storing | Storing | Non-Storing | | Mode | Storing | Storing | Non-Storing |
+--------------------+--------------+--------------+--------------+ +====================+--------------+--------------+--------------+
| Track Ingress | A | A | A | | Track Ingress | A | A | A |
+--------------------+--------------+--------------+--------------+ +====================+--------------+--------------+--------------+
| (DODAGID, TrackID) | (A, 129) | (A, 129) | (A, 129) | | (DODAGID, TrackID) | (A, 129) | (A, 129) | (A, 129) |
+--------------------+--------------+--------------+--------------+ +====================+--------------+--------------+--------------+
| SegmentID | 1 | 2 | 3 | | SegmentID | 1 | 2 | 3 |
+--------------------+--------------+--------------+--------------+ +====================+--------------+--------------+--------------+
| VIO | C, D, E | A, B | C, E | | VIO | C, D, E | A, B | C, E |
+--------------------+--------------+--------------+--------------+ +====================+--------------+--------------+--------------+
| Targets | E | B, C | F, G | | Targets | E | B, C | F, G |
+--------------------+--------------+--------------+--------------+ +====================+--------------+--------------+--------------+
Table 7: P-DAO Messages Table 7: P-DAO Messages
Note in the above that the segment can terminate at the loose hop as Note in the table above that the segment can terminate at the loose
used in the example of P-DAO 1 or at the previous hop as done with hop as used in the example of P-DAO 1 or at the previous hop as done
P-DAO 2. Both methods are possible on any segment joined by a loose with P-DAO 2. Both methods are possible on any segment joined by a
protection path. P-DAO 1 generates more signaling since E is the loose protection path. P-DAO 1 generates more signaling since E is
segment Egress when D could be, but has the benefit that it validates the segment Egress when D could be, but a benefit is that it
that the connectivity between D and E still exists. validates that the connectivity between D and E still exists.
As a result the RIBs are set as follows: As a result, the RIBs are set as follows:
+======+=============+=========+=============+==========+ +======+=============+=========+=============+==========+
| Node | Destination | Origin | Next Hop(s) | TrackID | | Node | Destination | Origin | Next Hop(s) | TrackID |
+======+=============+=========+=============+==========+ +======+=============+=========+=============+==========+
| E | F, G | P-DAO 1 | Neighbor | (A, 129) | | E | F, G | P-DAO 1 | Neighbor | (A, 129) |
+------+-------------+---------+-------------+----------+ +------+-------------+---------+-------------+----------+
| D | E | P-DAO 1 | Neighbor | (A, 129) | | D | E | P-DAO 1 | Neighbor | (A, 129) |
+------+-------------+---------+-------------+----------+ +------+-------------+---------+-------------+----------+
| C | D | P-DAO 1 | Neighbor | (A, 129) | | C | D | P-DAO 1 | Neighbor | (A, 129) |
+------+-------------+---------+-------------+----------+ +------+-------------+---------+-------------+----------+
| " | E | P-DAO 1 | D | (A, 129) | | " | E | P-DAO 1 | D | (A, 129) |
+------+-------------+---------+-------------+----------+ +------+-------------+---------+-------------+----------+
| B | C | P-DAO 2 | Neighbor | (A, 129) | | B | C | P-DAO 2 | Neighbor | (A, 129) |
+------+-------------+---------+-------------+----------+ +------+-------------+---------+-------------+----------+
| A | B | P-DAO 2 | Neighbor | (A, 129) | | A | B | P-DAO 2 | Neighbor | (A, 129) |
+------+-------------+---------+-------------+----------+ +------+-------------+---------+-------------+----------+
| " | C | P-DAO 2 | B | (A, 129) | | " | C | P-DAO 2 | B | (A, 129) |
+------+-------------+---------+-------------+----------+ +------+-------------+---------+-------------+----------+
| " | E, F, G | P-DAO 3 | C, E | (A, 129) | | " | E, F, G | P-DAO 3 | C, E | (A, 129) |
+------+-------------+---------+-------------+----------+ +------+-------------+---------+-------------+----------+
Table 8: RIB setting Table 8: RIB Settings
Packets originated at A to E do not require an encapsulation, but Packets originated at A to E do not require an encapsulation, but
carry a SRH via C. The outer headers of the packets that are they carry an SRH via C. The outer headers of the packets that are
forwarded along the Track have the following settings: forwarded along the Track have the following settings:
+========+===================+===========================+=========+ +========+=====================+==========================+=========+
| Header | IPv6 Source Addr. | IPv6 Dest. Addr. | TrackID | | Header | IPv6 Source | IPv6 Destination Address | TrackID |
| | | | in RPI | | | Address | | in RPI |
+========+===================+===========================+=========+ +========+=====================+==========================+=========+
| Outer | A | C until C then E | (A, | | Outer | A | C until C then E | (A, |
| | | | 129) | | | | | 129) |
+--------+-------------------+---------------------------+---------+ +--------+---------------------+--------------------------+---------+
| Inner | X | Either F or G. If X!=A, | N/A | | Inner | X | Either F or G. If X!=A, | N/A |
| | | then E is also permitted. | | | | | E is also permitted. | |
+--------+-------------------+---------------------------+---------+ +--------+---------------------+--------------------------+---------+
Table 9: Packet Header Settings Table 9: Packet Header Settings
As an example, say that A has a packet for F. Using the RIB in As an example, say that A has a packet for F. Using the RIB in
Table 8: Table 8:
* From P-DAO 3: A encapsulates the packet the Track signaled by * From P-DAO 3: A encapsulates the packet the Track signaled by
P-DAO 3, with the outer header above. Now the destination in the P-DAO 3, with the outer header above. Now the destination in the
IPv6 Header is C, and a SRH signals the final destination is E. IPv6 header is C, and an SRH signals that the final destination is
E.
* From P-DAO 2: A forwards to B and B forwards to C. * From P-DAO 2: A forwards to B, and B forwards to C.
* From P-DAO 3: C processes the SRH and sets the destination in the * From P-DAO 3: C processes the SRH and sets the destination in the
IPv6 Header to E. IPv6 header to E.
* From P-DAO 1: C forwards to D and D forwards to E; E decapsulates * From P-DAO 1: C forwards to D, and D forwards to E; E decapsulates
the packet. the packet.
* From the Neighbor Cache Entry: E delivers packets to F or G. * From the Neighbor Cache Entry: E delivers packets to F or G.
3.5.2. Using Non-Storing Mode joining Tracks 3.5.2. Using Non-Storing Mode Joining Tracks
In this formulation: In this formulation:
* P-DAO 1 signals C==>D==>E-to-(E),F,G * P-DAO 1 signals C==>D==>E-to-(E),F,G
* P-DAO 2 signals A==>B==>C-to-(C),E,F,G * P-DAO 2 signals A==>B==>C-to-(C),E,F,G
A==>B==>C and C==>D==>E are Tracks expressed as Non-Storing P-DAOs. A==>B==>C and C==>D==>E are Tracks expressed as Non-Storing Mode
P-DAOs.
3.5.2.1. Stitched Tracks 3.5.2.1. Stitched Tracks
Non-Storing Mode P-DAO 1 and 2 are sent to C and A respectively, as Non-Storing Mode P-DAO 1 and 2 are sent to C and A, respectively, as
follows: follows:
+====================+==============+==============+ +====================+==============+==============+
| | P-DAO 1 to C | P-DAO 2 to A | | | P-DAO 1 to C | P-DAO 2 to A |
+====================+==============+==============+ +====================+==============+==============+
| Mode | Non-Storing | Non-Storing | | Mode | Non-Storing | Non-Storing |
+--------------------+--------------+--------------+ +====================+--------------+--------------+
| Track Ingress | C | A | | Track Ingress | C | A |
+--------------------+--------------+--------------+ +====================+--------------+--------------+
| (DODAGID, TrackID) | (C, 131) | (A, 131) | | (DODAGID, TrackID) | (C, 131) | (A, 131) |
+--------------------+--------------+--------------+ +====================+--------------+--------------+
| SegmentID | 1 | 1 | | SegmentID | 1 | 1 |
+--------------------+--------------+--------------+ +====================+--------------+--------------+
| VIO | D, E | B, C | | VIO | D, E | B, C |
+--------------------+--------------+--------------+ +====================+--------------+--------------+
| Targets | F, G | E, F, G | | Targets | F, G | E, F, G |
+--------------------+--------------+--------------+ +====================+--------------+--------------+
Table 10: P-DAO Messages Table 10: P-DAO Messages
As a result the RIBs are set as follows (using ND to indicate that As a result, the RIBs are set as follows (using "ND" to indicate that
the address is discovered by IPv6 Neighbor Discovery the address is discovered by IPv6 Neighbor Discovery [RFC4861]
[RFC4861][RFC8505] or an equivalent method: [RFC8505] or an equivalent method):
+======+=============+=========+=============+==========+ +======+=============+=========+=============+==========+
| Node | Destination | Origin | Next Hop(s) | TrackID | | Node | Destination | Origin | Next Hop(s) | TrackID |
+======+=============+=========+=============+==========+ +======+=============+=========+=============+==========+
| E | F, G | ND | Neighbor | Any | | E | F, G | ND | Neighbor | Any |
+------+-------------+---------+-------------+----------+ +------+-------------+---------+-------------+----------+
| D | E | ND | Neighbor | Any | | D | E | ND | Neighbor | Any |
+------+-------------+---------+-------------+----------+ +------+-------------+---------+-------------+----------+
| C | D | ND | Neighbor | Any | | C | D | ND | Neighbor | Any |
+------+-------------+---------+-------------+----------+ +------+-------------+---------+-------------+----------+
| " | E, F, G | P-DAO 1 | D, E | (C, 131) | | " | E, F, G | P-DAO 1 | D, E | (C, 131) |
+------+-------------+---------+-------------+----------+ +------+-------------+---------+-------------+----------+
| B | C | ND | Neighbor | Any | | B | C | ND | Neighbor | Any |
+------+-------------+---------+-------------+----------+ +------+-------------+---------+-------------+----------+
| A | B | ND | Neighbor | Any | | A | B | ND | Neighbor | Any |
+------+-------------+---------+-------------+----------+ +------+-------------+---------+-------------+----------+
| " | C, E, F, G | P-DAO 2 | B, C | (A, 131) | | " | C, E, F, G | P-DAO 2 | B, C | (A, 131) |
+------+-------------+---------+-------------+----------+ +------+-------------+---------+-------------+----------+
Table 11: RIB setting Table 11: RIB Settings
Packets originated at A to E, F and G could be generated with the RPI Packets originated at A to E, F, and G could be generated with the
and the SRH, and no encapsulation. Alternatively, A may generate a RPI and the SRH and no encapsulation. Alternatively, A may generate
native packet to the target, and then encapsulate it with an RPI and a native packet to the target and then encapsulate it with an RPI and
an SRH indicating the source-routed path leading to E, as it would an SRH indicating the source-routed path leading to E, as it would
for a packet that it routes coming from another node. This is for a packet that it routes coming from another node. This is
effectively the same case as for packets generated by the root in a effectively the same case as for packets generated by the root in a
RPL network in Non-Storing mode, see section 8.1.3 of [RFC9008]. The RPL network in Non-Storing Mode; see Section 8.1.3 of [RFC9008]. The
latter is often preferred since it leads to a single code path, and latter is often preferred since it leads to a single code path, and
the destination when it is F or G, does not need to understand and when the destination is F or G, it does not need to understand and
process the RPI or the SRH. Either way, the packets to E, F, or G process the RPI or the SRH. Either way, the packets to E, F, or G
carry an SRH via B and C, and when they reach C, C needs to carry an SRH via B and C, and when they reach C, C needs to
encapsulate them again to add an SRH via D and E. The encapsulating encapsulate them again to add an SRH via D and E. The encapsulating
headers of packets that are forwarded along the Track between C and E headers of packets that are forwarded along the Track between C and E
have the following settings: have the following settings:
+========+===================+===================+================+ +========+=====================+==========================+=========+
| Header | IPv6 Source Addr. | IPv6 Dest. Addr. | TrackID in RPI | | Header | IPv6 Source Address | IPv6 Destination | TrackID |
+========+===================+===================+================+ | | | Address | in RPI |
| Outer | C | D until D then E | (C, 131) | +========+=====================+==========================+=========+
+--------+-------------------+-------------------+----------------+ | Outer | C | D until D then E | (C, |
| Inner | X | E, F, or G | N/A | | | | | 131) |
+--------+-------------------+-------------------+----------------+ +--------+---------------------+--------------------------+---------+
| Inner | X | E, F, or G | N/A |
+--------+---------------------+--------------------------+---------+
Table 12: Packet Header Settings between C and E Table 12: Packet Header Settings Between C and E
As an example, say that A has a packet for F. Using the RIB in As an example, say that A has a packet for F. Using the RIB in
Table 11: Table 11:
* From P-DAO 2: A encapsulates the packet with destination of F in * From P-DAO 2: A encapsulates the packet with a destination of F in
the Track signaled by P-DAO 2. The outer header has source A, the Track signaled by P-DAO 2. The outer header has source A,
destination B, an SRH that indicates C as the next loose hop, and destination B, an SRH that indicates C as the next loose hop, and
a RPI indicating a TrackID of 131 from A's namespace, which is an RPI indicating a TrackID of 131 from A's namespace, which is
distinct from TrackID of 131 from C's. distinct from a TrackID of 131 from C's.
* From the SRH: Packets forwarded by B have source A, destination C, * From the SRH: Packets forwarded by B have source A, destination C,
a consumed SRH, and a RPI indicating a TrackID of 131 from A's a consumed SRH, and an RPI indicating a TrackID of 131 from A's
namespace. C decapsulates. namespace. C decapsulates.
* From P-DAO 1: C encapsulates the packet with destination of F in * From P-DAO 1: C encapsulates the packet with a destination of F in
the Track signaled by P-DAO 1. The outer header has source C, the Track signaled by P-DAO 1. The outer header has source C,
destination D, an SRH that indicates E as the next loose hop, and destination D, an SRH that indicates E as the next loose hop, and
a RPI indicating a TrackID of 131 from C's namespace. E an RPI indicating a TrackID of 131 from C's namespace. E
decapsulates. decapsulates.
3.5.2.2. External Routes 3.5.2.2. External Routes
In this formulation: In this formulation:
* P-DAO 1 signals C==>D==>E-to-(E) * P-DAO 1 signals C==>D==>E-to-(E)
* P-DAO 2 signals A==>B==>C-to-(C),E * P-DAO 2 signals A==>B==>C-to-(C),E
* P-DAO 3 signals F and G via the A-->E-to-F,G Track * P-DAO 3 signals F and G via the A-->E-to-F,G Track
Non-Storing Mode P-DAO 1 is sent to C and Non-Storing Mode P-DAO 2 Non-Storing Mode P-DAO 1 is sent to C, and Non-Storing Mode P-DAOs 2
and 3 are sent to A, as follows: and 3 are sent to A, as follows:
+====================+==============+==============+==============+ +====================+==============+==============+==============+
| | P-DAO 1 to C | P-DAO 2 to A | P-DAO 3 to A | | | P-DAO 1 to C | P-DAO 2 to A | P-DAO 3 to A |
+====================+==============+==============+==============+ +====================+==============+==============+==============+
| Mode | Non-Storing | Non-Storing | Non-Storing | | Mode | Non-Storing | Non-Storing | Non-Storing |
+--------------------+--------------+--------------+--------------+ +====================+--------------+--------------+--------------+
| Track Ingress | C | A | A | | Track Ingress | C | A | A |
+--------------------+--------------+--------------+--------------+ +====================+--------------+--------------+--------------+
| (DODAGID, TrackID) | (C, 131) | (A, 129) | (A, 141) | | (DODAGID, TrackID) | (C, 131) | (A, 129) | (A, 141) |
+--------------------+--------------+--------------+--------------+ +====================+--------------+--------------+--------------+
| SegmentID | 1 | 1 | 1 | | SegmentID | 1 | 1 | 1 |
+--------------------+--------------+--------------+--------------+ +====================+--------------+--------------+--------------+
| VIO | D, E | B, C | E | | VIO | D, E | B, C | E |
+--------------------+--------------+--------------+--------------+ +====================+--------------+--------------+--------------+
| Targets | | E | F, G | | Targets | | E | F, G |
+--------------------+--------------+--------------+--------------+ +====================+--------------+--------------+--------------+
Table 13: P-DAO Messages Table 13: P-DAO Messages
Note in the above that E is an implicit Target in P-DAO 1 and so is C Note in the table above that E is an implicit Target in P-DAO 1 and
in P-DAO 2. As Non-Storing Mode Egress nodes addresses, they not so is C in P-DAO 2. As Non-Storing Mode Egress node addresses, they
listed in the respective RTOs. are not listed in the respective RTOs.
As a result the RIBs are set as follows: As a result, the RIBs are set as follows:
+======+=============+=========+=============+==========+ +======+=============+=========+=============+==========+
| Node | Destination | Origin | Next Hop(s) | TrackID | | Node | Destination | Origin | Next Hop(s) | TrackID |
+======+=============+=========+=============+==========+ +======+=============+=========+=============+==========+
| E | F, G | ND | Neighbor | Any | | E | F, G | ND | Neighbor | Any |
+------+-------------+---------+-------------+----------+ +------+-------------+---------+-------------+----------+
| D | E | ND | Neighbor | Any | | D | E | ND | Neighbor | Any |
+------+-------------+---------+-------------+----------+ +------+-------------+---------+-------------+----------+
| C | D | ND | Neighbor | Any | | C | D | ND | Neighbor | Any |
+------+-------------+---------+-------------+----------+ +------+-------------+---------+-------------+----------+
| " | E | P-DAO 1 | D, E | (C, 131) | | " | E | P-DAO 1 | D, E | (C, 131) |
+------+-------------+---------+-------------+----------+ +------+-------------+---------+-------------+----------+
| B | C | ND | Neighbor | Any | | B | C | ND | Neighbor | Any |
+------+-------------+---------+-------------+----------+ +------+-------------+---------+-------------+----------+
| A | B | ND | Neighbor | Any | | A | B | ND | Neighbor | Any |
+------+-------------+---------+-------------+----------+ +------+-------------+---------+-------------+----------+
| " | C, E | P-DAO 2 | B, C | (A, 129) | | " | C, E | P-DAO 2 | B, C | (A, 129) |
+------+-------------+---------+-------------+----------+ +------+-------------+---------+-------------+----------+
| " | F, G | P-DAO 3 | E | (A, 141) | | " | F, G | P-DAO 3 | E | (A, 141) |
+------+-------------+---------+-------------+----------+ +------+-------------+---------+-------------+----------+
Table 14: RIB setting Table 14: RIB Settings
The encapsulating headers of packets that are forwarded along the The encapsulating headers of packets that are forwarded along the
Track between C and E have the following settings: Track between C and E have the following settings:
+========+===================+===================+================+ +========+=====================+==========================+=========+
| Header | IPv6 Source Addr. | IPv6 Dest. Addr. | TrackID in RPI | | Header | IPv6 Source Address | IPv6 Destination | TrackID |
+========+===================+===================+================+ | | | Address | in RPI |
| Outer | C | D until D then E | (C, 131) | +========+=====================+==========================+=========+
+--------+-------------------+-------------------+----------------+ | Outer | C | D until D then E | (C, |
| Middle | A | E | (A, 141) | | | | | 131) |
+--------+-------------------+-------------------+----------------+ +--------+---------------------+--------------------------+---------+
| Inner | X | E, F or G | N/A | | Middle | A | E | (A, |
+--------+-------------------+-------------------+----------------+ | | | | 141) |
+--------+---------------------+--------------------------+---------+
| Inner | X | E, F, or G | N/A |
+--------+---------------------+--------------------------+---------+
Table 15: Packet Header Settings Table 15: Packet Header Settings
As an example, say that A has a packet for F. Using the RIB in As an example, say that A has a packet for F. Using the RIB in
Table 14: Table 14:
* From P-DAO 3: A encapsulates the packet with destination of F in * From P-DAO 3: A encapsulates the packet with a destination of F in
the Track signaled by P-DAO 3. The outer header has source A, the Track signaled by P-DAO 3. The outer header has source A,
destination E, and a RPI indicating a TrackID of 141 from A's destination E, and an RPI indicating a TrackID of 141 from A's
namespace. This recurses with: namespace. This recurses with the following.
* From P-DAO 2: A encapsulates the packet with destination of E in * From P-DAO 2: A encapsulates the packet with a destination of E in
the Track signaled by P-DAO 2. The outer header has source A, the Track signaled by P-DAO 2. The outer header has source A,
destination B, an SRH that indicates C as the next loose hop, and destination B, an SRH that indicates C as the next loose hop, and
a RPI indicating a TrackID of 129 from A's namespace. an RPI indicating a TrackID of 129 from A's namespace.
* From the SRH: Packets forwarded by B have source A, destination C * From the SRH: Packets forwarded by B have source A, destination C,
, a consumed SRH, and a RPI indicating a TrackID of 129 from A's a consumed SRH, and an RPI indicating a TrackID of 129 from A's
namespace. C decapsulates. namespace. C decapsulates.
* From P-DAO 1: C encapsulates the packet with destination of E in * From P-DAO 1: C encapsulates the packet with a destination of E in
the Track signaled by P-DAO 1. The outer header has source C, the Track signaled by P-DAO 1. The outer header has source C,
destination D, an SRH that indicates E as the next loose hop, and destination D, an SRH that indicates E as the next loose hop, and
a RPI indicating a TrackID of 131 from C's namespace. E an RPI indicating a TrackID of 131 from C's namespace. E
decapsulates. decapsulates.
3.5.2.3. Segment Routing 3.5.2.3. Segment Routing
In this formulation: In this formulation:
* P-DAO 1 signals C==>D==>E-to-(E) * P-DAO 1 signals C==>D==>E-to-(E)
* P-DAO 2 signals A==>B-to-C * P-DAO 2 signals A==>B-to-C
* P-DAO 3 signals F and G via the A-->C-->E-to-(E),F,G Track * P-DAO 3 signals F and G via the A-->C-->E-to-(E),F,G Track
Non-Storing Mode P-DAO 1 is sent to C and Non-Storing Mode P-DAO 2 Non-Storing Mode P-DAO 1 is sent to C, and Non-Storing Mode P-DAOs 2
and 3 are sent to A, as follows: and 3 are sent to A, as follows:
+====================+==============+==============+==============+ +====================+==============+==============+==============+
| | P-DAO 1 to C | P-DAO 2 to A | P-DAO 3 to A | | | P-DAO 1 to C | P-DAO 2 to A | P-DAO 3 to A |
+====================+==============+==============+==============+ +====================+==============+==============+==============+
| Mode | Non-Storing | Non-Storing | Non-Storing | | Mode | Non-Storing | Non-Storing | Non-Storing |
+--------------------+--------------+--------------+--------------+ +====================+--------------+--------------+--------------+
| Track Ingress | C | A | A | | Track Ingress | C | A | A |
+--------------------+--------------+--------------+--------------+ +====================+--------------+--------------+--------------+
| (DODAGID, TrackID) | (C, 131) | (A, 129) | (A, 141) | | (DODAGID, TrackID) | (C, 131) | (A, 129) | (A, 141) |
+--------------------+--------------+--------------+--------------+ +====================+--------------+--------------+--------------+
| SegmentID | 1 | 1 | 1 | | SegmentID | 1 | 1 | 1 |
+--------------------+--------------+--------------+--------------+ +====================+--------------+--------------+--------------+
| VIO | D, E | B | C, E | | VIO | D, E | B | C, E |
+--------------------+--------------+--------------+--------------+ +====================+--------------+--------------+--------------+
| Targets | | C | F, G | | Targets | | C | F, G |
+--------------------+--------------+--------------+--------------+ +====================+--------------+--------------+--------------+
Table 16: P-DAO Messages Table 16: P-DAO Messages
As a result the RIBs are set as follows: As a result, the RIBs are set as follows:
+======+=============+=========+=============+==========+ +======+=============+=========+=============+==========+
| Node | Destination | Origin | Next Hop(s) | TrackID | | Node | Destination | Origin | Next Hop(s) | TrackID |
+======+=============+=========+=============+==========+ +======+=============+=========+=============+==========+
| E | F, G | ND | Neighbor | Any | | E | F, G | ND | Neighbor | Any |
+------+-------------+---------+-------------+----------+ +------+-------------+---------+-------------+----------+
| D | E | ND | Neighbor | Any | | D | E | ND | Neighbor | Any |
+------+-------------+---------+-------------+----------+ +------+-------------+---------+-------------+----------+
| C | D | ND | Neighbor | Any | | C | D | ND | Neighbor | Any |
+------+-------------+---------+-------------+----------+ +------+-------------+---------+-------------+----------+
| " | E | P-DAO 1 | D, E | (C, 131) | | " | E | P-DAO 1 | D, E | (C, 131) |
+------+-------------+---------+-------------+----------+ +------+-------------+---------+-------------+----------+
| B | C | ND | Neighbor | Any | | B | C | ND | Neighbor | Any |
+------+-------------+---------+-------------+----------+ +------+-------------+---------+-------------+----------+
| A | B | ND | Neighbor | Any | | A | B | ND | Neighbor | Any |
+------+-------------+---------+-------------+----------+ +------+-------------+---------+-------------+----------+
| " | B, C | P-DAO 2 | C | (A, 129) | | " | B, C | P-DAO 2 | C | (A, 129) |
+------+-------------+---------+-------------+----------+ +------+-------------+---------+-------------+----------+
| " | E, F, G | P-DAO 3 | C, E | (A, 141) | | " | E, F, G | P-DAO 3 | C, E | (A, 141) |
+------+-------------+---------+-------------+----------+ +------+-------------+---------+-------------+----------+
Table 17: RIB setting Table 17: RIB Settings
The encapsulating headers of packets that are forwarded along the The encapsulating headers of packets that are forwarded along the
Track between A and B have the following settings: Track between A and B have the following settings:
+========+===================+===================+================+ +========+=====================+==========================+=========+
| Header | IPv6 Source Addr. | IPv6 Dest. Addr. | TrackID in RPI | | Header | IPv6 Source Address | IPv6 Destination | TrackID |
+========+===================+===================+================+ | | | Address | in RPI |
| Outer | A | B until D then E | (A, 129) | +========+=====================+==========================+=========+
+--------+-------------------+-------------------+----------------+ | Outer | A | B until D then E | (A, |
| Middle | A | C | (A, 141) | | | | | 129) |
+--------+-------------------+-------------------+----------------+ +--------+---------------------+--------------------------+---------+
| Inner | X | E, F or G | N/A | | Middle | A | C | (A, |
+--------+-------------------+-------------------+----------------+ | | | | 141) |
+--------+---------------------+--------------------------+---------+
| Inner | X | E, F, or G | N/A |
+--------+---------------------+--------------------------+---------+
Table 18: Packet Header Settings Table 18: Packet Header Settings
The encapsulating headers of packets that are forwarded along the The encapsulating headers of packets that are forwarded along the
Track between B and C have the following settings: Track between B and C have the following settings:
+========+===================+===================+================+ +========+=====================+==========================+=========+
| Header | IPv6 Source Addr. | IPv6 Dest. Addr. | TrackID in RPI | | Header | IPv6 Source Address | IPv6 Destination | TrackID |
+========+===================+===================+================+ | | | Address | in RPI |
| Outer | A | C | (A, 141) | +========+=====================+==========================+=========+
+--------+-------------------+-------------------+----------------+ | Outer | A | C | (A, |
| Inner | X | E, F or G | N/A | | | | | 141) |
+--------+-------------------+-------------------+----------------+ +--------+---------------------+--------------------------+---------+
| Inner | X | E, F, or G | N/A |
+--------+---------------------+--------------------------+---------+
Table 19: Packet Header Settings Table 19: Packet Header Settings
The encapsulating headers of packets that are forwarded along the The encapsulating headers of packets that are forwarded along the
Track between C and E have the following settings: Track between C and E have the following settings:
+========+===================+===================+================+ +========+=====================+==========================+=========+
| Header | IPv6 Source Addr. | IPv6 Dest. Addr. | TrackID in RPI | | Header | IPv6 Source Address | IPv6 Destination | TrackID |
+========+===================+===================+================+ | | | Address | in RPI |
| Outer | C | D until D then E | (C, 131) | +========+=====================+==========================+=========+
+--------+-------------------+-------------------+----------------+ | Outer | C | D until D then E | (C, |
| Middle | A | E | (A, 141) | | | | | 131) |
+--------+-------------------+-------------------+----------------+ +--------+---------------------+--------------------------+---------+
| Inner | X | E, F or G | N/A | | Middle | A | E | (A, |
+--------+-------------------+-------------------+----------------+ | | | | 141) |
+--------+---------------------+--------------------------+---------+
| Inner | X | E, F, or G | N/A |
+--------+---------------------+--------------------------+---------+
Table 20: Packet Header Settings Table 20: Packet Header Settings
As an example, say that A has a packet for F. Using the Table 18: As an example, say that A has a packet for F. Using Table 18:
* From P-DAO 3: A encapsulates the packet with destination of F in * From P-DAO 3: A encapsulates the packet with a destination of F in
the Track signaled by P-DAO 3. The outer header has source A, the Track signaled by P-DAO 3. The outer header has source A,
destination C, an SRH that indicates E as the next loose hop, and destination C, an SRH that indicates E as the next loose hop, and
a RPI indicating a TrackID of 141 from A's namespace. This an RPI indicating a TrackID of 141 from A's namespace. This
recurses with: recurses with the following.
* From P-DAO 2: A encapsulates the packet with destination of C in * From P-DAO 2: A encapsulates the packet with a destination of C in
the Track signaled by P-DAO 2. The outer header has source A, the Track signaled by P-DAO 2. The outer header has source A,
destination B, and a RPI indicating a TrackID of 129 from A's destination B, and an RPI indicating a TrackID of 129 from A's
namespace. B decapsulates forwards to C based on a sibling namespace. B decapsulates forwards to C based on a sibling
connected route. connected route.
* From the SRH: C consumes the SRH and makes the destination E. * From the SRH: C consumes the SRH and makes the destination E.
* From P-DAO 1: C encapsulates the packet with destination of E in * From P-DAO 1: C encapsulates the packet with a destination of E in
the Track signaled by P-DAO 1. The outer header has source C, the Track signaled by P-DAO 1. The outer header has source C,
destination D, an SRH that indicates E as the next loose hop, and destination D, an SRH that indicates E as the next loose hop, and
a RPI indicating a TrackID of 131 from C's namespace. E an RPI indicating a TrackID of 131 from C's namespace. E
decapsulates. decapsulates.
3.6. Complex Tracks 3.6. Complex Tracks
To increase the reliability of the P2P transmission, this To increase the reliability of the P2P transmission, this
specification enables building a collection of protection paths specification enables building a collection of protection paths
between the same Ingress and Egress Nodes and combining them within between the same Ingress and Egress Nodes and combining them within
the same TrackID, as shown in Figure 7. Protection paths may be the same TrackID, as shown in Figure 7. Protection paths may be
interleaved at the edges of loose hops or remain parallel. interleaved at the edges of loose hops or remain parallel.
The segments that join the loose hops of a protection path are The segments that join the loose hops of a protection path are
installed with the same TrackID as the protection path. But each installed with the same TrackID as the protection path. But each
individual protection path and segment has its own P-RouteID which individual protection path and segment has its own P-RouteID that
allows it to be managed separately. Two protection paths of the same allows it to be managed separately. Two protection paths of the same
Track may cross at a common node that participates to a segment of Track may cross at a common node that participates to a segment of
Each protection path, or may be joined by additional segments. The each protection path or that may be joined by additional segments.
final path of a packet may then be the result of interleaving those The final path of a packet may then be the result of interleaving
two (and possibly more) protection paths. In that case the common those two (and possibly more) protection paths. In that case, the
node has more than one next hop in its RIB associated to the Track, common node has more than one next hop in its RIB associated to the
but no specific signal in the packet to indicate which segment is Track but no specific signal in the packet to indicate which segment
being followed. A next hop that can reach the loose hop is selected. is being followed. A next hop that can reach the loose hop is
selected.
< Controller Plane Functions > < Controller Plane Functions >
Southbound API Southbound API
_-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._- _-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-
_-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._- _-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-
+----------+ +----------+
| RPL Root | | RPL Root |
+----------+ +----------+
skipping to change at page 38, line 15 skipping to change at line 1747
Note that while this specification enables building both segments Note that while this specification enables building both segments
inside a protection path, for instance segment 2 above which is inside a protection path, for instance segment 2 above which is
within protection path 1, and Inter-protection-path segments (i.e., within protection path 1, and Inter-protection-path segments (i.e.,
North-South), for instance segment 5 above which joins protection North-South), for instance segment 5 above which joins protection
path 1 and protection path 2, it does not signal to the Ingress which path 1 and protection path 2, it does not signal to the Ingress which
Inter-protection-path segments are available, so the use of North- Inter-protection-path segments are available, so the use of North-
South segments and associated path redundancy functions is currently South segments and associated path redundancy functions is currently
limited. The only possibility available at this time is to define limited. The only possibility available at this time is to define
overlapping protection paths as illustrated in Figure 7, with overlapping protection paths as illustrated in Figure 7, with
protection path 3 that is congruent with protection path 1 until node protection path 3 that is congruent with protection path 1 until node
B and congruent with protection path 2 from node H on, abstracting B and that is congruent with protection path 2 from node H on,
segment 5 as a forward segment. abstracting segment 5 as a forward 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 main DODAG is operated in RPL This specification expects that the 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 document adds the capability for nodes to advertise additional
sibling information to complement the topological awareness of the sibling information to complement the topological awareness of the
Root to be passed on to the PCE, and enable the PCE to build more / Root to be passed on to the PCE and enables the PCE to build more/
better paths that traverse those siblings. better paths 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 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 Operations,
Administration, and Maintenance (OAM).
3.7.2. Positioning vs. Related IETF Standards 3.7.2. Positioning Versus 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
that is similar to that of "Deterministic Networking Architecture" is similar to that of the DetNet architecture [RFC8655], whereby the
[RFC8655], whereby the device resources and capabilities are exposed device resources and capabilities are exposed to an external
to an external controller which installs routing states into the controller that installs routing states into the network based on its
network based on its own objective functions that reside in that own objective functions 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 protection path and the signal the Relay Nodes as the hops of a protection path and the
forwarding Nodes as the hops in a segment that join the Relay nodes forwarding nodes as the hops in a segment that join the Relay nodes
as illustrated in Figure 7. as illustrated in Figure 7.
3.7.2.3. Leveraging PCE 3.7.2.3. Leveraging PCE
With DetNet and 6TiSCH, the component of the controller that is With DetNet and 6TiSCH, the component of the controller that is
responsible of computing routes is a PCE. The PCE computes its responsible for computing routes is a PCE. The PCE computes its
routes based on its own objective functions such as described in routes based on its own objective functions, as described in
[RFC4655], and typically controls the routes using the PCE Protocol [RFC4655], and typically controls the routes using the PCE
(PCEP) by [RFC5440]. While this specification expects a PCE and Communication Protocol (PCEP) [RFC5440]. While this specification
while PCEP might effectively be used between the Root and the PCE, expects a PCE, and while PCEP might effectively be used between the
the control protocol between the PCE and the Root is out of scope. Root and the PCE, the control protocol between the PCE and the Root
is out of scope.
This specification also expects a single PCE with a full view of the This specification also expects a single PCE with a full view of the
network. Distributing the PCE function for a large network is out of network. Distributing the PCE function for a large network is out of
scope. This specification uses the RPL Root as a proxy to the PCE. scope. This specification uses the RPL Root as a proxy to the PCE.
The PCE may be collocated with the Root, or may reside in an external The PCE may be collocated with the Root or reside in an external
Controller. In that case, the protocol between the Root and the PCE controller. In that case, the protocol between the Root and the PCE
is out of scope and mapped to RPL inside the DODAG; one possibility is out of scope and mapped to RPL inside the DODAG; one possibility
is for the Root to transmit to the PCEs the information it received is for the Root to transmit to the PCEs the information it received
in RPL DAOs including all the SIOs that detail the parent/child and in RPL DAOs including all the SIOs that detail the parent/child and
sibling information. sibling information.
The algorithm to compute the paths, the protocol used by the PCE and The algorithm to compute the paths, the protocol used by the PCE, and
the metrics and link statistics involved in the computation are also the metrics and link statistics involved in the computation are also
out of scope. The effectiveness of the route computation by the PCE out of scope. The effectiveness of the route computation by the PCE
depends on the quality of the metrics that are reported from the RPL 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 of network. Which metrics are used and how they are reported are out of
scope, but the expectation is that they are mostly of a long-term, scope, but the expectation is that they are mostly of a 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 RAW Architecture [RAW-ARCHI] extends the definition of Track, as The RAW architecture [RAW-ARCH] extends the definition of Track, as
being composed of forward directional segments and North-South being composed of forward directional segments and North-South
bidirectional segments, to enable additional path diversity, using bidirectional segments, to enable additional path diversity, using
Packet ARQ, Replication, Elimination, and Overhearing (PAREO) PAREO functions over the available paths, to provide a dynamic
functions over the available paths, to provide a dynamic balance balance between the reliability and availability requirements of the
between the reliability and availability requirements of the flows flows and the need to conserve energy and spectrum. This
and the need to conserve energy and spectrum. This specification specification prepares for RAW by setting up the Tracks, but it only
prepares for RAW by setting up the Tracks, but only forms DODAGs, forms DODAGs, which are composed of aggregated end-to-end loose
which are composed of aggregated end-to-end loose source routed source-routed protection paths, joined by strict routed segments, all
protection paths, joined by strict routed segments, all oriented oriented forward.
forward.
The RAW Architecture defines a dataplane extension of the PCE called The RAW architecture defines a data plane extension of the PCE called
the Point of Local Repair (PLR), that adapts the use of the path the Point of Local Repair (PLR) 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 PLR controls the forwarding operation of the packets loss. The PLR controls the forwarding operation of the packets
within a Track. This specification can use but does not impose a PLR within a Track. This specification can use but does not impose a PLR
and does not provide the policies that would select which packets are and does not provide the policies that would select which packets are
routed through which path within a Track, in other words, how the PLR routed through which path within a Track (in other words, how the PLR
may use the path redundancy within the Track. By default, the use of may use the path redundancy within the Track). By default, the use
the available redundancy is limited to simple load balancing, and all of the available redundancy is limited to simple load balancing, and
the segments are forward unidirectional only. all the segments are forward unidirectional only.
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
enable urgent traffic to flow more directly. This specification does urgent traffic to flow more directly. This specification does not
not provide the policies that would decide which flows are routed provide the policies that would decide which flows are routed through
through which Track. In a Non-Storing Mode RPL Instance, the main which Track. In a Non-Storing Mode RPL Instance, the main DODAG
DODAG provides a default route via the Root, and the Tracks provide provides a default route via the Root, and the Tracks provide more-
more specific routes to the Track Targets. specific routes to the Track Targets.
4. Extending existing RFCs 4. Extending Existing RFCs
This section explains which changes are extensions to existing This section explains which changes are extensions and which are
specifications, and which changes are amendments to existing amendments to existing specifications. It is expected that
specifications. It is expected that extensions to existing extensions to existing specifications will not cause existing code on
specifications do not cause existing code on legacy 6LRs to legacy 6LRs to malfunction, as the extensions will simply be ignored.
malfunction, as the extensions will simply be ignored. New code is New code is required for an extension. Those 6LRs will be unable to
required for an extension. Those 6LRs will be unable to participate participate in the new mechanisms and may also cause P-DAOs to be
in the new mechanisms, but may also cause projected DAOs to be
impossible to install. Amendments to existing specifications are impossible to install. Amendments to existing specifications are
situations where there are semantic changes required to existing situations where there are semantic changes required to existing code
code, and which may require new unit tests to confirm that legacy and where new unit tests may be required to confirm that legacy
operations will continue unaffected. operations will continue unaffected.
4.1. Extending RPL RFC 6550 4.1. Extending RPL RFC 6550
This specification Extends RPL [RPL] to enable the Root to install This specification Extends RPL [RPL] to enable the Root to install
forward routes inside a main DODAG that is operated as Non-Storing forward 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 P-DAO message (see Section 4.1.1) to the
Section 4.1.1) to the Track Ingress; the P-DAO message contains a new Track Ingress; the P-DAO message contains a new VIO that installs a
Via Information Option (VIO) that installs a strict or a loose strict or a loose sequence of hops to form a Track segment or a
sequence of hops to form a Track segment or a protection path, protection path, respectively.
respectively.
The P-DAO Request (PDR) is a new message detailed in Section 5.1. As The P-DAO Request (PDR) is a new message detailed in Section 5.1. As
per [RPL] section 6, if a node receives this message and it does not per Section 6 of [RPL], if a node receives this message and it does
understand this new Code, it then discards the message. When the not understand this new code, it discards the message. When the Root
Root initiates communication to a node that it has not communicated initiates communication to a node that it has not communicated with
with before and which it has not ascertained to implement this before and that it has not ascertained to implement this
specification (by means such as capabilities), then the Root SHOULD specification (by means such as capabilities), then the Root SHOULD
request a PDR-ACK. request a PDR-ACK.
A P-DAO Request (PDR) message enables a Track Ingress to request the A PDR message enables a Track Ingress to request the Track from the
Track from the Root. The resulting Track is also a DODAG for which Root. The resulting Track is also a DODAG for which the Track
the Track Ingress is the Root, the owner the address that serves as Ingress is the Root, and the owner is the address that serves as the
DODAGID and authoritative for the associated namespace from which the DODAGID and is authoritative for the associated namespace from which
TrackID is selected. In the context of this specification, the the TrackID is selected. In the context of this specification, the
installed route appears as a more specific route to the Track installed route appears as a more-specific route to the Track
Targets, and the Track Ingress forwards the packets towards the Targets, and the Track Ingress forwards the packets toward the
Targets via the Track using normal longest match IP forwarding. Targets via the Track using normal longest match IP forwarding.
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 (CMOs),
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 DAO. A DAO
Advertisement Object (DAO). A DAO message signals routing message signals routing information to one or more Targets indicated
information to one or more Targets indicated in RTOs, and provides in the RTOs and provides one and only one via-node in the TIO, with
one and only one via-node in the TIO, the via-node being the tunnel the via-node being the tunnel endpoint to reach the targets.
end-point to reach the targets.
This document Amends the specification of the DAO to create the P-DAO This document 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 P-DAO is a special DAO message generated by the Root to install a
Root to install a P-Route formed of multiple hops in its DODAG. This P-Route formed of multiple hops in its DODAG. This provides a RPL-
provides a RPL-based method to install the Tracks as expected by the based method to install the Tracks as a collection of multiple
6TiSCH Architecture [RFC9030] as a collection of multiple P-Routes. P-Routes as expected by the 6TiSCH architecture [RFC9030].
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 the DODAGID for the main DODAG. The receiver MUST NOT accept a
message that is not sent by the Root of its DODAG and MUST ignore P-DAO message that is not sent by the Root of its DODAG and MUST
such messages silently. ignore such messages silently.
The 'P' flag is encoded in bit position 2 (to be confirmed by IANA) The 'P' flag is encoded in bit position 2 of the Flags field in the
of the Flags field in the DAO Base Object. The Root MUST set it to 1 DAO Base Object. The Root MUST set it to 1 in a P-DAO message.
in a Projected DAO message. Otherwise it MUST be set to 0. It is Otherwise, it MUST be set to 0. It is set to 0 in legacy
set to 0 in Legacy implementations as specified respectively in implementations as specified, respectively, in Sections 20.11 and 6.4
Sections 20.11 and 6.4 of [RPL]. of [RPL].
The P-DAO is a part of control plane signaling and should not be The P-DAO is a part of control plane signaling and should not be
stuck behind high traffic levels. The expectation is that the P-DAO stuck behind high traffic levels. The expectation is that the P-DAO
message is sent at high QoS level, above that of data traffic, message be sent at a high QoS level, above that of data traffic,
typically with the Network Control precedence. typically with 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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
+ + + +
| DODAGID field set to the | | DODAGID field is set to the |
+ IPv6 Address of the Track Ingress + + IPv6 address of the Track Ingress +
| used to source encapsulated packets | | used to source encapsulated packets |
+ + + +
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Option(s)... | Option(s)...
+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+
Figure 8: Projected DAO Base Object Figure 8: Projected DAO Base Object
New fields: New fields:
TrackID: The local or global RPLInstanceID of the DODAG that serves TrackID: The Local or Global RPLInstanceID of the DODAG that serves
as Track (more in Section 6.3). as the Track (see more in Section 6.3).
P: 1-bit flag (position to be confirmed by IANA). P: 1-bit flag.
The 'P' flag is set to 1 by the Root to signal a Projected DAO, The 'P' flag is set to 1 by the Root to signal a P-DAO; otherwise,
and it is set to 0 otherwise. it is set to 0.
The D flag is set to one to signal that the DODAGID field is present. The D flag is set to 1 to signal that the DODAGID field is present.
It may be set to zero if and only if the destination address of the It may be set to 0 if and only if the destination address of the P-
P-DAO-ACK message is set to the IPv6 address that serves as DODAGID DAO-ACK message is set to the IPv6 address that serves as the
and it MUST be set to one otherwise, meaning that the DODAGID field DODAGID, and it MUST be set to one otherwise, meaning that the
MUST then be present. DODAGID field MUST then be present.
In RPL Non-Storing Mode, the TIO and RTO are combined in a DAO In RPL Non-Storing Mode, the TIO and RTO are combined in a DAO
message to inform the DODAG Root of all the edges in the DODAG, which message to inform the DODAG Root of all the edges in the DODAG, which
are formed by the directed parent-child relationships. The DAO are formed by the directed parent-child relationships. The DAO
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 the Root can be used
reach children and siblings of the Track Egress. In both cases, to 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 document also Amends the DAO-ACK message. The new P flag
signals the projected form. signals 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 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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
+ + + +
| DODAGID field set to the | | DODAGID field is set to the |
+ IPv6 Address of the Track Ingress + + IPv6 address of the Track Ingress +
| used to source encapsulated packets | | used to source encapsulated packets |
+ + + +
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Option(s)... | Option(s)...
+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+
Figure 9: Projected DAO-ACK Base Object Figure 9: Projected DAO-ACK Base Object
New fields: New fields:
TrackID: The local or global RPLInstanceID of the DODAG that serves TrackID: The Local or Global RPLInstanceID of the DODAG that serves
as Track (more in Section 6.3). as the Track (see more in Section 6.3).
P: 1-bit flag (position to be confirmed by IANA). P: 1-bit flag.
The 'P' flag is set to 1 by the Root to signal a Projected DAO, The 'P' flag is set to 1 by the Root to signal a P-DAO; otherwise,
and it is set to 0 otherwise. it is set to 0.
The D flag is set to one to signal that the DODAGID field is present. The D flag is set to 1 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 0 if and only if the source address of the P-DAO-ACK
ACK message is set to the IPv6 address that serves as DODAGID and it message is set to the IPv6 address that serves as the 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 document Extends the CMO to create new objects called Via
Information Options (VIO). The VIOs are the multihop alternative to Information Options (VIOs). The VIOs are the multi-hop alternative
the TIO (more in Section 5.3). One VIO is the stateful Storing Mode to the TIOs (see more in Section 5.3). One VIO is the stateful
VIO (SM-VIO); an SM-VIO installs a strict hop-by-hop P-Route called a Storing Mode VIO (SM-VIO); an SM-VIO installs a strict hop-by-hop
Track segment. The other is the Non-Storing Mode VIO (NSM-VIO); the P-Route called a Track segment. The other is the Non-Storing Mode
NSM-VIO installs a loose source-routed P-Route called a protection VIO (NSM-VIO); the NSM-VIO installs a loose source-routed P-Route
path at the Track Ingress, which uses that state to encapsulate a called a protection path at the Track Ingress, which uses that state
packet IP-in-IP with a new Routing Header (RH) to the Track Egress to encapsulate an IP-in-IP packet with a new Routing Header (RH) to
(more in Section 6.7). the Track Egress (see more 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 (see 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: Storing Mode and Non-Storing Mode (see more in Sections
Section 6.4.2 and Section 6.4.3 respectively for more. 6.4.2 and 6.4.3, respectively).
4.1.4. Sibling Information Option 4.1.4. Sibling Information Option
This specification Extends the CMO to create the Sibling Information This specification Extends the CMO to create the Sibling Information
Option (SIO). The SIO is used by a RPL Aware Node (RAN) to advertise Option (SIO). The SIO is used by a RPL-Aware Node (RAN) to advertise
a selection of its candidate neighbors as siblings to the Root (more a selection of its candidate neighbors as siblings to the Root (see
in Section 5.4). The SIO is placed in DAO messages that are sent more in Section 5.4). The SIO is placed in DAO messages that are
directly to the main Root, including multicast DAO (see section 9.10 sent directly to the main Root, including multicast DAO (see
of [RPL]). Section 9.10 of [RPL]).
This specification AMENDS rules 1 and 2 listed in section 9.10 of This specification Amends rules 1 and 2 listed in Section 9.10 of
[RPL]) for the multicast DAO operation as follows: [RPL] for the multicast DAO operation as follows:
OLD: OLD:
1. A node MAY multicast a DAO message to the link-local scope all- | 1. A node MAY multicast a DAO message to the link-local scope
RPL-nodes multicast address. | all-RPL-nodes multicast address.
|
2. A multicast DAO message MUST be used only to advertise | 2. A multicast DAO message MUST be used only to advertise
information about the node itself, i.e., prefixes directly | information about the node itself, i.e., prefixes directly
connected to or owned by the node, such as a multicast group that | connected to or owned by the node, such as a multicast group
the node is subscribed to or a global address owned by the node | that the node is subscribed to or a global address owned by
| the node
NEW: NEW:
1. A multicast DAO message MUST be used only to advertise | 1. A multicast DAO message MUST be used only to advertise
information about the node (using the Target Option), and direct | information about the node (using the Target Option) and
Link Neighbors such as learned by Neighbor Discovery (using the | direct Link Neighbors such as learned by Neighbor Discovery
Sibling Information Option). | (using the SIO).
|
2. The multicast DAO may be used to enable direct and indirect (via | 2. The multicast DAO may be used to enable direct and indirect
a common neighbor) P2P communication without needing the DODAG to | (via a common neighbor) P2P communication without needing the
relay the packets. The multicast DAO exposes the sender's | DODAG to relay the packets. The multicast DAO exposes the
addresses as Targets in RTOs and the sender's neighbors addresses | sender's addresses as Targets in RTOs and the sender's
as siblings in SIOs; this tells the sender's neighbors that the | neighbors addresses as siblings in SIOs; this tells the
sender is willing to act as a relay between those of its | sender's neighbors that the sender is willing to act as a
neighbors that are too far apart. | relay between those of its neighbors that are too far apart.
4.1.5. P-DAO Request 4.1.5. P-DAO Request
The set of RPL Control Messages is Extended to include the P-DAO The set of RPL Control Messages is Extended to include the PDR and
Request (PDR) and P-DAO Request Acknowledgement (PDR-ACK). These two P-DAO Request Acknowledgement (PDR-ACK). These two new RPL Control
new RPL Control Messages enable an RPL-Aware Node to request the Messages enable a RAN to request the establishment of a Track between
establishment of a Track between itself as the Track Ingress Node and itself (as the Track Ingress Node) and a Track Egress. The node
a Track Egress. The node makes its request by sending a new P-DAO makes its request by sending a new PDR message to the Root. The Root
Request (PDR) Message to the Root. The Root confirms with a new PDR- confirms with a new PDR-ACK message back to the requester RAN; see
ACK message back to the requester RAN, see Section 5.1 for more. Section 5.1 for more.
4.1.6. Amending 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 RPI described in Section 11.2 of [RPL] in the outer IPv6
of [RPL] in the outer IPv6 Header chain (see [RFC9008]). The RPI header chain (see [RFC9008]). The RPI carries a Local RPLInstanceID
carries a local RPLInstanceID which, in association with either the that, in association with either the source or the destination
source or the destination address in the IPv6 Header, indicates the address in the IPv6 header, indicates the RPL Instance that the
RPL Instance that the packet follows. packet follows.
This specification Amends [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. when 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 DODAG (as a is set to 0 when a packet is forwarded along the main DODAG (as a
Track), including when the packet follows a segment that joins Track), including when the packet follows a segment that joins
loose hops of the main DODAG. The flag is not mutable en-route. loose hops 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.
4.1.7. Additional Flag in the RPL DODAG Configuration Option 4.1.7. Additional Flag in the RPL DODAG Configuration Option
The DODAG Configuration Option is defined in Section 6.7.6 of [RPL]. The DODAG Configuration option is defined in Section 6.7.6 of [RPL].
Its purpose is extended to distribute configuration information Its purpose is extended to distribute configuration information
affecting the construction and maintenance of the DODAG, as well as affecting the construction and maintenance of the DODAG, as well as
operational parameters for RPL on the DODAG, through the DODAG. This operational parameters for RPL on the DODAG, through the DODAG. This
Option was originally designed with 4 bit positions reserved for option was originally designed with four bit positions reserved for
future use as Flags. future use as Flags.
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 Amends the specification to define a new flag This specification Amends [RPL] to define the new "Projected Routes
"Projected Routes Support" (D). The 'D' flag is encoded in bit Support" (D) flag. The 'D' flag is encoded in bit position 0 of the
position 0 of the reserved Flags in the DODAG Configuration Option reserved Flags in the DODAG Configuration option (this is the most
(this is the most significant bit)(to be confirmed by IANA but significant bit). It is set to 0 in legacy implementations as
there's little choice). It is set to 0 in legacy implementations as
specified respectively in Sections 20.14 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 receiving a PDR message.
Section 4.1.2. of [RFC9008] Amends [RPL] to indicate that the Section 4.1.2 of [RFC9008] Amends [RPL] to indicate that the
definition of the Flags applies to Mode of Operation values from zero definition of the Flags applies to MOP values from zero (0) to six
(0) to six (6) only. For a MOP value of 7, the implementation MUST (6) only. For a MOP value of 7, the implementation MUST consider
consider that the Root accepts PDR messages and will install that the Root accepts PDR messages and will install P-Routes.
Projected Routes.
The RPL DODAG Configuration option is typically placed in a DODAG The RPL DODAG Configuration option is typically placed in a DIO
Information Object (DIO) message. The DIO message propagates down message. The DIO message propagates down the DODAG to form and then
the DODAG to form and then maintain its structure. The DODAG maintain its structure. The DODAG Configuration option is copied
Configuration option is copied unmodified from parents to children. unmodified from parents to children.
[RPL] states that: [RPL] states that:
| Nodes other than the DODAG root MUST NOT modify this information | Nodes other than the DODAG root MUST NOT modify this information
| when propagating the DODAG Configuration option. | when propagating the DODAG Configuration option.
Therefore, a legacy parent propagates the 'D' flag as set by the Therefore, a legacy parent propagates the 'D' flag as set by the
root, and when the 'D' flag is set to 1, it is transparently flooded root, and when the 'D' flag is set to 1, it is transparently flooded
to all the nodes in the DODAG. to all the nodes in the DODAG.
4.2. Extending RPL RFC 6553 4.2. Extending RPL RFC 6553
"The RPL Option for Carrying RPL Information in Data-Plane Datagrams" "The Routing Protocol for Low-Power and Lossy Networks (RPL) Option
[RFC6553] describes the RPL Option for use among RPL routers to for Carrying RPL Information in Data-Plane Datagrams" [RFC6553]
include the abstract RPL Packet Information (RPI) described in describes the RPL Option for use among RPL routers to include the
section 11.2. of [RPL] in data packets. abstract RPI described in 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 even though the RPI
really the abstract information that is transported in the RPL is 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 Extends the RPL Option to encode the 'P' flag as This specification Extends 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: Amended 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]. These flags MUST be set to
by the sender and ignored by the receiver if the 'P' flag is set. 0 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.
RPLInstanceID: See [RFC6553]. Indicates the TrackID if the 'P' flag RPLInstanceID: See [RFC6553]. Indicates the TrackID if the 'P' flag
is set, as discussed in Section 4.1.1. is set, as discussed in Section 4.1.1.
SenderRank: See [RFC6553]. This field MUST be set to 0 by the SenderRank: See [RFC6553]. This field MUST be set to 0 by the
sender and ignored by the receiver if the 'P' flag is set. sender and ignored by the receiver if the 'P' flag is set.
4.3. Extending RPL RFC 8138 4.3. Extending RPL RFC 8138
The 6LoWPAN Routing Header [RFC8138] specification introduces a new The 6LoWPAN Routing Header specification [RFC8138] introduces a new
IPv6 over Low-Power Wireless Personal Area Network (6LoWPAN) 6LoWPAN [RFC6282] dispatch type for use in 6LoWPAN route-over
[RFC6282] dispatch type for use in 6LoWPAN route-over topologies, topologies, which initially covers the needs of RPL data packet
which initially covers the needs of RPL data packet compression. compression.
Section 4 of [RFC8138] presents the generic formats of the 6LoWPAN Section 4 of [RFC8138] presents the generic formats of the 6LoRH in
Routing Header (6LoRH) with two forms, one Elective that can be two forms: Elective, which can be ignored and skipped when the router
ignored and skipped when the router does not understand it, and one does not understand it, and Critical, which causes the packet to be
Critical which causes the packet to be dropped when the router cannot dropped when the router cannot process it. The 'E' flag in the 6LoRH
process it. The 'E' Flag in the 6LoRH indicates its form. In order indicates its form. In order to skip the Elective 6LoRHs, their
to skip the Elective 6LoRHs, their format imposes a fixed expression format imposes a fixed expression of the size, whereas the size of a
of the size, whereas the size of a Critical 6LoRH may be signaled in Critical 6LoRH may be signaled in variable forms to enable additional
variable forms to enable additional optimizations. optimizations.
When the [RFC8138] compression is used, the Root of the main DODAG When compression as described in [RFC8138] is used, the Root of the
that sets up the Track also constructs the compressed routing header main DODAG that sets up the Track also constructs the compressed
(SRH-6LoRH) on behalf of the Track Ingress, which saves the routing header (SRH-6LoRH) on behalf of the Track Ingress, which
complexities of optimizing the SRH-6LoRH encoding in constrained avoids the complexities of optimizing SRH-6LoRH encoding in
code. The SRH-6LoRH is signaled in the NSM-VIO, in a fashion that it constrained code. The SRH-6LoRH is signaled in the NSM-VIO, in a
is ready to be placed as is in the packet encapsulation by the Track fashion that it is ready to be placed as is in the packet
Ingress. encapsulation by the Track Ingress.
Section 6.3 of [RFC8138] presents the formats of the 6LoWPAN Routing Section 6.3 of [RFC8138] presents the formats of the 6LoWPAN RH of
Header of type 5 (RPI-6LoRH) that compresses the RPI for normal RPL type 5 (RPI-6LoRH) that compresses the RPI for normal RPL operation.
operation. The format of the RPI-6LoRH is not suited for P-Routes The format of the RPI-6LoRH is not suited for P-Routes since the O,
since the O,R,F flags are not used and the Rank is unknown and R, and F flags are not used and the Rank is unknown and ignored.
ignored.
This specification extends [RFC8138] to introduce a new 6LoRH, the P- This specification Extends [RFC8138] to introduce a new 6LoRH, the P-
RPI-6LoRH that can be used in either Elective or Critical 6LoRH form, RPI-6LoRH, that can be used in either Elective or Critical 6LoRH
see Table 22 and Table 23 respectively. The new 6LoRH MUST be used form; see Tables 22 and 23, respectively. The new 6LoRH MUST be used
as a Critical 6LoRH, unless an SRH-6LoRH is present and controls the as a Critical 6LoRH, unless an SRH-6LoRH is present and controls the
routing 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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 12: P-RPI-6LoRH Format Figure 12: P-RPI-6LoRH Format
Type: IANA is requested to define the same value of the type for 6LoRH Type: IANA has defined the value 8 for both the Elective and
both Elective and Critical forms. A type of 8 is suggested. Critical forms.
Elective 'E': See [RFC8138]. The 'E' flag is set to 1 to indicate Elective 'E': See [RFC8138]. The 'E' flag is set to 1 to indicate
an Elective 6LoRH, meaning that it can be ignored when forwarding. an Elective 6LoRH, meaning that it can be ignored when forwarding.
RPLInstanceID : In the context of this specification, the RPLInstanceID : In the context of this specification, the
RPLInstanceID field signals the TrackID, see Section 3.4 and RPLInstanceID field signals the TrackID; see Sections 3.4 and 6.3.
Section 6.3 .
Section 6.8 details how a Track Ingress leverages the P-RPI-6LoRH Section 6.8 details how a Track Ingress leverages the P-RPI-6LoRH
Header as part of the encapsulation of a packet to place it into a Header as part of the encapsulation of a packet to place it into a
Track. Track.
5. New RPL Control Messages and Options 5. New RPL Control Messages and Options
5.1. New P-DAO Request Control Message 5.1. New P-DAO Request Control Message
The P-DAO Request (PDR) message is sent by a Node in the main DODAG The PDR message is sent by a node in the main DODAG to the Root. It
to the Root. It is a request to establish or refresh a Track where is a request to establish or refresh a Track where the node sending
the node sending the PDR is Track Ingress, and signals whether an the PDR is the Track Ingress, and it signals whether or not an
acknowledgment called PDR-ACK is requested or not. A positive PDR- acknowledgment called PDR-ACK is requested. A positive PDR-ACK
ACK indicates that the Track was built and that the Root commits to indicates that the Track was built and that the Root commits to
maintaining the Track for the negotiated lifetime. maintaining the Track for the negotiated lifetime.
The main Root MAY indicate to the Track Ingress that the Track was The main Root MAY indicate to the Track Ingress that the Track was
terminated before its time and to do so, it MUST use an asynchronous terminated before its time; to do so, it MUST use an asynchronous
PDR-ACK with a negative status. A status of "Transient Failure" (see PDR-ACK with a negative status. A status of "Transient Failure" (see
Section 11.10) is an indication that the PDR may be retried after a Section 11.10) is an indication that the PDR may be retried after a
reasonable time that depends on the deployment. Other negative reasonable time that depends on the deployment. Other negative
status values indicate a permanent error; the attempt must be status values indicate a permanent error; the attempt must be
abandoned until a corrective action is taken at the application layer abandoned until a corrective action is taken at the application layer
or through network management. or through network management.
The Track Ingress to-be of the requested Track is indicated in the The Track Ingress to be of the requested Track is indicated in the
source IPv6 address of the PDR, and the TrackID is indicated in the source IPv6 address of the PDR, and the TrackID is indicated in the
message itself. At least one RPL Target Option MUST be present in message itself. At least one RPL Target Option MUST be present in
the message. If more than one RPL Target Option is present, the Root the message. If more than one RPL Target Option is present, the Root
will provide a Track that reaches the first listed Target and a will provide a Track that reaches the first listed Target and a
subset of the other Targets; the details of the subset selection are subset of the other Targets; the details of the subset selection are
out of scope. The RTO signals the Track Egress (more in out of scope. The RTO signals the Track Egress (see more in
Section 6.2). 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. The format of the PDR Base
The format of PDR Base Object is as follows: Object is as follows:
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| TrackID |K|R| Flags | ReqLifetime | PDRSequence | | TrackID |K|R| Flags | ReqLifetime | PDRSequence |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Option(s)... | Option(s)...
+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+
Figure 13: New P-DAO Request Format Figure 13: New P-DAO Request Format
TrackID: 8-bit field. In the context of this specification, the TrackID: 8-bit field. In the context of this specification, the
TrackID field signals the RPLInstanceID of the DODAG formed by the TrackID field signals the RPLInstanceID of the DODAG formed by the
Track, see Section 3.4 and Section 6.3. To allocate a new Track, Track; see Sections 3.4 and 6.3. To allocate a new Track, the
the Ingress Node must provide a value that is not in use at this Ingress Node must provide a value that is not in use at this time.
time.
K: The 'K' flag is set to indicate that the recipient is expected to K: The 'K' flag is set to indicate that the recipient is expected to
send a PDR-ACK back. send a PDR-ACK back.
R: The 'R' flag is set to request a Complex Track for redundancy. R: The 'R' flag is set to request a Complex Track for redundancy.
Flags: Reserved. The Flags field MUST be initialized to zero by the Flags: Reserved. The Flags field MUST be initialized to zero by the
sender and MUST be ignored by the receiver. sender and MUST be ignored by the receiver.
ReqLifetime: 8-bit unsigned integer. The requested lifetime for the ReqLifetime: 8-bit unsigned integer. The requested lifetime for the
Track expressed in Lifetime Units (obtained from the DODAG Track expressed in Lifetime Units (obtained from the DODAG
Configuration option). The value of 255 (0xFF) represents Configuration option). The value of 255 (0xFF) represents
infinity (never time out). infinity (never time out).
A PDR with a fresher PDRSequence refreshes the lifetime, and a A PDR with a fresher PDRSequence refreshes the lifetime, and a
PDRLifetime of 0 indicates that the Track MUST be destroyed, e.g., PDRLifetime of 0 indicates that the Track MUST be destroyed, e.g.,
when the application that requested the Track terminates. when the application that requested the Track terminates.
PDRSequence: 8-bit wrapping sequence number, obeying the operation PDRSequence: 8-bit wrapping sequence number, obeying the operation
in section 7.2 of [RPL]. The PDRSequence is used to correlate a in Section 7.2 of [RPL]. The PDRSequence is used to correlate a
PDR-ACK message with the PDR message that triggered it. It is PDR-ACK message with the PDR message that triggered it. It is
incremented at each PDR message and echoed in the PDR-ACK by the incremented at each PDR message and echoed in the PDR-ACK by the
Root. Root.
5.2. New PDR-ACK Control Message 5.2. New PDR-ACK Control Message
The new PDR-ACK is sent as a response to a PDR message with the 'K' The new PDR-ACK is sent as a response to a PDR message with the 'K'
flag set. The RPL Control Code for the PDR-ACK is 0x0A, to be flag set. The RPL Control Code for the PDR-ACK is 0x0A. Its format
confirmed by IANA. Its format is as follows: is as follows:
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| TrackID | Flags | Track Lifetime| PDRSequence | | TrackID | Flags | Track Lifetime| PDRSequence |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| PDR-ACK Status| Reserved | | PDR-ACK Status| Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Option(s)... | Option(s)...
+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+
Figure 14: New PDR-ACK Control Message Format Figure 14: New PDR-ACK Control Message Format
TrackID: Set to the TrackID indicated in the TrackID field of the TrackID: Set to the TrackID indicated in the TrackID field of the
PDR messages that this replies to. PDR messages that this replies to.
Flags: Reserved. The Flags field MUST be initialized to zero by the Flags: Reserved. The Flags field MUST be initialized to zero by the
sender and MUST be ignored by the receiver. sender and MUST be ignored by the receiver.
Track Lifetime: Indicates the remaining Lifetime for the Track, Track Lifetime: Indicates the remaining lifetime for the Track,
expressed in Lifetime Units; The value of 255 (0xFF) represents expressed in Lifetime Units. The value of 255 (0xFF) represents
infinity. The value of zero (0x00) indicates that the Track was infinity. The value of zero (0x00) indicates that the Track was
destroyed or not created. destroyed or not created.
PDRSequence: 8-bit wrapping sequence number. It is incremented at PDRSequence: 8-bit wrapping sequence number. It is incremented at
each PDR message and echoed in the PDR-ACK. each PDR message and echoed in the PDR-ACK.
PDR-ACK Status: 8-bit field indicating the completion. The PDR-ACK PDR-ACK Status: 8-bit field indicating the completion. The PDR-ACK
Status is substructured as indicated in Figure 15: Status is substructured as indicated in Figure 15:
0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7
+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+
|E|R| Value | |E|R| Value |
+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+
Figure 15: PDR-ACK status Format Figure 15: PDR-ACK Status Format
E: 1-bit flag. Set to indicate a rejection. When not set, a E: 1-bit flag. Set to indicate a rejection. When not set, a
Value field that is set to 0 indicates Success/Unqualified Value field that is set to 0 indicates Success/Unqualified
Acceptance and other values indicate "not an outright Acceptance, and other values indicate "not an outright
rejection". rejection".
R: 1-bit flag. Reserved, MUST be set to 0 by the sender and
R: 1-bit flag. Reserved; MUST be set to 0 by the sender and
ignored by the receiver. ignored by the receiver.
Status Value: 6-bit unsigned integer. Values depending on the
setting of the 'E' flag, see Table 28 and Table 29. Status Value: 6-bit unsigned integer. Values depend on the
setting of the 'E' flag; see Tables 28 and 29.
Reserved: The Reserved field MUST be initialized to zero by the Reserved: The Reserved field MUST be initialized to zero by the
sender and MUST be ignored by the receiver. sender and MUST be ignored by the receiver.
5.3. Via Information Options 5.3. Via Information Options
A VIO signals the ordered list of IPv6 Via Addresses that constitutes A VIO signals the ordered list of IPv6 Via Addresses that constitutes
the hops of either a protection path (using Non-Storing Mode) or a the hops of either a protection path (using Non-Storing Mode) or a
segment (using Storing mode) of a Track. A Storing Mode P-DAO segment (using Storing Mode) of a Track. A Storing Mode P-DAO
contains one Storing Mode VIO (SM-VIO) whereas a Non-Storing Mode contains one SM-VIO whereas a Non-Storing Mode P-DAO contains one
P-DAO contains one Non-Storing Mode VIO (NSM-VIO). NSM-VIO.
The duration of the validity of a VIO is indicated in a segment The duration of the validity of a VIO is indicated in a Segment
Lifetime field. A P-DAO message that contains a VIO with a segment Lifetime field. A P-DAO message that contains a VIO with a Segment
Lifetime of zero is referred as a No-Path P-DAO. Lifetime of 0 is referred as a No-Path P-DAO.
The VIO contains one or more SRH-6LoRH header(s), each formed of a The VIO contains one or more SRH-6LoRH headers, each formed of an
SRH-6LoRH head and a collection of compressed Via Addresses, except SRH-6LoRH head and a collection of compressed Via Addresses, except
in the case of a Non-Storing Mode No-Path P-DAO where the SRH-6LoRH in the case of a Non-Storing Mode No-Path P-DAO where the SRH-6LoRH
header is not present. header is not present.
In the case of a SM-VIO, or if [RFC8138] is not used in the data In the case of an SM-VIO, or if [RFC8138] is not used in the data
packets, then the Root MUST use only one SRH-6LoRH per Via packets, then the Root MUST use only one SRH-6LoRH per Via
Information Option, and the compression is the same for all the Information Option, and the compression is the same for all the
addresses, as shown in Figure 16, for simplicity. addresses, as shown in Figure 16, for simplicity.
In case of an NSM-VIO and if [RFC8138] is in use in the main DODAG, In case of an NSM-VIO, and if [RFC8138] is in use in the main DODAG,
the Root SHOULD optimize the size of the NSM-VIO if using different the Root SHOULD optimize the size of the NSM-VIO if using different
SRH-6LoRH Types would make the VIO globally shorter; this means that SRH-6LoRH Types would make the VIO globally shorter; this means that
more than one SRH-6LoRH may be present. more than one SRH-6LoRH may be present.
The format of the Via Information Option is as follows: The format of the VIO 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Option Type | Option Length | Flags | P-RouteID | | Option Type | Option Length | Flags | P-RouteID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Segm. Sequence | Seg. Lifetime | SRH-6LoRH head | | Seg. Sequence | Seg. Lifetime | SRH-6LoRH head |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
. Via Address 1 (compressed by RFC 8138) . . Via Address 1 (compressed by RFC 8138) .
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
. .... . . .... .
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
. Via Address n (compressed by RFC 8138) . . Via Address n (compressed by RFC 8138) .
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
. Additional SRH-6LoRH Header(s) . . Additional SRH-6LoRH header(s) .
| | | |
. .... . . .... .
Figure 16: VIO format Figure 16: VIO Format
Option Type: 0x0E for SM-VIO, 0x0F for NSM-VIO (to be confirmed by Option Type: 0x0F for SM-VIO and 0x10 for NSM-VIO (see Table 26).
IANA) (see Table 26).
Option Length: 8-bit unsigned integer, representing the length in Option Length: 8-bit unsigned integer, representing the length in
octets of the option, not including the Option Type and Length octets of the option, not including the Option Type and Length
fields (see section 6.7.1. of [RPL]); the Option Length is fields (see Section 6.7.1 of [RPL]); the Option Length is
variable, depending on the number of Via Addresses and the variable, depending on the number of Via Addresses and the
compression applied. compression applied.
Flags: 8-bit field. No flag is defined in this specification. The Flags: 8-bit field. No flag is defined in this specification. The
field MUST be set to 0 by the sender and ignored by the receiver. field MUST be set to 0 by the sender and ignored by the receiver.
P-RouteID: 8-bit field that identifies a component of a Track or the P-RouteID: 8-bit field that identifies a component of a Track or the
main DODAG as indicated by the TrackID field. The value of 0 is main DODAG as indicated by the TrackID field. The value of 0 is
used to signal a path, i.e., made of a single segment/protection used to signal a path, i.e., made of a single segment/protection
path. In an SM-VIO, the P-RouteID indicates a Segment ID. In an path. In an SM-VIO, the P-RouteID indicates a Segment ID. In an
NSM-VIO, it indicates the ID of a protection path that is added NSM-VIO, it indicates the ID of a protection path that is added
(or updated) to the overall topology of the Track. (or updated) to the overall topology of the Track.
Segment Sequence: 8-bit unsigned integer. The Segment Sequence Segment Sequence: 8-bit unsigned integer. The Segment Sequence
obeys the operation in section 7.2 of [RPL] and the initial value obeys the operation in Section 7.2 of [RPL], and the initial value
is 255. is 255.
When the Root of the DODAG needs to refresh or update a segment in When the Root of the DODAG needs to refresh or update a segment in
a Track, it increments the Segment Sequence individually for that a Track, it increments the Segment Sequence individually for that
segment. segment.
The segment information indicated in the VIO deprecates any state The segment information indicated in the VIO deprecates any state
for the segment indicated by the P-RouteID within the indicated for the segment indicated by the P-RouteID within the indicated
Track and sets up the new information. Track and sets up the new information.
skipping to change at page 54, line 32 skipping to change at line 2488
Segment Lifetime: 8-bit unsigned integer. The length of time in Segment Lifetime: 8-bit unsigned integer. The length of time in
Lifetime Units (obtained from the Configuration option) that the Lifetime Units (obtained from the Configuration option) that the
segment is usable. segment is usable.
The period starts when a new Segment Sequence is seen. The value The period starts when a new Segment Sequence is seen. The value
of 255 (0xFF) represents infinity. The value of zero (0x00) of 255 (0xFF) represents infinity. The value of zero (0x00)
indicates a loss of reachability. indicates a loss of reachability.
SRH-6LoRH head: The first 2 bytes of the (first) SRH-6LoRH as shown SRH-6LoRH head: The first 2 bytes of the (first) SRH-6LoRH as shown
in Figure 6 of [RFC8138]. As an example, a 6LoRH Type of 4 means in Figure 6 of [RFC8138]. As an example, a 6LoRH Type of 4 means
that the VIA Addresses are provided in full with no compression. that the Via Addresses are provided in full with no compression.
Via Address: An IPv6 ULA or GUA of a node along the segment. The Via Address: An IPv6 ULA or GUA of a node along the segment. The
VIO contains one or more IPv6 Via Addresses listed in the datapath VIO contains one or more IPv6 Via Addresses listed in the datapath
order from Ingress to Egress. The list is expressed in a order from Ingress to Egress. The list is expressed in a
compressed form as signaled by the preceding SRH-6LoRH header. compressed form as signaled by the preceding SRH-6LoRH header.
In a Storing Mode P-DAO that updates or removes a section of an In a Storing Mode P-DAO that updates or removes a section of an
already existing segment, the list in the SM-VIO may represent already existing segment, the list in the SM-VIO may represent
only the section of the segment that is being updated; at the only the section of the segment that is being updated; at the
extreme, the SM-VIO updates only one node, in which case it extreme, the SM-VIO updates only one node, in which case it
contains only one IPv6 address. In all other cases, the list in contains only one IPv6 address. In all other cases, the list in
the VIO MUST be complete. the VIO MUST be complete.
In the case of an SM-VIO, the list indicates a sequential (strict) In the case of an SM-VIO, the list indicates a sequential (strict)
path through direct neighbors, the complete list starts at Ingress path through direct neighbors; the complete list starts at the
and ends at Egress, and the nodes listed in the VIO, including the Ingress and ends at the Egress, and the nodes listed in the VIO,
Egress, MAY be considered as implicit Targets. including the Egress, MAY be considered as implicit Targets.
In the case of an NSM-VIO, the complete list can be loose and In the case of an NSM-VIO, the complete list can be loose and
excludes the Ingress node, starting at the first loose hop and excludes the Ingress node, starting at the first loose hop and
ending at a Track Egress; the Track Egress MUST be considered as ending at a Track Egress; the Track Egress MUST be considered as
an implicit Target, so it MUST NOT be signaled in a RPL Target an implicit Target, so it MUST NOT be signaled in a RPL Target
Option. Option.
5.4. Sibling Information Option 5.4. Sibling Information Option
The Sibling Information Option (SIO) provides information about The Sibling Information Option (SIO) provides information about
siblings that could be used by the Root to form P-Routes. One or siblings that could be used by the Root to form P-Routes. One or
more SIO(s) may be placed in the DAO messages that are sent to the more SIOs may be placed in the DAO messages that are sent to the Root
Root in Non-Storing Mode. in Non-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 per [RFC8505] for an address (ULA or
or GUA) that serves as identifier for the node. If this router also GUA) that serves as an 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 to report the SIO, with Interface ID in its registered address needs to report the SIO, with
the B flag set, and the Root will assume symmetry. the B flag set, and the Root will assume symmetry.
The SIO carries a flag (B) that is set when similar performance can The SIO carries a flag (B) that is set when similar performance can
be expected in both directions, so the routing can consider that the be expected in both directions, so the routing can consider that the
information provided for one direction is valid for both. If the SIO information provided for one direction is valid for both. If the SIO
is effectively received from both sides then the B flag MUST be is effectively received from both sides, then the B flag MUST be
ignored. The policy that describes the performance criteria, and how ignored. The policy that describes the performance criteria and how
they are asserted is out of scope. In the absence of an external 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. 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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
+ + + +
. . . .
. Sibling DODAGID (if the D flag not set) . . Sibling DODAGID (if the D flag is not set) .
. . . .
+ + + +
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
+ + + +
. . . .
. Sibling Address . . Sibling Address .
. . . .
+ + + +
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 17: Sibling Information Option Format Figure 17: Sibling Information Option Format
Option Type: 0x10 for SIO (to be confirmed by IANA) (see Table 26). Option Type: 0x11 for SIO (see Table 26).
Option Length: 8-bit unsigned integer, representing the length in Option Length: 8-bit unsigned integer, representing the length in
octets of the option, not including the Option Type and Length octets of the option, not including the Option Type and Length
fields (see section 6.7.1. of [RPL]). fields (see Section 6.7.1 of [RPL]).
Reserved for Flags: MUST be set to zero by the sender and MUST be Reserved for Flags: MUST be set to 0 by the sender and MUST be
ignored by the receiver. ignored by the receiver.
B: 1-bit flag that is set to indicate that the connectivity to the B: 1-bit flag that is set to indicate that the connectivity to the
sibling is bidirectional and roughly symmetrical. In that case, sibling is bidirectional and roughly symmetrical. In that case,
only one of the siblings needs report the SIO for the hop. If 'B' only one of the siblings needs to report the SIO for the hop. If
is not set then the SIO only indicates connectivity from the 'B' is not set, then the SIO only indicates connectivity from the
sibling to this node, and does not provide information on the hop sibling to this node, and it does not provide information on the
from this node to the sibling. hop from this node to the sibling.
S: 1-bit flag that is set to indicate that sibling belongs to the S: 1-bit flag that is set to indicate that the sibling belongs to
same DODAG. When not set, the Sibling DODAGID is indicated. the same DODAG. When not set, the Sibling DODAGID is indicated.
Flags: Reserved. The Flags field MUST be initialized to zero by the Flags: Reserved. The Flags field MUST be initialized to zero by the
sender and MUST be ignored by the receiver. sender and MUST be ignored by the receiver.
Comp.: Compression Type, a 3-bit unsigned integer. This is the SRH- Comp.: Compression Type; a 3-bit unsigned integer. This is the SRH-
6LoRH Type as defined in figure 7 in section 5.1 of [RFC8138] that 6LoRH Type as defined in Figure 7 in Section 5.1 of [RFC8138] that
corresponds to the compression used for the Sibling Address and corresponds to the compression used for the Sibling Address and
its DODAGID if present. The Compression reference is the Root of its DODAGID if present. The Compression reference is the Root of
the main DODAG. the main DODAG.
Opaque: MAY be used to carry information that the node and the Root Opaque: MAY be used to carry information that the node and the Root
understand, e.g., a particular representation of the Link understand, e.g., a particular representation of the link
properties such as a proprietary Link Quality Information for properties such as a proprietary Link Quality Information for
packets received from the sibling. In some scenarios such as the packets received from the sibling. In some scenarios such as
case of an Industrial Alliances that uses RPL for a particular use Industrial Alliances that use RPL for a particular use/
/ environment, this field MAY be redefined to fit the needs of environment, this field MAY be redefined to fit the needs of the
that case. case.
Step in Rank: 16-bit unsigned integer. This is the Step in Rank Step in Rank: 16-bit unsigned integer. This is the Step in Rank
[RPL] as computed by the Objective Function between this node and [RPL] as computed by the Objective Function between this node and
the sibling, that reflects the abstract Rank increment that would the sibling, which reflects the abstract Rank increment that would
be computed by the OF if the sibling was the preferred parent. be computed by the Objective Function if the sibling was the
preferred parent.
Reserved: The Reserved field MUST be initialized to zero by the Reserved: The Reserved field MUST be initialized to zero by the
sender and MUST be ignored by the receiver sender and MUST be ignored by the receiver
Sibling DODAGID: 2 to 16 bytes, the DODAGID of the sibling in a Sibling DODAGID: 2 to 16 bytes. The DODAGID of the sibling in a
[RFC8138] compressed form as indicated by the Compression Type compressed form [RFC8138] as indicated by the Compression Type
field. This field is present if and only if the D flag is not field. This field is present if and only if the D flag is not
set. set.
Sibling Address: 2 to 16 bytes, an IPv6 Address of the sibling, with Sibling Address: 2 to 16 bytes. An IPv6 address of the sibling with
a scope that MUST make it reachable from the Root, e.g., it cannot a scope that MUST make it reachable from the Root, e.g., it cannot
be a Link Local Address. The IPv6 address is encoded in the be a Link Local Address. The IPv6 address is encoded in the
[RFC8138] compressed form indicated by the Compression Type field. compressed form [RFC8138] indicated by the Compression Type field.
An SIO MAY be immediately followed by a DAG Metric Container. In An SIO MAY be immediately followed by a DAG Metric Container. In
that case the DAG Metric Container provides additional metrics for that case, the DAG Metric Container provides additional metrics for
the hop from the Sibling to this node. the hop from the Sibling to this node.
6. Root Initiated Routing State 6. Root-Initiated Routing State
6.1. RPL Network Setup 6.1. RPL Network Setup
To avoid the need of Path MTU Discovery by 6LoWPAN end-points, To avoid the need of Path MTU Discovery by 6LoWPAN endpoints, 6LoWPAN
6LoWPAN links are normally defined with a MTU of 1280 (see section 4 links are normally defined with an MTU of 1280 (see Section 4 of
of [6LoWPAN]). Injecting packets in a Track typically involves an [6LoWPAN]). Injecting packets in a Track typically involves an IP-
IP-in-IP encapsulation and additional IPv6 Extension Headers. This in-IP encapsulation and additional IPv6 extension headers. This may
may cause fragmentation if the resulting packets exceed the MTU that cause fragmentation if the resulting packets exceed the MTU that is
is defined for the RPL domain. defined for the RPL domain.
Though fragmentation is possible in a 6LoWPAN LLN, e.g., using Though fragmentation is possible in a 6LoWPAN LLN, e.g., using
[6LoWPAN], [RFC8930], and/or [RFC8931], it is RECOMMENDED to define [6LoWPAN], [RFC8930], and/or [RFC8931], it is RECOMMENDED to define
an MTU that is larger than 1280 between RPL routers that form the an MTU that is larger than 1280 between the RPL routers that form the
main DODAG to allow for the necessary header additions, while still main DODAG to allow for the necessary header additions, while still
exposing 1280 to the 6LoWPAN end-point stacks. exposing 1280 to the 6LoWPAN endpoint stacks.
6.2. Requesting a Track 6.2. Requesting a Track
This specification introduces the PDR message, used by an LLN node to This specification introduces the PDR message, which is used by an
request the formation of a new Track for which this node is the LLN node to request the formation of a new Track for which the LLN
Ingress. Note that the namespace for the TrackID is owned by the node is the Ingress. Note that the namespace for the TrackID is
Ingress node, and in the absence of a PDR, there must be some owned by the Ingress node, and in the absence of a PDR, there must be
procedure for the Root to assign TrackIDs in that namespace while some procedure for the Root to assign TrackIDs in that namespace
avoiding collisions (more in Section 6.3). while avoiding collisions (see more in Section 6.3).
The PDR signals the desired TrackID and the duration for which the The PDR signals the desired TrackID and the duration for which the
Track should be established. Upon a PDR, the Root MAY install the Track should be established. Upon a PDR, the Root MAY install the
Track as requested, in which case it answers with a PDR-ACK Track as requested, in which case it answers with a PDR-ACK
indicating the granted Track Lifetime. All the segments MUST be of a indicating the granted Track Lifetime. All the segments MUST be of
same mode, either Storing or Non-Storing. All the segments MUST be the same mode, either Storing or Non-Storing. All the segments MUST
created with the same TrackID and the same DODAGID signaled in the be created with the same TrackID and the same DODAGID signaled in the
P-DAO. P-DAO.
The Root designs the Track as it sees best, and updates / changes the The Root designs the Track as it sees fit and updates/changes the
segments over time to serve the Track as needed. Note that there is segments over time to serve the Track as needed. Note that there is
no protocol element to notify to the requesting Track Ingress when no protocol element to notify the requesting Track Ingress when
changes happen deeper down the Track, so they are transparent to the changes happen deeper down the Track, so they are transparent to the
Track Ingress. If the main Root cannot maintain an expected service Track Ingress. If the main Root cannot maintain an expected service
level, then it needs to tear down the Track completely. The Segment level, then it needs to tear down the Track completely. The Segment
Lifetime in the P-DAO messages does not need to be aligned to the Lifetime in the P-DAO messages does not need to be aligned to the
Requested Lifetime in the PDR, or between P-DAO messages for Requested Lifetime in the PDR or between P-DAO messages for different
different segments. E.g., The Root may use shorter lifetimes for the segments. For example, the Root may use shorter lifetimes for the
segments and renew them or change them during the lifetime of the segments and renew them or change them during the lifetime of the
Track. All the components (protection paths and segments) of a Track Track. All the components (protection paths and segments) of a Track
MUST be destroyed (or have their lifetime elapsed) before the TrackID MUST be destroyed (or have their lifetime elapsed) before the TrackID
can be reused. can be reused.
When the Track Lifetime is relatively close to elapse - meaning in When the Track Lifetime is relatively close to elapse -- meaning in
the order of the trip time from the node to the Root - the requesting the order of the trip time from the node to the Root -- the
node SHOULD resend a PDR using the TrackID in the PDR-ACK to extend requesting node SHOULD resend a PDR using the TrackID in the PDR-ACK
the lifetime of the Track, else the Track will time out and the Root to extend the lifetime of the Track; otherwise, the Track will time
will tear down the whole structure. out, and the Root will tear down the whole structure.
If the Track fails and cannot be restored, the Root notifies the If the Track fails and cannot be restored, the Root notifies the
requesting node asynchronously with a PDR-ACK with a Track Lifetime requesting node asynchronously with a PDR-ACK with a Track Lifetime
of 0, indicating that the Track has failed, and a PDR-ACK Status of 0, indicating that the Track has failed, and a PDR-ACK Status,
indicating the reason of the fault. indicating the reason of the fault.
6.3. Identifying a Track 6.3. Identifying a Track
RPL defines the concept of an Instance to signal an individual RPL defines the concept of an Instance to signal an individual
routing topology, and multiple topologies can coexist in the same routing topology, and multiple topologies can coexist in the same
network. The RPLInstanceID is tagged in the RPI of every packet to network. The RPLInstanceID is tagged in the RPI of every packet to
signal which topology the packet actually follows. signal which topology the packet actually follows.
This specification leverages the RPL Instance model as follows: This specification leverages the RPL Instance model as follows:
* The main Root MAY use P-DAO messages to add better routes in the * The main Root MAY use P-DAO messages to add better routes in the
main Instance in conformance with the routing objectives in that main Instance in conformance with the routing objectives in that
Instance. Instance.
To achieve this, the main Root MAY install a segment along a path To achieve this, the main Root MAY install a segment along a path
down the main DODAG, which is operated in Non-Storing Mode. This down the main DODAG, which is operated in Non-Storing Mode. This
enables a loose source routing and reduces the size of the Routing enables loose source routing and reduces the size of the Routing
Header, see Section 3.3.1. The main Root MAY also install a Header; see Section 3.3.1. The main Root MAY also install a
protection path across the main DODAG to complement the routing protection path across the main DODAG to complement the routing
topology. topology.
When adding a P-Route to the RPL main DODAG, the main Root MUST When adding a P-Route to the RPL main DODAG, the main Root MUST
set the RPLInstanceID field of the P-DAO Base Object (see section set the RPLInstanceID field of the P-DAO Base Object (see
6.4.1. of [RPL]) to the RPLInstanceID of the main DODAG, and MUST Section 6.4.1 of [RPL]) to the RPLInstanceID of the main DODAG,
NOT use the DODAGID field. A P-Route provides a longer match to and it MUST NOT use the DODAGID field. A P-Route provides a
the Target Address than the default route via the main Root, so it longer match to the Target Address than the default route via the
is preferred. main Root, so it is preferred.
* The main Root MAY also use P-DAO messages to install a Track as an * The main Root MAY also use P-DAO messages to install a Track as an
independent routing topology (say, Traffic Engineered) to achieve independent routing topology (say, Traffic Engineered) to achieve
particular routing characteristics from an Ingress to Egress particular routing characteristics from Ingress to Egress
Endpoints. To achieve this, the main Root MUST set up a Local RPL endpoints. To achieve this, the main Root MUST set up a Local RPL
Instance (see section 5 of [RPL]), and the Local RPLInstanceID Instance (see Section 5 of [RPL]), and the Local RPLInstanceID
serves as the TrackID. The TrackID MUST be unique for the IPv6 serves as the TrackID. The TrackID MUST be unique for the IPv6
ULA or GUA of the Track Ingress that serves as DODAGID for the ULA or GUA of the Track Ingress that serves as the DODAGID for the
Track. Track.
This way, a Track is uniquely identified by the tuple (DODAGID, This way, a Track is uniquely identified by the tuple (DODAGID,
TrackID) where the TrackID is always represented with the D flag TrackID) where the TrackID is always represented with the D flag
set to 0 (see also section 5.1. of [RPL]), indicating when used in set to 0 (see also Section 5.1 of [RPL]), indicating that when
an RPI that the source address of the IPv6 packet signals the used in an RPI, the source address of the IPv6 packet signals the
DODAGID. DODAGID.
The P-DAO Base Object MUST indicate the tuple (DODAGID, TrackID) The P-DAO Base Object MUST indicate the tuple (DODAGID, TrackID)
that identifies the Track as shown in Figure 8, and the P-RouteID that identifies the Track as shown in Figure 8, and the P-RouteID
that identifies the P-Route MUST be signaled in the VIO as shown that identifies the P-Route MUST be signaled in the VIO as shown
in Figure 16. in Figure 16.
The Track Ingress is the Root of the DODAG ID formed by the local The Track Ingress is the Root of the DODAGID formed by the Local
RPL Instance. It owns the namespace of its TrackIDs, so it can RPL Instance. It owns the namespace of its TrackIDs, so it can
pick any unused value to request a new Track with a PDR. In a pick any unused value to request a new Track with a PDR. In a
particular deployment where PDRs are not used, a portion of the particular deployment where PDRs are not used, a portion of the
namespace can be administratively delegated to the main Root, namespace can be administratively delegated to the main Root,
meaning that the main Root is authoritative for assigning the meaning that the main Root is authoritative for assigning the
TrackIDs for the Tracks it creates. TrackIDs for the Tracks it creates.
With this specification, the main Root is aware of all the active With this specification, the main Root is aware of all the active
Tracks, so it can also pick any unused value to form Tracks Tracks, so it can also pick any unused value to form Tracks
without a PDR. To avoid a collision of the main Root and the without a PDR. To avoid a collision of the main Root and the
Track Ingress picking the same value at the same time, it is Track Ingress picking the same value at the same time, it is
RECOMMENDED that the Track Ingress starts allocating the ID value RECOMMENDED that the Track Ingress starts allocating the ID value
of the Local RPLInstanceID (see section 5.1. of [RPL]) used as of the Local RPLInstanceID (see Section 5.1 of [RPL]) used as
TrackIDs with the value 0 incrementing, while the Root starts with TrackIDs with the value 0 incrementing, while the Root starts with
63 decrementing. 63 decrementing.
6.4. Installing a Track 6.4. Installing a Track
A path can be installed by a single P-Route that signals the sequence A path can be installed by a single P-Route that signals the sequence
of consecutive nodes, either in Storing Mode as a single-segment of consecutive nodes either in Storing Mode as a single-segment Track
Track, or in Non-Storing Mode as a single-protection-path Track. A or in Non-Storing Mode as a single-protection-path Track. A single-
single-protection-path Track can be installed as a loose Non-Storing protection-path Track can be installed as a loose Non-Storing Mode
Mode P-Route, in which case the next loose entry must recursively be P-Route, in which case the next loose entry must recursively be
reached over a path. reached over a path.
A Complex Track can be installed as a collection of P-Routes with the A Complex Track can be installed as a collection of P-Routes with the
same DODAGID and Track ID. The Ingress of a Non-Storing Mode P-Route same DODAGID and Track ID. The Ingress of a Non-Storing Mode P-Route
is the owner and Root of the DODAGID. The Ingress of a Storing Mode is the owner and Root of the DODAGID. The Ingress of a Storing Mode
P-Route must be either the owner of the DODAGID, or a hop of a P-Route must be either the owner of the DODAGID or a hop of a
protection path of the same Track. In the latter case, the Targets protection path of the same Track. In the latter case, the Targets
of the P-Route must include the next hop of the protection path if of the P-Route must include the next hop of the protection path if
there is one, to ensure forwarding continuity. In the case of a there is one to ensure forwarding continuity. In the case of a
Complex Track, each segment is maintained independently and Complex Track, each segment is maintained independently and
asynchronously by the Root, with its own lifetime that may be asynchronously by the Root, with its own lifetime that may be
shorter, the same, or longer than that of the Track. shorter, the same, or longer than that of the Track.
A route along a Track for which the TrackID is not the RPLInstanceID A route along a Track for which the TrackID is not the RPLInstanceID
of the main DODAG MUST be installed with a higher precedence than the of the main DODAG MUST be installed with a higher precedence than the
routes along the main DODAG, meaning that: routes along the main DODAG, meaning that:
* Longest match MUST be the prime comparison for routing. * The longest match MUST be the prime comparison for routing.
* In case of equal length match, the route along the Track MUST be * For an equal-length match, the route along the Track MUST be
preferred vs. the one along the main DODAG. preferred over the one along the main DODAG.
* There SHOULD NOT be 2 different Tracks leading to the same Target * There SHOULD NOT be two different Tracks leading to the same
from same Ingress node, unless there's a policy for selecting Target from same Ingress node, unless there's a policy for
which packets use which Track; such a policy is out of scope. selecting which packets use which Track; such a policy is out of
scope.
* A packet that was routed along a Track MUST NOT be routed along * A packet that was routed along a Track MUST NOT be routed along
the main DODAG again; if the destination is not reachable as a the main DODAG again; if the destination is not reachable as a
neighbor by the node where the packet exits the Track then the neighbor by the node where the packet exits the Track, then the
packet MUST be dropped. packet MUST be dropped.
6.4.1. Signaling a Projected Route 6.4.1. Signaling a Projected Route
This specification adds a capability whereby the Root of a main DODAG This specification adds a capability whereby the Root of a main DODAG
installs a Track as a collection of P-Routes, using a Projected-DAO installs a Track as a collection of P-Routes, using a P-DAO message
(P-DAO) message for each individual protection path or segment. The for each individual protection path or segment. The P-DAO signals a
P-DAO signals a collection of Targets in the RPL Target Option(s) collection of Targets in one or more RTOs. Those Targets can be
(RTO). Those Targets can be reached via a sequence of routers reached via a sequence of routers indicated in a VIO.
indicated in a VIO.
Like a classical DAO message, a P-DAO causes a change of state only Like a classical DAO message, a P-DAO causes a change of state only
if it is "new" per section 9.2.2. "Generation of DAO Messages" of if it is "new" per Section 9.2.2 ("Generation of DAO Messages") of
the RPL specification [RPL]; this is determined using the Segment the RPL specification [RPL]; this is determined using the Segment
Sequence information from the VIO as opposed to the Path Sequence Sequence information from the VIO as opposed to the Path Sequence
from a TIO. Also, a Segment Lifetime of 0 in a VIO indicates that from a TIO. Also, a Segment Lifetime of 0 in a VIO indicates that
the P-Route associated to the segment is to be removed. There are the P-Route associated to the segment is to be removed. There are
two Modes of operation for the P-Routes, the Storing and the Non- two Modes of operation for the P-Routes: Storing and Non-Storing.
Storing Modes.
A P-DAO message MUST be sent from the address of the Root that serves A P-DAO message MUST be sent from the address of the Root that serves
as DODAGID for the main DODAG. It MUST contain either exactly one as the DODAGID for the main DODAG. It MUST contain either exactly
sequence of one or more RTOs followed by one VIO, or any number of one sequence of one or more RTOs followed by one VIO or any number of
sequences of one or more RTOs followed by one or more TIOs. The sequences of one or more RTOs followed by one or more TIOs. The
former is the normal expression for this specification, whereas the former is the normal expression for this specification, whereas the
latter corresponds to the variation for less-constrained environments latter corresponds to the variation for less-constrained environments
described in Section 7.2. described in Section 7.2.
A P-DAO that creates or updates a protection path MUST be sent to a A P-DAO that creates or updates a protection path MUST be sent to a
GUA or a ULA of the Ingress of the protection path; it MUST contain GUA or a ULA of the Ingress of the protection path; it MUST contain
the full list of hops in the protection path unless the protection the full list of hops in the protection path unless the protection
path is being removed. A P-DAO that creates a new Track segment MUST path is being removed. A P-DAO that creates a new Track segment MUST
be sent to a GUA or a ULA of the segment Egress and MUST signal the be sent to a GUA or a ULA of the segment Egress and MUST signal the
full list of hops in segment; a P-DAO that updates (including full list of hops in a segment; a P-DAO that updates (including
deletes) a section of a segment MUST be sent to the first node after deletes) a section of a segment MUST be sent to the first node after
the modified segment and signal the full list of hops in the section the modified segment and signal the full list of hops in the section
starting at the node that immediately precedes the modified section. starting at the node that immediately precedes the modified section.
In Non-Storing Mode, as discussed in Section 6.4.3, the Root sends In Non-Storing Mode, as discussed in Section 6.4.3, the Root sends
the P-DAO to the Track Ingress where the source-routing state is the P-DAO to the Track Ingress where the source routing state is
applied, whereas in Storing Mode, the P-DAO is sent to the last node applied, whereas in Storing Mode, the P-DAO is sent to the last node
on the installed path and forwarded in the reverse direction, on the installed path and forwarded in the reverse direction,
installing a Storing Mode state at each hop, as discussed in installing a Storing Mode state at each hop, as discussed in
Section 6.4.2. In both cases the Track Ingress is the owner of the Section 6.4.2. In both cases, the Track Ingress is the owner of the
Track, and it generates the P-DAO-ACK when the installation is Track, and it generates the P-DAO-ACK when the installation is
successful. successful.
If the 'K' Flag is present in the P-DAO, the P-DAO MUST be If the 'K' flag is present in the P-DAO, the P-DAO MUST be
acknowledged using a DAO-ACK that is sent back to the address of the acknowledged using a DAO-ACK that is sent back to the address of the
Root from which the P-DAO was received. In most cases, the first Root from which the P-DAO was received. In most cases, the first
node of the protection path, segment, or updated section of the node of the protection path, segment, or updated section of the
segment is the node that sends the acknowledgment. The exception to segment is the node that sends the acknowledgment. The exception to
the rule is when an intermediate node in a segment fails to forward a the rule is when an intermediate node in a segment fails to forward a
Storing Mode P-DAO to the previous node in the SM-VIO. Storing Mode P-DAO to the previous node in the SM-VIO.
In a No-Path Non-Storing Mode P-DAO, the SRH-6LoRH MUST NOT be In a No-Path Non-Storing Mode P-DAO, the SRH-6LoRH MUST NOT be
present in the NSM-VIO; the state in the Ingress is erased present in the NSM-VIO; the state in the Ingress is erased
regardless. In all other cases, a VIO MUST contain at least one Via regardless. In all other cases, a VIO MUST contain at least one Via
Address, and a Via Address MUST NOT be present more than once, which Address, and a Via Address MUST NOT be present more than once, which
would create a loop. would create a loop.
A node that processes a VIO MAY verify whether any of these A node that processes a VIO MAY verify whether any of these
conditions happen, and when one does, it MUST ignore the P-DAO and conditions happen, and when one does, it MUST ignore the P-DAO and
reject it with a RPL Rejection Status of "Error in VIO" in the DAO- reject it with a RPL Rejection Status of "Error in VIO" in the DAO-
ACK, see Section 11.16. ACK; see Section 11.16.
Other errors than those discussed explicitly that prevent the Errors, other than those discussed explicitly, that prevent the
installation of the route are acknowledged with a RPL Rejection installation of the route are acknowledged with a RPL Rejection
Status of "Unqualified Rejection" in the DAO-ACK. Status of "Unqualified Rejection" in the DAO-ACK.
6.4.2. Installing a Track Segment with a Storing Mode P-Route 6.4.2. Installing a Track Segment with a Storing Mode P-Route
As illustrated in Figure 18, a Storing Mode P-DAO installs a route As illustrated in Figure 18, a Storing Mode P-DAO installs a route
along the segment signaled by the SM-VIO towards the Targets along the segment signaled by the SM-VIO towards the Targets
indicated in the Target Options. The segment is to be included in a indicated in the Target Options. The segment is to be included in a
DODAG indicated by the P-DAO Base Object, that may be the one formed DODAG indicated by the P-DAO Base Object, which may be the one formed
by the main DODAG, or a Track associated with a local RPL Instance. by the main DODAG, or a Track associated with a Local RPL Instance.
------+--------- ------+---------
| Internet | Internet
| |
+-----+ +-----+
| | Border router | | Border Router
| | (RPL Root) | | (RPL Root)
+-----+ | ^ | +-----+ | ^ |
| | DAO | ACK | | | DAO | ACK |
o o o o | | | o o o o | | |
o o o o Ingress o o o | ^ | Projected . o o o o Ingress o o o | ^ | Projected .
o o o o o \\ o o o | | DAO | Route . o o o o o \\ o o o | | DAO | Route .
o o o o \\ o o o o | ^ | . o o o o \\ o o o o | ^ | .
o o o o o Egress o o v | DAO v . o o o o o Egress o o v | DAO v .
o o LLN o o o | o o LLN o o o |
o o o o o Loose Source Route Path | o o o o o Loose Source Route Path |
o o o o v o o o o v
Figure 18: Projecting a route Figure 18: Projecting a Route
In order to install the relevant routing state along the segment , In order to install the relevant routing state along the segment, the
the Root sends a unicast P-DAO message to the Track Egress router of Root sends a unicast P-DAO message to the Track Egress router of the
the routing segment that is being installed. The P-DAO message routing segment that is being installed. The P-DAO message contains
contains a SM-VIO with the strict sequence of Via Addresses. The SM- an SM-VIO with a strict sequence of Via Addresses. The SM-VIO
VIO follows one or more RTOs indicating the Targets to which the follows one or more RTOs indicating the Targets to which the Track
Track leads. The SM-VIO contains a Segment Lifetime for which the leads. The SM-VIO contains a Segment Lifetime for which the state is
state is to be maintained. to be maintained.
The Root sends the P-DAO directly to the Egress node of the segment. The Root sends the P-DAO directly to the Egress node of the segment.
In that P-DAO, the destination IP address matches the last Via In that P-DAO, the destination IP address matches the last Via
Address in the SM-VIO. This is how the Egress recognizes its role. Address in the SM-VIO. This is how the Egress recognizes its role.
In a similar fashion, the segment Ingress node recognizes its role In a similar fashion, the segment Ingress node recognizes its role
because it matches the first Via Address in the SM-VIO. because it matches the first Via Address in the SM-VIO.
The Egress node of the segment is the only node in the path that does The Egress node of the segment is the only node in the path that does
not install a route in response to the P-DAO; it is expected to be not install a route in response to the P-DAO; it is expected to be
already able to route to the Target(s) based on its existing tables. already able to route to the Target(s) based on its existing tables.
If one of the Targets is not known, the node MUST answer to the Root If one of the Targets is not known, the node MUST answer to the Root
with a DAO-ACK listing the unreachable Target(s) in an RTO and a with a DAO-ACK listing the unreachable Target(s) in an RTO and a
rejection status of "Unreachable Target". rejection status of "Unreachable Target".
If the Egress node can reach all the Targets, then it forwards the If the Egress node can reach all the Targets, it forwards the P-DAO
P-DAO with unchanged content to its predecessor in the segment as with unchanged content to its predecessor in the segment as indicated
indicated in the list of Via Information options, and recursively the in the list of VIOs, and the message is recursively propagated
message is propagated unchanged along the sequence of routers unchanged along the sequence of routers indicated in the P-DAO, but
indicated in the P-DAO, but in the reverse order, from Egress to in the reverse order, from Egress to Ingress.
Ingress.
The address of the predecessor to be used as destination of the The address of the predecessor to be used as the destination of the
propagated DAO message is found in the Via Address list, at the propagated DAO message is found in the Via Address list at the
position preceding the one that contains the address of the position preceding the one that contains the address of the
propagating node, which is used as source of the message. propagating node, which is used as the source of the message.
Upon receiving a propagated DAO, all except the Egress router MUST Upon receiving a propagated DAO, all except the Egress router MUST
install a route towards the DAO Target(s) via their successor in the install a route towards the DAO Target(s) via their successor in the
SM-VIO. A router that cannot store the routes to all the Targets in SM-VIO. A router that cannot store the routes to all the Targets in
a P-DAO MUST reject the P-DAO by sending a DAO-ACK to the Root with a a P-DAO MUST reject the P-DAO by sending a DAO-ACK to the Root with a
Rejection Status of "Out of Resources" as opposed to forwarding the Rejection Status of "Out of Resources" as opposed to forwarding the
DAO to its predecessor in the list. The router MAY install DAO to its predecessor in the list. The router MAY install
additional routes towards the Via Addresses that appear in the SM-VIO additional routes towards the Via Addresses that appear in the SM-VIO
after its own address, if any, but in case of a conflict or a lack of after its own address, if any, but in case of a conflict or a lack of
resource, the route(s) to the Target(s) are the ones that MUST be resource, the route(s) to the Target(s) MUST be installed in
installed in priority. priority.
If a router cannot reach its predecessor in the SM-VIO, the router If a router cannot reach its predecessor in the SM-VIO, the router
MUST send the DAO-ACK to the Root with a Rejection Status of MUST send the DAO-ACK to the Root with a Rejection Status of
"Predecessor Unreachable". "Predecessor Unreachable".
The process continues until the P-DAO is propagated to the Ingress The process continues until the P-DAO is propagated to the Ingress
router of the segment, which answers with a DAO-ACK to the Root. The router of the segment, which answers with a DAO-ACK to the Root. The
Root always expects a DAO-ACK, either from the Track Ingress with a Root always expects a DAO-ACK, either from the Track Ingress with a
positive status or from any node along the segment with a negative positive status or from any node along the segment with a negative
status. If the DAO-ACK is not received, the Root may retry the DAO status. If the DAO-ACK is not received, the Root may retry the DAO
with the same TID, or tear down the route. with the same TID or tear down the route.
6.4.3. Installing a protection path with a Non-Storing Mode P-Route 6.4.3. Installing a Protection Path with a Non-Storing Mode P-Route
As illustrated in Figure 19, a Non-Storing Mode P-DAO installs a As illustrated in Figure 19, a Non-Storing Mode P-DAO installs a
source-routed path within the Track indicated by the P-DAO Base source-routed path within the Track indicated by the P-DAO Base
Object, towards the Targets indicated in the Target Options. The Object towards the Targets indicated in the Target Options. The
source-routed path requires a Source-Routing header which implies an source-routed path requires a Source Routing Header, which implies an
IP-in-IP encapsulation to add the SRH to an existing packet. It is IP-in-IP encapsulation is needed to add the SRH to an existing
sent to the Track Ingress which creates a tunnel associated with the packet. It is sent to the Track Ingress, which creates a tunnel
Track, and connected routes over the tunnel to the Targets in the associated with the Track and connected routes over the tunnel to the
RTO. The tunnel encapsulation MUST incorporate a routing header via Targets in the RTO. The tunnel encapsulation MUST incorporate a
the list addresses listed in the VIO in the same order. The content routing header via the list addresses listed in the VIO in the same
of the NSM-VIO starting at the first SRH-6LoRH header MUST be used order. The content of the NSM-VIO starting at the first SRH-6LoRH
verbatim by the Track Ingress when it encapsulates a packet to header MUST be used verbatim by the Track Ingress when it
forward it over the Track. encapsulates a packet to forward it over the Track.
------+--------- ------+---------
| Internet | Internet
| |
+-----+ +-----+
| | Border router | | Border Router
| | (RPL Root) | | (RPL Root)
+-----+ | P ^ ACK +-----+ | P ^ ACK
| Track | DAO | | Track | DAO |
o o o o Ingress X V | X o o o o Ingress X V | X
o o o o o o o X o X Source o o o o o o o X o X Source-
o o o o o o o o X o o X Routed o o o o o o o o X o o X Routed
o o ° o o o o X o X Segment o o ° o o o o X o X Segment
o o o o o o o o X Egress X o o o o o o o o X Egress X
o o o o o | o o o o o |
Target Target
o o LLN o o o o LLN o o
o o o o o o o o
Figure 19: Projecting a Non-Storing Route Figure 19: Projecting a Non-Storing Route
The next entry in the source-routed path must be either a neighbor of The next entry in the source-routed path must be either a neighbor of
the previous entry, or reachable as a Target via another P-Route, the previous entry or reachable as a Target via another P-Route,
either Storing or Non-Storing, which implies that the nested P-Route either Storing or Non-Storing, which implies that the nested P-Route
has to be installed before the loose sequence is, and that P-Routes has to be installed before the loose sequence is and that P-Routes
must be installed from the last to the first along the datapath. For must be installed from the last to the first along the datapath. For
instance, a segment of a Track must be installed before the instance, a segment of a Track must be installed before the
protection path(s) of the same Track that use it, and stitched protection path(s) of the same Track that uses it, and stitched
segments must be installed in order from the last that reaches to the segments must be installed in order from the last to the first to
Targets to the first. reach the Targets.
If the next entry in the loose sequence is reachable over a Storing If the next entry in the loose sequence is reachable over a Storing
Mode P-Route, it MUST be the Target of a segment and the Ingress of a Mode P-Route, it MUST be the Target of a segment and the Ingress of a
next segment, both already setup; the segments are associated with next segment, which are both already set up; the segments are
the same Track, which avoids the need of an additional encapsulation. associated with the same Track, which avoids needing an additional
For instance, in Section 3.5.1.3, segments A==>B-to-C and encapsulation. For instance, in Section 3.5.1.3, segments A==>B-to-C
C==>D==>E-to-F must be installed with Storing Mode P-DAO messages 1 and C==>D==>E-to-F must be installed with Storing Mode P-DAO messages
and 2 before the Track A-->C-->E-to-F that joins them can be 1 and 2 before the Track A-->C-->E-to-F that joins them can be
installed with Non-Storing Mode P-DAO 3. installed with Non-Storing Mode P-DAO 3.
Conversely, if it is reachable over a Non-Storing Mode P-Route, the Conversely, if it is reachable over a Non-Storing Mode P-Route, the
next loose source-routed hop of the inner Track is a Target of a next loose source-routed hop of the inner Track is a Target of a
previously installed Track and the Ingress of a next Track, which previously installed Track and the Ingress of a next Track, which
requires a de- and a re-encapsulation when switching the outer Tracks requires de- and re-encapsulation when switching the outer Tracks
that join the loose hops. This is examplified in Section 3.5.2.3 that join the loose hops. This is exemplified in Section 3.5.2.3
where Non-Storing Mode P-DAO 1 and 2 install strict Tracks that Non- where Non-Storing Mode P-DAOs 1 and 2 install strict Tracks that Non-
Storing Mode P-DAO 3 joins as a super Track. In such a case, packets Storing Mode P-DAO 3 joins as a super Track. In such a case, packets
are subject to double IP-in-IP encapsulation. are subject to double IP-in-IP encapsulation.
6.5. Tearing Down a P-Route 6.5. Tearing Down a P-Route
A P-DAO with a lifetime of 0 is interpreted as a No-Path DAO and A P-DAO with a lifetime of 0 is interpreted as a No-Path DAO and
results in cleaning up existing state as opposed to refreshing an results in cleaning up existing state as opposed to refreshing an
existing one or installing a new one. To tear down a Track, the Root existing one or installing a new one. To tear down a Track, the Root
must tear down all the Track segments and protection paths that must tear down all the Track segments and protection paths that
compose it one by one. compose it one by one.
Since the state about a protection path of a Track is located only on Since the protection path state of a Track is located only on the
the Ingress Node, the Root cleans up the protection path by sending Ingress Node, the Root cleans up the protection path by sending an
an NSM-VIO to the Ingress indicating the TrackID and the P-RouteID of NSM-VIO to the Ingress to indicate the TrackID and the P-RouteID of
the protection path being removed, a Segment Lifetime of 0 and a the protection path being removed, a Segment Lifetime of 0, and a
newer Segment Sequence. The SRH-6LoRH with the Via Addresses in the newer Segment Sequence. The SRH-6LoRH with Via Addresses in the NSM-
NSM-VIO are not needed; it SHOULD NOT be placed in the message and VIO is not needed; it SHOULD NOT be placed in the message and MUST be
MUST be ignored by the receiver. Upon that NSM-VIO, the Ingress node ignored by the receiver. Upon that NSM-VIO, the Ingress node removes
removes all state for that Track if any, and replies positively all state for that Track, if any, and replies positively anyway.
anyway.
The Root cleans up a section of a segment by sending an SM-VIO to the The Root cleans up a section of a segment by sending an SM-VIO to the
last node of the segment, with the TrackID and the P-RouteID of the last node of the segment with an updated TrackID and P-RouteID, a
segment being updated, a Segment Lifetime of zero (0) and a newer Segment Lifetime of 0, and a newer Segment Sequence. The Via
Segment Sequence. The Via Addresses in the SM-VIO indicates the Addresses in the SM-VIO indicate the section of the segment being
section of the segment being modified, from the first to the last modified, from the first to the last node that is impacted. This can
node that is impacted. This can be the whole segment if it is be the whole segment if it is totally removed or a sequence of one or
totally removed, or a sequence of one or more nodes that have been more nodes that have been bypassed by a segment update.
bypassed by a segment update.
The No-Path P-DAO is forwarded normally along the reverse list, even The No-Path P-DAO is forwarded normally along the reverse list, even
if the intermediate node does not find a segment state to clean up. if the intermediate node does not find a segment state to clean up.
This results in cleaning up the existing segment state if any, as This results in cleaning up the existing segment state, if any, as
opposed to refreshing an existing one or installing a new one. opposed to refreshing an existing one or installing a new one.
6.6. Maintaining a Track 6.6. Maintaining a Track
Repathing a Track segment or protection path may cause jitter and Repathing a Track segment or protection path may cause jitter and
packet misordering. For critical flows that require timely and/or packet misordering. For critical flows that require timely and/or
in-order delivery, it might be necessary to deploy the PAREO in-order delivery, it might be necessary to deploy the PAREO
functions [RAW-ARCHI] over a highly redundant Track. This functions [RAW-ARCH] over a highly redundant Track. This
specification allows to use more than one protection path for a specification allows the use of more than one protection path for a
Track, and 1+N packet redundancy. Track and 1+N packet redundancy.
This section provides the steps to ensure that no packet is lost due This section provides the steps to ensure that no packet is lost due
to the operation itself. This is ensured by installing the new to the operation itself. This is ensured by installing the new
section from its last node to the first, so when an intermediate node section from its last node to the first, so when an intermediate node
installs a route along the new section, all the downstream nodes in installs a route along the new section, all the downstream nodes in
the section have already installed their own. The disabled section the section have already installed their own. The disabled section
is removed when the packets in-flight are forwarded along the new is removed as well when the in-flight packets are forwarded along the
section as well. new section.
6.6.1. Maintaining a Track Segment 6.6.1. Maintaining a Track Segment
To modify a section of a segment between a first node and a second, To modify a section of a segment between the first node and a second
downstream node (which can be the Ingress and Egress, respectively), downstream node (which can be the Ingress and Egress, respectively)
while retaining those nodes in the segment, the Root sends an SM-VIO while retaining those nodes in the segment, the Root sends an SM-VIO
to the second node indicating the sequence of nodes in the new to the second node indicating the sequence of nodes in the new
section of the segment. The SM-VIO indicates the TrackID and the section of the segment. The SM-VIO indicates the TrackID and the
P-RouteID of the segment being updated, and a newer Segment Sequence. P-RouteID of the segment being updated and a newer Segment Sequence.
The P-DAO is propagated from the second to the first node and on the The P-DAO is propagated from the second to the first node, and on the
way, it updates the state on the nodes that are common to the old and way, it updates the state on the nodes that are common to the old and
the new section of the segment and creates a state in the new nodes. new section of the segment and creates a state in the new nodes.
When the state is updated in an intermediate node, that node might When the state is updated in an intermediate node, that node might
still receive packets that were in flight from the Ingress to self still receive packets that were in flight from the Ingress to self
over the old section of the segment. Since the remainder of the over the old section of the segment. Since the remainder of the
segment is already updated, the packets are forwarded along the new segment is already updated, the packets are forwarded along the new
version of the segment from that node on. version of the segment from that node on.
After a reasonable time to enable the deprecated sections to drain After a reasonable amount of time, the Root tears down the remaining
their traffic, the Root tears down the remaining section(s) of the section(s) of the old segments as described in Section 6.5 to enable
old segments as described in Section 6.5. the deprecated sections to drain their traffic.
6.6.2. Maintaining a protection path 6.6.2. Maintaining a Protection Path
This specification allows the Root to add protection paths to a Track This specification allows the Root to add protection paths to a Track
by sending a Non-Storing Mode P-DAO to the Ingress associated to the by sending a Non-Storing Mode P-DAO to the Ingress associated to the
same TrackID, and a new Segment ID. If the protection path is loose, same TrackID and a new Segment ID. If the protection path is loose,
then the segments that join the hops must be created first. It makes then the segments that join the hops must be created first. It makes
sense to add a new protection path before removing one that is sense to add a new protection path before removing one that is
becoming excessively lossy, and switch to the new protection path becoming excessively lossy and switch to the new protection path
before removing the old. Dropping a Track before the new one is before removing the old. Dropping a Track before the new one is
installed would reroute the traffic via the root; this may increase installed would reroute the traffic via the root; this may increase
the latency beyond acceptable thresholds, and overload the network the latency beyond acceptable thresholds and overload the network
near the root. This may also cause loops in the case of stitched near the root. This may also cause loops in the case of stitched
Tracks: the packets that cannot be injected in the second Track might Tracks: The packets that cannot be injected in the second Track might
be routed back and reinjected at the Ingress of the first. be routed back and reinjected at the Ingress of the first Track.
It is also possible to update a protection path by sending a Non- It is also possible to update a protection path by sending a Non-
Storing Mode P-DAO to the Ingress with the same Segment ID, an Storing Mode P-DAO to the Ingress with the same Segment ID, an
incremented Segment Sequence, and the new complete list of hops in incremented Segment Sequence, and the new complete list of hops in
the NSM-VIO. Updating a live protection path means changing one or the NSM-VIO. Updating a live protection path means changing one or
more of the intermediate loose hops, and involves laying out new more of the intermediate loose hops, and it involves laying out new
segments from and to the new loose hops before the NSM-VIO for the segments from and to the new loose hops before the NSM-VIO is issued
new protection path is issued. for the new protection path.
Packets that are in flight over the old version of the protection Packets that are in flight over the old version of the protection
path still follow the old source route path over the old segments. path still follow the old source route path over the old segments.
After a reasonable time to enable the deprecated segments to drain After a reasonable time, the Root tears down those segments as
their traffic, the Root tears down those segments as described in described in Section 6.5 to enable the deprecated segments to drain
Section 6.5. their traffic.
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's operations are inherited form the main All properties of a Track's operations are inherited from the main
Instance that is used to install the Track. For instance, the use of Instance that is used to install the Track. For instance, the use of
compression per [RFC8138] is determined by whether it is used in the compression per [RFC8138] is determined by whether it is used in the
RPL main DODAG, e.g., by setting the "T" flag [RFC9035] in the RPL RPL main DODAG, e.g., by setting the 'T' flag [RFC9035] in the RPL
configuration option. configuration option.
The Track Ingress that places a packet in a Track encapsulates it When the Track Ingress places a packet in a Track, it encapsulates it
with an additional IPv6 header, a Routing Header, and an IPv6 Hop-by- with an additional IPv6 header, a Routing Header, and an IPv6 Hop-by-
Hop Option Header that contains the RPL Packet Information (RPI) as Hop Option Header that contains the 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 the DODAGID for the Track, the
the first Via Address in the NSM-VIO, and the RH is a Source destination is the first Via Address in the NSM-VIO, and the RH is
Routing Header (SRH) [RFC6554] that contains the list of the an SRH [RFC6554] that contains the list of the remaining Via
remaining Via Addresses, ending with the Track Egress. Addresses, ending with the Track Egress.
* The preferred alternative in a network where 6LoWPAN Header * To compress RPL artifacts in data packets as indicated in
Compression [RFC6282] is used is to leverage "IPv6 over Low-Power [RFC8138], the preferred alternative in a network where 6LoWPAN
Wireless Personal Area Network (6LoWPAN) Paging Dispatch" header compression [RFC6282] is used is to implement "IPv6 over
[RFC8025] to compress the RPL artifacts as indicated in [RFC8138]. Low-Power Wireless Personal Area Network (6LoWPAN) Paging
Dispatch" [RFC8025].
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 ending with the (chain of) SRH-6LoRH found in the NSM-VIO, also ending with 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 a similar case in Figure 20 of
[RFC8138]. [RFC8138].
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 as follows: RPL Forwarding model as 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 MUST be placed in the outer chain
chain of IPv6 Headers. of IPv6 headers.
The RPI carries a local RPLInstanceID called the TrackID, which, The RPI carries a Local RPLInstanceID called the TrackID, which,
in association with the DODAGID, indicates the Track along which in association with the DODAGID, indicates the Track along which
the packet is forwarded. the packet is forwarded.
The D flag in the RPLInstanceID MUST be set to 0 to indicate that The D flag in the RPLInstanceID MUST be set to 0 to indicate that
the source address in the IPv6 header is set to the DODAGID (more the source address in the IPv6 header is set to the DODAGID (see
in Section 6.3). more in Section 6.3).
* This specification conforms to the principles of [RFC9008] with * This specification conforms to the principles of [RFC9008] with
regards to packet forwarding and encapsulation along a Track, as regard to packet forwarding and encapsulation along a Track as
follows: follows:
- With this specification, the Track is a RPL DODAG. From the - With this specification, the Track is a RPL DODAG. From the
perspective of that DODAG, the Track Ingress is the Root, the perspective of that DODAG, the Track Ingress is the Root, the
Track Egress is a RPL-Aware 6LR, and neighbors of the Track Track Egress is a RPL-Aware 6LR, and neighbors of the Track
Egress that can be reached via the Track, but are external to Egress that can be reached via the Track, but are external to
it, are external destinations and treated as RPL-Unaware Leaves it, are external destinations and treated as RPL-Unaware Leaves
(RULs). The encapsulation rules in [RFC9008] apply. (RULs). The encapsulation rules in [RFC9008] apply.
- If the Track Ingress is the originator of the packet and the - If the Track Ingress is the originator of the packet and the
Track Egress is the destination of the packet, there is no need Track Egress is the destination of the packet, there is no need
for an encapsulation. for an encapsulation.
- So the Track Ingress must encapsulate the traffic that it did - Thus, the Track Ingress must encapsulate the traffic that it
not originate, and it must include an RPI in the encapsulation did not originate, and it must include an RPI in the
to signal the TrackID. encapsulation to signal the TrackID.
A packet that is being routed over the RPL Instance associated to A packet that is being routed over the RPL Instance associated to
a first Non-Storing Mode Track MAY be placed recursively in a a first Non-Storing Mode Track MAY be placed recursively in a
second Track to cover one loose hop of the first Track as second Track to cover one loose hop of the first Track, as
discussed in more detail Section 3.5.2.3. On the other hand, a discussed in more detail in Section 3.5.2.3. On the other hand, a
Storing Mode segment must be strict and a packet that it placed in Storing Mode segment must be strict, and a packet that it placed
a Storing Mode segment MUST follow that segment till the segment in a Storing Mode segment MUST follow that segment till the
Egress. segment Egress.
It is known that a packet is forwarded along a Track by the source It is known that a packet is forwarded along a Track by the source
address and the RPI in the encapsulation. The Track ID is used to address and the RPI in the encapsulation. The Track ID is used to
identify the RIB entries associated to that Track, which, in identify the RIB entries associated to that Track, which, in
intermediate nodes, correspond to the P-routes for the segments of intermediate nodes, correspond to the P-Routes for the segments of
the Track that the forwarding router is aware of. The packet the Track that the forwarding router is aware of. The packet
processing uses a precedence that favors self delivery or routing processing uses a precedence that favors self-delivery or routing
header handling when one is present, then delivery to direct header handling when one is present, then delivery to direct
neighbors, then to indirect neighbors, then routing along a segment neighbors, then to indirect neighbors, then routing along a segment
along the Track, and finally as a last resort injecting the packet in along the Track, and finally as a last resort injecting the packet in
another Track. another Track.
To achieve this, the packet handling logic MUST happen in the To achieve this, the packet handling logic MUST happen in the
following order: following order:
* If the destination of the packet is self: * If the destination of the packet is self:
1. if the header chain contains a RPL Source Route Header that is 1. If the header chain contains a RPL Source Route Header that is
not fully consumed, then the packet is forwarded along the not fully consumed, then the packet is forwarded along the
Track as prescribed by [RFC6554], meaning that the next entry Track as prescribed by [RFC6554], meaning that the next entry
in the routing header becomes the destination; in the routing header becomes the destination.
2. otherwise: if the packet was encapsulated, then the packet is 2. Otherwise, if the packet was encapsulated, then the packet is
decapsulated and the forwarding process recurses; else the decapsulated and the forwarding process recurses; else, the
packet is delivered to the stack. packet is delivered to the stack.
* Otherwise, the packet is forwarded as follows: * Otherwise, the packet is forwarded as follows:
1. If the destination of the packet is a direct neighbor, e.g., 1. If the destination of the packet is a direct neighbor, e.g.,
installed by IPv6 Neighbor Discovery, then the packet MUST be installed by IPv6 Neighbor Discovery, then the packet MUST be
forwarded to that neighbor; forwarded to that neighbor.
2. Else If the destination of the packet is an indirect neighbor, 2. Else, if the destination of the packet is an indirect
e.g., installed by a multicast DAO message from a common neighbor, e.g., installed by a multicast DAO message from a
neighbor, see Section 4.1.4, then the packet MUST be forwarded common neighbor (see Section 4.1.4), then the packet MUST be
to the common neighbor; forwarded to the common neighbor.
3. Else, if there is a RIB entry for the same Track (e.g., 3. Else, if there is a RIB entry for the same Track (e.g.,
installed by an SM-VIO in a DAO message with the destination installed by an SM-VIO in a DAO message with the destination
as target), and the next hop in the RIB entry is a direct as the target) and the next hop in the RIB entry is a direct
neighbor, then the packet is passed to that neighbor; neighbor, then the packet is passed to that neighbor.
4. Else, if there is a RIB entry for the different Track (e.g., 4. Else, if there is a RIB entry for the different Track (e.g.,
installed by an NSM-VIO in a DAO message with the destination installed by an NSM-VIO in a DAO message with the destination
as target), then the packet is encapsulated to be forwarded as the target), then the packet is encapsulated to be
along that Track and the forwarding process recurses; forwarded along that Track and the forwarding process
otherwise the packet is dropped. recurses; otherwise, the packet is dropped.
5. To avoid loops, and as opposed to packets that were not 5. To avoid loops, and as opposed to packets that were not
encapsulated, a packet that was decapsulated from a Track MUST encapsulated, a packet that was decapsulated from a Track MUST
NOT be routed along the default route of the main DODAG; this NOT be routed along the default route of the main DODAG; this
would mean that the end-to-end path is uncontrolled. The node would mean that the end-to-end path is uncontrolled. The node
that discovers the fault MUST discard the packet. that discovers the fault MUST discard the packet.
The node that drops a packet for either of the reasons above MUST The node that drops a packet for either of the reasons above MUST
send an ICMPv6 Error message [RFC4443] to the Root, with a new Code send an ICMPv6 error message [RFC4443] to the Root, with the new code
"Error in P-Route" (See Section 11.15). The Root can then repair by "Error in P-Route" (see Section 11.15). The Root can then repair by
updating the broken segment and/or Tracks, and in the case of a updating the broken segment and/or Tracks, and in the case of a
broken segment, remove the leftover sections of the segment using SM- broken segment, remove the leftover sections of the segment using SM-
VIOs with a lifetime of 0 indicating the section to one or more nodes VIOs with a lifetime of 0 indicating the section to one or more nodes
being removed (See Section 6.6). being removed (see Section 6.6).
In case of a permanent forwarding error along a Source Route path, In case of a permanent forwarding error along a source route path,
the node that fails to forward SHOULD send an ICMP error with a code the node that fails to forward SHOULD send an ICMP error with the
"Error in Source Routing Header" back to the source of the packet, as code "Error in Source Routing Header" back to the source of the
described in section 11.2.2.3. of [RPL]. Upon receiving this packet, as described in Section 11.2.2.3 of [RPL]. Upon receiving
message, the encapsulating node SHOULD stop using the source route this message, the encapsulating node SHOULD stop using the source
path for a reasonable period of time which depends on the deployment, route path for a reasonable period of time, which depends on the
and it SHOULD send an ICMP message with a Code "Error in P-Route" to deployment, and it SHOULD send an ICMP message with the code "Error
the Root. Failure to follow these steps may result in packet loss in P-Route" to the Root. Failure to follow these steps may result in
and wasted resources along the source route path that is broken. packet loss and wasted resources along the source route path that is
broken.
Either way, the ICMP message MUST be throttled in case of consecutive Either way, the ICMP message MUST be throttled in case of consecutive
occurrences. It MUST be sourced at the ULA or a GUA that is used in occurrences. It MUST be sourced at the ULA or GUA that is used in
this Track for the source node, so the Root can establish where the this Track for the source node, so the Root can establish where the
error happened. error happened.
The portion of the invoking packet that is sent back in the ICMP The portion of the invoking packet that is sent back in the ICMP
message SHOULD record at least up to the RH if one is present, and message SHOULD record at least up to the RH if one is present, and
this hop of the RH SHOULD be consumed by this node so that the the hop of the RH SHOULD be consumed by this node so that the
destination in the IPv6 header is the next hop that this node could destination in the IPv6 header is the next hop that this node could
not reach. If a 6LoWPAN Routing Header (6LoRH) [RFC8138] is used to not reach. If a 6LoRH [RFC8138] is used to carry the IPv6 routing
carry the IPv6 routing information in the outer header then that information in the outer header, then the whole 6LoRH information
whole 6LoRH information SHOULD be present in the ICMP message. SHOULD be present in the ICMP message.
6.8. Compression of the RPL Artifacts 6.8. Compression of RPL Artifacts
When using [RFC8138] in the main DODAG operated in Non-Storing Mode When using [RFC8138] in the main DODAG operated in Non-Storing Mode
in a 6LoWPAN LLN, a typical packet that circulates in the main DODAG in a 6LoWPAN LLN, a typical packet that circulates in the main DODAG
is formatted as shown in Figure 20, representing the case where an is formatted as shown in Figure 20, representing the case where an
IP-in-IP encapsulation is needed (see Table 19 of [RFC9008]): IP-in-IP encapsulation is needed (see Table 19 of [RFC9008]):
+-+ ... -+- ... -+- ... -+-+- ... +-+-+-+ ... +-+-+ ... -+ ... +-... +-+ ... -+- ... -+- ... -+-+- ... +-+-+-+ ... +-+-+ ... -+ ... +-...
|11110001| SRH- | RPI- | IP-in-IP | NH=1 |11110CPP| UDP | UDP |11110001| SRH- | RPI- | IP-in-IP | NH=1 |11110CPP| UDP | UDP
| Page 1 | 6LoRH | 6LoRH | 6LoRH |LOWPAN_IPHC| UDP | hdr |Payld | Page 1 | 6LoRH | 6LoRH | 6LoRH |LOWPAN_IPHC| UDP | hdr |Payld
+-+ ... -+- ... -+- ... -+-+- ... +-+-+-+ ... +-+-+ ... -+ ... +-... +-+ ... -+- ... -+- ... -+-+- ... +-+-+-+ ... +-+-+ ... -+ ... +-...
<= RFC 6282 => <= RFC 6282 =>
<================ Inner packet ==================== = = <================ Inner packet ==================== = =
Figure 20: A Packet as Forwarded along the main DODAG Figure 20: A Packet as Forwarded Along the Main DODAG
Since there is no page switch between the encapsulated packet and the Since there is no page switch between the encapsulated packet and the
encapsulation, the first octet of the compressed packet that acts as encapsulation, the first octet of the compressed packet that acts as
page selector is actually removed at encapsulation, so the inner the page selector is actually removed at encapsulation; therefore,
packet used in the descriptions below starts with the SRH-6LoRH, and the inner packet used in the descriptions below starts with the SRH-
is exactly the packet represented in Figure 20, from the second octet 6LoRH and is exactly the packet represented in Figure 20, from the
onward. second octet onward.
When encapsulating that inner packet to place it in the Track, the When encapsulating the inner packet to place in the Track, the first
first header that the Ingress appends at the head of the inner packet header that the Ingress appends at the head of the inner packet is an
is an IP-in-IP 6LoRH Header; in that header, the encapsulator IP-in-IP 6LoRH Header; in that header, the encapsulator address,
address, which maps to the IPv6 source address in the uncompressed which maps to the IPv6 source address in the uncompressed form,
form, contains a GUA or ULA IPv6 address of the Ingress node that contains a GUA or ULA IPv6 address of the Ingress node that serves as
serves as DODAG ID for the Track, expressed in the compressed form the DODAGID for the Track, expressed in a compressed form using the
and using the DODAGID of the main DODAG as compression reference. If DODAGID of the main DODAG as a reference for the compression. If the
the address is compressed to 2 bytes, the resulting value for the address is compressed to 2 bytes, the resulting value for the Length
Length field shown in Figure 21 is 3, meaning that the SRH-6LoRH as a field (shown in Figure 21) is 3, meaning that the SRH-6LoRH as a
whole is 5-octets long. whole is 5 octets long.
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|1| Length | 6LoRH Type 6 | Hop Limit | Track DODAGID | |1|0|1| Length | 6LoRH Type 6 | Hop Limit | Track DODAGID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- ... -+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- ... -+
Figure 21: The IP-in-IP 6LoRH Header Figure 21: The IP-in-IP 6LoRH Header
At the head of the resulting sequence of bytes, the track Ingress At the head of the resulting sequence of bytes, the Track Ingress
then adds the RPI that carries the TrackID as RPLinstanceID as a P- then adds the RPI that carries the TrackID as RPLInstanceID as a P-
RPI-6LoRH Header, as illustrated in Figure 12, using the TrackID as RPI-6LoRH Header, as illustrated in Figure 12, using the TrackID as
RPLInstanceID. Combined with the IP-in-IP 6LoRH Header, this allows RPLInstanceID. Combined with the IP-in-IP 6LoRH Header, this allows
to identify the Track without ambiguity. identifying the Track without ambiguity.
The SRH-6LoRH is then added at the head of the resulting sequence of The SRH-6LoRH is then added at the head of the resulting sequence of
bytes as a verbatim copy of the content of the SR-VIO that signaled bytes as a verbatim copy of the content of the SM-VIO that signaled
the selected protection path. the selected protection path.
0 1 0 1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 .. .. .. 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 .. .. ..
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- -+- -+ ... +- -+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- -+- -+ ... +- -+
|1|0|0| Size |6LoRH Type 0..4| Hop1 | Hop2 | | HopN | |1|0|0| Size |6LoRH Type 0..4| Hop1 | Hop2 | | HopN |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- -+- -+ ... +- -+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- -+- -+ ... +- -+
Where N = Size + 1 Where N = Size + 1
Figure 22: The SRH 6LoRH Header Figure 22: The SRH-6LoRH Header
The format of the resulting encapsulated packet in [RFC8138] The format of the resulting encapsulated packet, which is in
compressed form is illustrated in Figure 23: compressed form per [RFC8138], is illustrated in Figure 23:
+-+ ... -+-+-+- ... -+-+-+- ... -+-+-+-+-+- ... +-+-+-+-+-+-+- ... +-+ ... -+-+-+- ... -+-+-+- ... -+-+-+-+-+- ... +-+-+-+-+-+-+- ...
| Page 1 | SRH-6LoRH | P-RPI-6LoRH | IP-in-IP 6LoRH | Inner Packet | Page 1 | SRH-6LoRH | P-RPI-6LoRH | IP-in-IP 6LoRH | Inner Packet
+-+ ... -+-+-+- ... -+-+-+- ... -+-+-+-+-+- ... +-+-+-+-+-+-+- ... +-+ ... -+-+-+- ... -+-+-+- ... -+-+-+-+-+- ... +-+-+-+-+-+-+- ...
Signals : Loose Hops : TrackID : Track DODAGID : Signals : Loose Hops : TrackID : Track DODAGID :
Figure 23: A Packet as Forwarded along a Track Figure 23: A Packet as Forwarded Along a Track
7. Less-Constrained Variations 7. Less-Constrained Variations
7.1. Storing Mode main DODAG 7.1. Storing Mode Main DODAG
This specification expects that the main DODAG is operated in Non- This specification expects that the main DODAG is operated in Non-
Storing Mode. The reasons for that limitation are mostly related to Storing Mode. The reasons for that limitation are mostly related to
LLN operations, power and spectrum conservation: LLN operations, power, and spectrum conservation:
* In Non-Storing Mode, the Root already knowns the DODAG topology, * In Non-Storing Mode, the Root already knows the DODAG topology, so
so the additional topological information is reduced to the the additional topological information is reduced to the siblings.
siblings.
* The downward routes are updated with unicast messages to the Root, * The downward routes are updated with unicast messages to the Root,
which ensures that the Root can reach back to the LLN nodes after which ensures that the Root can reach back to the LLN nodes after
a repair faster than in the case of Storing Mode. Also the Root a repair faster than in the case of Storing Mode. Also, the Root
can control the use of the path diversity in the DODAG to reach can control the use of path diversity in the DODAG to reach the
the LLN nodes. For both reasons, Non-Storing Mode provides better LLN nodes. For both reasons, Non-Storing Mode provides better
capabilities for the Root to maintain the P-Routes. capabilities for the Root to maintain the P-Routes.
* When the main DODAG is operated in Non-Storing Mode, P-Routes * When the main DODAG is operated in Non-Storing Mode, P-Routes
enable loose Source Routing, which is only an advantage in that enable loose source routing, which is only an advantage in that
mode. Storing Mode does not use Source Routing Headers, and does mode. Storing Mode does not use Source Routing Headers and does
not derive the same benefits from this capability. not derive the same benefits from this capability.
On the other hand, since RPL is a Layer-3 routing protocol, its On the other hand, since RPL is a Layer 3 routing protocol, its
applicability extends beyond LLNs to a generic IP network. RPL applicability extends beyond LLNs to a generic IP network. RPL
requires less resources than alternative IGPs like OSPF, ISIS, EIGRP, requires fewer resources than alternative IGPs such as OSPF, IS-IS,
BABEL or RIP at the expense of a route stretch vs. the shortest path the Enhanced Interior Gateway Routing Protocol (EIGRP), BABEL, or RIP
routes to a destination that those protocols compute. P-Routes add at the expense of a route stretch versus the shortest path routes to
the capability to install shortest and/or constrained routes to a destination that those protocols compute. P-Routes add the
special destinations such as discussed in section A.9.4. of the ANIMA capability to install the shortest and/or constrained routes to
ACP [RFC8994]. special destinations as discussed in Appendix A.9.4 of the ANIMA ACP
[RFC8994].
In a powered and wired network, when enough memory to store the In a powered and wired network, when enough memory to store the
needed routes is available, the RPL Storing Mode proposes a better needed routes is available, the RPL Storing Mode proposes a better
trade-off than the Non-Storing, as it reduces the route stretch and trade-off than the Non-Storing Mode, as it reduces the route stretch
lowers the load on the Root. In that case, the control path between and lowers the load on the Root. In that case, the control path
the Root and the RPL nodes can be maintained more aggressively and between the Root and the RPL nodes can be maintained more
with more redundancy than in LLNs, and the nodes can be reached to aggressively and with more redundancy than in LLNs, and the nodes can
maintain the P-Routes at most times for a finer and more reactive be reached to maintain the P-Routes at most times for a finer and
control. more reactive control.
This section specifies the additions that are needed to support This section specifies the additions that are needed to support
Projected Routes when the main DODAG is operated in Storing Mode. As P-Routes when the main DODAG is operated in Storing Mode. As long as
long as the RPI can be processed adequately by the dataplane, the the RPI can be processed adequately by the data plane, the changes in
changes to this specification are limited to the DAO message. The this specification are limited to the DAO message. The Track
Track structure, routes and forwarding operations remain the same. structure, routes, and forwarding operations remain the same. Since
Since there is no capability negotiation, the expectation is that all there is no capability negotiation, the expectation is that all the
the nodes in the network support this specification in the same nodes in the network support this specification in the same fashion
fashion, or are configured the same way through management. or are configured the same way through management.
In Storing Mode, the Root misses the Child to Parent relationship In Storing Mode, the Root misses the Child-to-Parent relationship
that forms the main DODAG, as well as the sibling information. To that forms the main DODAG as well as the sibling information. To
provide that knowledge the nodes in the network MUST send additional provide that knowledge, the nodes in the network MUST send additional
DAO messages that are unicast to the Root just like Non-Storing DAO DAO messages that are unicast to the Root just like Non-Storing DAO
messages are. messages are.
In the DAO message, the originating router advertises a set of In the DAO message, the originating router advertises a set of
neighbor nodes using Sibling Information Options (SIO)s, regardless neighbor nodes using SIOs, regardless of the relative position in the
of the relative position in the DODAG of the advertised node vs. this DODAG of the advertised node versus this router.
router.
The DAO message MUST be formed as follows: The DAO message MUST be formed as follows:
* The originating router is identified by the source address of the * The originating router is identified by the source address of the
DAO. That address MUST be the one that this router registers to DAO. That address MUST be the one that this router registers to
neighbor routers so the Root can correlate the DAOs from those the neighbor routers so the Root can correlate the DAOs from those
routers when they advertise this router as their neighbor. The routers when they advertise this router as their neighbor. The
DAO contains one or more sequences of one Transit Information DAO contains one or more sequences of one TIO and one or more
Option and one or more Sibling Information Options. There is no SIOs. There is no RPL Target Option so that the Root is not
RPL Target Option so the Root is not confused into adding a confused into adding a Storing Mode route to the Target.
Storing Mode route to the Target.
* The TIO is formed as in Storing Mode, and the Parent Address is * The TIO is formed as in Storing Mode, and the Parent Address is
not present. The Path Sequence and Path Lifetime fields are not present. The Path Sequence and Path Lifetime fields are
aligned with the values used in the Address Registration of the aligned with the values used in the Address Registration of the
node(s) advertised in the SIO, as explained in Section 9.1. of node(s) advertised in the SIO, as explained in Section 9.1 of
[RFC9010]. Having similar values in all nodes allows factorising [RFC9010]. Having similar values in all nodes allows factorizing
the TIO for multiple SIOs as done with [RPL]. the TIO for multiple SIOs as done in [RPL].
* The TIO is followed by one or more SIOs that provide an address * The TIO is followed by one or more SIOs that provide an address
(ULA or GUA) of the advertised neighbor node. (ULA or GUA) of the advertised neighbor node.
But the RPL routing information headers may not be supported on all However, the RPL routing information headers may not be supported on
type of routed network infrastructures, especially not in high-speed all types of routed network infrastructures, especially not in high-
routers. When the RPI is not supported in the dataplane, there speed routers. When the RPI is not supported in the data plane,
cannot be local RPL Instances and RPL can only operate as a single there cannot be Local RPL Instances and RPL can only operate as a
topology (the main DODAG). The RPL Instance is that of the main single topology (the main DODAG). The RPL Instance is that of the
DODAG and the Ingress node that encapsulates is not the Root. The main DODAG, and the Ingress node that encapsulates is not the Root.
routes along the Tracks are alternate routes to those available along The routes along the Tracks are alternate routes to those available
the main DODAG. They MAY conflict with routes to children and MUST along the main DODAG. They MAY conflict with routes to children and
take precedence in the routing table. The Targets MUST be adjacent MUST take precedence in the routing table. The Targets MUST be
to the Track Egress to avoid loops that may form if the packet is adjacent to the Track Egress to avoid loops that may form if the
reinjected in the main DODAG. packet is reinjected in the main DODAG.
7.2. A Track as a Full DODAG 7.2. A Track as a Full DODAG
This specification builds Tracks with parallel or interleaved This specification builds Tracks with parallel or interleaved
protection paths as opposed to a more complex DODAG with protection paths as opposed to a more complex DODAG with
interconnections at any place desirable. The reason for that interconnections at any place desirable. The reason for that
limitation is related to constrained node operations, and the limitation is related to constrained node operations and the
capability to store large amount of topological information and capability to store a large amount of topological information and
compute complex paths: compute complex paths:
* With this specification, the node in the LLN has no topological * With this specification, the node in the LLN has no topological
awareness, and does not need to maintain dynamic information about awareness and does not need to maintain dynamic information about
the link quality and availability. the link quality and availability.
* The Root has a complete topological information and statistical * The Root has 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
of all Tracks in its DODAG. Based on that information, the Root optimization of all Tracks in its DODAG. Based on that
computes the protection path and produces the source route paths. information, the Root computes the protection path and produces
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 RAW Architecture [RAW-ARCHI] actually expects the PLR at the The RAW architecture [RAW-ARCH] actually expects the PLR at the Track
Track Ingress to react to changes in the forwarding conditions along Ingress to react to changes in the forwarding conditions along the
the Track, and reroute packets to maintain the required degree of Track and reroute packets to maintain the required degree of
reliability. To achieve this, the PLR needs the full richness of a reliability. To achieve this, the PLR needs the full richness of a
DODAG to form any path that could meet the Service Level Objective DODAG to form any path that could meet the SLO.
(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 PLR uses are of an order expectation is that the metrics that the PLR 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 timescale
between routing and forwarding, more in [RAW-ARCHI]. It follows that between routing and forwarding; see more in [RAW-ARCH]. It follows
the PLR will learn the metrics it needs from an alternate source, that the PLR will learn the metrics it needs from an alternate
e.g., OAM frames. source, e.g., OAM frames.
To pass the topological information to the Ingress, the Root uses a To pass the topological information to the Ingress, the Root uses a
P-DAO messages that contains sequences of Target and Transit P-DAO message that contains sequences of Targets and TIOs that
Information options that collectively represent the Track, expressed collectively represent the Track, expressed in the same fashion as in
in the same fashion as in classical Non-Storing Mode. The difference classical Non-Storing Mode. The difference is that the Root is the
is that the Root is the source as opposed to the destination, and can source as opposed to the destination, and the Root can report
report information on many Targets, possibly the full Track, with one information on many Targets, possibly the full Track, with one 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 tuples in the P-DAO the Root and that the Target/Transit information tuples in the P-DAO
are not those received by the Root in the DAO messages about the said are not those received by the Root in the DAO messages about the said
Targets. The Track may follow sibling routes and does not need to be Targets. The Track may follow sibling routes and does not need to be
congruent with the main DODAG. congruent with the main DODAG.
8. Profiles 8. Profiles
This document provides a set of tools that may or may not be needed This document provides a set of tools that may or may not be needed
by an implementation depending on the type of application it serves. by an implementation depending on the type of application it serves.
This section describes profiles that can be implemented separately This section describes profiles that can be implemented separately
and can be used to discriminate what an implementation can and cannot and can be used to discriminate what an implementation can and cannot
do. This section describes profiles that enable implementing only a do. This section describes profiles that enable implementing 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 Instance and do not require the Profiles 0 to 2 operate in the main Instance and do not require the
support of local RPL Instances or the indication of the RPL Instance support of Local RPL Instances or the indication of the RPL Instance
in the data plane. Profile 3 and above leverage Local RPL Instances in the data plane. Profile 3 and above leverage Local RPL Instances
to build arbitrary Tracks Rooted at the Track Ingress and using its to build arbitrary Tracks rooted at the Track Ingress and using its
namespace for TrackID. namespace for the 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; Profile 1 leverages Storing Mode to reduce the size of the in LLNs; Profile 1 leverages Storing Mode to reduce the size of the
Source Route Header in the most common LLN deployments. Profile 2 is Source Route Header in the most common LLN deployments. Profile 2 is
RECOMMENDED in high speed / wired environment to enable traffic RECOMMENDED in a high-speed or wired environment to enable Traffic
Engineering and network automation. All the other profile / Engineering and network automation. All the other profile/
environment combinations are OPTIONAL. environment combinations are OPTIONAL.
Profile 0 Profile 0 is the Legacy support of [RPL] Non-Storing Mode, Profile 0:
with default routing Northwards (up) and strict source routing Profile 0 is the legacy support of [RPL] Non-Storing Mode, with
default routing Northwards (up) and strict source routing
Southwards (down the main DODAG). It provides the minimal common Southwards (down the main DODAG). It provides the minimal common
functionality that must be implemented as a prerequisite to all functionality that must be implemented as a prerequisite to all
the Track-supporting profiles. The other Profiles extend Profile the Track-supporting profiles. The other profiles extend Profile
0 with selected capabilities that this specification introduces on 0 with selected capabilities that this specification introduces on
top. top.
Profile 1 (Storing Mode P-Route segments along the main DODAG) Profile 1 (Storing Mode P-Route segments along the main DODAG):
Profile 1 does not create new paths; compared to Profile 0, it Profile 1 does not create new paths; compared to Profile 0, it
combines Storing and Non-Storing Modes to balance the size of the combines Storing and Non-Storing Modes to balance the size of the
Routing Header in the packet and the amount of state in the Routing Header in the packet and the amount of state in the
intermediate routers in a Non-Storing Mode RPL DODAG. intermediate routers in a Non-Storing Mode RPL DODAG.
Profile 2 (Non-Storing Mode P-Route segments along the main DODAG) Profile 2 (Non-Storing Mode P-Route segments along the main
Profile 2 extends Profile 0 with Strict Source-Routing Non-Storing DODAG):
Profile 2 extends Profile 0 with strict source routing Non-Storing
Mode P-Routes along the main DODAG, which is the same as Profile 1 Mode P-Routes along the main DODAG, which is the same as Profile 1
but using NSM VIOs as opposed to SM VIOs. Profile 2 provides the but using NSM-VIOs as opposed to SM-VIOs. Profile 2 provides the
same capability to compress the SRH in packets down the main DODAG same capability to compress the SRH in packets down the main DODAG
as Profile 1, but it requires an encapsulation, in order to insert as Profile 1, but it requires an encapsulation in order to insert
an additional SRH between the loose source routing hops. In that an additional SRH between the loose source routing hops. With
case, the Tracks MUST be installed as subTracks of the main DODAG, Profile 2, the Tracks MUST be installed as subTracks of the main
the main Instance MUST be used as TrackID. Note that the Ingress DODAG, and the main Instance MUST be used as the TrackID. Note
node encapsulates but is not the Root, as it does not own the that the Ingress node encapsulates but is not the Root, as it does
DODAGID. not own the DODAGID.
Profile 3 In order to form the best path possible, this Profile Profile 3:
requires the support of Sibling Information Option to inform the In order to form the best path possible, this profile requires the
Root of additional possible hops. Profile 3 extends Profile 1 support of an SIO to inform the Root of additional possible hops.
with additional Storing Mode P-Routes that install segments that Profile 3 extends Profile 1 with additional Storing Mode P-Routes
do not follow the main DODAG. If the segment Ingress (in the SM- that install segments that do not follow the main DODAG. If the
VIO) is the same as the IPv6 Address of the Track Ingress (in the segment Ingress (in the SM-VIO) is the same as the IPv6 address of
projected DAO base Object), the P-DAO creates an implicit Track the Track Ingress (in the Projected DAO Base Object), the P-DAO
between the segment Ingress and the segment Egress. creates an implicit Track between the segment Ingress and the
segment Egress.
Profile 4 Profile 4 extends Profile 2 with Strict Source-Routing Profile 4:
Non-Storing Mode P-Routes to form forward Tracks that are inside Profile 4 extends Profile 2 with strict source routing Non-Storing
the main DODAG but do not necessarily follow it. A Track is Mode P-Routes to form forward Tracks that are inside the main
formed as one or more strict source routed paths between the Root DODAG but do not necessarily follow it. A Track is formed as one
that is the Track Ingress, and the Track Egress that is the last or more strict source-routed paths between the Root that is the
node. Track Ingress and the Track Egress that is the last node.
Profile 5 Profile 5 Combines Profile 4 with Profile 1 and enables Profile 5:
loose source routing between the Ingress and the Egress of the Profile 5 combines Profile 4 with Profile 1 and enables loose
Track. As in Profile 1, Storing Mode P-Routes form the source routing between the Ingress and the Egress of the Track.
connections in the loose source route. As in Profile 1, Storing Mode P-Routes form the connections in the
loose source route.
Profile 6 Profile 6 Combines Profile 4 with Profile 2 and also Profile 6:
enables loose source routing between the Ingress and the Egress of Profile 6 combines Profile 4 with Profile 2 and enables loose
the Track. source routing between the Ingress and the Egress of the Track.
Profile 7 Profile 7 implements Profile 5 in a main DODAG that is Profile 7:
operated in Storing Mode as presented in Section 7.1. As in Profile 7 implements Profile 5 in a main DODAG that is operated in
Profile 1 and 2, the TrackID is the RPLInstanceID of the main Storing Mode as presented in Section 7.1. As in Profiles 1 and 2,
DODAG. Longest match rules decide whether a packet is sent along the TrackID is the RPLInstanceID of the main DODAG. Longest match
the main DODAG or rerouted in a track. rules decide whether a packet is sent along the main DODAG or
rerouted in a Track.
Profile 8 Profile 8 is offered in preparation of the RAW work, and Profile 8:
for use cases where an arbitrary node in the network can afford Profile 8 is offered in preparation of the RAW work and for use
the same code complexity as the RPL Root in a traditional cases where an arbitrary node in the network can afford the same
deployment. It offers a full DODAG visibility to the Track code complexity as the RPL Root in a traditional deployment. It
Ingress as specified in Section 7.2 in a Non-Storing Mode main offers a full DODAG visibility to the Track Ingress, as specified
DODAG. in Section 7.2, in a Non-Storing Mode main DODAG.
Profile 9 Profile 9 combines profiles 7 and 8, operating the Track Profile 9:
as a full DODAG within a Storing Mode main DODAG, using only the Profile 9 combines Profiles 7 and 8, operating the Track as a full
main DODAG RPLInstanceID as TrackID. DODAG within a Storing Mode main DODAG, using only the main DODAG
RPLInstanceID as the TrackID.
9. Backwards Compatibility 9. Backwards Compatibility
This specification can operate in a mixed network where some nodes This specification can operate in a mixed network where some nodes
support it and some do not. There are restrictions, though. All support it and some do not. There are restrictions, though. All
nodes that need to process a P-DAO MUST support this specification. nodes that need to process a P-DAO MUST support this specification.
As discussed in Section 3.7.1, how the root knows the node As discussed in Section 3.7.1, how the root knows the node
capabilities and whether they support this specification is out of capabilities and whether they support this specification are out of
scope. scope.
This specification defines the 'D' flag in the RPL DODAG This specification defines the 'D' flag in the RPL DODAG
Configuration Option (see Section 4.1.7) to signal that the RPL nodes Configuration option (see Section 4.1.7) to signal that the RPL nodes
can request the creation of Tracks. The requester may not know can request the creation of Tracks. The requester may not know
whether the Track can effectively be constructed, and whether enough whether the Track can effectively be constructed or whether enough
nodes along the preferred paths support this specification. nodes along the preferred paths support this specification.
Therefore, it makes sense to only set the 'D' flags in the DIO when Therefore, it makes sense to only set the 'D' flags in the DIO when
the conditions of success are in place, in particular when all the the conditions for success are in place, in particular when all the
nodes that could be on the path of tracks are upgraded. nodes that could be on the path of the Tracks are upgraded.
10. Security Considerations 10. Security Considerations
It is worth noting that with [RPL], every node in the LLN is RPL- It is worth noting that per [RPL], every node in the LLN is RPL-aware
aware and can inject any RPL-based attack in the network. This and can inject any RPL-based attack in the network. This
specification uses messages that are already present in RPL [RPL] specification uses messages that are already present in RPL [RPL]
with optional secured versions. The same secured versions may be with optional secured versions. The same secured versions may be
used with this specification, and whatever security is deployed for a used with this specification, and whatever security is deployed for a
given network also applies to the flows in this specification. given network also applies to the flows in this specification.
The LLN nodes depend on the RPL Root and the RANs for their The LLN nodes depend on the RPL Root and RANs for their operation. A
operation. A trust model is necessary to ensure that the right trust model is necessary to ensure that the right devices are acting
devices are acting in these roles, avoiding sinkhole attacks (as is in these roles, avoiding sinkhole attacks (as is done in Section 7 of
done in [RFC7416] section 7). This trust model could be at a minimum [RFC7416]). This trust model could be, at a minimum, based on a
based on a Layer-2 Secure joining and the Link-Layer security. This Layer 2 secure joining and link-layer security. This is a generic
is a generic 6LoWPAN requirement, see Req5.1 in Appendix B.5 of 6LoWPAN requirement; see Req-5.1 in Appendix B.5 of [RFC8505].
[RFC8505].
In a general manner, the Security Considerations in [RPL], and In a general manner, the Security Considerations in [RPL] and
[RFC7416] apply to this specification as well. The Link-Layer [RFC7416] apply to this specification as well. In particular, link-
security is needed in particular to prevent Denial-Of-Service attacks layer security is needed to prevent denial-of-service attacks,
whereby a rogue router creates a high churn in the RPL network by whereby a rogue router creates a high churn in the RPL network by
constantly injecting forged P-DAO messages and using up all the constantly injecting forged P-DAO messages and using up all the
available storage in the attacked routers. available storage in the attacked routers.
When applied to radio LLNs such as IEEE std 802.15.4, the lower-layer When applied to radio LLNs such as IEEE Std 802.15.4, the lower-layer
frame protection can be leveraged with an appropriate join protocol. frame protection can be leveraged with an appropriate join protocol.
6TiSCH defined [RFC9031] with the RPL Root acting as 6LBR. The join 6TiSCH defined [RFC9031] with the RPL Root acting as 6LBR. The join
protocol could be extended to provide additional key material for protocol could be extended to provide additional key material for
pledge to 6LBR communication when additional end-to-end security is pledges to 6LBR communication when additional end-to-end security is
desired beyond the hop-by-hop security from the lower layer. desired beyond the hop-by-hop security from the lower layer.
With this specification, the Root MAY generate P-DAO messages but With this specification, the Root MAY generate P-DAO messages but
other nodes MUST NOT do so. PDR messages MUST be sent to the Root. other nodes MUST NOT do so. PDR messages MUST be sent to the Root.
This specification expects that the communication with the Root is This specification expects that the communication with the Root is
authenticated but does not enforce which method is used. authenticated but does not 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 that 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 rapidly deplete critical resources such
spectrum and battery in the LLN rapidly. as the spectrum and battery in the LLN.
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 has assigned a flag in the "DODAG Configuration Option Flags for
Option Flags for MOP 0..6" [RFC9010] registry under the heading MOP 0..6" registry [RFC9008] under the "Routing Protocol for Low
"Routing Protocol for Low Power and Lossy Networks (RPL)" [IANA-RPL] Power and Lossy Networks (RPL)" registry group [IANA-RPL] as follows:
as follows:
+---------------+------------------------------+-----------+ +============+==============================+===========+
| Bit Number | Capability Description | Reference | | Bit Number | Capability Description | Reference |
+---------------+------------------------------+-----------+ +============+==============================+===========+
| 0 (suggested) | Projected Routes Support (D) | THIS RFC | | 0 | Projected Routes Support (D) | RFC 9914 |
+---------------+------------------------------+-----------+ +------------+------------------------------+-----------+
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 has added this RFC as an additional reference for MOP 7 in the
Mode of Operation registry that is part of the Routing Protocol for "Mode of Operation" registry under the "Routing Protocol for Low
Low Power and Lossy Networks (RPL) registry group [IANA-RPL]. Power and Lossy Networks (RPL)" registry group [IANA-RPL].
11.2. Elective 6LoWPAN Routing Header Type 11.2. Elective 6LoWPAN Routing Header Type
IANA is requested to update the "Elective 6LoWPAN Routing Header IANA has updated the "Elective 6LoWPAN Routing Header Type" registry
Type" registry that was created for [RFC8138] under the heading [RFC8138] under the "IPv6 Low Power Personal Area Network Parameters"
"Elective 6LoWPAN Routing Header Type" in the "IPv6 Low Power registry group [IANA-6LO] as follows:
Personal Area Network Parameters" registry group [IANA-6LO] and
assign the following value:
+===============+=============+===========+ +=======+=============+===========+
| Value | Description | Reference | | Value | Description | Reference |
+===============+=============+===========+ +=======+=============+===========+
| 8 (Suggested) | P-RPI-6LoRH | THIS RFC | | 8 | P-RPI-6LoRH | RFC 9914 |
+---------------+-------------+-----------+ +-------+-------------+-----------+
Table 22: New Elective 6LoWPAN Routing Table 22: New Elective 6LoWPAN
Header Type Routing Header Type
11.3. Critical 6LoWPAN Routing Header Type 11.3. Critical 6LoWPAN Routing Header Type
IANA is requested to update the "Critical 6LoWPAN Routing Header IANA has updated the "Critical 6LoWPAN Routing Header Type" registry
Type" registry that was created for [RFC8138] under the heading [RFC8138] under the "IPv6 Low Power Personal Area Network Parameters"
"Critical 6LoWPAN Routing Header Type" in the "IPv6 Low Power registry group [IANA-6LO] as follows:
Personal Area Network Parameters" registry group [IANA-6LO] and
assign the following value:
+===============+=============+===========+ +=======+=============+===========+
| Value | Description | Reference | | Value | Description | Reference |
+===============+=============+===========+ +=======+=============+===========+
| 8 (Suggested) | P-RPI-6LoRH | THIS RFC | | 8 | P-RPI-6LoRH | RFC 9914 |
+---------------+-------------+-----------+ +-------+-------------+-----------+
Table 23: New Critical 6LoWPAN Routing Table 23: New Critical 6LoWPAN
Header Type Routing Header Type
11.4. Registry For The RPL Option Flags 11.4. Registry for RPL Option Flags
IANA is requested to create a registry for the 8-bit "RPL Option IANA has created the "RPL Option Flags" registry, for the 8-bit RPL
Flags" field, as detailed in Figure 11, under the heading "Routing Option flags field as detailed in Figure 11, under the "Routing
Protocol for Low Power and Lossy Networks (RPL)" [IANA-RPL]. The Protocol for Low Power and Lossy Networks (RPL)" registry group
bits are indexed from 0 (leftmost) to 7. Each bit is tracked with [IANA-RPL]. The bits are indexed from 0 (leftmost) to 7. Each bit
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)
* Indication When Set * Indication when set
* Reference * Reference
Registration procedure is "Standards Action" [RFC8126]. The initial
allocation is as indicated in Table 24:
+===============+======================+===========+ The registration procedure is Standards Action [RFC8126]. The
| Bit number | Indication When Set | Reference | initial allocation is as indicated in Table 24:
+===============+======================+===========+
| 0 | Down 'O' | [RFC6553] |
+---------------+----------------------+-----------+
| 1 | Rank-Error (R) | [RFC6553] |
+---------------+----------------------+-----------+
| 2 | Forwarding-Error (F) | [RFC6553] |
+---------------+----------------------+-----------+
| 3 (Suggested) | Projected-Route (P) | THIS RFC |
+---------------+----------------------+-----------+
| 4..255 | Unassigned | |
+---------------+----------------------+-----------+
Table 24: Initial PDR Flags +============+======================+===========+
| Bit Number | Indication When Set | Reference |
+============+======================+===========+
| 0 | Down (O) | [RFC6553] |
+------------+----------------------+-----------+
| 1 | Rank-Error (R) | [RFC6553] |
+------------+----------------------+-----------+
| 2 | Forwarding-Error (F) | [RFC6553] |
+------------+----------------------+-----------+
| 3 | Projected-Route (P) | RFC 9914 |
+------------+----------------------+-----------+
| 4..255 | Unassigned | |
+------------+----------------------+-----------+
Table 24: Initial PDR Flags
11.5. RPL Control Codes 11.5. RPL Control Codes
IANA is requested to update the "RPL Control Codes" registry under IANA has updated the "RPL Control Codes" registry under the "Routing
the heading "Routing Protocol for Low Power and Lossy Networks (RPL)" Protocol for Low Power and Lossy Networks (RPL)" registry group
[IANA-RPL] as indicated in Table 25: [IANA-RPL] as indicated in Table 25:
+==================+=============================+===========+ +======+=============================+===========+
| Code | Description | Reference | | Code | Description | Reference |
+==================+=============================+===========+ +======+=============================+===========+
| 0x09 (Suggested) | Projected DAO Request (PDR) | THIS RFC | | 0x09 | Projected DAO Request (PDR) | RFC 9914 |
+------------------+-----------------------------+-----------+ +------+-----------------------------+-----------+
| 0x0A (Suggested) | PDR-ACK | THIS RFC | | 0x0A | PDR-ACK | RFC 9914 |
+------------------+-----------------------------+-----------+ +------+-----------------------------+-----------+
Table 25: New RPL Control Codes Table 25: New RPL Control Codes
11.6. RPL Control Message Options 11.6. RPL Control Message Options
IANA is requested to update the "RPL Control Message Options" IANA has updated the "RPL Control Message Options" registry under the
registry under the heading "Routing Protocol for Low Power and Lossy "Routing Protocol for Low Power and Lossy Networks (RPL)" registry
Networks (RPL)" [IANA-RPL] as indicated in Table 26: group [IANA-RPL] as indicated in Table 26:
+==================+=============================+===========+ +=======+==================================+===========+
| Value | Meaning | Reference | | Value | Meaning | Reference |
+==================+=============================+===========+ +=======+==================================+===========+
| 0x0E (Suggested) | Stateful VIO (SM-VIO) | THIS RFC | | 0x0F | Stateful VIO (SM-VIO) | RFC 9914 |
+------------------+-----------------------------+-----------+ +-------+----------------------------------+-----------+
| 0x0F (Suggested) | Source-Routed VIO (NSM-VIO) | THIS RFC | | 0x10 | Source-Routed VIO (NSM-VIO) | RFC 9914 |
+------------------+-----------------------------+-----------+ +-------+----------------------------------+-----------+
| 0x10 (Suggested) | Sibling Information option | THIS RFC | | 0x11 | Sibling Information Option (SIO) | RFC 9914 |
+------------------+-----------------------------+-----------+ +-------+----------------------------------+-----------+
Table 26: RPL Control Message Options Table 26: RPL Control Message Options
11.7. SubRegistry for the Projected DAO Request Flags 11.7. Registry for Projected DAO Request Flags
IANA is requested to create a registry for the 8-bit "Projected DAO IANA has created the "Projected DAO Request (PDR) Flags" registry
Request (PDR)" field under the heading "Routing Protocol for Low under the "Routing Protocol for Low Power and Lossy Networks (RPL)"
Power and Lossy Networks (RPL)" [IANA-RPL]. The bits are indexed registry group [IANA-RPL]. The bits are indexed from 0 (leftmost) to
from 0 (leftmost) to 7. Each bit is tracked with the following 7. 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 The registration procedure is Standards Action [RFC8126]. The
allocation is as indicated in Table 27: initial allocation is as indicated in Table 27:
+============+========================================+===========+ +============+========================================+===========+
| Bit number | Capability description | Reference | | Bit Number | Capability Description | Reference |
+============+========================================+===========+ +============+========================================+===========+
| 0 | PDR-ACK request (K) | THIS RFC | | 0 | PDR-ACK request (K) | RFC 9914 |
+------------+----------------------------------------+-----------+ +------------+----------------------------------------+-----------+
| 1 | Requested path should be redundant (R) | THIS RFC | | 1 | Requested path should be redundant (R) | RFC 9914 |
+------------+----------------------------------------+-----------+ +------------+----------------------------------------+-----------+
| 2..255 | Unassigned | | | 2..255 | Unassigned | |
+------------+----------------------------------------+-----------+ +------------+----------------------------------------+-----------+
Table 27: Initial PDR Flags Table 27: Initial PDR Flags
11.8. SubRegistry for the PDR-ACK Flags 11.8. Registry for PDR-ACK Flags
IANA is requested to create a registry for the 8-bit "PDR-ACK Flags" IANA has created the "PDR-ACK Flags" registry under the "Routing
field under the heading "Routing Protocol for Low Power and Lossy Protocol for Low Power and Lossy Networks (RPL)" registry group
Networks (RPL)" [IANA-RPL]. The bits are indexed from 0 (leftmost) [IANA-RPL]. The bits are indexed from 0 (leftmost) to 7. Each bit
to 7. 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
* Reference * Reference
Registration procedure is "Standards Action" [RFC8126]. No bit is The registration procedure is Standards Action [RFC8126]. At the
currently assigned for the PDR-ACK Flags. time of publication of this document, no bit has been assigned in
this registry.
11.9. Registry for the PDR-ACK Acceptance Status Values 11.9. Registry for PDR-ACK Acceptance Status Values
IANA is requested to create a registry for the 8-bit "PDR-ACK IANA has created the "PDR-ACK Acceptance Status Values" registry
Acceptance Status Values" under the heading "Routing Protocol for Low under the "Routing Protocol for Low Power and Lossy Networks (RPL)"
Power and Lossy Networks (RPL)" [IANA-RPL]. Each value is tracked registry group [IANA-RPL]. Each value is tracked with the following
with the following qualities: qualities:
* Value * Value
* Meaning * Meaning
* Reference * Reference
the possible values are expressed as a 6-bit unsigned integer The possible values are expressed as a 6-bit unsigned integer
(0..63). the registration procedure is "Standards Action" [RFC8126]. (0..63). The registration procedure is Standards Action [RFC8126].
The initial allocation is as indicated in Table 28:
The (suggested) initial allocation is as indicated in Table 28:
+-------+------------------------+-----------+ +=======+========================+===========+
| Value | Meaning | Reference | | Value | Meaning | Reference |
+-------+------------------------+-----------+ +=======+========================+===========+
| 0 | Unqualified Acceptance | THIS RFC | | 0 | Unqualified Acceptance | RFC 9914 |
+-------+------------------------+-----------+ +-------+------------------------+-----------+
| 1..63 | Unassigned | | | 1..63 | Unassigned | |
+-------+------------------------+-----------+ +-------+------------------------+-----------+
Table 28: Acceptance values of the PDR-ACK Table 28: Acceptance Values of the PDR-ACK
Status Status
11.10. Registry for the PDR-ACK Rejection Status Values 11.10. Registry for PDR-ACK Rejection Status Values
IANA is requested to create a registry for the 6-bit "PDR-ACK IANA has created the "PDR-ACK Rejection Status Values" registry under
Rejection Status Values" under the heading "Routing Protocol for Low the "Routing Protocol for Low Power and Lossy Networks (RPL)"
Power and Lossy Networks (RPL)" [IANA-RPL]. Each value is tracked registry group [IANA-RPL]. Each value is tracked with the following
with the following qualities: qualities:
* Value * Value
* Meaning * Meaning
* Reference
the possible values are expressed as a 6-bit unsigned integer * Reference
(0..63). the registration procedure is "Standards Action" [RFC8126].
The (suggected) initial allocation is as indicated in Table 29: The possible values are expressed as a 6-bit unsigned integer
(0..63). The registration procedure is Standards Action [RFC8126].
The initial allocation is as indicated in Table 29:
+-------+-----------------------+-----------+ +=======+=======================+===========+
| Value | Meaning | Reference | | Value | Meaning | Reference |
+=======+=======================+===========+
| 0 | Unqualified Rejection | RFC 9914 |
+-------+-----------------------+-----------+ +-------+-----------------------+-----------+
| 0 | Unqualified Rejection | THIS RFC | | 1 | Transient Failure | RFC 9914 |
+-------+-----------------------+-----------+
| 1 | Transient Failure | THIS RFC |
+-------+-----------------------+-----------+ +-------+-----------------------+-----------+
| 2..63 | Unassigned | | | 2..63 | Unassigned | |
+-------+-----------------------+-----------+ +-------+-----------------------+-----------+
Table 29: Rejection values of the PDR-ACK Table 29: PDR-ACK Rejection Status Values
Status
11.11. SubRegistry for the Via Information Options Flags 11.11. Registry for Via Information Options Flags
IANA is requested to create a registry for the 8-bit "Via Information IANA has created the "Via Information Options (VIO) Flags" registry
Options (VIO) Flags" field under the heading "Routing Protocol for under the "Routing Protocol for Low Power and Lossy Networks (RPL)"
Low Power and Lossy Networks (RPL)" [IANA-RPL]. The bits are indexed registry group [IANA-RPL]. The bits are indexed from 0 (leftmost) to
from 0 (leftmost) to 7. Each bit is tracked with the following 7. 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]. No bit is The registration procedure is Standards Action [RFC8126]. At the
currently assigned for the VIO Flags, more in Section 5.3. time of publication of this document, no bit has been assigned in
this registry (see more in Section 5.3).
11.12. SubRegistry for the Sibling Information Option Flags 11.12. Registry for Sibling Information Option Flags
IANA is requested to create a registry for the 5-bit "Sibling IANA has created the "Sibling Information Option (SIO) Flags"
Information Option (SIO) Flags" field under the heading "Routing registry under the "Routing Protocol for Low Power and Lossy Networks
Protocol for Low Power and Lossy Networks (RPL)" [IANA-RPL]. The (RPL)" registry group [IANA-RPL]. The bits are indexed from 0
bits are indexed from 0 (leftmost) to 4. Each bit is tracked with (leftmost) to 4. Each bit is tracked with the following qualities:
the following qualities:
* Bit number (counting from bit 0 as the most significant bit) * Bit number (counting from bit 0 as the most significant bit)
* Capability description * Capability description
* Reference * Reference
Registration procedure is "Standards Action" [RFC8126]. The initial The registration procedure is Standards Action [RFC8126]. The
allocation is as indicated in Table 30, more in Figure 17: initial allocation is as indicated in Table 30 (see more in
Figure 17):
+===============+========================+===========+ +============+=========================================+===========+
| Bit number | Capability description | Reference | | Bit Number | Capability Description | Reference |
+===============+========================+===========+ +============+=========================================+===========+
| 0 (Suggested) | "S" flag: Sibling in | THIS RFC | | 0 | 'S' flag: Sibling in same DODAG as self | RFC 9914 |
| | same DODAG as Self | | +------------+-----------------------------------------+-----------+
+---------------+------------------------+-----------+ | 1..4 | Unassigned | |
| 1..4 | Unassigned | | +------------+-----------------------------------------+-----------+
+---------------+------------------------+-----------+
Table 30: Initial SIO Flags Table 30: Initial SIO Flags
11.13. Destination Advertisement Object Flag 11.13. Destination Advertisement Object Flag
IANA is requested to update the "Destination Advertisement Object IANA has updated the "Destination Advertisement Object (DAO) Flags"
(DAO) Flags" registry created in Section 20.11 of [RPL] under the registry, created in Section 20.11 of [RPL], under the "Routing
heading "Routing Protocol for Low Power and Lossy Networks (RPL)" Protocol for Low Power and Lossy Networks (RPL)" registry group
[IANA-RPL] as indicated in Table 31, more in Section 4.1.1: [IANA-RPL] as indicated in Table 31 (see more in Section 4.1.1):
+---------------+------------------------+-----------+ +============+========================+===========+
| Bit Number | Capability Description | Reference | | Bit Number | Capability Description | Reference |
+---------------+------------------------+-----------+ +============+========================+===========+
| 2 (Suggested) | Projected DAO (P) | THIS RFC | | 2 | Projected DAO (P) | RFC 9914 |
+---------------+------------------------+-----------+ +------------+------------------------+-----------+
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
IANA is requested to update the "Destination Advertisement Object IANA has updated the "Destination Advertisement Object (DAO)
(DAO) Acknowledgment Flags" registry created in Section 20.12 of Acknowledgment Flags" registry, created in Section 20.12 of [RPL],
[RPL] under the heading "Routing Protocol for Low Power and Lossy under the "Routing Protocol for Low Power and Lossy Networks (RPL)"
Networks (RPL)" [IANA-RPL] as indicated in Table 32, more in registry group [IANA-RPL] as indicated in Table 32 (see more in
Section 4.1.2: Section 4.1.2):
+---------------+------------------------+-----------+ +============+========================+===========+
| Bit Number | Capability Description | Reference | | Bit Number | Capability Description | Reference |
+---------------+------------------------+-----------+ +============+========================+===========+
| 1 (Suggested) | Projected DAO-ACK (P) | THIS RFC | | 1 | Projected DAO-ACK (P) | RFC 9914 |
+---------------+------------------------+-----------+ +------------+------------------------+-----------+
Table 32: New Destination Advertisement Object Table 32: New Destination Advertisement Object
Acknowledgment Flag Acknowledgment Flag
11.15. New ICMPv6 Error Code 11.15. ICMPv6 Error Code
In some cases RPL will return an ICMPv6 error message when a message In some cases, RPL will return an ICMPv6 error message when a message
cannot be forwarded along a P-Route. cannot be forwarded along a P-Route.
This specification requires that a new code is allocated from the Per this specification, IANA has updated the "Type 1 - Destination
'ICMPv6 "Code" Fields' heading of the "Internet Control Message Unreachable" registry, in the "ICMPv6 'Code' Fields" registry, under
Protocol version 6 (ICMPv6) Parameters" [IANA-ICMP] Registry for the "Internet Control Message Protocol version 6 (ICMPv6) Parameters"
"Type 1 - Destination Unreachable", with a suggested code value of 9, registry group [IANA-ICMP] as indicated in Table 33.
to be confirmed by IANA to indicate an "Error in P-Route".
11.16. RPL Rejection Status values +======+==================+===========+
| Code | Name | Reference |
+======+==================+===========+
| 9 | Error in P-Route | RFC 9914 |
+------+------------------+-----------+
IANA is requested to update the "RPL Rejection Status" registry under Table 33: New ICMPv6 Error Code
the heading "Routing Protocol for Low Power and Lossy Networks (RPL)"
[IANA-RPL] as indicated in Table 33:
+---------------+-------------------------+-----------+ 11.16. RPL Rejection Status Values
| Value | Meaning | Reference |
+---------------+-------------------------+-----------+
| 2 (Suggested) | Out of Resources | THIS RFC |
+---------------+-------------------------+-----------+
| 3 (Suggested) | Error in VIO | THIS RFC |
+---------------+-------------------------+-----------+
| 4 (Suggested) | Predecessor Unreachable | THIS RFC |
+---------------+-------------------------+-----------+
| 5 (Suggested) | Unreachable Target | THIS RFC |
+---------------+-------------------------+-----------+
| 6..63 | Unassigned | |
+---------------+-------------------------+-----------+
Table 33: Rejection values of the RPL Status IANA has updated the "RPL Rejection Status" registry under the
"Routing Protocol for Low Power and Lossy Networks (RPL)" registry
group [IANA-RPL] as indicated in Table 34:
12. Acknowledgments +=======+=========================+===========+
| Value | Meaning | Reference |
+=======+=========================+===========+
| 2 | Out of Resources | RFC 9914 |
+-------+-------------------------+-----------+
| 3 | Error in VIO | RFC 9914 |
+-------+-------------------------+-----------+
| 4 | Predecessor Unreachable | RFC 9914 |
+-------+-------------------------+-----------+
| 5 | Unreachable Target | RFC 9914 |
+-------+-------------------------+-----------+
| 6..63 | Unassigned | |
+-------+-------------------------+-----------+
The authors wish to acknowledge JP Vasseur, Remy Liubing, James Table 34: RPL Rejection Status Values
Pylakutty, and Patrick Wetterwald for their contributions to the
ideas developed here. Many thanks to Dominique Barthel and SVR Anand
for their global contribution to 6TiSCH, RAW and this RFC, as well as
text suggestions that were incorporated. Also special thanks to
Remous-Aris Koutsiamanis, Li Zhao, Dominique Barthel, and Toerless
Eckert for their in-depth reviews, with many excellent suggestions
that improved the readability and well as the content of the
specification. Many thanks to Remous-Aris Koutsiamanis for his
review during WGLC and to Ines Robles for her shepherding and
thorough review. Many thanks to Warren Kumari, Ran Chen, Murray
Kucherawy, Roman Danyliw, Klaas Wierenga, Deb Cooley, Eric Vyncke,
Gunter Van de Velde, Sue Hares and John Scudder for their comments
and suggestions during the IETF last call and IESG review cycle.
13. Normative References 12. References
12.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997, DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/info/rfc2119>. <https://www.rfc-editor.org/info/rfc2119>.
[RFC4443] Conta, A., Deering, S., and M. Gupta, Ed., "Internet [RFC4443] Conta, A., Deering, S., and M. Gupta, Ed., "Internet
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,
skipping to change at page 88, line 20 skipping to change at line 4033
Option Type, Routing Header for Source Routes, and IPv6- Option Type, Routing Header for Source Routes, and IPv6-
in-IPv6 Encapsulation in the RPL Data Plane", RFC 9008, in-IPv6 Encapsulation in the RPL Data Plane", RFC 9008,
DOI 10.17487/RFC9008, April 2021, DOI 10.17487/RFC9008, April 2021,
<https://www.rfc-editor.org/info/rfc9008>. <https://www.rfc-editor.org/info/rfc9008>.
[RFC9030] Thubert, P., Ed., "An Architecture for IPv6 over the Time- [RFC9030] Thubert, P., Ed., "An Architecture for IPv6 over the Time-
Slotted Channel Hopping Mode of IEEE 802.15.4 (6TiSCH)", Slotted Channel Hopping Mode of IEEE 802.15.4 (6TiSCH)",
RFC 9030, DOI 10.17487/RFC9030, May 2021, RFC 9030, DOI 10.17487/RFC9030, May 2021,
<https://www.rfc-editor.org/info/rfc9030>. <https://www.rfc-editor.org/info/rfc9030>.
[RAW-ARCHI] [RAW-ARCH] Thubert, P., Ed., "Reliable and Available Wireless (RAW)
Thubert, P., "Reliable and Available Wireless Architecture", RFC 9912, DOI 10.17487/RFC9912, February
Architecture", Work in Progress, Internet-Draft, draft- 2026, <https://www.rfc-editor.org/info/rfc9912>.
ietf-raw-architecture-24, 25 February 2025,
<https://datatracker.ietf.org/api/v1/doc/document/draft-
ietf-raw-architecture/>.
14. Informative References 12.2. Informative References
[INT-ARCHI] [INT-ARCH] 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>.
[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>.
[RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman, [RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman,
skipping to change at page 90, line 42 skipping to change at line 4143
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>.
[RFC9450] Bernardos, CJ., Ed., Papadopoulos, G., Thubert, P., and F. [RFC9450] Bernardos, CJ., Ed., Papadopoulos, G., Thubert, P., and F.
Theoleyre, "Reliable and Available Wireless (RAW) Use Theoleyre, "Reliable and Available Wireless (RAW) Use
Cases", RFC 9450, DOI 10.17487/RFC9450, August 2023, Cases", RFC 9450, DOI 10.17487/RFC9450, August 2023,
<https://www.rfc-editor.org/info/rfc9450>. <https://www.rfc-editor.org/info/rfc9450>.
[I-D.kuehlewind-update-tag] [RFC9473] Enghardt, R. and C. Krähenbühl, "A Vocabulary of Path
Kühlewind, M. and S. Krishnan, "Definition of new tags for Properties", RFC 9473, DOI 10.17487/RFC9473, September
2023, <https://www.rfc-editor.org/info/rfc9473>.
[NEW-TAGS] Kühlewind, M. and S. Krishnan, "Definition of new tags for
relations between RFCs", Work in Progress, Internet-Draft, relations between RFCs", Work in Progress, Internet-Draft,
draft-kuehlewind-update-tag-04, 12 July 2021, draft-kuehlewind-rswg-updates-tag-02, 8 July 2024,
<https://datatracker.ietf.org/doc/html/draft-kuehlewind- <https://datatracker.ietf.org/doc/html/draft-kuehlewind-
update-tag-04>. rswg-updates-tag-02>.
[I-D.irtf-panrg-path-properties]
Enghardt, R. and C. Krähenbühl, "A Vocabulary of Path
Properties", Work in Progress, Internet-Draft, draft-irtf-
panrg-path-properties-08, 6 March 2023,
<https://datatracker.ietf.org/doc/html/draft-irtf-panrg-
path-properties-08>.
[IANA-6LO] IETF, "IPv6 Low Power Personal Area Network Parameters [IANA-6LO] IANA, "IPv6 Low Power Personal Area Network Parameters",
registry", <https://www.iana.org/assignments/_6lowpan-parameters>.
<https://www.iana.org/assignments/icmpv6-parameters/>.
[IANA-RPL] IETF, "Routing Protocol for Low Power and Lossy Networks [IANA-RPL] IANA, "Routing Protocol for Low Power and Lossy Networks
(RPL) registry group", (RPL)", <https://www.iana.org/assignments/rpl/>.
<https://www.iana.org/assignments/rpl/>.
[IANA-ICMP] [IANA-ICMP]
IETF, "Internet Control Message Protocol version 6 IANA, "Internet Control Message Protocol version 6
(ICMPv6) Parameters registry group", (ICMPv6) Parameters",
<https://www.iana.org/assignments/icmpv6-parameters/>. <https://www.iana.org/assignments/icmpv6-parameters/>.
Acknowledgments
The authors wish to acknowledge JP. Vasseur, Remy Liubing, James
Pylakutty, and Patrick Wetterwald for their contributions to the
ideas developed here. Many thanks to Dominique Barthel and
S.V.R. Anand for their global contribution to 6TiSCH, RAW, and this
RFC, as well as text suggestions that were incorporated. Also,
special thanks to Remous-Aris Koutsiamanis, Li Zhao, Dominique
Barthel, and Toerless Eckert for their in-depth reviews, with many
excellent suggestions that improved the readability and the content
of the specification. Many thanks to Remous-Aris Koutsiamanis for
his review during WG Last Call and to Maria Ines Robles for her
thorough shepherd review. Many thanks to Warren Kumari, Ran Chen,
Murray Kucherawy, Roman Danyliw, Klaas Wierenga, Deb Cooley, Éric
Vyncke, Gunter Van de Velde, Sue Hares, and John Scudder for their
comments and suggestions during the IETF Last Call and IESG review
cycle.
Authors' Addresses Authors' Addresses
Pascal Thubert (editor) Pascal Thubert (editor)
06330 Roquefort-les-Pins 06330 Roquefort-les-Pins
France France
Email: pascal.thubert@gmail.com Email: pascal.thubert@gmail.com
Rahul Arvind Jadhav Rahul Arvind Jadhav
AccuKnox AccuKnox
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 Michael C. Richardson
Sandelman Software Works Sandelman Software Works
Email: mcr+ietf@sandelman.ca Email: mcr+ietf@sandelman.ca
URI: http://www.sandelman.ca/ URI: http://www.sandelman.ca/
 End of changes. 639 change blocks. 
1823 lines changed or deleted 1874 lines changed or added

This html diff was produced by rfcdiff 1.48.