6. Root-Initiated Routing State
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
6. Root-Initiated Routing State
6.1. RPL Network Setup
To avoid the need of Path MTU Discovery by 6LoWPAN endpoints, 6LoWPAN
links are normally defined with an 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 fragmentation if the resulting packets exceed 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 define
an MTU that is larger than 1280 between the RPL routers that form the
main DODAG to allow for the necessary header additions, while still
exposing 1280 to the 6LoWPAN endpoint stacks.
6.2. Requesting a Track
This specification introduces the P-DAO-REQ message, which is used by
an LLN node to request the formation of a new Track for which the LLN
node is the ingress. Note that the namespace for the TrackID is
owned by the ingress node, and in the absence of a P-DAO-REQ, there
must be some procedure for the Root to assign TrackIDs in that
namespace while avoiding collisions (see more in Section 6.3).
The P-DAO-REQ signals the desired TrackID and the duration for which
the Track should be established. Upon a P-DAO-REQ, the Root MAY
install the Track as requested, in which case it answers with a PDR-
ACK indicating the granted Track Lifetime. All the segments MUST be
of the same mode, either Storing or Non-Storing. All the segments
MUST be created with the same TrackID and the same DODAGID signaled
in the P-DAO.
The Root designs the Track as it sees fit and updates/changes the
segments over time to serve the Track as needed. Note that there is
no protocol element to notify the requesting Track ingress when
changes happen deeper down the Track, so they are transparent to the
Track ingress. If the main Root cannot maintain an expected service
level, then it needs to tear down the Track completely. The Segment
Lifetime in the P-DAO messages does not need to be aligned to the
Requested Lifetime in the P-DAO-REQ or between P-DAO messages for
different segments. For example, the Root may use shorter lifetimes
for the segments and renew them or change them during the lifetime of
the Track. All the components (protection paths and segments) of a
Track MUST be destroyed (or have their lifetime elapsed) before the
TrackID can be reused.
When the Track Lifetime is relatively close to elapse -- meaning in
the order of the trip time from the node to the Root -- the
requesting node SHOULD resend a P-DAO-REQ using the TrackID in the
PDR-ACK to extend the lifetime of the Track; otherwise, the Track
will time out, and the Root will tear down the whole structure.
If the Track fails and cannot be restored, the Root notifies the
requesting node asynchronously with a PDR-ACK with a Track Lifetime
of 0, indicating that the Track has failed, and a PDR-ACK Status,
indicating the reason of the fault.
6.3. Identifying a Track
RPL defines the concept of an Instance to signal an individual
routing topology, and multiple topologies can coexist in the same
network. The RPLInstanceID is tagged in the RPI of every packet to
signal which topology the packet actually follows.
This specification leverages the RPL Instance model as follows:
* The main Root MAY use P-DAO messages to add better routes in the
main Instance in conformance with the routing objectives in that
Instance.
To achieve this, the main Root MAY install a segment along a path
down the main DODAG, which is operated in Non-Storing Mode. This
enables loose source routing and reduces the size of the Routing
Header; see Section 3.3.1. The main Root MAY also install a
protection path across the main DODAG to complement the routing
topology.
When adding a P-Route to the RPL main DODAG, the main Root MUST
set the RPLInstanceID field of the P-DAO Base Object (see
Section 6.4.1 of [RPL]) to the RPLInstanceID of the main DODAG,
and it MUST NOT use the DODAGID field. A P-Route provides a
longer match to the Target Address than the default route via the
main Root, so it is preferred.
* The main Root MAY also use P-DAO messages to install a Track as an
independent routing topology (say, Traffic Engineered) to achieve
particular routing characteristics from ingress to egress
endpoints. To achieve this, the main Root MUST set up a Local RPL
Instance (see Section 5 of [RPL]), and the Local RPLInstanceID
serves as the TrackID. The TrackID MUST be unique for the IPv6
ULA or GUA of the Track ingress that serves as the DODAGID for the
Track.
This way, a Track is uniquely identified by the tuple (DODAGID,
TrackID) where the TrackID is always represented with the 'D' flag
set to 0 (see also Section 5.1 of [RPL]), indicating that when
used in an RPI, the source address of the IPv6 packet signals the
DODAGID.
The P-DAO Base Object MUST indicate the tuple (DODAGID, TrackID)
that identifies the Track as shown in Figure 8, and the P-RouteID
that identifies the P-Route MUST be signaled in the VIO as shown
in Figure 16.
The Track ingress is the Root of the DODAGID formed by the Local
RPL Instance. It owns the namespace of its TrackIDs, so it can
pick any unused value to request a new Track with a P-DAO-REQ. In
a particular deployment where P-DAO-REQs are not used, a portion
of the namespace can be administratively delegated to the main
Root, meaning that the main Root is authoritative for assigning
the TrackIDs for the Tracks it creates.
With this specification, the main Root is aware of all the active
Tracks, so it can also pick any unused value to form Tracks
without a P-DAO-REQ. To avoid a collision of the main Root and
the Track ingress picking the same value at the same time, it is
RECOMMENDED that the Track ingress starts allocating the ID value
of the Local RPLInstanceID (see Section 5.1 of [RPL]) used as
TrackIDs with the value 0 incrementing, while the Root starts with
63 decrementing.
6.4. Installing a Track
A path can be installed by a single P-Route that signals the sequence
of consecutive nodes either in Storing Mode as a single-segment Track
or in Non-Storing Mode as a single-protection-path Track. A single-
protection-path Track can be installed as a loose Non-Storing Mode
P-Route, in which case the next loose entry must recursively be
reached over a path.
A Complex Track can be installed as a collection of P-Routes with the
same DODAGID and TrackID. The ingress of a Non-Storing Mode P-Route
is the owner and Root of the DODAGID. The ingress of a Storing Mode
P-Route must be either the owner of the DODAGID or a hop of a
protection path of the same Track. In the latter case, the Targets
of the P-Route must include the next hop of the protection path if
there is one to ensure forwarding continuity. In the case of a
Complex Track, each segment is maintained independently and
asynchronously by the Root, with its own lifetime that may be
shorter, the same, or longer than that of the Track.
A route along a Track for which the TrackID is not the RPLInstanceID
of the main DODAG MUST be installed with a higher precedence than the
routes along the main DODAG, meaning that:
* The longest match MUST be the prime comparison for routing.
* For an equal-length match, the route along the Track MUST be
preferred over the one along the main DODAG.
* There SHOULD NOT be two different Tracks leading to the same
Target from same ingress node, unless there's a policy for
selecting which packets use which Track; such a policy is out of
scope.
* A packet that was routed along a Track MUST NOT be routed along
the main DODAG again; if the destination is not reachable as a
neighbor by the node where the packet exits the Track, then the
packet MUST be dropped.
6.4.1. Signaling a Projected Route
This specification adds a capability whereby the Root of a main DODAG
installs a Track as a collection of P-Routes, using a P-DAO message
for each individual protection path or segment. The P-DAO signals a
collection of Targets in one or more RTOs. Those Targets can be
reached via a sequence of routers indicated in a VIO.
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
the RPL specification [RPL]; this is determined using the Segment
Sequence information from the VIO as opposed to the Path Sequence
from a TIO. Also, a Segment Lifetime of 0 in a VIO indicates that
the P-Route associated to the segment is to be removed. There are
two Modes of operation for the P-Routes: Storing and Non-Storing.
A P-DAO message MUST be sent from the address of the Root that serves
as the DODAGID for the main DODAG. It MUST contain either exactly
one sequence of one or more RTOs followed by one VIO or any number of
sequences of one or more RTOs followed by one or more TIOs. The
former is the normal expression for this specification, whereas the
latter corresponds to the variation for less-constrained environments
described in Section 7.2.
A P-DAO that creates or updates a protection path MUST be sent to a
GUA or a ULA of the ingress of the protection path; it MUST contain
the full list of hops in the protection path unless the protection
path is being removed. A P-DAO that creates a new Track segment MUST
be sent to a GUA or a ULA of the segment egress and MUST signal the
full list of hops in a segment; a P-DAO that updates (including
deletes) a section of a segment MUST be sent to the first node after
the modified segment and MUST signal the full list of hops in the
section starting at the node that immediately precedes the modified
section.
In Non-Storing Mode, as discussed in Section 6.4.3, the Root sends
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
on the installed path and forwarded in the reverse direction,
installing a Storing Mode state at each hop, as discussed in
Section 6.4.2. In both cases, the Track ingress is the owner of the
Track, and it generates the P-DAO-ACK when the installation is
successful.
If the 'K' flag is present in the P-DAO, the P-DAO MUST be
acknowledged using a P-DAO-ACK that is sent back to the address of
the Root from which the P-DAO was received. In most cases, the first
node of the protection path, segment, or updated section of the
segment is the node that sends the acknowledgment. The exception to
the rule is when an intermediate node in a segment fails to forward a
Storing Mode P-DAO to the previous node in the SM-VIO.
In a No-Path Non-Storing Mode P-DAO, the SRH-6LoRH MUST NOT be
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
Address, and a Via Address MUST NOT be present more than once, which
would create a loop.
A node that processes a VIO MAY verify whether any of these
conditions happen, and when one does, it MUST ignore the P-DAO and
reject it with a RPL rejection status of "Error in VIO" in the DAO-
ACK; see Section 11.16.
Errors, other than those discussed explicitly, that prevent the
installation of the route are acknowledged with a RPL rejection
status of "Unqualified Rejection" in the P-DAO-ACK.
6.4.2. Installing a Track Segment with a Storing Mode P-Route
As illustrated in Figure 18, a Storing Mode P-DAO installs a route
along the segment signaled by the SM-VIO towards the Targets
indicated in the Target Options. The segment is to be included in a
DODAG indicated by the P-DAO Base Object, which may be the one formed
by the main DODAG, or a Track associated with a Local RPL Instance.
------+---------
| Internet
|
+-----+
| | Border Router
| | (RPL Root)
+-----+ | P- ^ |
| | DAO | P-DAO-ACK |
o o o o | | |
o o o o Ingress o o o | ^ | Projected .
o o o o o \\ o o o | | P-DAO | Route .
o o o o \\ o o o o | ^ | .
o o o o o Egress o o v | P-DAO v .
o o LLN o o o |
o o o o o Loose Source Route Path |
o o o o v
Figure 18: Projecting a Route
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
routing segment that is being installed. The P-DAO message contains
an SM-VIO with a strict sequence of Via Addresses. The SM-VIO
follows one or more RTOs indicating the Targets to which the Track
leads. The SM-VIO contains a Segment Lifetime for which the state is
to be maintained.
The Root sends the P-DAO directly to the egress node of the segment.
In that P-DAO, the destination IP address matches the last Via
Address in the SM-VIO. This is how the egress recognizes its role.
In a similar fashion, the segment ingress node recognizes its role
because it matches the first Via Address in the SM-VIO.
The egress node of the segment is the only node in the path that does
not install a route in response to the P-DAO; it is expected to be
already able to route to the Target(s) based on its existing tables.
If one of the Targets is not known, the node MUST answer to the Root
with a P-DAO-ACK listing the unreachable Target(s) in an RTO and a
rejection status of "Unreachable Target".
If the egress node can reach all the Targets, it forwards the P-DAO
with unchanged content to its predecessor in the segment as indicated
in the list of VIOs, and the message is recursively propagated
unchanged along the sequence of routers indicated in the P-DAO, but
in the reverse order, from egress to ingress.
The address of the predecessor to be used as the destination of the
propagated DAO message is found in the Via Address list at the
position preceding the one that contains the address of the
propagating node, which is used as the source of the message.
Upon receiving a propagated DAO, all except the egress router MUST
install a route towards the DAO Target(s) via their successor in the
SM-VIO. A router that cannot store the routes to all the Targets in
a P-DAO MUST reject the P-DAO by sending a P-DAO-ACK to the Root with
a rejection status of "Out of Resources" as opposed to forwarding the
DAO to its predecessor in the list. The router MAY install
additional routes towards the Via Addresses that appear in the SM-VIO
after its own address, if any, but in case of a conflict or a lack of
resource, the route(s) to the Target(s) MUST be installed in
priority.
If a router cannot reach its predecessor in the SM-VIO, the router
MUST send the P-DAO-ACK to the Root with a rejection status of
"Predecessor Unreachable".
The process continues until the P-DAO is propagated to the ingress
router of the segment, which answers with a P-DAO-ACK to the Root.
The Root always expects a P-DAO-ACK, either from the Track ingress
with a positive status or from any node along the segment with a
negative status. If the P-DAO-ACK is not received, the Root may
retry the DAO with the same TrackID or tear down the route.
6.4.3. Installing a Protection Path with a Non-Storing Mode P-Route
As illustrated in Figure 19, a Non-Storing Mode P-DAO installs a
source-routed path within the Track indicated by the P-DAO Base
Object towards the Targets indicated in the Target Options. The
source-routed path requires a Source Routing Header, which implies an
IP-in-IP encapsulation is needed to add the SRH to an existing
packet. It is sent to the Track ingress, which creates a tunnel
associated with the Track and connected routes over the tunnel to the
Targets in the RTO. The tunnel encapsulation MUST incorporate a
Routing Header via 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 verbatim by the Track ingress when it
encapsulates a packet to forward it over the Track.
------+---------
| Internet
|
+-----+
| | Border Router
| | (RPL Root)
+-----+ | P- ^ P-DAO-ACK
| Track | DAO |
o o o Ingress V |
o o o o o o X o X Source-
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 o o X X
Egress
o o o o o |
Target
o o LLN o
o o o o
Figure 19: Projecting a Non-Storing Route
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,
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
must be installed from the last to the first along the datapath. For
instance, a segment of a Track must be installed before the
protection path(s) of the same Track that uses it, and stitched
segments must be installed in order from the last to the first to
reach the Targets.
If the next entry in the loose sequence is reachable over a Storing
Mode P-Route, it MUST be the Target of a segment and the ingress of a
next segment, which are both already set up; the segments are
associated with the same Track, which avoids needing an additional
encapsulation. For instance, in Section 3.5.1.3, segments A==>B-to-C
and C==>D==>E-to-F must be installed with Storing Mode P-DAO messages
1 and 2 before the Track A-->C-->E-to-F that joins them can be
installed with Non-Storing Mode P-DAO 3.
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
previously installed Track and the ingress of a next Track, which
requires de- and re-encapsulation when switching the outer Tracks
that join the loose hops. This is exemplified in Section 3.5.2.3
where Non-Storing Mode P-DAOs 1 and 2 install strict Tracks that Non-
Storing Mode P-DAO 3 joins as a super Track. In such a case, packets
are subject to double IP-in-IP encapsulation.
6.5. Tearing Down a P-Route
A P-DAO with a lifetime of 0 is interpreted as a No-Path DAO. Its
function is to clean up an existing state as opposed to refreshing it
or installing a new one. To tear down a Track, the Root must tear
down all the Track segments and protection paths that compose it one
by one.
Since the protection path state of a Track is located only on the
ingress Node, the Root cleans up the protection path by sending an
NSM-VIO to the ingress to indicate the TrackID and the P-RouteID of
the protection path being removed, a Segment Lifetime of 0, and a
newer Segment Sequence. The SRH-6LoRH with Via Addresses in the NSM-
VIO is not needed; it SHOULD NOT be placed in the message and MUST be
ignored by the receiver. Upon 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
last node of the segment with an updated TrackID and P-RouteID, a
Segment Lifetime of 0, and a newer Segment Sequence. The Via
Addresses in the SM-VIO indicate the 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 totally removed or a sequence of one or
more nodes that have been bypassed by a segment update.
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.
This results in cleaning up the existing segment state, if any, as
opposed to refreshing an existing one or installing a new one.
6.6. Maintaining a Track
Repathing a Track segment or protection path may cause jitter and
packet misordering. For critical flows that require timely and/or
in-order delivery, it might be necessary to deploy PREOF [RAW-ARCH]
over a highly redundant Track. This specification allows the use of
more than one protection path for a Track and 1+N packet redundancy.
This section provides the steps to ensure that no packet is lost due
to the operation itself. This is ensured by installing the new
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
the section have already installed their own. The disabled section
is removed as well when the in-flight packets are forwarded along the
new section.
6.6.1. Maintaining a Track Segment
To modify a section of a segment between the first node and a second
downstream node (which can be the ingress and egress, respectively)
while retaining those nodes in the segment, the Root sends an SM-VIO
to the second node indicating the sequence of nodes in the new
section of the segment. The SM-VIO indicates the TrackID and the
P-RouteID of the segment being updated and a newer Segment Sequence.
The P-DAO is propagated from the second to the first node, and on the
way, it updates the state on the nodes that are common to the old and
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
still receive packets that were in flight from the ingress to self
over the old section of the segment. Since the remainder of the
segment is already updated, the packets are forwarded along the new
version of the segment from that node on.
After a reasonable amount of time, the Root tears down the remaining
section(s) of the old segments as described in Section 6.5 to enable
the deprecated sections to drain their traffic.
6.6.2. Maintaining a Protection Path
This specification allows the Root to add protection paths to a Track
by sending a Non-Storing Mode P-DAO to the ingress associated to the
same TrackID and a new SegmentID. If the protection path is loose,
then the segments that join the hops must be created first. It makes
sense to add a new protection path before removing one that is
becoming excessively lossy and switch to the new protection path
before removing the old. Dropping a Track before the new one is
installed would reroute the traffic via the Root; this may increase
the latency beyond acceptable thresholds and overload 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 might
be routed back and reinjected at the ingress of the first Track.
It is also possible to update a protection path by sending a Non-
Storing Mode P-DAO to the ingress with the same SegmentID, an
incremented Segment Sequence, and the new complete list of hops in
the NSM-VIO. Updating a live protection path means changing one or
more of the intermediate loose hops, and it involves laying out new
segments from and to the new loose hops before the NSM-VIO is issued
for the new protection path.
Packets that are in flight over the old version of the protection
path still follow the old source route path over the old segments.
After a reasonable time, the Root tears down those segments as
described in Section 6.5 to enable the deprecated segments to drain
their traffic.
6.7. Encapsulating and Forwarding Along a Track
When injecting a packet in a Track, the ingress router must
encapsulate the packet using IP-in-IP to add the Source Routing
Header with the final destination set to the Track egress.
All properties of a Track's operations are inherited from the main
Instance that is used to install the Track. For instance, the use of
compression per [RFC8138] is determined by whether it is used in the
RPL main DODAG, e.g., by setting the 'T' flag [RFC9035] in the RPL
Configuration option.
When the Track ingress places a packet in a Track, it encapsulates it
with an additional IPv6 header, a Routing Header, and an IPv6 Hop-by-
Hop Option Header that contains the RPI as follows:
* In the uncompressed form, the source of the packet is the address
that this router uses as the DODAGID for the Track, the
destination is the first Via Address in the NSM-VIO, and the RH is
an SRH [RFC6554] that contains the list of the remaining Via
Addresses, ending with the Track egress.
* In a network where 6LoWPAN header compression [RFC6282] is in use,
it is preferred to implement "IPv6 over Low-Power Wireless
Personal Area Network (6LoWPAN) Paging Dispatch" [RFC8025] and
compress the RPL artifacts as indicated in [RFC8138].
In that case, the RPL Source Route Header is the exact copy of the
(chain of) SRH-6LoRH found in the NSM-VIO, also ending with the
Track egress. The RPI-6LoRH is appended next, followed by an IP-
in-IP 6LoRH header that indicates the ingress router in the
Encapsulator Address field; see a similar case in Figure 20 of
[RFC8138].
To signal the Track in the packet, this specification leverages the
RPL forwarding model as follows:
* In the data packets, the Track DODAGID and the TrackID MUST be
respectively signaled as the IPv6 source address, and the
RPLInstanceID field of the RPI MUST be placed in the outer chain
of IPv6 headers.
The RPI carries a Local RPLInstanceID called the TrackID, which,
in association with the DODAGID, indicates the Track along which
the packet is forwarded.
The 'D' flag in the RPLInstanceID MUST be set to 0 to indicate
that the source address in the IPv6 header is set to the DODAGID
(see more in Section 6.3).
* This specification conforms to the principles of [RFC9008] with
regard to packet forwarding and encapsulation along a Track as
follows:
- With this specification, the Track is a RPL DODAG. From the
perspective of that DODAG, the Track ingress is the Root, the
Track egress is a RPL-Aware 6LR, and neighbors of the Track
egress that can be reached via the Track, but are external to
it, are external destinations and treated as RPL-Unaware Leaves
(RULs). The encapsulation rules in [RFC9008] apply.
- If the Track ingress is the originator of the packet and the
Track egress is the destination of the packet, there is no need
for an encapsulation.
- Thus, the Track ingress must encapsulate the traffic that it
did not originate, and it must include an RPI in the
encapsulation to signal the TrackID.
A packet that is being routed over the RPL Instance associated to
a first Non-Storing Mode Track MAY be placed recursively in a
second Track to cover one loose hop of the first Track, as
discussed in more detail in Section 3.5.2.3. On the other hand, a
Storing Mode segment must be strict, and a packet that it placed
in a Storing Mode segment MUST follow that segment till the
segment egress.
It is known that a packet is forwarded along a Track by the source
address and the RPI in the encapsulation. The TrackID is used to
identify the RIB entries associated to that Track, which, in
intermediate nodes, correspond to the P-Routes for the segments of
the Track that the forwarding router is aware of. Packet processing
uses the following precedence: 1) self-delivery or Routing Header
handling when one is present, 2) delivery to direct neighbors, 3)
delivery to indirect neighbors, 4) routing along a segment along the
Track, and 5) injecting the packet in another Track, as a last
resort.
To achieve this, the packet handling logic MUST happen in the
following order:
* If the destination of the packet is self:
1. If the header chain contains a RPL Source Route Header that is
not fully consumed, then the packet is forwarded along the
Track as prescribed by [RFC6554], meaning that the next entry
in the Routing Header becomes the destination.
2. Otherwise, if the packet was encapsulated, then the packet is
decapsulated and the forwarding process recurses; else, the
packet is delivered to the stack.
* Otherwise, the packet is forwarded as follows:
1. If the destination of the packet is a direct neighbor, e.g.,
installed by IPv6 Neighbor Discovery, then the packet MUST be
forwarded to that neighbor.
2. Else, if the destination of the packet is an indirect
neighbor, e.g., installed by a multicast DAO message from a
common neighbor (see Section 4.1.4), then the packet MUST be
forwarded to the common neighbor.
3. Else, if there is a RIB entry for the same Track (e.g.,
installed by an SM-VIO in a DAO message with the destination
as the target) and the next hop in the RIB entry is a direct
neighbor, then the packet is passed to that neighbor.
4. Else, if there is a RIB entry for the different Track (e.g.,
installed by an NSM-VIO in a DAO message with the destination
as the target), then the packet is encapsulated to be
forwarded along that Track and the forwarding process
recurses; otherwise, the packet is dropped.
5. To avoid loops, and as opposed to packets that were not
encapsulated, a packet that was decapsulated from a Track MUST
NOT be routed along the default route of the main DODAG; this
would mean that the end-to-end path is uncontrolled. The node
that discovers the fault MUST discard the packet.
The node that drops a packet in any of the steps above MUST send an
ICMPv6 error message [RFC4443] to the Root, with a new code "Error in
P-Route" (see Section 11.15). The Root can then repair by updating
the broken segment and/or Tracks. In the case of a broken segment,
the Root removes the leftover sections of the segment using SM-VIOs
with a lifetime of 0, indicating the section where one or more nodes
are being removed (see Section 6.6).
In case of a permanent forwarding error along a source route path,
the node that fails to forward SHOULD send an ICMP error with the
code "Error in Source Routing Header" back to the source of the
packet, as described in Section 11.2.2.3 of [RPL]. Upon receiving
this message, the encapsulating node SHOULD stop using the source
route path for a reasonable period of time, which depends on the
deployment, and it SHOULD send an ICMP message with the code "Error
in P-Route" to the Root. Failure to follow these steps may result in
packet loss and wasted resources along the source route path that is
broken.
Either way, the ICMP message MUST be throttled in case of consecutive
occurrences. It MUST be sourced at the ULA or GUA that is used in
this Track for the source node, so the Root can establish where the
error happened.
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
the hop of the RH SHOULD be consumed by this node so that the
destination in the IPv6 header is the next hop that this node could
not reach. If a 6LoRH [RFC8138] is used to carry the IPv6 routing
information in the outer header, then the whole 6LoRH information
SHOULD be present in the ICMP message.
6.8. Compression of RPL Artifacts
When the main DODAG in a 6LoWPAN LLN is operated in Non-Storing Mode
and the data packets are compressed using [RFC8138], a typical packet
that circulates in the main DODAG is formatted as shown in Figure 20,
representing the case where an IP-in-IP encapsulation is needed (see
Table 19 of [RFC9008]):
+-+ ... -+- ... -+- ... -+-+- ... +-+-+-+ ... +-+-+ ... -+ ... +-...
|11110001| SRH- | RPI- | IP-in-IP | NH=1 |11110CPP| UDP | UDP
| Page 1 | 6LoRH | 6LoRH | 6LoRH |LOWPAN_IPHC| UDP | hdr |Payld
+-+ ... -+- ... -+- ... -+-+- ... +-+-+-+ ... +-+-+ ... -+ ... +-...
<= RFC 6282 =>
<================ Inner packet ==================== = =
Figure 20: A Packet as Forwarded Along the Main DODAG
Since there is no page switch between the encapsulated packet and the
encapsulation, the first octet of the compressed packet that acts as
the page selector is actually removed at encapsulation; therefore,
the inner packet used in the descriptions below starts with the SRH-
6LoRH and is exactly the packet represented in Figure 20, from the
second octet onward.
When encapsulating the inner packet to place in the Track, the 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 address,
which maps to the IPv6 source address in the uncompressed form,
contains a GUA or ULA IPv6 address of the ingress node that serves as
the DODAGID for the Track, expressed in a compressed form using the
DODAGID of the main DODAG as a reference for the compression. If the
address is compressed to 2 bytes, the resulting value for the Length
field (shown in Figure 21) is 3, meaning that the SRH-6LoRH as a
whole is 5 octets long.
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- ... -+
|1|0|1| Length | 6LoRH Type 6 | Hop Limit | Track DODAGID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- ... -+
Figure 21: The IP-in-IP 6LoRH Header
At the head of the resulting sequence of bytes, the Track ingress
then adds a P-RPI-6LoRH header to transport the RPI in its compressed
form as illustrated in Figure 12. The RPI carries the TrackID as
RPLInstanceID. Combined with the IP-in-IP 6LoRH header, this allows
identifying the Track without ambiguity.
The SRH-6LoRH is then added at the head of the resulting sequence of
bytes as a verbatim copy of the content of the SM-VIO that signaled
the selected protection path.
0 1
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- -+- -+ ... +- -+
Where N = Size + 1
Figure 22: The SRH-6LoRH Header
The format of the resulting encapsulated packet, which is in
compressed form per [RFC8138], is illustrated in Figure 23:
+-+ ... -+-+-+- ... -+-+-+- ... -+-+-+-+-+- ... +-+-+-+-+-+-+- ...
| Page 1 | SRH-6LoRH | P-RPI-6LoRH | IP-in-IP 6LoRH | Inner Packet
+-+ ... -+-+-+- ... -+-+-+- ... -+-+-+-+-+- ... +-+-+-+-+-+-+- ...
Signals : Loose Hops : TrackID : Track DODAGID :
Figure 23: A Packet as Forwarded Along a Track