A Centralized Control Plane for Computing-Aware Traffic Steering

The CATS framework defines a set of functional components that use computing and network information to steer service traffic toward a suitable service contact instance. The framework does not require the CATS Path Selector (C-PS) to be a particular physical device. A C-PS can be a standalone controller component, a function in an SDN controller or PCE server, or a function co-located with a CATS-Forwarder. This document specifies one realization in which the C-PS is logically centralized and has an associated path-computation function. The central distinction in this realization is between service selection and network path computation. The C-PS first interprets the client service request and selects a reachable service destination using the Computing Service Table (CST), the Network Service Table (NST), and the referenced joint-selection policy. Only after the destination has been selected does the C-PS form a path-computation request for the PCE function. The PCE computes a path from the ingress forwarding headend toward the selected egress or endpoint. The PCE is therefore not a service catalogue and does not receive the complete service-selection problem. The resulting data path has four visible roles: the client, an ingress CATS-Forwarder, an egress CATS-Forwarder, and a service contact instance. The control path has the C-PS, the C-SMA and C-NMA information sources, and the PCE function. The ingress forwarder applies the selected destination translation and path steering instruction. A deployment in which the C-PS and the ingress forwarding function are co-located can execute the same actions locally; this is an implementation placement choice.

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 when, and only when, they appear in all capitals, as shown here.

This document specifies control-plane processing and the interfaces needed to realize the described flow. It does not define a new metric vocabulary, a new service catalogue, a new PCEP message, an application protocol, or a universal southbound protocol for every forwarding device. Those functions are either defined by the referenced documents or selected by a deployment. The baseline assumes a single CATS administrative domain, an authorized client attachment, and a service destination that can be represented by an IP address or another locator supported by the selected data plane. Multi-domain federation, transport termination, application-layer load balancing, and transparent migration of an established stateful session require additional profiles.

defines the CATS framework, including C-PS, C-TC, C-SMA, C-NMA, CATS-Forwarder, service contact instance, service instance, CS-ID, and CSCI-ID. This document uses those roles and adds a concrete centralized processing sequence. defines the role of a public service platform and the CS-ID-related service information used for publication, deployment, and client service resolution. A CMAS-style platform can provide service context and assign or resolve a CS-ID; it does not replace runtime C-PS selection. specifies observable C-SMA behavior, including collection from service contact instances, validation and sanitization, soft-state caching, update control, and synchronization with a C-PS. This document consumes the resulting service reports and does not define their collection protocol. defines the CATS metric hierarchy, fields, aggregation, and normalization. defines explicit service-oriented metrics and the CST/NST joint-selection information model. This document refers to those definitions and intentionally does not reproduce their metric formulas or selection algorithm. defines the common CS-ID and constraint encoding and its Mode A and Mode B carriage. The packet figure and processing rules in this document are an application of that encoding to the centralized C-PS profile.

This document uses the CATS terminology from , and the request terminology from . The following terms describe this realization.

C-PS: The logical CATS Path Selector. It parses the service request context, selects an eligible service destination, forms the path-computation request, and creates the steering binding.
CPS control-plane node: The deployment unit that hosts the logically centralized C-PS and its associated state. It MAY also host the PCE function, a C-TC, or a data-plane forwarder.
PCE function: The path-computation function invoked after the C-PS has selected a destination. It computes a network path using topology and network resources. It does not resolve a CS-ID to a service instance in this profile.
Ingress CATS-Forwarder: The data-plane node that first classifies a client service flow and applies the steering binding supplied by the C-PS.
Egress CATS-Forwarder: The data-plane node at the service-side end of the selected CATS path. It terminates the CATS path encapsulation and delivers the packet to the selected service contact instance or service instance.
Service destination: The CSCI-ID and associated network locator selected for a request. The locator can identify a service contact instance; a direct-instance deployment binds it to one service instance.
Steering binding: The per-flow or aggregate forwarding state that associates a classification key with a selected destination, a path or policy, translation actions, an egress forwarder, and a lifetime.
Global Available Slots (GAS): The maximum number of concurrent requests/sessions a service site is willing and able to serve for a specific CS-ID at a given time.
Computing Service Table (CST): A data structure maintained by the C-PS that contains computing-oriented metrics (GAS, Computing Time, etc.) indexed by CS-ID and CSCI-ID. It is populated from C-SMA reports.
Network Service Table (NST): A data structure maintained by the C-PS that contains network-oriented metrics (delay, jitter, bandwidth, etc.) indexed by network path identifiers. It can be derived from the Traffic Engineering Database (TEDB).
Joint Selection Algorithm: The decision logic used by the C-PS to select the optimal CSCI-ID by simultaneously evaluating both computing and network metrics.

