Computing Service Metric Definitions and Operation 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 achieve this, 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, Level 2) and proposes normalizing heterogeneous computing metrics into unitless scores (e.g., compute_norm). While this establishes a solid theoretical baseline, mapping diverse hardware capabilities (CPUs, GPUs, NPUs) into a single normalized score is highly complex and provider-dependent. In practice, additional service-oriented abstractions are useful for expressing the actual service capacity needed for fine-grained traffic steering. To fill the gap between theoretical metric definitions and practical implementation, this document introduces a set of Computing Service Metrics. By decoupling the service capacity from hardware-specific raw metrics, service sites can directly expose actionable metrics that describe their concrete ability to handle specific services. These metrics complement the existing normalized metric framework and focus on operational use under the CATS architecture. Another key contribution of this document is the specification of how the C-PS combines the Computing Service Table (built from C-SMA reports) with the Network Service Table to make joint traffic-steering decisions that simultaneously optimize computing and network performance.

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. 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 CATS working group has made significant progress in defining how computing metrics should be collected and distributed. In particular, existing works introduce a comprehensive framework that categorizes computing metrics into Raw Metrics (Level 0) and Normalized Metrics (Level 1 and Level 2). However, a critical gap remains: how exactly to use these hardware-centric metrics to effectively steer traffic in operational networks. This document does not negate the value of L1/L2 normalized metrics; rather, it identifies that relying solely on the normalization of raw hardware metrics poses operational challenges during routing execution: The Implementation Gap (HOW to normalize?): In a real-world multi-vendor network, computing resources are highly heterogeneous. It is extremely difficult to establish a unified mathematical model that fairly normalizes a GPU's capacity and a CPU's capacity into the same 0-10 score. The Information Loss Gap (WHY disseminate raw features?): Normalizing diverse hardware capabilities into a single unitless score results in the loss of actionable information. A normalized compute score of "7" cannot explicitly guarantee a client's <10 ms delay requirement. The Routing Mechanism Gap (WHO uses this data?): Routers (C-PS) do not need to know whether a service is backed by a CPU or a GPU. They only care about routing parameters: "Is there capacity?", "How long will it take?", and "Where is the destination?". The Joint Decision Gap (HOW to combine?): Even when both computing metrics and network metrics are available, existing drafts do not specify how the C-PS should combine them to make a unified steering decision. Simply selecting the service site with the best computing metrics may result in a poor network path, and vice versa. To bridge these gaps, CATS requires a Service-Oriented Abstraction and a clear Joint Selection Algorithm. We explicitly divide the required service information into Mandatory Computing Service Metrics and Optional Extension Metrics, and we specify how the C-PS combines the Computing Service Table with the Network Service Table to support executable traffic-steering policies.

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.

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.

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. Basic fields:

Metric Type: gas Level: Level 0 Format: unsigned integer Length: two octets 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. Basic fields:

Metric Type: comp_time Level: Level 0 Format: floating point Length: four octets Unit: ms Value: 5 Source: estimation

To accommodate advanced traffic-steering scenarios and maintain backward compatibility, the following optional fields are defined.

Self-defined by the service site to apply administrative or economic billing policies. Cost is used as a constraint or secondary objective in the Joint Selection Algorithm (see ). Basic fields:

Metric Type: cost Level: Level 0 Format: unsigned integer Length: two octets 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. Basic fields:

Metric Type: reputation Level: Level 0 Format: unsigned integer Length: two octets Value: 8 Source: nominal

The Security Label reflects the security status of a service site. A higher score indicates a more secure site. The Security Label is used as a constraint in the Joint Selection Algorithm: a C-PS MUST NOT select a service contact instance with a Security Label below the client's minimum requirement. Score range: 0-10 (0 indicates the poorest security; 10 indicates optimal security). Basic fields:

Metric Type: security_label Level: Level 0 Format: unsigned integer Length: two octets Value: 7 Source: nominal

To maintain compatibility with L1/L2 normalized metrics, this optional field represents the overall computing and storage capability allocated by the site. It can correspond to a Level 1 or Level 2 overall capability score when such a normalized value is available. Basic fields:

Metric Type: site_cap Level: Level 1/Level 2 Format: unsigned integer Length: one octet Source: normalization Value: 7

