4. Extending and Amending Existing RFCs
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
4. Extending and Amending Existing RFCs
This section explains which changes are extensions and which are
amendments to existing specifications. It is expected that
extensions to existing specifications will not cause existing code on
legacy 6LRs to malfunction, as the extensions will simply be ignored.
New code is required for an extension. Those 6LRs will be unable to
function in the new mechanisms and may also make the P-DAOs
impossible to install. Amendments to existing specifications are
situations where there are semantic changes required to existing code
and where new unit tests may be required to confirm that legacy
operations will continue unaffected.
4.1. Extending RFC 6550
This specification Extends RPL [RPL] to enable the Root to install
forward routes inside a main DODAG that is operated as Non-Storing
Mode. The Root issues a P-DAO message (see Section 4.1.1) to the
Track ingress; the P-DAO message contains a new VIO that installs a
strict or a loose sequence of hops to form a Track segment or a
protection path, respectively.
The Projected DAO Request (P-DAO-REQ) is a new message detailed in
Section 5.1. As per Section 6 of [RPL], if a node receives this
message and it does not understand this new code, it discards the
message. When the Root initiates communication to a node that it has
not communicated with before and that it has not ascertained to
implement this specification (by means such as capabilities), then
the Root SHOULD request a Projected DAO Request Acknowledgment (PDR-
ACK).
A P-DAO-REQ message enables a Track ingress to request the Track from
the Root. The resulting Track is also a DODAG for which the Track
ingress is the Root, and the owner is the address that serves as the
DODAGID and is authoritative for the associated namespace from which
the TrackID is selected. In the context of this specification, the
installed route appears as a more-specific route to the Track
Targets, and the Track ingress forwards the packets toward the
Targets via the Track using normal longest match IP forwarding.
To ensure that the P-DAO-REQ and P-DAO messages can flow at most
times, it is RECOMMENDED that the nodes involved in a Track maintain
multiple parents in the main DODAG, advertise them all to the Root,
and use them in turn to retry similar packets. It is also
RECOMMENDED that the Root uses diverse source route paths to retry
similar messages to the nodes in the Track.
4.1.1. Projected DAO
Section 6 of [RPL] introduces the RPL Control Message Options (CMOs),
including the RPL Target Option (RTO) and Transit Information Option
(TIO), which can be placed in RPL messages such as the DAO. A DAO
message signals routing information to one or more Targets indicated
in the RTOs and provides one and only one via-node in the TIO, with
the via-node being the tunnel endpoint to reach the targets.
This document Amends the specification of the DAO to create the P-DAO
message. This Amended DAO is signaled with a new "Projected DAO" (P)
flag; see Figure 8.
A P-DAO is a special DAO message generated by the Root to install a
P-Route formed of multiple hops in its DODAG. This provides a RPL-
based method to install the Tracks as a collection of multiple
P-Routes as expected by the 6TiSCH architecture [RFC9030].
The Root MUST source the P-DAO message with its address that serves
as the DODAGID for the main DODAG. The receiver MUST NOT accept a
P-DAO message that is not sent by the Root of its DODAG and MUST
ignore such messages silently.
The 'P' flag is encoded in bit position 2 of the Flags field in the
DAO Base Object. The Root MUST set it to 1 in a P-DAO message.
Otherwise, it MUST be set to 0. It is set to 0 in legacy
implementations as specified, respectively, in Sections 20.11 and 6.4
of [RPL].
The P-DAO is a part of control plane signaling and should not be
stuck behind high traffic levels. The expectation is that the P-DAO
message be sent at a high QoS level, above that of data traffic,
typically with the Network Control precedence.
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| TrackID |K|D|P| Flags | Reserved | DAOSequence |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ +
| DODAGID field is set to the |
+ IPv6 address of the Track ingress +
| used to source encapsulated packets |
+ +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Option(s)...
+-+-+-+-+-+-+-+-+
Figure 8: Projected DAO Base Object
New fields:
TrackID: The Local or Global RPLInstanceID of the DODAG that serves
as the Track (see more in Section 6.3).
P: 1-bit flag.
The 'P' flag is set to 1 by the Root to signal a P-DAO; otherwise,
it is set to 0.
The 'D' flag is set to 1 to signal that the DODAGID field is present.
It may be set to 0 if and only if the destination address of the
Projected DAO Acknowledgment (P-DAO-ACK) message is set to the IPv6
address that serves as the DODAGID, and it MUST be set to one
otherwise, meaning that the DODAGID field MUST then be present.
In RPL Non-Storing Mode, the TIO and RTO are combined in a DAO
message to inform the DODAG Root of all the edges in the DODAG, which
are formed by the directed parent-child relationships. The DAO
message signals to the Root that a given parent can be used to reach
a given child. The P-DAO message generalizes the DAO to signal to
the Track ingress that a Track, for which the sender is the Root, can
be used to reach children and siblings of the Track egress. In both
cases, options may be factorized and multiple RTOs may be present to
signal a collection of children that can be reached through the
parent or the Track, respectively.
4.1.2. Projected DAO Acknowledgment
This document also Amends the DAO-ACK message. The new 'P' flag
signals the projected form.
The format of the P-DAO-ACK message is thus illustrated in Figure 9:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| TrackID |D|P| Reserved | DAOSequence | Status |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ +
| DODAGID field is set to the |
+ IPv6 address of the Track ingress +
| used to source encapsulated packets |
+ +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Option(s)...
+-+-+-+-+-+-+-+-+
Figure 9: P-DAO-ACK Base Object
New fields:
TrackID: The Local or Global RPLInstanceID of the DODAG that serves
as the Track (see more in Section 6.3).
P: 1-bit flag.
The 'P' flag is set to 1 by the Root to signal a P-DAO; otherwise,
it is set to 0.
The 'D' flag is set to 1 to signal that the DODAGID field is present.
It may be set to 0 if and only if the source address of the P-DAO-ACK
message is set to the IPv6 address that serves as the DODAGID, and it
MUST be set to one otherwise, meaning that the DODAGID field MUST
then be present.
4.1.3. Via Information Option
This document Extends the CMO to create new objects called Via
Information Options (VIOs). The VIOs are the multi-hop alternative
to the TIOs (see more in Section 5.3). One VIO is the stateful
Storing Mode VIO (SM-VIO); an SM-VIO installs a strict hop-by-hop
P-Route called a Track segment. The other is the Non-Storing Mode
VIO (NSM-VIO); the NSM-VIO installs a loose source-routed P-Route
called a protection path at the Track ingress, which uses that state
to encapsulate an IP-in-IP packet with a new Routing Header (RH) to
the Track egress (see more in Section 6.7).
A P-DAO contains one or more RTOs to indicate the Target
(destinations) that can be reached via the P-Route, followed by
exactly one VIO that signals the sequence of nodes to be followed
(see more in Section 6). There are two modes of operation for the
P-Routes: Storing Mode and Non-Storing Mode (see more in Sections
6.4.2 and 6.4.3, respectively).
4.1.4. Sibling Information Option
This specification Extends the CMO to create the Sibling Information
Option (SIO). The SIO is used by a RPL-Aware Node (RAN) to advertise
a selection of its candidate neighbors as siblings to the Root (see
more in Section 5.4). The SIO is placed in DAO messages that are
sent directly to the main Root, including multicast DAO (see
Section 9.10 of [RPL]).
This specification Amends rules 1 and 2 listed in Section 9.10 of
[RPL] for the multicast DAO operation as follows:
OLD:
| 1. A node MAY multicast a DAO message to the link-local scope
| all-RPL-nodes multicast address.
|
| 2. A multicast DAO message MUST be used only to advertise
| information about the node itself, i.e., prefixes directly
| connected to or owned by the node, such as a multicast group
| that the node is subscribed to or a global address owned by
| the node
NEW:
| 1. A multicast DAO message MUST be used only to advertise
| information about the node (using the Target Option) and
| direct Link Neighbors such as learned by Neighbor Discovery
| (using the SIO).
|
| 2. The multicast DAO may be used to enable direct and indirect
| (via a common neighbor) P2P communication without needing the
| DODAG to relay the packets. The multicast DAO exposes the
| sender's addresses as Targets in RTOs and the sender's
| neighbors addresses as siblings in SIOs; this tells the
| sender's neighbors that the sender is willing to act as a
| relay between those of its neighbors that are too far apart.
4.1.5. P-DAO Request
The set of RPL Control Messages is Extended to include the P-DAO-REQ
and PDR-ACK. These two new RPL Control Messages enable a RAN to
request the establishment of a Track between itself (as the Track
ingress Node) and a Track egress. The node makes its request by
sending a new P-DAO-REQ message to the Root. The Root confirms with
a new PDR-ACK message back to the requester RAN; see Section 5.1 for
more.
4.1.6. Amending the RPI
Sending a packet within a RPL Local Instance requires the presence of
the abstract RPI described in Section 11.2 of [RPL] in the outer IPv6
header chain (see [RFC9008]). The RPI carries a Local RPLInstanceID
that, in association with either the source or the destination
address in the IPv6 header, indicates the RPL Instance that the
packet follows.
This specification Amends [RPL] to create a new flag that signals
when a packet is forwarded along a P-Route.
Projected-Route 'P': 1-bit flag. It is set to 1 in the RPI that is
added in the encapsulation when a packet is sent over a Track. It
is set to 0 when a packet is forwarded along the main DODAG (as a
Track), including when the packet follows a segment that joins
loose hops of the main DODAG. The flag is not mutable en route.
The encoding of the 'P' flag in native format is shown in Section 4.2
while the compressed format is indicated in Section 4.3.
4.1.7. Additional Flag in the RPL DODAG Configuration Option
The DODAG Configuration option is defined in Section 6.7.6 of [RPL].
Its purpose is extended to distribute configuration information
affecting the construction and maintenance of the DODAG, as well as
operational parameters for RPL on the DODAG, through the DODAG. This
option was originally designed with four bit positions reserved for
future use as Flags.
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type = 0x04 |Opt Length = 14|D| | | |A| ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +
|4 bits |
Figure 10: DODAG Configuration Option (Partial View)
This specification Amends [RPL] to define the new "Projected Routes
Support" (D) flag. The 'D' flag is encoded in bit position 0 of the
reserved Flags in the DODAG Configuration option (this is the most
significant bit). It is set to 0 in legacy implementations as
specified respectively in Sections 20.14 and 6.7.6 of [RPL].
The 'D' flag is set to 1 to indicate that this specification is
enabled in the network and that the Root will install the requested
Tracks when feasible upon receiving a P-DAO-REQ message.
Section 4.1.2 of [RFC9008] Amends [RPL] to indicate that the
definition of the Flags applies to MOP values from zero (0) to six
(6) only. For a MOP value of 7, the implementation MUST consider
that the Root accepts P-DAO-REQ messages and will install P-Routes.
The RPL DODAG Configuration option is typically placed in a DIO
message. The DIO message propagates down the DODAG to form and then
maintain its structure. The DODAG Configuration option is copied
unmodified from parents to children.
[RPL] states that:
| Nodes other than the DODAG root MUST NOT modify this information
| when propagating the DODAG Configuration option.
Therefore, a legacy parent propagates the 'D' flag as set by the
Root, and when the 'D' flag is set to 1, it is transparently flooded
to all the nodes in the DODAG.
4.2. Extending RFC 6553
"The Routing Protocol for Low-Power and Lossy Networks (RPL) Option
for Carrying RPL Information in Data-Plane Datagrams" [RFC6553]
describes the RPL Option for use among RPL routers to include the
abstract RPI described in Section 11.2 of [RPL] in data packets.
The RPL Option is commonly referred to as the RPI even though the RPI
is really the abstract information that is transported in the RPL
Option. [RFC9008] updated the Option Type from 0x63 to 0x23.
This specification Extends the RPL Option to encode the 'P' flag as
follows:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Option Type | Opt Data Len |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|O|R|F|P|0|0|0|0| RPLInstanceID | SenderRank |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| (sub-TLVs) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 11: Amended RPL Option Format
Option Type: 0x23 or 0x63; see [RFC9008].
Opt Data Len: See [RFC6553].
'O', 'R', and 'F' flags: See [RFC6553]. These flags MUST be set to
0 by the sender and MUST be ignored by the receiver if the 'P'
flag is set.
Projected-Route 'P': 1-bit flag as defined in Section 4.1.6.
RPLInstanceID: See [RFC6553]. Indicates the TrackID if the 'P' flag
is set, as discussed in Section 4.1.1.
SenderRank: See [RFC6553]. This field MUST be set to 0 by the
sender and MUST be ignored by the receiver if the 'P' flag is set.
4.3. Extending RFC 8138
The 6LoWPAN Routing Header specification [RFC8138] introduces a new
6LoWPAN [RFC6282] dispatch type for use in 6LoWPAN route-over
topologies, which initially covers the needs of RPL data packet
compression.
Section 4 of [RFC8138] presents the generic formats of the 6LoRH in
two forms: Elective, which can be ignored and skipped when the router
does not understand it, and Critical, which causes the packet to be
dropped when the router cannot process it. The 'E' flag in the 6LoRH
indicates its form. In order to skip the Elective 6LoRHs, their
format imposes a fixed expression of the size, whereas the size of a
Critical 6LoRH may be signaled in variable forms to enable additional
optimizations.
When compression as described in [RFC8138] is used, the Root of the
main DODAG that sets up the Track also constructs the compressed
Routing Header (SRH-6LoRH) on behalf of the Track ingress, which
avoids the complexities of optimizing SRH-6LoRH encoding in
constrained code. In that case, the SRH-6LoRH is signaled in the
NSM-VIO, and it is expressed in a fashion that can be placed as is in
the packet encapsulation by the Track ingress.
Section 6.3 of [RFC8138] presents the formats of the 6LoWPAN RH of
type 5 (RPI-6LoRH) that compresses the RPI for normal RPL operation.
The format of the RPI-6LoRH is not suited for P-Routes since the 'O',
'R', and 'F' flags are not used and the Rank is unknown and ignored.
This specification Extends [RFC8138] to introduce a new 6LoRH, the P-
RPI-6LoRH, that can be used in either Elective or Critical 6LoRH
form; see Tables 22 and 23, respectively. The new 6LoRH MUST be used
as a Critical 6LoRH, unless an SRH-6LoRH is present and controls the
routing decision, in which case it MAY be used in Elective form.
The P-RPI-6LoRH is designed to compress the RPI along RPL P-Routes.
Its format is as follows:
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|E| Length | 6LoRH Type | RPLInstanceID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 12: P-RPI-6LoRH Format
6LoRH Type: IANA has defined the value 8 for both the Elective and
Critical forms.
Elective 'E': See [RFC8138]. The 'E' flag is set to 1 to indicate
an Elective 6LoRH, meaning that it can be ignored when forwarding.
RPLInstanceID : In the context of this specification, the
RPLInstanceID field signals the TrackID; see Sections 3.4 and 6.3.
Section 6.8 details how a Track ingress leverages the P-RPI-6LoRH
header as part of the encapsulation of a packet to place it into a
Track.