CATS B. Zhang, Ed. Internet-Draft Pengcheng Laboratory Intended status: Standards Track Y. Dai, Ed. Expires: 26 February 2027 Sun Yat-sen University Z. Du, Ed. China Mobile G. Zeng Huawei Technologies C. Miao, Ed. ZTE Corporation 25 August 2026 Computing Service Metric Definitions and Operation under CATS draft-zhangb-cats-service-metrics-op-04 Abstract Computing-Aware Traffic Steering (CATS) optimizes traffic forwarding by considering both computing and networking metrics. While existing framework and metric definition drafts provide theoretical models (e.g., L1/L2 normalized metrics), they face significant challenges in achieving direct operational execution in real-world deployments. Normalization methods vary across providers, and aggregated unitless scores often lose critical operational information, making it difficult for routers to make precise traffic-steering decisions. This document fills this gap by providing an executable operational approach. It defines a set of Computing Service Metrics and their operations under the CATS framework. Instead of transmitting low- level raw hardware metrics, service sites dynamically evaluate and report service-oriented metrics (e.g., Global Available Slots) to the control plane. The document clarifies how such service-oriented metrics can be derived from basic resource information, service reference information, and local policy. It also specifies how the CATS Path Selector (C-PS) combines the Computing Service Table (derived from C-SMA reports) with the Network Service Table to make joint traffic-steering decisions. Finally, the document defines update control mechanisms for large-scale deployments. This enables efficient and precise traffic-steering policies without negating the value of existing normalized metrics. Status of This Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Zhang, et al. Expires 26 February 2027 [Page 1] Internet-Draft CATS Service Metrics Operation August 2026 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 26 February 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 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 3. Motivation and Problem Statement . . . . . . . . . . . . . . 5 4. Service Information and Metrics Definition . . . . . . . . . 6 4.1. Derivation from Basic and Reference Information . . . . . 6 4.2. Mandatory Computing Service Information . . . . . . . . . 7 4.2.1. Global Available Slots (GAS) . . . . . . . . . . . . 7 4.2.2. Computing Time . . . . . . . . . . . . . . . . . . . 8 4.3. Optional Extension Metrics . . . . . . . . . . . . . . . 8 4.3.1. Cost . . . . . . . . . . . . . . . . . . . . . . . . 8 4.3.2. Reputation . . . . . . . . . . . . . . . . . . . . . 9 4.3.3. Security Label . . . . . . . . . . . . . . . . . . . 9 4.3.4. Capability (L1/L2 Compatibility) . . . . . . . . . . 10 5. Operation under CATS Framework . . . . . . . . . . . . . . . 10 5.1. Dynamic Metric Reporting . . . . . . . . . . . . . . . . 10 5.2. Joint Decision: Computing Service Table and Network Service Table . . . . . . . . . . . . . . . . . . . . . . . . . . 11 5.2.1. Computing Service Table Structure . . . . . . . . . . 11 5.2.2. Network Service Table Structure . . . . . . . . . . . 11 5.2.3. Joint Selection Algorithm . . . . . . . . . . . . . . 13 Zhang, et al. Expires 26 February 2027 [Page 2] Internet-Draft CATS Service Metrics Operation August 2026 5.2.4. Multi-Objective Optimization and Constraints . . . . 16 5.2.5. Fallback and Re-routing Policies . . . . . . . . . . 18 6. Use Case: Joint Service Selection and Path Computation . . . 19 6.1. Service Distribution and Table Formation . . . . . . . . 19 6.2. Scenario A: Normal Operation with Balanced Load . . . . . 21 6.3. Scenario B: Network Congestion Impact . . . . . . . . . . 22 6.4. Scenario C: Service Site Degradation and Failover . . . . 23 6.5. Scenario D: Multi-Objective Optimization with Cost Constraint . . . . . . . . . . . . . . . . . . . . . . . 24 7. Update Control in Large-Scale Deployments . . . . . . . . . . 26 8. Security Considerations . . . . . . . . . . . . . . . . . . . 27 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 28 9.1. CATS Computing Service Metrics Registry . . . . . . . . . 28 10. Informative References . . . . . . . . . . . . . . . . . . . 29 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 31 1. Introduction The Computing-Aware Traffic Steering (CATS) [I-D.ietf-cats-framework-24] architecture aims to steer service traffic to the most suitable service contact instance by evaluating both network state and computing resource availability. To achieve this, CATS Service Metric Agents (C-SMAs) collect computing metrics and advertise them to CATS Path Selectors (C-PSes). [I-D.ietf-cats-metric-definition-10] introduces a multi-level metric framework (Level 0, Level 1, Level 2) and proposes normalizing heterogeneous computing metrics into unitless scores (e.g., compute_norm). While this establishes a solid theoretical baseline, mapping diverse hardware capabilities (CPUs, GPUs, NPUs) into a single normalized score is highly complex and provider-dependent. In practice, additional service-oriented abstractions are useful for expressing the actual service capacity needed for fine-grained traffic steering. To fill the gap between theoretical metric definitions and practical implementation, this document introduces a set of Computing Service Metrics. By decoupling the service capacity from hardware-specific raw metrics, service sites can directly expose actionable metrics that describe their concrete ability to handle specific services. These metrics complement the existing normalized metric framework and focus on operational use under the CATS architecture. Another key contribution of this document is the specification of how the C-PS combines the Computing Service Table (built from C-SMA reports) with the Network Service Table to make joint traffic- steering decisions that simultaneously optimize computing and network performance. Zhang, et al. Expires 26 February 2027 [Page 3] Internet-Draft CATS Service Metrics Operation August 2026 2. Terminology This document makes use of the terms defined in [I-D.ietf-cats-framework-24] and [I-D.ietf-cats-metric-definition-10]. In particular, CS-ID and CSCI- ID are used as CATS identifiers. They provide stable service and service-contact-instance references for lookup and forwarding, but are not treated as computing metrics in this document. Additionally, the following terms are used: * 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. * CS-ID (CATS Service ID): An identifier for a service. It is used as a stable lookup key in the C-PS Computing Service Table. * CSCI-ID (CATS Service Contact Instance ID): An identifier for contact information of a service instance that provides a specific CS-ID at a service site. In this document, it is interpreted operationally as a locator, such as an IP address and port number, used to establish the data tunnel. * Computing Service Table (CST): A data structure maintained by the C-PS that contains computing-oriented metrics (GAS, Computing Time, etc.) indexed by CS-ID and CSCI-ID. It is populated from C-SMA reports. * Network Service Table (NST): A data structure maintained by the C-PS that contains network-oriented metrics (delay, jitter, bandwidth, etc.) indexed by network path identifiers. In an SDN context, it can be derived from the Traffic Engineering Database (TEDB). * Total Service Time (TST): The sum of Computing Time and network delay (Ingress-to-Egress), used as the primary optimization objective in the joint selection algorithm. * 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. Zhang, et al. Expires 26 February 2027 [Page 4] Internet-Draft CATS Service Metrics Operation August 2026 3. Motivation and Problem Statement The CATS working group has made significant progress in defining how computing metrics should be collected and distributed. In particular, existing works introduce a comprehensive framework that categorizes computing metrics into Raw Metrics (Level 0) and Normalized Metrics (Level 1 and Level 2). However, a critical gap remains: how exactly to use these hardware-centric metrics to effectively steer traffic in operational networks. This document does not negate the value of L1/L2 normalized metrics; rather, it identifies that relying solely on the normalization of raw hardware metrics poses operational challenges during routing execution: 1. The Implementation Gap (HOW to normalize?): In a real-world multi-vendor network, computing resources are highly heterogeneous. It is extremely difficult to establish a unified mathematical model that fairly normalizes a GPU's capacity and a CPU's capacity into the same 0-10 score. 2. The Information Loss Gap (WHY disseminate raw features?): Normalizing diverse hardware capabilities into a single unitless score results in the loss of actionable information. A normalized compute score of "7" cannot explicitly guarantee a client's <10 ms delay requirement. 3. The Routing Mechanism Gap (WHO uses this data?): Routers (C-PS) do not need to know whether a service is backed by a CPU or a GPU. They only care about routing parameters: "Is there capacity?", "How long will it take?", and "Where is the destination?". 4. The Joint Decision Gap (HOW to combine?): Even when both computing metrics and network metrics are available, existing drafts do not specify how the C-PS should combine them to make a unified steering decision. Simply selecting the service site with the best computing metrics may result in a poor network path, and vice versa. To bridge these gaps, CATS requires a Service-Oriented Abstraction and a clear Joint Selection Algorithm. We explicitly divide the required service information into Mandatory Computing Service Metrics and Optional Extension Metrics, and we specify how the C-PS combines the Computing Service Table with the Network Service Table to support executable traffic-steering policies. Zhang, et al. Expires 26 February 2027 [Page 5] Internet-Draft CATS Service Metrics Operation August 2026 4. Service Information and Metrics Definition This section defines the service information used by CATS control- plane components. Some fields are identifiers or locators, while others are service-oriented metrics. Metric examples follow the structural guidelines specified in Section 4.1 of [I-D.ietf-cats-metric-definition-10]. This document focuses on the semantics and operational use of these metrics, rather than defining new routing, transport, signaling, or wire-encoding mechanisms. 4.1. Derivation from Basic and Reference Information The Computing Service Metrics defined in this document are service- oriented metrics. They are estimations produced by each service site based on local monitoring and deployment policy. This allows heterogeneous hardware details and frequent local resource changes to be hidden from the CATS control plane while still exposing actionable information for traffic steering. These metrics can be derived from basic resource metrics, status metrics, service requirements, and local policy at the service site. The public service platform described in [I-D.zhangb-cats-cmas-04] can provide reference information, such as Computing Requirement, Storage Requirement, Reference Computing Time, software dependency, and Reference GAS, that a service site can use when deploying a service. For example, if the resources allocated to a service instance just meet the listed Computing Requirement and Storage Requirement, the service site can use the Reference GAS as a starting value. If more resources are allocated, the reported GAS is evaluated by the service site and is generally expected to be larger than the Reference GAS. Similarly, Computing Time can be measured or estimated based on the runtime behavior of the deployed service instance. The specific derivation algorithm is a local matter and is not standardized by this document. The basic field examples in Section 4.2 and Section 4.3 provide recommended data types, lengths, and units as guidance for protocols that carry these metrics (e.g., BGP-LS extensions or RESTful APIs). This document does not mandate a specific wire format; the exact encoding is a matter for the protocol or transport mechanism used between the C-SMA and the C-PS. Zhang, et al. Expires 26 February 2027 [Page 6] Internet-Draft CATS Service Metrics Operation August 2026 4.2. Mandatory Computing Service Information These fields are essential for the C-PS to make fundamental traffic steering decisions. CS-ID and CSCI-ID are identifiers, while GAS and Computing Time are service-oriented metrics. 4.2.1. Global Available Slots (GAS) GAS is the core contribution of this metric framework. It represents the maximum number of concurrent requests/sessions that a service site is willing and able to serve for a specific CS-ID through a specific CSCI-ID at a given time. Crucially, GAS acts as a direct abstraction layer over the complex and fluctuating raw computing metrics (CPU, GPU, Memory, Storage) and status metrics (load and health). Instead of exposing highly dynamic raw metrics to the network, the service site absorbs these variations internally. The site can initially provide a GAS value based on its fixed resource allocation and service reference information, and then adjust it according to local policy based on internal status metrics. As the number of concurrent requests increases, the GAS value naturally decreases. Furthermore, the site monitoring system dynamically reduces the GAS value upon detecting abnormal status metrics, such as: * Load changes: Sudden increase in internal resources occupied by local users or tasks. * Health changes: Sudden performance drop, possibly due to a cyber attack. * Reachability: The site crashes or becomes unresponsive. Note: The C-SMA proactively reports significant adjustments to the control plane according to local policy, thresholds, or aggregation intervals. Small per-session changes do not necessarily need to be reported immediately. When GAS drops to 0, it means the instance cannot allocate any more resources, and no new requests will be steered to it. Basic fields: Zhang, et al. Expires 26 February 2027 [Page 7] Internet-Draft CATS Service Metrics Operation August 2026 Metric Type: gas Level: Level 0 Format: unsigned integer Length: two octets Value: 500 Source: estimation 4.2.2. Computing Time The time required for the site to perform one service request. The service site can initialize this metric based on service reference information and then measure or estimate it according to the runtime behavior of the deployed service instance. The service site dynamically adjusts this metric based on real-time load and local policy. Computing Time is a critical input to the Joint Selection Algorithm because it represents the processing latency component of the Total Service Time. Basic fields: Metric Type: comp_time Level: Level 0 Format: floating point Length: four octets Unit: ms Value: 5 Source: estimation 4.3. Optional Extension Metrics To accommodate advanced traffic-steering scenarios and maintain backward compatibility, the following optional fields are defined. 4.3.1. Cost Self-defined by the service site to apply administrative or economic billing policies. Cost is used as a constraint or secondary objective in the Joint Selection Algorithm (see Section 5.2.4). Basic fields: Zhang, et al. Expires 26 February 2027 [Page 8] Internet-Draft CATS Service Metrics Operation August 2026 Metric Type: cost Level: Level 0 Format: unsigned integer Length: two octets Value: 100 Source: nominal 4.3.2. Reputation A dynamic quality score based on user feedback. Upon completion, if a user experiences long delays or inaccurate results, feedback is returned to the C-PS *along with the resource release message*. Reputation is used as a tie-breaker or threshold filter in the Joint Selection Algorithm. Basic fields: Metric Type: reputation Level: Level 0 Format: unsigned integer Length: two octets Value: 8 Source: nominal 4.3.3. Security Label The Security Label reflects the security status of a service site. A higher score indicates a more secure site. The Security Label is used as a constraint in the Joint Selection Algorithm: a C-PS MUST NOT select a service contact instance with a Security Label below the client's minimum requirement. Score range: 0-10 (0 indicates the poorest security; 10 indicates optimal security). Basic fields: Metric Type: security_label Level: Level 0 Format: unsigned integer Length: two octets Value: 7 Source: nominal Zhang, et al. Expires 26 February 2027 [Page 9] Internet-Draft CATS Service Metrics Operation August 2026 4.3.4. Capability (L1/L2 Compatibility) To maintain compatibility with L1/L2 normalized metrics, this optional field represents the overall computing and storage capability allocated by the site. It can correspond to a Level 1 or Level 2 overall capability score when such a normalized value is available. Basic fields: Metric Type: site_cap Level: Level 1/Level 2 Format: unsigned integer Length: one octet Source: normalization Value: 7 5. Operation under CATS Framework 5.1. Dynamic Metric Reporting Service sites proactively monitor their internal instances. In large-scale deployments, service sites can use a delta-threshold reporting model. Each service site or C-SMA maintains a local metric cache. Per-session allocation and release events update local GAS values, but do not necessarily trigger immediate reports to the C-PS. Updates are reported when they become operationally significant. Examples include GAS crossing a configured threshold, Computing Time deviating beyond a configured percentage band, or health status changing due to failure, attack detection, or unreachability. A periodic heartbeat or soft-state synchronization can also be used to refresh the C-PS view and avoid stale metrics even when no trigger event occurs. Choosing appropriate protocols for conveying CATS metrics is important. For distributed systems, existing routing protocols such as BGP extensions [RFC4760] and GRASP [RFC8990] may serve as a baseline. However, considering that the CATS working group focuses on single-domain models, centralized approaches are highly suitable. In an SDN context [RFC7149] [RFC7426], the metric agent acts as an application that uses a RESTful API via the northbound interface to report CATS metrics directly to the centralized C-PS (or SDN controller) for centralized decision-making. Zhang, et al. Expires 26 February 2027 [Page 10] Internet-Draft CATS Service Metrics Operation August 2026 5.2. Joint Decision: Computing Service Table and Network Service Table This section specifies the core operational procedure by which the C-PS combines computing metrics and network metrics to select the optimal CSCI-ID for a service request. This joint decision is the central mechanism that enables Computing-Aware Traffic Steering. 5.2.1. Computing Service Table Structure The Computing Service Table (CST) is maintained by the C-PS and is populated from C-SMA reports. It contains one entry per (CS-ID, CSCI-ID) pair. Each entry contains the following fields: +-------------------+------------------------------------------------+ | Field | Description | +-------------------+------------------------------------------------+ | CS-ID | The CATS Service Identifier | | CSCI-ID | The Service Contact Instance locator | | | (e.g., IP:Port) | | GAS | Global Available Slots (uint32) | | Computing Time | Estimated processing time in ms (uint32) | | Cost | Service cost (optional, uint32) | | Reputation | Quality score 0-10 (optional, uint8) | | Security Label | Security score 0-10 (optional, uint8) | | Capability | L1/L2 normalized score (optional) | | Last Updated | Timestamp of last C-SMA report | | Expiry Time | Soft-state expiration time | +-------------------+------------------------------------------------+ The CST is indexed by CS-ID for fast lookup of all candidate CSCI-IDs for a given service. The C-PS MUST age out entries whose Expiry Time has passed, treating them as unreachable (GAS = 0). The CST is logically separate from the Network Service Table to maintain separation of concerns between computing and network domains. 5.2.2. Network Service Table Structure The Network Service Table (NST) is maintained by the C-PS and is populated from C-NMA reports. The NST is a logical data structure maintained by the C-PS, providing a view of network metrics tailored for CATS joint decision. In a SDN context, the NST is derived from the SDN controller's Traffic Engineering Database (TEDB), which aggregates network topology and performance information from the underlay network via protocols such as BGP-LS [RFC8571] or IGP TE extensions [RFC7471] [RFC8570]. Zhang, et al. Expires 26 February 2027 [Page 11] Internet-Draft CATS Service Metrics Operation August 2026 In the reference architecture, the C-PS accesses the NST rather than the raw TEDB, though implementations MAY co-locate these functions. Instead, a NST Generator component performs the following steps: 1. Filtering: Extracts paths relevant to the CATS domain and the set of Egress CATS-Forwarders. 2. Aggregation: Computes path-level metrics (e.g., one-way delay, available bandwidth) from link-level TEDB data. 3. Indexing: Re-indexes the information by (Ingress CF, Egress CF) pair for fast lookup. The NST MAY be cached and periodically refreshed based on TEDB updates, or MAY be generated on-the-fly based on the current TEDB snapshot. The NST contains one entry per (Ingress, Egress) pair, representing the network path from the client's Ingress CATS- Forwarder to the Egress CATS-Forwarder that connects to the service site. The specific implementation is a local matter. Each entry contains the following fields: +-------------------+------------------------------------------------+ | Field | Description | +-------------------+------------------------------------------------+ | Ingress CF | Ingress CATS-Forwarder identifier | | Egress CF | Egress CATS-Forwarder identifier | | Network Delay | One-way delay in ms (uint32) | | Jitter | Delay variation in ms (uint32, optional) | | Bandwidth | Available bandwidth in Mbps (uint32, optional) | | Loss Rate | Packet loss rate in ppm (uint32, optional) | | Path Attributes | TE attributes (e.g., affinity, color) | | Last Updated | Timestamp of last C-NMA report | +-------------------+------------------------------------------------+ The service node may be outside the ingress domain, so this document does not require measuring delay directly from the ingress to the service node. Instead, the Network Delay represents the path from the Ingress CATS-Forwarder to the Egress CATS-Forwarder. The C-PS MUST ensure that the NST and CST are synchronized in time: when evaluating a candidate, the C-PS SHOULD use NST entries whose Last Updated timestamp is within a reasonable window of the CST entry's Last Updated timestamp (e.g., within 30 seconds) to avoid decisions based on stale combinations. Zhang, et al. Expires 26 February 2027 [Page 12] Internet-Draft CATS Service Metrics Operation August 2026 Network performance metrics such as delay, jitter, and loss can be distributed via IGP TE metric extensions for OSPF [RFC7471] and IS-IS [RFC8570], or via BGP-LS TE performance metric extensions [RFC8571]. The C-PS can consume these standard protocol advertisements to populate the NST. 5.2.3. Joint Selection Algorithm When a service request arrives at the Ingress CATS-Forwarder, the C-PS executes the following Joint Selection Algorithm to determine the optimal CSCI-ID: Step 1: Service Lookup (Computing Filter) The C-PS queries the CST using the requested CS-ID. It retrieves all entries matching the CS-ID. Entries with GAS = 0 or expired entries are discarded. This produces the Candidate Set: Candidate_Set = { (CSCI-ID_i, GAS_i, CompTime_i, ...) | CST[CS-ID, CSCI-ID_i] exists AND CST.GAS > 0 AND CST.Expiry > now } Step 2: Computing Constraint Filtering (Hard Constraints) The C-PS applies hard constraints to eliminate infeasible candidates: a. Security Label: If the client or policy specifies a minimum security label S_min, remove all candidates where Security_Label < S_min. b. Reputation: If the client or policy specifies a minimum reputation R_min, remove all candidates where Reputation < R_min. c. Cost: If the client or policy specifies a maximum cost M_max, remove all candidates where Cost > M_max. d. GAS Sufficiency: If local policy indicates a required session count N_req, remove all candidates where GAS < N_req. (Note: typically N_req = 1 for a single session.) After constraint filtering, if the Candidate_Set is empty, the C-PS proceeds to Fallback (Section 5.2.5). Step 3: Network Path Lookup For each remaining candidate CSCI-ID_i, the C-PS determines the corresponding Egress CATS-Forwarder Egress_i (based on the CSCI-ID's network attachment point). It then queries the NST for the path from the client's Ingress CATS- Forwarder to Egress_i: Zhang, et al. Expires 26 February 2027 [Page 13] Internet-Draft CATS Service Metrics Operation August 2026 Path_i = NST[Ingress, Egress_i] If no NST entry exists for a candidate, that candidate is removed from the Candidate_Set. Step 4: Total Service Time Computation For each remaining candidate, the C-PS computes the Total Service Time (TST): TST_i = Computing_Time_i + Network_Delay_i Where: * Computing_Time_i is from the CST entry for CSCI-ID_i. * Network_Delay_i is from the NST entry for Path_i. Step 5: Network Constraint Filtering (Hard Constraints) The C-PS applies network-side hard constraints to eliminate infeasible candidates: a. Bandwidth: If the client or policy specifies a minimum bandwidth BW_min, remove all candidates where Bandwidth < BW_min. b. Jitter: If the client or policy specifies a maximum jitter J_max, remove all candidates where Jitter > J_max. c. Loss Rate: If the client or policy specifies a maximum loss rate LR_max, remove all candidates where Loss_Rate > LR_max. d. Latency: If the client or policy specifies a maximum total latency L_max, remove all candidates where TST_i > L_max. After constraint filtering, if the Candidate_Set is empty, the C-PS proceeds to Fallback (Section 5.2.5). Step 6: Optimization Selection If multiple candidates remain after all hard constraints have been applied, the C-PS performs optimization selection. The client service requirement MAY indicate that a specific metric should be optimized rather than constrained. A reserved value of 0 in a service requirement metric indicates an optimization objective (i.e., find the best value for that metric) rather than a threshold. The C-PS processes optimization objectives in the following priority order: 1. Security Label = 0: Optimal_CSCI-ID = argmax_{i in Candidate_Set} (Security_Label_i) Zhang, et al. Expires 26 February 2027 [Page 14] Internet-Draft CATS Service Metrics Operation August 2026 2. Reputation = 0: Optimal_CSCI-ID = argmax_{i in Candidate_Set} (Reputation_i) 3. Cost = 0: Optimal_CSCI-ID = argmin_{i in Candidate_Set} (Cost_i) 4. GAS = 0: Optimal_CSCI-ID = argmax_{i in Candidate_Set} (GAS_i) 5. Bandwidth = 0: Optimal_CSCI-ID = argmax_{i in Candidate_Set} (Bandwidth_i) 6. Jitter = 0: Optimal_CSCI-ID = argmin_{i in Candidate_Set} (Jitter_i) 7. Loss Rate = 0: Optimal_CSCI-ID = argmin_{i in Candidate_Set} (Loss_Rate_i) 8. Latency = 0: Optimal_CSCI-ID = argmin_{i in Candidate_Set} (TST_i) If no optimization objectives are specified (i.e., no reserved zero values), the C-PS applies soft constraints and preference rules listed in the client service requirement. The processing of soft constraints follows the same logic as hard constraints, but violation of a soft constraint does not eliminate a candidate; instead, it contributes to a penalty in the candidate's score. If still multiple candidates exist after optimization and soft- constraint processing, the C-PS applies tie-breaking rules in the following priority: 1. Highest GAS (prefer sites with more available capacity). 2. Lowest Cost (prefer cheaper sites). 3. Highest Reputation (prefer higher-quality sites). 4. Random selection among remaining ties. Step 7: Result Installation The C-PS returns the selected CSCI-ID to the Ingress CATS-Forwarder. The Ingress CATS-Forwarder encapsulates the client traffic and forwards it along the CATS- computed path to the Egress CATS-Forwarder, which then delivers it to the selected CSCI-ID. The following figure illustrates the data flow and decision logic: Zhang, et al. Expires 26 February 2027 [Page 15] Internet-Draft CATS Service Metrics Operation August 2026 +-------------------------+ +-------------------------+ | Computing Service Table | | Network Service Table | | (CS-ID, CSCI-ID, GAS, | | (Ingress, Egress, | | Comp Time, Cost, etc.) | | Delay, Jitter, BW) | +-----------+-------------+ +-----------+-------------+ | | | 1. Lookup by CS-ID | 3. Lookup by | (filter GAS>0) | (Ingress, Egress) v v +----------------------------------------------------------+ | C-PS Joint Selector | | | | 2. Apply Computing Hard Constraints | | (Security, Reputation, Cost, GAS) | | | | 4. Compute TST = Comp Time + Network Delay | | | | 5. Apply Network Hard Constraints | | (Bandwidth, Jitter, Loss, Latency) | | | | 6. Optimize / Tie-break | | | | 7. Return CSCI-ID to Ingress CATS-Forwarder | +----------------------------------------------------------+ | v +---------+---------+ | Ingress CATS-FW | | (Encapsulate & | | Forward) | +---------+---------+ | v +---------+---------+ | Egress CATS-FW | | (Decapsulate & | | Deliver to SCI) | +-------------------+ Figure 1: Joint Selection Algorithm Data Flow 5.2.4. Multi-Objective Optimization and Constraints The basic Joint Selection Algorithm executes according to the client's service requirement parameters. However, production deployments often require multi-objective optimization that balances competing goals. This section defines extensions to the basic algorithm. Zhang, et al. Expires 26 February 2027 [Page 16] Internet-Draft CATS Service Metrics Operation August 2026 Weighted Objective Function: The C-PS MAY use a weighted objective function that combines multiple metrics: Score_i = w1 * TST_i + w2 * Cost_i + w3 * (1 / GAS_i)+ w4 * (1 / Reputation_i) + w5 * (1 / Security_Label_i) + w6 * (1 / Bandwidth_i) + w7 * Loss_Rate_i + w8 * Jitter_i Where w1, w2, w3, w4, w5, w6, w7, w8 are non-negative weights configured by the manager. The C-PS selects the candidate with the minimum Score_i. By default, w1 = 1 and w2 = w3 = w4 = w5 = w6 = w7= w8= 0 (pure TST minimization). Weights are normalized such that each term contributes proportionally to its configured priority. Constraint-Based Selection: Instead of (or in addition to) optimization, the C-PS MAY apply constraint-based selection: * Delay Budget: TST_i <= TST_max. Remove candidates exceeding the maximum acceptable total service time. * Cost Budget: Cost_i <= Cost_max. Remove candidates exceeding the maximum acceptable cost. * Bandwidth Requirement: Bandwidth_i >= BW_min. Remove candidates that cannot provide sufficient network bandwidth. * Affinity Requirement: If the client requires session affinity to a previously selected CSCI-ID, and that CSCI-ID is still in the Candidate_Set, the C-PS MAY bypass the optimization and select the affined CSCI-ID directly. Hierarchical Selection: For scalability, the C-PS MAY perform hierarchical selection: 1. First, select the best Egress CATS-Forwarder based on network metrics alone (e.g., minimum Network Delay). 2. Then, among the SCIs reachable via that Egress CATS-Forwarder, select the best CSCI-ID based on computing metrics. This reduces the search space and simplifies the decision, but may miss globally optimal solutions where a slightly longer network path leads to a significantly better computing site. Policy-Driven Override: The C-PS MAY support policy-driven overrides that take precedence over the optimization algorithm: * Geo-fencing: Always prefer service sites within a specific geographic region. Zhang, et al. Expires 26 February 2027 [Page 17] Internet-Draft CATS Service Metrics Operation August 2026 * Provider preference: Always prefer a specific service provider. * Maintenance avoidance: Avoid service sites under maintenance. * Load balancing: Distribute traffic evenly across multiple sites even if one has slightly better TST. 5.2.5. Fallback and Re-routing Policies When the Joint Selection Algorithm cannot produce a valid candidate, the C-PS MUST execute fallback procedures: Fallback Level 1: Relax Soft Constraints If the Candidate_Set is empty after applying constraints, the C-PS MAY apply some implementation-specific relaxation policies, for example: 1. Increase the acceptable Cost threshold by 20%. 2. Decrease the acceptable Security Label by 1 point. 3. Decrease the minimum Reputation threshold by 1 point. 4. Decrease the minimum GAS threshold by 1 point. 5. Decrease the acceptable Bandwidth threshold by 20%. 6. Increase the acceptable Jitter threshold by 20%. 7. Increase the acceptable Loss Rate threshold by 20%. 8. Increase the acceptable Latency threshold by 20%. 9. Accept DEGRADED service sites (if previously excluded). 10. Re-run the Joint Selection Algorithm with relaxed constraints. Fallback Level 2: Network-Only Steering If no computing metrics are available (e.g., all CST entries expired), the C-PS falls back to pure network-based steering: select the Egress CATS-Forwarder with the minimum Network Delay to the destination, and let the Egress CATS-Forwarder select a local CSCI-ID. Fallback Level 3: Default Route If no network path is available, the C-PS uses the default underlay routing (i.e., shortest-path IP routing) without CATS optimization. The client request is forwarded without CATS encapsulation. Zhang, et al. Expires 26 February 2027 [Page 18] Internet-Draft CATS Service Metrics Operation August 2026 Re-routing on Failure: If the selected CSCI-ID becomes unreachable after the session is established (detected by C-PS via C-SMA withdrawal or path failure), the C-PS: 1. Marks the CSCI-ID as unavailable in the CST (GAS = 0). 2. Re-runs the Joint Selection Algorithm for new requests. 3. For existing affined sessions, the C-PS MAY either: a. Migrate the session to the new optimal CSCI-ID (if the service protocol supports it), or b. Terminate the session and require the client to re- establish. 6. Use Case: Joint Service Selection and Path Computation This section provides detailed use cases that illustrate the integrated routing logic of the Joint Selection Algorithm. The scenarios demonstrate how the C-PS combines the Computing Service Table and the Network Service Table under different operational conditions. 6.1. Service Distribution and Table Formation Consider a CATS domain with three service sites providing computing services. The topology is as follows: Zhang, et al. Expires 26 February 2027 [Page 19] Internet-Draft CATS Service Metrics Operation August 2026 Service Site 2 (SS2) Service Site 3 (SS3) +------------------+ +------------------+ | SCI-1: AR1 | | SCI-3: AR1 | | 188.3.67.3:67 | | 188.3.67.4:69 | | GAS=400, CT=5 | | GAS=600, CT=6 | | Cost=10 | | Cost=5 | | | | | | SCI-2: AR2 | | SCI-4: LLM1 | | 188.3.67.3:68 | | 188.3.67.4:70 | | GAS=100, CT=15 | | GAS=300, CT=12 | | Cost=20 | | Cost=15 | +--------+---------+ +--------+---------+ | | Egress CF-2 Egress CF-3 (188.3.67.3) (188.3.67.4) ^ ^ | | +--------------+-----------------------------------+-------------+ | Underlay Network | | (P-routers) | +--------------+-----------------------------------+-------------+ | | | | +-----+------+ +---+----------+ | C-NMA | | C-SMA#2 | | | | (SS3) | +------------+ +----------------+ ^ | +--------------+-----------------------------------+-------------+ | | | +---------------------+ | | | Ingress CATS-FW 1 | | | | 10.0.0.1 (Client) | | | | C-PS (co-located) | | | +---------------------+ | | | +------------------------------------------------------------------+ The C-SMAs at each service site push their local service information to the C-PS, forming the Computing Service Table (CST). The C-NMA collects network information and pushes it to the C-PS, forming the Network Service Table (NST). Computing Service Table (CST): Zhang, et al. Expires 26 February 2027 [Page 20] Internet-Draft CATS Service Metrics Operation August 2026 +=======+===================+=====+===============+=================+ | CS-ID | CSCI-ID (IP:Port) | GAS | Comp Time(ms) | Cost (Optional) | +=======+===================+=====+===============+=================+ | AR1 | 188.3.67.3:67 | 400 | 5 | 10 | +-------+-------------------+-----+---------------+-----------------+ | AR2 | 188.3.67.3:68 | 100 | 15 | 20 | +-------+-------------------+-----+---------------+-----------------+ | AR1 | 188.3.67.4:69 | 600 | 6 | 5 | +-------+-------------------+-----+---------------+-----------------+ | LLM1 | 188.3.67.4:70 | 300 | 12 | 15 | +-------+-------------------+-----+---------------+-----------------+ Network Service Table (NST): +========================+=======================+============+ | Ingress CATS-Forwarder | Egress CATS-Forwarder | Network | | | | Delay (ms) | +========================+=======================+============+ | 10.0.0.1 | 188.3.67.3 (CF-2) | 8 | +------------------------+-----------------------+------------+ | 10.0.0.1 | 188.3.67.4 (CF-3) | 6 | +------------------------+-----------------------+------------+ Note: In this example, the Egress CATS-Forwarder identifiers are represented by their attachment IP addresses for simplicity. In a real deployment, they would be router IDs or loopback addresses. 6.2. Scenario A: Normal Operation with Balanced Load A client at Ingress CATS-Forwarder 1 (10.0.0.1) requests the AR1 service with the requirement for the shortest Total Service Time. Step 1: Service Lookup (Computing Filter) The C-PS queries the CST for CS-ID = "AR1". Candidates: * CSCI-ID 188.3.67.3:67 (SS2, GAS=400, CT=5ms, Cost=10) * CSCI-ID 188.3.67.4:69 (SS3, GAS=600, CT=6ms, Cost=5) Both have GAS > 0 and are not expired. Step 2: Constraint Filtering No hard constraints are applied in this scenario (no minimum security label, reputation, or cost limits). Both candidates remain. Step 3: Network Path Lookup * For 188.3.67.3:67, the Egress CATS-Forwarder is 188.3.67.3. NST[10.0.0.1, 188.3.67.3] -> Network Delay = 8 ms. Zhang, et al. Expires 26 February 2027 [Page 21] Internet-Draft CATS Service Metrics Operation August 2026 * For 188.3.67.4:69, the Egress CATS-Forwarder is 188.3.67.4. NST[10.0.0.1, 188.3.67.4] -> Network Delay = 6 ms. Step 4: Total Service Time Computation * Candidate 188.3.67.3:67: TST = 5 ms + 8 ms = 13 ms. * Candidate 188.3.67.4:69: TST = 6 ms + 6 ms = 12 ms. Step 5: Optimization Selection The C-PS compares TST values: * 188.3.67.4:69 has TST = 12 ms (optimal). * 188.3.67.3:67 has TST = 13 ms. The C-PS selects 188.3.67.4:69 (Service Site 3) because it offers the shortest Total Service Time, even though its computing time (6 ms) is slightly higher than candidate 188.3.67.3:67 (5 ms). The shorter network path (6 ms vs. 8 ms) compensates for the slightly higher computing time. Step 6: Result Installation The C-PS returns CSCI-ID 188.3.67.4:69 to Ingress CATS-Forwarder 1. The Ingress CATS-Forwarder encapsulates the client packets and forwards them along the CATS- computed path to Egress CATS-Forwarder 3 (188.3.67.4). The Egress CATS-Forwarder decapsulates and delivers the packets to SCI-3 at 188.3.67.4:69. This scenario demonstrates that CATS selects the globally optimal combination of computing and network performance, not just the best computing site or the best network path in isolation. 6.3. Scenario B: Network Congestion Impact Suppose the network path to Service Site 3 experiences congestion, and the C-NMA updates the NST: Updated Network Service Table (NST): +========================+=======================+============+ | Ingress CATS-Forwarder | Egress CATS-Forwarder | Network | | | | Delay (ms) | +========================+=======================+============+ | 10.0.0.1 | 188.3.67.3 (CF-2) | 8 | +------------------------+-----------------------+------------+ | 10.0.0.1 | 188.3.67.4 (CF-3) | 20 | <-- changed +------------------------+-----------------------+------------+ The C-PS re-evaluates the AR1 request: Zhang, et al. Expires 26 February 2027 [Page 22] Internet-Draft CATS Service Metrics Operation August 2026 Step 4 (Re-evaluation): Total Service Time Computation * Candidate 188.3.67.3:67: TST = 5 ms + 8 ms = 13 ms. * Candidate 188.3.67.4:69: TST = 6 ms + 20 ms = 26 ms. Step 5: Optimization Selection Now 188.3.67.3:67 (TST = 13 ms) is optimal, while 188.3.67.4:69 (TST = 26 ms) is penalized by the congested network path. The C-PS dynamically re-selects 188.3.67.3:67 (Service Site 2) and updates the forwarding rules at Ingress CATS-Forwarder 1. New client requests for AR1 are steered to Service Site 2 until the network congestion to Service Site 3 subsides. This scenario demonstrates CATS's ability to dynamically adapt to network condition changes and re-steer traffic to maintain optimal Total Service Time. 6.4. Scenario C: Service Site Degradation and Failover Suppose Service Site 3 experiences a partial failure: SCI-3 (AR1) becomes DEGRADED, and its GAS drops from 600 to 50. The C-SMA at Service Site 3 reports the updated metrics to the C-PS: Updated Computing Service Table (CST): +=======+===================+=====+===============+=================+ | CS-ID | CSCI-ID (IP:Port) | GAS | Comp Time(ms) | Cost (Optional) | +=======+===================+=====+===============+=================+ | AR1 | 188.3.67.3:67 | 400 | 5 | 10 | +-------+-------------------+-----+---------------+-----------------+ | AR2 | 188.3.67.3:68 | 100 | 15 | 20 | +-------+-------------------+-----+---------------+-----------------+ | AR1 | 188.3.67.4:69 | 50 | 25 | 5 | <-- changed +-------+-------------------+-----+---------------+-----------------+ | LLM1 | 188.3.67.4:70 | 300 | 12 | 15 | +-------+-------------------+-----+---------------+-----------------+ Note: Computing Time increased to 25 ms due to degraded performance. The C-PS re-evaluates the AR1 request: Step 1: Service Lookup Candidates: 188.3.67.3:67 (GAS=400) and 188.3.67.4:69 (GAS=50). Both have GAS > 0, so both remain. Step 4: Total Service Time Computation (using original NST delays) * Candidate 188.3.67.3:67: TST = 5 ms + 8 ms = 13 ms. Zhang, et al. Expires 26 February 2027 [Page 23] Internet-Draft CATS Service Metrics Operation August 2026 * Candidate 188.3.67.4:69: TST = 25 ms + 6 ms = 31 ms. Step 5: Optimization Selection 188.3.67.3:67 (TST = 13 ms) is clearly optimal. Even without the network congestion from Scenario B, the degraded computing performance at Service Site 3 makes it an inferior choice. Now suppose the failure worsens: SCI-3 becomes UNHEALTHY, and GAS drops to 0. The C-SMA reports the withdrawal: Updated Computing Service Table (CST): +=======+===================+=====+===============+=================+ | CS-ID | CSCI-ID (IP:Port) | GAS | Comp Time(ms) | Cost (Optional) | +=======+===================+=====+===============+=================+ | AR1 | 188.3.67.3:67 | 400 | 5 | 10 | +-------+-------------------+-----+---------------+-----------------+ | AR2 | 188.3.67.3:68 | 100 | 15 | 20 | +-------+-------------------+-----+---------------+-----------------+ | AR1 | 188.3.67.4:69 | 0 | 25 | 5 | <-- GAS=0 +-------+-------------------+-----+---------------+-----------------+ | LLM1 | 188.3.67.4:70 | 300 | 12 | 15 | +-------+-------------------+-----+---------------+-----------------+ Step 1: Service Lookup (Computing Filter) Candidate 188.3.67.4:69 has GAS = 0 and is filtered out. Only 188.3.67.3:67 remains. The C-PS selects 188.3.67.3:67 as the only available candidate. This scenario demonstrates automatic failover when a service site becomes unavailable. If ALL AR1 candidates have GAS = 0 (e.g., both sites fail), the C-PS triggers Fallback Level 2 (Section 5.2.5): it falls back to pure network-based steering or returns a "Service Unavailable" indication to the client. 6.5. Scenario D: Multi-Objective Optimization with Cost Constraint Consider a client request for AR1 with the following policy: * Primary objective: Minimize Total Service Time. * Hard constraint: Cost <= 8. * Secondary objective: Maximize GAS (prefer sites with more available capacity). The CST and NST are as in the initial state (Scenario A): Zhang, et al. Expires 26 February 2027 [Page 24] Internet-Draft CATS Service Metrics Operation August 2026 Computing Service Table (CST): +=======+===================+=====+===============+=================+ | CS-ID | CSCI-ID (IP:Port) | GAS | Comp Time(ms) | Cost (Optional) | +=======+===================+=====+===============+=================+ | AR1 | 188.3.67.3:67 | 400 | 5 | 10 | +-------+-------------------+-----+---------------+-----------------+ | AR1 | 188.3.67.4:69 | 600 | 6 | 5 | +-------+-------------------+-----+---------------+-----------------+ Network Service Table (NST): +========================+=======================+============+ | Ingress CATS-Forwarder | Egress CATS-Forwarder | Network | | | | Delay (ms) | +========================+=======================+============+ | 10.0.0.1 | 188.3.67.3 (CF-2) | 8 | +------------------------+-----------------------+------------+ | 10.0.0.1 | 188.3.67.4 (CF-3) | 6 | +------------------------+-----------------------+------------+ Step 1: Service Lookup Candidates: 188.3.67.3:67 and 188.3.67.4:69. Step 2: Constraint Filtering (Hard Constraints) Apply Cost <= 8: * 188.3.67.3:67 has Cost = 10 -> EXCLUDED. * 188.3.67.4:69 has Cost = 5 -> RETAINED. Candidate_Set = { 188.3.67.4:69 }. Step 3-5: The C-PS computes TST for the remaining candidate: TST = 6 ms + 6 ms = 12 ms. Only one candidate remains, so 188.3.67.4:69 is selected. This scenario demonstrates how hard constraints (Cost <= 8) filter out expensive candidates before optimization. Even though 188.3.67.3:67 has a slightly better computing time (5 ms vs. 6 ms), it is excluded due to cost. Now suppose the client policy changes to Cost <= 12 (relaxing the constraint). Both candidates are eligible: Step 4: Total Service Time Computation * 188.3.67.3:67: TST = 5 ms + 8 ms = 13 ms. * 188.3.67.4:69: TST = 6 ms + 6 ms = 12 ms. Zhang, et al. Expires 26 February 2027 [Page 25] Internet-Draft CATS Service Metrics Operation August 2026 Step 5: Optimization Selection 188.3.67.4:69 has lower TST (12 ms vs. 13 ms) and is selected. However, if the policy includes a secondary objective (maximize GAS) and both candidates have the same TST (e.g., due to a network change making both paths equal), the tie-breaker rule selects the candidate with higher GAS. If 188.3.67.4:69 has GAS = 600 and 188.3.67.3:67 has GAS = 400, the C-PS prefers 188.3.67.4:69. This scenario demonstrates the interaction between hard constraints, primary optimization (TST), and secondary tie-breaking (GAS). 7. Update Control in Large-Scale Deployments In large-scale deployments with hundreds of service sites and thousands of service instances, unconstrained metric updates can overwhelm the C-PS and the control-plane network. This section defines update control mechanisms. Delta-Threshold Reporting: Each C-SMA maintains a local metric cache. Per-session GAS changes are accumulated locally. The C-SMA reports an update only when: * GAS changes by more than a configured absolute threshold (e.g., 50 slots) or relative threshold (e.g., 10%). * Computing Time changes by more than a configured relative threshold (e.g., 20%). * Health status changes (HEALTHY <-> DEGRADED <-> UNHEALTHY). * A periodic heartbeat interval expires (e.g., every 60 seconds). Hierarchical Aggregation: In deployments with many SCIs per site, the C-SMA MAY aggregate per-SCI metrics into a single per-site advertisement. This reduces the number of entries in the CST and the control-plane update load. However, per-SCI granularity is lost, and the Egress CATS-Forwarder must perform local CSCI-ID selection. Rate Limiting and Dampening: The C-PS SHOULD implement rate limiting on incoming C-SMA reports to prevent update storms during network events (e.g., flash crowds, DDoS attacks). If a C-SMA exceeds the allowed update rate, the C-PS MAY drop excess updates or throttle the C-SMA. Soft-State Aging: The C-PS ages out CST entries whose Expiry Time Zhang, et al. Expires 26 February 2027 [Page 26] Internet-Draft CATS Service Metrics Operation August 2026 has passed. The default expiry time SHOULD be 3x the C-SMA heartbeat interval. If no update is received within the expiry time, the C-PS sets GAS = 0 for that entry and triggers re- computation for affected sessions. 8. Security Considerations The dynamic reporting of Service Metrics introduces potential attack vectors. Authentication mechanisms between service sites and C-SMAs MUST be enforced. The Security Label (Section 4.3.3) can be utilized by the C-PS to prevent routing sensitive traffic to compromised sites. Service Metric reports influence service selection and therefore need integrity protection, source authentication, and authorization checks. Deployments should protect against forged, replayed, or stale metric reports, for example by using freshness information and aging out old metric state. Implementations should also consider rate limiting or aggregation policies so that abnormal local events do not create excessive update bursts toward the C-PS. The Joint Selection Algorithm relies on the integrity of both the CST and the NST. If an attacker injects false network delays into the NST or false computing times into the CST, traffic may be misdirected to suboptimal or compromised service sites. Therefore, both the C-NMA and C-SMA MUST authenticate their reports to the C-PS, and the C-PS MUST validate the freshness and plausibility of all inputs. Specific threats related to individual Computing Service Metrics include: GAS Inflation: A malicious or compromised service site could advertise artificially high GAS values to attract more traffic than it can handle, leading to overload and service degradation for all clients. The C-PS SHOULD implement plausibility checks (e.g., comparing reported GAS against historical capacity, or validating against observed session success rates) and SHOULD penalize sites that consistently fail to honor their advertised GAS. Computing Time Under-reporting: A service site could under-report Computing Time to appear more attractive in the TST calculation. The C-PS SHOULD maintain a moving average of observed response times and SHOULD flag sites whose reported Computing Time deviates significantly from observed values. Reputation Gaming: Malicious users or coordinated botnets could Zhang, et al. Expires 26 February 2027 [Page 27] Internet-Draft CATS Service Metrics Operation August 2026 submit fake positive feedback to inflate a site's reputation score, or fake negative feedback to damage a competitor. The C-PS SHOULD implement anti-gaming measures such as rate limiting on feedback submissions, identity verification, outlier detection, and weighting feedback by client trust level. Cost Manipulation: While Cost is self-defined by the service site, a provider could temporarily set an artificially low cost to capture market share and then raise it abruptly. The C-PS MAY implement cost-change dampening (e.g., ignoring cost increases above a threshold within a short time window) to protect clients from bait-and-switch tactics. Security Label Misrepresentation: The Security Label is self- reported by the service site. A compromised site could claim a high security score while actually being vulnerable. The C-PS SHOULD verify security claims through independent audits, trusted third-party attestations, or automated security scanning where available. A Security Label without external validation SHOULD be treated as a hint rather than a guarantee. CST/NST Poisoning: If an attacker gains control of a C-SMA or C-NMA, or injects false reports into the control channel, both the CST and NST can be poisoned. This could lead to systematic mis- steering of traffic. All control-plane channels between C-SMA/ C-NMA and C-PS MUST be integrity-protected (e.g., using TLS or IPsec) and mutually authenticated. Finally, the C-PS itself is a critical security component. If compromised, it could steer all traffic to an attacker-controlled service site. The C-PS SHOULD run in a hardened environment, and its policy configuration SHOULD be protected against unauthorized modification. 9. IANA Considerations This section requests IANA to create a new registry and follows the guidelines in [RFC8126]. 9.1. CATS Computing Service Metrics Registry IANA is requested to create a new registry titled "CATS Computing Service Metrics" under the existing "Computing-Aware Traffic Steering (CATS)" registry heading. Each registry entry contains the following fields: * Identifier: A unique integer assigned by IANA. Zhang, et al. Expires 26 February 2027 [Page 28] Internet-Draft CATS Service Metrics Operation August 2026 * Name: The formal metric name. * URI: A stable URI reference for the metric entry. * Description: A brief description of the metric. * Change Controller: The entity responsible for the metric definition (IETF for entries defined in this document and its companion registry document). * Version: The version of the metric definition. The registration policy for this registry is "Specification Required" [RFC8126]. New entries require a publicly available specification document. The initial entries for this registry are as follows. Full registry definitions (including Summary, Metric Definition, Method of Measurement, Output, and Administrative Items) are provided in the companion document [I-D.zhangb-cats-service-metric-registry-entries], which serves as the authoritative specification for the initial entries. +------------+------------------+ | Identifier | Metric Name | +------------+------------------+ | TBD1 | GAS | | TBD2 | Computing Time | | TBD3 | Cost | | TBD4 | Reputation | | TBD5 | Security Label | | TBD6 | Capability | +------------+------------------+ 10. Informative References [I-D.ietf-cats-framework-24] 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-24, April 2026, . Zhang, et al. Expires 26 February 2027 [Page 29] Internet-Draft CATS Service Metrics Operation August 2026 [I-D.ietf-cats-metric-definition-10] Kehan, Y., Li, C., Contreras, L. M., Ros-Giralt, J., and G. Zeng, "CATS Metrics Definition", Work in Progress, Internet-Draft, draft-ietf-cats-metric-definition-10, 22 June 2026, . [I-D.zhangb-cats-cmas-04] Zhang, B., Dai, Y., Du, Z., Li, C., and C. Miao, "Public Service Platform for Computing-Aware Traffic Steering (CATS)", Work in Progress, Internet-Draft, draft-zhangb- cats-cmas-04, 13 May 2026, . [I-D.zhangb-cats-service-metric-registry-entries] Zhang, B., Dai, Y., Du, Z., and C. Miao, "IANA Registry Entries for CATS Computing Service Metrics", Work in Progress, Internet-Draft, draft-zhangb-cats-service- metric-registry-entries, 23 August 2026, . [RFC4760] Bates, T., Chandra, R., Katz, D., and Y. Rekhter, "Multiprotocol Extensions for BGP-4", RFC 4760, January 2007, . [RFC7149] Boucadair, M. and C. Jacquenet, "Software-Defined Networking: A Perspective from within a Service Provider Environment", RFC 7149, March 2014, . [RFC7426] Haleplidis, E., Ed., Pentikousis, K., Ed., Denazis, S., Salim, J. H., Meyer, D., and O. Koufopavlou, "Software- Defined Networking (SDN): Layers and Architecture Terminology", RFC 7426, January 2015, . [RFC7471] Giacalone, S., Ward, D., Drake, J., Atlas, A., and S. Previdi, "OSPF Traffic Engineering (TE) Metric Extensions", RFC 7471, March 2015, . [RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for Writing an IANA Considerations Section in RFCs", RFC 8126, June 2017, . Zhang, et al. Expires 26 February 2027 [Page 30] Internet-Draft CATS Service Metrics Operation August 2026 [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, 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, March 2019, . [RFC8990] Bormann, C., Carpenter, B., Ed., and B. Liu, Ed., "GeneRic Autonomic Signaling Protocol (GRASP)", RFC 8990, March 2021, . Authors' Addresses Bin Zhang (editor) Pengcheng Laboratory Email: zhangb@pcl.ac.cn Yina Dai (editor) Sun Yat-sen University Email: daiyn5@mail2.sysu.edu.cn Zongpeng Du (editor) China Mobile Email: duzongpeng@chinamobile.com Guanming Zeng Huawei Technologies Email: zengguanming@huawei.com Chuanyang Miao (editor) ZTE Corporation Email: miao.chuanyang@zte.com.cn Zhang, et al. Expires 26 February 2027 [Page 31]