DetNet path optimisation begins with authority

Summary

RFC 9938 describes a DetNet Controller Plane that can receive flow requests, calculate feasible paths, choose an optimal one, reserve resources and install per-hop behaviour. “Optimal” is never self-defining: it depends on an authorised ordering of latency, loss, jitter, bandwidth, protection, shared-risk, domain and coexistence constraints.
The missing evidence is a constraint-ownership receipt that binds a request and its versioned objective to the actor allowed to rank trade-offs, the resources each domain committed, the computation snapshot, monitoring triggers, exception expiry and teardown owner—without publishing sensitive topology, schedules or flow purpose.

The decision happens before the solver starts

Imagine a controller returning two paths. Both meet the requested maximum delay. One uses less bandwidth but shares a risk group with an existing protected flow. The other consumes more buffer and reserves a second disjoint route, yet leaves less capacity for ordinary traffic. The controller can compare metrics, reject infeasible candidates and install the selected behaviour with impressive precision.

It still cannot discover, from the metrics alone, which sacrifice it was authorised to make.

That is the hidden step in the phrase “optimal path”. Optimisation looks like a mathematical act because it ends with a calculation. Before the calculation, however, someone has to name the objective, distinguish hard limits from preferences, assign weights, decide whose capacity may be spent and say what happens when no candidate satisfies everything. A solver can execute those choices. It cannot confer legitimacy on them.

RFC 9938 makes this boundary unusually visible. The document describes a framework for the Deterministic Networking Controller Plane. It compiles requirements and sketches distributed, centralised and hybrid architectures that could support later protocol solutions. It is Informational, not a Standards Track protocol specification, and it explicitly leaves solution details to future work.

Within that scope, the controller plane has consequential work to do. It may create, modify and delete flows; determine explicit paths; reserve bandwidth, buffers and other node resources; place queuing disciplines; configure replication, elimination and ordering; distribute labels; learn topology and capabilities; and monitor whether the resulting service is meeting its objectives. A request may come from an application, static provisioning, an SDN controller or a distributed signalling process.

These are not clerical acts. They convert a requested service into exclusive or scarce claims on a shared network. The architecture can describe how that conversion happens without deciding every institution’s authority model. The governance mistake would be to treat the architecture’s ability to carry a request as proof that the requester was entitled to define the trade-off.

A service request is not yet an objective function

The centralised example in RFC 9938 is clean. A controller collects topology information and DetNet capabilities, receives a flow-establishment request, calculates one or more valid paths, chooses the optimal path and configures the devices along it. Each verb is operationally intelligible. The gap lies between “request” and “optimal”.

An application can state that it needs a maximum end-to-end delay, a loss bound, limited delay variation and a particular bandwidth. RFC 9016 provides a way to describe flow and service information. RFC 9938 notes that the traffic specification is a worst case rather than an average. These inputs help a controller test feasibility. They do not say whether every requested value is contractually binding, an engineering preference, a diagnostic aspiration or an accidentally stale default.

That distinction changes the path. A hard latency ceiling may exclude a longer but safer route. A soft latency preference may yield to better fault isolation. A protection requirement may cause packet replication across multiple paths, consuming resources that would otherwise serve another flow. A zero-misordering constraint can require extra buffering or ordering functions. A requested validity interval may turn a permanent reservation into a temporary one.

Even a correct model can carry the wrong mandate. YANG can encode the intended state. NETCONF or PCE-based control can install it. BGP-LS can supply topology and capability information. None of those protocols can infer whether the person or system that chose a value was allowed to bind the network to it.

The question is not whether an API caller is authenticated in the narrow security sense. Authentication can show that a credential belongs to a recognised principal. Authorisation can show that a principal may invoke a class of operation. The harder question is whether the particular operation stays within a decision mandate: this service, these constraints, this resource ceiling, these domains, this interval and this fallback rule.

Without that link, “request accepted” can become a substitute for “trade-off approved”.

Reserved capacity makes preference distributive

Ordinary route selection often invites a simplified story: find the lowest cost and forward. DetNet’s promise is more demanding. Its forwarding layer can reserve bandwidth and buffers, use explicit paths, configure queues and add service protection. RFC 8938 says a “best” path can be optimised for highest bandwidth, lowest jitter or a combination of metrics, and it need not be the shortest.

Once the controller reserves resources, path preference becomes distributive. The selected flow gains a protected opportunity that another flow cannot assume. Replication may consume capacity on several routes. Buffer allocation can affect what remains available to other traffic. Holding an obsolete reservation after teardown should have occurred can prevent a new flow from being admitted.

