CATS Working Group Y. Zhao Internet-Draft L. Han Intended status: Informational China Mobile Expires: 1 September 2026 X. Li H. Zheng Huawei D. King Old Dog Consulting 28 February 2026 Framework and Applicability of Computation-aware Traffic Steering (CATS) in Optical Transport Networks (OTN) draft-zhao-cats-otn-applicability-00 Abstract Computation-aware Traffic Steering (CATS) offers a framework for selecting computation service sites based on computation capabilities and load, and considering the network capabilities and state on the paths to the sites. Optical Transport Networks (OTN) provide guaranteed separation of traffic along with reserved hardware resources offering bandwidth and quality of service promises. This document describes how OTN may be used to support a CATS system to achieve the stringent performance targets required by demanding service environments. 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." This Internet-Draft will expire on 1 September 2026. Zhao, et al. Expires 1 September 2026 [Page 1] Internet-Draft CATS for OTN February 2026 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 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5 3. CATS Framework and Components . . . . . . . . . . . . . . . . 6 3.1. Assumptions . . . . . . . . . . . . . . . . . . . . . . . 7 3.2. CATS Identifiers . . . . . . . . . . . . . . . . . . . . 7 3.3. Framework Overview . . . . . . . . . . . . . . . . . . . 7 3.4. CATS Functional Components . . . . . . . . . . . . . . . 8 3.4.1. Service Sites, Service Instances, and Service Contact Instances . . . . . . . . . . . . . . . . . . . . . . 8 3.4.2. CATS Service Metric Agent (C-SMA) . . . . . . . . . . 8 3.4.3. CATS Network Metric Agent (C-NMA) . . . . . . . . . . 9 3.4.4. CATS Path Selector (C-PS) . . . . . . . . . . . . . . 9 3.4.5. CATS Traffic Classifier (C-TC) . . . . . . . . . . . 9 3.4.6. CATS-Aware OTN Edge Nodes . . . . . . . . . . . . . . 10 3.4.7. Underlay Infrastructure . . . . . . . . . . . . . . . 10 4. CATS-Aware OTN Workflow . . . . . . . . . . . . . . . . . . . 10 4.1. Service Announcement . . . . . . . . . . . . . . . . . . 10 4.2. Metrics Distribution . . . . . . . . . . . . . . . . . . 11 4.3. Service Access Processing . . . . . . . . . . . . . . . . 11 4.4. Service Contact Instance Affinity . . . . . . . . . . . . 12 5. Operational Considerations . . . . . . . . . . . . . . . . . 13 5.1. Provisioning of CATS Components . . . . . . . . . . . . . 13 5.2. Supervision of CATS Components and CATS OAM . . . . . . . 14 5.3. Deployment Considerations . . . . . . . . . . . . . . . . 15 5.4. Implementation Considerations on Using CATS Metrics . . . 16 5.5. Verifying Correct Operations . . . . . . . . . . . . . . 17 5.6. Impact on Network Operations . . . . . . . . . . . . . . 18 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 18 7. Security Considerations . . . . . . . . . . . . . . . . . . . 18 8. Privacy Considerations . . . . . . . . . . . . . . . . . . . 19 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 20 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 20 Zhao, et al. Expires 1 September 2026 [Page 2] Internet-Draft CATS for OTN February 2026 10.1. Normative References . . . . . . . . . . . . . . . . . . 20 10.2. Informative References . . . . . . . . . . . . . . . . . 21 Contributors . . . . . . . . . . . . . . . . . . . . . . . . . . 23 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 23 1. Introduction Computing service architectures have evolved toward multi-site environments, where collaborative service sites work together to optimize performance. This decentralized approach addresses critical issues like long response times and ensures a more efficient use of service and network resources, avoiding localized resource under- utilization or exhaustion. Networking infrastructures that incorporate computing resources have typically employed static service dispatching mechanisms, particularly for the selection of service instances. Within these architectures, service-specific traffic is frequently steered toward the nearest service site based on optical network service availability (such as fixed light-path or pre-established connections). This approach, however, often overlooks the real-time network state (e.g., utilization or congestion) and the dynamic service site state (e.g., GPU availability). Consistent with the use cases and requirements described in [I-D.ietf-cats-usecases-requirements], various services stand to benefit from traffic steering that integrates knowledge of network capabilities and state with computing resource metrics (such as capabilities and current usage). AI large-model training, some AI inference jobs, and distributed computing workloads impose stringent requirements on network determinism. These tasks rely on high- bandwidth, deterministic latency, and minimal jitter to ensure efficient synchronization between massive GPU clusters. Although the Computing-Aware Traffic Steering (CATS) framework [I-D.ietf-cats-framework] supports making joint compute- and network- aware decisions, the utilization of Optical Transport Network (OTN) features offers a reliable "hard-isolation" infrastructure. This integration is particularly effective for achieving the stringent performance targets required by demanding service environments. Current enterprise environments frequently distribute AI training and inference workloads across hybrid infrastructures, including on- premises and cloud-based networks. To ensure high availability and responsiveness, the CATS framework enables a specific service to be delivered through one or more service instances deployed across multiple service sites. These service instances are reached by clients via service contact instances. While a single service site, such as an intelligent computing center, can host multiple service Zhao, et al. Expires 1 September 2026 [Page 3] Internet-Draft CATS for OTN February 2026 contact instances, its available computing resources (e.g., GPU memory or FLOPS) may be constrained at any given time (usually because they are in use for other services). Since resource availability fluctuates across different service sites, steering traffic via dynamically reconfigurable optical paths provides an effective mechanism to mitigate resource limitations within a specific service site. The primary objective of traffic steering within the CATS framework is to identify an optimal service contact instance for each request, based on a combination of network and computing metrics. In certain scenarios, such as hierarchical or recursive contexts, this selection process does not necessarily expose the specific service instance that ultimately handles the client's invocation. Instead, only a service contact instance that acts as a gateway to multiple service instance is identified. Consequently, the metrics associated with a service contact instance may represent aggregate metrics derived from a collection of underlying service instances. Achieving deterministic performance for packet-based (e.g., IP) traffic steering is challenging because path selection and forwarding are performed on a hop-by-hop basis, which may introduce variability in latency, jitter, and queuing behavior. This limitation may render packet-based CATS insufficient to meet the strict performance requirements of highly performance-sensitive use cases, such as AI training and tele-health. This document introduces CATS-aware OTN which is intended to complement packet-based CATS by providing deterministic transport capabilities to support highly performance-sensitive use cases. It maps service flows into optimized optical containers (e.g., ODUk or OSU). By incorporating optical-layer characteristics (e.g., deterministic path latency, wavelength continuity constraints, and optical link performance parameters) together with computing-layer metrics, the framework enables the establishment of an end-to-end "hard-isolation" capable of delivering the performance stability required by AI cluster workloads. The CATS framework serves as an overlay architecture designed to facilitate the selection of optimal service contact instances among multiple candidates. The determination of whether a service instance is deemed 'suitable' depends on a multi-dimensional evaluation of both networking and computing metrics. This document extends the application of the CATS framework into the OTN domain, specifying how optical path computation and connection establishment can be made compute-aware. Zhao, et al. Expires 1 September 2026 [Page 4] Internet-Draft CATS for OTN February 2026 Additionally, this document outlines the operational workflow of the primary CATS procedures (see Section 4) as they are implemented across both the control and data planes within a CATS-aware OTN infrastructure. It is assumed that the CATS functional elements are situated within a single provider network. Consequently, deployment scenarios involving the co-location of these elements at the client site are considered out of scope for this discussion. 2. Terminology The following terms are defined in [I-D.ietf-cats-framework] and are not redefined here: * Client * Computing-Aware Traffic Steering (CATS). * Metric * Computing metrics * Service * Computing Service * CATS Service ID (CS-ID) * Service instance * Service contact instance * CATS Service Contact Instance ID (CSCI-ID) * Service request * CATS Path Selector (C-PS) * CATS Service Metric Agent (C-SMA) * CATS Network Metric Agent (C-NMA) * CATS forwarder The following definitions are extended from those provided in [I-D.ietf-cats-framework]. Zhao, et al. Expires 1 September 2026 [Page 5] Internet-Draft CATS for OTN February 2026 * Flow: A set of packets or signals grouped logically over a defined period. Within the context of CATS-aware OTN, a flow is generally encapsulated into an Optical Data Unit (ODU) or a fine-grain OTN (fgOTN) connection to provide deterministic transport for AI workloads. * CATS Traffic Classifier (C-TC): A functional entity responsible for identifying which packets or client signals constitute a traffic flow for a particular service request. It operates in coordination with the Ingress CATS-aware OTN edge node to ensure that such traffic is encapsulated into an OTN connection (e.g., ODUk) and follows the path computed by the C-PS. Refer to <> for additional details. This document makes use of the following additional terms: * CATS-aware OTN edge node: An OTN node deployed at the network edge that is capable of functioning as a CATS-Forwarder. It operates based on forwarding instructions provided by a CATS Path Selector (C-PS), which might be integrated into or external to the CATS- aware OTN edge node. A CATS-aware OTN edge node can function in either an Ingress or Egress capacity. Refer to Section 3.4.6 for further details. - Ingress CATS-aware OTN edge node: A functional entity that directs service-specific traffic along a path determined by CATS. In a CATS-aware OTN, an ingress CATS-aware OTN edge node connecting to the client site is responsible for mapping of client signals into ODU/fgOTN containers. It serves as the ingress point. - Egress CATS-aware OTN edge node: An entity situated at the termination of a CATS-computed path that interfaces with a service site. In a CATS-aware OTN, a Egress CATS-aware OTN edge node connecting to the Service Contact Instance is responsible for de-mapping signals from ODU/fgOTN containers. It serves as the egress point. 3. CATS Framework and Components Zhao, et al. Expires 1 September 2026 [Page 6] Internet-Draft CATS for OTN February 2026 3.1. Assumptions Under the CATS framework, a specific service can be implemented through single or multiple service instances, which may be deployed across one or several service sites. Each service is uniquely identified by a consistent service identifier (see Section 3.2). Furthermore, CATS operates under the premise that these instances are accessible through one or more service contact instances, without requiring further internal details of the instances themselves. 3.2. CATS Identifiers The CATS architecture utilizes two functional identifiers as defined in [I-D.ietf-cats-framework]: the CATS Service ID (CS-ID) and the CATS Service Contact Instance ID (CSCI-ID). This document maintains neutrality regarding the internal structure or semantics of the CSCI-ID. Within the context of CATS-aware OTN, a unicast IP address may serve as a CSCI-ID to uniquely identify the location or access point of a service instance. 3.3. Framework Overview Figure 1 in [I-D.ietf-cats-framework] provides a high-level conceptual overview of the CATS framework, abstracting the internal functional entities within the network. [I-D.ietf-cats-framework] further categorizes the architecture into three functional planes: the CATS Management Plane, the CATS Control Plane, and the CATS Data Plane. In the context of this document, the CATS Management Plane handles the configuration and maintenance of CATS-aware OTN edge nodes. The CATS Control Plane manages service scheduling by evaluating both computing and network status. In the context of OTN, this augmented Control Plane determines the establishment and cross-connection of optical paths or connections (e.g., ODUk/fgOTN) across the associated CATS-aware OTN edge nodes, relaying these instructions to the CATS Data Plane for execution. The CATS Data Plane manages compute-aware optical transport, which involves encapsulating service traffic into optical containers (e.g., ODUk), directing them via designated optical paths toward selected service contact instances, and performing signal cross-connections to maintain deterministic performance throughout the transit. Zhao, et al. Expires 1 September 2026 [Page 7] Internet-Draft CATS for OTN February 2026 Depending on the specific implementation and deployment scenario, these planes may comprise various functional components; subsequent sections will provide further details. For instance, the control plane may incorporate elements such as C-PS and C-NMA, while the data plane may include CATS-aware OTN edge nodes, C-TC, and other related entities. 3.4. CATS Functional Components CATS nodes determine the forwarding path for service requests received from clients by evaluating the operational status and capabilities of both service contact instances and the network. Within a CATS-aware OTN environment, this process incorporates the selection and provisioning of deterministic optical paths. The primary functional entities of the CATS framework and their interworking are illustrated in Figure 2 of [I-D.ietf-cats-framework] where CATS-aware OTN edge nodes access the underlying OTN infrastructure. 3.4.1. Service Sites, Service Instances, and Service Contact Instances Service sites are described in [I-D.ietf-cats-framework]. They represent physical or logical locations hosting the necessary resources (such as GPU clusters for AI training) to provide a specific service. A compute service is identified by a CATS Service Identifier (CS-ID). Figure 2 in [I-D.ietf-cats-framework] illustrates two CATS nodes (which in a CATS-aware OTN are CATS-aware OTN edge node 1 and CATS- aware OTN edge node 3) that facilitate access to these service contact instances. These entities function as Egress CATS-aware OTN edge nodes (see Section 3.4.6) implemented as CATS-aware OTN edge nodes. Note: "Egress" refers to the direction of service request placement, specifically identifying the exit point of the CATS infrastructure. 3.4.2. CATS Service Metric Agent (C-SMA) As described in [I-D.ietf-cats-framework], the CATS Service Metric Agent (C-SMA) is a functional entity that collects data regarding service sites and server resources (such as GPU utilization and memory availability), alongside the operational status of various service instances. Depending on the deployment, a C-SMA can be integrated with or positioned near a service contact instance, or hosted by/adjacent to an Egress CATS-aware OTN edge node (see Section 3.4.6). A given deployment may utilize one or multiple C-SMA Zhao, et al. Expires 1 September 2026 [Page 8] Internet-Draft CATS for OTN February 2026 instances. 3.4.3. CATS Network Metric Agent (C-NMA) The CATS Network Metric Agent (C-NMA) is a functional component described in [I-D.ietf-cats-framework]. It is responsible for acquiring information about the underlay network state. Within the context of CATS-aware OTN, the C-NMA retrieves optical-layer performance indicators, including Optical Signal-to-Noise Ratio (OSNR), wavelength or timeslot availability, and deterministic latency derived from physical fiber distance. The C-NMA is expected to employ established mechanisms (e.g., [RFC7471], [RFC8570], and [RFC8571]) in addition to specialized optical performance monitoring protocols. 3.4.4. CATS Path Selector (C-PS) The C-PS receives aggregated data from C-SMAs and C-NMAs to determine the optimal Egress CATS-aware OTN edge nodes for routing specific service requests. In the context of CATS-aware OTN, C-PSes focus on the computation and selection of optical paths (such as ODUk or fgOTN connections) to satisfy the rigorous demands of AI workloads. A C-PS may employ the Path Computation Element Communication Protocol (PCEP) [RFC5440] or PCEP Link-State (PCEP-LS) [I-D.ietf-pce-pcep-ls] with PCEP-LS optical extensions [I-D.lee-pce-pcep-ls-optical] to advertise metrics and synchronize path selection, adhering to the procedures outlined in [RFC9730]. A C-PS can be embedded within CATS-aware OTN edge nodes or implemented as a standalone entity. Typically, a standalone C-PS functions as a part of a centralized controller, such as a Path Computation Element (PCE) [RFC4655] capable of addressing optical constraints.. 3.4.5. CATS Traffic Classifier (C-TC) As described in [I-D.ietf-cats-framework], the CATS Traffic Classifier (C-TC) is a functional entity responsible for mapping incoming client signals or packets to their respective service requests. Within CATS-aware OTN, the C-TC identifies traffic through physical ports, VLAN tags, or specific Service IDs, ensuring these flows are encapsulated into the appropriate optical containers (e.g., ODUk/fgOTN) as directed by the C-PS. C-TCs are generally situated within CATS-aware OTN edge nodes (acting as Ingress CATS-aware OTN edge nodes). Zhao, et al. Expires 1 September 2026 [Page 9] Internet-Draft CATS for OTN February 2026 3.4.6. CATS-Aware OTN Edge Nodes Ingress CATS-aware OTN edge nodes are tasked with directing service- specific traffic along a path determined by the CATS framework. In the context of this document, these are CATS-aware OTN edge nodes that encapsulate client signals into deterministic optical pipes. Egress CATS-aware OTN edge nodes function as the exit points for service requests by decapsulating the optical containers back into their original client formats. Within a CATS-aware OTN infrastructure, these CATS-aware OTN edge nodes execute wavelength or timeslot cross-connections at the physical and link layers. This ensures the zero-jitter and high- bandwidth transmission essential for the synchronization of AI clusters. 3.4.7. Underlay Infrastructure The "underlay infrastructure" depicted in Figure 2 of [I-D.ietf-cats-framework] represents an OTN and optical network (which may include WDM layers) that does not inherently need to be CATS-aware. The CATS-specific paths determined by a C-PS are distributed to the CATS-aware OTN edge nodes, ensuring that the underlying optical nodes (such as P-nodes) remain unaffected by CATS- level steering. 4. CATS-Aware OTN Workflow The following subsections outline an operational workflow for CATS- aware OTN. To activate CATS within a specific domain, certain provisioning steps are required, as detailed in Section 5.1. Furthermore, Section 5.3 explores various deployment strategies (including distributed, centralized, and hybrid architectures) to suit different operational environments. 4.1. Service Announcement A service provider assigns a unique identifier, known as a CS-ID, to each service. Within CATS-aware OTN, the service announcement procedure facilitates the alignment of service demands with deterministic optical resources. The service provider or the controller links the CS-ID with particular ingress CATS-aware OTN edge nodes to ensure that traffic is accurately identified and encapsulated into the relevant optical containers (e.g., ODUk/fgOTN). Zhao, et al. Expires 1 September 2026 [Page 10] Internet-Draft CATS for OTN February 2026 4.2. Metrics Distribution As outlined in Section 3.4, a C-SMA gathers computing capabilities and performance metrics, linking them to the service-specific CS-ID. The C-SMA is responsible for either aggregating these metrics across multiple service contact instances or maintaining individual records for each, or a combination of both approaches. Given that computing metrics often fluctuate rapidly (as discussed in Section 5.3 of [I-D.ietf-cats-usecases-requirements]), the frequency of their distribution is defined by the specific communication protocol employed. Potential update mechanisms include interval- based, threshold-triggered, or policy-driven updates, as well as the use of normalized metrics to ensure stability. Furthermore, the C-NMA is responsible for collecting optical network- layer capabilities and metrics. This information may be disseminated using PCEP-LS for optical networks [I-D.lee-pce-pcep-ls-optical], which may require extensions to support additional optical parameters such as link latency, OSNR, and wavelength availability. By distributing these optical metrics to C-PSes, the system enables them to evaluate both service and network conditions to identify the optimal Egress CATS-aware OTN edge node for servicing a request. Consistent with computing metrics, optical network data can be distributed through centralized, distributed, or hybrid frameworks, the specifics of which remain deployment-dependent. Optical network state may also vary over time. To avoid excessive control plane overhead or flooding, a ttol such as PCEP-LS for optical networks [I-D.lee-pce-pcep-ls-optical] can utilize existing mechanisms to manage state change notifications. Similar to C-SMAs, C-NMAs should be configured with specific triggers or intervals to regulate when updates are reported to the C-PSes. 4.3. Service Access Processing Based on the service and optical network metrics advertised to the C-PS (for example, via PCEP-LS for optical networks [I-D.lee-pce-pcep-ls-optical], a C-PS identifies the optimal paths to the relevant CATS-aware OTN edge nodes (acting as egress points). The C-PS may be integrated into an Ingress CATS-aware OTN edge node (as illustrated in Figure 3 of [I-D.ietf-cats-framework]) or operate as a logically centralized entity, consistent with the centralized or hybrid models discussed in Section 5.3. In the scenario depicted in Figure 3 of [I-D.ietf-cats-framework], a client initiates a service request through CATS-aware OTN edge node 1, which serves as the Ingress CATS-aware OTN edge node. Such Zhao, et al. Expires 1 September 2026 [Page 11] Internet-Draft CATS for OTN February 2026 service requests may involve high-bandwidth data flows (e.g., RDMA or Ethernet) identified by VLAN tags or specific physical ports that convey the CS-ID and associated parameters. Upon identifying a matching classification entry via the C-TC, the Ingress CATS-aware OTN edge node maps and encapsulates the incoming signals into an Optical Data Unit (ODUk) or fine-grain OTN (fgOTN) container, as defined in [ITU-T-G-709]. This encapsulated traffic is subsequently steered toward the Egress CATS-aware OTN edge node selected by the C-PS, following the optical path established through PCEP. Once these optical containers arrive at the Egress CATS-aware OTN edge node, the ODUk/fgOTN overhead is stripped away (via decapsulation/demapping per [ITU-T-G-709]), allowing the original client signals to be delivered to the designated service contact instance. 4.4. Service Contact Instance Affinity Service contact instance affinity requires that all packets or signals constituting a flow for a given service request are consistently routed to the same service contact instance. Additionally, such traffic should follow a uniform path to prevent packet mis-ordering and avoid the introduction of jitter or unpredictable latency. Within a CATS-aware OTN environment, this path consistency is fundamentally maintained through the use of dedicated optical channels which provide a circuit-switched infrastructure that inherently eliminates reordering and guarantees deterministic performance. Any CATS framework implementation for OTN must ensure that both the service instance selection and the subsequent path steering remain stable for the duration of a flow. Specifically, the traffic must be directed through the same Egress CATS-aware OTN edge node. Maintaining service affinity is a capability that can be provisioned on the C-PS during service deployment (applying to all associated flows) or assigned dynamically when a new service request is initiated (applying to a specific flow). Zhao, et al. Expires 1 September 2026 [Page 12] Internet-Draft CATS for OTN February 2026 It should be noted that the definition of a 'flow' may vary across different services. In a CATS-aware OTN infrastructure, a flow can be identified using physical or link-layer attributes as defined in [ITU-T-G-709], such as a designated port or a specific ODUk/fgOTN timeslot. Therefore, any protocol designed to convey affinity information to the C-TC should provide flexible flow identification mechanisms. More broadly, there must be a way to define and recognize the specific set of signals or packets that require affinity. Crucially, the criteria for flow identification should remain application-independent to prevent the proliferation of service- specific affinity methods. Nonetheless, affinity parameters (such as identification types, methods, and timeout values) may be configurable on a per-service basis, adhering to the mapping and policy frameworks of [ITU-T-G-709]. This document does not specify the particular mechanisms used to define or enforce service contact instance affinity. 5. Operational Considerations 5.1. Provisioning of CATS Components The deployment of CATS within an OTN can be achieved through an incremental approach. It is not mandatory for all CATS-aware OTN edge nodes (such as Terminal Muxes) to be upgraded simultaneously. Support for CATS awareness may be restricted to specific CATS-aware OTN edge nodes. For example, CATS capabilities could be prioritized on CATS-aware OTN edge nodes that interconnect AI computing data centers (DCI nodes), while the remaining intermediate nodes maintain transparent transport. Beyond the CATS steering policies transmitted by a C-PS to an Ingress CATS-aware OTN edge node, several provisioning actions are necessary. These tasks include, but are not limited to: * Locating Ingress Entities: Supplying C-PS elements with the locators of available Ingress CATS-aware OTN edge nodes (e.g., node identifiers or termination points). These locators may also be dynamically discovered from the network topology via the optical control plane. * Agent Connectivity: Providing the necessary information to establish communication between C-PS elements, C-NMAs, and C-SMAs. * Identifier Management: Assigning CS-ID/CSCI-ID identifiers and associating them with particular service contact instances. Zhao, et al. Expires 1 September 2026 [Page 13] Internet-Draft CATS for OTN February 2026 * Policy Definition: Configuring C-PS elements with service-specific optimization metrics and policies, emphasizing latency determinism, bandwidth rigidity, and optical-layer availability to meet the requirements of (for example) AI training tasks. * Traffic Mapping: Configuring the mapping and multiplexing functions of CATS-aware OTN edge nodes, such as allocating AI traffic to designated wavelengths or ODUk/fgOTN timeslots to ensure physical isolation. This also includes credentials for mutual authentication between peer CATS-aware OTN edge nodes. * Classifier Initialization: Clearing or updating the classification tables within C-TC elements. * Monitoring and Correlation: Initializing traffic counters and performance monitoring (PM) parameters at CATS-aware OTN edge nodes to facilitate correlation between Ingress and Egress CATS- aware OTN edge nodes. This correlation is essential for identifying performance degradations in the underlying optical transport layer, utilizing the native OAM mechanisms of OTN for end-to-end delay and error-rate monitoring. Provisioning encompasses both static configuration and dynamic distribution via protocols. These tasks can be implemented through various mechanisms, such as NETCONF [RFC6241], IPFIX [RFC7011], RESTCONF [RFC8040], or YANG-Push [RFC8639]. Detailed discussion of specific CATS extensions for these protocols is beyond the scope of this document. 5.2. Supervision of CATS Components and CATS OAM Complementary supervision and OAM mechanisms are essential to guide CATS provisioning and evaluate the effectiveness of CATS operations. Key requirements include: * Capabilities Exposure: Reporting the classification features of C-TC elements (e.g., identifying AI traffic through designated physical ports or VLAN tags for traffic mapping). * Mapping Capabilities: Identifying the mapping and multiplexing functions supported by CATS-aware OTN edge nodes, adhering to the frameworks established in [ITU-T-G-709]. * State Retrieval: Accessing the active classification and mapping tables from C-TC elements. * Forwarding Rules: Retrieving current cross-connect and timeslot assignment configurations within CATS-aware OTN edge nodes. Zhao, et al. Expires 1 September 2026 [Page 14] Internet-Draft CATS for OTN February 2026 * Policy Auditing: Extracting the active policies currently residing in C-PSes. * Performance Monitoring: Collecting OTN performance monitoring (PM) data (such as Bit Error Rate (BER), Pre-FEC/Post-FEC status, and wavelength power) from CATS-aware OTN edge nodes to simplify operational correlation between Ingress and Egress CATS-aware OTN edge nodes. * Hardware-level Verification: Utilizing hardware-based OAM tools (e.g., OTN Overhead and Tandem Connection Monitoring (TCM)) to verify the integrity of various functional entities, including classification, cross-connect, and forwarding behaviors. In contrast to packet-based OAM, OTN OAM leverages dedicated frame overhead, which prevents any impact on service traffic. Refer to Section 5.5. * Deterministic Measurement: Implementing OAM tools focused on deterministic performance, specifically for high-precision monitoring of latency and jitter. 5.3. Deployment Considerations This document remains agnostic regarding the specific implementation and deployment of CATS-aware OTN functional entities. In practice, whether a CATS architecture adopts a fully decentralized design or utilizes a combination of centralized (e.g., a centralized C-PS) and distributed components (e.g., C-TCs) is a deployment-specific decision. Within a CATS-aware OTN infrastructure, this typically necessitates coordination between Customer Network Controllers (CNCs) and Physical Network Controllers (PNCs) as outlined in the ACTN framework [RFC8453]. Furthermore, specific use cases [I-D.ietf-cats-usecases-requirements] may influence the chosen deployment strategy. For instance, in a centralized architecture, a logically centralized path computation entity (such as a PCE or an ACTN MDSC) aggregates both computing metrics from C-SMAs and network performance data. In this scenario, the path computation logic processes service requests to determine the optimal paths to service contact instances. For workloads involving high-bandwidth and long-duration flows (such as AI training), paths and optical channels (e.g., ODUk/fgOTN) may be pre-provisioned to guarantee zero packet loss and immediate service availability. The C-PS then identifies the most suitable path based on current metrics and synchronizes these decisions with the C-TCs. Zhao, et al. Expires 1 September 2026 [Page 15] Internet-Draft CATS for OTN February 2026 Depending on the distribution and collection mechanisms for computing metrics, the CATS framework supports three primary deployment models as set out in [I-D.ietf-cats-framework]. In a CATS-aware OTN context, these can be re-stated as follows: * Distributed model: In this model, the service scheduling function is executed by the CATS-aware OTN edge nodes; consequently, the C-PS is integrated within an Ingress CATS-aware OTN edge node. * Centralized model: Centralized control entities (e.g., CNC or MDSC) collect all computing metrics and compute forwarding paths for service requests via PCEP and synchronize with the Ingress CATS-aware OTN edge nodes. Here, the C-PS resides within the centralized controller. * Hybrid model: This model integrates elements of both distributed and centralized architectures. In the hybrid approach, some computing metrics are shared among network devices while others are gathered by a centralized controller. For example, static optical parameters (such as fiber distance, Shared Risk Link Groups (SRLG), or maximum port capacity) may be distributed among network devices due to their stability. Conversely, highly dynamic information (such as GPU resource utilization, wavelength availability, or optical power fluctuations) is centralized to prevent excessive flooding within the distributed control plane. Service scheduling may be performed by a centralized controller, Ingress CATS-aware OTN edge nodes (co-located with a C-PS), or both, based on local policies. When path computation is distributed, centralized entities must communicate collected path information to the Ingress CATS-aware OTN edge nodes (co-located with a C-PS) to ensure the full metric set is considered for scheduling. 5.4. Implementation Considerations on Using CATS Metrics [I-D.ietf-cats-framework] observes the scaling concerns when distributing computing-related metrics. Within CATS-aware OTN infrastructure, normalization of metrics is important for managing heterogeneous hardware accelerators, such as GPUs, NPUs, or FPGAs. These normalized computing scores can then be correlated with OTN-specific network resources (including available ODUk/fgOTN timeslots or bandwidth) to create a composite metric for path selection. For further discussion on metrics and their distribution, refer to [I-D.ietf-cats-metric-definition]. Zhao, et al. Expires 1 September 2026 [Page 16] Internet-Draft CATS for OTN February 2026 The placement of normalization and aggregation functions depends on the available processing capacity of the CATS components. One strategy is to host these functions away from C-PSes, particularly when C-PSes are integrated into CATS-aware OTN edge nodes. Consequently, these functions may be situated at service contact instances, C-SMAs, or specialized computing gateways interfaced with the OTN ingress. In scenarios where C-SMAs are co-located with CATS-aware OTN edge nodes that have limited processing power, implementing normalization within the C-SMA may generate excessive overhead and degrade the efficiency of metric distribution (for example via PCEP-LS optical extensions [I-D.lee-pce-pcep-ls-optical]. Therefore, this document recommends performing normalization at the service contact instances. Aggregation functions, however, may reside in either the C-SMA or the service contact instances. To maintain consistency in CATS path selection, all participating CATS components must utilize identical normalization and aggregation functions. Furthermore, in environments involving multiple vendors or where service contact instances and C-SMAs are provided by different parties, a standardized set of common functions is necessary to ensure fair selection across all instances. To this end, these functions must be standardized, potentially leveraging YANG models compatible with ACTN PNC/CNC architectures. CATS implementations must provide a configuration parameter to manage and activate these specific functions in contexts where multiple versions are supported. 5.5. Verifying Correct Operations A CATS implementation must maintain logs of error events (such as light-path switching failures, wavelength conflicts, or computing resource downtime) to facilitate enhanced network management and operations. Mechanisms to evaluate reachability and perform CATS path tracing should be provided. Within a CATS-aware OTN infrastructure, reachability assessment utilizes hardware-level monitoring of end-to-end optical or electrical trails. The operational status of a CATS path can be verified in real-time using ODUk/fgOTN maintenance signals (e.g., Alarm Indication Signal (AIS) or Locked (LCK) signals) as specified in [ITU-T-G-709], thereby removing the requirement for active probe packets. Additionally, path tracing is supported by the Trail Trace Identifier (TTI) within the OTN frame overhead. This enables the physical verification that traffic is traversing the exact sequence of nodes Zhao, et al. Expires 1 September 2026 [Page 17] Internet-Draft CATS for OTN February 2026 as determined by the C-PS. Such verification data should be synchronized with the PNC or CNC to maintain alignment between the control plane steering policies and the actual state of the data plane. 5.6. Impact on Network Operations The collection and distribution of computing metrics within the CATS framework necessitate a management function to coordinate interactions between network and computing resources. This role can be fulfilled by an orchestrator, such as a Customer Network Controller (CNC) or a Multi-Domain Service Coordinator (MDSC) within the ACTN framework [RFC8453], which interfaces with both the C-SMA and C-NMA. Utilizing existing optical control hierarchies in this manner minimizes the requirement for entirely new functional entities. While introducing this coordination function may increase network management complexity (particularly if it is exclusively dedicated to CATS) this is balanced by the superior determinism offered by the OTN layer for workloads. In contrast to connectionless IP networks, CATS-aware OTN is connection-oriented. Once computing-aware paths are provisioned (for example, through PCEP-LS mechanisms for optical networks [I-D.lee.pce-pcep-ls-optical]) operational efforts transition from addressing routing oscillations to maintaining stable, high-bandwidth "hard-isolations." This approach greatly streamlines the supervision of long-duration traffic flows, such as for AI training traffic. Additionally, the CNC can act as a Northbound interface for external computing platforms, such as AI job schedulers, to enable coordinated resource allocation. This allows the CATS-aware OTN infrastructure to adapt reliably to the specific latency and topological demands of, for example, distributed AI clusters. 6. IANA Considerations This document does not make any requests of IANA. 7. Security Considerations Computing resource information is highly dynamic, fluctuating rapidly as service instances are initialized or terminated. If this information is disseminated via a distribution protocol (such as PCEP-LS for optical networks [I-D.lee.pce-pcep-ls-optical], an excessive volume of updates can undermine network stability. An attacker might exploit this vulnerability by rapidly creating and deleting service instances to trigger instability. Consequently, Zhao, et al. Expires 1 September 2026 [Page 18] Internet-Draft CATS for OTN February 2026 CATS solutions must implement safeguards against such behavior, including aggregation techniques, dampening mechanisms, and threshold-triggered updates. Within CATS-aware OTN, where path setup is resource-intensive, the architecture should incorporate a "computing fluctuation window." This ensures that optical layer reconfigurations are only initiated by significant or sustained shifts in compute metrics. The data distributed by C-SMAs and C-NMAs is often sensitive, as it may reveal network intelligence, the precise topology of GPU clusters, and the specific locations of compute resources within service sites. Attackers could leverage this data to pinpoint vulnerabilities in a provider's infrastructure. Furthermore, unauthorized modification of this information could disrupt service delivery or redirect traffic to malicious service instances. CATS- aware OTN provides a distinct security advantage by supporting Layer 1 physical layer encryption (e.g., OTN-SEC). This provides high- throughput security for data flows without the header overhead or latency increases typical of higher-layer encryption like IPsec, which is vital for the performance of latency-sensitive AI training. CATS implementations must provide robust authentication and integrity protection between C-SMAs/C-NMAs and C-PSes, as well as between C-PSes and Ingress CATS-aware OTN edge nodes. In an ACTN-based environment, stringent mutual authentication is required between the PNC/CNC and the CATS-aware OTN edge nodes to prevent unauthorized changes to optical cross-connects or timeslot allocations. Additionally, C-SMAs must have mechanisms to authenticate the services for which they provide data to the C-PS selection logic. This document is restricted to a single service provider scenario. The centralized architecture of the OTN control plane within a single domain facilitates a closed management loop, effectively minimizing the external attack surface. Therefore, security issues specific to multi-provider deployments are considered out of scope. 8. Privacy Considerations CATS solutions are required to prevent on-path nodes within the underlay infrastructure from performing client fingerprinting or tracking (e.g., identifying which client is accessing a particular service). Generally, the CATS framework must ensure that personal data is not disclosed to external parties, exceeding the information already present in the original packets transmitted by the client. Within a CATS-aware OTN infrastructure, privacy is naturally bolstered by the use of Layer 1 rigid "Hard-isolations." Because intermediate elements (such as Optical Amplifiers) function at the Zhao, et al. Expires 1 September 2026 [Page 19] Internet-Draft CATS for OTN February 2026 physical layer, they are unable to inspect the payload of the encapsulated traffic. This transparency at the physical layer ensures that on-path nodes cannot perform traffic analysis or track application behavior through packet header inspection. In certain scenarios, a CATS solution might require knowledge of specific applications, clients, or user identities. Such sensitive data must be protected via encryption. To mitigate the risk of information leakage among CATS components, path information computed by the C-PS and specific mapping instructions (such as ODUk/fgOTN timeslot assignments) should be encrypted during distribution. For instance, communication between the PNC/CNC and CATS-aware OTN edge nodes should be protected using secure southbound protocols like NETCONF over TLS or RESTCONF. The choice of encryption-whether at the network, transport, or application layer-is implementation- dependent and remains outside the scope of this document. This document is restricted to a single service provider environment. Consequently, privacy issues related to multi-provider deployments are not addressed here. For further details on privacy, refer to [RFC6462] and [RFC6973]. 9. Acknowledgements The authors wish to acknowledge Adrian Farrel for helpful discussions. 10. References 10.1. Normative References [I-D.ietf-cats-framework] Li, C., Du, Z., Boucadair, M., Contreras, L. M., and J. Drake, "A Framework for Computing-Aware Traffic Steering (CATS)", Work in Progress, Internet-Draft, draft-ietf- cats-framework-20, 26 February 2026, . [I-D.ietf-cats-usecases-requirements] Yao, K., Contreras, L. M., Shi, H., Zhang, S., and Q. An, "Computing-Aware Traffic Steering (CATS) Problem Statement, Use Cases, and Requirements", Work in Progress, Internet-Draft, draft-ietf-cats-usecases-requirements-14, 2 February 2026, . Zhao, et al. Expires 1 September 2026 [Page 20] Internet-Draft CATS for OTN February 2026 [ITU-T-G-709] ITU-T, "G.709 - Interfaces for the optical transport network", June 2020, . [RFC6462] Cooper, A., "Report from the Internet Privacy Workshop", RFC 6462, DOI 10.17487/RFC6462, January 2012, . [RFC6973] Cooper, A., Tschofenig, H., Aboba, B., Peterson, J., Morris, J., Hansen, M., and R. Smith, "Privacy Considerations for Internet Protocols", RFC 6973, DOI 10.17487/RFC6973, July 2013, . [RFC8453] Ceccarelli, D., Ed. and Y. Lee, Ed., "Framework for Abstraction and Control of TE Networks (ACTN)", RFC 8453, DOI 10.17487/RFC8453, August 2018, . 10.2. Informative 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-05, 2 February 2026, . [I-D.ietf-pce-pcep-ls] Dhody, D., Peng, S., Lee, Y., Ceccarelli, D., Wang, A., and G. S. Mishra, "PCEP extensions for Distribution of Link-State and TE Information", Work in Progress, Internet-Draft, draft-ietf-pce-pcep-ls-04, 14 October 2025, . [I-D.lee-pce-pcep-ls-optical] Zhao, Y., Ceccarelli, D., LiXiao, Yoon, B. Y., and A. Farrel, "PCEP Extensions for Distribution of Link-State and TE Information for Optical Networks", Work in Progress, Internet-Draft, draft-lee-pce-pcep-ls-optical- 17, 7 February 2026, . [I-D.lee.pce-pcep-ls-optical] "*** BROKEN REFERENCE ***". Zhao, et al. Expires 1 September 2026 [Page 21] Internet-Draft CATS for OTN February 2026 [RFC4655] Farrel, A., Vasseur, J.-P., and J. Ash, "A Path Computation Element (PCE)-Based Architecture", RFC 4655, DOI 10.17487/RFC4655, August 2006, . [RFC5440] Vasseur, JP., Ed. and JL. Le Roux, Ed., "Path Computation Element (PCE) Communication Protocol (PCEP)", RFC 5440, DOI 10.17487/RFC5440, March 2009, . [RFC6241] Enns, R., Ed., Bjorklund, M., Ed., Schoenwaelder, J., Ed., and A. Bierman, Ed., "Network Configuration Protocol (NETCONF)", RFC 6241, DOI 10.17487/RFC6241, June 2011, . [RFC7011] Claise, B., Ed., Trammell, B., Ed., and P. Aitken, "Specification of the IP Flow Information Export (IPFIX) Protocol for the Exchange of Flow Information", STD 77, RFC 7011, DOI 10.17487/RFC7011, September 2013, . [RFC7471] Giacalone, S., Ward, D., Drake, J., Atlas, A., and S. Previdi, "OSPF Traffic Engineering (TE) Metric Extensions", RFC 7471, DOI 10.17487/RFC7471, March 2015, . [RFC8040] Bierman, A., Bjorklund, M., and K. Watsen, "RESTCONF Protocol", RFC 8040, DOI 10.17487/RFC8040, January 2017, . [RFC8570] Ginsberg, L., Ed., Previdi, S., Ed., Giacalone, S., Ward, D., Drake, J., and Q. Wu, "IS-IS Traffic Engineering (TE) Metric Extensions", RFC 8570, DOI 10.17487/RFC8570, March 2019, . [RFC8571] Ginsberg, L., Ed., Previdi, S., Wu, Q., Tantsura, J., and C. Filsfils, "BGP - Link State (BGP-LS) Advertisement of IGP Traffic Engineering Performance Metric Extensions", RFC 8571, DOI 10.17487/RFC8571, March 2019, . [RFC8639] Voit, E., Clemm, A., Gonzalez Prieto, A., Nilsen-Nygaard, E., and A. Tripathy, "Subscription to YANG Notifications", RFC 8639, DOI 10.17487/RFC8639, September 2019, . Zhao, et al. Expires 1 September 2026 [Page 22] Internet-Draft CATS for OTN February 2026 [RFC9730] Zheng, H., Lin, Y., Zhao, Y., Xu, Y., and D. Beller, "Interworking of GMPLS Control and Centralized Controller Systems", RFC 9730, DOI 10.17487/RFC9730, March 2025, . Contributors Minxue Wang China Mobile Email: wangminxue@chinamobile.com Authors' Addresses Yang Zhao China Mobile China Email: zhaoyangyjy@chinamobile.com LiuYan Han China Mobile China Email: hanliuyan@chinamobile.com Xiao Li Huawei China Email: lixiao33@huawei.com Haomian Zheng Huawei China Email: zhenghaomian@huawei.com Daniel King Old Dog Consulting United Kingdom Email: daniel@olddog.co.uk Zhao, et al. Expires 1 September 2026 [Page 23]