CATS B. Zhang, Ed. Internet-Draft Pengcheng Laboratory Intended status: Standards Track Y. Dai, Ed. Expires: 18 March 2027 Sun Yat-sen University Z. Du, Ed. China Mobile G. Zeng Huawei Technologies C. Miao, Ed. ZTE Corporation 14 September 2026 Computing Service Metrics Operation and Joint Service Selection under CATS draft-zhangb-cats-service-metrics-op-05 Abstract Computing-Aware Traffic Steering (CATS) optimizes traffic forwarding by considering both computing and networking metrics. The CATS framework and metric-definition documents provide valuable theoretical models, yet they face challenges in achieving direct operational execution in real-world deployments: normalization methods vary across providers, and aggregated unitless scores often lose the operational information that routers need for precise steering decisions. This document provides a self-contained, executable operational model for a core class of CATS deployment scenarios: latency-sensitive, compute-intensive services whose steering decisions are made in real time at the forwarding node. Instead of disseminating low-level raw hardware metrics, service sites dynamically evaluate and report service-oriented metrics (e.g., Global Available Slots and Computing Time) to the control plane. The document clarifies how these metrics are 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 (populated from C-SMA reports) with the Network Service Table to make joint traffic- steering decisions, and defines update-control and fallback mechanisms suitable for large-scale deployments. Zhang, et al. Expires 18 March 2027 [Page 1] Internet-Draft CATS Service Metrics Operation September 2026 Within the unified CATS architecture, the service-oriented operational model defined in this document coexists with the general- purpose L1/L2 normalized metric framework: a deployment MAY use either model, or run both pipelines in parallel for different service classes, without embedding metric fields across frameworks. This document does not negate the value of normalized metrics; it focuses on the service-level abstractions and runtime operations required for direct traffic steering. 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 18 March 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 . . . . . . . . . . . . . . . . . . . . . . . . . 5 3. Conventions . . . . . . . . . . . . . . . . . . . . . . . . . 6 4. Motivation and Problem Statement . . . . . . . . . . . . . . 6 5. Service Information and Metrics Definition . . . . . . . . . 7 5.1. Relationship to the CATS Metrics Framework . . . . . . . 7 Zhang, et al. Expires 18 March 2027 [Page 2] Internet-Draft CATS Service Metrics Operation September 2026 5.2. Derivation from Basic and Reference Information . . . . . 9 5.3. Mandatory Computing Service Information . . . . . . . . . 10 5.3.1. Global Available Slots (GAS) . . . . . . . . . . . . 10 5.3.2. Computing Time . . . . . . . . . . . . . . . . . . . 11 5.4. Optional Extension Metrics . . . . . . . . . . . . . . . 12 5.4.1. Price . . . . . . . . . . . . . . . . . . . . . . . . 12 5.4.2. Reputation . . . . . . . . . . . . . . . . . . . . . 12 5.4.3. Security Level . . . . . . . . . . . . . . . . . . . 13 6. Operation under CATS Framework . . . . . . . . . . . . . . . 13 6.1. Dynamic Metric Reporting . . . . . . . . . . . . . . . . 13 6.2. Joint Decision: Computing Service Table and Network Service Table . . . . . . . . . . . . . . . . . . . . . . . . . . 14 6.2.1. Computing Service Table Structure . . . . . . . . . . 14 6.2.2. Network Service Table Structure . . . . . . . . . . . 15 6.2.3. Joint Selection Algorithm . . . . . . . . . . . . . . 16 6.2.4. Multi-Objective Optimization and Constraints . . . . 20 6.2.5. Fallback and Re-routing Policies . . . . . . . . . . 22 7. Use Case: Joint Service Selection and Path Computation . . . 23 7.1. Service Distribution and Table Formation . . . . . . . . 23 7.2. Scenario A: Normal Operation with Balanced Load . . . . . 25 7.3. Scenario B: Network Congestion Impact . . . . . . . . . . 26 7.4. Scenario C: Service Site Degradation and Failover . . . . 27 7.5. Scenario D: Multi-Objective Optimization with Price Constraint . . . . . . . . . . . . . . . . . . . . . . . 28 8. Update Control in Large-Scale Deployments . . . . . . . . . . 30 9. Security Considerations . . . . . . . . . . . . . . . . . . . 31 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 33 10.1. CATS Computing Service Metrics . . . . . . . . . . . . . 33 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 34 11.1. Normative References . . . . . . . . . . . . . . . . . . 34 11.2. Informative References . . . . . . . . . . . . . . . . . 34 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 36 1. Introduction The Computing-Aware Traffic Steering (CATS) architecture [I-D.ietf-cats-framework-24] aims to steer service traffic to the most suitable service contact instance by evaluating both network state and computing resource availability. To this end, CATS Service Metric Agents (C-SMAs) collect computing metrics and advertise them to CATS Path Selectors (C-PSes). [I-D.ietf-cats-metric-definition-11] introduces a multi-level metric framework (Level 0, Level 1, and Level 2) and proposes normalizing heterogeneous computing metrics into unitless scores (e.g., compute_norm). This establishes a solid theoretical baseline for describing and comparing computing resources. However, mapping diverse hardware capabilities (CPUs, GPUs, NPUs) into a single Zhang, et al. Expires 18 March 2027 [Page 3] Internet-Draft CATS Service Metrics Operation September 2026 normalized score is complex and provider-dependent, and a normalized score does not, by itself, express the concrete service capacity that a router needs for fine-grained steering decisions. The operational limitation concerns the Level 2 normalized representation and the absence of service-capacity entries in the current Level 1 Service category; it is not a criticism of the metric hierarchy itself. Different deployment scenarios impose distinct requirements on metric processing and steering logic. [I-D.ietf-cats-metric-definition-11] describes a general-purpose metric framework for CATS traffic steering: it defines a broad set of metrics and metric processing procedures suitable for general-class deployments, including the L0/L1/L2 metric hierarchy, aggregation and normalization functions, and registry templates. It answers the question: how are computing metrics categorized, aggregated, and normalized? This document specifies metric sets and normative steering decision logic targeting a specific class of deployment scenarios. In these targeted scenarios, forwarding nodes (C-PS) perform real-time steering selections under tight local resource constraints, and the traffic flows are latency-sensitive and compute-intensive. Steering decisions are generated directly from service-oriented metrics reported by service sites. This document defines the required service metrics, the joint selection workflow, edge-case handling, and persistent operational rules applicable to this particular use case. Within the unified CATS architecture, a deployment MAY select either metric-processing pipeline, or operate both pipelines in parallel as separate control-plane workflows for different service classes. These two pipelines do not require mutual embedding of metric fields; the operational model defined in this document does not rely on any L1/L2 normalized score field for its operation. The metric entries defined in this document (GAS, Computing Time, Price, Reputation, and Security Level) are registered in the "CATS Metrics" registry established by [I-D.ietf-cats-metric-definition-11], while their definitions remain in this document and its companion registry document [I-D.zhangb-cats-service-metric-registry-entries], following the pattern of a shared registry with document-specific entry definitions (cf. [RFC8911]). This explicit separation keeps each document's scope focused and avoids tight coupling between the two metric-processing approaches. A further 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 account for computing and network performance. Zhang, et al. Expires 18 March 2027 [Page 4] Internet-Draft CATS Service Metrics Operation September 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-11]. 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. TST is an instance of the Level 1 Composed category (end-to-end delay / application- level response time) defined in [I-D.ietf-cats-metric-definition-11]. * 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 18 March 2027 [Page 5] Internet-Draft CATS Service Metrics Operation September 2026 3. Conventions The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here. 4. 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 work introduces 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 metrics to effectively steer traffic in operational networks. This document does not negate the value of the L1/L2 normalized metric framework; rather, it observes 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 difficult to establish a unified mathematical model that fairly normalizes the capacity of a GPU and a CPU into the same 0-10 score. 2. The Information Loss Gap (WHY disseminate raw features?): Normalizing diverse hardware capabilities into a single unitless score can lose actionable information. A normalized compute score of "7" does not, by itself, guarantee a client's sub-10-ms delay requirement or express the concrete remaining capacity of a service instance. 3. The Routing Mechanism Gap (WHO uses this data?): Routers (C-PSes) 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 into a unified steering decision. Selecting the service site with the best computing metrics may yield a poor network path, and vice versa. Zhang, et al. Expires 18 March 2027 [Page 6] Internet-Draft CATS Service Metrics Operation September 2026 To bridge these gaps, CATS requires a Service-Oriented Abstraction and a clear Joint Selection Algorithm. This document provides both as a self-contained operational model: it defines the required computing service information as Mandatory Computing Service Metrics (Global Available Slots and Computing Time) and Optional Extension Metrics (Price, Reputation, and Security Level), and it specifies how the C-PS combines the Computing Service Table with the Network Service Table to support executable traffic-steering policies. This self-contained operational model targets latency-sensitive compute-intensive workloads under tight forwarding-node resource constraints. It is a first-class metric-processing and steering workflow within the unified CATS architecture, complementary to the general-purpose normalized metric framework. A deployment may use either workflow, or deploy both workflows side-by-side for distinct service classes. 5. 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-11]. This document focuses on the semantics and operational use of these metrics, rather than defining new routing, transport, signaling, or wire-encoding mechanisms. 5.1. Relationship to the CATS Metrics Framework [I-D.ietf-cats-metric-definition-11] defines a three-level metric taxonomy: Level 0 raw metrics, Level 1 category metrics (computing, communication, service, and composed), and Level 2 normalized metrics, together with the CATS metric field template and registry. This document does not extend that taxonomy. The service-oriented metrics defined in this document are mapped to the framework's categories in Table 1 as a semantic correspondence; operationally, the model defined here is self-contained and does not depend on any normalized score field (see below). Zhang, et al. Expires 18 March 2027 [Page 7] Internet-Draft CATS Service Metrics Operation September 2026 +------------------+---------------------------------------------------+ | Metric | Relationship to the CATS Metric Framework | +------------------+---------------------------------------------------+ | GAS | Semantic correspondence: Level 0 Service-specific | +------------------+---------------------------------------------------+ | Computing Time | Semantic correspondence: Level 0 Service-specific | +------------------+---------------------------------------------------+ | | (registration needs WG consensus) | | Price | Service attribute / policy metric (no level); | +------------------+---------------------------------------------------+ | | (registration needs WG consensus) | | Reputation | Service attribute / policy metric (no level); | +------------------+---------------------------------------------------+ | | (registration needs WG consensus) | | Security Level | Service attribute / policy metric (no level); | +------------------+---------------------------------------------------+ Figure 1: Relationship of Computing Service Metrics to the CATS Metric Framework Table 1 is a semantic correspondence, not a claim of interoperability with the normalized pipeline. GAS corresponds to the service- specific metrics anticipated in Section 3.2 of [I-D.ietf-cats-framework-24], which notes that computing metrics may include "the number of clients that access the service contact instance at any given time". Computing Time, when combined with network delay (see Section 6.2.3), forms the Total Service Time (TST), which corresponds to the end-to-end delay / application-level response time described in the Level 1 Composed category of [I-D.ietf-cats-metric-definition-11]. Price, Reputation, and Security Level are operator- or provider-defined service attributes used as constraints or secondary objectives in the Joint Selection Algorithm; whether they are registered in the CATS metric registry as extensions of the Level 1 Service category or as members of a new category is to be agreed with the working group. Zhang, et al. Expires 18 March 2027 [Page 8] Internet-Draft CATS Service Metrics Operation September 2026 The operational model defined in this document does not rely on any Level 1 or Level 2 normalized score field: GAS and Computing Time are reported and consumed in their native service-oriented units, and the steering decision logic in Section 6.2.3 operates directly on these values. The metric entries defined in this document are registered in the "CATS Metrics" registry established by [I-D.ietf-cats-metric-definition-11] (see Section 10), while their definitions remain in this document and its companion registry document [I-D.zhangb-cats-service-metric-registry-entries]. Service attributes that are not measured quantities (Price, Reputation, Security Level) are labeled "Service attribute" and are not assigned to a metric level; a metric MUST NOT be assigned to more than one level. 5.2. 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 5.3 and Section 5.4 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 18 March 2027 [Page 9] Internet-Draft CATS Service Metrics Operation September 2026 To support fair comparison across service sites, the derivation of GAS SHOULD follow a common reference method within an administrative domain; a reference derivation (e.g., the sum over healthy instances of available capacity minus active sessions, with an optional policy safety margin) is provided in [I-D.zhangb-cats-service-metric-registry-entries]. This is consistent with the guidance in Section 5.4 of [I-D.ietf-cats-framework-24] that consistent normalization and aggregation functions be enabled across all involved CATS components so that service contact instance selection is fair among candidates. 5.3. 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. 5.3.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 Zhang, et al. Expires 18 March 2027 [Page 10] Internet-Draft CATS Service Metrics Operation September 2026 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. Each reported GAS value is the current estimate at the time of reporting, taken over the configured measurement window. Basic fields: Metric Type: gas Level: Level 0 (Service-specific metrics) Format: unsigned integer Length: four octets Unit: count (concurrent sessions) Statistics: cur Measurement_Window: 10 seconds (default) Value: 500 Source: estimation 5.3.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 (see Section 6.2.3). It is reported as the mean processing time over the measurement window; implementations MAY additionally report percentile values (e.g., p95) in the Statistics field. Basic fields: Metric Type: comp_time Level: Level 0 (Service-specific metrics) Format: floating point Length: four octets Unit: ms Statistics: mean Measurement_Window: 10 seconds (default) Value: 5 Source: estimation Zhang, et al. Expires 18 March 2027 [Page 11] Internet-Draft CATS Service Metrics Operation September 2026 5.4. Optional Extension Metrics To accommodate advanced traffic-steering scenarios, the following optional fields are defined. 5.4.1. Price Self-defined by the service site to apply administrative or economic billing policies. Price is used as a constraint or secondary objective in the Joint Selection Algorithm (see Section 6.2.4). Price is a service attribute rather than a measured quantity; it is therefore not assigned to a metric level. Basic fields: Metric Type: price Level: Service attribute (no metric level) Format: unsigned integer Length: two octets Unit: unitless (provider-defined pricing unit) Value: 100 Source: nominal 5.4.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. It is a service attribute rather than a measured quantity and is therefore not assigned to a metric level. Score semantics follow the 0-10 normalized score mapping of [I-D.ietf-cats-metric-definition-11] (Section 4.3): 0-3 indicates poor reputation (avoid if alternatives exist), 4-7 average (acceptable for steering), 8-10 excellent (preferred for steering). Basic fields: Metric Type: reputation Level: Service attribute (no metric level) Format: unsigned integer Length: one octet Unit: score (0-10) Value: 8 Source: nominal Zhang, et al. Expires 18 March 2027 [Page 12] Internet-Draft CATS Service Metrics Operation September 2026 5.4.3. Security Level The Security Level reflects the security status of a service site. A higher score indicates a more secure site. The Security Level is used as a constraint in the Joint Selection Algorithm: a C-PS MUST NOT select a service contact instance with a Security Level below the client's minimum requirement. It is a service attribute rather than a measured quantity and is therefore not assigned to a metric level. Score range: 0-10 (0 indicates the poorest security; 10 indicates optimal security). Score semantics follow the 0-10 normalized score mapping of [I-D.ietf-cats-metric-definition-11] (Section 4.3): 0-3 indicates low security posture (not recommended for sensitive traffic), 4-7 medium (acceptable for general traffic), 8-10 high (preferred for sensitive or regulated traffic). Basic fields: Metric Type: security_level Level: Service attribute (no metric level) Format: unsigned integer Length: one octet Unit: score (0-10) Value: 7 Source: nominal 6. Operation under CATS Framework 6.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. The reporting model defined here aligns with the CATS OAM requirements of [I-D.ietf-cats-oam-fw]: O-REQ-1 (the system SHOULD support both periodic and threshold-triggered reporting) and O-REQ-4 (computing metrics SHOULD be accompanied by timestamps indicating the Zhang, et al. Expires 18 March 2027 [Page 13] Internet-Draft CATS Service Metrics Operation September 2026 time of collection so that the C-SMA or C-PS can configure a maximum acceptable staleness threshold). The default update interval is consistent with the "update-interval" parameter of the CATS YANG data model [I-D.yl-cats-data-model]. 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. A systematic analysis of the applicability of these protocols is provided in [I-D.yxl-cats-protocols-applicability]; this document does not mandate a specific transport mechanism. 6.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. 6.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, count) | | Computing Time | Estimated processing time in ms (float32) | | Price | Service price (optional, uint32) | | Reputation | Quality score 0-10 (optional, uint8) | | Security Level | Security score 0-10 (optional, uint8) | | Last Updated | Timestamp of last C-SMA report | | Expiry Time | Soft-state expiration time | +-------------------+------------------------------------------------+ Zhang, et al. Expires 18 March 2027 [Page 14] Internet-Draft CATS Service Metrics Operation September 2026 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. 6.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]. 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: Zhang, et al. Expires 18 March 2027 [Page 15] Internet-Draft CATS Service Metrics Operation September 2026 +-------------------+------------------------------------------------+ | 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. This document expresses network delay in milliseconds for consistency with Computing Time in the TST computation (see Section 6.2.3). Network performance metrics such as delay, jitter, and loss are typically distributed via IGP TE metric extensions for OSPF [RFC7471] and IS-IS [RFC8570], or via BGP-LS TE performance metric extensions [RFC8571], which use microseconds for delay values. When consuming such advertisements, the C-PS SHOULD convert the received values to a common time base (e.g., milliseconds) before populating the NST and computing TST, to avoid unit mismatches. 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. 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. 6.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 Zhang, et al. Expires 18 March 2027 [Page 16] Internet-Draft CATS Service Metrics Operation September 2026 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 Level: If the client or policy specifies a minimum security label S_min, remove all candidates where Security_Level < S_min. b. Reputation: If the client or policy specifies a minimum reputation R_min, remove all candidates where Reputation < R_min. c. Price: If the client or policy specifies a maximum price M_max, remove all candidates where Price > 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 6.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: 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: Zhang, et al. Expires 18 March 2027 [Page 17] Internet-Draft CATS Service Metrics Operation September 2026 * Computing_Time_i is from the CST entry for CSCI-ID_i. * Network_Delay_i is from the NST entry for Path_i. TST is the CATS instance of the Level 1 Composed category (end-to- end delay) of [I-D.ietf-cats-metric-definition-11], and corresponds to the "Joint Performance Measurement" (total latency = network transmission time + service processing time) defined in the CATS OAM framework [I-D.ietf-cats-oam-fw]. Computing_Time_i and Network_Delay_i MUST be expressed on the same time base (see Section 6.2.2). 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 6.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 explicitly designate one or more metrics as optimization objectives (i.e., find the best value for that metric), as opposed to constraints. Optimization objectives MUST be expressed as an explicit list in the client service requirement; they MUST NOT be inferred from a reserved metric value such as 0, because values such as Price = 0 (free service) or Security_Level = 0 (poorest security) are legitimate metric values. The C-PS processes optimization objectives in the following priority order: 1. Optimize Security Level: Optimal_CSCI-ID = argmax_{i in Candidate_Set} (Security_Level_i) Zhang, et al. Expires 18 March 2027 [Page 18] Internet-Draft CATS Service Metrics Operation September 2026 2. Optimize Reputation: Optimal_CSCI-ID = argmax_{i in Candidate_Set} (Reputation_i) 3. Optimize Price (minimize): Optimal_CSCI-ID = argmin_{i in Candidate_Set} (Price_i) 4. Optimize GAS: Optimal_CSCI-ID = argmax_{i in Candidate_Set} (GAS_i) 5. Optimize Bandwidth: Optimal_CSCI-ID = argmax_{i in Candidate_Set} (Bandwidth_i) 6. Optimize Jitter (minimize): Optimal_CSCI-ID = argmin_{i in Candidate_Set} (Jitter_i) 7. Optimize Loss Rate (minimize): Optimal_CSCI-ID = argmin_{i in Candidate_Set} (Loss_Rate_i) 8. Optimize Latency (minimize): 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 Price (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 18 March 2027 [Page 19] Internet-Draft CATS Service Metrics Operation September 2026 +-------------------------+ +-------------------------+ | Computing Service Table | | Network Service Table | | (CS-ID, CSCI-ID, GAS, | | (Ingress, Egress, | | Comp Time, Price, 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, Price, 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 2: Joint Selection Algorithm Data Flow 6.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 18 March 2027 [Page 20] Internet-Draft CATS Service Metrics Operation September 2026 Weighted Objective Function: The C-PS MAY use a weighted objective function that combines multiple metrics: Score_i = w1 * n(TST_i) + w2 * n(Price_i) + w3 * (1 - n(GAS_i)) + w4 * (1 - n(Reputation_i)) + w5 * (1 - n(Security_Level_i)) + w6 * (1 - n(Bandwidth_i)) + w7 * n(Loss_Rate_i) + w8 * n(Jitter_i) Where w1, w2, w3, w4, w5, w6, w7, w8 are non-negative weights configured by the manager, and n(x) denotes min-max normalization of each metric to the range [0,1] based on implementation- configured minimum and maximum expected values per metric (when max = min, n(x) = 0.5). Terms for metrics that are maximized (GAS, Reputation, Security Level, Bandwidth) are expressed as (1 - n(value)) so that a better value contributes a lower score; reciprocal terms such as 1/GAS are avoided because zero is a legitimate value for some metrics (e.g., Security Level = 0, Price = 0) and would cause division by zero. Because all terms are unitless and bounded, weights can be compared and configured meaningfully. 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. * Price Budget: Price_i <= Price_max. Remove candidates exceeding the maximum acceptable price. * 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). Zhang, et al. Expires 18 March 2027 [Page 21] Internet-Draft CATS Service Metrics Operation September 2026 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. * 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. 6.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 Price threshold by 20%. 2. Decrease the acceptable Security Level 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). Zhang, et al. Expires 18 March 2027 [Page 22] Internet-Draft CATS Service Metrics Operation September 2026 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. 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. 7. 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. In these examples, ARS, VRS, and LLMS denote an Augmented Reality service, a Virtual Reality service, and a Large Language Model inference service, respectively; they are illustrative service names used as CS-IDs, not router models. 7.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 18 March 2027 [Page 23] Internet-Draft CATS Service Metrics Operation September 2026 Service Site 2 (SS2) Service Site 3 (SS3) +------------------+ +------------------+ | SCI-1: ARS | | SCI-3: ARS | | 188.3.67.3:67 | | 188.3.67.4:69 | | GAS=400, CT=5 | | GAS=600, CT=6 | | Price=10 | | Price=5 | | | | | | SCI-2: VRS | | SCI-4: LLMS | | 188.3.67.3:68 | | 188.3.67.4:70 | | GAS=100, CT=15 | | GAS=300, CT=12 | | Price=20 | | Price=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 18 March 2027 [Page 24] Internet-Draft CATS Service Metrics Operation September 2026 +=======+===================+=====+===============+===================+ | CS-ID | CSCI-ID (IP:Port) | GAS | Comp Time(ms) | Price (Optional) | +=======+===================+=====+===============+===================+ | ARS | 188.3.67.3:67 | 400 | 5 | 10 | +-------+-------------------+-----+---------------+-------------------+ | VRS | 188.3.67.3:68 | 100 | 15 | 20 | +-------+-------------------+-----+---------------+-------------------+ | ARS | 188.3.67.4:69 | 600 | 6 | 5 | +-------+-------------------+-----+---------------+-------------------+ | LLMS | 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. 7.2. Scenario A: Normal Operation with Balanced Load A client at Ingress CATS-Forwarder 1 (10.0.0.1) requests the ARS 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 = "ARS". Candidates: * CSCI-ID 188.3.67.3:67 (SS2, GAS=400, CT=5ms, Price=10) * CSCI-ID 188.3.67.4:69 (SS3, GAS=600, CT=6ms, Price=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 price 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 18 March 2027 [Page 25] Internet-Draft CATS Service Metrics Operation September 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. 7.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 ARS request: Zhang, et al. Expires 18 March 2027 [Page 26] Internet-Draft CATS Service Metrics Operation September 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 ARS 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. 7.4. Scenario C: Service Site Degradation and Failover Suppose Service Site 3 experiences a partial failure: SCI-3 (ARS) 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) | Price (Optional) | +=======+===================+=====+===============+===================+ | ARS | 188.3.67.3:67 | 400 | 5 | 10 | +-------+-------------------+-----+---------------+-------------------+ | VRS | 188.3.67.3:68 | 100 | 15 | 20 | +-------+-------------------+-----+---------------+-------------------+ | ARS | 188.3.67.4:69 | 50 | 25 | 5 | <-- changed +-------+-------------------+-----+---------------+-------------------+ | LLMS | 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 ARS 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 18 March 2027 [Page 27] Internet-Draft CATS Service Metrics Operation September 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) | Price (Optional) | +=======+===================+=====+===============+===================+ | ARS | 188.3.67.3:67 | 400 | 5 | 10 | +-------+-------------------+-----+---------------+-------------------+ | VRS | 188.3.67.3:68 | 100 | 15 | 20 | +-------+-------------------+-----+---------------+-------------------+ | ARS | 188.3.67.4:69 | 0 | 25 | 5 | <-- GAS=0 +-------+-------------------+-----+---------------+-------------------+ | LLMS | 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 ARS candidates have GAS = 0 (e.g., both sites fail), the C-PS triggers Fallback Level 2 (Section 6.2.5): it falls back to pure network-based steering or returns a "Service Unavailable" indication to the client. 7.5. Scenario D: Multi-Objective Optimization with Price Constraint Consider a client request for ARS with the following policy: * Primary objective: Minimize Total Service Time. * Hard constraint: Price <= 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 18 March 2027 [Page 28] Internet-Draft CATS Service Metrics Operation September 2026 Computing Service Table (CST): +=======+===================+=====+===============+===================+ | CS-ID | CSCI-ID (IP:Port) | GAS | Comp Time(ms) | Price (Optional) | +=======+===================+=====+===============+===================+ | ARS | 188.3.67.3:67 | 400 | 5 | 10 | +-------+-------------------+-----+---------------+-------------------+ | ARS | 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 Price <= 8: * 188.3.67.3:67 has Price = 10 -> EXCLUDED. * 188.3.67.4:69 has Price = 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 (Price <= 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 price. Now suppose the client policy changes to Price <= 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 18 March 2027 [Page 29] Internet-Draft CATS Service Metrics Operation September 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). 8. 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. These mechanisms are consistent with the scalability considerations of [I-D.ietf-cats-metric-definition-11] (Section 3.1) and with the CATS OAM framework [I-D.ietf-cats-oam-fw] (O-REQ-1: balanced periodic and threshold-triggered reporting; O-REQ-4: freshness handling). 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 Zhang, et al. Expires 18 March 2027 [Page 30] Internet-Draft CATS Service Metrics Operation September 2026 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 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. 9. Security Considerations This section complements the general security requirements for CATS metrics defined in Section 7 of [I-D.ietf-cats-metric-definition-11]: integrity (SEC-1), authenticity (SEC-2), controllability (SEC-3), freshness (SEC-4), and confidentiality (SEC-5). The requirements below are specific to the Computing Service Metrics and the Joint Selection Algorithm defined in this document; they MUST be applied in addition to, and consistent with, the general requirements. The dynamic reporting of Service Metrics introduces potential attack vectors. Authentication mechanisms between service sites and C-SMAs MUST be enforced. The Security Level (Section 5.4.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 Zhang, et al. Expires 18 March 2027 [Page 31] Internet-Draft CATS Service Metrics Operation September 2026 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 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. Price Manipulation: While Price is self-defined by the service site, a provider could temporarily set an artificially low price to capture market share and then raise it abruptly. The C-PS MAY implement price-change dampening (e.g., ignoring price increases above a threshold within a short time window) to protect clients from bait-and-switch tactics. Security Level Misrepresentation: The Security Level 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 Level 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. Zhang, et al. Expires 18 March 2027 [Page 32] Internet-Draft CATS Service Metrics Operation September 2026 10. IANA Considerations This section follows the guidelines in [RFC8126]. 10.1. CATS Computing Service Metrics [I-D.ietf-cats-metric-definition-11] requests IANA to create the "CATS Metrics" registry under the "Computing-Aware Traffic Steering (CATS)" heading. To keep a single point of registration for CATS metrics, this document does not request a separate registry. Instead, the service-oriented metric entries defined in this document (GAS, Computing Time, Price, Reputation, and Security Level) are registered as entries in the "CATS Metrics" registry, in a dedicated "Computing Service Metrics" section of that registry. Each registry entry contains the following fields: * Identifier: A unique integer assigned by IANA. * 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 these entries is "IETF Review" [RFC8126], consistent with the CATS metric framework, because the entries influence traffic steering decisions. The policy is aligned between this document and the companion registry document [I-D.zhangb-cats-service-metric-registry-entries]. The initial entries are listed below. 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. The naming convention follows the pattern defined in that document ("Svc_" prefix), extending the "Norm_"/"Comb_" naming of [I-D.ietf-cats-metric-definition-11] to service-oriented metrics that are not normalized scores (e.g., GAS) or that are score attributes (e.g., Reputation). Zhang, et al. Expires 18 March 2027 [Page 33] Internet-Draft CATS Service Metrics Operation September 2026 +------------+---------------------------------------+ | Identifier | Metric Name (short) | +------------+---------------------------------------+ | TBD1 | GAS | | TBD2 | Computing Time | | TBD3 | Price | | TBD4 | Reputation | | TBD5 | Security Level | +------------+---------------------------------------+ Note: The allocation of identifiers and the exact relationship between this registry section and the "CATS Metrics" registry are to be finalized in coordination with the CATS working group before publication. 11. References 11.1. Normative 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, . [I-D.ietf-cats-metric-definition-11] 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-11, 4 September 2026, . [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997, . [RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for Writing an IANA Considerations Section in RFCs", RFC 8126, June 2017, . [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, May 2017, . 11.2. Informative References Zhang, et al. Expires 18 March 2027 [Page 34] Internet-Draft CATS Service Metrics Operation September 2026 [I-D.ietf-cats-oam-fw] Fu, H., Xiong, Q., Du, Z., Liu, B., and Z. Li, "Computing- Aware Traffic Steering (CATS) Operations, Administration, and Maintenance (OAM) Framework", Work in Progress, Internet-Draft, draft-ietf-cats-oam-fw-01, 21 July 2026, . [I-D.yl-cats-data-model] Yao, H., Lin, C., Li, Z., Xiong, Q., and L. M. Contreras, "Data Model for Computing-Aware Traffic Steering (CATS)", Work in Progress, Internet-Draft, draft-yl-cats-data- model-07, 6 July 2026, . [I-D.yxl-cats-protocols-applicability] Yao, H., Dunbar, L., Xiong, Q., and C. Lin, "Protocols Applicability for Computing-Aware Traffic Steering (CATS)", Work in Progress, Internet-Draft, draft-yxl-cats- protocols-applicability-01, 2 July 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, . Zhang, et al. Expires 18 March 2027 [Page 35] Internet-Draft CATS Service Metrics Operation September 2026 [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, . [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, . [RFC8911] Bagnulo, M., Claise, B., Eardley, P., Morton, A., and A. Akhter, "Registry for Performance Metrics", RFC 8911, November 2021, . [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 Zhang, et al. Expires 18 March 2027 [Page 36] Internet-Draft CATS Service Metrics Operation September 2026 Guanming Zeng Huawei Technologies Email: zengguanming@huawei.com Chuanyang Miao (editor) ZTE Corporation Email: miao.chuanyang@zte.com.cn Zhang, et al. Expires 18 March 2027 [Page 37]