Centralized C-PS Control and Data Plane C-PS -> PCE function | | CST/NST view, bindings | +---------------+---------------+ | steering binding | v Client --> Ingress CATS-Forwarder =======> Egress CATS-Forwarder --> classify, hold, decapsulate, deliver rewrite, encapsulate | v SCI or service instance Return traffic: SCI/instance --> Egress --> Ingress --> Client ]]> The C-PS is logically centralized even when implemented as a redundant cluster. The CST is populated from authorized service information and C-SMA reports. The NST is the C-PS view of network reachability and metrics; it MAY be derived from a TEDB or supplied by a network-control component. The PCE function consumes the selected headend, endpoint, and network constraints and returns a realizable path. The ingress and egress forwarders are data-plane functions. A C-PS message or PCEP message does not carry the user's application packets. A forwarder can communicate with the C-PS over a protected control channel, while client traffic follows the data-plane path installed or activated by the steering binding.

The C-PS is a logical function and is not tied to a particular server or hardware class. It MAY run on a standalone x86 server, a virtual machine, a container, an SDN controller, a PCE server, or a node that also hosts a CATS-Forwarder. A deployment MAY use a separate PCE service; in that case the C-PS is a PCC-like client for path computation as described by the PCE architecture . If the PCE function is co-located, the request and reply can be an internal API or IPC exchange with PCReq/PCRep semantics. The centralized-control baseline in this document keeps packet forwarding in the ingress and egress CATS-Forwarders. An inline realization MAY co-locate the ingress data plane with the CPS node. In that realization the CPS data plane itself performs the destination replacement and path encapsulation described in Section . The placement does not change the service-selection order or the requirement that the C-PS select the destination before invoking path computation.

The headend in a path-computation request is the node that will impose or select the path instructions. In the baseline it is the ingress CATS-Forwarder. In an inline realization it is the CPS data-plane headend. The endpoint is the selected egress attachment or service locator according to the underlay and encapsulation model. The C-PS MUST provide the PCE function enough information to identify both endpoints and the required routing context.

The C-PS maintains or accesses the following logical views. Their data models and selection algorithms are defined by reference. Logical Information Views

View	Role in this document	Defined by reference
Service context	Maps a CS-ID to service description, version, input context, and deployment information. It can be supplied by a CMAS-style public service platform.
CST	Indexes eligible service contact or instance candidates and explicit service-oriented values such as GAS and Computing Time.
NST	Provides network reachability and metrics for the candidate headend-to-egress or endpoint paths. It can be derived from a TEDB.
Metric hierarchy	Provides metric fields, levels, aggregation, normalization, and freshness semantics used by a deployment.
Flow binding table	Records the selected destination, path handle, address transformations, forwarder owner, and lifetime for an admitted flow.	This document

The C-PS MUST apply the freshness and validity rules of the selected metric operation. A service report with an expired soft state, GAS equal to zero, failed health status, or an unauthorized source MUST NOT be treated as an eligible candidate. The C-PS MUST NOT infer a computing capability from a network path record. The joint-selection algorithm is referenced rather than redefined. Conceptually, the C-PS first resolves the CS-ID, filters candidates against hard constraints, joins each candidate with a reachable path view, and then applies the configured ranking or policy. If no policy-compliant candidate/path pair exists, the C-PS reports selection failure and does not install a steering binding.

The client request format is defined by . A request identifies a service through a destination address, an explicit CS-ID, or both. Network and computing constraints are optional. A CATS domain MUST provision the selected carriage mode and the interpretation of CS-IDs and service addresses. The carriage mechanisms are intended for a limited domain in which clients and CATS nodes are provisioned consistently .

