< draft-ietf-roll-dao-projection-21.txt   draft-ietf-roll-dao-projection-22.txt >
ROLL P. Thubert, Ed. ROLL P. Thubert, Ed.
Internet-Draft Cisco Systems Internet-Draft Cisco Systems
Intended status: Standards Track R.A. Jadhav Intended status: Standards Track R.A. Jadhav
Expires: 31 March 2022 Huawei Tech Expires: 29 May 2022 Huawei Tech
M. Gillmore M. Gillmore
Itron Itron
27 September 2021 25 November 2021
Root initiated routing state in RPL Root initiated routing state in RPL
draft-ietf-roll-dao-projection-21 draft-ietf-roll-dao-projection-22
Abstract Abstract
This document extends RFC 6550, RFC 6553,and RFC 8138 to enable a RPL This document extends RFC 6550, RFC 6553, and RFC 8138 to enable a
Root to install and maintain Projected Routes within its DODAG, along RPL Root to install and maintain Projected Routes within its DODAG,
a selected set of nodes that may or may not include self, for a along a selected set of nodes that may or may not include self, for a
chosen duration. This potentially enables routes that are more chosen duration. This potentially enables routes that are more
optimized or resilient than those obtained with the classical optimized or resilient than those obtained with the classical
distributed operation of RPL, either in terms of the size of a distributed operation of RPL, either in terms of the size of a
Routing Header or in terms of path length, which impacts both the Routing Header or in terms of path length, which impacts both the
latency and the packet delivery ratio. latency and the packet delivery ratio.
Status of This Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
skipping to change at page 1, line 40 skipping to change at page 1, line 40
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/. Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on 31 March 2022. This Internet-Draft will expire on 29 May 2022.
Copyright Notice Copyright Notice
Copyright (c) 2021 IETF Trust and the persons identified as the Copyright (c) 2021 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents (https://trustee.ietf.org/ Provisions Relating to IETF Documents (https://trustee.ietf.org/
license-info) in effect on the date of publication of this document. license-info) in effect on the date of publication of this document.
Please review these documents carefully, as they describe your rights Please review these documents carefully, as they describe your rights
and restrictions with respect to this document. Code Components and restrictions with respect to this document. Code Components
extracted from this document must include Simplified BSD License text extracted from this document must include Revised BSD License text as
as described in Section 4.e of the Trust Legal Provisions and are described in Section 4.e of the Trust Legal Provisions and are
provided without warranty as described in the Simplified BSD License. provided without warranty as described in the Revised BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 4
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4
2.1. Requirements Language . . . . . . . . . . . . . . . . . . 4 2.1. Requirements Language . . . . . . . . . . . . . . . . . . 4
2.2. References . . . . . . . . . . . . . . . . . . . . . . . 4 2.2. References . . . . . . . . . . . . . . . . . . . . . . . 5
2.3. Glossary . . . . . . . . . . . . . . . . . . . . . . . . 4 2.3. Glossary . . . . . . . . . . . . . . . . . . . . . . . . 5
2.4. Domain Terms . . . . . . . . . . . . . . . . . . . . . . 5 2.4. Domain Terms . . . . . . . . . . . . . . . . . . . . . . 5
3. Context and Goal . . . . . . . . . . . . . . . . . . . . . . 6 2.4.1. Projected Route . . . . . . . . . . . . . . . . . . . 6
3.1. RPL Applicability . . . . . . . . . . . . . . . . . . . . 7 2.4.2. Projected DAO . . . . . . . . . . . . . . . . . . . . 6
3.2. RPL Routing Modes . . . . . . . . . . . . . . . . . . . . 8 2.4.3. Path . . . . . . . . . . . . . . . . . . . . . . . . 6
3.3. Requirements . . . . . . . . . . . . . . . . . . . . . . 9 2.4.4. Routing Stretch . . . . . . . . . . . . . . . . . . . 6
3.3.1. Loose Source Routing . . . . . . . . . . . . . . . . 9 2.4.5. Track . . . . . . . . . . . . . . . . . . . . . . . . 7
3.3.2. East-West Routes . . . . . . . . . . . . . . . . . . 10 3. Context and Goal . . . . . . . . . . . . . . . . . . . . . . 9
3.4. On Tracks . . . . . . . . . . . . . . . . . . . . . . . . 12 3.1. RPL Applicability . . . . . . . . . . . . . . . . . . . . 9
3.5. Serial Track Signaling . . . . . . . . . . . . . . . . . 13 3.2. RPL Routing Modes . . . . . . . . . . . . . . . . . . . . 10
3.5.1. Using Storing Mode Segments . . . . . . . . . . . . . 14 3.3. Requirements . . . . . . . . . . . . . . . . . . . . . . 11
3.5.2. Using Non-Storing Mode joining Tracks . . . . . . . . 20 3.3.1. Loose Source Routing . . . . . . . . . . . . . . . . 11
3.6. Complex Tracks . . . . . . . . . . . . . . . . . . . . . 27 3.3.2. East-West Routes . . . . . . . . . . . . . . . . . . 13
3.7. Scope and Expectations . . . . . . . . . . . . . . . . . 29 3.4. On Tracks . . . . . . . . . . . . . . . . . . . . . . . . 14
4. Extending existing RFCs . . . . . . . . . . . . . . . . . . . 31 3.4.1. Building Tracks With RPL . . . . . . . . . . . . . . 15
4.1. Extending RFC 6550 . . . . . . . . . . . . . . . . . . . 31 3.4.2. Tracks and RPL Instances . . . . . . . . . . . . . . 15
4.1.1. Projected DAO . . . . . . . . . . . . . . . . . . . . 31 3.5. Serial Track Signaling . . . . . . . . . . . . . . . . . 16
4.1.2. Via Information Option . . . . . . . . . . . . . . . 33 3.5.1. Using Storing Mode Segments . . . . . . . . . . . . . 17
4.1.3. Sibling Information Option . . . . . . . . . . . . . 33 3.5.2. Using Non-Storing Mode joining Tracks . . . . . . . . 24
4.1.4. P-DAO Request . . . . . . . . . . . . . . . . . . . . 33 3.6. Complex Tracks . . . . . . . . . . . . . . . . . . . . . 31
4.1.5. Extending the RPI . . . . . . . . . . . . . . . . . . 33 3.7. Scope and Expectations . . . . . . . . . . . . . . . . . 33
4.2. Extending RFC 6553 . . . . . . . . . . . . . . . . . . . 34 3.7.1. External Dependencies . . . . . . . . . . . . . . . . 33
4.3. Extending RFC 8138 . . . . . . . . . . . . . . . . . . . 35 3.7.2. Positioning vs. Related IETF Standards . . . . . . . 33
5. New RPL Control Messages and Options . . . . . . . . . . . . 36 4. Extending existing RFCs . . . . . . . . . . . . . . . . . . . 35
5.1. New P-DAO Request Control Message . . . . . . . . . . . . 36 4.1. Extending RFC 6550 . . . . . . . . . . . . . . . . . . . 35
5.2. New PDR-ACK Control Message . . . . . . . . . . . . . . . 37 4.1.1. Projected DAO . . . . . . . . . . . . . . . . . . . . 36
5.3. Via Information Options . . . . . . . . . . . . . . . . . 39 4.1.2. Via Information Option . . . . . . . . . . . . . . . 37
5.4. Sibling Information Option . . . . . . . . . . . . . . . 42 4.1.3. Sibling Information Option . . . . . . . . . . . . . 37
6. Root Initiated Routing State . . . . . . . . . . . . . . . . 44 4.1.4. P-DAO Request . . . . . . . . . . . . . . . . . . . . 38
6.1. Requesting a Track . . . . . . . . . . . . . . . . . . . 44 4.1.5. Extending the RPI . . . . . . . . . . . . . . . . . . 38
6.2. Identifying a Track . . . . . . . . . . . . . . . . . . . 45 4.1.6. Additional Flag in the RPL DODAG Configuration
6.3. Installing a Track . . . . . . . . . . . . . . . . . . . 46 Option . . . . . . . . . . . . . . . . . . . . . . . 38
6.3.1. Signaling a Projected Route . . . . . . . . . . . . . 47 4.2. Extending RFC 6553 . . . . . . . . . . . . . . . . . . . 39
6.3.2. Installing a Track Segment with a Storing Mode 4.3. Extending RFC 8138 . . . . . . . . . . . . . . . . . . . 40
P-Route . . . . . . . . . . . . . . . . . . . . . . . 48 5. New RPL Control Messages and Options . . . . . . . . . . . . 41
5.1. New P-DAO Request Control Message . . . . . . . . . . . . 42
6.3.3. Installing a Track Leg with a Non-Storing Mode 5.2. New PDR-ACK Control Message . . . . . . . . . . . . . . . 43
P-Route . . . . . . . . . . . . . . . . . . . . . . . 50 5.3. Via Information Options . . . . . . . . . . . . . . . . . 44
6.4. Tearing Down a P-Route . . . . . . . . . . . . . . . . . 52 5.4. Sibling Information Option . . . . . . . . . . . . . . . 47
6.5. Maintaining a Track . . . . . . . . . . . . . . . . . . . 52 6. Root Initiated Routing State . . . . . . . . . . . . . . . . 49
6.5.1. Maintaining a Track Segment . . . . . . . . . . . . . 53 6.1. RPL Network Setup . . . . . . . . . . . . . . . . . . . . 49
6.5.2. Maintaining a Track Leg . . . . . . . . . . . . . . . 53 6.2. Requesting a Track . . . . . . . . . . . . . . . . . . . 49
6.6. Encapsulating and Forwarding Along a Track . . . . . . . 54 6.3. Identifying a Track . . . . . . . . . . . . . . . . . . . 50
6.7. Compression of the RPL Artifacts . . . . . . . . . . . . 56 6.4. Installing a Track . . . . . . . . . . . . . . . . . . . 51
7. Lesser Constrained Variations . . . . . . . . . . . . . . . . 58 6.4.1. Signaling a Projected Route . . . . . . . . . . . . . 52
7.1. Storing Mode Main DODAG . . . . . . . . . . . . . . . . . 58 6.4.2. Installing a Track Segment with a Storing Mode
7.2. A Track as a Full DODAG . . . . . . . . . . . . . . . . . 60 P-Route . . . . . . . . . . . . . . . . . . . . . . . 53
8. Profiles . . . . . . . . . . . . . . . . . . . . . . . . . . 61 6.4.3. Installing a Track Leg with a Non-Storing Mode
9. Security Considerations . . . . . . . . . . . . . . . . . . . 63 P-Route . . . . . . . . . . . . . . . . . . . . . . . 55
10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 63 6.5. Tearing Down a P-Route . . . . . . . . . . . . . . . . . 57
10.1. New Elective 6LoWPAN Routing Header Type . . . . . . . . 64 6.6. Maintaining a Track . . . . . . . . . . . . . . . . . . . 57
10.2. New Critical 6LoWPAN Routing Header Type . . . . . . . . 64 6.6.1. Maintaining a Track Segment . . . . . . . . . . . . . 58
10.3. New Subregistry For The RPL Option Flags . . . . . . . . 64 6.6.2. Maintaining a Track Leg . . . . . . . . . . . . . . . 58
10.4. New RPL Control Codes . . . . . . . . . . . . . . . . . 65 6.7. Encapsulating and Forwarding Along a Track . . . . . . . 59
10.5. New RPL Control Message Options . . . . . . . . . . . . 65 6.8. Compression of the RPL Artifacts . . . . . . . . . . . . 61
10.6. SubRegistry for the Projected DAO Request Flags . . . . 66 7. Lesser Constrained Variations . . . . . . . . . . . . . . . . 63
10.7. SubRegistry for the PDR-ACK Flags . . . . . . . . . . . 66 7.1. Storing Mode Main DODAG . . . . . . . . . . . . . . . . . 63
10.8. Subregistry for the PDR-ACK Acceptance Status Values . . 66 7.2. A Track as a Full DODAG . . . . . . . . . . . . . . . . . 65
10.9. Subregistry for the PDR-ACK Rejection Status Values . . 67 8. Profiles . . . . . . . . . . . . . . . . . . . . . . . . . . 66
10.10. SubRegistry for the Via Information Options Flags . . . 67 9. Backwards Compatibility . . . . . . . . . . . . . . . . . . . 68
10.11. SubRegistry for the Sibling Information Option Flags . . 68 10. Security Considerations . . . . . . . . . . . . . . . . . . . 69
10.12. New destination Advertisement Object Flag . . . . . . . 68 11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 69
10.13. New ICMPv6 Error Code . . . . . . . . . . . . . . . . . 68 11.1. RPL DODAG Configuration Option Flag . . . . . . . . . . 69
10.14. New RPL Rejection Status values . . . . . . . . . . . . 69 11.2. Elective 6LoWPAN Routing Header Type . . . . . . . . . . 70
11. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 69 11.3. Critical 6LoWPAN Routing Header Type . . . . . . . . . . 70
12. Normative References . . . . . . . . . . . . . . . . . . . . 69 11.4. Subregistry For The RPL Option Flags . . . . . . . . . . 70
13. Informative References . . . . . . . . . . . . . . . . . . . 71 11.5. RPL Control Codes . . . . . . . . . . . . . . . . . . . 71
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 73 11.6. RPL Control Message Options . . . . . . . . . . . . . . 71
11.7. SubRegistry for the Projected DAO Request Flags . . . . 72
11.8. SubRegistry for the PDR-ACK Flags . . . . . . . . . . . 72
11.9. Subregistry for the PDR-ACK Acceptance Status Values . . 73
11.10. Subregistry for the PDR-ACK Rejection Status Values . . 73
11.11. SubRegistry for the Via Information Options Flags . . . 73
11.12. SubRegistry for the Sibling Information Option Flags . . 74
11.13. destination Advertisement Object Flag . . . . . . . . . 74
11.14. New ICMPv6 Error Code . . . . . . . . . . . . . . . . . 75
11.15. RPL Rejection Status values . . . . . . . . . . . . . . 75
12. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 76
13. Normative References . . . . . . . . . . . . . . . . . . . . 76
14. Informative References . . . . . . . . . . . . . . . . . . . 77
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 80
1. Introduction 1. Introduction
RPL, the "Routing Protocol for Low Power and Lossy Networks" [RPL] RPL, the "Routing Protocol for Low Power and Lossy Networks" [RPL]
(LLNs), is an anisotropic Distance Vector protocol that is well- (LLNs), is an anisotropic Distance Vector protocol that is well-
suited for application in a variety of low energy Internet of Things suited for application in a variety of low energy Internet of Things
(IoT) networks where stretched P2P paths are acceptable vs. the (IoT) networks where stretched P2P paths are acceptable vs. the
signaling and state overhead involved in maintaining shortest paths signaling and state overhead involved in maintaining shortest paths
across. across.
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 and routes along that graph up, towards the domain to the IP backbone and routes along that graph up, towards the
Root, and down towards the nodes. Root, and down towards the nodes.
With this specification, a Path Computation Element [PCE] in an With this specification, an abstract routing function called a Path
external controller interacts with the RPL Root to compute centrally Computation Element [PCE] (e.g., located in an central controller or
shorter Peer to Peer (P2P) paths within a pre-existing RPL Main collocated with the Root) interacts with the RPL Root to compute Peer
DODAG. The topological information that is passed to the PCE is to Peer (P2P) paths within a pre-existing RPL Main DODAG. The
derived from the DODAG that is already available at the Root in RPL topological information that is passed to the PCE is derived from the
Non-Storing Mode. This specification introduces protocol extensions DODAG that is already available at the Root in RPL Non-Storing Mode.
that enrich the topological information that is available at the Root This specification introduces protocol extensions that enrich the
and passed to the PCE. topological information that is available at the Root and passed to
the PCE.
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 on the system can optimize the computed with a global visibility on the system can optimize the computed
routes for the application needs, including the capability to provide routes for the application needs, including the capability to provide
path redundancy. This specification also introduces protocol path redundancy. This specification also introduces protocol
extensions that enable the Root to translates the computed paths into extensions that enable the Root to translates the computed paths into
RPL and install them as Projected Routes (aka P-Routes) inside the RPL and install them as Projected Routes (aka P-Routes) inside the
DODAG on behalf of a PCE. DODAG on behalf of a PCE.
skipping to change at page 5, line 26 skipping to change at page 5, line 47
NSM-VIO: A Source-Routed Via Information Option, used in Non-Storing NSM-VIO: A Source-Routed Via Information Option, used in Non-Storing
Mode P-DAO messages. Mode P-DAO messages.
SLO: Service Level Objective SLO: Service Level Objective
TIO: RPL Transit Information Option TIO: RPL Transit Information Option
SM-VIO: A strict Via Information Option, used in Storing Mode P-DAO SM-VIO: A strict Via Information Option, used in Storing Mode P-DAO
messages. messages.
VIO: A Via Information Option; it can be a SM-VIO or an NSM-VIO. VIO: A Via Information Option; it can be a SM-VIO or an NSM-VIO.
2.4. Domain Terms 2.4. Domain Terms
Projected Route: A RPL P-Route is a RPL route that is computed This specification uses the following terminology:
remotely by a PCE, and installed and maintained by a RPL Root on
behalf of the PCE. It is installed as a state that signals that 2.4.1. Projected Route
destinations (aka Targets) are reachable along a sequence of
nodes. A RPL P-Route is a RPL route that is computed remotely by a PCE, and
Projected DAO: A DAO message used to install a P-Route. installed and maintained by a RPL Root on behalf of the PCE. It is
Path: Quoting section 1.1.3 of [INT-ARCHI]: "At a given moment, all installed as a state that signals that destinations (aka Targets) are
the IP datagrams from a particular source host to a particular reachable along a sequence of nodes.
destination host will typically traverse the same sequence of
gateways. We use the term "path" for this sequence. Note that a 2.4.2. Projected DAO
path is uni-directional; it is not unusual to have different paths
in the two directions between a given host pair.". A DAO message used to install a P-Route.
Section 2 of [I-D.irtf-panrg-path-properties] points to a longer,
more modern definition of path, which begins as follows: " A 2.4.3. Path
sequence of adjacent path elements over which a packet can be
transmitted, starting and ending with a node. A path is Quoting section 1.1.3 of [INT-ARCHI]:
unidirectional. Paths are time-dependent, i.e., the sequence of
path elements over which packets are sent from one node to another | At a given moment, all the IP datagrams from a particular source
may change. A path is defined between two nodes. " | host to a particular destination host will typically traverse the
It follows that the general acceptance of a path is a linear | same sequence of gateways. We use the term "path" for this
sequence of nodes, as opposed to a multi-dimensional graph. In | sequence. Note that a path is uni-directional; it is not unusual
the context of this document, a path is observed by following one | to have different paths in the two directions between a given host
copy of a packet that is injected in a Track and possibly | pair.
replicated within.
Track: A networking graph that can be followed to transport packets Section 2 of [I-D.irtf-panrg-path-properties] points to a longer,
with equivalent treatment; as opposed to the definition of a path more modern definition of path, which begins as follows:
above, a Track Track is not necessarily linear. It may contain
multiple paths that may fork and rejoin, and may enable the RAW | A sequence of adjacent path elements over which a packet can be
Packet ARQ, Replication, Elimination, and Overhearing (PAREO) | transmitted, starting and ending with a node. A path is
operations. | unidirectional. Paths are time-dependent, i.e., the sequence of
This specification builds Tracks that are DODAGs oriented towards | path elements over which packets are sent from one node to another
a Track Ingress, and the forward direction for packets is East- | may change. A path is defined between two nodes.
West from the Track Ingress to one of the possibly multiple Track
Egress Nodes, which is also down the DODAG. It follows that the general acceptance of a path is a linear sequence
The Track may be strictly connected, meaning that the vertices are of nodes, as opposed to a multi-dimensional graph. In the context of
adjacent, or loosely connected, meaning that the vertices are this document, a path is observed by following one copy of a packet
connected using Segments that are associated to the same Track. that is injected in a Track and possibly replicated within.
TrackID: A RPL Local InstanceID that identifies a Track using the
namespace owned ny the Track Ingress. The TrackID is associated 2.4.4. Routing Stretch
with the IPv6 Address of the Track Ingress that is used as
DODAGID, and together they form a unique identification of the RPL is anisotropic, meaning that it is directional, or more exactly
Track (see the definition of DODAGID in section 2 of [RPL]. polar. RPL does not behave the same way "down" with multicast DIO
Serial Track: A Track that has only one path. messages that form the DODAG and "up" with unicast DAO messages that
Stand-Alone: A single P-DAO that fully defines a Track, e.g., a follow the DODAG. This is in contrast with traditional IGPs that
Serial Track installed with a single Storing Mode Via Information operate the same in all directions and are thus called isotropic.
option (SM-VIO).
subTrack: A Track within a Track. As the Non-Storing Mode Via The term Routing Stretch denotes the length of a path, as compared
Information option (NSM-VIO) can only signal a loose sequence of with a shortest path, which can be a abstract concepts in RPL when
nodes, it takes a number of them to signal a complex Track. Each the metrics are statistical and dynamic, and the concept of short
NSM-VIO for the same TrackId but a different Segment ID signals a varies with the Objective Function.
different subTracks that the Track Ingress adds to the topology.
Track Leg: An end-to-end East-West serial path that can be a Track The RPL DODAG optimizes the P2MP (from Root) and MP2P (to Root)
by itself or a subTrack of a complex Track. With this paths, but the P2P (node to node) traffic has to follow the same
specification, a Leg is is installed by the Root of the main DODAG DODAG. Following the DODAG, the RPL datapath passes via a common
using Non-Storing Mode P-DAO messages, and it is expressed as a parent in Storing Mode and via the Root in Non-Storing Mode. This
loose sequence of nodes that are joined by Track Segments. typically involves more hops and more latency than the minimum
Track Segment: A serial path formed by a strict sequence of nodes, possible for a direct P2P path that an isotropic protocol would
along which a P-Route is installed. With this specification, a compute. We refer to this elongated path as stretched.
Segment is typically installed by the Root of the main DODAG using
Storing Mode P-DAO messages. A Segment used as the topological 2.4.5. Track
edge of a Track. Since this specification builds only DODAGs, all
Segments are oriented from Ingress (East) to Egress (West), as A networking graph that can be followed to transport packets with
opposed to the general RAW model, which allows North/South equivalent treatment; as opposed to the definition of a path above, a
Segments that can be bidirectional. Track is not necessarily linear. It may contain multiple paths that
may fork and rejoin, and may enable the RAW Packet ARQ, Replication,
Elimination, and Overhearing (PAREO) operations.
A ==> B ==> C -=- F ==> G ==> H T1 I: Ingress
/ \ / \ / E: Egress
I O E -=- T2 T1, T2, T3:
\ / \ / \ External
P ==> Q ==> R -=- T ==> U ==> V T3 Targets
I ==> A ==> B ==> C : a segment to targets F and O
I --> F --> E : a leg to targets T1, T2, T3
I, A, B, C, F, G, H, E : a path to T1, T2, T3
Figure 1: A Track and its Components
This specification builds Tracks that are DODAGs oriented towards a
Track Ingress, and the forward direction for packets (aka East-West)
is from the Track Ingress to one of the possibly multiple Track
Egress Nodes, which is also down the DODAG.
The Track may be strictly 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.
2.4.5.1. TrackID
A RPL Local InstanceID that identifies a Track using the namespace
owned by the Track Ingress. The TrackID is associated with the IPv6
Address of the Track Ingress that is used as DODAGID, and together
they form a unique identification of the Track (see the definition of
DODAGID in section 2 of [RPL].
2.4.5.2. namespace
The term namespace is used to refer to the scope of the TrackID. The
TrackID is locally significant within its namespace. The namespace
is identified by the DODAGID for the Track. The tuple (DODAGID,
TrackID) is globally unique.
2.4.5.3. Serial Track
A Track that has only one path.
2.4.5.4. Stand-Alone
A single P-DAO that fully defines a Track, e.g., a Serial Track
installed with a single Storing Mode Via Information option (SM-VIO).
2.4.5.5. Stitching
This specification using the term stitching to indicate that a track
is piped to another one, meaning that traffic out of the first is
injected in the other.
2.4.5.6. subTrack
A Track within a Track. As the Non-Storing Mode Via Information
option (NSM-VIO) can only signal a loose sequence of nodes, it takes
a number of them to signal a complex Track. Each NSM-VIO for the
same TrackId but a different Segment ID signals a different subTracks
that the Track Ingress adds to the topology.
2.4.5.7. Leg
An end-to-end East-West serial path that can be a Track by itself or
a subTrack of a complex Track. With this specification, a Leg is is
installed by the Root of the main DODAG using Non-Storing Mode P-DAO
messages, and it is expressed as a loose sequence of nodes that are
joined by Track Segments.
2.4.5.8. Segment
A serial path formed by a strict sequence of nodes, along which a
P-Route is installed. With this specification, a Segment is
typically installed by the Root of the main DODAG using Storing Mode
P-DAO messages. A Segment used as the topological edge of a Track.
Since this specification builds only DODAGs, all Segments are
oriented from Ingress (East) to Egress (West), as opposed to the
general RAW model, which allows North/South Segments that can be
bidirectional.
2.4.5.8.1. Section of a Segment
A continuous subset of a segment that may be replaced while the
segment remains. for instance, in segment A=>B=>C=>D=>E=>F, say that
the link C to D might be misbehaving. The section B=>C=>D=>E in the
segment may be replaced by B=>C'=>D'=>E to route around the problem.
The segment becomes A=>B=>C'=>D'=>E=>F.
2.4.5.8.2. Segment Routing and SRH
The terms Segment Routing and SRH refer to using source-routing to
hop over segments. In a Non-Storing mode RPL domain, the SRH is
typically a RPL Source Route Header (the IPv6 RH of type 3) as
defined in [RFC6554].
If the network is a 6LoWPAN Network, the expectation is that the SRH
is compressed and encoded as a 6LoWPAN Routing Header (6LoRH), as
specified in section 5 of [RFC8138].
On the other hand, if the RPL Network is less constrained and
operated in Storing Mode, as discussed in Section 7.1, the Segment
Routing operation and the SRH could be as specified in [RFC8754].
This specification applies equally to both forms of source routing
and SRH.
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 constrained and the transmissions unreliable. This matches bandwidth constrained and the transmissions unreliable. This matches
the use case of an IoT LLN where RPL is typically used today, but the use case of an IoT LLN where RPL is typically used today, but
also situations of high relative mobility between the nodes in the also situations of high relative mobility between the nodes in the
network (aka swarming), e.g., within a variable set of vehicles with network (aka swarming), e.g., within a variable set of vehicles with
a similar global motion, or a toon of drones. a similar global motion, or a toon of drones.
To reach this goal, RPL is primarily designed to minimize the control To reach this goal, RPL is primarily designed to minimize the control
skipping to change at page 7, line 26 skipping to change at page 10, line 5
maintained in each node. RPL does not need converge, and provides maintained in each node. RPL does not need converge, and provides
connectivity to most nodes most of the time. 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 to adapt 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 as ships in the night, unbeknownst of one RPL instances operate as ships passing in the night, unbeknownst of
another. The RPL Root is responsible to select the RPL Instance that one another. The RPL Root is responsible to select the RPL Instance
is used to forward a packet coming from the Backbone into the RPL that is used to forward a packet coming from the Backbone into the
domain and set the related RPL information in the packets. 6TiSCH RPL domain and set the related RPL information in the packets. 6TiSCH
leverages RPL for its distributed routing operations. leverages RPL 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 a global knowledge of
the topology, and only optimizes the routes to and from the RPL Root, the 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
skipping to change at page 8, line 9 skipping to change at page 10, line 34
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 [USE-CASES], which demand high availability RAW use cases document [USE-CASES], which demand high availability
and reliability, and as a consequence require both short and diverse and reliability, and as a consequence require both short and diverse
paths. paths.
3.2. RPL Routing Modes 3.2. RPL Routing Modes
RPL first forms a default route in each node towards the a Root, and RPL first forms a default route in each node towards the a Root, and
those routes together coalesce as a Directed Acyclic Graph upwards. those routes together coalesce as a Directed Acyclic Graph upwards.
RPL then constructs routes to so-called Targets in the reverse RPL then constructs routes to destinations signaled as Targets in the
direction, down the same DODAG. So do so, a RPL Instance can be reverse direction, down the same DODAG. So do so, a RPL Instance can
operated either in RPL Storing or Non-Storing Mode of Operation (MOP) be operated either in RPL Storing or Non-Storing Mode of Operation
The default route towards the Root is maintained aggressively and may (MOP). The default route towards the Root is maintained aggressively
change while a packet progresses without causing loops, so the packet and may change while a packet progresses without causing loops, so
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 self. to the Root, indicating the parents that may be used to reach self.
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
single unicast packet to the Root along the default route to update single unicast packet to the Root along the default route to update
it, and the connectivity is restored immediately; this mode is it, and the connectivity is restored immediately; this mode is
preferable for use cases where internet connectivity is dominant, or preferable for use cases where internet connectivity is dominant, or
when, like here, the Root controls the network activity in the nodes. when, like here, the Root controls the network activity in the nodes.
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 vs. Non-Storing, for a better P2P routing stretch is reduced vs. Non-Storing, for a better P2P
connectivity, while the internet connectivity is restored more connectivity. On the other hand, a new route takes a longer time to
slowly, time for the DV operation to operate hop-by-hop. propagate to the Root, time for the Distance-Vector protocol to
operate hop-by-hop, and the Internet connectivity is restored more
slowly upon 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 an hybrid mode that combines stretch, this specification introduces an 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 P-Route to refer to those routes. the term Projected Route (P-Route) to refer to those routes.
A P-Route may be installed in either Storing and Non-Storing Mode, A P-Route may be installed in either Storing and Non-Storing Mode,
potentially resulting in hybrid situations where the Mode of the P- potentially resulting in hybrid situations where the Mode of the P-
Route is different from that of the RPL Main DODAG. P-Routes can be Route is different from that of the RPL Main DODAG. P-Routes can be
used as stand-alone segments to reduce the size of the source routing used as stand-alone segments to reduce the size of the source routing
headers with loose source routing operations down the main RPL DODAG. headers with loose source routing operations down the main RPL DODAG.
P-Routes can also be combined with other P-Routes to form a more P-Routes can also be combined with other P-Routes to form a more
complex forwarding graph called a Track. complex forwarding graph called a Track.
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 1. 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 1: 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 about Storing DAO messages, the Root possesses topological information
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 a source routing information to reach the destination
if the destination is also in the DODAG. Similarly, a packet coming if 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. be in a RPL domain reaches the Root. It results that the wireless
bandwidth near the Root is the gating factor for all transmissions
towards or within the domain, and that the Root is a single point of
failure for all connectivity to nodes within its domain.
It results that the Root, or then some associated centralized The RPL Root must add a source routing header to all downward
computation engine such as a PCE, can determine the amount of packets packets. As a network grows, the size of the source routing header
that reach a destination in the RPL domain, and thus the amount of augments with the depth of the nodes. In some use cases, a RPL
energy and bandwidth that is wasted for transmission, between itself network forms long lines along physical structures such as streets
and the destination, as well as the risk of fragmentation, any for lighting. Limiting the packet size is directly beneficial to the
potential delays because of a paths longer than necessary (shorter energy budget, but, mostly, it reduces the chances of frame loss and
paths exist that would not traverse the Root). packet fragmentation, which are highly detrimental to the LLN
operation. A limited amount of well-targeted routing state would
allow the source routing operation to be loose as opposed to strict,
and save packet size. Because the capability to store a routing
state in every node is limited, the decision of which route is
installed where can only be optimized with a global knowledge of the
system, a knowledge that the Root or an associated PCE may possess by
means that are outside of the scope of this specification.
As a network gets deep, the size of the source routing header that Being on path for all packets in Non-Storing mode, the Root may
the Root must add to all the downward packets becomes an issue for determine the number of P2P packets in its RPL domain per source and
nodes that are many hops away. In some use cases, a RPL network destination, the latency incurred, and the amount of energy and
forms long lines and a limited amount of well-targeted routing state bandwidth that is consumed to reach the self and then down, including
would allow to make the source routing operation loose as opposed to a possible fragmentation when encapsulating larger packets. Enabling
strict, and save packet size. Limiting the packet size is directly a shorter path that would not traverse the Root for select P2P
beneficial to the energy budget, but, mostly, it reduces the chances source/destinations may improve the latency, lower the consumption of
of frame loss and/or packet fragmentation, which is highly constrained resources, free bandwidth at the bottleneck near the
detrimental to the LLN operation. Because the capability to store a Root, improve the delivery ratio and reduce the latency for those P2P
routing state in every node is limited, the decision of which route flows with a global benefit for all flows of reducing the load at the
is installed where can only be optimized with a global knowledge of Root.
the system, a knowledge that the Root or an associated PCE may
possess by means that are outside of the scope of this specification.
This requirement is to store a routing state associated with the Main This requirement is to store a routing state associated with the Main
DODAG in selected RPL routers, to limit the excursion of the source DODAG in selected RPL routers, to limit the excursion of the source
route headers in deep networks. The Root may elide the sequence of route headers in deep networks. The Root may elide the sequence of
routers that is installed in the network from its source route routers that is installed in the network from its source route
header, which becomes loose while it is strict in [RPL]. header, which becomes loose while it is strict in [RPL].
3.3.2. East-West Routes 3.3.2. East-West Routes
RPL is optimized for INternet access, with Point-to-Multipoint (P2MP) [RPL] optimizes Point-to-Multipoint (P2MP) routes from the Root,
and Multipoint-to-Point (MP2P), whereby routes are always installed Multipoint-to-Point (MP2P) routes to the DODAG Root, and Internet
North-South (aka up/down) along the RPL DODAG respectively from and access when the Root also serves as Border Router. All routes are
towards the Border Router that also serves as DODAG Root. Peer to installed North-South (aka up/down) along the RPL DODAG. Peer to
Peer (P2P) East-West routes in a RPL network will generally suffer Peer (P2P) East-West routes in a RPL network will generally suffer
from some elongated (stretched) path versus a direct (optimized) from some elongated (stretched) path versus a direct (optimized)
path, since routing between two nodes always happens via a common path, since routing between two nodes always happens via a common
parent, as illustrated in Figure 2: parent, as illustrated 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 2: 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
The amount of stretch depends on the Mode of Operation: As described in [RFC9008], the amount of stretch depends on the Mode
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.
skipping to change at page 11, line 45 skipping to change at page 14, line 41
+-----+ +-----+
| |
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 3: More direct East-West Route between S and D Figure 4: More direct East-West 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 SLO, e.g., in terms of latency and/or
reliability. reliability.
3.4. On Tracks 3.4. On Tracks
3.4.1. Building Tracks With RPL
A Track is typically a collection of parallel loose source routed The concept of a Track was introduced in the "6TiSCH Architecture"
sequences of nodes from Ingress to Egress, forming so-called Track [6TiSCH-ARCHI], as a collection of potential paths that leverage
Legs, that are joined with strict Segments of other nodes. The Legs redundant forwarding solutions along the way. This can be a DODAG or
are expressed in RPL Non-Storing Modes and require an encapsulation a more complex structure that is only partially acyclic (e.g., per
to add a Source Route Header, whereas the Segments are expressed in packet).
Storing Mode.
With this specification, a Track is shaped as a DODAG, and following
the directed edges leads to a Track Ingress. Storing Mode P-DAO
messages follow the direction of the edges to set up routes for
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
another DODAG by reversing the direction of each edge. A node at the
Ingress of more than one Segment in a Track may use one or more of
these Segments to forward a packet inside the Track.
A RPL Track is a collection of (one or more) parallel loose source
routed sequences of nodes ordered from Ingress to Egress, each
forming a Track Leg. The nodes that are directly connected,
reachable via existing Tracks as illustrated in Section 3.5.2.3 or
joined with strict Segments of other nodes as shown in
Section 3.5.1.3. The Legs are expressed in RPL Non-Storing Mode and
require an encapsulation to add a Source Route Header, whereas the
Segments are expressed in RPL Storing Mode.
A Serial Track comprises provides only one path between Ingress and A Serial Track comprises provides only one path between Ingress and
Egress. It comprises at most one Leg. A Stand-Alone Segment defines Egress. It comprises at most one Leg. A Stand-Alone Segment
implicitly a Serial Track from its Ingress to Egress. implicitly defines a Serial Track 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 Legs that may be parallel or cross at certain points, or as a more of Legs that may be parallel or cross at certain points, or as a more
generic DODAG. generic DODAG.
The concept of a Track was introduced in the "6TiSCH Architecture" 3.4.2. Tracks and RPL Instances
[6TiSCH-ARCHI], as a collection of potential paths that leverage
redundant forwarding solutions along the way. With this
specification, a Track forms DODAG that is directed towards a Track
Ingress. If there is a single Track Egress, then the Track is
reversible to form another DODAG by reversing the direction of each
edge. A node at the Ingress of more than one Segment in a Track may
use one or more of these Segments to forward a packet inside the
Track.
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. the DODAG. Bit 0 (most significant) is set to 1 to signal a Local
RPLInstanceID, as shown in Figure 5. By extension, this
specification expresses the value of the RPLInstanceID as a single
integer between 128 and 191, representing both the Local
RPLInstanceID in 0..63 and Bit 0 set.
0 1 2 3 4 5 6 7
+-+-+-+-+-+-+-+-+
|1|D| ID | Local RPLInstanceID in 0..63
+-+-+-+-+-+-+-+-+
Figure 5: Local RPLInstanceID Encoding
A Track is normally associated with a Local RPL Instance which A Track is normally associated with a Local RPL Instance which
RPLInstanceID is used as the TrackID, more in Section 6.2. A Track RPLInstanceID is used as the TrackID, more in Section 6.3. A Track
Leg may also be used as a subTrack that extends the RPL main DODAG. Leg may also be used as a subTrack that extends the RPL main DODAG.
In that case, the TrackID is set to the global RPLInstanceID of the In that case, the TrackID is set to the global RPLInstanceID of the
main DODAG, which suffices to identify the routing topology. As main DODAG, which suffices to identify the routing topology. As
opposed to local RPL instances, the Track Ingress that encapsulates opposed to local RPL instances, the Track Ingress that encapsulates
the packets over a subtrack is not Root, and that the source address the packets over a subtrack is not Root, and that the source address
of the encapsulated packet is not used to determine the Track. of the encapsulated packet is not used to determine the Track.
3.5. Serial Track Signaling 3.5. Serial Track Signaling
This specification enables to set up a P-Route along either a Track This specification enables to set up a P-Route along either a Track
Leg or a Segment. A P-Route is installed and maintained using an Leg or a Segment. A P-Route is installed and maintained by the Root
extended RPL DAO message called a Projected DAO (P-DAO), and a Track of the main DODAG using an extended RPL DAO message called a
is composed of the combination of one or more P-Routes. Projected DAO (P-DAO), and a Track is composed of the combination of
one or more P-Routes.
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 encapsulated packets along the Track is Ingress is used as source to encapsulate packets along the Track.
signaled in the DODAGID field of the Projected DAO Base Object, see The Track is signaled in the DODAGID field of the Projected DAO Base
Figure 6. Object, 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 Leg or a Segment in the P-DAO signal a sequence of hops in a Leg or a Segment in the P-DAO
messages, either in Storing Mode (SM-VIO) or NON-Storing Mode (NSM- messages, either in Storing Mode (SM-VIO) or Non-Storing Mode (NSM-
VIO). One P-DAO messages contains a single VIO, associated to one or VIO). One P-DAO messages contains a single VIO, associated to one or
more RPL Target Options that signal the destination IPv6 addresses more RPL Target Options that signal the destination IPv6 addresses
that can reached along the Track, more in Section 5.3. that can reached along the Track, more in Section 5.3.
Before diving deeper into Track Legs and Segments signaling and Before diving deeper into Track Legs and Segments signaling and
operation, this section provides examples of what how route operation, this section provides examples of what how route
projection works through variations of a simple example. This simple projection works through variations of a simple example. This simple
example illustrates the case of host routes, though RPL Targets can example illustrates the case of host routes, though RPL Targets can
be prefixes. be prefixes.
Say we want to build a Serial Track from node A to E in Figure 4, so Say we want to build a Serial Track from node A to E in Figure 6, so
A can route packets to E's neighbors F and G along A, B, C, D and E A can route packets to E's neighbors F and G along A, B, C, D and E
as opposed to via the Root: as opposed to via the Root:
/===> F /===> F
A ===> B ===> C ===> D===> E < A ===> B ===> C ===> D===> E <
\===> G \===> G
Figure 4: Reference Track Figure 6: Reference Track
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- like in C==>D==>E-to-F to represent coma- loose hop. We use "-to-", such as in C==>D==>E-to-F to represent
separated Targets, e.g., F is a Target for Segment C==>D==>E. In coma-separated Targets, e.g., F is a Target for Segment C==>D==>E.
this example, A is Track Ingress, E is Track Egress. C is a In this example, A is Track Ingress, E is Track Egress. C is a
stitching point. F and G are "external" Targets for the Track, and stitching point. F and G are "external" Targets for the Track, and
become reachable from A via the Track A(ingress) to E (Egress and become reachable from A via the Track A(ingress) to E (Egress and
implicit Target in Non-Storing Mode) leading to F and G (explicit implicit Target in Non-Storing Mode) leading to F and G (explicit
Targets). Targets).
Figure 5 depicts the format of the RPLInstanceID encoding for a local
RPLInstanceID .
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
skipping to change at page 16, line 27 skipping to change at page 19, line 51
+--------+-------------------+-------------------+----------------+ +--------+-------------------+-------------------+----------------+
Table 3: Packet Header Settings Table 3: Packet Header Settings
As an example, say that A has a packet for F. Using the RIB above: As an example, say that A has a packet for F. Using the RIB above:
* 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: C 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.6. case, more in Section 6.7.
In this formulation, we set up the Track Leg explicitly, which In this formulation, we set up the Track Leg 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
skipping to change at page 18, line 30 skipping to change at page 22, line 5
* 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 packet destination P-DAO 3, with the outer header above. Now the packet destination
is E. 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: C 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 leverages Track Legs to combine Segments and form In this formulation leverages Track Legs to combine Segments and form
a Graph. The packets are source routed from a Segment to the next to a Graph. The packets are source routed from a Segment to the next to
adapt the path. As such, this can be seen as a form of Segment adapt the path. As such, this can be seen as a form of Segment
Routing [RFC8402]: Routing [RFC8402]:
* P-DAO 1 signals C==>D==>E-to-E * P-DAO 1 signals C==>D==>E-to-E
skipping to change at page 20, line 33 skipping to change at page 24, line 8
IPv6 Header is C, and a SRH signals the final destination is E. IPv6 Header is C, and a SRH signals 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: C 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-F,G * P-DAO 1 signals C==>D==>E-to-F,G
* P-DAO 2 signals A==>B==>C-to-C,F,G * P-DAO 2 signals A==>B==>C-to-C,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 P-DAOs.
skipping to change at page 27, line 24 skipping to change at page 31, line 10
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 a 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 to build a collection of Legs between the same specification enables to build a collection of Legs between the same
Ingress and Egress Nodes and combine them with the same TrackID, as Ingress and Egress Nodes and combine them with the same TrackID, as
shown in Figure 5. Legs may cross at loose hops edges or remain shown in Figure 7. Legs may cross at the edges of loose hops or
parallel. remain parallel.
The Segments that join the loose hops of a Leg are installed with the The Segments that join the loose hops of a Leg are installed with the
same TrackID as the Leg. But each individual Leg and Segment has its same TrackID as the Leg. But each individual Leg and Segment has its
own P-RouteID which allows to manage it separately. When Legs cross own P-RouteID which allows it to be managed separately. When Legs
within respsective Segment, the next loose hop (the current cross within respective Segment, the next loose hop (the current
destination of the packet) indicates which Leg is being followed and destination of the packet) indicates which Leg is being followed and
a Segment that can reach that next loose hop is selected. a Segment that can reach that next loose hop is selected.
CPF CPF CPF CPF CPF CPF CPF CPF
Southbound API Southbound API
_-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._- _-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-
_-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._- _-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-
skipping to change at page 28, line 44 skipping to change at page 32, line 44
<------ Segment 3 F,G,H ------> <---- Segment 4 J,E ----> <------ Segment 3 F,G,H ------> <---- Segment 4 J,E ---->
<- Leg 2 H, E -> <- Leg 2 H, E ->
<--- Segment 1 A,B ---> <- S5-> <---- Segment 4 J,E ----> <--- Segment 1 A,B ---> <- S5-> <---- Segment 4 J,E ---->
<- Leg 3 B, H, E -> <- Leg 3 B, H, E ->
) )
( (
( ) ( )
Figure 5: Segments and Tracks Figure 7: Segments and Tracks
Note that while this specification enables to build both Segments Note that while this specification enables to build both Segments
inside a Leg (aka East-West), such as Segment 2 above which is within inside a Leg (aka East-West), such as Segment 2 above which is within
Leg 1, and Inter-Leg Segments (aka North-South), such as Segment 2 Leg 1, and Inter-Leg Segments (aka North-South), such as Segment 2
above which joins Leg 1 and Leg 2, it does not signal to the Ingress above which joins Leg 1 and Leg 2, it does not signal to the Ingress
which Inter-Leg Segments are available, so the use of North-South which Inter-Leg Segments are available, so the use of North-South
Segments and associated PAREO functions is curently limited. The Segments and associated PAREO functions is curently limited. The
only possibility available at this time is to define overlapping Legs only possibility available at this time is to define overlapping Legs
as illustrated in Figure 5, with Leg 3 that is congruent with Leg 1 as illustrated in Figure 7, with Leg 3 that is congruent with Leg 1
till node B and congruent with Leg 2 from node H on, abstracting till node B and congruent with Leg 2 from node H on, abstracting
Segment 5 as an East-West Segment. Segment 5 as an East-West Segment.
DetNet Forwarding Nodes only understand the simple 1-to-1 forwarding
sublayer transport operation along a segment whereas the more
sophisticated Relay nodes can also provide service sublayer functions
such as Replication and Elimination. One possible mapping between
DetNet and this specification is to signal the Relay Nodes as the
hops of a Leg and the forwarding Nodes as the hops in a Segment that
join the Relay nodes as illustrated in Figure 5.
3.7. Scope and Expectations 3.7. Scope and Expectations
3.7.1. External Dependencies
This specification expects that the RPL Main DODAG is operated in RPL This specification expects that the RPL Main DODAG is operated in RPL
Non-Storing Mode to sustain the exchanges with the Root. Based on Non-Storing Mode to sustain the exchanges with the Root. Based on
its comprehensive knowledge of the parent-child relationship, the its comprehensive knowledge of the parent-child relationship, the
Root can form an abstracted view of the whole DODAG topology. This Root can form an abstracted view of the whole DODAG topology. This
document adds the capability for nodes to advertise additional 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 enable 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 OAM.
3.7.2. Positioning vs. Related IETF Standards
3.7.2.1. Extending 6TiSCH
The "6TiSCH Architecture" [6TiSCH-ARCHI] leverages a centralized The "6TiSCH Architecture" [6TiSCH-ARCHI] leverages a centralized
model that is similar to that of "Deterministic Networking model that is similar to that of "Deterministic Networking
Architecture" [RFC8655], whereby the device resources and Architecture" [RFC8655], whereby the device resources and
capabilities are exposed to an external controller which installs capabilities are exposed to an external controller which installs
routing states into the network based on its own objective functions routing states into the network based on its own objective functions
that reside in that external entity. With DetNet and 6TiSCH, the that reside in that external entity.
component of the controller that is responsible of computing routes
is a PCE. The PCE computes its routes based on its own objective
functions such as described in [RFC4655], and typically controls the
routes using the PCE Protocol (PCEP) by [RFC5440]. While this
specification expects a PCE and while PCEP might effectively be used
between the Root and the PCE, the control protocol between the PCE
and the Root is out of scope.
This specification expects a single PCE with a full view of the 3.7.2.2. Mapping to DetNet
DetNet Forwarding Nodes only understand the simple 1-to-1 forwarding
sublayer transport operation along a segment whereas the more
sophisticated Relay nodes can also provide service sublayer functions
such as Replication and Elimination.
One possible mapping between DetNet and this specification is to
signal the Relay Nodes as the hops of a Leg and the forwarding Nodes
as the hops in a Segment that join the Relay nodes as illustrated in
Figure 7.
3.7.2.3. Leveraging PCE
With DetNet and 6TiSCH, the component of the controller that is
responsible of computing routes is a PCE. The PCE computes its
routes based on its own objective functions such as described in
[RFC4655], and typically controls the routes using the PCE Protocol
(PCEP) by [RFC5440]. While this specification expects a PCE and
while PCEP might effectively be used between the 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
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 may 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 abstracted by / mapped to RPL inside the DODAG; is out of scope and abstracted by / mapped to RPL inside the DODAG;
one possibility is for the Root to transmit the RPL DAOs with the one possibility is for the Root to transmit the RPL DAOs with the
SIOs that detail the parent/child and sibling information. SIOs that detail the parent/child and sibling information.
The algorithm to compute the paths and the protocol used by the PCE The algorithm to compute the paths and the protocol used by the PCE
and the metrics and link statistics involved in the computation are and the metrics and link statistics involved in the computation are
also out of scope. The effectiveness of the route computation by the also out of scope. The effectiveness of the route computation by the
PCE depends on the quality of the metrics that are reported from the PCE depends on the quality of the metrics that are reported from the
RPL network. Which metrics are used and how they are reported is out RPL network. Which metrics are used and how they are reported is out
of scope, but the expectation is that they are mostly of long-term, of scope, but the expectation is that they are mostly of long-term,
statistical nature, and provide visibility on link throughput, statistical nature, and provide visibility on link throughput,
latency, stability and availability over relatively long periods. latency, stability and availability over relatively long periods.
3.7.2.4. Providing for RAW
The "Reliable and Available Wireless (RAW) Architecture/Framework" The "Reliable and Available Wireless (RAW) Architecture/Framework"
[RAW-ARCHI] extends the definition of Track, as being composed of [RAW-ARCHI] extends the definition of Track, as being composed of
East-West directional segments and North-South bidirectional East-West directional segments and North-South bidirectional
segments, to enable additional path diversity, using Packet ARQ, segments, to enable additional path diversity, using Packet ARQ,
Replication, Elimination, and Overhearing (PAREO) functions over the Replication, Elimination, and Overhearing (PAREO) functions over the
available paths, to provide a dynamic balance between the reliability available paths, to provide a dynamic balance between the reliability
and availability requirements of the flows and the need to conserve and availability requirements of the flows and the need to conserve
energy and spectrum. This specification prepares for RAW by setting energy and spectrum. This specification prepares for RAW by setting
up the Tracks, but only forms DODAGs, which are composed of up the Tracks, but only forms DODAGs, which are composed of
aggregated end-to-end loose source routed Legs, joined by strict aggregated end-to-end loose source routed Legs, joined by strict
skipping to change at page 31, line 10 skipping to change at page 35, line 28
not provide the policies that would decide which flows are routed not provide the policies that would decide which flows are routed
through which Track. In a Non-Storing Mode RPL Instance, the Main through which Track. In a Non-Storing Mode RPL Instance, the Main
DODAG provides a default route via the Root, and the Tracks provide DODAG provides a default route via the Root, and the Tracks provide
more specific routes to the Track Targets. more specific routes to the Track Targets.
4. Extending existing RFCs 4. Extending existing RFCs
4.1. Extending RFC 6550 4.1. Extending RFC 6550
This specification extends RPL [RPL] to enable the Root to install This specification extends RPL [RPL] to enable the Root to install
East-West routes inside a Main DODAG that is operated as non-Storing East-West routes inside a Main DODAG that is operated as Non-Storing
Mode. A Projected DAO (P-DAO) message (see Section 4.1.1) contains a Mode. A Projected DAO (P-DAO) message (see Section 4.1.1) contains a
new Via Information Option that installs a strict or a loose sequence new Via Information Option that installs a strict or a loose sequence
of hops to form respectively a Track Segment or a Track Leg. A new of hops to form respectively a Track Segment or a Track Leg. A new
P-DAO Request (PDR) message (see Section 5.1) enables a Track Ingress P-DAO Request (PDR) message (see Section 5.1) enables a Track Ingress
to request the Track from the Root for which it is the Root and it to request the Track from the Root. The resulting Track is also a
owns the address that serves as TrackID, as well as the associated DODAG for which the Track Ingress is the Root, the owner the address
namespace from which it selects the TrackID. In the context of this that serves as DODAGID and authoritative for the associated namespace
from which the TrackID is selected. In the context of this
specification, the installed route appears as a more specific route specification, the installed route appears as a more specific route
to the Track Targets, and the Track Ingress routes the packets to the Track Targets, and the Track Ingress routes the packets
towards the Targets via the Track using the longest match as usual. towards the Targets via the Track using the longest match as usual.
To ensure that the PDR and P-DAO messages can flow at most times, it To ensure that the PDR and P-DAO messages can flow at most times, it
is RECOMMENDED that the nodes involved in a Track mantain multiple is RECOMMENDED that the nodes involved in a Track mantain 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 ot the Root uses diverse source route paths to retry similar messages ot
the nodes in the Track. the nodes in the Track.
skipping to change at page 31, line 43 skipping to change at page 36, line 19
(TIO), which can be placed in RPL messages such as the destination (TIO), which can be placed in RPL messages such as the destination
Advertisement Object (DAO). A DAO message signals routing Advertisement Object (DAO). A DAO message signals routing
information to one or more Targets indicated in RTOs, providing one information to one or more Targets indicated in RTOs, providing one
hop information at a time in the TIO. A Projected DAO (P-DAO) is a hop information at a time in the TIO. A Projected DAO (P-DAO) is a
special DAO message generated by the Root to install a P-Route formed special DAO message generated by the Root to install a P-Route formed
of multiple hops in its DODAG. This provides a RPL-based method to of multiple hops in its DODAG. This provides a RPL-based method to
install the Tracks as expected by the 6TiSCH Architecture install the Tracks as expected by the 6TiSCH Architecture
[6TiSCH-ARCHI] as a collection of multiple P-Routes. [6TiSCH-ARCHI] as a collection of multiple P-Routes.
The P-DAO is signaled with a new "Projected DAO" (P) flag, see The P-DAO is signaled with a new "Projected DAO" (P) flag, see
Figure 6. The 'P' flag is encoded in bit position 2 (to be confirmed Figure 8. The 'P' flag is encoded in bit position 2 (to be confirmed
by IANA) of the Flags field in the DAO Base Object. The Root MUST by IANA) of the Flags field in the DAO Base Object. The Root MUST
set it to 1 in a Projected DAO message. Otherwise it MUST be set to set it to 1 in a Projected DAO message. Otherwise it MUST be set to
0. It is set to 0 in Legacy implementations as specified 0. It is set to 0 in Legacy implementations as specified
respectively in Sections 20.11 and 6.4 of [RPL] respectively in Sections 20.11 and 6.4 of [RPL]
The P-DAO is control plane signaling and should not be stuck behind The P-DAO is control plane signaling and should not be stuck behind
high traffic levels. The expectation is that the P-DAO message is high traffic levels. The expectation is that the P-DAO message is
sent as high QoS level, above that of data traffic, typically with sent as high QoS level, above that of data traffic, typically with
the Network Control precedence. the Network Control precedence.
skipping to change at page 32, line 21 skipping to change at page 36, line 46
+ + + +
| DODAGID field set to the | | DODAGID field 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 6: 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.2 as Track, more in Section 6.3
P: 1-bit flag (position to be confirmed by IANA). P: 1-bit flag (position to be confirmed by IANA).
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 Projected DAO,
and it is set to 0 otherwise. and it is set to 0 otherwise.
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. Options may are formed by the directed parent-child relationships. The DAO
be factorized; multiple RTOs may be present to signal a collection of message signals to the Root that a given parent can be used to reach
children that can be reached via the parent(s) indicated in the a given child. The P-DAO message generalizes the DAO to signal to
TIO(s) that follows the RTOs. This specification generalizes the the Track Ingress that a Track for which it is Root can be used to
case of a parent that can be used to reach a child with that of a reach children and siblings of the Track Egress. In both cases,
whole Track through which children and siblings of the Track Egress options may be factorized and multiple RTOs may be present to signal
are reachable. a collection of children that can be reached through the parent or
the Track, respectively.
4.1.2. Via Information Option 4.1.2. Via Information Option
New CMOs called the Via Information Options (VIO) are introduced for New CMOs called the Via Information Options (VIO) are introduced for
use in P-DAO messages as a multihop alternative to the TIO, more in use in P-DAO messages as a multihop alternative to the TIO, more in
Section 5.3. One VIO is the stateful Storing Mode VIO (SM-VIO); an Section 5.3. One VIO is the stateful Storing Mode VIO (SM-VIO); an
SM-VIO installs a strict hop-by-hop P-Route called a Track Segment. SM-VIO installs a strict hop-by-hop P-Route called a Track Segment.
The other is the Non-Storing Mode VIO (NSM-VIO); the NSM-VIO installs The other is the Non-Storing Mode VIO (NSM-VIO); the NSM-VIO installs
a loose source-routed P-Route called a Track Leg at the Track a loose source-routed P-Route called a Track Leg at the Track
Ingress, which uses that state to encapsulate a packet IPv6_in_IPv6 Ingress, which uses that state to encapsulate a packet IPv6_in_IPv6
with a new Routing Header (RH) to the Track Egress, more in with a new Routing Header (RH) to the Track Egress, more in
Section 6.6. Section 6.7.
A P-DAO contains one or more RTOs to indicate the Target A P-DAO contains one or more RTOs to indicate the Target
(destinations) that can be reached via the P-Route, followed by (destinations) that can be reached via the P-Route, followed by
exactly one VIO that signals the sequence of nodes to be followed, exactly one VIO that signals the sequence of nodes to be followed,
more in Section 6. There are two modes of operation for the more in Section 6. There are two modes of operation for the
P-Routes, the Storing Mode and the Non-Storing Mode, see P-Routes, the Storing Mode and the Non-Storing Mode, see
Section 6.3.2 and Section 6.3.3 respectively for more. Section 6.4.2 and Section 6.4.3 respectively for more.
4.1.3. Sibling Information Option 4.1.3. Sibling Information Option
This specification adds another CMO called the Sibling Information This specification adds another CMO called the Sibling Information
Option (SIO) that is used by a RPL Aware Node (RAN) to advertise a Option (SIO) that is used by a RPL Aware Node (RAN) to advertise a
selection of its candidate neighbors as siblings to the Root, more in selection of its candidate neighbors as siblings to the Root, more in
Section 5.4. The SIO is placed in DAO messages that are sent Section 5.4. The SIO is placed in DAO messages that are sent
directly to the Root of the main DODAG. directly to the Root of the main DODAG.
4.1.4. P-DAO Request 4.1.4. P-DAO Request
skipping to change at page 34, line 14 skipping to change at page 38, line 35
Projected-Route 'P': 1-bit flag. It is set to 1 in the RPI that is Projected-Route 'P': 1-bit flag. It is set to 1 in the RPI that is
added in the encapsulation when a packet is sent over a Track. It added in the encapsulation when a packet is sent over a Track. It
is set to 0 when a packet is forwarded along the main Track, is set to 0 when a packet is forwarded along the main Track,
including when the packet follows a Segment that joins loose hops including when the packet follows a Segment that joins loose hops
of the Main DODAG. The flag is not mutable en-route. of the Main DODAG. The flag is not mutable en-route.
The encoding of the 'P' flag in native format is shown in Section 4.2 The encoding of the 'P' flag in native format is shown in Section 4.2
while the compressed format is indicated in Section 4.3. while the compressed format is indicated in Section 4.3.
4.1.6. Additional Flag in the RPL DODAG Configuration Option
The DODAG Configuration Option is defined in Section 6.7.6 of [RPL].
Its purpose is extended to distribute configuration information
affecting the construction and maintenance of the DODAG, as well as
operational parameters for RPL on the DODAG, through the DODAG. This
Option was originally designed with 4 bit positions reserved for
future use as Flags.
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type = 0x04 |Opt Length = 14|D| | | |A| ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +
|4 bits |
Figure 9: DODAG Configuration Option (Partial View)
This specification defines a new flag "Projected Routes Support" (D).
The 'D' flag is encoded in bit position 0 of the reserved Flags in
the DODAG Configuration Option (this is the most significant bit)(to
be confirmed by IANA but 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].
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
Tracks when feasible upon a PDR message.
Section 4.1.2. of [RFC9008] updates [RPL] to indicate that the
definition of the Flags applies to Mode of Operation values from zero
(0) to six (6) only. For a MOP value of 7, the implementation MUST
consider that the Root accepts PDR messages and will install
Projected Routes.
The RPL DODAG Configuration option is typically placed in a DODAG
Information Object (DIO) message. The DIO message propagates down
the DODAG to form and then maintain its structure. The DODAG
Configuration option is copied unmodified from parents to children.
xref target='RFC6550'/> states that:
| Nodes other than the DODAG root MUST NOT modify this information
| when propagating the DODAG Configuration option.
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
to all the nodes in the DODAG.
4.2. Extending RFC 6553 4.2. Extending RFC 6553
"The RPL Option for Carrying RPL Information in Data-Plane Datagrams" "The RPL Option for Carrying RPL Information in Data-Plane Datagrams"
[RFC6553]describes the RPL Option for use among RPL routers to [RFC6553]describes the RPL Option for use among RPL routers to
include the abstract RPL Packet Information (RPI) described in include the abstract RPL Packet Information (RPI) described in
section 11.2. of [RPL] in data packets. section 11.2. of [RPL] in data packets.
The RPL Option is commonly referred to as the RPI though the RPI is The RPL Option is commonly referred to as the RPI though the RPI is
really the abstract information that is transported in the RPL really the abstract information that is transported in the RPL
Option. [RFC9008] updated the Option Type from 0x63 to 0x23. Option. [RFC9008] updated the Option Type from 0x63 to 0x23.
skipping to change at page 34, line 38 skipping to change at page 40, line 15
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 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 7: Extended RPL Option Format Figure 10: Extended RPL Option Format
Option Type: 0x23 or 0x63, see [RFC9008] Option Type: 0x23 or 0x63, see [RFC9008]
Opt Data Len: See [RFC6553] Opt Data Len: See [RFC6553]
'O', 'R' and 'F' flags: See [RFC6553]. Those flags MUST be set to 0 'O', 'R' and 'F' flags: See [RFC6553]. Those flags MUST be set to 0
by the sender and ignored by the receiver if the 'P' flag is set. by the sender and ignored by the receiver if the 'P' flag is set.
Projected-Route 'P': 1-bit flag as defined in Section 4.1.5. Projected-Route 'P': 1-bit flag as defined in Section 4.1.5.
skipping to change at page 35, line 37 skipping to change at page 41, line 20
is ready to be placed as is in the packet encapsulation by the Track is ready to be placed as is in the packet encapsulation by the Track
Ingress. Ingress.
Section 6.3 of [RFC8138] presents the formats of the 6LoWPAN Routing Section 6.3 of [RFC8138] presents the formats of the 6LoWPAN Routing
Header of type 5 (RPI-6LoRH) that compresses the RPI for normal RPL Header of type 5 (RPI-6LoRH) that compresses the RPI for normal RPL
operation. The format of the RPI-6LoRH is not suited for P-Routes operation. The format of the RPI-6LoRH is not suited for P-Routes
since the O,R,F flags are not used and the Rank is unknown and since the O,R,F flags are not used and the Rank is unknown and
ignored. ignored.
This specification introduces a new 6LoRH, the P-RPI-6LoRH that can This specification introduces a new 6LoRH, the P-RPI-6LoRH that can
be used in either Elective or Critical 6LoRH form, see Table 21 and be used in either Elective or Critical 6LoRH form, see Table 22 and
Table 22 respectively. The new 6LoRH MUST be used as a Critical Table 23 respectively. The new 6LoRH MUST be used as a Critical
6LoRH, unless an SRH-6LoRH is present and controls the routing 6LoRH, unless an SRH-6LoRH is present and controls the routing
decision, in which case it MAY be used in Elective form. 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 8: P-RPI-6LoRH Format
Figure 11: P-RPI-6LoRH Format
Type: IANA is requested to define the same value of the type for Type: IANA is requested to define the same value of the type for
both Elective and Critical forms. A type of 8 is suggested. both Elective and Critical forms. A type of 8 is suggested.
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 Section 3.4 and
Section 6.2 . Section 6.3 .
Section 6.7 details how a a Track Ingress leverages the P-RPI-6LoRH Section 6.8 details how a 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 P-DAO Request (PDR) message is sent by a Node in the Main DODAG
to the Root. It is a request to establish or refresh a Track where to the Root. It is a request to establish or refresh a Track where
this node is Track Ingress, and signals whether an acknowledgment this node is Track Ingress, and signals whether an acknowledgment
called PDR-ACK is requested or not. A positive PDR-ACK indicates called PDR-ACK is requested or not. A positive PDR-ACK indicates
that the Track was built and that the Roots commits to maintain the that the Track was built and that the Roots commits to maintain the
Track for the negotiated lifetime. Track for the negotiated lifetime.
The Root may use an asynchronous PDR-ACK with an negative status to The Root may use an asynchronous PDR-ACK with an negative status to
indicate that the Track was terminated before its time. A status of indicate that the Track was terminated before its time. A status of
"Transient Failure" (see Section 10.9) is an indication that the PDR "Transient Failure" (see Section 11.10) is an indication that the PDR
may be retried after a reasonable time that depends on the may be retried after a reasonable time that depends on the
deployment. Other negative status values indicate a permanent error; deployment. Other negative status values indicate a permanent error;
the tentative must be abandoned until a corrective action is taken at the tentative must be abandoned until a corrective action is taken at
the application layer or through network management. the application layer or through network management.
The source IPv6 address of the PDR signals the Track Ingress to-be of The source IPv6 address of the PDR signals the Track Ingress to-be of
the requested Track, and the TrackID is indicated in the message the requested Track, and the TrackID is indicated in the message
itself. One and only one RPL Target Option MUST be present in the itself. One and only one RPL Target Option MUST be present in the
message. The RTO signals the Track Egress, more in Section 6.1. message. The RTO signals the Track Egress, more in Section 6.2.
The RPL Control Code for the PDR is 0x09, to be confirmed by IANA. The RPL Control Code for the PDR is 0x09, to be confirmed by IANA.
The format of PDR Base Object is as follows: The format of PDR Base Object is as follows:
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| TrackID |K|R| Flags | ReqLifetime | PDRSequence | | TrackID |K|R| Flags | ReqLifetime | PDRSequence |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Option(s)... | Option(s)...
+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+
Figure 9: New P-DAO Request Format Figure 12: 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.2. To allocate a new Track, Track, see Section 3.4 and Section 6.3. To allocate a new Track,
the Ingress Node must provide a value that is not in use at this the 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 initialized to zero by the Flags: Reserved. The Flags field MUST initialized to zero by the
sender and MUST be ignored by the receiver sender and MUST be ignored by the receiver
skipping to change at page 38, line 15 skipping to change at page 43, line 35
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 10: New PDR-ACK Control Message Format Figure 13: 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 initialized to zero by the Flags: Reserved. The Flags field MUST initialized to zero by the
sender and MUST be ignored by the receiver sender and MUST be ignored by the receiver
Track Lifetime: Indicates that remaining Lifetime for the Track, Track Lifetime: Indicates that remaining Lifetime for the Track,
expressed in Lifetime Units; the value of zero (0x00) indicates expressed in Lifetime Units; the value of zero (0x00) indicates
that the Track was destroyed or not created. that the Track was 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 11: Status is substructured as indicated in Figure 14:
0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7
+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+
|E|R| Value | |E|R| Value |
+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+
Figure 11: PDR-ACK status Format Figure 14: PDR-ACK status Format
E: 1-bit flag. Set to indicate a rejection. When not set, the E: 1-bit flag. Set to indicate a rejection. When not set, the
value of 0 indicates Success/Unqualified Acceptance and other value of 0 indicates Success/Unqualified Acceptance and other
values indicate "not an outright rejection". values indicate "not an outright 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 Status Value: 6-bit unsigned integer. Values depending on the
setting of the 'E' flag, see Table 27 and Table 28. setting of the 'E' flag, see Table 28 and Table 29.
Reserved: The Reserved field MUST initialized to zero by the sender Reserved: The Reserved field MUST initialized to zero by the sender
and MUST be ignored by the receiver and MUST be ignored by the receiver
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 Leg (using Non-Storing Mode) a Segment (using the hops of either a Leg (using Non-Storing Mode) a Segment (using
storing mode) of a Track. A Storing Mode P-DAO contains one Storing storing mode) of a Track. A Storing Mode P-DAO contains one Storing
Mode VIO (SM-VIO) whereas a Non-Storing Mode P-DAO contains one Non- Mode VIO (SM-VIO) whereas a Non-Storing Mode P-DAO contains one Non-
skipping to change at page 39, line 25 skipping to change at page 44, line 43
Lifetime of zero is referred as a No-Path P-DAO. Lifetime of zero 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 header(s), each formed of a
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 a 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 forall the Information Option, and the compression is the same forall the
addresses, as shown in Figure 12, for simplicity. addresses, as shown in Figure 15, 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 make the VIO globally shorter; this means that more SRH-6LoRH Types make the VIO globally shorter; this means that more
than one SRH-6LoRH may be present. than one SRH-6LoRH may be present.
The format of the Via Information Options is as follows: The format of the Via Information Options 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
skipping to change at page 40, line 29 skipping to change at page 45, line 29
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
. 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 12: VIO format (uncompressed form) Figure 15: VIO format (uncompressed form)
Option Type: 0x0E for SM-VIO, 0x0F for NSM-VIO (to be confirmed by Option Type: 0x0E for SM-VIO, 0x0F for NSM-VIO (to be confirmed by
IANA), see =Table 25 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.
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 Serial Track, i.e., made of a single segment/Leg. used to signal a Serial Track, i.e., made of a single segment/Leg.
skipping to change at page 42, line 33 skipping to change at page 47, line 33
Interface ID in its registered address needs report the SIO, and the Interface ID in its registered address needs report the SIO, and the
Root will assume symmetry. Root will assume symmetry.
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| Flags |Comp.| Opaque | | Type | Option Length |S| Flags |Comp.| Opaque |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Step of Rank | Reserved | | Step in Rank | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
+ + + +
. . . .
. Sibling DODAGID (if the D flag not set) . . Sibling DODAGID (if the D flag not set) .
. . . .
+ + + +
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
+ + + +
. . . .
. Sibling Address . . Sibling Address .
. . . .
+ + + +
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 13: Sibling Information Option Format Figure 16: Sibling Information Option Format
Option Type: 0x10 for SIO (to be confirmed by IANA), see =Table 25 Option Type: 0x10 for SIO (to be confirmed by 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]. 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 zero by the sender and MUST be
ignored by the receiver. ignored by the receiver.
S: 1-bit flag that is set to indicate that sibling belongs to the S: 1-bit flag that is set to indicate that sibling belongs to the
same DODAG. When not set, the Sibling DODAGID is indicated. same DODAG. When not set, the Sibling DODAGID is indicated.
skipping to change at page 43, line 33 skipping to change at page 48, line 33
packets received from the sibling. An industrial Alliance that packets received from the sibling. An industrial Alliance that
uses RPL for a particular use / environment MAY redefine the use uses RPL for a particular use / environment MAY redefine the use
of this field to fit its needs. of this field to fit its needs.
Compression Type: 3-bit unsigned integer. This is the SRH-6LoRH Compression Type: 3-bit unsigned integer. This is the SRH-6LoRH
Type as defined in figure 7 in section 5.1 of [RFC8138] that Type as defined in figure 7 in section 5.1 of [RFC8138] that
corresponds to the compression used for the Sibling Address and corresponds to the compression used for the Sibling Address and
its DODAGID if resent. The Compression reference is the Root of its DODAGID if resent. The Compression reference is the Root of
the Main DODAG. the Main DODAG.
Step of Rank: 16-bit unsigned integer. This is the Step of 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. the sibling, that reflects the abstract Rank increment that would
be computed by the OF if the sibling was the preferred parent.
Reserved: The Reserved field MUST initialized to zero by the sender Reserved: The Reserved field MUST initialized to zero by the sender
and MUST be ignored by the receiver and MUST be ignored by the receiver
Sibling DODAGID: 2 to 16 bytes, the DODAGID of the sibling in a Sibling DODAGID: 2 to 16 bytes, the DODAGID of the sibling in a
[RFC8138] compressed form as indicated by the Compression Type [RFC8138] compressed form as indicated by the Compression Type
field. This field is present 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
skipping to change at page 44, line 11 skipping to change at page 49, line 11
cannot be a Link Local Address. The IPv6 address is encoded in cannot be a Link Local Address. The IPv6 address is encoded in
the [RFC8138] compressed form indicated by the Compression Type the [RFC8138] compressed form indicated by the Compression Type
field. field.
An SIO MAY be immediately followed by a DAG Metric Container. In An SIO MAY be immediately followed by a DAG Metric Container. In
that case the DAG Metric Container provides additional metrics for that case the DAG Metric Container provides additional metrics for
the hop from the Sibling to this node. the hop from the Sibling to this node.
6. Root Initiated Routing State 6. Root Initiated Routing State
6.1. Requesting a Track 6.1. RPL Network Setup
To avoid the need of Path MTU Discovery, 6LoWPAN links are normally
defined with a MTU of 1280 (see section 4 of [6LoWPAN]). Injecting
packets in a Track typically involves an IP-in-IP encapsulation and
additional IPv6 Extension Headers. This may cause a fragmentation if
the resulting packets exceeds the MTU that is defined for the RPL
domain.
Though fragmentation is possible in a 6LoWPAN LLN, e.g., using
[6LoWPAN], [RFC8930], and/or [RFC8931], it is RECOMMENDED to allow an
MTU that is larger than 1280 in the main DODAG and allows for the
additional headers while exposing only 1280 to the 6LoWPAN Nodes.
6.2. Requesting a Track
This specification introduces the PDR message, used by an LLN node to This specification introduces the PDR message, used by an LLN node to
request the formation of a new Track for which this node is Ingress. request the formation of a new Track for which this node is Ingress.
Note that the namespace for the TrackID is owned by the Ingress node, Note that the namespace for the TrackID is owned by the Ingress node,
and in the absence of a PDR, there must be some procedure for the and in the absence of a PDR, there must be some procedure for the
Root to assign TrackIDs in that namespace while avoiding collisions, Root to assign TrackIDs in that namespace while avoiding collisions,
more in Section 6.2. 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 a
same mode, either Storing or Non-Storing. All the Segments MUST be same mode, either Storing or Non-Storing. All the Segments MUST be
created with the same TrackID and the same DODAGID signaled in the 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 best, and updates / changes the
skipping to change at page 45, line 5 skipping to change at page 50, line 16
elapse - vs. the trip time from the node to the Root, the requesting elapse - vs. the trip time from the node to the Root, the requesting
node SHOULD resend a PDR using the TrackID in the PDR-ACK to extend node SHOULD resend a PDR using the TrackID in the PDR-ACK to extend
the lifetime of the Track, else the Track will time out and the Root the lifetime of the Track, else the Track will time out and the Root
will tear down the whole structure. 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.2. 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 draft leverages the RPL Instance model as follows: This draft leverages the RPL Instance model as follows:
* The Root MAY use P-DAO messages to add better routes in the main * The Root MAY use P-DAO messages to add better routes in the main
(Global) RPL Instance in conformance with the routing objectives (Global) RPL Instance in conformance with the routing objectives
skipping to change at page 45, line 46 skipping to change at page 51, line 12
serves as TrackID. The TrackID MUST be unique for the IPv6 ULA or serves as TrackID. The TrackID MUST be unique for the IPv6 ULA or
GUA of the Track Ingress that serves as DODAGID for the Track. GUA of the Track Ingress that serves as DODAGID for the 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 when used in
an RPI that the source address of the IPv6 packet signals the an RPI that 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 6, 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 12. in Figure 15.
The Track Ingress is the root of the DODAG ID formed by the local The Track Ingress is the Root of the DODAG ID 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 PDR are not used, the namespace can be particular deployment where PDR are not used, the namespace can be
delegated to the main Root, which can assign the TrackIDs for the delegated to the main Root, which can assign the TrackIDs for the
Tracks it creates without collision. Tracks it creates without collision.
With this specification, the Root is aware of all the active With this specification, the 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 Root and the Track without a PDR. To avoid a collision of the Root and the Track
Ingress picking the same value at the same time, it is RECOMMENDED Ingress picking the same value at the same time, it is RECOMMENDED
that the Track Ingress starts allocating the ID value of the Local that the Track Ingress starts allocating the ID value of the Local
RPLInstanceID (see section 5.1. of [RPL]) used as TrackIDs with RPLInstanceID (see section 5.1. of [RPL]) used as TrackIDs with
the value 0 incrementing, while the Root starts with 63 the value 0 incrementing, while the Root starts with 63
decrementing. decrementing.
6.3. Installing a Track 6.4. Installing a Track
A Serial Track can be installed by a single P-Route that signals the A Serial Track can be installed by a single P-Route that signals the
sequence of consecutive nodes, either in Storing Mode as a single- sequence of consecutive nodes, either in Storing Mode as a single-
Segment Track, or in Non-Storing Mode as a single-Leg Track. A Segment Track, or in Non-Storing Mode as a single-Leg Track. A
single-Leg Track can be installed as a loose Non-Storing Mode single-Leg Track can be installed as a loose Non-Storing 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 Serial Track. reached over a Serial Track.
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
skipping to change at page 47, line 10 skipping to change at page 52, line 23
* There SHOULD NOT be 2 different Tracks leading to the same Target * There SHOULD NOT be 2 different Tracks leading to the same Target
from same Ingress node, unless there's a policy for selecting from same Ingress node, unless there's a policy for selecting
which packets use which Track; such policy is out of scope. which packets use which Track; such 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.3.1. Signaling a Projected Route 6.4.1. Signaling a Projected Route
This draft adds a capability whereby the Root of a main RPL DODAG This draft adds a capability whereby the Root of a main RPL 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 Projected-DAO
(P-DAO) message for each individual Track Leg or Segment. The P-DAO (P-DAO) message for each individual Track Leg or Segment. The P-DAO
signals a collection of Targets in the RPL Target Option(s) (RTO). signals a collection of Targets in the RPL Target Option(s) (RTO).
Those Targets can be reached via a sequence of routers indicated in a Those Targets can be reached via a sequence of routers indicated in a
VIO. 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
skipping to change at page 48, line 5 skipping to change at page 53, line 10
A P-DAO that creates or updates a Track Leg MUST be sent to a GUA or A P-DAO that creates or updates a Track Leg MUST be sent to a GUA or
a ULA of the Ingress of the Leg; it must contain the full list of a ULA of the Ingress of the Leg; it must contain the full list of
hops in the Leg unless the Leg is being removed. A P-DAO that hops in the Leg unless the Leg is being removed. A P-DAO that
creates a new Track Segment MUST be sent to a GUA or a ULA of the creates a new Track Segment MUST be sent to a GUA or a ULA of the
Segment Egress and MUST signal the full list of hops in Segment; a Segment Egress and MUST signal the full list of hops in Segment; a
P-DAO that updates (including deletes) a section of a Segment MUST be P-DAO that updates (including deletes) a section of a Segment MUST be
sent to the first node after the modified Segment and signal the full sent to the first node after the modified Segment and signal the full
list of hops in the section starting at the node that immediately list of hops in the section starting at the node that immediately
precedes the modified section. precedes the modified section.
In Non-Storing Mode, as discussed in Section 6.3.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.3.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 Leg, Segment, or updated section of the Segment is the node of the Leg, Segment, or updated section of the Segment is the
node that sends the acknowledgment. The exception to the rule is node that sends the acknowledgment. The exception to the rule is
when an intermediate node in a Segment fails to forward a Storing when an intermediate node in a Segment fails to forward a Storing
Mode P-DAO to the previous node in the SM-VIO. 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 one of these A node that processes a VIO MAY verify whether one of these
conditions happen, and when so, it MUST ignore the P-DAO and reject conditions happen, and when so, it MUST ignore the P-DAO and reject
it with a RPL Rejection Status of "Error in VIO" in the DAO-ACK, see it with a RPL Rejection Status of "Error in VIO" in the DAO-ACK, see
Section 10.14. Section 11.15.
Other errors than those discussed explicitely that prevent the Other errors than those discussed explicitely that prevent the
installing the route are acknowledged with a RPL Rejection Status of installing the route are acknowledged with a RPL Rejection Status of
"Unqualified Rejection" in the DAO-ACK. "Unqualified Rejection" in the DAO-ACK.
6.3.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 14, a Storing Mode P-DAO installs a route As illustrated in Figure 17, 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, that may be the one formed
by the RPL Main DODAG, or a Track associated with a local RPL by the RPL Main DODAG, or a Track associated with a local RPL
Instance. Instance.
------+--------- ------+---------
| Internet | Internet
| |
+-----+ +-----+
skipping to change at page 49, line 22 skipping to change at page 54, line 22
| | DAO | ACK | | | DAO | ACK |
o o o o | | | o o o o | | |
o o o o o o o o o | ^ | Projected . o o o o o o o o o | ^ | Projected .
o o o o o o o o o o | | DAO | Route . o o 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 o o o o o v | DAO v . o o o o o o 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 14: Projecting a route Figure 17: 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 Root sends a unicast P-DAO message to the Track Egress router of the Root sends a unicast P-DAO message to the Track Egress router of
the routing Segment that is being installed. The P-DAO message the routing Segment that is being installed. The P-DAO message
contains a SM-VIO with the strict sequence of Via Addresses. The SM- contains a SM-VIO with the strict sequence of Via Addresses. The SM-
VIO follows one or more RTOs indicating the Targets to which the VIO follows one or more RTOs indicating the Targets to which the
Track leads. The SM-VIO contains a Segment Lifetime for which the Track leads. The SM-VIO contains a Segment Lifetime for which the
state is to be maintained. state is 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.
skipping to change at page 50, line 32 skipping to change at page 55, line 32
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 till the P-DAO is propagated to Ingress router The process continues till the P-DAO is propagated to Ingress router
of the Segment, which answers with a DAO-ACK to the Root. The Root 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 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.3.3. Installing a Track Leg with a Non-Storing Mode P-Route 6.4.3. Installing a Track Leg with a Non-Storing Mode P-Route
As illustrated in Figure 15, a Non-Storing Mode P-DAO installs a As illustrated in Figure 18, 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 to add the SRH to an existing packet. It is
sent to the Track Ingress which creates a tunnel associated with the sent to the Track Ingress which creates a tunnel associated with the
Track, and connected routes over the tunnel to the Targets in the Track, and connected routes over the tunnel to the Targets in the
RTO. The tunnel encapsulation MUST incorporate a routing header via RTO. The tunnel encapsulation MUST incorporate a routing header via
the list addresses listed in the VIO in the same order. The content the list addresses listed in the VIO in the same order. The content
of the NSM-VIO starting at the first SRH-6LoRH header MUST be used of the NSM-VIO starting at the first SRH-6LoRH header MUST be used
verbatim by the Track Ingress when it encapsulates a packet to verbatim by the Track Ingress when it encapsulates a packet to
skipping to change at page 51, line 23 skipping to change at page 56, line 23
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 15: Projecting a Non-Storing Route Figure 18: 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 Leg(s) of instance, a Segment of a Track must be installed before the Leg(s) of
the same Track that use it, and stitched Segments must be installed the same Track that use it, and stitched Segments must be installed
in order from the last that reaches to the Targets to the first. in order from the last that reaches to the Targets to the first.
skipping to change at page 52, line 5 skipping to change at page 57, line 5
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 a de- and a 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 examplified 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-DAO 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.4. 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 Legs that compose it one by must tear down all the Track Segments and Legs that compose it one by
one. one.
Since the state about a Leg of a Track is located only the Ingress Since the state about a Leg of a Track is located only on the Ingress
Node, the Root cleans up the Leg by sending an NSM-VIO to the Ingress Node, the Root cleans up the Leg by sending an NSM-VIO to the Ingress
indicating the TrackID and the P-RouteID of the Leg being removed, a indicating the TrackID and the P-RouteID of the Leg being removed, a
Segment Lifetime of 0 and a newer Segment Sequence. The SRH-6LoRH Segment Lifetime of 0 and a newer Segment Sequence. The SRH-6LoRH
with the Via Addresses in the NSM-VIO are not needed and MUST be with the Via Addresses in the NSM-VIO are not needed; it SHOULD not
omitted. Upon that NSM-VIO, the Ingress node removes all state for be placed in the message and MUST be ignored by the receiver. Upon
that Track if any, and replies positively anyway. that NSM-VIO, the Ingress node removes all state for that Track if
any, and replies positively 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 the TrackID and the P-RouteID of the
Segment being updated, a Segment Lifetime of zero (0) and a newer Segment being updated, a Segment Lifetime of zero (0) and a newer
Segment Sequence. The Via Addresses in the SM-VIO indicates the Segment Sequence. The Via Addresses in the SM-VIO indicates the
section of the Segment being modified, from the first to the last section of the Segment being modified, from the first to the last
node that is impacted. This can be the whole Segment if it is node that is impacted. This can be the whole Segment if it is
totally removed, or a sequence of one or more nodes that have been totally removed, or a sequence of one or 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.5. Maintaining a Track 6.6. Maintaining a Track
Repathing a Track Segment or Leg may cause jitter and packet Repathing a Track Segment or Leg may cause jitter and packet
misordering. For critical flows that require timely and/or in-order misordering. For critical flows that require timely and/or in-order
delivery, it might be necessary to deploy the PAREO functions delivery, it might be necessary to deploy the PAREO functions
[RAW-ARCHI] over a highly redundant Track. This specification allows [RAW-ARCHI] over a highly redundant Track. This specification allows
to use more than one Leg for a Track, and 1+N packet redundancy. to use more than one Leg for a 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 when the packets in-flight are forwarded along the new
section as well. section as well.
6.5.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 a first node and a second,
downstream node (which can be the Ingress and Egress), while downstream node (which can be the Ingress and Egress), while
conserving those nodes in the Segment, the Root sends an SM-VIO to conserving those nodes in the Segment, the Root sends an SM-VIO to
the second node indicating the sequence of nodes in the new section the second node indicating the sequence of nodes in the new section
of the Segment. The SM-VIO indicates the TrackID and the P-RouteID of the Segment. The SM-VIO indicates the TrackID and the P-RouteID
of the Segment being updated, and a newer Segment Sequence. The 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 way, 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 the 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 empty, After a reasonable time to enable the deprecated sections to empty,
the root tears down the remaining section(s) of the old segments are the Root tears down the remaining section(s) of the old segments are
teared down as described in Section 6.4. teared down as described in Section 6.5.
6.5.2. Maintaining a Track Leg 6.6.2. Maintaining a Track Leg
This specification allows to add Legs to a Track by sending a Non- This specification allows the Root to add Legs to a Track by sending
Storing Mode P-DAO to the Ingress associated to the same TrackID, and a Non-Storing Mode P-DAO to the Ingress associated to the same
a new Segment ID. If the Leg is loose, then the Segments that join TrackID, and a new Segment ID. If the Leg is loose, then the
the hops must be created first. It makes sense to add a new Leg Segments that join the hops must be created first. It makes sense to
before removing one that is misbehaving, and switch to the new Leg add a new Leg before removing one that is becoming excessively lossy,
before removing the old. and switch to the new Leg before removing the old. Dropping a Track
before the new one is installed would reroute the traffic via the
root; this may augment the latency beyond acceptable thresholds, and
load the network near the root. This may also cause loops in the
case of stitched Tracks; the packets that cannot be injected in the
second Track may be routed back at reinjected at the Ingress of the
first.
It is also possible to update a Track Leg by sending a Non-Storing It is also possible to update a Track Leg by sending a Non-Storing
Mode P-DAO to the Ingress with the same Segment ID, an incremented Mode P-DAO to the Ingress with the same Segment ID, an incremented
Segment Sequence, and the new complete listy of hops in the NSM-VIO. Segment Sequence, and the new complete list of hops in the NSM-VIO.
Updating a live Leg means changing one or more of the intermediate Updating a live Leg means changing one or more of the intermediate
loose hops, and involves laying out new Segments from and to the new loose hops, and involves laying out new Segments from and to the new
loose hops before the NSM-VIO for the new Leg is issued. loose hops before the NSM-VIO for the new Leg is issued.
Packets that are in flight over the old version of the Track Leg Packets that are in flight over the old version of the Track Leg
still follow the old source route path over the old Segments. After still follow the old source route path over the old Segments. After
a reasonable time to enable the deprecated Segments to empty, the a reasonable time to enable the deprecated Segments to empty, the
root tears down those Segments as described in Section 6.4. Root tears down those Segments as described in Section 6.5.
6.6. Encapsulating and Forwarding Along a Track 6.7. Encapsulating and Forwarding Along a Track
When forwarding a packet to a destination for which a router When injecting a packet in a Track, the Ingress router must
determines that routing happens via a Track for which it is Ingress, encapsulate the packet using IP-in-IP to add the Source Routing
the router must encapsulated the packet using IP-in-IP to add the Header with the final destination set to the Track Egress.
Source Routing Header with the final destination set to the Track
Egress. Though fragmentation is possible in a 6LoWPAN LLN, e.g.,
using [6LoWPAN], [RFC8930], and/or [RFC8931], it is RECOMMENDED to
allow an MTU that is larger than 1280 in the main DODAG and allows
for the additional headers while exposing only 1280 to the 6LoWPAN
Nodes as indicated by section 4 of [6LoWPAN].
All properties of a Track operations are inherited form the main RPL All properties of a Track operations are inherited form the main RPL
Instance that is used to install the Track. For instance, the use of Instance that is used to install the Track. For instance, the use of
compression per [RFC8138] is determined by whether it is used in the compression per [RFC8138] is determined by whether it is used in the
RPL Main DODAG, e.g., by setting the "T" flag [TURN-ON_RFC8138] in RPL Main DODAG, e.g., by setting the "T" flag [TURN-ON_RFC8138] in
the RPL configuration option. the RPL configuration option.
The Track Ingress that places a packet in a Track encapsulates it The Track Ingress that places a packet in a Track encapsulates it
with an IP-in-IP header, a Routing Header, and an IPv6 Hop-by-Hop with an IP-in-IP header, a Routing Header, and an IPv6 Hop-by-Hop
Option Header that contains the RPL Packet Information (RPI) as Option Header that contains the RPL Packet Information (RPI) as
skipping to change at page 55, line 11 skipping to change at page 60, line 7
respectively signaled as the IPv6 Source Address and the respectively signaled as the IPv6 Source Address and the
RPLInstanceID field of the RPI that MUST be placed in the outer RPLInstanceID field of the RPI that MUST be placed in the outer
chain of IPv6 Headers. chain of IPv6 Headers.
The RPI carries a local RPLInstanceID called the TrackID, which, The RPI carries a local RPLInstanceID called the TrackID, which,
in association with the DODAGID, indicates the Track along which in association with the DODAGID, indicates the Track along which
the packet is forwarded. the packet is forwarded.
The D flag in the RPLInstanceID MUST be set to 0 to indicate that The D flag in the RPLInstanceID MUST be set to 0 to indicate that
the source address in the IPv6 header is set ot the DODAGID, more the source address in the IPv6 header is set ot the DODAGID, more
in Section 6.2. in Section 6.3.
* This draft conforms to the principles of [RFC9008] with regards to * This draft conforms to the principles of [RFC9008] with regards to
packet forwarding and encapsulation along a Track, as follows: packet forwarding and encapsulation along a Track, as follows:
- With this draft, the Track is a RPL DODAG. From the - With this draft, 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.
skipping to change at page 56, line 14 skipping to change at page 61, line 14
* When a Track Egress extracts a packet from a Track (decapsulates * When a Track Egress extracts a packet from a Track (decapsulates
the packet), the destination of the inner packet must be either the packet), the destination of the inner packet must be either
this node or a direct neighbor, or a Target of another Segment of this node or a direct neighbor, or a Target of another Segment of
the same Track for which this node is Ingress, otherwise the the same Track for which this node is Ingress, otherwise the
packet MUST be dropped. packet MUST be dropped.
In case of a failure forwarding a packet along a Segment, e.g., the In case of a failure forwarding a packet along a Segment, e.g., the
next hop is unreachable, the node that discovers the fault MUST send next hop is unreachable, the node that discovers the fault MUST send
an ICMPv6 Error message [RFC4443] to the Root, with a new Code "Error an ICMPv6 Error message [RFC4443] to the Root, with a new Code "Error
in P-Route" (See Section 10.13). The Root can then repair by in P-Route" (See Section 11.14). 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 ot one or more nodes VIOs with a lifetime of 0 indicating the section ot one or more nodes
being removed (See Section 6.5). 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 a code
"Error in Source Routing Header" back to the source of the packet, as "Error in Source Routing Header" back to the source of the packet, as
described in section 11.2.2.3. of [RPL]. Upon this message, the described in section 11.2.2.3. of [RPL]. Upon this message, the
encapsulating node SHOULD stop using the source route path for a encapsulating node SHOULD stop using the source route path for a
reasonable period of time which duration depends on the deployment, reasonable period of time which duration depends on the deployment,
and it SHOULD send an ICMP message with a Code "Error in P-Route" to and it SHOULD send an ICMP message with a Code "Error in P-Route" to
the Root. Failure to follow these steps may result in packet loss the Root. Failure to follow these steps may result in packet loss
and wasted resources along the source route path that is broken. and wasted resources along the source route path that is broken.
skipping to change at page 56, line 43 skipping to change at page 61, line 43
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 this 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 6LoWPAN Routing Header (6LoRH) [RFC8138] is used to
carry the IPv6 routing information in the outer header then that carry the IPv6 routing information in the outer header then that
whole 6LoRH information SHOULD be present in the ICMP message. whole 6LoRH information SHOULD be present in the ICMP message.
6.7. Compression of the RPL Artifacts 6.8. Compression of the 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 16, representing the case where : is formatted as shown in Figure 19, representing the case where :
+-+ ... -+- ... -+- ... -+-+- ... +-+-+-+ ... +-+-+ ... -+ ... +-... +-+ ... -+- ... -+- ... -+-+- ... +-+-+-+ ... +-+-+ ... -+ ... +-...
|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 16: A Packet as Forwarded along the Main DODAG Figure 19: 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 page selector is actually removed at encapsulation, so the inner
packet used in the descriptions below start with the SRH-6LoRH, and packet used in the descriptions below start with the SRH-6LoRH, and
is verbatim the packet represented in Figure 16 from the second octet is verbatim the packet represented in Figure 19 from the second octet
on. on.
When encapsulating that inner packet to place it in the Track, the When encapsulating that inner packet to place it in the Track, the
first header that the Ingress appends at the head of the inner packet first header that the Ingress appends at the head of the inner packet
is an IP-in-IP 6LoRH Header; in that header, the encapsulator is an IP-in-IP 6LoRH Header; in that header, the encapsulator
address, which maps to the IPv6 source address in the uncompressed address, which maps to the IPv6 source address in the uncompressed
form, contains a GUA or ULA IPv6 address of the Ingress node that form, contains a GUA or ULA IPv6 address of the Ingress node that
serves as DODAG ID for the Track, expressed in the compressed form serves as DODAG ID for the Track, expressed in the compressed form
and using the DODAGID of the Main DODAG as compression reference. If and using the DODAGID of the Main DODAG as compression reference. If
the address is compressed to 2 bytes, the resulting value for the the address is compressed to 2 bytes, the resulting value for the
Length field shown in Figure 17 is 3, meaning that the SRH-6LoRH as a Length field shown in Figure 20 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 17: The IP-in-IP 6LoRH Header Figure 20: 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 8, using the TrackID as RPI-6LoRH Header, as illustrated in Figure 11, 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. to identify 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 SR-VIO that signaled
the selected Track Leg. the selected Track Leg.
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 18: The SRH 6LoRH Header Figure 21: The SRH 6LoRH Header
The format of the resulting encapsulated packet in [RFC8138] The format of the resulting encapsulated packet in [RFC8138]
compressed form is illustrated in Figure 19: compressed form is illustrated in Figure 22:
+-+ ... -+-+-+- ... -+-+-+- ... -+-+-+-+-+- ... +-+-+-+-+-+-+- ... +-+ ... -+-+-+- ... -+-+-+- ... -+-+-+-+-+- ... +-+-+-+-+-+-+- ...
| 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 19: A Packet as Forwarded along a Track Figure 22: A Packet as Forwarded along a Track
7. Lesser Constrained Variations 7. Lesser 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 possesses the DODAG topology, * In Non-Storing Mode The Root already possesses the DODAG topology,
skipping to change at page 59, line 22 skipping to change at page 64, line 22
trade-off than the Non-Storing, as it reduces the route stretch and trade-off than the Non-Storing, as it reduces the route stretch and
lowers the load on the Root. In that case, the control path between lowers the load on the Root. In that case, the control path between
the Root and the LLN nodes is highly available compared to LLNs, and the Root and the LLN nodes is highly available compared to LLNs, and
the nodes can be reached to maintain the P-Routes at most times. the nodes can be reached to maintain the P-Routes at most times.
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 Projected Routes when the Main DODAG is operated in Storing Mode. As
long as the RPI can be processed adequately by the dataplane, the long as the RPI can be processed adequately by the dataplane, the
changes to this specification are limited to the DAO message. The changes to this specification are limited to the DAO message. The
Track structure, routes and forwarding operations remain the same. Track structure, routes and forwarding operations remain the same.
Since there is no capability negotiation, the expectation is that all
the nodes in the network support this specification in the same
fashion, 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 as Non-Storing DAO messages DAO messages that are unicast to the Root as Non-Storing DAO messages
are. 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 Sibling Information Options (SIO)s, regardless
of the relative position in the DODAG of the advertised node vs. this of the relative position in the DODAG of the advertised node vs. this
skipping to change at page 60, line 10 skipping to change at page 65, line 17
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 to factorise [RFC9010]. Having similar values in all nodes allows to factorise
the TIO for multiple SIOs as done with [RPL]. the TIO for multiple SIOs as done with [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 But the RPL routing information headers may not be supported on all
type of routed network infrastructures, especially not in high-speed type of routed network infrastructures, especially not in high-speed
routers. When the RPI is not be supported in the dataplane, there routers. When the RPI is not supported in the dataplane, there
cannot be local RPL Instances and RPL can only operate as a single cannot be local RPL Instances and RPL can only operate as a single
topology (the Main DODAG). The RPL Instance is that of the Main topology (the Main DODAG). The RPL Instance is that of the Main
DODAG and the Ingress node that encapsulates is not the Root. The DODAG and the Ingress node that encapsulates is not the Root. The
routes along the Tracks are alternate routes to those available along routes along the Tracks are alternate routes to those available along
the Main DODAG. They MAY conflict with routes to children and MUST the Main DODAG. They MAY conflict with routes to children and MUST
take precedence in the routing table. The Targets MUST be adjacent take precedence in the routing table. The Targets MUST be adjacent
to the Track Egress to avoid loops that may form if the packet is to the Track Egress to avoid loops that may form if the packet is
reinjected in the Main DODAG. reinjected in the Main DODAG.
7.2. A Track as a Full DODAG 7.2. A Track as a Full DODAG
skipping to change at page 61, line 35 skipping to change at page 66, line 47
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 sections described profiles that can be implemented separately This sections described 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 to implement only a do. This section describes profiles that enable to implement only a
portion of this specification to meet a particular use case. portion of this specification to meet a particular use case.
Profiles 0 to 2 operate in the Main RPL Instance and do not require Profiles 0 to 2 operate in the Main RPL Instance and do not require
the support of local RPL Instances or the indication of the RPL the support of local RPL Instances or the indication of the RPL
Instance in the data plane. Profile 3 and above leverage Local RPL Instance in the data plane. Profile 3 and above leverage Local RPL
Instances to build arbitrary Tracks rooted at the Track Ingress and Instances to build arbitrary Tracks Rooted at the Track Ingress and
using its namespace for TrackID. using its namespace for TrackID.
Profiles 0 and 1 are REQUIRED by all implementations that may be used Profiles 0 and 1 are REQUIRED by all implementations that may be used
in LLNs; this enables to use Storing Mode to reduce the size of the in LLNs; this enables to use 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 high speed / 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 Profile 0 is the Legacy support of [RPL] Non-Storing Mode,
skipping to change at page 63, line 16 skipping to change at page 68, line 29
for use cases where an arbitrary node in the network can afford for use cases where an arbitrary node in the network can afford
the same code complexity as the RPL Root in a traditional the same code complexity as the RPL Root in a traditional
deployment. It offers a full DODAG visibility to the Track deployment. It offers a full DODAG visibility to the Track
Ingress as specified in Section 7.2 in a Non-Storing Mode Main Ingress as specified in Section 7.2 in a Non-Storing Mode Main
DODAG. DODAG.
Profile 9 Profile 9 combines profiles 7 and 8, operating the Track Profile 9 Profile 9 combines profiles 7 and 8, operating the Track
as a full DODAG within a Storing Mode Main DODAG, using only the as a full DODAG within a Storing Mode Main DODAG, using only the
Main DODAG RPLInstanceID as TrackID. Main DODAG RPLInstanceID as TrackID.
9. Security Considerations 9. Backwards Compatibility
This specification can operate in a mixed network where some nodes
support it and some do not. There are restructions, though. All
nodes that need to process a P-DAO must support this specification.
As discussed in Section 3.7.1, how the root knows whether the nodes
capabilities and whether it support this specification is out of
scope.
This specification defines the 'D' flag in the RPL DODAG
Configuration Option (see Section 4.1.6) to signal that the RPL nodes
can request the creation of Tracks. The requester may not know
whether the Track can effectively be constructed, and whether enough
nodes along the preferred paths support this specification.
Therefore it makes sense to only set the 'D' flags in DIO when the
conditions of success are in place, in particular when all the nodes
that could be on path of tracks are upgraded.
10. Security Considerations
It is worth noting that with [RPL], every node in the LLN is RPL- It is worth noting that with [RPL], every node in the LLN is RPL-
aware and can inject any RPL-based attack in the network. This draft aware and can inject any RPL-based attack in the network. This draft
uses messages that are already present in RPL [RPL] with optional uses messages that are already present in RPL [RPL] with optional
secured versions. The same secured versions may be used with this secured versions. The same secured versions may be used with this
draft, and whatever security is deployed for a given network also draft, and whatever security is deployed for a given network also
applies to the flows in this draft. applies to the flows in this draft.
The LLN nodes depend on the 6LBR and the RPL participants for their The LLN nodes depend on the 6LBR and the RPL participants for their
operation. A trust model must be put in place to ensure that the operation. A trust model must be put in place to ensure that the
skipping to change at page 63, line 40 skipping to change at page 69, line 29
security. This is a generic 6LoWPAN requirement, see Req5.1 in security. This is a generic 6LoWPAN requirement, see Req5.1 in
Appendix B.5 of [RFC8505]. Appendix B.5 of [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. The Link-Layer
security is needed in particular to prevent Denial-Of-Service attacks security is needed in particular 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 injected forged P-DAO messages and using up all the constantly injected forged P-DAO messages and using up all the
available storage in the attacked routers. available storage in the attacked routers.
With this specification, only the Root may generate P-DAO messages.
PDR messages may only be sent to the Root. This specification
expects that the communication with the Root is authenticated but
does enforce which method is used.
Additionally, the trust model could include a role validation (e.g., Additionally, the trust model could include a role validation (e.g.,
using a role-based authorization) to ensure that the node that claims using a role-based authorization) to ensure that the node that claims
to be a RPL Root is entitled to do so. That trust should propagate to be a RPL Root is entitled to do so. That trust should propagate
from Egress to Ingress in the case of a Storing Mode P-DAO. from Egress to Ingress in the case of a Storing Mode P-DAO.
This specification suggests some validation of the VIO to prevent This specification suggests some validation of the VIO to prevent
basic loops by avoiding that a node appears twice. But that is only basic loops by avoiding that a node appears twice. But that is only
a minimal protection. Arguably, an attacker tha can inject P-DAOs a minimal protection. Arguably, an attacker tha can inject P-DAOs
can reroute any traffic and deplete critical resources such as can reroute any traffic and deplete critical resources such as
spectrum and battery in the LLN rapidly. spectrum and battery in the LLN rapidly.
10. IANA Considerations 11. IANA Considerations
10.1. New Elective 6LoWPAN Routing Header Type
11.1. RPL DODAG Configuration Option Flag
IANA is requested to assign a flag from the "DODAG Configuration
Option Flags for MOP 0..6" [RFC9010] registry as follows:
+---------------+------------------------------+-----------+
| Bit Number | Capability Description | Reference |
+---------------+------------------------------+-----------+
| 0 (suggested) | Projected Routes Support (D) | THIS RFC |
+---------------+------------------------------+-----------+
Table 21: New DODAG Configuration Option Flag
IANA is requested to add [THIS RFC] as a reference for MOP 7 in the
RPL Mode of Operation registry.
11.2. Elective 6LoWPAN Routing Header Type
This document updates the IANA registry titled "Elective 6LoWPAN This document updates the IANA registry titled "Elective 6LoWPAN
Routing Header Type" that was created for [RFC8138] and assigns the Routing Header Type" that was created for [RFC8138] and assigns the
following value: following value:
+===============+=============+===============+ +===============+=============+===============+
| Value | Description | Reference | | Value | Description | Reference |
+===============+=============+===============+ +===============+=============+===============+
| 8 (Suggested) | P-RPI-6LoRH | This document | | 8 (Suggested) | P-RPI-6LoRH | This document |
+---------------+-------------+---------------+ +---------------+-------------+---------------+
Table 21: New Elective 6LoWPAN Routing Table 22: New Elective 6LoWPAN Routing
Header Type Header Type
10.2. New Critical 6LoWPAN Routing Header Type 11.3. Critical 6LoWPAN Routing Header Type
This document updates the IANA registry titled "Critical 6LoWPAN This document updates the IANA registry titled "Critical 6LoWPAN
Routing Header Type" that was created for [RFC8138] and assigns the Routing Header Type" that was created for [RFC8138] and assigns the
following value: following value:
+===============+=============+===============+ +===============+=============+===============+
| Value | Description | Reference | | Value | Description | Reference |
+===============+=============+===============+ +===============+=============+===============+
| 8 (Suggested) | P-RPI-6LoRH | This document | | 8 (Suggested) | P-RPI-6LoRH | This document |
+---------------+-------------+---------------+ +---------------+-------------+---------------+
Table 22: New Critical 6LoWPAN Routing Table 23: New Critical 6LoWPAN Routing
Header Type Header Type
10.3. New Subregistry For The RPL Option Flags 11.4. Subregistry For The RPL Option Flags
IANA is required to create a subregistry for the 8-bit RPL Option IANA is required to create a subregistry for the 8-bit RPL Option
Flags field, as detailed in Figure 7, under the "Routing Protocol for Flags field, as detailed in Figure 10, under the "Routing Protocol
Low Power and Lossy Networks (RPL)" registry. The bits are indexed for Low Power and Lossy Networks (RPL)" registry. The bits are
from 0 (leftmost) to 7. Each bit is Tracked with the following indexed from 0 (leftmost) to 7. Each bit is Tracked with the
qualities: 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 Registration procedure is "Standards Action" [RFC8126]. The initial
allocation is as indicated in Table 26: allocation is as indicated in Table 27:
+===============+======================+===============+ +===============+======================+===============+
| Bit number | Indication When Set | Reference | | Bit number | Indication When Set | Reference |
+===============+======================+===============+ +===============+======================+===============+
| 0 | Down 'O' | [RFC6553] | | 0 | Down 'O' | [RFC6553] |
+---------------+----------------------+---------------+ +---------------+----------------------+---------------+
| 1 | Rank-Error (R) | [RFC6553] | | 1 | Rank-Error (R) | [RFC6553] |
+---------------+----------------------+---------------+ +---------------+----------------------+---------------+
| 2 | Forwarding-Error (F) | [RFC6553] | | 2 | Forwarding-Error (F) | [RFC6553] |
+---------------+----------------------+---------------+ +---------------+----------------------+---------------+
| 3 (Suggested) | Projected-Route (P) | This document | | 3 (Suggested) | Projected-Route (P) | This document |
+---------------+----------------------+---------------+ +---------------+----------------------+---------------+
Table 23: Initial PDR Flags Table 24: Initial PDR Flags
10.4. New RPL Control Codes 11.5. RPL Control Codes
This document extends the IANA Subregistry created by RFC 6550 for This document extends the IANA Subregistry created by RFC 6550 for
RPL Control Codes as indicated in Table 24: RPL Control Codes as indicated in Table 25:
+==================+=============================+===============+ +==================+=============================+===============+
| Code | Description | Reference | | Code | Description | Reference |
+==================+=============================+===============+ +==================+=============================+===============+
| 0x09 (Suggested) | Projected DAO Request (PDR) | This document | | 0x09 (Suggested) | Projected DAO Request (PDR) | This document |
+------------------+-----------------------------+---------------+ +------------------+-----------------------------+---------------+
| 0x0A (Suggested) | PDR-ACK | This document | | 0x0A (Suggested) | PDR-ACK | This document |
+------------------+-----------------------------+---------------+ +------------------+-----------------------------+---------------+
Table 24: New RPL Control Codes Table 25: New RPL Control Codes
10.5. New RPL Control Message Options 11.6. RPL Control Message Options
This document extends the IANA Subregistry created by RFC 6550 for This document extends the IANA Subregistry created by RFC 6550 for
RPL Control Message Options as indicated in Table 25: RPL Control Message Options as indicated in Table 26:
+==================+=============================+===============+ +==================+=============================+===============+
| Value | Meaning | Reference | | Value | Meaning | Reference |
+==================+=============================+===============+ +==================+=============================+===============+
| 0x0E (Suggested) | Stateful VIO (SM-VIO) | This document | | 0x0E (Suggested) | Stateful VIO (SM-VIO) | This document |
+------------------+-----------------------------+---------------+ +------------------+-----------------------------+---------------+
| 0x0F (Suggested) | Source-Routed VIO (NSM-VIO) | This document | | 0x0F (Suggested) | Source-Routed VIO (NSM-VIO) | This document |
+------------------+-----------------------------+---------------+ +------------------+-----------------------------+---------------+
| 0x10 (Suggested) | Sibling Information option | This document | | 0x10 (Suggested) | Sibling Information option | This document |
+------------------+-----------------------------+---------------+ +------------------+-----------------------------+---------------+
Table 25: RPL Control Message Options Table 26: RPL Control Message Options
10.6. SubRegistry for the Projected DAO Request Flags 11.7. SubRegistry for the Projected DAO Request Flags
IANA is required to create a registry for the 8-bit Projected DAO IANA is required to create a registry for the 8-bit Projected DAO
Request (PDR) Flags field. Each bit is Tracked with the following Request (PDR) Flags field. Each bit is Tracked with the following
qualities: qualities:
* Bit number (counting from bit 0 as the most significant bit) * Bit number (counting from bit 0 as the most significant bit)
* Capability description * Capability description
* Reference * Reference
Registration procedure is "Standards Action" [RFC8126]. The initial Registration procedure is "Standards Action" [RFC8126]. The initial
allocation is as indicated in Table 26: allocation is as indicated in Table 27:
+============+========================+===============+ +============+========================+===============+
| Bit number | Capability description | Reference | | Bit number | Capability description | Reference |
+============+========================+===============+ +============+========================+===============+
| 0 | PDR-ACK request (K) | This document | | 0 | PDR-ACK request (K) | This document |
+------------+------------------------+---------------+ +------------+------------------------+---------------+
| 1 | Requested path should | This document | | 1 | Requested path should | This document |
| | be redundant (R) | | | | be redundant (R) | |
+------------+------------------------+---------------+ +------------+------------------------+---------------+
Table 26: Initial PDR Flags Table 27: Initial PDR Flags
10.7. SubRegistry for the PDR-ACK Flags 11.8. SubRegistry for the PDR-ACK Flags
IANA is required to create an subregistry for the 8-bit PDR-ACK Flags IANA is required to create an subregistry for the 8-bit PDR-ACK Flags
field. Each bit is Tracked with the following qualities: field. Each bit is Tracked with the following qualities:
* Bit number (counting from bit 0 as the most significant bit) * Bit number (counting from bit 0 as the most significant bit)
* Capability description * Capability description
* Reference * Reference
Registration procedure is "Standards Action" [RFC8126]. No bit is Registration procedure is "Standards Action" [RFC8126]. No bit is
currently defined for the PDR-ACK Flags. currently defined for the PDR-ACK Flags.
10.8. Subregistry for the PDR-ACK Acceptance Status Values 11.9. Subregistry for the PDR-ACK Acceptance Status Values
IANA is requested to create a Subregistry for the PDR-ACK Acceptance IANA is requested to create a Subregistry for the PDR-ACK Acceptance
Status values. Status values.
* Possible values are 6-bit unsigned integers (0..63). * Possible values are 6-bit unsigned integers (0..63).
* Registration procedure is "Standards Action" [RFC8126]. * Registration procedure is "Standards Action" [RFC8126].
* Initial allocation is as indicated in Table 27: * Initial allocation is as indicated in Table 28:
+-------+------------------------+---------------+ +-------+------------------------+---------------+
| Value | Meaning | Reference | | Value | Meaning | Reference |
+-------+------------------------+---------------+ +-------+------------------------+---------------+
| 0 | Unqualified Acceptance | This document | | 0 | Unqualified Acceptance | This document |
+-------+------------------------+---------------+ +-------+------------------------+---------------+
Table 27: Acceptance values of the PDR-ACK Status Table 28: Acceptance values of the PDR-ACK Status
10.9. Subregistry for the PDR-ACK Rejection Status Values 11.10. Subregistry for the PDR-ACK Rejection Status Values
IANA is requested to create a Subregistry for the PDR-ACK Rejection IANA is requested to create a Subregistry for the PDR-ACK Rejection
Status values. Status values.
* Possible values are 6-bit unsigned integers (0..63). * Possible values are 6-bit unsigned integers (0..63).
* Registration procedure is "Standards Action" [RFC8126]. * Registration procedure is "Standards Action" [RFC8126].
* Initial allocation is as indicated in Table 28: * Initial allocation is as indicated in Table 29:
+-------+-----------------------+---------------+ +-------+-----------------------+---------------+
| Value | Meaning | Reference | | Value | Meaning | Reference |
+-------+-----------------------+---------------+ +-------+-----------------------+---------------+
| 0 | Unqualified Rejection | This document | | 0 | Unqualified Rejection | This document |
+-------+-----------------------+---------------+ +-------+-----------------------+---------------+
| 1 | Transient Failure | This document | | 1 | Transient Failure | This document |
+-------+-----------------------+---------------+ +-------+-----------------------+---------------+
Table 28: Rejection values of the PDR-ACK Status Table 29: Rejection values of the PDR-ACK Status
10.10. SubRegistry for the Via Information Options Flags 11.11. SubRegistry for the Via Information Options Flags
IANA is requested to create a Subregistry for the 5-bit Via IANA is requested to create a Subregistry for the 5-bit Via
Information Options (Via Information Option) Flags field. Each bit Information Options (Via Information Option) Flags field. Each bit
is Tracked with the following qualities: is Tracked with the following qualities:
* Bit number (counting from bit 0 as the most significant bit) * Bit number (counting from bit 0 as the most significant bit)
* Capability description * Capability description
* Reference * Reference
Registration procedure is "Standards Action" [RFC8126]. No bit is Registration procedure is "Standards Action" [RFC8126]. No bit is
currently defined for the Via Information Options (Via Information currently defined for the Via Information Options (Via Information
Option) Flags. Option) Flags.
10.11. SubRegistry for the Sibling Information Option Flags 11.12. SubRegistry for the Sibling Information Option Flags
IANA is required to create a registry for the 5-bit Sibling IANA is required to create a registry for the 5-bit Sibling
Information Option (SIO) Flags field. Each bit is Tracked with the Information Option (SIO) Flags field. Each bit is Tracked with the
following qualities: 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 Registration procedure is "Standards Action" [RFC8126]. The initial
allocation is as indicated in Table 29: allocation is as indicated in Table 30:
+===============+========================+===========+ +===============+========================+===========+
| Bit number | Capability description | Reference | | Bit number | Capability description | Reference |
+===============+========================+===========+ +===============+========================+===========+
| 0 (Suggested) | "S" flag: Sibling in | This | | 0 (Suggested) | "S" flag: Sibling in | This |
| | same DODAG as Self | document | | | same DODAG as Self | document |
+---------------+------------------------+-----------+ +---------------+------------------------+-----------+
Table 29: Initial SIO Flags Table 30: Initial SIO Flags
10.12. New destination Advertisement Object Flag 11.13. destination Advertisement Object Flag
This document modifies the "destination Advertisement Object (DAO) This document modifies the "destination Advertisement Object (DAO)
Flags" registry initially created in Section 20.11 of [RPL] . Flags" registry initially created in Section 20.11 of [RPL] .
Section 4.1.1 also defines one new entry in the Registry as follows: Section 4.1.1 also defines one new entry in the Registry as follows:
+---------------+------------------------+-----------+ +---------------+------------------------+-----------+
| Bit Number | Capability Description | Reference | | Bit Number | Capability Description | Reference |
+---------------+------------------------+-----------+ +---------------+------------------------+-----------+
| 2 (Suggested) | Projected DAO (P) | THIS RFC | | 2 (Suggested) | Projected DAO (P) | THIS RFC |
+---------------+------------------------+-----------+ +---------------+------------------------+-----------+
Table 30: New destination Advertisement Object Table 31: New destination Advertisement Object
(DAO) Flag (DAO) Flag
10.13. New ICMPv6 Error Code 11.14. New 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.
IANA has defined an ICMPv6 "Code" Fields Registry for ICMPv6 Message IANA has defined an ICMPv6 "Code" Fields Registry for ICMPv6 Message
Types. ICMPv6 Message Type 1 describes "destination Unreachable" Types. ICMPv6 Message Type 1 describes "destination Unreachable"
codes. This specification requires that a new code is allocated from codes. This specification requires that a new code is allocated from
the ICMPv6 Code Fields Registry for ICMPv6 Message Type 1, for "Error the ICMPv6 Code Fields Registry for ICMPv6 Message Type 1, for "Error
in P-Route", with a suggested code value of 8, to be confirmed by in P-Route", with a suggested code value of 8, to be confirmed by
IANA. IANA.
10.14. New RPL Rejection Status values 11.15. RPL Rejection Status values
This specification updates the Subregistry for the "RPL Rejection This specification updates the Subregistry for the "RPL Rejection
Status" values under the RPL registry, as follows: Status" values under the RPL registry, as follows:
+---------------+-------------------------+-----------+ +---------------+-------------------------+-----------+
| Value | Meaning | Reference | | Value | Meaning | Reference |
+---------------+-------------------------+-----------+ +---------------+-------------------------+-----------+
| 2 (Suggested) | Out of Resources | THIS RFC | | 2 (Suggested) | Out of Resources | THIS RFC |
+---------------+-------------------------+-----------+ +---------------+-------------------------+-----------+
| 3 (Suggested) | Error in VIO | THIS RFC | | 3 (Suggested) | Error in VIO | THIS RFC |
+---------------+-------------------------+-----------+ +---------------+-------------------------+-----------+
| 4 (Suggested) | Predecessor Unreachable | THIS RFC | | 4 (Suggested) | Predecessor Unreachable | THIS RFC |
+---------------+-------------------------+-----------+ +---------------+-------------------------+-----------+
| 5 (Suggested) | Unreachable Target | THIS RFC | | 5 (Suggested) | Unreachable Target | THIS RFC |
+---------------+-------------------------+-----------+ +---------------+-------------------------+-----------+
| 6..63 | Unassigned | | | 6..63 | Unassigned | |
+---------------+-------------------------+-----------+ +---------------+-------------------------+-----------+
Table 31: Rejection values of the RPL Status Table 32: Rejection values of the RPL Status
11. Acknowledgments 12. Acknowledgments
The authors wish to acknowledge JP Vasseur, Remy Liubing, James The authors wish to acknowledge JP Vasseur, Remy Liubing, James
Pylakutty, and Patrick Wetterwald for their contributions to the Pylakutty, and Patrick Wetterwald for their contributions to the
ideas developed here. Many thanks to Dominique Barthel and SVR Anand ideas developed here. Many thanks to Dominique Barthel and SVR Anand
for their global contribution to 6TiSCH, RAW and this document, as for their global contribution to 6TiSCH, RAW and this document, as
well as text suggestions that were incorporated, and to Michael well as text suggestions that were incorporated, and to Michael
Richardson for his useful recommendations based on his global view of Richardson for his useful recommendations based on his global view of
the system. Also special thanks Toerless Eckert for his deep review, the system. Also special thanks Toerless Eckert for his deep review,
with many excellent suggestions that improved the readability and with many excellent suggestions that improved the readability and
well as the content of the specification. well as the content of the specification.
12. Normative References 13. Normative References
[INT-ARCHI] [INT-ARCHI]
Braden, R., Ed., "Requirements for Internet Hosts - Braden, R., Ed., "Requirements for Internet Hosts -
Communication Layers", STD 3, RFC 1122, Communication Layers", STD 3, RFC 1122,
DOI 10.17487/RFC1122, October 1989, DOI 10.17487/RFC1122, October 1989,
<https://www.rfc-editor.org/info/rfc1122>. <https://www.rfc-editor.org/info/rfc1122>.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997, DOI 10.17487/RFC2119, March 1997,
skipping to change at page 71, line 10 skipping to change at page 77, line 33
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
May 2017, <https://www.rfc-editor.org/info/rfc8174>. May 2017, <https://www.rfc-editor.org/info/rfc8174>.
[RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for [RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for
Writing an IANA Considerations Section in RFCs", BCP 26, Writing an IANA Considerations Section in RFCs", BCP 26,
RFC 8126, DOI 10.17487/RFC8126, June 2017, RFC 8126, DOI 10.17487/RFC8126, June 2017,
<https://www.rfc-editor.org/info/rfc8126>. <https://www.rfc-editor.org/info/rfc8126>.
13. Informative References [RFC8138] Thubert, P., Ed., Bormann, C., Toutain, L., and R. Cragie,
"IPv6 over Low-Power Wireless Personal Area Network
(6LoWPAN) Routing Header", RFC 8138, DOI 10.17487/RFC8138,
April 2017, <https://www.rfc-editor.org/info/rfc8138>.
[RFC8754] Filsfils, C., Ed., Dukes, D., Ed., Previdi, S., Leddy, J.,
Matsushima, S., and D. Voyer, "IPv6 Segment Routing Header
(SRH)", RFC 8754, DOI 10.17487/RFC8754, March 2020,
<https://www.rfc-editor.org/info/rfc8754>.
14. Informative References
[6LoWPAN] Montenegro, G., Kushalnagar, N., Hui, J., and D. Culler, [6LoWPAN] Montenegro, G., Kushalnagar, N., Hui, J., and D. Culler,
"Transmission of IPv6 Packets over IEEE 802.15.4 "Transmission of IPv6 Packets over IEEE 802.15.4
Networks", RFC 4944, DOI 10.17487/RFC4944, September 2007, Networks", RFC 4944, DOI 10.17487/RFC4944, September 2007,
<https://www.rfc-editor.org/info/rfc4944>. <https://www.rfc-editor.org/info/rfc4944>.
[RFC7102] Vasseur, JP., "Terms Used in Routing for Low-Power and [RFC7102] Vasseur, JP., "Terms Used in Routing for Low-Power and
Lossy Networks", RFC 7102, DOI 10.17487/RFC7102, January Lossy Networks", RFC 7102, DOI 10.17487/RFC7102, January
2014, <https://www.rfc-editor.org/info/rfc7102>. 2014, <https://www.rfc-editor.org/info/rfc7102>.
skipping to change at page 71, line 49 skipping to change at page 78, line 33
[RAW-ARCHI] [RAW-ARCHI]
Thubert, P., Papadopoulos, G. Z., and L. Berger, "Reliable Thubert, P., Papadopoulos, G. Z., and L. Berger, "Reliable
and Available Wireless Architecture/Framework", Work in and Available Wireless Architecture/Framework", Work in
Progress, Internet-Draft, draft-ietf-raw-architecture-01, Progress, Internet-Draft, draft-ietf-raw-architecture-01,
28 July 2021, <https://datatracker.ietf.org/doc/html/ 28 July 2021, <https://datatracker.ietf.org/doc/html/
draft-ietf-raw-architecture-01>. draft-ietf-raw-architecture-01>.
[USE-CASES] [USE-CASES]
Papadopoulos, G. Z., Thubert, P., Theoleyre, F., and C. J. Papadopoulos, G. Z., Thubert, P., Theoleyre, F., and C. J.
Bernardos, "RAW use cases", Work in Progress, Internet- Bernardos, "RAW use cases", Work in Progress, Internet-
Draft, draft-ietf-raw-use-cases-02, 12 July 2021, Draft, draft-ietf-raw-use-cases-03, 20 October 2021,
<https://datatracker.ietf.org/doc/html/draft-ietf-raw-use- <https://datatracker.ietf.org/doc/html/draft-ietf-raw-use-
cases-02>. cases-03>.
[TURN-ON_RFC8138] [TURN-ON_RFC8138]
Thubert, P., Ed. and L. Zhao, "A Routing Protocol for Low- Thubert, P., Ed. and L. Zhao, "A Routing Protocol for Low-
Power and Lossy Networks (RPL) Destination-Oriented Power and Lossy Networks (RPL) Destination-Oriented
Directed Acyclic Graph (DODAG) Configuration Option for Directed Acyclic Graph (DODAG) Configuration Option for
the 6LoWPAN Routing Header", RFC 9035, the 6LoWPAN Routing Header", RFC 9035,
DOI 10.17487/RFC9035, April 2021, DOI 10.17487/RFC9035, April 2021,
<https://www.rfc-editor.org/info/rfc9035>. <https://www.rfc-editor.org/info/rfc9035>.
[RFC8025] Thubert, P., Ed. and R. Cragie, "IPv6 over Low-Power [RFC8025] Thubert, P., Ed. and R. Cragie, "IPv6 over Low-Power
Wireless Personal Area Network (6LoWPAN) Paging Dispatch", Wireless Personal Area Network (6LoWPAN) Paging Dispatch",
RFC 8025, DOI 10.17487/RFC8025, November 2016, RFC 8025, DOI 10.17487/RFC8025, November 2016,
<https://www.rfc-editor.org/info/rfc8025>. <https://www.rfc-editor.org/info/rfc8025>.
[RFC8138] Thubert, P., Ed., Bormann, C., Toutain, L., and R. Cragie,
"IPv6 over Low-Power Wireless Personal Area Network
(6LoWPAN) Routing Header", RFC 8138, DOI 10.17487/RFC8138,
April 2017, <https://www.rfc-editor.org/info/rfc8138>.
[RFC8505] Thubert, P., Ed., Nordmark, E., Chakrabarti, S., and C. [RFC8505] Thubert, P., Ed., Nordmark, E., Chakrabarti, S., and C.
Perkins, "Registration Extensions for IPv6 over Low-Power Perkins, "Registration Extensions for IPv6 over Low-Power
Wireless Personal Area Network (6LoWPAN) Neighbor Wireless Personal Area Network (6LoWPAN) Neighbor
Discovery", RFC 8505, DOI 10.17487/RFC8505, November 2018, Discovery", RFC 8505, DOI 10.17487/RFC8505, November 2018,
<https://www.rfc-editor.org/info/rfc8505>. <https://www.rfc-editor.org/info/rfc8505>.
[RFC8402] Filsfils, C., Ed., Previdi, S., Ed., Ginsberg, L., [RFC8402] Filsfils, C., Ed., Previdi, S., Ed., Ginsberg, L.,
Decraene, B., Litkowski, S., and R. Shakir, "Segment Decraene, B., Litkowski, S., and R. Shakir, "Segment
Routing Architecture", RFC 8402, DOI 10.17487/RFC8402, Routing Architecture", RFC 8402, DOI 10.17487/RFC8402,
July 2018, <https://www.rfc-editor.org/info/rfc8402>. July 2018, <https://www.rfc-editor.org/info/rfc8402>.
skipping to change at page 73, line 17 skipping to change at page 79, line 48
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>.
[RFC9010] Thubert, P., Ed. and M. Richardson, "Routing for RPL [RFC9010] Thubert, P., Ed. and M. Richardson, "Routing for RPL
(Routing Protocol for Low-Power and Lossy Networks) (Routing Protocol for Low-Power and Lossy Networks)
Leaves", RFC 9010, DOI 10.17487/RFC9010, April 2021, Leaves", RFC 9010, DOI 10.17487/RFC9010, April 2021,
<https://www.rfc-editor.org/info/rfc9010>. <https://www.rfc-editor.org/info/rfc9010>.
[I-D.irtf-panrg-path-properties] [I-D.irtf-panrg-path-properties]
Enghardt, T. and C. Krähenbühl, "A Vocabulary of Path Enghardt, T. and C. Kraehenbuehl, "A Vocabulary of Path
Properties", Work in Progress, Internet-Draft, draft-irtf- Properties", Work in Progress, Internet-Draft, draft-irtf-
panrg-path-properties-03, 9 July 2021, panrg-path-properties-04, 25 October 2021,
<https://datatracker.ietf.org/doc/html/draft-irtf-panrg- <https://datatracker.ietf.org/doc/html/draft-irtf-panrg-
path-properties-03>. path-properties-04>.
[PCE] IETF, "Path Computation Element", [PCE] IETF, "Path Computation Element",
<https://dataTracker.ietf.org/doc/charter-ietf-pce/>. <https://dataTracker.ietf.org/doc/charter-ietf-pce/>.
Authors' Addresses Authors' Addresses
Pascal Thubert (editor) Pascal Thubert (editor)
Cisco Systems, Inc Cisco Systems, Inc
Building D Building D
45 Allee des Ormes - BP1200 45 Allee des Ormes - BP1200
 End of changes. 175 change blocks. 
406 lines changed or deleted 692 lines changed or added

This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/