| Internet-Draft | Centralized CATS Control Plane | October 2026 |
| Zhang & Shen | Expires 22 April 2027 | [Page] |
This document specifies a centralized control-plane realization of Computing-Aware Traffic Steering (CATS). The realization uses a logically centralized CATS Path Selector (C-PS) together with ingress and egress CATS-Forwarders. The C-PS receives a service request from an ingress CATS-Forwarder, resolves the requested service to an eligible service contact instance using computing service and network information, and then invokes a path-computation function for the selected destination. The path-computation request contains a resolved headend, endpoint, and network constraints; it does not ask the PCE to discover service instances.¶
After path computation, the C-PS returns a steering binding to the ingress CATS-Forwarder. The binding identifies the selected destination address, the egress CATS-Forwarder, and a realizable path or policy. The ingress forwarder applies the destination replacement and path encapsulation to the first packet and forwards it. The egress forwarder removes the path encapsulation and delivers the packet to the selected service contact instance. Subsequent packets use the installed flow binding, and reverse traffic uses the corresponding return binding.¶
This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.¶
Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet-Drafts is at https://datatracker.ietf.org/drafts/current/.¶
Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress."¶
This Internet-Draft will expire on 22 April 2027.¶
Copyright (c) 2026 IETF Trust and the persons identified as the document authors. All rights reserved.¶
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Revised BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Revised BSD License.¶
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 [RFC2119] [RFC8174] 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.¶
This document uses the CATS terminology from [RFC10053], [I-D.zhangb-cats-service-metrics-op] and the request terminology from [I-D.zhang-cats-clients-request-packet]. The following terms describe this realization.¶
Service catalogue / CMAS C-SMA reports C-NMA / TE reports
| | |
v v v
service context CST input topology/TEDB
\ /
v v
+-------------------------------+
| Centralized CPS control node |
| C-TC -> 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 [RFC4655]. 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 Section 8.4. 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.¶
| 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. | [I-D.zhangb-cats-cmas] |
| CST | Indexes eligible service contact or instance candidates and explicit service-oriented values such as GAS and Computing Time. | [I-D.zhangb-cats-service-metrics-op] |
| NST | Provides network reachability and metrics for the candidate headend-to-egress or endpoint paths. It can be derived from a TEDB. | [I-D.zhangb-cats-service-metrics-op] |
| Metric hierarchy | Provides metric fields, levels, aggregation, normalization, and freshness semantics used by a deployment. | [I-D.ietf-cats-metric-definition] |
| 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 [I-D.zhang-cats-clients-request-packet]. 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 [RFC8799].¶
+---------------------------------------------------------------+ | IP Header (IPv4 or IPv6) | | Source: client's address | | Destination: VPA, anycast, or dedicated service address | +---------------------------------------------------------------+ | [Optional] IPv6 Options Header with the CATS Request Option | | (Mode A) | +---------------------------------------------------------------+ | Transport Header (TCP/UDP/QUIC/etc.) | +---------------------------------------------------------------+ | [Optional] CATS Request Envelope with the TLVs (Mode B) | | -- position identified by a mapping | +---------------------------------------------------------------+ | Application Payload | +---------------------------------------------------------------+
The figure is reproduced as an architectural view of the request defined by [I-D.zhang-cats-clients-request-packet]. 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.¶
| 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 [RFC5440]. SR-MPLS and SRv6 path information uses the applicable PCEP extensions [RFC8664] [RFC9603]. 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 Section 8.5.¶
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 Section 7.1. 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.¶
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.¶
ABSENT -- new classified packet --> 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.¶
Client-facing packet:
192.0.2.10:51000 --> 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.¶