Computing Service Metrics Operation and Joint Service Selection under CATS

The Computing-Aware Traffic Steering (CATS) architecture 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). 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 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. 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 , while their definitions remain in this document and its companion registry document , following the pattern of a shared registry with document-specific entry definitions (cf. ). 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.

This document makes use of the terms defined in and . 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 . 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.

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 when, and only when, they appear in all capitals, as shown here.

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: 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. 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. 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?". 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. 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.

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 . This document focuses on the semantics and operational use of these metrics, rather than defining new routing, transport, signaling, or wire-encoding mechanisms.

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).

+------------------+---------------------------------------------------+ | 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); | +------------------+---------------------------------------------------+ 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 , 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 ), 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 . 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. 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 operates directly on these values. The metric entries defined in this document are registered in the "CATS Metrics" registry established by (see ), while their definitions remain in this document and its companion registry document . 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.

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 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 and 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. 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 . This is consistent with the guidance in Section 5.4 of that consistent normalization and aggregation functions be enabled across all involved CATS components so that service contact instance selection is fair among candidates.

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.

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. 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

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 ). 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

To accommodate advanced traffic-steering scenarios, the following optional fields are defined.

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 ). 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

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 (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

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 (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

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 : 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 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 . Choosing appropriate protocols for conveying CATS metrics is important. For distributed systems, existing routing protocols such as BGP extensions and GRASP 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 , 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 ; this document does not mandate a specific transport mechanism.

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.

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:

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 or IGP TE extensions . 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: Filtering: Extracts paths relevant to the CATS domain and the set of Egress CATS-Forwarders. Aggregation: Computes path-level metrics (e.g., one-way delay, available bandwidth) from link-level TEDB data. 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. This document expresses network delay in milliseconds for consistency with Computing Time in the TST computation (see ). Network performance metrics such as delay, jitter, and loss are typically distributed via IGP TE metric extensions for OSPF and IS-IS , or via BGP-LS TE performance metric extensions , 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 and IS-IS , or via BGP-LS TE performance metric extensions . The C-PS can consume these standard protocol advertisements to populate the NST.

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: 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 } The C-PS applies hard constraints to eliminate infeasible candidates: Security Level: If the client or policy specifies a minimum security label S_min, remove all candidates where Security_Level < S_min. Reputation: If the client or policy specifies a minimum reputation R_min, remove all candidates where Reputation < R_min. Price: If the client or policy specifies a maximum price M_max, remove all candidates where Price > M_max. 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 (). 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. 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. TST is the CATS instance of the Level 1 Composed category (end-to-end delay) of , and corresponds to the "Joint Performance Measurement" (total latency = network transmission time + service processing time) defined in the CATS OAM framework . Computing_Time_i and Network_Delay_i MUST be expressed on the same time base (see ). The C-PS applies network-side hard constraints to eliminate infeasible candidates: Bandwidth: If the client or policy specifies a minimum bandwidth BW_min, remove all candidates where Bandwidth < BW_min. Jitter: If the client or policy specifies a maximum jitter J_max, remove all candidates where Jitter > J_max. Loss Rate: If the client or policy specifies a maximum loss rate LR_max, remove all candidates where Loss_Rate > LR_max. 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 (). 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: Optimize Security Level: Optimal_CSCI-ID = argmax_{i in Candidate_Set} (Security_Level_i) Optimize Reputation: Optimal_CSCI-ID = argmax_{i in Candidate_Set} (Reputation_i) Optimize Price (minimize): Optimal_CSCI-ID = argmin_{i in Candidate_Set} (Price_i) Optimize GAS: Optimal_CSCI-ID = argmax_{i in Candidate_Set} (GAS_i) Optimize Bandwidth: Optimal_CSCI-ID = argmax_{i in Candidate_Set} (Bandwidth_i) Optimize Jitter (minimize): Optimal_CSCI-ID = argmin_{i in Candidate_Set} (Jitter_i) Optimize Loss Rate (minimize): Optimal_CSCI-ID = argmin_{i in Candidate_Set} (Loss_Rate_i) 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: Highest GAS (prefer sites with more available capacity). Lowest Price (prefer cheaper sites). Highest Reputation (prefer higher-quality sites). Random selection among remaining ties. 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:

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. 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. 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. For scalability, the C-PS MAY perform hierarchical selection: First, select the best Egress CATS-Forwarder based on network metrics alone (e.g., minimum Network Delay). 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. 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.

When the Joint Selection Algorithm cannot produce a valid candidate, the C-PS MUST execute fallback procedures: If the Candidate_Set is empty after applying constraints, the C-PS MAY apply some implementation-specific relaxation policies, for example: Increase the acceptable Price threshold by 20%. Decrease the acceptable Security Level by 1 point. Decrease the minimum Reputation threshold by 1 point. Decrease the minimum GAS threshold by 1 point. Decrease the acceptable Bandwidth threshold by 20%. Increase the acceptable Jitter threshold by 20%. Increase the acceptable Loss Rate threshold by 20%. Increase the acceptable Latency threshold by 20%. Accept DEGRADED service sites (if previously excluded). Re-run the Joint Selection Algorithm with relaxed constraints. 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. 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. 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: Marks the CSCI-ID as unavailable in the CST (GAS = 0). Re-runs the Joint Selection Algorithm for new requests. For existing affined sessions, the C-PS MAY either: Migrate the session to the new optimal CSCI-ID (if the service protocol supports it), or Terminate the session and require the client to re-establish.

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.

Consider a CATS domain with three service sites providing computing services. The topology is as follows:

A client at Ingress CATS-Forwarder 1 (10.0.0.1) requests the ARS service with the requirement for the shortest Total Service Time. 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. No hard constraints are applied in this scenario (no minimum security label, reputation, or price limits). Both candidates remain. 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. 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. 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. 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. 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.

Suppose the network path to Service Site 3 experiences congestion, and the C-NMA updates the NST: Updated Network Service Table (NST):

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: Candidates: 188.3.67.3:67 (GAS=400) and 188.3.67.4:69 (GAS=50). Both have GAS > 0, so both remain. Candidate 188.3.67.3:67: TST = 5 ms + 8 ms = 13 ms. Candidate 188.3.67.4:69: TST = 25 ms + 6 ms = 31 ms. 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 | +-------+-------------------+-----+---------------+-------------------+ 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 (): it falls back to pure network-based steering or returns a "Service Unavailable" indication to the client.

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): Computing Service Table (CST):

+========================+=======================+============+ | 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 | +------------------------+-----------------------+------------+ Candidates: 188.3.67.3:67 and 188.3.67.4:69. 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 }. 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: 188.3.67.3:67: TST = 5 ms + 8 ms = 13 ms. 188.3.67.4:69: TST = 6 ms + 6 ms = 12 ms. 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).

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 (Section 3.1) and with the CATS OAM framework (O-REQ-1: balanced periodic and threshold-triggered reporting; O-REQ-4: freshness handling). 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). 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. 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. 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.

This section complements the general security requirements for CATS metrics defined in Section 7 of : 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 () 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: 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. 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. 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. 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. 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. 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.

This section follows the guidelines in .

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" , 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 . 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 , 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 to service-oriented metrics that are not normalized scores (e.g., GAS) or that are score attributes (e.g., Reputation).

+------------+---------------------------------------+ | 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.