Summary

  • RFC 9912 defines a recovery graph as the finite set of feasible DetNet paths available to a flow. It is a potential graph, not the route an individual packet actually experienced.
  • A local Point of Local Repair chooses paths for one packet or a small burst on a faster clock than controller routing. In loose or distributed operation, no single node may be able to report the complete current path.

The illustrative factory controller displayed three protection routes between one ingress and one egress. Its graph version was current, resources were reserved and the service objective was green. Then a moving obstruction disturbed one radio link for less time than a trip to the controller and back.

The next packet did not wait. A local relay changed its forwarding choice. A downstream relay, seeing different conditions, revised that choice again. The packet arrived. Yet the controller screenshot could not establish which complete path the packet had taken, which local observation prompted each switch, or whether two apparently separate radio links shared the same interference domain. This is not a reported deployment. It is the evidence problem exposed by RFC 9912.

Published in April 2026, RFC 9912 is an Informational document in the IETF stream. The RFC information record says it represents IETF consensus while remaining outside the Internet Standards Track. It extends the Deterministic Networking architecture in RFC 8655 to combinations of wired and wireless segments, where interference, movement and shared spectrum can change delivery conditions abruptly.

Its central object is easy to misread. A recovery graph coalesces all feasible DetNet paths available to a flow, together with usage metadata. It can fork, rejoin and contain a main and one or more protection paths. But it represents potential paths, not an actual path. One assigned packet experiences one feasible path according to the selection made by a Point of Local Repair at traversal time. The next packet may experience another.

That distinction divides authority across three clocks. The Controller Plane computes and maintains routes and installs the recovery graph. RFC 9938 describes the wider DetNet Controller Plane and its role in flow instantiation, resource information and monitoring. RFC 9912 assumes that path establishment is slow relative to local forwarding. In a wireless mesh, even reaching a controller may cost too much time and radio capacity to answer a transient event.

The RAW operational loop therefore runs between routing and forwarding. Controller calculations can use averaged statistics over minutes or hours. A local PLR consumes current observations and changes path use in microseconds to milliseconds, for one packet or a short run. Ordinary lookup and transmission then execute the choice. The fast actor is not free to invent a new network: its authority remains inside the finite graph and resource envelope already made available.

RFC 9912 describes that loop as Observe, Orient, Decide and Act. RAW OAM observes link state, some or all hops and end-to-end delivery. Orientation can combine current measurements with history, predictions and controller-provided models. A PLR decides what future packet or packets should use. PREOF—Packet Replication, Elimination and Ordering Functions—and lower-layer mechanisms act on that decision.

Observation is not one uniform fact. The DetNet OAM framework in RFC 9551 distinguishes in-band measurements that receive the monitored flow's link, QoS and PREOF treatment from out-of-band tests that may not. RFC 7799 separates active, passive and hybrid measurement methods. RFC 9378 explains in-situ OAM carried with live traffic. Each channel answers a different question. An active probe may inspect an unused alternative but consume scarce capacity; live packet telemetry can record actual treatment but only where the deployment captures it.

The strict-versus-loose graph boundary makes the evidence gap visible. In a strict graph, RAW observes and controls the relevant forwarding behavior end to end. A loose graph can cross an opaque non-RAW subnetwork. RFC 9912's radio-access example observes the first-hop access links and the end-to-end result while the tunnel underlay remains hidden. A loss can occur inside the opaque segment even when the local model attributes it to the access choice. An end-to-end delivery ratio is therefore valid outcome evidence and incomplete cause evidence at the same time.

Distributed decision makes reconstruction harder still. RFC 9912 explicitly allows feasible paths to be decided after a change and the PLR decision to be distributed. The combination can be large enough that no node is capable of reporting the current end-to-end DetNet path. This is not a defect hidden between the lines. It is an architectural warning against treating one controller record as the authoritative history of every packet.

The configured objective is another separate layer. A recovery graph may carry objectives for Packet Delivery Ratio, maximum packets lost in a row, bounded latency, jitter, ordering, received-copy count or copy-delay spread. Those are targets. An achieved SLO requires measurements with packet or interval scope, timestamps, observation boundaries and a stated aggregation method. The RAW use cases in RFC 9450 explain why these services matter, while RFC 9913's technology survey describes enabling radio capabilities. Neither proves that a named system met a bound.

Redundancy itself is a governed resource. RAW can use spatial, temporal, coding and frequency diversity, retransmission, FEC and PREOF. The recovery vocabulary inherited from RFC 4427 helps separate protection and restoration concepts. Flooding every alternative, however, consumes spectrum and battery and can alter latency or ordering. RAW's control problem is to apply enough diversity without turning assurance into permanent overuse.

Nor does a branching diagram prove independent failure domains. Two paths may share spectrum, a power source, location, hardware or an opaque underlay. RFC 9913 notes the value of non-shared-risk links, but independence must be evidenced, not inferred from line colour. The same caution applies to security: RFC 9912 says diversity can help route around interference, yet an attacker can disable cheap access and force paid connectivity, extra retransmission, battery drain or congestion elsewhere.

The decision also changes its own evidence. Moving traffic affects the metrics used to justify the next move. RFC 9912 warns that this feedback can produce oscillation and must be avoided or damped. A sequence of locally correct switches can therefore create a globally unstable pattern unless the receipts preserve graph version, metric window, decision identity and timing.

The RFC Editor's RFC 9912 errata search showed no matching errata at the evidence freeze. That is document metadata, not proof that a radio, controller, PLR, OAM design or service works.

Heng Lu's Running-Code Primacy puts the packet after the diagram: operational truth comes from what forwarding code did and what evidence survived. Minimum Initial Specification supports a narrow shared envelope with explicit local choice. Reality Layers prevents feasible topology, selected path, observed packet, inferred cause and accepted service from collapsing into one green state.

The useful receipt is consequently layered. Preserve the graph version and candidate paths; the strict or loose observation boundary; controller statistics and their window; PLR identity, trigger and decision time; packet or burst scope; old and new tags; PREOF and lower-layer actions; in-situ or probe evidence; and the end-to-end result. A controller can prove what choices it made possible. Only packet- and decision-level evidence can begin to show which choice became real.

Sources