Computing Service Metric Definitions and Operation under CATS

4.2.1. Global Available Slots (GAS)

GAS is the core contribution of this metric framework. It represents the maximum number of concurrent requests/sessions that a service site is willing and able to serve for a specific CS-ID through a specific CSCI-ID at a given time.¶

Crucially, GAS acts as a direct abstraction layer over the complex and fluctuating raw computing metrics (CPU, GPU, Memory, Storage) and status metrics (load and health). Instead of exposing highly dynamic raw metrics to the network, the service site absorbs these variations internally. The site can initially provide a GAS value based on its fixed resource allocation and service reference information, and then adjust it according to local policy based on internal status metrics.¶

As the number of concurrent requests increases, the GAS value naturally decreases. Furthermore, the site monitoring system dynamically reduces the GAS value upon detecting abnormal status metrics, such as:¶

• Load changes: Sudden increase in internal resources occupied by local users or tasks.¶

• Health changes: Sudden performance drop, possibly due to a cyber attack.¶

• Reachability: The site crashes or becomes unresponsive.¶

Note: The C-SMA proactively reports significant adjustments to the control plane according to local policy, thresholds, or aggregation intervals. Small per-session changes do not necessarily need to be reported immediately. When GAS drops to 0, it means the instance cannot allocate any more resources, and no new requests will be steered to it.¶

Basic fields:¶

  Metric Type: gas
  Level: Level 0
  Format: unsigned integer
  Length: two octets
  Value: 500
  Source: estimation

4.2.2. Computing Time

The time required for the site to perform one service request. The service site can initialize this metric based on service reference information and then measure or estimate it according to the runtime behavior of the deployed service instance. The service site dynamically adjusts this metric based on real-time load and local policy.¶

Computing Time is a critical input to the Joint Selection Algorithm because it represents the processing latency component of the Total Service Time.¶

Basic fields:¶

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

4.3.1. Cost

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

Basic fields:¶

  Metric Type: cost
  Level: Level 0
  Format: unsigned integer
  Length: two octets
  Value: 100
  Source: nominal

4.3.2. Reputation

A dynamic quality score based on user feedback. Upon completion, if a user experiences long delays or inaccurate results, feedback is returned to the C-PS *along with the resource release message*. Reputation is used as a tie-breaker or threshold filter in the Joint Selection Algorithm.¶

Basic fields:¶

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

4.3.3. Security Label

The Security Label reflects the security status of a service site. A higher score indicates a more secure site. The Security Label is used as a constraint in the Joint Selection Algorithm: a C-PS MUST NOT select a service contact instance with a Security Label below the client's minimum requirement.¶

Score range: 0-10 (0 indicates the poorest security; 10 indicates optimal security).¶

Basic fields:¶

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

4.3.4. Capability (L1/L2 Compatibility)

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

Basic fields:¶

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

5.2.1. Computing Service Table Structure

The Computing Service Table (CST) is maintained by the C-PS and is populated from C-SMA reports. It contains one entry per (CS-ID, CSCI-ID) pair. Each entry contains the following fields:¶

+-------------------+------------------------------------------------+
| Field             | Description                                    |
+-------------------+------------------------------------------------+
| CS-ID             | The CATS Service Identifier                    |
| CSCI-ID           | The Service Contact Instance locator           |
|                   | (e.g., IP:Port)                                |
| GAS               | Global Available Slots (uint32)                |
| Computing Time    | Estimated processing time in ms (uint32)       |
| Cost              | Service cost (optional, uint32)                |
| Reputation        | Quality score 0-10 (optional, uint8)           |
| Security Label    | Security score 0-10 (optional, uint8)          |
| Capability        | L1/L2 normalized score (optional)              |
| Last Updated      | Timestamp of last C-SMA report                 |
| Expiry Time       | Soft-state expiration time                     |
+-------------------+------------------------------------------------+

The CST is indexed by CS-ID for fast lookup of all candidate CSCI-IDs for a given service. The C-PS MUST age out entries whose Expiry Time has passed, treating them as unreachable (GAS = 0).¶

The CST is logically separate from the Network Service Table to maintain separation of concerns between computing and network domains.¶

5.2.2. Network Service Table Structure

The Network Service Table (NST) is maintained by the C-PS and is populated from C-NMA reports. The NST is a logical data structure maintained by the C-PS, providing a view of network metrics tailored for CATS joint decision. In a SDN context, the NST is derived from the SDN controller's Traffic Engineering Database (TEDB), which aggregates network topology and performance information from the underlay network via protocols such as BGP-LS [RFC8571] or IGP TE extensions [RFC7471] [RFC8570].¶

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

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

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

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

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

Each entry contains the following fields:¶

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

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