Client Service Request Packet Structure The figure is reproduced as an architectural view of the request defined by . Mode A carries the common CATS Request TLVs in an IPv6 Destination Options or Hop-by-Hop Options header. Mode B carries the same TLVs in an application-layer envelope at a position identified by an explicit application, API, or transport mapping. An ingress forwarder MUST NOT search arbitrary encrypted payload bytes for a request envelope. For a packet that contains no explicit metadata, the destination address MUST unambiguously identify a service in the local CATS domain. A VPA, anycast address, or dedicated service address can instead identify an ingress interception point; the C-PS then uses a configured mapping to resolve the service. If a packet carries an explicit CS-ID and an address-based service identity that disagree, the ingress forwarder MUST reject the request or apply an explicitly configured precedence rule. It MUST NOT silently combine two different services. The ingress forwarder passes the parsed CS-ID, constraints, original packet tuple, tenant context, ingress identity, and request-generation information to the C-PS. The request metadata is input to selection; it does not authorize a client to select an arbitrary endpoint or override the service catalogue.

This document defines information carried between logical functions. It does not require one new wire protocol. A deployment can use an authenticated API, a message bus, an existing controller protocol, or an implementation-local call. The following interfaces MUST provide equivalent information. Required Logical Interfaces

Interface	Producer	Required information
Service context	CMAS-style platform or authorized registry	CS-ID, service version, service context, and authorized deployment associations
Metric report	C-SMA and C-NMA	CS-ID/CSCI-ID records, network records, timestamps, validity, source identity, and update generation
Service request	Ingress CATS-Forwarder	Transaction identifier, CS-ID or resolved address identity, constraints, flow key, ingress context, and packet disposition
Path request	C-PS	Selected endpoint, headend, egress context, network constraints, path policy, and correlation identifier
Path reply	PCE function	Path status, segment list or policy handle, endpoint/egress, metric generation, and failure reason if no path exists
Steering binding	C-PS	Flow match, selected destination, address actions, path handle, egress, reverse binding, lifetime, and version
Binding status	Forwarders	Install result, counters, path status, expiry, and removal reason

The C-PS MUST complete service selection before creating a path request. The request contains at least a transaction identifier, the path headend, the selected endpoint or egress, the routing domain, and the network constraints that remain applicable. It MAY contain bandwidth, delay, disjointness, protection, affinity, color, or segment-routing capability information. It MUST NOT require the PCE to query the CST or decide which CS-ID candidate is appropriate. If the PCE function is accessed using PCEP, the request can use the PCReq semantics and the reply can use PCRep semantics from . SR-MPLS and SRv6 path information uses the applicable PCEP extensions . If the PCE is internal, the same fields can be exchanged by an API or IPC message. This document does not define a new PCEP object or carry a user packet in the path request.

A successful C-PS decision produces one logical binding. Its forward direction includes a match context, selected CSCI-ID or instance locator, destination replacement, path handle or segment list, egress identity, and lifetime. Its reverse direction includes the expected service-side tuple, the original client tuple, source restoration, and the return path or ownership context. The two directions MUST be committed as one logical state transition.

This section defines the normative processing sequence for a new service flow. The ingress and egress forwarders MAY be hardware, software, virtual, or containerized functions as long as they provide the required matching, buffering, address, and path actions.

When a client packet arrives, the ingress CATS-Forwarder MUST identify the ingress context, flow key, destination service identity, and any authorized request metadata. It MUST check an existing steering binding before initiating a new selection. A packet matching an active binding follows Section . If no binding exists, the ingress forwarder MUST create a bounded pending record and either buffer the packet or retain enough packet state to retransmit it once the decision completes. Additional packets for the same pending key SHOULD join the pending record. They MUST NOT cause independent selections that could bind one connection to multiple service instances. The forwarder sends a service-request message to the C-PS over an authenticated control channel. It includes the request metadata and packet tuple, but it does not send the user's application payload unless a deployment explicitly requires a security-authorized inspection. Mode B metadata protected by end-to-end encryption is not available to a transparent on-path forwarder.

