Computing Service Metrics Operation and Joint Service Selection under CATS

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

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

The 0-10 range uses the same three score bands as the registered normalized metrics in Section 6 of [I-D.ietf-cats-metric-definition-13]: 0-3 indicates poor reputation (avoid if alternatives exist), 4-7 average (acceptable for steering), and 8-10 excellent (preferred for steering). Reputation remains an optional service attribute in this document, not a Level 1 or Level 2 normalized metric.¶

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

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). The range uses the same three score bands as the registered normalized metrics in Section 6 of [I-D.ietf-cats-metric-definition-13]: 0-3 indicates low security posture (not recommended for sensitive traffic), 4-7 medium (acceptable for general traffic), and 8-10 high (preferred for sensitive or regulated traffic). Security Level remains an optional service attribute in this document, not a Level 1 or Level 2 normalized metric.¶

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.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, uint16)               |
| 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                     |
+-------------------+------------------------------------------------+

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 decisions. In an SDN realization, the NST can be derived from the 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]. Other centralized implementations, including a PCE, can provide an equivalent path-computation view.¶

In the reference architecture, the C-PS accesses the NST rather than the raw TEDB, though implementations MAY co-locate these functions. Instead, a NST Generator component performs the following steps:¶

1. Filtering: Extracts paths relevant to the CATS domain and the set of Egress CATS-Forwarders.¶

2. Aggregation: Computes path-level metrics (e.g., one-way delay, available bandwidth) from link-level TEDB data.¶

3. Indexing: Re-indexes the information by (Ingress CF, Egress CF) pair for fast lookup.¶

The NST MAY be cached and periodically refreshed based on TEDB updates, or MAY be generated on-the-fly based on the current TEDB snapshot. The NST contains one entry per (Ingress, Egress) pair, representing the network path from the client's Ingress CATS-Forwarder to the Egress CATS-Forwarder that connects to the service site. The specific implementation is a local matter.¶

Each entry contains the following fields:¶

+-------------------+------------------------------------------------+
| Field             | Description                                    |
+-------------------+------------------------------------------------+
| Ingress CF        | Ingress CATS-Forwarder identifier              |
| Egress CF         | Egress CATS-Forwarder identifier               |
| Network Delay     | One-way delay in ms (uint32)                   |
| Jitter            | Delay variation in ms (uint32, optional)       |
| Bandwidth         | Available bandwidth in Mbps (uint32, optional) |
| Loss Rate         | Packet loss rate in ppm (uint32, optional)     |
| Path Attributes   | TE attributes (e.g., affinity, color)          |
| Last Updated      | Timestamp of last C-NMA report                 |
+-------------------+------------------------------------------------+

The service node may be outside the ingress domain, so this document does not require measuring delay directly from the ingress to the service node. Instead, the Network Delay represents the path from the Ingress CATS-Forwarder to the Egress CATS-Forwarder.¶

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 in the Centralized CATS Model

The algorithm in this section applies to the centralized CATS model described in Section 5.3 of [RFC10053]. For an incoming service request, logically centralized path-computation logic, such as a PCE, processes the requirements associated with that request and combines computing-related metrics from C-SMAs with network metrics from C-NMAs to compute candidate paths to service contact instances. Based on these metrics and paths, the centralized C-PS jointly selects the appropriate CSCI-ID and associated path and synchronizes the result with the relevant C-TC. Procedures for distributed or hybrid selection, or for precomputing paths independently of an incoming service request, are outside the scope of this algorithm.¶

When a service request received by an Ingress CATS-Forwarder is presented to the centralized C-PS, the C-PS executes the following Joint Selection Algorithm to determine the selected CSCI-ID and associated path:¶

Step 1: Service Lookup (Computing Filter)

The C-PS queries the CST using the requested CS-ID. It retrieves all entries matching the CS-ID. Entries with GAS = 0 or expired entries are discarded. This produces the Candidate Set:¶

                    Candidate_Set = { (CSCI-ID_i, GAS_i, CompTime_i, ...) |
                    CST[CS-ID, CSCI-ID_i] exists AND
                    CST.GAS > 0 AND
                    CST.Expiry > now }

¶

Step 2: Computing Constraint Filtering (Hard Constraints)

The C-PS applies hard constraints to eliminate infeasible candidates:¶

1. Security Level: If the client or policy specifies a minimum security label S_min, remove all candidates where Security_Level < S_min.¶

2. Reputation: If the client or policy specifies a minimum reputation R_min, remove all candidates where Reputation < R_min.¶

3. Price: If the client or policy specifies a maximum price M_max, remove all candidates where Price > M_max.¶

4. 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:¶

• Computing_Time_i is from the CST entry for CSCI-ID_i.¶

• Network_Delay_i is from the NST entry for Path_i.¶

TST has semantic correspondence to the Level 1 Composed category (end-to-end delay) of [I-D.ietf-cats-metric-definition-13], 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:¶

1. Bandwidth: If the client or policy specifies a minimum bandwidth BW_min, remove all candidates where Bandwidth < BW_min.¶

2. Jitter: If the client or policy specifies a maximum jitter J_max, remove all candidates where Jitter > J_max.¶

3. Loss Rate: If the client or policy specifies a maximum loss rate LR_max, remove all candidates where Loss_Rate > LR_max.¶

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

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, 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 centralized C-PS returns the selected CSCI-ID and associated path or steering instructions to the Ingress CATS-Forwarder, synchronizing the result with the relevant C-TC as described in [RFC10053]. The Ingress CATS-Forwarder then forwards the client traffic along the selected path to the Egress CATS-Forwarder, which delivers it to the selected CSCI-ID.¶

The following figure illustrates the data flow and decision logic:¶

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

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

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

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

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:¶

   1. Migrate the session to the new optimal CSCI-ID (if the service protocol supports it), or¶

   2. Terminate the session and require the client to re-establish.¶