Summary

  • A positive PDR-ACK under RFC 9914 means the Root says it built the requested Track and commits to its negotiated lifetime. It is not evidence that a packet used the Track or that a service objective was achieved.
  • A defensible operational claim joins the request and sequence, mode-specific installation evidence, segment and Track lifetimes, data-plane Track identity, observed packet behavior and the application result—without asking any acknowledgment to prove the next layer.

The control system returned success. The ingress had requested a Track, the Root had accepted the request, and the reply carried the expected sequence. On a dashboard, that could easily become “deterministic path active.” Yet no packet capture had shown the Track identity, no counter had advanced along the intended path and no receiver had recorded a delivery. The acknowledgment was real. The service claim was premature.

RFC 9914, published in April 2026 as a Proposed Standard, specifies Root-Initiated Routing State in RPL. Its RFC Editor record identifies its status and its updates to RFC 6550, RFC 6553 and RFC 8138. The mechanism lets a central RPL Root project a Track across a low-power and lossy network. It does not report a named deployment, vendor implementation or measured service outcome.

The opening transaction is precise. A Track ingress may send a P-DAO-REQ to the Root, carrying a TrackID, the ingress and egress endpoints, a requested lifetime and a PDRSequence value. The Root uses that sequence to correlate its PDR-ACK. A positive acknowledgment says the Track was built and commits the Root to maintain it for the negotiated lifetime. A negative response says the request was rejected. Neither response contains a packet observation.

What “built” means depends on RPL mode. In Non-Storing Mode, the Root retains source-route or tunnel state that can steer traffic toward the Track egress. In Storing Mode, the Root sends a Projected DAO, or P-DAO, to the egress; the information propagates in reverse toward the ingress, and each participating router installs its portion. A positive P-DAO-ACK returning from the ingress confirms that installation exchange. If the P-DAO-ACK does not arrive, the Root may retry with the same TrackID or tear the Track down. The two modes therefore expose different custody points.

A generic green “route installed” field erases information needed for diagnosis.

RFC 9914 also makes refusal legible. The Vector Information Option can report an error, and status values distinguish conditions such as Out of Resources, Predecessor Unreachable and Unreachable Target. These are bounded control-plane statements: a router could not accept a segment under the stated condition. They are more useful than a single failure bit, but they do not identify an application outage or prove the physical cause of lost radio reachability.

Time is not one counter. Vector state carries a Segment Sequence and Segment Lifetime. An older sequence is ignored; repeating the same tuple is a retry that must not rewrite state; a zero lifetime removes the segment. Segment lifetimes can expire and be refreshed asynchronously, independently of the Track lifetime promised to the requester. A dashboard that displays only the outer Track expiry can therefore show a commitment whose internal segments are changing on different clocks.

The design intentionally hides some maintenance from the requester. Changes deeper down the Track can be transparent to the ingress. If the Root can no longer maintain the service, it tears down the complete Track and may send an asynchronous negative PDR-ACK with a zero lifetime. Silence before that event is not proof that every hop remained unchanged. It means the protocol has not delivered that particular failure signal.

Forwarding creates the next evidence boundary. A Track route has higher precedence than the main RPL DODAG route. Once a packet is on a Track, it must not fall back into the main DODAG; if the next Track neighbor is unreachable, the packet is dropped. The rule protects the Track's intended properties from an unexamined fallback, but it also means “ordinary RPL connectivity remains” cannot be used to infer Track delivery.

Data-plane identity can be observed. The TrackID and DODAGID are carried with RPL Packet Information, source routing or encapsulation according to the inherited rules in RFC 9008 and the RPI definition in RFC 6553. That evidence can establish that a captured packet was associated with a particular Track at a particular point. It still does not show what occurred at an uncaptured hop or whether the receiving application accepted the payload.

Reprojection is not semantically free. When a segment is changed, packets already in flight and packets entering after the change can follow different paths. Different delay can create jitter or reordering even when every control message is valid. The deterministic-networking context in RFC 8655 describes bounded service objectives; the RAW architecture in RFC 9912 discusses protection, replication, elimination and rapid adaptation. Those architectures explain why Tracks matter. They do not turn a route acknowledgment into latency, loss or independence measurements.

Security has the same layered shape. RFC 9914 warns that a rogue node able to inject P-DAO state can cause churn or exhaust storage on routers. It relies on link-layer security and the broader RPL threat analysis in RFC 7416. The current codepoints and statuses appear in the IANA RPL registries. Registration proves coordination of protocol values, not that a particular network enabled the mechanism securely or resisted an attack.

A useful evidence record therefore preserves the P-DAO-REQ and PDRSequence; the Root's decision and negotiated Track lifetime; Storing or Non-Storing mode; P-DAO/P-DAO-ACK state where applicable; per-node rejection codes; Segment Sequence and lifetime; TrackID and DODAGID observed on packets; ingress, egress and hop telemetry; drops during reprojection; and the application-level result. This is an editorial synthesis of the protocol's observable boundaries, not a mandatory schema defined by RFC 9914.

Heng Lu's Minimum Initial Specification supports a narrow common mechanism while leaving later operating choices locally accountable. Running-Code Primacy requires the installed and observed system to carry more weight than a symbolic declaration. Reality Layers prevents request, acknowledgment, routing state, packet and service from collapsing into one status. These are disclosed editorial principles, not additions to IETF requirements.

RFC 9914 earns trust by limiting what each message can say. The request asks for a Track. The acknowledgments report control-plane decisions and installation progress. Packet evidence shows use. Receiver and service telemetry show outcome. Automation becomes stronger when it preserves those boundaries instead of compressing them into “active.”

Sources