On receipt of a service request, the C-PS MUST authenticate the ingress forwarder, validate the tenant and request-generation context, and reject malformed or unauthorized metadata. It resolves the CS-ID from the explicit request or configured destination mapping. If the service identity cannot be resolved, the C-PS terminates the pending transaction with a service-resolution failure. The C-PS queries the CST for candidates and applies the referenced eligibility, freshness, and hard-constraint rules. It associates each remaining candidate with its egress attachment and the corresponding NST path view. The C-PS then applies the joint-selection algorithm and records the selected CSCI-ID, service locator, endpoint or egress, policy version, metric generations, and decision timestamp. The selection result is a control-plane decision. It is not a path-computation result. If the result does not identify a realizable destination, the C-PS MUST NOT send an unconstrained path request to the PCE function. It MUST fail the pending request or use only a fallback explicitly configured for that service.

After service selection, the C-PS constructs the path request described in Section . The headend is the ingress forwarding function or the inline CPS data-plane headend. The endpoint is the selected egress or instance locator according to the underlay realization. The PCE function reads its TEDB or the network view that supplies the NST and computes a path that satisfies the supplied network constraints. The PCE function returns a path result or a no-path result. A successful result MUST identify a path that the selected headend can activate, such as an SR Policy handle, an SR-MPLS label or segment list, an SRv6 segment list, a tunnel identifier, or a native forwarding-policy reference. A path result that cannot be represented by the headend's advertised capabilities MUST be treated as a path failure. The C-PS joins the path result with the earlier service decision. It MUST verify that the endpoint, egress, metric generations, and path result refer to the same transaction. A path computation response does not replace the service selection record and cannot change the selected service without a new C-PS decision.

After the service and path decisions are joined, the C-PS sends a steering binding to the ingress forwarder. The binding tells the forwarder which packets belong to the selected flow, which destination locator to use, and which path or policy to activate. The ingress forwarder MUST install or activate the forward and reverse state before releasing the buffered first packet. For the forward direction, the data-plane action normally replaces the service virtual, anycast, or dedicated interception address with the selected service locator. It then applies the required next-hop resolution, TTL or hop-limit processing, checksum updates, and path encapsulation. The underlay path can be ordinary IP forwarding, an IP tunnel, an SR-MPLS policy, an SRv6 policy, or another supported CATS path mechanism. The chosen action MUST match the capabilities advertised by the forwarder. If the C-PS and ingress forwarding function are co-located, the CPS data plane MAY perform these actions locally. In the baseline, the C-PS makes the decision and the ingress CATS-Forwarder executes it. In either placement, the phrase "C-PS selects the destination" refers to the control decision; the packet rewrite is performed by the data-plane function that owns the packet. The ingress forwarder sends the packet along the selected path to the egress CATS-Forwarder. The egress forwarder terminates the CATS path encapsulation, verifies the selected service context, and delivers the inner packet to the selected service contact instance or service instance. If the selected service contact instance fronts multiple hidden instances, the final dispatch is a service-function decision and MUST preserve the service affinity required by that service.

Subsequent packets that match the active steering binding MUST be forwarded without a new C-PS service-selection request or a new PCE computation. The ingress forwarder applies the same destination and path actions, and the egress forwarder delivers the packets to the same selected service destination unless an explicit migration procedure is active. The flow key MUST be sufficient for the service's affinity requirement. A five-tuple is a common choice, but a service MAY require a broader association, such as related media flows or a tenant-and-session identifier. A metric update normally affects new admissions. It MUST NOT silently move an established stateful flow to another instance.

Return traffic MUST reach the forwarder that owns the reverse binding, or a synchronized replacement. The reverse binding changes the service-side source locator back to the client-visible service address when address translation is used and restores the client-facing forwarding context. The return path can use the reverse CATS path, ordinary routing constrained to the binding owner, or a deployment-specific symmetric path. A reverse packet with no valid binding MUST NOT trigger a new service selection or be delivered to an arbitrary client. The forward and reverse binding lifetimes, ownership epochs, and path generations MUST be coordinated.

The C-PS steering binding is technology-neutral. A forwarder can realize it through an existing controller protocol or device interface. The deployment MUST state which actions and path encodings are supported.

