Summary

  • CATS can select service instances using both network and computing conditions. For a moving client using a stateful service, RFC 10054 requires the application to explicitly indicate whether it allows CATS to steer the session midstream.
  • A route change, a flow-affinity record and a valid application-context migration are three different receipts. Better latency at a second edge does not prove that the second service site holds the state needed to continue the session.

A greener edge can still be the wrong place for this session

Imagine a cloud-rendered mixed-reality session that begins near a city centre. The edge site handles the client’s changing input and returns successive frames. As the client moves, a more distant site may have spare compute capacity and a better path. The network sees a promising destination. The application still has to answer a different question: can this particular session continue there with its context intact?

That distinction is the useful part of RFC 10054. Computing-Aware Traffic Steering, or CATS, selects service instances and directs traffic using computing capabilities and resource status alongside network conditions. It is designed for the fact that a physically closest site may be overloaded or lack the required hardware. A client’s movement and changing service load can also make the formerly suitable site less suitable.

From the routing perspective, CATS can be application-transparent and can schedule stateful as well as stateless services. Transparency helps a provider make a network decision without asking every application to choose every packet path. It does not make application state transparent. The same document draws that boundary expressly: when a client moves and its service is stateful, the application must explicitly indicate whether it allows the routing system to enable CATS. Without that indication, mid-session scheduling can leave application context inconsistent across service sites or interrupt the service.

The word “allows” should stay narrow. RFC 10054 describes an application-side operational indication. It does not define a universal wire format for that indication, a user-facing consent screen, or a legal authorization regime. Nor does an allow signal prove that the destination has received a valid snapshot. It says the service permits CATS functionality in the relevant stateful-mobility case; the implementation still has to make continuity real.

Three different things can move

Operators often compress three separate conditions into the word “handoff.” First, the network can redirect packets. Second, a flow can remain associated with the same service contact instance and path. Third, the service can carry the client’s application context to a different instance and resume correctly. The first is a forwarding action. The second is an affinity property. The third is a service-level state transition.

RFC 10053 describes service-contact-instance affinity as keeping packets in a flow on the same service contact and path, in part to avoid reordering and unpredictable latency. It also says the framework does not itself introduce a mechanism for defining or enforcing that affinity. RFC 10054 adds a related but distinct set of requirements: R14 says to maintain per-flow instance affinity for stateful sessions and transactions; R15 says to avoid maintaining application-specific per-flow state in network nodes for that purpose; and R16 says to support continuity when a user device or service instance moves.

Those requirements expose a design boundary rather than a finished handoff protocol. The network needs enough information to preserve a flow’s treatment without becoming the application’s state store. The application needs to say whether a move is permitted, then its service must know what has to be copied, reconstructed or left behind. If a rendering service treats the previous user input as state, for example, new packets reaching another site are not by themselves evidence that the next frame is based on the right history.

RFC 10054 uses AR/VR to illustrate that client-specific input may be processed by a stateful instance even when common base assets can be served more freely.

The safe inference is modest: route selection can identify a better candidate, but only the application can define whether its state is movable under the circumstances. CATS metrics are not a state-transfer receipt. A forwarding-table update is not proof of a restored context. A healthy new endpoint is not proof that a long-running transaction continued without a semantic break.

The boundary is also an operating contract

The RFC is an IETF community-consensus document approved for publication by the IESG, but it is Informational and not an Internet Standards Track specification. It sets out use cases and requirements for single-domain scenarios. That matters for deployment claims: the text identifies a problem and desired behavior; it does not establish that a provider’s service can migrate safely or that two providers share one state-continuity contract.

The operational question is therefore not simply whether the application “supports CATS.” A useful contract needs to say which service and session classes may move, what event makes a move eligible, who signals the decision, and what evidence is required before packets are redirected. A blanket setting can conceal the difference between an idempotent request and a session whose next step depends on state held at the current site.

The same discipline applies to failure. If the application gives no allow indication, the provider should not infer one from a low-latency target or a generic service label. A reasonable policy is to preserve existing affinity until the application’s own migration path can take over, or to make a new request decision without silently reassigning an active stateful session. That is an operational recommendation, not a new RFC requirement.

The economics are uneven. A network operator sees utilization and path quality; the application provider owns the state model and the customer-facing continuity promise. If the steering system treats a better metric as permission, the utilization gain lands with the network while a broken session lands with the service and its customer. The explicit application signal makes that allocation visible, but it does not settle implementation quality.

Sources and status