CATS B. Zhang, Ed. Internet-Draft Pengcheng Laboratory Intended status: Standards Track B. Shen, Ed. Expires: 22 April 2027 Harbin Institute of Technology 19 October 2026 A Centralized Control Plane for Computing-Aware Traffic Steering draft-zhangb-cats-centralized-control-plane-00 Abstract 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. Status of This Memo 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." Zhang & Shen Expires 22 April 2027 [Page 1] Internet-Draft Centralized CATS Control Plane October 2026 This Internet-Draft will expire on 22 April 2027. Copyright Notice 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. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 1.1. Requirements Language . . . . . . . . . . . . . . . . . . 3 1.2. Scope and Non-Goals . . . . . . . . . . . . . . . . . . . 4 2. Relationship to Other CATS Documents . . . . . . . . . . . . 4 3. Terminology and Roles . . . . . . . . . . . . . . . . . . . . 5 4. Architecture . . . . . . . . . . . . . . . . . . . . . . . . 6 4.1. Deployment Placements . . . . . . . . . . . . . . . . . . 7 4.2. Path Headend and Endpoint . . . . . . . . . . . . . . . . 7 5. Information Sources and Selection State . . . . . . . . . . . 7 6. Client Service Request and Metadata . . . . . . . . . . . . . 9 7. Control-Plane Interfaces . . . . . . . . . . . . . . . . . . 10 7.1. C-PS to PCE Request . . . . . . . . . . . . . . . . . . . 11 7.2. Steering Binding Information . . . . . . . . . . . . . . 12 8. Centralized Request Processing . . . . . . . . . . . . . . . 12 8.1. Packet Arrival at the Ingress Forwarder . . . . . . . . . 12 8.2. C-PS Service Selection . . . . . . . . . . . . . . . . . 13 8.3. PCE Path Computation after Destination Selection . . . . 13 8.4. Destination Replacement and Forwarding . . . . . . . . . 14 8.5. Subsequent Packets and Flow Affinity . . . . . . . . . . 14 8.6. Return Traffic . . . . . . . . . . . . . . . . . . . . . 15 9. Forwarder Actions and Southbound Realization . . . . . . . . 15 10. State Machine and Resource Lifetime . . . . . . . . . . . . . 16 11. Failure Handling . . . . . . . . . . . . . . . . . . . . . . 16 12. Security and Privacy Considerations . . . . . . . . . . . . . 17 13. Operational Considerations . . . . . . . . . . . . . . . . . 17 13.1. Metric and Path Freshness . . . . . . . . . . . . . . . 18 13.2. High Availability . . . . . . . . . . . . . . . . . . . 18 13.3. Capacity and Placement . . . . . . . . . . . . . . . . . 18 13.4. Observability and Verification . . . . . . . . . . . . . 18 14. End-to-End Example . . . . . . . . . . . . . . . . . . . . . 18 Zhang & Shen Expires 22 April 2027 [Page 2] Internet-Draft Centralized CATS Control Plane October 2026 15. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 20 16. Implementation and Validation Guidance . . . . . . . . . . . 20 17. References . . . . . . . . . . . . . . . . . . . . . . . . . 20 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 22 1. Introduction 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. 1.1. Requirements Language 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. Zhang & Shen Expires 22 April 2027 [Page 3] Internet-Draft Centralized CATS Control Plane October 2026 1.2. Scope and Non-Goals 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. 2. Relationship to Other CATS Documents [RFC10053] 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. [I-D.zhangb-cats-cmas] 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. [I-D.zhangb-cats-csma-implementation] 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. [I-D.ietf-cats-metric-definition] defines the CATS metric hierarchy, fields, aggregation, and normalization. [I-D.zhangb-cats-service-metrics-op] 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. [I-D.zhang-cats-clients-request-packet] 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. Zhang & Shen Expires 22 April 2027 [Page 4] Internet-Draft Centralized CATS Control Plane October 2026 3. Terminology and Roles 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. 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. Zhang & Shen Expires 22 April 2027 [Page 5] Internet-Draft Centralized CATS Control Plane October 2026 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. 4. Architecture 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 Figure 1: Centralized C-PS Control and Data Plane 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. Zhang & Shen Expires 22 April 2027 [Page 6] Internet-Draft Centralized CATS Control Plane October 2026 4.1. Deployment Placements 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. 4.2. Path Headend and Endpoint 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. 5. Information Sources and Selection State The C-PS maintains or accesses the following logical views. Their data models and selection algorithms are defined by reference. +=========+=================+======================================+ |View |Role in this | Defined by reference | | |document | | +=========+=================+======================================+ |Service |Maps a CS-ID to | [I-D.zhangb-cats-cmas] | |context |service | | | |description, | | | |version, input | | | |context, and | | | |deployment | | | |information. It | | | |can be supplied | | | |by a CMAS-style | | Zhang & Shen Expires 22 April 2027 [Page 7] Internet-Draft Centralized CATS Control Plane October 2026 | |public service | | | |platform. | | +---------+-----------------+--------------------------------------+ |CST |Indexes eligible | [I-D.zhangb-cats-service-metrics-op] | | |service contact | | | |or instance | | | |candidates and | | | |explicit service-| | | |oriented values | | | |such as GAS and | | | |Computing Time. | | +---------+-----------------+--------------------------------------+ |NST |Provides network | [I-D.zhangb-cats-service-metrics-op] | | |reachability and | | | |metrics for the | | | |candidate | | | |headend-to-egress| | | |or endpoint | | | |paths. It can be| | | |derived from a | | | |TEDB. | | +---------+-----------------+--------------------------------------+ |Metric |Provides metric | [I-D.ietf-cats-metric-definition] | |hierarchy|fields, levels, | | | |aggregation, | | | |normalization, | | | |and freshness | | | |semantics used by| | | |a deployment. | | +---------+-----------------+--------------------------------------+ |Flow |Records the | This document | |binding |selected | | |table |destination, path| | | |handle, address | | | |transformations, | | | |forwarder owner, | | | |and lifetime for | | | |an admitted flow.| | +---------+-----------------+--------------------------------------+ Table 1: Logical Information Views 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. Zhang & Shen Expires 22 April 2027 [Page 8] Internet-Draft Centralized CATS Control Plane October 2026 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. 6. Client Service Request and Metadata 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 | +---------------------------------------------------------------+ Figure 2: Client Service Request Packet Structure 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 Zhang & Shen Expires 22 April 2027 [Page 9] Internet-Draft Centralized CATS Control Plane October 2026 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. 7. Control-Plane Interfaces 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. Zhang & Shen Expires 22 April 2027 [Page 10] Internet-Draft Centralized CATS Control Plane October 2026 +===========+=====================+=================================+ | Interface | Producer | Required information | +===========+=====================+=================================+ | Service | CMAS-style | CS-ID, service version, service | | context | platform or | context, and authorized | | | authorized | deployment associations | | | registry | | +-----------+---------------------+---------------------------------+ | Metric | C-SMA and | CS-ID/CSCI-ID records, network | | report | C-NMA | records, timestamps, validity, | | | | source identity, and update | | | | generation | +-----------+---------------------+---------------------------------+ | Service | Ingress CATS- | Transaction identifier, CS-ID | | request | Forwarder | or resolved address identity, | | | | constraints, flow key, ingress | | | | context, and packet disposition | +-----------+---------------------+---------------------------------+ | Path | C-PS | Selected endpoint, headend, | | request | | egress context, network | | | | constraints, path policy, and | | | | correlation identifier | +-----------+---------------------+---------------------------------+ | Path | PCE function | Path status, segment list or | | reply | | policy handle, endpoint/egress, | | | | metric generation, and failure | | | | reason if no path exists | +-----------+---------------------+---------------------------------+ | Steering | C-PS | Flow match, selected | | binding | | destination, address actions, | | | | path handle, egress, reverse | | | | binding, lifetime, and version | +-----------+---------------------+---------------------------------+ | Binding | Forwarders | Install result, counters, path | | status | | status, expiry, and removal | | | | reason | +-----------+---------------------+---------------------------------+ Table 2: Required Logical Interfaces 7.1. C-PS to PCE Request 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 Zhang & Shen Expires 22 April 2027 [Page 11] Internet-Draft Centralized CATS Control Plane October 2026 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. 7.2. Steering Binding Information 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. 8. Centralized Request Processing 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. 8.1. Packet Arrival at the Ingress Forwarder 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. Zhang & Shen Expires 22 April 2027 [Page 12] Internet-Draft Centralized CATS Control Plane October 2026 8.2. C-PS Service Selection 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. 8.3. PCE Path Computation after Destination Selection 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. Zhang & Shen Expires 22 April 2027 [Page 13] Internet-Draft Centralized CATS Control Plane October 2026 8.4. Destination Replacement and Forwarding 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. 8.5. Subsequent Packets and Flow Affinity 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. Zhang & Shen Expires 22 April 2027 [Page 14] Internet-Draft Centralized CATS Control Plane October 2026 8.6. Return Traffic 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. 9. Forwarder Actions and Southbound Realization 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 [RFC9256]. 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. Zhang & Shen Expires 22 April 2027 [Page 15] Internet-Draft Centralized CATS Control Plane October 2026 10. State Machine and Resource Lifetime 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 Figure 3: Centralized Flow State 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. 11. Failure Handling 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. Zhang & Shen Expires 22 April 2027 [Page 16] Internet-Draft Centralized CATS Control Plane October 2026 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. 12. Security and Privacy Considerations 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. 13. Operational Considerations Zhang & Shen Expires 22 April 2027 [Page 17] Internet-Draft Centralized CATS Control Plane October 2026 13.1. Metric and Path Freshness 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. 13.2. High Availability 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. 13.3. Capacity and Placement 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. 13.4. Observability and Verification 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. 14. End-to-End Example 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. Zhang & Shen Expires 22 April 2027 [Page 18] Internet-Draft Centralized CATS Control Plane October 2026 1. 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. 2. 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. 3. 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. 4. 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. 5. 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. 6. 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. 7. 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. 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 Figure 4: Example Address Transformation Zhang & Shen Expires 22 April 2027 [Page 19] Internet-Draft Centralized CATS Control Plane October 2026 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. 15. IANA Considerations 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. 16. Implementation and Validation Guidance 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. 17. References [I-D.ietf-cats-metric-definition] Yao, K., Li, C., Contreras, L. M., Ros-Giralt, J., and G. Zeng, "CATS Metrics Definition", Work in Progress, Internet-Draft, draft-ietf-cats-metric-definition-13, 30 September 2026, . [I-D.zhang-cats-clients-request-packet] Zhang, B., Dai, Y., Du, Z., and R. Yang, "Carriage of CATS Service Identification and Request Constraints", Work in Progress, Internet-Draft, draft-zhang-cats-clients- Zhang & Shen Expires 22 April 2027 [Page 20] Internet-Draft Centralized CATS Control Plane October 2026 request-packet-01, 21 September 2026, . [I-D.zhangb-cats-cmas] Zhang, B., Dai, Y., Shen, B., Zhang, W., and Y. Qiao, "Public Service Platform for Computing-Aware Traffic Steering (CATS)", Work in Progress, Internet-Draft, draft- zhangb-cats-cmas-06, 18 August 2026, . [I-D.zhangb-cats-csma-implementation] Zhang, B., Du, Z., Shen, B., and Y. Yang, "CATS Service Metric Agent (C-SMA) Functional Implementation", Work in Progress, Internet-Draft, draft-zhangb-cats-csma- implementation-01, 7 October 2026, . [I-D.zhangb-cats-service-metrics-op] Zhang, B., Dai, Y., Du, Z., Zeng, G., and C. Miao, "Computing Service Metrics Operation and Joint Service Selection under CATS", Work in Progress, Internet-Draft, draft-zhangb-cats-service-metrics-op-06, 10 October 2026, . [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997, . [RFC4655] Farrel, A., Vasseur, J.-P., and J. Ash, "A Path Computation Element (PCE)-Based Architecture", RFC 4655, August 2006, . [RFC5440] Vasseur, JP. and JL. Le Roux, "Path Computation Element (PCE) Communication Protocol (PCEP)", RFC 5440, March 2009, . [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, May 2017, . [RFC8664] Dhody, D., "Path Computation Element Communication Protocol (PCEP) Extensions for Segment Routing", RFC 8664, December 2019, . Zhang & Shen Expires 22 April 2027 [Page 21] Internet-Draft Centralized CATS Control Plane October 2026 [RFC8799] Caldwell, M., "Limited Domains and Internet Protocols", RFC 8799, June 2020, . [RFC9256] Filsfils, C., "Segment Routing Policy Architecture", RFC 9256, July 2022, . [RFC9603] Dhody, D., "Path Computation Element Communication Protocol (PCEP) Extensions for IPv6 Segment Routing", RFC 9603, September 2024, . [RFC10053] Li, C., Du, Z., Boucadair, M., Contreras, L. M., and J. Drake, "A Framework for Computing-Aware Traffic Steering (CATS)", RFC 10053, October 2026, . Authors' Addresses Bin Zhang (editor) Pengcheng Laboratory Sibilong Street Shenzhen Guangdong, 518055 China Email: zhangb@pcl.ac.cn Bowen Shen (editor) Harbin Institute of Technology Taoyuan Street Shenzhen 518055 China Email: shenbowen@stu.hit.edu.cn Zhang & Shen Expires 22 April 2027 [Page 22]