Segment routing: The binding can select an SR Policy or segment list. PCEP SR extensions, NETCONF, gNMI, or another supported interface can activate the policy. The headend MUST bind matching service traffic to the active policy; merely computing a segment list does not steer packets. The distinction between policy validity, activation, and traffic steering follows .
OpenFlow or programmable switching: A switch that supports the required flow matches, field-rewrite, encapsulation, and output actions MAY receive a flow rule through its controller interface. OpenFlow capability is device-specific; a switch is not required to support every optional action.
Conventional routing systems: A conventional router can receive an SR Policy, a tunnel, a label or forwarding entry, a policy route, or another native forwarding object through its supported interface. The C-PS specification does not assume that the device accepts OpenFlow.

The underlay nodes that do not participate in CATS need only process the selected encapsulation or forwarding instructions. The egress attachment and instance delivery must be provisioned before the C-PS admits traffic. A route, label, or policy installed without a corresponding service-side delivery rule is not a complete CATS path.

Centralized Flow State PENDING PENDING -- service selection ------> DESTINATION_SELECTED DESTINATION_SELECTED -- no path --> FAILED DESTINATION_SELECTED -- path reply -> BINDING_READY BINDING_READY -- forwarder commit -> ACTIVE BINDING_READY -- commit failure ---> FAILED ACTIVE -- idle/hard expiry --------> DRAINING ACTIVE -- path repair --------------> ACTIVE ACTIVE -- instance failure ---------> FAILED or RECONNECT_REQUIRED DRAINING -- reverse cleanup --------> ABSENT FAILED -- pending cleanup ----------> ABSENT ]]> PENDING state has a finite deadline and bounded packet memory. DESTINATION_SELECTED records the C-PS decision before path computation. BINDING_READY records a usable path result that has not yet been committed at the forwarders. ACTIVE state represents a committed forward and reverse binding. When a binding expires, the forwarder and the C-PS MUST release the flow state together. A shared path or policy MAY be retained while other bindings reference it. A path resource MUST NOT be removed merely because one flow ended. If service-side capacity or bandwidth reservation is used, its release is a separate resource operation and MUST follow the applicable reservation protocol. On a C-PS or forwarder restart, a replacement MUST restore the selected destination, reverse tuple, path reference, and ownership epoch before accepting packets for an established flow. Anycast or ordinary ECMP alone does not guarantee that both directions reach the same state owner.

The C-PS MUST fail closed for a malformed request, unauthorized ingress, unknown CS-ID, stale or unavailable service candidate, unavailable path, path-capability mismatch, or failed binding commit. The pending packet is discarded or an applicable rate-limited error is returned according to the deployment policy. A late PCE response MUST NOT resurrect a timed-out transaction. If the C-SMA or C-NMA information becomes unavailable, the C-PS follows the referenced metric-operation fallback policy. It MUST distinguish a valid cached value from an expired value. A fallback that changes the service, endpoint, or hard constraint interpretation MUST be explicitly configured and auditable. If the selected instance becomes unavailable after a flow is active, the C-PS MAY repair the path to the same instance. Re-selection to another instance requires service support for state migration or a client-visible reconnect. A control-plane failure and a data-plane failure affect different states and MUST be monitored separately.

The C-PS is a high-impact control-plane component. C-SMA, C-NMA, service registries, ingress forwarders, egress forwarders, and PCE peers MUST be authenticated and authorized. Metric reports MUST be integrity protected and checked for freshness, source, and update generation. A client-supplied CS-ID or constraint MUST NOT override service authorization or select an arbitrary network locator. The C-PS-to-forwarder and C-PS-to-PCE channels MUST provide authentication, integrity, replay protection, and access control. TLS or another authenticated channel can provide the transport protection; the deployment remains responsible for authorization and key management. PCEP control traffic is separate from user traffic and MUST NOT be used to carry application payloads. Request metadata can reveal service identity, workload type, latency sensitivity, bandwidth requirements, or security requirements. Mode A exposes metadata to nodes that inspect the IPv6 options. Mode B is visible to an on-path classifier only when the classifier is an authorized security endpoint. Logs and replicated flow bindings require access control, minimization, and bounded retention. Attackers can exhaust pending buffers, PCE request capacity, flow-binding memory, forwarder table entries, or translation resources by creating many distinct flows. Implementations MUST apply per-client, per-tenant, and global admission limits and SHOULD isolate management and path-computation resources from forwarding resources.

