3. Context and Goal
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
3. Context and Goal
3.1. RPL Applicability
RPL is optimized for situations where the power is scarce, the
bandwidth is constrained, and the transmissions are unreliable. This
matches the use case of an IoT LLN where RPL is typically used today
and also situations of high relative mobility between the nodes in
the network (a.k.a. swarming), e.g., within a variable set of
vehicles with a similar global motion or a platoon of drones. In
contrast, this specification only applies when the platoon has a
relatively stable topology where the segments can be attributed
reliability and availability for a certain lifetime; see [RAW-ARCH].
To reach this goal, RPL is primarily designed to minimize the control
plane activity (i.e., the relative amount of routing protocol
exchanges versus data traffic) and the amount of state that is
maintained in each node. RPL does not need to converge, and it
provides connectivity to most nodes most of the time.
RPL may form multiple topologies called Instances. Instances can be
created to enforce various optimizations through Objective Functions
or to reach out through different Root nodes. The concept of
Objective Function allows adapting the activity of the routing
protocol to the use case, e.g., type, speed, and quality of the LLN
links.
RPL Instances operate in parallel, unaware of one another. Yet, it
is possible to define a model whereby if a route cannot be found in
the current Instance A where a packet is being forwarded, then the
router may look up the routing table (i.e., the RIB) in Instance B
and forward along Instance B if the route is found there. To avoid
loops, this must happen in such a way that the Instances themselves
form a Directed Acyclic Graph (DAG) leading to the last resort
Instance, which is the "lowest" Instance if Instance A is considered
"higher" then Instance B. This specification uses underlay Tracks as
"lower" Instances, with the main Instance being the "highest" of all.
The RPL Root is responsible for selecting the RPL Instance that is
used to forward a packet coming from the backbone into the RPL domain
and for setting the related RPL information in the packets. Each
Instance creates its own routing table (i.e., a RIB) in participating
nodes, and the RIB associated to the Instance must be used end to end
in the RPL domain. To that effect, RPL tags the packets with the
Instance ID in a Hop-by-Hop extension header. 6TiSCH leverages RPL
for its distributed routing operations.
To reduce the routing exchanges, RPL leverages an anisotropic
Distance Vector approach, which does not need global knowledge of the
topology and only optimizes the routes to and from the RPL Root,
allowing P2P paths to be stretched. Although RPL installs its routes
proactively, it only maintains them lazily, in reaction to actual
traffic or as a slow background activity.
This is simple and efficient in situations where the traffic is
mostly directed from or to a central node, such as the control
traffic between routers and a controller of a Software-Defined
Networking (SDN) infrastructure or an Autonomic Control Plane (ACP).
But stretch in P2P routing is counter-productive to both reliability
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
RAW use cases document [RFC9450], which demand high availability and
reliability and, as a consequence, require both short and diverse
paths.
3.2. Multi-Topology Routing and Loop Avoidance
RPL first forms a default route in each node towards the Root, and
those routes together coalesce as a DAG oriented upwards. RPL then
constructs routes to destinations signaled as Targets in the reverse
direction, down the same DODAG. To do so, a RPL Instance can be
operated in either RPL Storing or Non-Storing MOP. The default route
towards the Root is maintained aggressively and may change while a
packet progresses without causing loops, so the packet will still
reach the Root.
In Non-Storing Mode, each node advertises itself as a Target directly
to the Root, indicating the parents that may be used to reach itself.
Recursively, the Root builds and maintains an image of the whole
DODAG in memory and leverages that abstraction to compute source
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
a single unicast packet to the Root along the default route to update
it, and the connectivity to the node is restored immediately; this
mode is preferable for use cases where internet connectivity is
dominant or when the Root controls the network activity in the nodes,
which is the case in this specification.
In Storing Mode, the routing information percolates upwards, and each
node maintains the routes to the subDAG of its descendants down the
DODAG. The maintenance is lazy; it is either reactive upon receiving
traffic or a slow background process. Packets flow via the common
parent and the routing stretch is reduced, compared to the Non-
Storing MOP, for better P2P connectivity. However, a new route takes
a longer time to propagate to the Root, since it takes time for the
Distance Vector protocol to operate hop by hop, and the connectivity
from the Internet to the node is restored more slowly upon node
movement.
Either way, the RPL routes are injected by the Target nodes in a
distributed fashion. To complement RPL and eliminate routing
stretch, this specification introduces a hybrid mode that combines
Storing and Non-Storing operations to build and project routes onto
the nodes where they should be installed. This specification uses
the term "P-Route" to refer to those routes.
In the simplest mode of this specification, Storing Mode P-Routes can
be deployed to complete the path between the hops described in the
loose SRH in the main DODAG. In that case, all the routes (source
routed and P-Routes) belong to the Routing Information Base (RIB)
associated with the main Instance. Storing Mode P-Routes are
referred to as segments in this specification.
A set of P-Routes can also be projected to form a dotted-line
underlay of the main Instance and provide Traffic-Engineered paths
for an application. In that case, the P-Routes are installed in Non-
Storing Mode, and the set of P-Routes is called a Track. A Track is
associated with its own RPL Instance and, as any RPL Instance, with
its own RIB. As a result, each Track defines a routing topology in
the RPL domain. As for the main DODAG, segments associated to the
Track Instance may be deployed to establish the complete path between
loose source routing hops using segments expressed as Storing Mode
P-Routes.
Routing in a multi-topology domain may cause loops unless strict
rules are applied. This specification defines two strict orders to
ensure loop avoidance when P-Routes are used in a RPL domain: one
between forwarding methods and one between RPL Instances, which are
routing topologies.
The first order is strict and complete and relates to the forwarding
method and, more specifically, the origin of the information used in
the next-hop computation. The possible forwarding methods are: 1) to
a direct next hop, 2) to an indirect neighbor via a common neighbor,
3) along a segment, and 4) along a nested Track. The methods are
strictly ordered as listed above; see more in Section 6.7. A
forwarding method may leverage any of the lower-order ones, but never
one with a higher order; for instance, when forwarding a packet along
a segment, the router may use direct or indirect neighbors but cannot
use a Track. The lower-order methods have a strict precedence, so
the router will always prefer a direct neighbor over an indirect one
or a segment within the current RPL Instance over another Track.
The second order is strict and partial and applies between RPL
Instances. It allows the RPL node to detect an error in the state
installed by the PCE, e.g., after a desynchronization. That order
must be defined by the administrator for the RPL domain and defines a
DODAG of underlay RPL Instances with the main Instance as the Root.
The relation of RPL Instances may be represented as a DODAG of
Instances where the main Instance is the Root. The rule is that a
RPL Instance may leverage another RPL Instance as an underlay if and
only if that other Instance is one of its descendants in the graph.
Supporting this method is OPTIONAL for nested Tracks and REQUIRED
between a Track Instance and the main Instance. It may be done using
network management or future extensions to this specifications. When
the DODAG of underlay Instances is not provided, the RPL nodes
consider by default that all Track Instances are children of the main
Instance, and they do not attempt to validate the order for nested
Tracks, trusting the PCE implicitly. As a result, a packet that is
being forwarded along the main Instance may be encapsulated in any
Track, but a packet that was forwarded along a Track MUST NOT be
forwarded along the default route of the main Instance.
3.3. Requirements
3.3.1. Loose Source Routing
A RPL implementation operating in a very constrained LLN typically
uses the Non-Storing MOP as represented in Figure 2. In that mode, a
RPL node indicates a parent-child relationship to the Root, using a
Destination Advertisement Object (DAO) that is unicast from the node
directly to the Root, and the Root typically builds a source-routed
path to a destination down the DODAG by recursively concatenating
this information.
+-----+
| | Border Router
| | (RPL Root)
+-----+ ^ | |
| | DAO | ACK |
o o o o | | | Strict
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 o o o o o o o | v v
o o o o
LLN
Figure 2: RPL Non-Storing Mode of Operation
Based on the parent-children relationships expressed in the Non-
Storing DAO messages, the Root possesses topological information
about the whole network, though this information is limited to the
structure of the DODAG for which it is the destination. A packet
that is generated within the domain will always reach the Root, which
can then apply source routing information to reach the destination 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
be in a RPL domain reaches the Root. This results in the wireless
bandwidth near the Root being the limiting factor for all
transmissions towards or within the domain, and the Root is a single
point of failure for all connectivity to nodes within its domain.
The RPL Root must add a Source Routing Header to all downward
packets. As a network grows, the size of the Source Routing Header
increases with the depth of the network. In some use cases, a RPL
network forms long lines along physical structures like streets with
lighting. Limiting the packet size is beneficial to the energy
budget, directly for the current transmission and also indirectly
since it reduces the chances of frame loss and energy spent in
retries, e.g., by ARQ over one hop at Layer 2 or end to end at upper
layers. Using smaller packets also reduces the chances of packet
fragmentation, which is highly detrimental to the LLN operation, in
particular when fragments are forwarded but not recovered; see
[RFC8930] compared to [RFC8931] for more details.
A limited amount of well-targeted routing state would allow the
source routing operation to be loose as opposed to strict and would
reduce the overhead of routing information in packets. Because the
capability to store routing state in every node is limited, the
decision of which route is installed where can only be optimized with
global knowledge of the system, knowledge that the Root or an
associated PCE may possess by means that are outside the scope of
this specification.
Being on path for all packets in Non-Storing Mode, the Root may
determine the number of P2P packets in its RPL domain per source and
destination, the latency incurred, and the amount of energy and
bandwidth that is consumed to reach itself and then back down,
including possible fragmentation when encapsulating larger packets.
Enabling a shorter path that would not traverse the Root for select
P2P sources/destinations may improve the latency, lower the
consumption of constrained resources, free bandwidth at the
bottleneck near the Root, improve the delivery ratio, and reduce the
latency for those P2P flows; this would be a global benefit for all
flows by reducing the load at the Root.
To limit the need for RPL Source Route Headers in deep networks, one
possibility is to store a routing state associated with the main
DODAG in select RPL routers down the path. The Root may elide the
sequence of routers that is installed in the network from its RPL
Source Route Header, which therefore becomes loose, in contrast to
being strict in [RPL].
3.3.2. Forward Routes
[RPL] optimizes P2MP routes from the Root, MP2P routes towards the
Root, and routes from/to the outside of the RPL domain when the Root
also serves as the border router. All routes are installed North-
South (a.k.a. up/down) along the RPL DODAG. Peer-to-Peer forward
routes in a RPL network will generally experience elongated
(stretched) paths rather than direct (optimized) paths, since routing
between two nodes always happens via a common parent, as illustrated
in Figure 3:
------+---------
| Internet
+-----+
| | Border Router
| | (RPL Root)
+-----+
X
^ v 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
S o o o D o o o
o o o o
LLN
Figure 3: Routing Stretch Between S and D via Common Parent X
Along North-South Paths
As described in [RFC9008], the amount of stretch depends on the MOP:
* 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
same DODAG, the Root must encapsulate the packet to place an RH
that has the strict source route information down the DODAG to the
destination. This will be the case even if the destination is
relatively close to the source and the Root is relatively far off.
* In Storing Mode, unless the destination is a child of the source,
the packets will follow the default route up the DODAG as well.
If the destination is in the same DODAG, they will eventually
reach a common parent that has a route to the destination; at
worst, the common parent may also be the Root. From that common
parent, the packet will follow a path down the DODAG that is
optimized for the Objective Function that was used to build the
DODAG.
It turns out that it is often beneficial to enable direct P2P routes
if either the RPL route presents a stretch from the shortest path or
the new route is engineered with a different objective, and this is
even more critical in Non-Storing Mode than it is in Storing Mode
because the routing stretch is wider. For that reason, earlier work
within the IETF was introduced: the "Reactive Discovery of
Point-to-Point Routes in Low-Power and Lossy Networks" [RFC6997],
which specifies a distributed method for establishing optimized P2P
routes. This specification proposes an alternative based on
centralized route computation.
+-----+
| | Border Router
| | (RPL Root)
+-----+
|
o o o o
o o o o o o o o o
o o o o o o o o o o
o o o o o o o o o
S>>A>>>B>>C>>>D o o o
o o o o
LLN
Figure 4: More Direct Forward Route Between S and D
The requirement is to install additional routes in the RPL routers,
to reduce the stretch of some P2P routes and maintain the
characteristics within a given Service Level Objective (SLO), e.g.,
in terms of latency and/or reliability.
3.4. On Tracks
3.4.1. Building Tracks with RPL
The concept of a Track was introduced in the 6TiSCH architecture
[RFC9030] as a collection of potential protection paths that leverage
redundant forwarding solutions along the way. This can be a DODAG or
a more complex structure that is only partially acyclic (e.g., per
packet).
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 so that
another DODAG may be formed 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 protection path. The nodes in a Track 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 protection paths are expressed in RPL
Non-Storing Mode and require an encapsulation to add a RPL Source
Route Header, whereas the segments are expressed in RPL Storing Mode.
A path provides only one path between the ingress and egress. It
comprises exactly one protection path. A stand-alone segment
implicitly defines a path from its ingress to egress.
A Complex Track forms a graph that provides a collection of potential
paths to provide redundancy for the packets, either as a collection
of protection paths that may be parallel or interleaved at certain
points or as a more generic DODAG.
3.4.2. Tracks and RPL Instances
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
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
Local Address (ULA) or a Global Unicast Address (GUA) of the Root of
the DODAG. Bit 0 (most significant) is set to 1 to signal a Local
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 in the rightmost bits and bit 0 set.
0 1 2 3 4 5 6 7
+-+-+-+-+-+-+-+-+
|1|D| ID | Local RPLInstanceID in 0..63
+-+-+-+-+-+-+-+-+
| |
\ \
\ Bit 1 is set to 0 in TrackIDs
Bit 0 set to 1 signals a Local RPLInstanceID
Figure 5: Local RPLInstanceID Encoding
A Track typically forms an underlay to the main Instance and is
associated with a Local RPL Instance from which the RPLInstanceID is
used as the TrackID. When a packet is placed on a Track, it is IP-
in-IP encapsulated with a RPL Option containing RPL Packet
Information (RPI) that signals the RPLInstanceID. The encapsulating
source IP address and RPI Instance are set to the Track ingress IP
address and Local RPLInstanceID, respectively; see more in
Section 6.3.
A Track typically offers service protection across several protection
paths. As a degraded form of a Track, a path made of a single
protection path (i.e., offering no protection) can be used as an
alternative to a segment for forwarding along a RPL Instance. In
that case, instead of following native routes along the Instance, the
packets are encapsulated to signal a more-specific source-routed path
between the loose hops in the encapsulated Source Routing Header.
If the encapsulated packet follows a Global Instance, then the
protection path may be part of that Global Instance as well, e.g.,
the Global Instance of the main DODAG. This can only be done for
Global Instances because the ingress node that encapsulates the
packets over the protection path is not the Root of the Instance, so
the source address of the encapsulated packet cannot be used to
determine the Track along the way.
3.5. Path Signaling
This specification enables setting up a P-Route along either a
protection path or a segment. A P-Route is installed and maintained
by the Root of the main DODAG using an extended RPL DAO message
called a P-DAO, and a Track is composed of the combination of one or
more P-Routes. In order to clarify the techniques that may be used
to install a P-Route, this section uses the simple case of the path
illustrated in Figure 6. Thus, the goal is to build a path from node
A to E for packets towards E's neighbors F and G along A, B, C, D,
and E as opposed to via the Root:
/===> F
A ===> B ===> C ===> D===> E <
\===> G
Figure 6: Reference Track
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
ingress is used as the source to encapsulate packets along the Track.
The Track is signaled in the DODAGID field of the P-DAO Base Object;
see Figure 8.
This specification introduces the Via Information Option (VIO) to
signal a sequence of hops in a protection path or a segment in the
P-DAO messages, either in Storing Mode (SM-VIO) or in Non-Storing
Mode (NSM-VIO). One P-DAO message contains a single VIO, which is
associated to one or more RPL Target Options that signal the
destination IPv6 addresses that can reached along the Track (see more
in Section 5.3).
Before diving deeper into Track and segment signaling and operation,
this section provides examples of how route projection works through
variations of a simple example. This simple example illustrates the
case of host routes, though RPL Targets can also be prefixes.
Conventionally, we use ==> to represent a strict hop and --> for a
loose hop. We use "-to-", such as in C==>D==>E-to-F, to represent
comma-separated Targets, e.g., F is a Target for segment C==>D==>E.
In the example below, A is the Track ingress and E is the Track
egress. C is a stitching point. F and G are "external" Targets for
the Track and become reachable from A via Track A (ingress) to E
(egress and implicit Target in Non-Storing Mode), leading to F and G
(explicit Targets).
In a general manner, the desired outcome is as follows:
* Targets are E, F, and G
* P-DAO 1 signals C==>D==>E
* P-DAO 2 signals A==>B==>C
* P-DAO 3 signals F and G via the A-->E Track
P-DAO 3 may be omitted if P-DAOs 1 and 2 signal F and G as Targets.
Loose sequences of hops are expressed in Non-Storing Mode; this is
why P-DAO 3 contains an NSM-VIO. With this specification:
* The DODAGID to be used by the ingress as the source address is
signaled in the DAO Base Object (see Figure 8).
* The via list in the VIO is encoded as an SRH-6LoRH (see
Figure 16), and it starts with the address of the first-hop node
after the ingress node in the loose hop sequence.
* The via list ends with the address of the egress node.
| Note 1: The egress of a Non-Storing Mode P-Route is implicitly
| a target; it is not listed in the RPL Target Options but is
| still accounted for as if it was. The only exception is when
| the egress is the only address listed in the VIO, in which case
| it would indicate via itself, which would be nonsensical.
| Note 2: By design, the list of nodes in a VIO in Non-Storing
| Mode is exactly the list that shows in the encapsulation SRH.
| So in the cases detailed below, if the Mode of the P-DAO is
| Non-Storing, then the VIO row can be read as indicating the SRH
| as well.
3.5.1. Using Storing Mode Segments
A==>B==>C and C==>D==>E are segments of the same Track. Note that
the Storing Mode signaling imposes strict continuity in a segment,
since the P-DAO is passed hop by hop, as a classical DAO is, along
the reverse datapath that it signals. One benefit of strict routing
is that loops are avoided along the Track.
3.5.1.1. Stitched Segments
In this formulation:
* P-DAO 1 signals C==>D==>E-to-F,G
* P-DAO 2 signals A==>B==>C-to-F,G
Storing Mode P-DAO 1 is sent to E, and when it is successfully
acknowledged, Storing Mode P-DAO 2 is sent to C as follows:
+====================+==============+==============+
| Field | P-DAO 1 to E | P-DAO 2 to C |
+====================+==============+==============+
| Mode | Storing | Storing |
+====================+--------------+--------------+
| Track ingress | A | A |
+====================+--------------+--------------+
| (DODAGID, TrackID) | (A, 129) | (A, 129) |
+====================+--------------+--------------+
| SegmentID | 1 | 2 |
+====================+--------------+--------------+
| VIO | C, D, E | A, B, C |
+====================+--------------+--------------+
| Targets | F, G | F, G |
+====================+--------------+--------------+
Table 1: P-DAO Messages
As a result, the RIBs are set as follows:
+======+=============+=========+=============+==========+
| Node | Destination | Origin | Next Hop(s) | TrackID |
+======+=============+=========+=============+==========+
| E | F, G | P-DAO 1 | Neighbor | (A, 129) |
+------+-------------+---------+-------------+----------+
| D | E | P-DAO 1 | Neighbor | (A, 129) |
+------+-------------+---------+-------------+----------+
| " | F, G | P-DAO 1 | E | (A, 129) |
+------+-------------+---------+-------------+----------+
| C | D | P-DAO 1 | Neighbor | (A, 129) |
+------+-------------+---------+-------------+----------+
| " | F, G | P-DAO 1 | D | (A, 129) |
+------+-------------+---------+-------------+----------+
| B | C | P-DAO 2 | Neighbor | (A, 129) |
+------+-------------+---------+-------------+----------+
| " | F, G | P-DAO 2 | C | (A, 129) |
+------+-------------+---------+-------------+----------+
| A | B | P-DAO 2 | Neighbor | (A, 129) |
+------+-------------+---------+-------------+----------+
| " | F, G | P-DAO 2 | B | (A, 129) |
+------+-------------+---------+-------------+----------+
Table 2: RIB Settings
| Note: The " sign is used throughout the tables in this document
| to indicate the same value as in the row above.
Packets originating at A and going to F or G do not require
encapsulation as the RPI can be placed in the native header chain.
For packets that it routes, A must encapsulate to add the RPI that
signals the TrackID; the outer headers of the packets that are
forwarded along the Track have the following settings:
+========+=====================+==========================+=========+
| Header | IPv6 Source Address | IPv6 Destination | TrackID |
| | | Address | in RPI |
+========+=====================+==========================+=========+
| Outer | A | F or G | (A, |
| | | | 129) |
+--------+---------------------+--------------------------+---------+
| Inner | Any but A | F or G | N/A |
+--------+---------------------+--------------------------+---------+
Table 3: Packet Header Settings
As an example, say that A has a packet for F. Using the RIB in
Table 2:
* 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 Neighbor Cache Entry: E delivers the packet to F.
3.5.1.2. External Routes
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
[RFC9008]. We then apply the directives for encapsulating in that
case (see more in Section 6.7).
In this formulation, we set up the protection path explicitly, which
creates less routing state in intermediate hops at the expense of
larger packets to accommodate source routing:
* P-DAO 1 signals C==>D==>E-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
Storing Mode P-DAOs 1 and 2 and Non-Storing Mode P-DAO 3 are sent to
E, C, and A, respectively, as follows:
+====================+==============+==============+==============+
| | P-DAO 1 to E | P-DAO 2 to C | P-DAO 3 to A |
+====================+==============+==============+==============+
| Mode | Storing | Storing | Non-Storing |
+====================+--------------+--------------+--------------+
| Track ingress | A | A | A |
+====================+--------------+--------------+--------------+
| (DODAGID, TrackID) | (A, 129) | (A, 129) | (A, 129) |
+====================+--------------+--------------+--------------+
| SegmentID | 1 | 2 | 3 |
+====================+--------------+--------------+--------------+
| VIO | C, D, E | A, B, C | E |
+====================+--------------+--------------+--------------+
| Targets | E | E | F, G |
+====================+--------------+--------------+--------------+
Table 4: P-DAO Messages
Note in the above that E is not an implicit Target in Storing Mode,
so it must be added in the RPL Target Option (RTO) for P-DAOs 1 and
2. E is not an implicit Target for P-DAO 3 either, since E is the
only entry in the VIO.
As a result, the RIBs are set as follows:
+======+=============+=========+=============+==========+
| Node | Destination | Origin | Next Hop(s) | TrackID |
+======+=============+=========+=============+==========+
| E | F, G | P-DAO 1 | Neighbor | (A, 129) |
+------+-------------+---------+-------------+----------+
| D | E | P-DAO 1 | Neighbor | (A, 129) |
+------+-------------+---------+-------------+----------+
| C | D | P-DAO 1 | Neighbor | (A, 129) |
+------+-------------+---------+-------------+----------+
| " | E | P-DAO 1 | D | (A, 129) |
+------+-------------+---------+-------------+----------+
| B | C | P-DAO 2 | Neighbor | (A, 129) |
+------+-------------+---------+-------------+----------+
| " | E | P-DAO 2 | C | (A, 129) |
+------+-------------+---------+-------------+----------+
| A | B | P-DAO 2 | Neighbor | (A, 129) |
+------+-------------+---------+-------------+----------+
| " | E | P-DAO 2 | B | (A, 129) |
+------+-------------+---------+-------------+----------+
| " | F, G | P-DAO 3 | E | (A, 129) |
+------+-------------+---------+-------------+----------+
Table 5: RIB Settings
Packets from A to E do not require an encapsulation. In the tables
below, this is why E may show as an IPv6 destination address only if
the IPv6 source address X is different from A. Conversely, the
encapsulation is always done when the IPv6 destination address is F
or G. Other destination addresses do not match this P-Route and are
not subject to encapsulation.
The outer headers of the packets that are forwarded along the Track
have the following settings:
+========+=====================+==========================+=========+
| Header | IPv6 Source | IPv6 Destination Address | TrackID |
| | Address | | in RPI |
+========+=====================+==========================+=========+
| Outer | A | E | (A, |
| | | | 129) |
+--------+---------------------+--------------------------+---------+
| Inner | X | Either F or G. If X!=A, | N/A |
| | | E is also permitted. | |
+--------+---------------------+--------------------------+---------+
Table 6: Packet Header Settings
As an example, say that A has a packet for F. Using the RIB in
Table 5:
* From P-DAO 3: A encapsulates the packet and sends it down the
Track signaled by P-DAO 3, with the outer header above. Now the
packet destination is E.
* 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
the packet.
* From Neighbor Cache Entry: E delivers packets to F or G.
3.5.1.3. Segment Routing
In this formulation, protection paths are leveraged to combine
segments and form a graph. The packets are source routed from a
segment to the next to adapt the path:
* P-DAO 1 signals C==>D==>E-to-E
* P-DAO 2 signals A==>B-to-B,C
* P-DAO 3 signals F and G via the A-->C-->E-to-(E),F,G Track
Storing Mode P-DAOs 1 and 2 and Non-Storing Mode P-DAO 3 are sent to
E, B, and A, respectively, as follows:
+====================+==============+==============+==============+
| | P-DAO 1 to E | P-DAO 2 to B | P-DAO 3 to A |
+====================+==============+==============+==============+
| Mode | Storing | Storing | Non-Storing |
+====================+--------------+--------------+--------------+
| Track ingress | A | A | A |
+====================+--------------+--------------+--------------+
| (DODAGID, TrackID) | (A, 129) | (A, 129) | (A, 129) |
+====================+--------------+--------------+--------------+
| SegmentID | 1 | 2 | 3 |
+====================+--------------+--------------+--------------+
| VIO | C, D, E | A, B | C, E |
+====================+--------------+--------------+--------------+
| Targets | E | B, C | F, G |
+====================+--------------+--------------+--------------+
Table 7: P-DAO Messages
Note in the table above that the segment can terminate at the loose
hop as used in the example of P-DAO 1 or at the previous hop as done
with P-DAO 2. Both methods are possible on any segment joined by a
loose protection path. P-DAO 1 generates more signaling since E is
the segment egress when D could be, but a benefit is that it
validates that the connectivity between D and E still exists.
As a result, the RIBs are set as follows:
+======+=============+=========+=============+==========+
| Node | Destination | Origin | Next Hop(s) | TrackID |
+======+=============+=========+=============+==========+
| E | F, G | P-DAO 1 | Neighbor | (A, 129) |
+------+-------------+---------+-------------+----------+
| D | E | P-DAO 1 | Neighbor | (A, 129) |
+------+-------------+---------+-------------+----------+
| C | D | P-DAO 1 | Neighbor | (A, 129) |
+------+-------------+---------+-------------+----------+
| " | E | P-DAO 1 | D | (A, 129) |
+------+-------------+---------+-------------+----------+
| B | C | P-DAO 2 | Neighbor | (A, 129) |
+------+-------------+---------+-------------+----------+
| A | B | P-DAO 2 | Neighbor | (A, 129) |
+------+-------------+---------+-------------+----------+
| " | C | P-DAO 2 | B | (A, 129) |
+------+-------------+---------+-------------+----------+
| " | E, F, G | P-DAO 3 | C, E | (A, 129) |
+------+-------------+---------+-------------+----------+
Table 8: RIB Settings
Packets originated at A to E do not require an encapsulation, but
they carry an SRH via C. The outer headers of the packets that are
forwarded along the Track have the following settings:
+========+=====================+==========================+=========+
| Header | IPv6 Source | IPv6 Destination Address | TrackID |
| | Address | | in RPI |
+========+=====================+==========================+=========+
| Outer | A | C until C then E | (A, |
| | | | 129) |
+--------+---------------------+--------------------------+---------+
| Inner | X | Either F or G. If X!=A, | N/A |
| | | E is also permitted. | |
+--------+---------------------+--------------------------+---------+
Table 9: Packet Header Settings
As an example, say that A has a packet for F. Using the RIB in
Table 8:
* From P-DAO 3: A encapsulates the packet the Track signaled by
P-DAO 3, with the outer header above. Now the destination in the
IPv6 header is C, and an SRH signals that the final destination is
E.
* From P-DAO 2: A forwards to B, and B forwards to C.
* From P-DAO 3: C processes the SRH and sets the destination in the
IPv6 header to E.
* From P-DAO 1: C forwards to D, and D forwards to E; E decapsulates
the packet.
* From the Neighbor Cache Entry: E delivers packets to F or G.
3.5.2. Using Non-Storing Mode Joining Tracks
In this formulation:
* P-DAO 1 signals C==>D==>E-to-(E),F,G
* P-DAO 2 signals A==>B==>C-to-(C),E,F,G
A==>B==>C and C==>D==>E are Tracks expressed as Non-Storing Mode
P-DAOs.
3.5.2.1. Stitched Tracks
Non-Storing Mode P-DAO 1 and 2 are sent to C and A, respectively, as
follows:
+====================+==============+==============+
| | P-DAO 1 to C | P-DAO 2 to A |
+====================+==============+==============+
| Mode | Non-Storing | Non-Storing |
+====================+--------------+--------------+
| Track ingress | C | A |
+====================+--------------+--------------+
| (DODAGID, TrackID) | (C, 131) | (A, 131) |
+====================+--------------+--------------+
| SegmentID | 1 | 1 |
+====================+--------------+--------------+
| VIO | D, E | B, C |
+====================+--------------+--------------+
| Targets | F, G | E, F, G |
+====================+--------------+--------------+
Table 10: P-DAO Messages
As a result, the RIBs are set as follows (using "ND" to indicate that
the address is discovered by IPv6 Neighbor Discovery [RFC4861]
[RFC8505] or an equivalent method):
+======+=============+=========+=============+==========+
| Node | Destination | Origin | Next Hop(s) | TrackID |
+======+=============+=========+=============+==========+
| E | F, G | ND | Neighbor | Any |
+------+-------------+---------+-------------+----------+
| D | E | ND | Neighbor | Any |
+------+-------------+---------+-------------+----------+
| C | D | ND | Neighbor | Any |
+------+-------------+---------+-------------+----------+
| " | E, F, G | P-DAO 1 | D, E | (C, 131) |
+------+-------------+---------+-------------+----------+
| B | C | ND | Neighbor | Any |
+------+-------------+---------+-------------+----------+
| A | B | ND | Neighbor | Any |
+------+-------------+---------+-------------+----------+
| " | C, E, F, G | P-DAO 2 | B, C | (A, 131) |
+------+-------------+---------+-------------+----------+
Table 11: RIB Settings
Packets originated at A to E, F, and G could be generated with the
RPI and the SRH and no encapsulation. Alternatively, A may generate
a native packet to the target and then encapsulate it with an RPI and
an SRH indicating the source-routed path leading to E, as it would
for a packet that it routes coming from another node. This is
effectively the same case as for packets generated by the Root in a
RPL network in Non-Storing Mode; see Section 8.1.3 of [RFC9008]. The
latter is often preferred since it leads to a single code path, and
when the destination is F or G, it does not need to understand and
process the RPI or the SRH. Either way, the packets to E, F, or G
carry an SRH via B and C, and when they reach C, C needs to
encapsulate them again to add an SRH via D and E. The encapsulating
headers of packets that are forwarded along the Track between C and E
have the following settings:
+========+=====================+==========================+=========+
| Header | IPv6 Source Address | IPv6 Destination | TrackID |
| | | Address | in RPI |
+========+=====================+==========================+=========+
| Outer | C | D until D then E | (C, |
| | | | 131) |
+--------+---------------------+--------------------------+---------+
| Inner | X | E, F, or G | N/A |
+--------+---------------------+--------------------------+---------+
Table 12: Packet Header Settings Between C and E
As an example, say that A has a packet for F. Using the RIB in
Table 11:
* From P-DAO 2: A encapsulates the packet with a destination of F in
the Track signaled by P-DAO 2. The outer header has source A,
destination B, an SRH that indicates C as the next loose hop, and
an RPI indicating a TrackID of 131 from A's namespace, which is
distinct from a TrackID of 131 from C's.
* From the SRH: Packets forwarded by B have source A, destination C,
a consumed SRH, and an RPI indicating a TrackID of 131 from A's
namespace. C decapsulates.
* From P-DAO 1: C encapsulates the packet with a destination of F in
the Track signaled by P-DAO 1. The outer header has source C,
destination D, an SRH that indicates E as the next loose hop, and
an RPI indicating a TrackID of 131 from C's namespace. E
decapsulates.
3.5.2.2. External Routes
In this formulation:
* P-DAO 1 signals C==>D==>E-to-(E)
* P-DAO 2 signals A==>B==>C-to-(C),E
* P-DAO 3 signals F and G via the A-->E-to-F,G Track
Non-Storing Mode P-DAO 1 is sent to C, and Non-Storing Mode P-DAOs 2
and 3 are sent to A, as follows:
+====================+==============+==============+==============+
| | P-DAO 1 to C | P-DAO 2 to A | P-DAO 3 to A |
+====================+==============+==============+==============+
| Mode | Non-Storing | Non-Storing | Non-Storing |
+====================+--------------+--------------+--------------+
| Track ingress | C | A | A |
+====================+--------------+--------------+--------------+
| (DODAGID, TrackID) | (C, 131) | (A, 129) | (A, 141) |
+====================+--------------+--------------+--------------+
| SegmentID | 1 | 1 | 1 |
+====================+--------------+--------------+--------------+
| VIO | D, E | B, C | E |
+====================+--------------+--------------+--------------+
| Targets | | E | F, G |
+====================+--------------+--------------+--------------+
Table 13: P-DAO Messages
Note in the table above that E is an implicit Target in P-DAO 1 and
so is C in P-DAO 2. As Non-Storing Mode egress node addresses, they
are not listed in the respective RTOs.
As a result, the RIBs are set as follows:
+======+=============+=========+=============+==========+
| Node | Destination | Origin | Next Hop(s) | TrackID |
+======+=============+=========+=============+==========+
| E | F, G | ND | Neighbor | Any |
+------+-------------+---------+-------------+----------+
| D | E | ND | Neighbor | Any |
+------+-------------+---------+-------------+----------+
| C | D | ND | Neighbor | Any |
+------+-------------+---------+-------------+----------+
| " | E | P-DAO 1 | D, E | (C, 131) |
+------+-------------+---------+-------------+----------+
| B | C | ND | Neighbor | Any |
+------+-------------+---------+-------------+----------+
| A | B | ND | Neighbor | Any |
+------+-------------+---------+-------------+----------+
| " | C, E | P-DAO 2 | B, C | (A, 129) |
+------+-------------+---------+-------------+----------+
| " | F, G | P-DAO 3 | E | (A, 141) |
+------+-------------+---------+-------------+----------+
Table 14: RIB Settings
The encapsulating headers of packets that are forwarded along the
Track between C and E have the following settings:
+========+=====================+==========================+=========+
| Header | IPv6 Source Address | IPv6 Destination | TrackID |
| | | Address | in RPI |
+========+=====================+==========================+=========+
| Outer | C | D until D then E | (C, |
| | | | 131) |
+--------+---------------------+--------------------------+---------+
| Middle | A | E | (A, |
| | | | 141) |
+--------+---------------------+--------------------------+---------+
| Inner | X | E, F, or G | N/A |
+--------+---------------------+--------------------------+---------+
Table 15: Packet Header Settings
As an example, say that A has a packet for F. Using the RIB in
Table 14:
* From P-DAO 3: A encapsulates the packet with a destination of F in
the Track signaled by P-DAO 3. The outer header has source A,
destination E, and an RPI indicating a TrackID of 141 from A's
namespace. This recurses with the following.
* From P-DAO 2: A encapsulates the packet with a destination of E in
the Track signaled by P-DAO 2. The outer header has source A,
destination B, an SRH that indicates C as the next loose hop, and
an RPI indicating a TrackID of 129 from A's namespace.
* From the SRH: Packets forwarded by B have source A, destination C,
a consumed SRH, and an RPI indicating a TrackID of 129 from A's
namespace. C decapsulates.
* From P-DAO 1: C encapsulates the packet with a destination of E in
the Track signaled by P-DAO 1. The outer header has source C,
destination D, an SRH that indicates E as the next loose hop, and
an RPI indicating a TrackID of 131 from C's namespace. E
decapsulates.
3.5.2.3. Segment Routing
In this formulation:
* P-DAO 1 signals C==>D==>E-to-(E)
* P-DAO 2 signals A==>B-to-C
* P-DAO 3 signals F and G via the A-->C-->E-to-(E),F,G Track
Non-Storing Mode P-DAO 1 is sent to C, and Non-Storing Mode P-DAOs 2
and 3 are sent to A, as follows:
+====================+==============+==============+==============+
| | P-DAO 1 to C | P-DAO 2 to A | P-DAO 3 to A |
+====================+==============+==============+==============+
| Mode | Non-Storing | Non-Storing | Non-Storing |
+====================+--------------+--------------+--------------+
| Track ingress | C | A | A |
+====================+--------------+--------------+--------------+
| (DODAGID, TrackID) | (C, 131) | (A, 129) | (A, 141) |
+====================+--------------+--------------+--------------+
| SegmentID | 1 | 1 | 1 |
+====================+--------------+--------------+--------------+
| VIO | D, E | B | C, E |
+====================+--------------+--------------+--------------+
| Targets | | C | F, G |
+====================+--------------+--------------+--------------+
Table 16: P-DAO Messages
As a result, the RIBs are set as follows:
+======+=============+=========+=============+==========+
| Node | Destination | Origin | Next Hop(s) | TrackID |
+======+=============+=========+=============+==========+
| E | F, G | ND | Neighbor | Any |
+------+-------------+---------+-------------+----------+
| D | E | ND | Neighbor | Any |
+------+-------------+---------+-------------+----------+
| C | D | ND | Neighbor | Any |
+------+-------------+---------+-------------+----------+
| " | E | P-DAO 1 | D, E | (C, 131) |
+------+-------------+---------+-------------+----------+
| B | C | ND | Neighbor | Any |
+------+-------------+---------+-------------+----------+
| A | B | ND | Neighbor | Any |
+------+-------------+---------+-------------+----------+
| " | B, C | P-DAO 2 | C | (A, 129) |
+------+-------------+---------+-------------+----------+
| " | E, F, G | P-DAO 3 | C, E | (A, 141) |
+------+-------------+---------+-------------+----------+
Table 17: RIB Settings
The encapsulating headers of packets that are forwarded along the
Track between A and B have the following settings:
+========+=====================+==========================+=========+
| Header | IPv6 Source Address | IPv6 Destination | TrackID |
| | | Address | in RPI |
+========+=====================+==========================+=========+
| Outer | A | B until D then E | (A, |
| | | | 129) |
+--------+---------------------+--------------------------+---------+
| Middle | A | C | (A, |
| | | | 141) |
+--------+---------------------+--------------------------+---------+
| Inner | X | E, F, or G | N/A |
+--------+---------------------+--------------------------+---------+
Table 18: Packet Header Settings
The encapsulating headers of packets that are forwarded along the
Track between B and C have the following settings:
+========+=====================+==========================+=========+
| Header | IPv6 Source Address | IPv6 Destination | TrackID |
| | | Address | in RPI |
+========+=====================+==========================+=========+
| Outer | A | C | (A, |
| | | | 141) |
+--------+---------------------+--------------------------+---------+
| Inner | X | E, F, or G | N/A |
+--------+---------------------+--------------------------+---------+
Table 19: Packet Header Settings
The encapsulating headers of packets that are forwarded along the
Track between C and E have the following settings:
+========+=====================+==========================+=========+
| Header | IPv6 Source Address | IPv6 Destination | TrackID |
| | | Address | in RPI |
+========+=====================+==========================+=========+
| Outer | C | D until D then E | (C, |
| | | | 131) |
+--------+---------------------+--------------------------+---------+
| Middle | A | E | (A, |
| | | | 141) |
+--------+---------------------+--------------------------+---------+
| Inner | X | E, F, or G | N/A |
+--------+---------------------+--------------------------+---------+
Table 20: Packet Header Settings
As an example, say that A has a packet for F. Using Table 18:
* From P-DAO 3: A encapsulates the packet with a destination of F in
the Track signaled by P-DAO 3. The outer header has source A,
destination C, an SRH that indicates E as the next loose hop, and
an RPI indicating a TrackID of 141 from A's namespace. This
recurses with the following.
* From P-DAO 2: A encapsulates the packet with a destination of C in
the Track signaled by P-DAO 2. The outer header has source A,
destination B, and an RPI indicating a TrackID of 129 from A's
namespace. B decapsulates forwards to C based on a sibling
connected route.
* From the SRH: C consumes the SRH and makes the destination E.
* From P-DAO 1: C encapsulates the packet with a destination of E in
the Track signaled by P-DAO 1. The outer header has source C,
destination D, an SRH that indicates E as the next loose hop, and
an RPI indicating a TrackID of 131 from C's namespace. E
decapsulates.
3.6. Complex Tracks
To increase the reliability of the P2P transmission, this
specification enables building a collection of protection paths
between the same ingress and egress Nodes and combining them within
the same TrackID, as shown in Figure 7. Protection paths may be
interleaved at the edges of loose hops or remain parallel.
The segments that join the loose hops of a protection path are
installed with the same TrackID as the protection path. But each
individual protection path and segment has its own P-RouteID that
allows it to be managed separately. Two protection paths of the same
Track may cross at a common node that is a member of a segment of
each protection path or may be joined by additional segments. The
final path of a packet may then be the result of interleaving those
two (and possibly more) protection paths. In that case, the common
node has more than one next hop in its RIB associated to the Track
but no specific signal in the packet to indicate which segment is
being followed. A next hop that can reach the loose hop is selected.
< Controller Plane Functions >
Southbound API
_-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-
_-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-
+----------+
| RPL Root |
+----------+
( main DODAG )
( all around )
<- Protection path 1 via B, E ->
<--- Segment 1 A,B ---> <------- Segment 2 C,D,E ------->
FWD -- Relay -- FWD -- FWD Target 1
/-- Node -- Node -- Node -- Node \ /
--/ (A) (B) \ (C) (D) \ /
Track \ Track
Ingress Segment 5 Egress -- Target
(I) \ -- (E) 2
\ \ / \
\ FWD -- FWD -- Relay -- FWD --/ \
Node -- Node -- Node -- Node Target 3
(F) (G) (H) (J)
<------ Segment 3 F,G,H ------> <---- Segment 4 J,E ---->
<- Protection path 2 via H, E ->
<--- Segment 1 A,B ---> <- S5-> <---- Segment 4 J,E ---->
<- Protection path 3 via B, H, E ->
)
(
( )
Figure 7: Segments and Tracks
Note that while this specification enables building both segments
inside a protection path, for instance, segment 2 above (which is
within protection path 1) and Inter-protection-path segments (i.e.,
North-South) such as segment 5 above (which joins protection paths 1
and 2), it does not signal which Inter-protection-path segments are
available to the ingress, so the use of North-South segments and
associated path redundancy functions is currently limited. The only
possibility available at this time is to define overlapping
protection paths as illustrated in Figure 7, with protection path 3
that is congruent with protection path 1 until node B and that is
congruent with protection path 2 from node H on, abstracting segment
5 as a forward segment.
3.7. Scope and Expectations
3.7.1. External Dependencies
This specification expects that the main DODAG is operated in RPL
Non-Storing Mode to sustain the exchanges with the Root. Based on
its comprehensive knowledge of the parent-child relationship, the
Root can form an abstracted view of the whole DODAG topology. This
document adds the capability for nodes to advertise additional
sibling information to complement the topological awareness of the
Root to be passed on to the PCE and enables the PCE to build more/
better paths that traverse those siblings.
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
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
transmission links. The methods used to learn the node capabilities
and the resources that are available in the devices and in the
network are out of scope for this document. The method to capture
and report the LLN link capacity and reliability statistics are also
out of scope. They may be fetched from the nodes through network
management functions or other forms of telemetry such as Operations,
Administration, and Maintenance (OAM).
3.7.2. Relationship to Other IETF Specifications
3.7.2.1. Extending 6TiSCH
The 6TiSCH architecture [RFC9030] leverages a centralized model that
is similar to that of the DetNet architecture [RFC8655], whereby the
device resources and capabilities are exposed to an external
controller that installs routing states into the network based on its
own Objective Functions that reside in that external entity.
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 protection path 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 for computing routes is a PCE. The PCE computes its
routes based on its own Objective Functions, as described in
[RFC4655], and typically controls the routes using the PCE
Communication Protocol (PCEP) [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
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
Controller. In the latter case, the protocol between the Root and
the PCE is out of scope and mapped to RPL inside the DODAG; one
possible control protocol between the Root and external PCE is for
the Root to transmit the information it received in the RPL DAOs,
including all the SIOs that detail the parent/child and sibling
information, to the PCEs.
The algorithm to compute the paths, the protocol used by the PCE, and
the metrics and link statistics involved in the computation are 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 RPL
network. Which metrics are used and how they are reported are out of
scope, but the expectation is that they are mostly of a long-term,
statistical nature and provide visibility on link throughput,
latency, stability, and availability over relatively long periods.
3.7.2.4. Providing for RAW
A recovery graph as in the RAW architecture [RAW-ARCH] can be
composed of forward East-West directional segments and North-South
bidirectional segments to enable additional path diversity using
PREOF to select the protection paths to be used for a given datagram.
This provides a dynamic balance between the reliability and
availability requirements of the flows and the need to conserve
energy and spectrum. This specification prepares for RAW by setting
up the Tracks, but it only forms DODAGs, which are composed of
aggregated end-to-end loose source-routed protection paths, joined by
strict routed segments, all oriented forward.
The RAW architecture defines a data plane extension of the PCE called
the Point of Local Repair (PLR) that adapts the use of the path
redundancy within a Track to defeat the diverse causes of packet
loss. The PLR controls the forwarding operation of the packets
within a Track. This specification can use but does not impose a PLR
and does not provide the policies that would select which packets are
routed through which path within a Track (in other words, how the PLR
may use the path redundancy within the Track). By default, the use
of the available redundancy is limited to simple load balancing, and
all the segments are forward unidirectional only.
A Track may be set up to reduce the load around the Root or to enable
urgent traffic to flow more directly. This specification does not
provide the policies that would decide which flows are routed through
which Track. In a Non-Storing Mode RPL Instance, the main DODAG
provides a default route via the Root, and the Tracks provide more-
specific routes to the Track Targets.