Service sites proactively monitor their internal instances. In large-scale deployments, service sites can use a delta-threshold reporting model. Each service site or C-SMA maintains a local metric cache. Per-session allocation and release events update local GAS values, but do not necessarily trigger immediate reports to the C-PS. Updates are reported when they become operationally significant. Examples include GAS crossing a configured threshold, Computing Time deviating beyond a configured percentage band, or health status changing due to failure, attack detection, or unreachability. A periodic heartbeat or soft-state synchronization can also be used to refresh the C-PS view and avoid stale metrics even when no trigger event occurs. Choosing appropriate protocols for conveying CATS metrics is important. For distributed systems, existing routing protocols such as BGP extensions 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.

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. 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 Label: If the client or policy specifies a minimum security label S_min, remove all candidates where Security_Label < S_min. Reputation: If the client or policy specifies a minimum reputation R_min, remove all candidates where Reputation < R_min. Cost: If the client or policy specifies a maximum cost M_max, remove all candidates where Cost > 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. 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 indicate that a specific metric should be optimized rather than constrained. A reserved value of 0 in a service requirement metric indicates an optimization objective (i.e., find the best value for that metric) rather than a threshold. The C-PS processes optimization objectives in the following priority order: Security Label = 0: Optimal_CSCI-ID = argmax_{i in Candidate_Set} (Security_Label_i) Reputation = 0: Optimal_CSCI-ID = argmax_{i in Candidate_Set} (Reputation_i) Cost = 0: Optimal_CSCI-ID = argmin_{i in Candidate_Set} (Cost_i) GAS = 0: Optimal_CSCI-ID = argmax_{i in Candidate_Set} (GAS_i) Bandwidth = 0: Optimal_CSCI-ID = argmax_{i in Candidate_Set} (Bandwidth_i) Jitter = 0: Optimal_CSCI-ID = argmin_{i in Candidate_Set} (Jitter_i) Loss Rate = 0: Optimal_CSCI-ID = argmin_{i in Candidate_Set} (Loss_Rate_i) Latency = 0: Optimal_CSCI-ID = argmin_{i in Candidate_Set} (TST_i) If no optimization objectives are specified (i.e., no reserved zero values), the C-PS applies soft constraints and preference rules listed in the client service requirement. The processing of soft constraints follows the same logic as hard constraints, but violation of a soft constraint does not eliminate a candidate; instead, it contributes to a penalty in the candidate's score. If still multiple candidates exist after optimization and soft-constraint processing, the C-PS applies tie-breaking rules in the following priority: Highest GAS (prefer sites with more available capacity). Lowest Cost (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 * TST_i + w2 * Cost_i + w3 * (1 / GAS_i)+ w4 * (1 / Reputation_i) + w5 * (1 / Security_Label_i) + w6 * (1 / Bandwidth_i) + w7 * Loss_Rate_i + w8 * Jitter_i Where w1, w2, w3, w4, w5, w6, w7, w8 are non-negative weights configured by the manager. The C-PS selects the candidate with the minimum Score_i. By default, w1 = 1 and w2 = w3 = w4 = w5 = w6 = w7= w8= 0 (pure TST minimization). Weights are normalized such that each term contributes proportionally to its configured priority. Instead of (or in addition to) optimization, the C-PS MAY apply constraint-based selection: Delay Budget: TST_i <= TST_max. Remove candidates exceeding the maximum acceptable total service time. Cost Budget: Cost_i <= Cost_max. Remove candidates exceeding the maximum acceptable cost. Bandwidth Requirement: Bandwidth_i >= BW_min. Remove candidates that cannot provide sufficient network bandwidth. Affinity Requirement: If the client requires session affinity to a previously selected CSCI-ID, and that CSCI-ID is still in the Candidate_Set, the C-PS MAY bypass the optimization and select the affined CSCI-ID directly. 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 Cost threshold by 20%. Decrease the acceptable Security Label 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.

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 AR1 service with the requirement for the shortest Total Service Time. The C-PS queries the CST for CS-ID = "AR1". Candidates: CSCI-ID 188.3.67.3:67 (SS2, GAS=400, CT=5ms, Cost=10) CSCI-ID 188.3.67.4:69 (SS3, GAS=600, CT=6ms, Cost=5) Both have GAS > 0 and are not expired. No hard constraints are applied in this scenario (no minimum security label, reputation, or cost 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 (AR1) becomes DEGRADED, and its GAS drops from 600 to 50. The C-SMA at Service Site 3 reports the updated metrics to the C-PS: Updated Computing Service Table (CST):

+=======+===================+=====+===============+=================+ | CS-ID | CSCI-ID (IP:Port) | GAS | Comp Time(ms) | Cost (Optional) | +=======+===================+=====+===============+=================+ | AR1 | 188.3.67.3:67 | 400 | 5 | 10 | +-------+-------------------+-----+---------------+-----------------+ | AR2 | 188.3.67.3:68 | 100 | 15 | 20 | +-------+-------------------+-----+---------------+-----------------+ | AR1 | 188.3.67.4:69 | 50 | 25 | 5 | <-- changed +-------+-------------------+-----+---------------+-----------------+ | LLM1 | 188.3.67.4:70 | 300 | 12 | 15 | +-------+-------------------+-----+---------------+-----------------+ Note: Computing Time increased to 25 ms due to degraded performance. The C-PS re-evaluates the AR1 request: 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) | Cost (Optional) | +=======+===================+=====+===============+=================+ | AR1 | 188.3.67.3:67 | 400 | 5 | 10 | +-------+-------------------+-----+---------------+-----------------+ | AR2 | 188.3.67.3:68 | 100 | 15 | 20 | +-------+-------------------+-----+---------------+-----------------+ | AR1 | 188.3.67.4:69 | 0 | 25 | 5 | <-- GAS=0 +-------+-------------------+-----+---------------+-----------------+ | LLM1 | 188.3.67.4:70 | 300 | 12 | 15 | +-------+-------------------+-----+---------------+-----------------+ Candidate 188.3.67.4:69 has GAS = 0 and is filtered out. Only 188.3.67.3:67 remains. The C-PS selects 188.3.67.3:67 as the only available candidate. This scenario demonstrates automatic failover when a service site becomes unavailable. If ALL AR1 candidates have GAS = 0 (e.g., both sites fail), the C-PS triggers Fallback Level 2 (): it falls back to pure network-based steering or returns a "Service Unavailable" indication to the client.