RFC 8655 acknowledges the shared environment. A DetNet domain may dedicate a high proportion of bandwidth to deterministic flows, but scheduling should still leave sufficient opportunities for non-DetNet traffic and starvation must be avoided. Unused DetNet opportunities may be available to ordinary packets, while not necessarily becoming capacity that another DetNet flow can claim. The boundaries are technically subtle and institutionally important.

This makes “optimal” a statement about more than the selected application. It also says how the network values other deterministic services and the non-DetNet population. A path that is ideal for one requester can be a poor institutional choice if it consumes a protected corridor reserved for a higher-priority purpose, duplicates traffic without an approved need, or leaves an ordinary class below its accepted service floor.

The controller needs constraints. The operator needs evidence of who owned them.

Three architectures do not remove the same question

RFC 9938 presents distributed, fully centralised and hybrid controller planes. It does not insist that one is always superior. Each places computation, signalling and configuration differently.

In a distributed arrangement, ingress and network nodes exchange information and signalling can establish the path and reservation. There may be no single machine that sees the whole decision. That does not eliminate accountability; it makes the mandate compositional. The initiating request, each node’s local admission decision and the resulting end-to-end state must still be connected.

In a fully centralised arrangement, one controller can collect topology, compute candidates and configure nodes. The audit trail can look simpler because the sequence passes through one logical point. Yet concentration creates its own ambiguity. A controller that is technically allowed to configure every node may serve several application owners and service classes. Its broad credential is not evidence that every objective it receives has equal priority or unlimited resource authority.

In a hybrid arrangement, a controller can calculate and distribute path information while RSVP-TE or another protocol performs signalling and reservation. Now a later reviewer may see a valid computation and a valid signalling exchange but still be unable to tell whether both were based on the same constraint version. A topology update between calculation and admission can make an earlier candidate set stale. A local node may reject or alter a reservation for reasons the central record does not preserve.

Architecture moves the points at which evidence is produced. It does not make the authority question disappear.

Crossing a domain multiplies commitments

The multi-domain section of RFC 9938 is brief and revealing. Several Controller Plane Functions may have to collaborate to translate a request from the Flow Management Entity into per-flow, per-hop behaviours. Controllers in different domains may discover one another, authenticate and negotiate behaviours. The application plane may itself split responsibility among domains.

Those are the mechanics of cooperation. They are not yet a complete account of commitment.

A domain can authenticate a peer controller and still need to know what that peer is entitled to request. It can negotiate a per-hop behaviour and still need a validity interval, capacity ceiling and teardown rule. It can accept a local segment and still refuse to expose its raw topology or internal scheduling. Another domain can deliver its segment correctly while an end-to-end promise fails because the boundary conditions were not aligned.

The useful evidence is therefore neither one global path dump nor nine incompatible local tickets. It is a set of composable commitments. Each domain should be able to attest to the constraint subset it accepted, the resource class it reserved, the time window, the local monitoring condition and the event that releases the reservation. An end-to-end reviewer should be able to verify that these commitments form a continuous service without learning the precise internal route.

This separation matters for both autonomy and correction. A domain may withdraw or revise a commitment when its conditions change. The end-to-end decision then needs re-evaluation. Silently substituting another path may preserve packet delivery while violating a shared-risk, latency or jurisdictional constraint that the original service owner considered hard.

Authentication answers “Is this really the peer?” A commitment record answers “What did the peer agree to do, for whom, under which limits, and until when?”

Security makes authentic excess possible

RFC 9055 shows why controller integrity matters. Control-packet modification and injection can manipulate paths and resource allocation. A compromised controller can appear legitimate to nodes and cause them to believe it is authorised to issue instructions. Spoofed controller messages can change bandwidth, add or remove endpoints, drop flows or create false reservations that exhaust resources. Delayed teardown can leak capacity until new flows cannot be admitted.

The obvious response is strong authentication, integrity protection and careful system design. Those controls are indispensable. They are still smaller than mandate evidence.

Consider a controller credential that is genuine, current and uncompromised. The controller issues a syntactically valid command to reserve resources for a recognised service. Every security check passes. The command can nevertheless be outside policy because the requested bandwidth exceeds that service’s ceiling, the protection mode was not approved, the time window expired or the route crosses a domain the requester may not bind.

Calling this an authentication failure would blur the remedy. Rotating credentials will not fix a stale objective. Calling it a computation failure is equally misleading if the solver faithfully optimised the inputs it received. The failure is that the system cannot reconstruct who owned the consequential constraint and whether the command was inside that ownership boundary.

Conversely, an audit system that stores every topology edge, schedule, endpoint and industrial purpose would create a reconnaissance asset. RFC 9055 notes that knowledge of flow count, bandwidth and timing can help an attacker. The governance record must show that the decision was authorised without reproducing the sensitive operational map.

Monitoring is part of the decision, not a verdict after it

