Root-Initiated Routing State in the Routing Protocol for Low-Power and Lossy Networks (RPL)
updates
Extracted elements (28)
RPL is anisotropic (polar), optimizing only MP2P (toward Root) and P2MP (from Root) paths; all P2P traffic must follow the same DODAG, producing routing stretch. DAO Projection was introduced to complement RPL with centralized PCE-computed paths that bypass the Root for select P2P flows, reducing latency, packet size, fragmentation risk, and Root bottleneck load without changing the base RPL operation.
Storing Mode segments are used to reduce SRH overhead in deep networks: the Root can elide the corresponding stretch of hops from the strict Source Routing Header, making it loose. Non-Storing Mode protection paths require encapsulation to carry an SRH at the Track ingress but avoid per-hop state in intermediate nodes, enabling a hybrid that balances memory constraints against packet-size constraints.
Tracks are modeled as separate Local RPL Instances with their own RIBs (rather than extending the main Instance) so that each Track defines an independent routing topology. This reuses the existing RPL Instance machinery for RIB isolation and loop avoidance while allowing the Track to serve as a transparent underlay with higher RIB precedence than the main Instance.
P-Routes can be deployed in a hybrid mode where the P-Route's Mode of Operation (Storing or Non-Storing) differs from that of the main RPL Instance. The forwarding method priority order and the DODAG-of-Instances ordering must be respected to ensure loop-free operation in such hybrid configurations.
A packet that was forwarded along a Track MUST NOT subsequently be forwarded along the default route of the main Instance. This prevents routing loops in the multi-topology domain where Track Instances underlay the main Instance.
Supporting the DODAG-of-Instances ordering for nested Tracks is OPTIONAL, but validating the ordering between a Track Instance and the main Instance is REQUIRED. When the DODAG of underlay Instances is not provided, all Track Instances are treated by default as children of the main Instance.
The main RPL Instance MUST be operated in RPL Non-Storing Mode of Operation (MOP) to sustain Root-initiated route projection, since Non-Storing Mode gives the Root a complete image of the DODAG topology needed for PCE-based path computation.
The RPL Packet Information (RPI) option is amended so that the RPLInstanceID field in packets forwarded along a Track carries the Local RPLInstanceID of the Track, allowing intermediate nodes to apply the correct Track RIB for forwarding decisions.
When installing a Track using Storing Mode P-DAOs, the Root MUST signal the egress segment first (sending P-DAO to the egress node and awaiting acknowledgment) before signaling upstream segments toward the ingress. This ordering ensures that routes are in place before traffic is steered onto them.
A Complex Track is formed by combining multiple protection paths sharing the same TrackID, potentially interleaved at common nodes. Each individual protection path and segment carries its own SegmentID within the TrackID namespace for independent lifecycle management. Nodes at interleaving points may have multiple next hops in the Track RIB and select one that can reach the next loose hop.
A Non-Storing Mode protection path is a loose source-routed end-to-end forward serial path installed by the Root using an NSM-VIO in a single P-DAO sent directly to the Track ingress node. Packets following the protection path are encapsulated with an SRH listing the intermediate hops. Each NSM-VIO for the same TrackID but a different SegmentID signals a distinct protection path.
A Projected DAO (P-DAO) is a DAO message used by the RPL Root (acting on behalf of a PCE) to install a Projected Route (P-Route) in the RPL domain. It extends the existing DAO base object and may carry either a Storing Mode or Non-Storing Mode Via Information Option, plus one or more RPL Target Options identifying reachable destinations.
A Storing Mode P-Route (segment) is a strict hop-by-hop sequence installed by passing a P-DAO along the reverse data path. Each intermediate node installs an entry in the Track's RIB. Segments reduce SRH size by enabling loose source routing over the main DODAG and are the building blocks joining loose hops of protection paths in a Complex Track.
A Track is a DODAG-shaped recovery graph composed of one or more protection paths and strict segments, oriented from a Track ingress to one or more Track egress nodes. It is associated with its own Local RPL Instance and its own Routing Information Base (RIB), which takes precedence over the main Instance RIB. The Track ingress IP address serves as the DODAGID for the associated Local Instance.
The P-DAO Request (P-DAO-REQ) is a new RPL control message through which a node requests the Root to install a P-Route. It allows RPL-Aware Nodes to explicitly solicit Track establishment rather than relying solely on Root-initiated projection.
The Projected DAO Acknowledgment (P-DAO-ACK) is used to confirm that a P-Route has been successfully installed or to signal failure. The Root waits for acknowledgment from the egress node before sending upstream P-DAOs for the same Track segment, ensuring ordered installation.
The Projected DAO Request Acknowledgment (PDR-ACK) is a new RPL control message used by the Root to respond to a P-DAO-REQ. It carries acceptance or rejection status values indicating whether the requested P-Route will be or was installed.
The Sibling Information Option (SIO) is a new RPL Control Message Option that allows RPL nodes to advertise sibling relationships (lateral links not used in the main DODAG) to the Root. This enriches the Root's topological awareness, enabling the PCE to compute additional paths that traverse sibling links.
The Via Information Option (VIO) is a new RPL Control Message Option introduced to signal a sequence of hops forming a segment or protection path inside a P-DAO. It appears in two variants: SM-VIO (Storing Mode, strict hop sequence) and NSM-VIO (Non-Storing Mode, loose source-routed sequence). The via list in the VIO is encoded as an SRH-6LoRH starting with the first hop after the ingress and ending at the egress.
IANA has allocated a new flag bit in the RPL DODAG Configuration Option (RFC 6550 Section 6.7.6) to signal that the RPL domain supports DAO Projection as defined by this document.
IANA has allocated new 6LoWPAN Routing Header type values: one Elective type and one Critical type for use with the RPL extensions defined in this document (Section 11.2 and 11.3), updating the 6LoWPAN Routing Header Type registry.
IANA has created new registries for: RPL Option Flags (Section 11.4), RPL Control Codes for P-DAO-REQ and PDR-ACK (Section 11.5), RPL Control Message Options for VIO and SIO (Section 11.6), P-DAO Request Flags (Section 11.7), PDR-ACK Flags (Section 11.8), PDR-ACK Acceptance Status Values (Section 11.9), and PDR-ACK Rejection Status Values (Section 11.10).
IANA has created new registries for Via Information Option Flags (Section 11.11), Sibling Information Option Flags (Section 11.12), DAO Flags (Section 11.13), DAO Acknowledgment Flags (Section 11.14), and RPL Rejection Status Values (Section 11.16). An ICMPv6 error code for RPL rejection is also allocated (Section 11.15).
Because P-DAO messages can install routes that bypass the normal DODAG structure, rogue P-DAOs could create forwarding loops or traffic-engineering attacks. The RPI-based TrackID tagging and the strict forwarding-method ordering provide loop protection, but they rely on the integrity of the installed state; unauthorized P-DAO injection must be prevented at the RPL security layer.
The Root and PCE have the authority to install arbitrary routing state in RPL nodes via P-DAO messages; a compromised Root or PCE can redirect or blackhole traffic across the domain. Implementations should secure the control plane between the PCE and Root (out of scope), and between the Root and RPL nodes using the security mechanisms defined in RFC 6550 (RPL).
Forwarding along a Track follows a strict priority order among four methods: (1) direct next hop, (2) indirect neighbor via a common neighbor, (3) forwarding along a segment, and (4) forwarding along a nested Track. A higher-order method may use lower-order ones but never a higher-order one; e.g., a segment may use direct or indirect neighbors but not another Track. This total order prevents forwarding loops across multiple topologies.
A Local RPLInstanceID is encoded in an 8-bit field where bit 0 (most significant) is set to 1, bit 1 is set to 0 for TrackIDs, and the remaining 6 bits carry the Local Instance ID (0–63). The resulting integer value falls in the range 128–191. The tuple (DODAGID, TrackID) forms a globally unique Track identifier.
When a packet is placed on a Track, it is IP-in-IP encapsulated. The outer IPv6 source address is set to the Track ingress IP address, and the RPL Packet Information (RPI) Hop-by-Hop option in the outer header carries the Local RPLInstanceID identifying the Track. The encapsulated (inner) packet carries no RPI.