Consider a client request for AR1 with the following policy: Primary objective: Minimize Total Service Time. Hard constraint: Cost <= 8. Secondary objective: Maximize GAS (prefer sites with more available capacity). The CST and NST are as in the initial state (Scenario A): 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 Cost <= 8: 188.3.67.3:67 has Cost = 10 -> EXCLUDED. 188.3.67.4:69 has Cost = 5 -> RETAINED. Candidate_Set = { 188.3.67.4:69 }. The C-PS computes TST for the remaining candidate: TST = 6 ms + 6 ms = 12 ms. Only one candidate remains, so 188.3.67.4:69 is selected. This scenario demonstrates how hard constraints (Cost <= 8) filter out expensive candidates before optimization. Even though 188.3.67.3:67 has a slightly better computing time (5 ms vs. 6 ms), it is excluded due to cost. Now suppose the client policy changes to Cost <= 12 (relaxing the constraint). Both candidates are eligible: 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. 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.

The dynamic reporting of Service Metrics introduces potential attack vectors. Authentication mechanisms between service sites and C-SMAs MUST be enforced. The Security Label () 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 Cost is self-defined by the service site, a provider could temporarily set an artificially low cost to capture market share and then raise it abruptly. The C-PS MAY implement cost-change dampening (e.g., ignoring cost increases above a threshold within a short time window) to protect clients from bait-and-switch tactics. The Security Label is self-reported by the service site. A compromised site could claim a high security score while actually being vulnerable. The C-PS SHOULD verify security claims through independent audits, trusted third-party attestations, or automated security scanning where available. A Security Label without external validation SHOULD be treated as a hint rather than a guarantee. 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 requests IANA to create a new registry and follows the guidelines in .

IANA is requested to create a new registry titled "CATS Computing Service Metrics" under the existing "Computing-Aware Traffic Steering (CATS)" registry heading. Each registry entry contains the following fields: Identifier: A unique integer assigned by IANA. Name: The formal metric name. URI: A stable URI reference for the metric entry. Description: A brief description of the metric. Change Controller: The entity responsible for the metric definition (IETF for entries defined in this document and its companion registry document). Version: The version of the metric definition. The registration policy for this registry is "Specification Required" . New entries require a publicly available specification document. The initial entries for this registry are as follows. Full registry definitions (including Summary, Metric Definition, Method of Measurement, Output, and Administrative Items) are provided in the companion document , which serves as the authoritative specification for the initial entries.

+------------+------------------+ | Identifier | Metric Name | +------------+------------------+ | TBD1 | GAS | | TBD2 | Computing Time | | TBD3 | Cost | | TBD4 | Reputation | | TBD5 | Security Label | | TBD6 | Capability | +------------+------------------+