CST and NST records carry independent source and freshness information. The C-PS SHOULD record the generations used in every steering binding. A topology update can invalidate a path while the service candidate remains healthy; a service report can expire while the network path remains usable. These conditions MUST be handled independently.

A redundant C-PS service can use active-standby, active-active, or a sharded ownership design. The replicated state MUST include pending requests, selected destinations, path references, forward and reverse bindings, resource reservations, and ownership epochs. A replacement MUST fence the previous owner or otherwise prevent split forwarding.

Operators SHOULD measure new-flow selection rate, PCE request rate, established-flow forwarding rate, number of active bindings, pending-buffer occupancy, control-channel latency, and failover recovery. A centralized C-PS can reduce duplicated selection state but can also become a traffic and state concentration point if the inline realization is used. No throughput or latency benefit is implied by this architecture alone.

Implementations SHOULD correlate a client request, C-PS decision, path request, path result, steering binding, forwarder counters, egress delivery, and reverse binding using a transaction or flow identifier. Verification should check that the selected service destination agrees with the CST generation, that the path agrees with the PCE result, that the destination rewrite is applied once, and that return traffic reaches the binding owner.

All addresses in this example are documentation addresses. A client at 192.0.2.10 sends a TCP request to service address 192.0.2.100:443. The ingress forwarder is IF-1 and the egress forwarder is EF-2. The request carries CS-ID S1 and a maximum network delay constraint. Two service instances are registered: instance A at 198.51.100.11 and instance B at 198.51.100.21.

IF-1 receives the packet, parses the destination and CATS request metadata, and finds no active binding. It queues the first packet and sends a service-request message to the C-PS.
The C-PS authenticates IF-1, resolves S1, queries the CST, filters unavailable candidates, and joins each candidate with the NST. The configured joint-selection algorithm selects instance B and EF-2.
The C-PS constructs a path request with headend IF-1, endpoint EF-2 or the supported service locator, the maximum delay constraint, and the selected routing context. Its internal PCE reads the TEDB and returns an SRv6 segment list or another supported path handle.
The C-PS creates a steering binding and sends it to IF-1. The binding says to match this client flow, replace 192.0.2.100 with 198.51.100.21, use the returned path, and deliver at EF-2.
IF-1 commits the forward and reverse state, changes the destination address of the queued packet, updates affected checksums, applies the path encapsulation, and sends the packet toward EF-2.
EF-2 removes the path encapsulation and delivers the inner packet to instance B. The response returns through the reverse binding; the service-side source is restored to 192.0.2.100 before delivery to the client.
Later packets match the binding at IF-1 and use the same destination and path. The C-PS and PCE are not invoked per packet.

Example Address Transformation 192.0.2.100:443 Packet after ingress steering: 192.0.2.10:51000 --> 198.51.100.21:443 [outer SR/tunnel header toward EF-2] Return before reverse processing: 198.51.100.21:443 --> 192.0.2.10:51000 Packet delivered to client: 192.0.2.100:443 --> 192.0.2.10:51000 ]]> If the CPS node also hosts IF-1's data plane, steps 4 and 5 are executed locally. The PCE request and response remain control-plane exchanges; the client packet is processed by the local data plane and is never carried inside PCEP.

This document makes no IANA requests. It reuses the CATS request carriage and PCEP mechanisms defined by the referenced documents and defines an implementation information model rather than a new global message registry.

An implementation can be decomposed into a request classifier, a C-PS service-selection module, CST/NST adapters, a PCE client or local PCE adapter, a binding manager, and a forwarder southbound adapter. The decomposition is guidance; the logical behavior and state transitions are normative. Validation should capture the client-facing packet, the ingress-to-egress path, the packet at the service instance, and the reverse packet. It should verify Mode A and Mode B parsing where supported, CS-ID and constraint validation, CST/NST generation correlation, PCE request/response correlation, destination replacement, path encapsulation, egress delivery, reverse restoration, flow affinity, expiration, and failure cleanup. Performance measurements should report new-flow selection latency, PCE computation latency, binding installation latency, established-flow forwarding throughput, active-binding capacity, pending-buffer limits, control-channel delay, and failover recovery under stated devices and packet sizes. The architecture itself is not a performance result.