2. Terminology
This section preserves the RFC text for RPL DAO Projection and root-initiated routing state, including P-DAO, P-DAO-ACK, P-DAO-REQ, PDR-ACK, VIO, SIO, RPI, SRH, Storing and Non-Storing P-Routes, Tracks, IANA registrations, and normative behavior.
Original RFC Text
2. Terminology
2.1. Requirements Language
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described in
BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all
capitals, as shown here.
In addition, the terms "Extends" and "Amends" are used as per
[NEW-TAGS], Section 3.
2.2. Terms and Concepts
In this document, readers will encounter terms and concepts that are
discussed in the following:
* "RPL: IPv6 Routing Protocol for Low-Power and Lossy Networks"
[RPL]
* "An Architecture for IPv6 over the Time-Slotted Channel Hopping
Mode of IEEE 802.15.4 (6TiSCH)" [RFC9030]
* "Deterministic Networking Architecture" [RFC8655]
* "Using RPI Option Type, Routing Header for Source Routes, and
IPv6-in-IPv6 Encapsulation in the RPL Data Plane" [RFC9008]
* "Reliable and Available Wireless (RAW) Architecture" [RAW-ARCH]
* "Terms Used in Routing for Low-Power and Lossy Networks" [RFC7102]
The 6TiSCH, Deterministic Networking (DetNet), and RAW architectures
utilize the terms "Track" and "recovery graph" to represent the same
concept even though they are in different environments. This
document uses "Track" to represent that concept and only builds
Tracks that are DODAGs, meaning that all links are oriented from
ingress to egress. This specification also utilizes the terms
"segment" and "protection path", which are also defined in the RAW
architecture.
As opposed to routing trees, RPL DODAGs are typically constructed to
provide redundancy and dynamically adapt the forwarding operation to
the state of the Low-Power and Lossy Network (LLN) links. Note that
the plain forwarding operation over DODAGs does not provide
redundancy for all nodes, since at least the node nearest to the Root
does not have an alternate feasible successor.
RAW solves that problem by defining protection paths that can be
interleaved to form new paths that can be activated dynamically upon
failures. This requires additional control in order to make the
routing decision early enough along the Track to route around the
failure.
RAW only uses single-ended DODAGs, meaning that they can be reversed
in another DODAG by reversing all the links. The ingress of the
Track is the Root of the DODAG, whereas the egress is the Root of the
reversed DODAG. From the RAW perspective, single-ended DODAGs are
special Tracks that only have forward links, and that can be
leveraged to provide protection services by defining destination-
oriented protection paths within the DODAG.
2.3. Glossary
This document often uses the following abbreviations:
6LoRH: 6LoWPAN Routing Header
6LR: 6LoWPAN Router (e.g., a RPL router in an LLN)
ARQ: Automatic Repeat Request (in other words, retries)
CMO: Control Message Option
DAG: Directed Acyclic Graph
DAO: Destination Advertisement Object
DIO: DODAG Information Object
DODAG: Destination-Oriented Directed Acyclic Graph. A DAG with
only one vertex (i.e., node) that has no outgoing edge
(i.e., link).
FEC: Forward Error Correction
GUA: Global Unicast Address
HARQ: Hybrid Automatic Repeat Request (combines FEC and ARQ)
LLN: Low-Power and Lossy Network
MOP: Mode of Operation
NSM-VIO: Non-Storing Mode Via Information Option. Source-routed
VIO used in Non-Storing Mode P-DAO messages.
P-DAO: Projected DAO
P-DAO-ACK: Projected DAO Acknowledgment
P-DAO-REQ: Projected DAO Request
P-Route: Projected Route
PCE: Path Computation Element
PDR-ACK Projected DAO Request Acknowledgment
PLR: Point of Local Repair
RAL: RPL-Aware Leaf
RAN: RPL-Aware Node (either a RPL router or a RPL-Aware Leaf)
RH: Routing Header
RIB: Routing Information Base (i.e., the routing table)
RPI: RPL Packet Information
RPL: Routing Protocol for Low-Power and Lossy Networks
RTO: RPL Target Option
RUL: RPL-Unaware Leaf
SIO: Sibling Information Option
SLO: Service Level Objective
SM-VIO: Storing Mode Via Information Option. Strict VIO used in
Storing Mode P-DAO messages.
SRH: Source Routing Header (i.e., IPv6 RH type 3); see
Section 2.4.5.7.2.
SRH-6LoRH: Source Routing Header 6LoRH. A compressed form of SRH
defined in "IPv6 over Low-Power Wireless Personal Area
Network (6LoWPAN) Routing Header" [RFC8138].
TIO: Transit Information Option
ULA: Unique Local Address
VIO: Via Information Option. It can be an SM-VIO or NSM-VIO.
2.4. Domain Terms
This specification uses the terminology defined in the sections that
follow.
2.4.1. Projected Route
A RPL P-Route is a RPL route that is computed remotely by a PCE and
installed and maintained by a RPL Root on behalf of the PCE. It is
installed as a state that signals that destinations (i.e., Targets)
are reachable via or along a sequence of nodes.
2.4.2. Projected DAO
A Projected DAO (P-DAO) is a DAO message that is used to install a
P-Route.
2.4.3. Path
Quoting (non-normatively) the definition of path in Section 1.3.3 of
[INT-ARCH]:
| At a given moment, all the IP datagrams from a particular source
| host to a particular destination host will typically traverse the
| same sequence of gateways. We use the term "path" for this
| sequence. Note that a path is uni-directional; it is not unusual
| to have different paths in the two directions between a given host
| pair.
See Section 3.1.1 of [RAW-ARCH] for a longer, more modern definition
of path.
It follows that the general acceptance of a path is a linear sequence
of nodes, as opposed to a multi-dimensional graph. In the context of
this document, a path is observed by following one copy of a packet
that is injected in a Track and possibly replicated within.
2.4.4. Routing Stretch
RPL is anisotropic, meaning that it is directional or, more
precisely, polar. RPL does not behave the same way "downwards" (Root
towards leaves) with _multicast_ DODAG Information Object (DIO)
messages that form the DODAG versus "upwards" (leaves towards Root)
with _unicast_ DAO messages that follow the DODAG. This is in
contrast with traditional IGPs that operate the same way in all
directions and are thus called isotropic.
The term "routing stretch" denotes the length of a path, in
comparison to the length of the shortest path, which can be an
abstract concept in RPL when the metrics are statistical and dynamic,
and the concept of distance varies with the Objective Function.
The RPL DODAG optimizes Point-to-Multipoint (P2MP) paths (from the
Root) and Multipoint-to-Point (MP2P) paths (towards the Root), but
the Point-to-Point (P2P) traffic has to follow the same DODAG.
Following the DODAG, the RPL datapath passes via a common parent in
Storing Mode and via the Root in Non-Storing Mode. This typically
involves more hops and more latency than the minimum possible for a
directional (i.e., forward) P2P path that an isotropic protocol would
compute. We refer to this elongated path as stretched.
2.4.5. Track
The concept of Track is inherited from the 6TiSCH architecture
[RFC9030] and equals that of a recovery graph in the RAW architecture
[RAW-ARCH]. A Track is a networking graph that can be followed to
transport packets with equivalent treatment; as opposed to other
definitions of a path (see Section 1.3.3 of [INT-ARCH] and
Section 3.1.1 of [RAW-ARCH], a Track is not necessarily linear. It
may contain multiple paths that may fork and rejoin and that may
enable RAW Packet Replication, Elimination, and Ordering Functions
(PREOF).
Figure 1 illustrates the mapping of the DODAG with the generic
concept of a Track, with the DODAG Root acting as the ingress for the
Track, and the mapping of protection paths and segments, i.e., only
forward segments, meaning that they are directional and progressing
towards the destination. Note that East is represented on the left
since the packets are forwarded East-West.
North East North West
A ==> B ==> C -=- F ==> G ==> H T1
/ \ / \ /
I O E -=- T2
\ / \ / \
P ==> Q ==> R -=- T ==> U ==> V T3
South East South West
I: ingress
E: egress
T1, T2, T3: external targets
Figure 1: A Track and Its Components
Of note:
I ==> A ==> B ==> C: A segment to targets F and O
I --> F --> E: A protection path to targets T1, T2, T3
I, A, B, C, F, G, H, E: A path to T1, T2, T3
This specification builds Tracks that are DODAGs oriented towards a
Track ingress, and the forward direction for packets is from the
Track ingress to one of the possible 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 RPLInstanceID (typically of a Local Instance) identifies a Track
using the namespace owned by the Track ingress. For Local Instances,
the TrackID is associated with the IPv6 address of the Track ingress
that is used as the 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. For Local
Instances, the namespace is identified by the DODAGID for the Track,
and the tuple (DODAGID, TrackID) is globally unique. For Global
Instances, the namespace is the whole RPL domain.
2.4.5.3. Complex Track
A Complex Track is a Track that can be traversed via more than one
path (e.g., a DODAG).
2.4.5.4. Stand Alone
Stand alone refers to a segment or a protection path that is
installed with a single P-DAO that fully defines the path, e.g., a
stand-alone segment is installed with a single Storing Mode Via
Information Option (SM-VIO) all the way between the ingress and
egress.
2.4.5.5. Stitching
This specification uses the term "stitching" to indicate that a Track
is piped to another one, meaning that traffic out of the first Track
is injected into the other Track.
2.4.5.6. Protection Path
The concept of protection path is defined in the RAW architecture
[RAW-ARCH] as an end-to-end forward serial path. With this
specification, a protection path is installed by the Root of the main
DODAG using a Non-Storing Mode P-DAO message, e.g., I --> F --> E in
Figure 1.
As the Non-Storing Mode Via Information Option (NSM-VIO) can only
signal sequences of nodes, it takes one Non-Storing Mode P-DAO
message per protection path to signal the structure of a Complex
Track.
Each NSM-VIO for the same TrackID but with a different SegmentID
signals a different protection path that the Track ingress adds to
the topology.
2.4.5.7. Segment
A segment is a serial path formed by a strict sequence of nodes along
which a P-Route is installed, e.g., I ==> A ==> B ==> C in Figure 1.
With this specification, a segment is typically installed by the Root
of the main DODAG using Storing Mode P-DAO messages. A segment is
used as the topological edge of a Track joining the loose steps along
the protection paths that form the structure of a Complex Track. The
same segment may be leveraged by more than one protection path where
the protection paths overlap.
Since this specification builds only DODAGs, all segments are
oriented from the ingress (East) to egress (West), as opposed to the
general Track model in the RAW architecture [RAW-ARCH], which allows
North/South segments that can be bidirectional as well.
2.4.5.7.1. Section of a Segment
The section of a segment refers to 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.7.2. Segment Routing and SRH
In a Non-Storing Mode RPL domain, the IPv6 Routing Header used for
source routing is the RPL Source Route Header as defined in
[RFC6554]. This specification operates in that context and uses the
acronym SRH to mean IPv6 RH type 3, as opposed to IPv6 RH type 4
defined in [RFC8754] for Segment Routing over IPv6 (SRv6) operation.
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].
This specification uses the term "Segment Routing" generically to
refer to using source routing to hop over segments. As such,
forwarding along segments as specified hereafter can be seen as a
form of Segment Routing [RFC8402] that leverages the RPL Source Route
Header for its operation.
Outside of LLNs, the RPL network may be less constrained and operated
in Storing Mode, as discussed in Section 7.1. In that case, this
specification could be extended to accommodate the SRv6 RH.