5. New RPL Control Messages and Options
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
5. New RPL Control Messages and Options
5.1. New P-DAO Request Control Message
The P-DAO-REQ message is sent by a node in the main DODAG to the
Root. It is a request to establish or refresh a Track where the node
sending the P-DAO-REQ is the Track ingress, and it signals whether or
not an acknowledgment called PDR-ACK is requested. A positive PDR-
ACK indicates that the Track was built and that the Root commits to
maintaining the Track for the negotiated lifetime.
The main Root MAY indicate to the Track ingress that the Track was
terminated before its time; to do so, it MUST use an asynchronous
PDR-ACK with a negative status. A status of "Transient Failure" (see
Section 11.10) is an indication that the P-DAO-REQ may be retried
after a reasonable time that depends on the deployment. Other
negative status values indicate a permanent error; the attempt must
be abandoned until a corrective action is taken at the application
layer or through network management.
The Track ingress to be of the requested Track is indicated in the
source IPv6 address of the P-DAO-REQ, and the TrackID is indicated in
the message itself. At least one RPL Target Option MUST be present
in the message. If more than one RPL Target Option is present, the
Root will provide a Track that reaches the first listed Target and a
subset of the other Targets; the details of the subset selection are
out of scope. The RTO signals the Track egress (see more in
Section 6.2).
The RPL Control Code for the P-DAO-REQ is 0x09. The format of the P-
DAO-REQ Base Object is 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| TrackID |K|R| Flags | ReqLifetime | PDRSequence |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Option(s)...
+-+-+-+-+-+-+-+-+
Figure 13: New P-DAO Request Format
TrackID: 8-bit field. In the context of this specification, the
TrackID field signals the RPLInstanceID of the DODAG formed by the
Track; see Sections 3.4 and 6.3. To allocate a new Track, the
ingress Node must provide a value that is not in use at this time.
K: The 'K' flag is set to indicate that the recipient is expected to
send a PDR-ACK back.
R: The 'R' flag is set to request a Complex Track for redundancy.
Flags: Reserved. The Flags field MUST be initialized to zero by the
sender and MUST be ignored by the receiver.
ReqLifetime: 8-bit unsigned integer. The requested lifetime for the
Track expressed in Lifetime Units (obtained from the DODAG
Configuration option). The value of 255 (0xFF) represents
infinity (never time out).
A P-DAO-REQ with a fresher PDRSequence refreshes the lifetime, and
a ReqLifetime of 0 indicates that the Track MUST be destroyed,
e.g., when the application that requested the Track terminates.
PDRSequence: 8-bit wrapping sequence number, obeying the operation
in Section 7.2 of [RPL]. The PDRSequence is used to correlate a
PDR-ACK message with the P-DAO-REQ message that triggered it. It
is incremented at each P-DAO-REQ message and echoed in the PDR-ACK
by the Root.
5.2. New PDR-ACK Control Message
The new PDR-ACK is sent as a response to a P-DAO-REQ message with the
'K' flag set. The RPL Control Code for the PDR-ACK is 0x0A. Its
format is 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| TrackID | Flags | Track Lifetime| PDRSequence |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| PDR-ACK Status| Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Option(s)...
+-+-+-+-+-+-+-+
Figure 14: New PDR-ACK Control Message Format
TrackID: Set to the TrackID indicated in the TrackID field of the P-
DAO-REQ messages that this replies to.
Flags: Reserved. The Flags field MUST be initialized to zero by the
sender and MUST be ignored by the receiver.
Track Lifetime: Indicates the remaining lifetime for the Track,
expressed in Lifetime Units. The value of 255 (0xFF) represents
infinity. The value of zero (0x00) indicates that the Track was
destroyed or not created.
PDRSequence: 8-bit wrapping sequence number. It is incremented at
each P-DAO-REQ message and echoed in the PDR-ACK.
PDR-ACK Status: 8-bit field indicating the completion. The PDR-ACK
Status is substructured as indicated in Figure 15:
0 1 2 3 4 5 6 7
+-+-+-+-+-+-+-+-+
|E|R| Value |
+-+-+-+-+-+-+-+-+
Figure 15: PDR-ACK Status Format
E: 1-bit flag. Set to indicate a rejection. When not set, a
Value field that is set to 0 indicates Success/Unqualified
Acceptance, and other values indicate "not an outright
rejection".
R: 1-bit flag. Reserved; MUST be set to 0 by the sender and MUST
be ignored by the receiver.
Status Value: 6-bit unsigned integer. Values depend on the
setting of the 'E' flag; see Tables 28 and 29.
Reserved: The Reserved field MUST be initialized to zero by the
sender and MUST be ignored by the receiver.
5.3. Via Information Options
A VIO signals the ordered list of IPv6 Via Addresses that constitutes
the hops of either a protection path (using Non-Storing Mode) or a
segment (using Storing Mode) of a Track. A Storing Mode P-DAO
contains one SM-VIO whereas a Non-Storing Mode P-DAO contains one
NSM-VIO.
The duration of the validity of a VIO is indicated in a Segment
Lifetime field. A P-DAO message that contains a VIO with a Segment
Lifetime of 0 is referred as a No-Path P-DAO.
The VIO contains one or more SRH-6LoRH headers, each formed of an
SRH-6LoRH head and a collection of compressed Via Addresses, except
in the case of a Non-Storing Mode No-Path P-DAO where the SRH-6LoRH
header is not present.
In the case of an SM-VIO, or if [RFC8138] is not used in the data
packets, then the Root MUST use only one SRH-6LoRH per Via
Information Option, and the compression is the same for all the
addresses, as shown in Figure 16, for simplicity.
In case of an NSM-VIO, and if [RFC8138] is in use in the main DODAG,
the Root SHOULD optimize the size of the NSM-VIO if using different
SRH-6LoRH Types would make the VIO globally shorter; this means that
more than one SRH-6LoRH may be present.
The format of the VIO is 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 | Option Length | Flags | P-RouteID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Seg. Sequence | Seg. Lifetime | SRH-6LoRH head |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
. Via Address 1 (compressed by RFC 8138) .
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
. .... .
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
. Via Address n (compressed by RFC 8138) .
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
. Additional SRH-6LoRH header(s) .
| |
. .... .
Figure 16: VIO Format
Option Type: 0x0F for SM-VIO and 0x10 for NSM-VIO (see Table 26).
Option Length: 8-bit unsigned integer, representing the length in
octets of the option, not including the Option Type and Length
fields (see Section 6.7.1 of [RPL]); the Option Length is
variable, depending on the number of Via Addresses and the
compression applied.
Flags: 8-bit field. No flag is defined in this specification. The
field MUST be set to 0 by the sender and MUST be ignored by the
receiver.
P-RouteID: 8-bit field that identifies a component of a Track or the
main DODAG as indicated by the TrackID field. The value of 0 is
used to signal a path, i.e., made of a single segment/protection
path. In an SM-VIO, the P-RouteID indicates a SegmentID. In an
NSM-VIO, it indicates the ID of a protection path that is added
(or updated) to the overall topology of the Track.
Segment Sequence: 8-bit unsigned integer. The Segment Sequence
obeys the operation in Section 7.2 of [RPL], and the initial value
is 255.
When the Root of the DODAG needs to refresh or update a segment in
a Track, it increments the Segment Sequence individually for that
segment.
The segment information indicated in the VIO deprecates any state
for the segment indicated by the P-RouteID within the indicated
Track and provides the new information about the segment.
A VIO with a Segment Sequence that is not as fresh as the current
one is ignored.
A VIO for a given DODAGID with the same (TrackID, P-RouteID,
Segment Sequence) indicates a retry; it MUST NOT change the
segment and MUST be propagated or answered as the first copy.
Segment Lifetime: 8-bit unsigned integer. The length of time in
Lifetime Units (obtained from the Configuration option) that the
segment is usable.
The period starts when a new Segment Sequence is seen. The value
of 255 (0xFF) represents infinity. The value of zero (0x00)
indicates a loss of reachability.
SRH-6LoRH head: The first 2 bytes of the (first) SRH-6LoRH as shown
in Figure 6 of [RFC8138]. As an example, a 6LoRH of type 4 means
that the Via Addresses are provided in full with no compression.
Via Address: An IPv6 ULA or GUA of a node along the segment. The
VIO contains one or more IPv6 Via Addresses listed in the datapath
order from ingress to egress. The list is expressed in a
compressed form as signaled by the preceding SRH-6LoRH header.
In a Storing Mode P-DAO that updates or removes a section of an
already existing segment, the list in the SM-VIO may represent
only the section of the segment that is being updated; at the
extreme, the SM-VIO updates only one node, in which case it
contains only one IPv6 address. In all other cases, the list in
the VIO MUST be complete.
In the case of an SM-VIO, the list indicates a sequential (strict)
path through direct neighbors; the complete list starts at the
ingress and ends at the egress, and the nodes listed in the VIO,
including the egress, MAY be considered as implicit Targets.
In the case of an NSM-VIO, the complete list can be loose and
excludes the ingress node, starting at the first loose hop and
ending at a Track egress; the Track egress MUST be considered as
an implicit Target, so it MUST NOT be signaled in a RPL Target
Option.
5.4. Sibling Information Option
The Sibling Information Option (SIO) provides information about
siblings that could be used by the Root to form P-Routes. One or
more SIOs may be placed in the DAO messages that are sent to the Root
in Non-Storing Mode.
To advertise a neighbor node, the router MUST have an active Address
Registration from that sibling per [RFC8505] for an address (ULA or
GUA) that serves as an identifier for the node. If this router also
registers an address to that sibling, and the link has similar
properties in both directions, only the router with the lowest
Interface ID in its registered address needs to report the SIO, with
the 'B' flag set, and the Root will assume symmetry.
The SIO carries a flag (B) that is set when similar performance can
be expected in both directions; this flag indicates to the routing
that the information provided for one direction is valid for both.
If the SIO is effectively received from both sides, then the 'B' flag
MUST be ignored. The policy that describes the performance criteria
and how they are asserted is out of scope. In the absence of an
external protocol to assert the link quality, the flag SHOULD NOT be
set.
The format of the SIO is 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 | Option Length |S|B|Flags|Comp.| Opaque |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Step in Rank | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ +
. .
. Sibling DODAGID (if the D flag is not set) .
. .
+ +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ +
. .
. Sibling Address .
. .
+ +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 17: Sibling Information Option Format
Option Type: 0x11 for SIO (see Table 26).
Option Length: 8-bit unsigned integer, representing the length in
octets of the option, not including the Option Type and Length
fields (see Section 6.7.1 of [RPL]).
Reserved for Flags: MUST be set to 0 by the sender and MUST be
ignored by the receiver.
B: 1-bit flag that is set to indicate that the connectivity to the
sibling is bidirectional and roughly symmetrical. In that case,
only one of the siblings needs to report the SIO for the hop. If
'B' is not set, then the SIO only indicates connectivity from the
sibling to this node, and it does not provide information on the
hop from this node to the sibling.
S: 1-bit flag that is set to indicate that the sibling belongs to
the same DODAG. When not set, the Sibling DODAGID is indicated.
Flags: Reserved. The Flags field MUST be initialized to zero by the
sender and MUST be ignored by the receiver.
Comp.: Compression Type; a 3-bit unsigned integer. This is the SRH-
6LoRH Type as defined in Figure 7 in Section 5.1 of [RFC8138] that
corresponds to the compression used for the Sibling Address and
its DODAGID if present. The Compression reference is the Root of
the main DODAG.
Opaque: MAY be used to carry information that the node and the Root
understand, e.g., a particular representation of the link
properties such as a proprietary Link Quality Information for
packets received from the sibling. In some scenarios such as
Industrial Alliances that use RPL for a particular use/
environment, this field MAY be redefined to fit the needs of the
case.
Step in Rank: 16-bit unsigned integer. This is the Step in Rank
[RPL] as computed by the Objective Function between this node and
the sibling, which reflects the abstract Rank increment that would
be computed by the Objective Function if the sibling was the
preferred parent.
Reserved: The Reserved field MUST be initialized to zero by the
sender and MUST be ignored by the receiver
Sibling DODAGID: 2 to 16 bytes. The DODAGID of the sibling in a
compressed form [RFC8138] as indicated by the Compression Type
field. This field is present if and only if the 'D' flag is not
set.
Sibling Address: 2 to 16 bytes. An IPv6 address of the sibling with
a scope that MUST make it reachable from the Root, e.g., it cannot
be a Link Local Address. The IPv6 address is encoded in the
compressed form [RFC8138] indicated by the Compression Type field.
An SIO MAY be immediately followed by a DAG Metric Container. In
that case, the DAG Metric Container provides additional metrics for
the hop from the Sibling to this node.