RFC 9938 assigns performance and fault observation to the management side of the controller plane. The distinction between active and passive measurement is material. Active OAM injects traffic and can itself affect delay and throughput, so the framework does not recommend it for ordinary operation; passive monitoring is preferred in operational domains.

This means that an “optimal” path is conditioned on an evidence method. A path computed from passive measurements may use different freshness and confidence assumptions from one commissioned with an active test. A controller may have complete configuration state but delayed performance evidence. A metric may be technically valid yet too old for a safety-sensitive reallocation.

Monitoring should therefore be tied to the constraint that depends on it. If the hard objective is end-to-end latency, the record should name the measurement window, aggregation rule and freshness limit. If the service relies on disjoint paths, the system should track changes in shared-risk evidence. If an exception temporarily permits reduced protection, the expiry should cause a new decision rather than merely a dashboard warning.

The controller does not need to promise omniscience. It needs to make the state of its knowledge visible enough that an authorised actor can decide whether reuse, re-computation or degradation is legitimate.

What a path computation proves

A reproducible computation can prove useful things. Given a stated topology/capability snapshot, a particular constraint set and a named algorithm version, it can show which candidates were considered feasible, which metrics were calculated and why one candidate ranked first. Installation evidence can show that nodes received the corresponding configuration. OAM can show how the service behaved over an observation interval.

That evidence cannot alone prove:

that the requester owned the service objective;
that the objective version was current;
that a soft preference was not mistakenly treated as a hard limit;
that the selected path’s resource cost was within an approved ceiling;
that replication or buffer consumption was justified;
that non-DetNet coexistence rules remained within policy;
that every participating domain accepted the same end-to-end meaning;
that a failure-mode relaxation had an owner and expiry;
that a reservation was released when the mandate ended.

These are not reasons to distrust computation. They are reasons to avoid asking computation to attest to facts outside its inputs.

A constraint-ownership receipt

The missing companion can be compact. Start with a stable digest of the flow request rather than its sensitive payload. Record the requester role, service owner, Flow Management Entity boundary and requested validity interval. Bind that identity to a versioned constraint set.

For each constraint, record its source and status. Is maximum latency a hard service commitment, a planning target or a monitoring trigger? Is path disjointness mandatory, preferred or temporarily waived? Is bandwidth a peak worst-case reservation or an observed average? Which coexistence floor protects non-DetNet traffic? A solver should not have to infer those distinctions from a field name.

Then name the decision authority. The record should show who may rank soft constraints, approve a resource ceiling, accept a degraded mode, commit an additional domain and order teardown. Authority should be scoped rather than inferred from an all-powerful controller credential.

Computation evidence can remain privacy-preserving: a digest and freshness statement for the topology/capability snapshot, algorithm and evaluator versions, a digest of the candidate set, a digest of the chosen path, reasons for rejected constraints and the uncertainty that remained. A reviewer usually does not need the raw path to establish that the approved process was followed.

Each domain can add a commitment token covering the subset it accepted, the resource class, activation result, validity interval and release condition. The end-to-end receipt joins those tokens without forcing a domain to reveal its internal topology.

Finally, capture lifecycle: OAM evidence window, re-evaluation triggers, exception expiry, rollback target, teardown owner and correction state. If evidence changes, issue a linked superseding receipt. Do not overwrite yesterday’s rationale with today’s topology and pretend the original choice was made from information that did not yet exist.

Evidence limits

The cited RFCs do not report a failed DetNet deployment. They do not show that a named controller made an improper allocation, that a domain broke a promise or that ordinary traffic was starved. They provide architecture, information models, security analysis and operational requirements from which the governance boundary can be examined.

Nor does RFC 9938 promise a finished controller protocol. It is a framework intended to inform later work. The proposed receipt is not a hidden requirement discovered between its lines. It is an editorial response to a recurring institutional problem: machines can apply decisions with greater precision than the organisation can later explain who was entitled to make them.

The practical conclusion is modest. Keep improving path computation, signalling, configuration and OAM. Authenticate controllers and protect their messages. But before calling the resulting path optimal, preserve the answer to an earlier question: optimal under whose constraints, spending whose resources, for how long?

DetNet’s ‘Optimal Path’ Is a Governance Decision Before It Is a Calculation

Summary

The decision happens before the solver starts

A service request is not yet an objective function

Reserved capacity makes preference distributive

Three architectures do not remove the same question

Crossing a domain multiplies commitments

Security makes authentic excess possible

Monitoring is part of the decision, not a verdict after it

What a path computation proves

A constraint-ownership receipt

Evidence limits

Sources

Deeper Profile Context

Strategic Circle

Leadership Alliance

Strategic Circle Briefing

Leadership Alliance Briefing