The C-PS MUST ensure that the NST and CST are synchronized in time: when evaluating a candidate, the C-PS SHOULD use NST entries whose Last Updated timestamp is within a reasonable window of the CST entry's Last Updated timestamp (e.g., within 30 seconds) to avoid decisions based on stale combinations.¶

Network performance metrics such as delay, jitter, and loss can be distributed via IGP TE metric extensions for OSPF [RFC7471] and IS-IS [RFC8570], or via BGP-LS TE performance metric extensions [RFC8571]. The C-PS can consume these standard protocol advertisements to populate the NST.¶

5.2.3. Joint Selection Algorithm

When a service request arrives at the Ingress CATS-Forwarder, the C-PS executes the following Joint Selection Algorithm to determine the optimal CSCI-ID:¶

Step 1: Service Lookup (Computing Filter)

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

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

¶

Step 2: Computing Constraint Filtering (Hard Constraints)

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

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

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

3. Cost: If the client or policy specifies a maximum cost M_max, remove all candidates where Cost > 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 5.2.5).¶

Step 3: Network Path Lookup

For each remaining candidate CSCI-ID_i, the C-PS determines the corresponding Egress CATS-Forwarder Egress_i (based on the CSCI-ID's network attachment point). It then queries the NST for the path from the client's Ingress CATS-Forwarder to Egress_i:¶

                    Path_i = NST[Ingress, Egress_i]

¶

If no NST entry exists for a candidate, that candidate is removed from the Candidate_Set.¶

Step 4: Total Service Time Computation

For each remaining candidate, the C-PS computes the Total Service Time (TST):¶

                    TST_i = Computing_Time_i + Network_Delay_i

¶

Where:¶

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

• Network_Delay_i is from the NST entry for Path_i.¶

Step 5: Network Constraint Filtering (Hard Constraints)

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

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

Step 6: Optimization Selection

If multiple candidates remain after all hard constraints have been applied, the C-PS performs optimization selection. The client service requirement MAY indicate that a specific metric should be optimized rather than constrained. A reserved value of 0 in a service requirement metric indicates an optimization objective (i.e., find the best value for that metric) rather than a threshold. The C-PS processes optimization objectives in the following priority order:¶

1. Security Label = 0: Optimal_CSCI-ID = argmax_{i in Candidate_Set} (Security_Label_i)¶

2. Reputation = 0: Optimal_CSCI-ID = argmax_{i in Candidate_Set} (Reputation_i)¶

3. Cost = 0: Optimal_CSCI-ID = argmin_{i in Candidate_Set} (Cost_i)¶

4. GAS = 0: Optimal_CSCI-ID = argmax_{i in Candidate_Set} (GAS_i)¶

5. Bandwidth = 0: Optimal_CSCI-ID = argmax_{i in Candidate_Set} (Bandwidth_i)¶

6. Jitter = 0: Optimal_CSCI-ID = argmin_{i in Candidate_Set} (Jitter_i)¶

7. Loss Rate = 0: Optimal_CSCI-ID = argmin_{i in Candidate_Set} (Loss_Rate_i)¶

8. Latency = 0: Optimal_CSCI-ID = argmin_{i in Candidate_Set} (TST_i)¶

If no optimization objectives are specified (i.e., no reserved zero values), the C-PS applies soft constraints and preference rules listed in the client service requirement. The processing of soft constraints follows the same logic as hard constraints, but violation of a soft constraint does not eliminate a candidate; instead, it contributes to a penalty in the candidate's score.¶

If still multiple candidates exist after optimization and soft-constraint processing, the C-PS applies tie-breaking rules in the following priority:¶

1. Highest GAS (prefer sites with more available capacity).¶

2. Lowest Cost (prefer cheaper sites).¶

3. Highest Reputation (prefer higher-quality sites).¶

4. Random selection among remaining ties.¶

Step 7: Result Installation

The C-PS returns the selected CSCI-ID to the Ingress CATS-Forwarder. The Ingress CATS-Forwarder encapsulates the client traffic and forwards it along the CATS-computed path to the Egress CATS-Forwarder, which then delivers it to the selected CSCI-ID.¶

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

              +-------------------------+      +-------------------------+
              | Computing Service Table |      |  Network Service Table  |
              | (CS-ID, CSCI-ID, GAS,   |      | (Ingress, Egress,       |
              |  Comp Time, Cost, etc.) |      |  Delay, Jitter, BW)     |
              +-----------+-------------+      +-----------+-------------+
              |                                |
              | 1. Lookup by CS-ID             | 3. Lookup by
              |    (filter GAS>0)              |    (Ingress, Egress)
              v                                v
              +----------------------------------------------------------+
              |                      C-PS Joint Selector                 |
              |                                                          |
              |  2. Apply Computing Hard Constraints                     |
              |     (Security, Reputation, Cost, GAS)                    |
              |                                                          |
              |  4. Compute TST = Comp Time + Network Delay              |
              |                                                          |
              |  5. Apply Network Hard Constraints                       |
              |     (Bandwidth, Jitter, Loss, Latency)                   |
              |                                                          |
              |  6. Optimize / Tie-break                                 |
              |                                                          |
              |  7. Return CSCI-ID to Ingress CATS-Forwarder           |
              +----------------------------------------------------------+
              |
              v
              +---------+---------+
              | Ingress CATS-FW   |
              | (Encapsulate &    |
              |  Forward)         |
              +---------+---------+
              |
              v
              +---------+---------+
              | Egress CATS-FW    |
              | (Decapsulate &    |
              |  Deliver to SCI)  |
              +-------------------+

5.2.4. Multi-Objective Optimization and Constraints

The basic Joint Selection Algorithm executes according to the client's service requirement parameters. However, production deployments often require multi-objective optimization that balances competing goals. This section defines extensions to the basic algorithm.¶

Weighted Objective Function:

The C-PS MAY use a weighted objective function that combines multiple metrics:¶

Score_i = w1 * TST_i + w2 * Cost_i + w3 * (1 / GAS_i)+ w4 * (1 / Reputation_i)
          + w5 * (1 / Security_Label_i) + w6 * (1 / Bandwidth_i) + w7 * Loss_Rate_i + w8 * Jitter_i

¶

Where w1, w2, w3, w4, w5, w6, w7, w8 are non-negative weights configured by the manager. The C-PS selects the candidate with the minimum Score_i. By default, w1 = 1 and w2 = w3 = w4 = w5 = w6 = w7= w8= 0 (pure TST minimization). Weights are normalized such that each term contributes proportionally to its configured priority.¶

Constraint-Based Selection:

Instead of (or in addition to) optimization, the C-PS MAY apply constraint-based selection:¶

• Delay Budget: TST_i <= TST_max. Remove candidates exceeding the maximum acceptable total service time.¶

• Cost Budget: Cost_i <= Cost_max. Remove candidates exceeding the maximum acceptable cost.¶

• Bandwidth Requirement: Bandwidth_i >= BW_min. Remove candidates that cannot provide sufficient network bandwidth.¶

• Affinity Requirement: If the client requires session affinity to a previously selected CSCI-ID, and that CSCI-ID is still in the Candidate_Set, the C-PS MAY bypass the optimization and select the affined CSCI-ID directly.¶

Hierarchical Selection:

For scalability, the C-PS MAY perform hierarchical selection:¶

1. First, select the best Egress CATS-Forwarder based on network metrics alone (e.g., minimum Network Delay).¶

2. Then, among the SCIs reachable via that Egress CATS-Forwarder, select the best CSCI-ID based on computing metrics.¶

This reduces the search space and simplifies the decision, but may miss globally optimal solutions where a slightly longer network path leads to a significantly better computing site.¶

Policy-Driven Override:

The C-PS MAY support policy-driven overrides that take precedence over the optimization algorithm:¶

• Geo-fencing: Always prefer service sites within a specific geographic region.¶

• Provider preference: Always prefer a specific service provider.¶

• Maintenance avoidance: Avoid service sites under maintenance.¶

• Load balancing: Distribute traffic evenly across multiple sites even if one has slightly better TST.¶

5.2.5. Fallback and Re-routing Policies

When the Joint Selection Algorithm cannot produce a valid candidate, the C-PS MUST execute fallback procedures:¶

Fallback Level 1: Relax Soft Constraints

If the Candidate_Set is empty after applying constraints, the C-PS MAY apply some implementation-specific relaxation policies, for example:¶

1. Increase the acceptable Cost threshold by 20%.¶

2. Decrease the acceptable Security Label by 1 point.¶

3. Decrease the minimum Reputation threshold by 1 point.¶

4. Decrease the minimum GAS threshold by 1 point.¶

5. Decrease the acceptable Bandwidth threshold by 20%.¶

6. Increase the acceptable Jitter threshold by 20%.¶

7. Increase the acceptable Loss Rate threshold by 20%.¶

8. Increase the acceptable Latency threshold by 20%.¶

9. Accept DEGRADED service sites (if previously excluded).¶

10. Re-run the Joint Selection Algorithm with relaxed constraints.¶

Fallback Level 2: Network-Only Steering

If no computing metrics are available (e.g., all CST entries expired), the C-PS falls back to pure network-based steering: select the Egress CATS-Forwarder with the minimum Network Delay to the destination, and let the Egress CATS-Forwarder select a local CSCI-ID.¶

Fallback Level 3: Default Route

If no network path is available, the C-PS uses the default underlay routing (i.e., shortest-path IP routing) without CATS optimization. The client request is forwarded without CATS encapsulation.¶

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