Computing Service Metrics Operation and Joint Service Selection under CATS
draft-zhangb-cats-service-metrics-op-05
This document is an Internet-Draft (I-D).
Anyone may submit an I-D to the IETF.
This I-D is not endorsed by the IETF and has no formal standing in the
IETF standards process.
| Document | Type | Active Internet-Draft (individual) | |
|---|---|---|---|
| Authors | Bin Zhang , Yina Dai , Zongpeng Du , Guanming Zeng , Chuanyang Miao | ||
| Last updated | 2026-09-16 | ||
| RFC stream | (None) | ||
| Intended RFC status | (None) | ||
| Formats | |||
| Stream | Stream state | (No stream defined) | |
| Consensus boilerplate | Unknown | ||
| RFC Editor Note | (None) | ||
| IESG | IESG state | I-D Exists | |
| Telechat date | (None) | ||
| Responsible AD | (None) | ||
| Send notices to | (None) |
draft-zhangb-cats-service-metrics-op-05
CATS B. Zhang, Ed.
Internet-Draft Pengcheng Laboratory
Intended status: Standards Track Y. Dai, Ed.
Expires: 18 March 2027 Sun Yat-sen University
Z. Du, Ed.
China Mobile
G. Zeng
Huawei Technologies
C. Miao, Ed.
ZTE Corporation
14 September 2026
Computing Service Metrics Operation and Joint Service Selection under
CATS
draft-zhangb-cats-service-metrics-op-05
Abstract
Computing-Aware Traffic Steering (CATS) optimizes traffic forwarding
by considering both computing and networking metrics. The CATS
framework and metric-definition documents provide valuable
theoretical models, yet they face challenges in achieving direct
operational execution in real-world deployments: normalization
methods vary across providers, and aggregated unitless scores often
lose the operational information that routers need for precise
steering decisions.
This document provides a self-contained, executable operational model
for a core class of CATS deployment scenarios: latency-sensitive,
compute-intensive services whose steering decisions are made in real
time at the forwarding node. Instead of disseminating low-level raw
hardware metrics, service sites dynamically evaluate and report
service-oriented metrics (e.g., Global Available Slots and Computing
Time) to the control plane. The document clarifies how these metrics
are derived from basic resource information, service reference
information, and local policy. It also specifies how the CATS Path
Selector (C-PS) combines the Computing Service Table (populated from
C-SMA reports) with the Network Service Table to make joint traffic-
steering decisions, and defines update-control and fallback
mechanisms suitable for large-scale deployments.
Zhang, et al. Expires 18 March 2027 [Page 1]
Internet-Draft CATS Service Metrics Operation September 2026
Within the unified CATS architecture, the service-oriented
operational model defined in this document coexists with the general-
purpose L1/L2 normalized metric framework: a deployment MAY use
either model, or run both pipelines in parallel for different service
classes, without embedding metric fields across frameworks. This
document does not negate the value of normalized metrics; it focuses
on the service-level abstractions and runtime operations required for
direct traffic steering.
Status of This Memo
This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
This Internet-Draft will expire on 18 March 2027.
Copyright Notice
Copyright (c) 2026 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents (https://trustee.ietf.org/
license-info) in effect on the date of publication of this document.
Please review these documents carefully, as they describe your rights
and restrictions with respect to this document. Code Components
extracted from this document must include Revised BSD License text as
described in Section 4.e of the Trust Legal Provisions and are
provided without warranty as described in the Revised BSD License.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5
3. Conventions . . . . . . . . . . . . . . . . . . . . . . . . . 6
4. Motivation and Problem Statement . . . . . . . . . . . . . . 6
5. Service Information and Metrics Definition . . . . . . . . . 7
5.1. Relationship to the CATS Metrics Framework . . . . . . . 7
Zhang, et al. Expires 18 March 2027 [Page 2]
Internet-Draft CATS Service Metrics Operation September 2026
5.2. Derivation from Basic and Reference Information . . . . . 9
5.3. Mandatory Computing Service Information . . . . . . . . . 10
5.3.1. Global Available Slots (GAS) . . . . . . . . . . . . 10
5.3.2. Computing Time . . . . . . . . . . . . . . . . . . . 11
5.4. Optional Extension Metrics . . . . . . . . . . . . . . . 12
5.4.1. Price . . . . . . . . . . . . . . . . . . . . . . . . 12
5.4.2. Reputation . . . . . . . . . . . . . . . . . . . . . 12
5.4.3. Security Level . . . . . . . . . . . . . . . . . . . 13
6. Operation under CATS Framework . . . . . . . . . . . . . . . 13
6.1. Dynamic Metric Reporting . . . . . . . . . . . . . . . . 13
6.2. Joint Decision: Computing Service Table and Network Service
Table . . . . . . . . . . . . . . . . . . . . . . . . . . 14
6.2.1. Computing Service Table Structure . . . . . . . . . . 14
6.2.2. Network Service Table Structure . . . . . . . . . . . 15
6.2.3. Joint Selection Algorithm . . . . . . . . . . . . . . 16
6.2.4. Multi-Objective Optimization and Constraints . . . . 20
6.2.5. Fallback and Re-routing Policies . . . . . . . . . . 22
7. Use Case: Joint Service Selection and Path Computation . . . 23
7.1. Service Distribution and Table Formation . . . . . . . . 23
7.2. Scenario A: Normal Operation with Balanced Load . . . . . 25
7.3. Scenario B: Network Congestion Impact . . . . . . . . . . 26
7.4. Scenario C: Service Site Degradation and Failover . . . . 27
7.5. Scenario D: Multi-Objective Optimization with Price
Constraint . . . . . . . . . . . . . . . . . . . . . . . 28
8. Update Control in Large-Scale Deployments . . . . . . . . . . 30
9. Security Considerations . . . . . . . . . . . . . . . . . . . 31
10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 33
10.1. CATS Computing Service Metrics . . . . . . . . . . . . . 33
11. References . . . . . . . . . . . . . . . . . . . . . . . . . 34
11.1. Normative References . . . . . . . . . . . . . . . . . . 34
11.2. Informative References . . . . . . . . . . . . . . . . . 34
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 36
1. Introduction
The Computing-Aware Traffic Steering (CATS) architecture
[I-D.ietf-cats-framework-24] aims to steer service traffic to the
most suitable service contact instance by evaluating both network
state and computing resource availability. To this end, CATS Service
Metric Agents (C-SMAs) collect computing metrics and advertise them
to CATS Path Selectors (C-PSes).
[I-D.ietf-cats-metric-definition-11] introduces a multi-level metric
framework (Level 0, Level 1, and Level 2) and proposes normalizing
heterogeneous computing metrics into unitless scores (e.g.,
compute_norm). This establishes a solid theoretical baseline for
describing and comparing computing resources. However, mapping
diverse hardware capabilities (CPUs, GPUs, NPUs) into a single
Zhang, et al. Expires 18 March 2027 [Page 3]
Internet-Draft CATS Service Metrics Operation September 2026
normalized score is complex and provider-dependent, and a normalized
score does not, by itself, express the concrete service capacity that
a router needs for fine-grained steering decisions. The operational
limitation concerns the Level 2 normalized representation and the
absence of service-capacity entries in the current Level 1 Service
category; it is not a criticism of the metric hierarchy itself.
Different deployment scenarios impose distinct requirements on metric
processing and steering logic. [I-D.ietf-cats-metric-definition-11]
describes a general-purpose metric framework for CATS traffic
steering: it defines a broad set of metrics and metric processing
procedures suitable for general-class deployments, including the
L0/L1/L2 metric hierarchy, aggregation and normalization functions,
and registry templates. It answers the question: how are computing
metrics categorized, aggregated, and normalized?
This document specifies metric sets and normative steering decision
logic targeting a specific class of deployment scenarios. In these
targeted scenarios, forwarding nodes (C-PS) perform real-time
steering selections under tight local resource constraints, and the
traffic flows are latency-sensitive and compute-intensive. Steering
decisions are generated directly from service-oriented metrics
reported by service sites. This document defines the required
service metrics, the joint selection workflow, edge-case handling,
and persistent operational rules applicable to this particular use
case.
Within the unified CATS architecture, a deployment MAY select either
metric-processing pipeline, or operate both pipelines in parallel as
separate control-plane workflows for different service classes.
These two pipelines do not require mutual embedding of metric fields;
the operational model defined in this document does not rely on any
L1/L2 normalized score field for its operation. The metric entries
defined in this document (GAS, Computing Time, Price, Reputation, and
Security Level) are registered in the "CATS Metrics" registry
established by [I-D.ietf-cats-metric-definition-11], while their
definitions remain in this document and its companion registry
document [I-D.zhangb-cats-service-metric-registry-entries], following
the pattern of a shared registry with document-specific entry
definitions (cf. [RFC8911]). This explicit separation keeps each
document's scope focused and avoids tight coupling between the two
metric-processing approaches.
A further key contribution of this document is the specification of
how the C-PS combines the Computing Service Table (built from C-SMA
reports) with the Network Service Table to make joint traffic-
steering decisions that simultaneously account for computing and
network performance.
Zhang, et al. Expires 18 March 2027 [Page 4]
Internet-Draft CATS Service Metrics Operation September 2026
2. Terminology
This document makes use of the terms defined in
[I-D.ietf-cats-framework-24] and
[I-D.ietf-cats-metric-definition-11]. In particular, CS-ID and CSCI-
ID are used as CATS identifiers. They provide stable service and
service-contact-instance references for lookup and forwarding, but
are not treated as computing metrics in this document.
Additionally, the following terms are used:
* Global Available Slots (GAS): The maximum number of concurrent
requests/sessions a service site is willing and able to serve for
a specific CS-ID at a given time.
* CS-ID (CATS Service ID): An identifier for a service. It is used
as a stable lookup key in the C-PS Computing Service Table.
* CSCI-ID (CATS Service Contact Instance ID): An identifier for
contact information of a service instance that provides a specific
CS-ID at a service site. In this document, it is interpreted
operationally as a locator, such as an IP address and port number,
used to establish the data tunnel.
* Computing Service Table (CST): A data structure maintained by the
C-PS that contains computing-oriented metrics (GAS, Computing
Time, etc.) indexed by CS-ID and CSCI-ID. It is populated from
C-SMA reports.
* Network Service Table (NST): A data structure maintained by the
C-PS that contains network-oriented metrics (delay, jitter,
bandwidth, etc.) indexed by network path identifiers. In an SDN
context, it can be derived from the Traffic Engineering Database
(TEDB).
* Total Service Time (TST): The sum of Computing Time and network
delay (Ingress-to-Egress), used as the primary optimization
objective in the joint selection algorithm. TST is an instance of
the Level 1 Composed category (end-to-end delay / application-
level response time) defined in
[I-D.ietf-cats-metric-definition-11].
* Joint Selection Algorithm: The decision logic used by the C-PS to
select the optimal CSCI-ID by simultaneously evaluating both
computing and network metrics.
Zhang, et al. Expires 18 March 2027 [Page 5]
Internet-Draft CATS Service Metrics Operation September 2026
3. Conventions
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described in BCP
14 [RFC2119] [RFC8174] when, and only when, they appear in all
capitals, as shown here.
4. Motivation and Problem Statement
The CATS working group has made significant progress in defining how
computing metrics should be collected and distributed. In
particular, existing work introduces a comprehensive framework that
categorizes computing metrics into Raw Metrics (Level 0) and
Normalized Metrics (Level 1 and Level 2). However, a critical gap
remains: how exactly to use these metrics to effectively steer
traffic in operational networks.
This document does not negate the value of the L1/L2 normalized
metric framework; rather, it observes that relying solely on the
normalization of raw hardware metrics poses operational challenges
during routing execution:
1. The Implementation Gap (HOW to normalize?): In a real-world
multi-vendor network, computing resources are highly
heterogeneous. It is difficult to establish a unified
mathematical model that fairly normalizes the capacity of a GPU
and a CPU into the same 0-10 score.
2. The Information Loss Gap (WHY disseminate raw features?):
Normalizing diverse hardware capabilities into a single unitless
score can lose actionable information. A normalized compute
score of "7" does not, by itself, guarantee a client's sub-10-ms
delay requirement or express the concrete remaining capacity of a
service instance.
3. The Routing Mechanism Gap (WHO uses this data?): Routers (C-PSes)
do not need to know whether a service is backed by a CPU or a
GPU. They only care about routing parameters: "Is there
capacity?", "How long will it take?", and "Where is the
destination?".
4. The Joint Decision Gap (HOW to combine?): Even when both
computing metrics and network metrics are available, existing
drafts do not specify how the C-PS should combine them into a
unified steering decision. Selecting the service site with the
best computing metrics may yield a poor network path, and vice
versa.
Zhang, et al. Expires 18 March 2027 [Page 6]
Internet-Draft CATS Service Metrics Operation September 2026
To bridge these gaps, CATS requires a Service-Oriented Abstraction
and a clear Joint Selection Algorithm. This document provides both
as a self-contained operational model: it defines the required
computing service information as Mandatory Computing Service Metrics
(Global Available Slots and Computing Time) and Optional Extension
Metrics (Price, Reputation, and Security Level), and it specifies how
the C-PS combines the Computing Service Table with the Network
Service Table to support executable traffic-steering policies.
This self-contained operational model targets latency-sensitive
compute-intensive workloads under tight forwarding-node resource
constraints. It is a first-class metric-processing and steering
workflow within the unified CATS architecture, complementary to the
general-purpose normalized metric framework. A deployment may use
either workflow, or deploy both workflows side-by-side for distinct
service classes.
5. Service Information and Metrics Definition
This section defines the service information used by CATS control-
plane components. Some fields are identifiers or locators, while
others are service-oriented metrics. Metric examples follow the
structural guidelines specified in Section 4.1 of
[I-D.ietf-cats-metric-definition-11]. This document focuses on the
semantics and operational use of these metrics, rather than defining
new routing, transport, signaling, or wire-encoding mechanisms.
5.1. Relationship to the CATS Metrics Framework
[I-D.ietf-cats-metric-definition-11] defines a three-level metric
taxonomy: Level 0 raw metrics, Level 1 category metrics (computing,
communication, service, and composed), and Level 2 normalized
metrics, together with the CATS metric field template and registry.
This document does not extend that taxonomy. The service-oriented
metrics defined in this document are mapped to the framework's
categories in Table 1 as a semantic correspondence; operationally,
the model defined here is self-contained and does not depend on any
normalized score field (see below).
Zhang, et al. Expires 18 March 2027 [Page 7]
Internet-Draft CATS Service Metrics Operation September 2026
+------------------+---------------------------------------------------+
| Metric | Relationship to the CATS Metric Framework |
+------------------+---------------------------------------------------+
| GAS | Semantic correspondence: Level 0 Service-specific |
+------------------+---------------------------------------------------+
| Computing Time | Semantic correspondence: Level 0 Service-specific |
+------------------+---------------------------------------------------+
| | (registration needs WG consensus) |
| Price | Service attribute / policy metric (no level); |
+------------------+---------------------------------------------------+
| | (registration needs WG consensus) |
| Reputation | Service attribute / policy metric (no level); |
+------------------+---------------------------------------------------+
| | (registration needs WG consensus) |
| Security Level | Service attribute / policy metric (no level); |
+------------------+---------------------------------------------------+
Figure 1: Relationship of Computing Service Metrics to the CATS
Metric Framework
Table 1 is a semantic correspondence, not a claim of interoperability
with the normalized pipeline. GAS corresponds to the service-
specific metrics anticipated in Section 3.2 of
[I-D.ietf-cats-framework-24], which notes that computing metrics may
include "the number of clients that access the service contact
instance at any given time". Computing Time, when combined with
network delay (see Section 6.2.3), forms the Total Service Time
(TST), which corresponds to the end-to-end delay / application-level
response time described in the Level 1 Composed category of
[I-D.ietf-cats-metric-definition-11]. Price, Reputation, and
Security Level are operator- or provider-defined service attributes
used as constraints or secondary objectives in the Joint Selection
Algorithm; whether they are registered in the CATS metric registry as
extensions of the Level 1 Service category or as members of a new
category is to be agreed with the working group.
Zhang, et al. Expires 18 March 2027 [Page 8]
Internet-Draft CATS Service Metrics Operation September 2026
The operational model defined in this document does not rely on any
Level 1 or Level 2 normalized score field: GAS and Computing Time are
reported and consumed in their native service-oriented units, and the
steering decision logic in Section 6.2.3 operates directly on these
values. The metric entries defined in this document are registered
in the "CATS Metrics" registry established by
[I-D.ietf-cats-metric-definition-11] (see Section 10), while their
definitions remain in this document and its companion registry
document [I-D.zhangb-cats-service-metric-registry-entries]. Service
attributes that are not measured quantities (Price, Reputation,
Security Level) are labeled "Service attribute" and are not assigned
to a metric level; a metric MUST NOT be assigned to more than one
level.
5.2. Derivation from Basic and Reference Information
The Computing Service Metrics defined in this document are service-
oriented metrics. They are estimations produced by each service site
based on local monitoring and deployment policy. This allows
heterogeneous hardware details and frequent local resource changes to
be hidden from the CATS control plane while still exposing actionable
information for traffic steering.
These metrics can be derived from basic resource metrics, status
metrics, service requirements, and local policy at the service site.
The public service platform described in [I-D.zhangb-cats-cmas-04]
can provide reference information, such as Computing Requirement,
Storage Requirement, Reference Computing Time, software dependency,
and Reference GAS, that a service site can use when deploying a
service.
For example, if the resources allocated to a service instance just
meet the listed Computing Requirement and Storage Requirement, the
service site can use the Reference GAS as a starting value. If more
resources are allocated, the reported GAS is evaluated by the service
site and is generally expected to be larger than the Reference GAS.
Similarly, Computing Time can be measured or estimated based on the
runtime behavior of the deployed service instance. The specific
derivation algorithm is a local matter and is not standardized by
this document.
The basic field examples in Section 5.3 and Section 5.4 provide
recommended data types, lengths, and units as guidance for protocols
that carry these metrics (e.g., BGP-LS extensions or RESTful APIs).
This document does not mandate a specific wire format; the exact
encoding is a matter for the protocol or transport mechanism used
between the C-SMA and the C-PS.
Zhang, et al. Expires 18 March 2027 [Page 9]
Internet-Draft CATS Service Metrics Operation September 2026
To support fair comparison across service sites, the derivation of
GAS SHOULD follow a common reference method within an administrative
domain; a reference derivation (e.g., the sum over healthy instances
of available capacity minus active sessions, with an optional policy
safety margin) is provided in
[I-D.zhangb-cats-service-metric-registry-entries]. This is
consistent with the guidance in Section 5.4 of
[I-D.ietf-cats-framework-24] that consistent normalization and
aggregation functions be enabled across all involved CATS components
so that service contact instance selection is fair among candidates.
5.3. Mandatory Computing Service Information
These fields are essential for the C-PS to make fundamental traffic
steering decisions. CS-ID and CSCI-ID are identifiers, while GAS and
Computing Time are service-oriented metrics.
5.3.1. Global Available Slots (GAS)
GAS is the core contribution of this metric framework. It represents
the maximum number of concurrent requests/sessions that a service
site is willing and able to serve for a specific CS-ID through a
specific CSCI-ID at a given time.
Crucially, GAS acts as a direct abstraction layer over the complex
and fluctuating raw computing metrics (CPU, GPU, Memory, Storage) and
status metrics (load and health). Instead of exposing highly dynamic
raw metrics to the network, the service site absorbs these variations
internally. The site can initially provide a GAS value based on its
fixed resource allocation and service reference information, and then
adjust it according to local policy based on internal status metrics.
As the number of concurrent requests increases, the GAS value
naturally decreases. Furthermore, the site monitoring system
dynamically reduces the GAS value upon detecting abnormal status
metrics, such as:
* Load changes: Sudden increase in internal resources occupied by
local users or tasks.
* Health changes: Sudden performance drop, possibly due to a cyber
attack.
* Reachability: The site crashes or becomes unresponsive.
Note: The C-SMA proactively reports significant adjustments to the
control plane according to local policy, thresholds, or aggregation
intervals. Small per-session changes do not necessarily need to be
Zhang, et al. Expires 18 March 2027 [Page 10]
Internet-Draft CATS Service Metrics Operation September 2026
reported immediately. When GAS drops to 0, it means the instance
cannot allocate any more resources, and no new requests will be
steered to it. Each reported GAS value is the current estimate at
the time of reporting, taken over the configured measurement window.
Basic fields:
Metric Type: gas
Level: Level 0 (Service-specific metrics)
Format: unsigned integer
Length: four octets
Unit: count (concurrent sessions)
Statistics: cur
Measurement_Window: 10 seconds (default)
Value: 500
Source: estimation
5.3.2. Computing Time
The time required for the site to perform one service request. The
service site can initialize this metric based on service reference
information and then measure or estimate it according to the runtime
behavior of the deployed service instance. The service site
dynamically adjusts this metric based on real-time load and local
policy.
Computing Time is a critical input to the Joint Selection Algorithm
because it represents the processing latency component of the Total
Service Time (see Section 6.2.3). It is reported as the mean
processing time over the measurement window; implementations MAY
additionally report percentile values (e.g., p95) in the Statistics
field.
Basic fields:
Metric Type: comp_time
Level: Level 0 (Service-specific metrics)
Format: floating point
Length: four octets
Unit: ms
Statistics: mean
Measurement_Window: 10 seconds (default)
Value: 5
Source: estimation
Zhang, et al. Expires 18 March 2027 [Page 11]
Internet-Draft CATS Service Metrics Operation September 2026
5.4. Optional Extension Metrics
To accommodate advanced traffic-steering scenarios, the following
optional fields are defined.
5.4.1. Price
Self-defined by the service site to apply administrative or economic
billing policies. Price is used as a constraint or secondary
objective in the Joint Selection Algorithm (see Section 6.2.4).
Price is a service attribute rather than a measured quantity; it is
therefore not assigned to a metric level.
Basic fields:
Metric Type: price
Level: Service attribute (no metric level)
Format: unsigned integer
Length: two octets
Unit: unitless (provider-defined pricing unit)
Value: 100
Source: nominal
5.4.2. Reputation
A dynamic quality score based on user feedback. Upon completion, if
a user experiences long delays or inaccurate results, feedback is
returned to the C-PS along with the resource release message.
Reputation is used as a tie-breaker or threshold filter in the Joint
Selection Algorithm. It is a service attribute rather than a
measured quantity and is therefore not assigned to a metric level.
Score semantics follow the 0-10 normalized score mapping of
[I-D.ietf-cats-metric-definition-11] (Section 4.3): 0-3 indicates
poor reputation (avoid if alternatives exist), 4-7 average
(acceptable for steering), 8-10 excellent (preferred for steering).
Basic fields:
Metric Type: reputation
Level: Service attribute (no metric level)
Format: unsigned integer
Length: one octet
Unit: score (0-10)
Value: 8
Source: nominal
Zhang, et al. Expires 18 March 2027 [Page 12]
Internet-Draft CATS Service Metrics Operation September 2026
5.4.3. Security Level
The Security Level reflects the security status of a service site. A
higher score indicates a more secure site. The Security Level is
used as a constraint in the Joint Selection Algorithm: a C-PS MUST
NOT select a service contact instance with a Security Level below the
client's minimum requirement. It is a service attribute rather than
a measured quantity and is therefore not assigned to a metric level.
Score range: 0-10 (0 indicates the poorest security; 10 indicates
optimal security). Score semantics follow the 0-10 normalized score
mapping of [I-D.ietf-cats-metric-definition-11] (Section 4.3): 0-3
indicates low security posture (not recommended for sensitive
traffic), 4-7 medium (acceptable for general traffic), 8-10 high
(preferred for sensitive or regulated traffic).
Basic fields:
Metric Type: security_level
Level: Service attribute (no metric level)
Format: unsigned integer
Length: one octet
Unit: score (0-10)
Value: 7
Source: nominal
6. Operation under CATS Framework
6.1. Dynamic Metric Reporting
Service sites proactively monitor their internal instances. In
large-scale deployments, service sites can use a delta-threshold
reporting model. Each service site or C-SMA maintains a local metric
cache. Per-session allocation and release events update local GAS
values, but do not necessarily trigger immediate reports to the C-PS.
Updates are reported when they become operationally significant.
Examples include GAS crossing a configured threshold, Computing Time
deviating beyond a configured percentage band, or health status
changing due to failure, attack detection, or unreachability. A
periodic heartbeat or soft-state synchronization can also be used to
refresh the C-PS view and avoid stale metrics even when no trigger
event occurs.
The reporting model defined here aligns with the CATS OAM
requirements of [I-D.ietf-cats-oam-fw]: O-REQ-1 (the system SHOULD
support both periodic and threshold-triggered reporting) and O-REQ-4
(computing metrics SHOULD be accompanied by timestamps indicating the
Zhang, et al. Expires 18 March 2027 [Page 13]
Internet-Draft CATS Service Metrics Operation September 2026
time of collection so that the C-SMA or C-PS can configure a maximum
acceptable staleness threshold). The default update interval is
consistent with the "update-interval" parameter of the CATS YANG data
model [I-D.yl-cats-data-model].
Choosing appropriate protocols for conveying CATS metrics is
important. For distributed systems, existing routing protocols such
as BGP extensions [RFC4760] and GRASP [RFC8990] may serve as a
baseline. However, considering that the CATS working group focuses
on single-domain models, centralized approaches are highly suitable.
In an SDN context [RFC7149] [RFC7426], the metric agent acts as an
application that uses a RESTful API via the northbound interface to
report CATS metrics directly to the centralized C-PS (or SDN
controller) for centralized decision-making. A systematic analysis
of the applicability of these protocols is provided in
[I-D.yxl-cats-protocols-applicability]; this document does not
mandate a specific transport mechanism.
6.2. Joint Decision: Computing Service Table and Network Service Table
This section specifies the core operational procedure by which the
C-PS combines computing metrics and network metrics to select the
optimal CSCI-ID for a service request. This joint decision is the
central mechanism that enables Computing-Aware Traffic Steering.
6.2.1. Computing Service Table Structure
The Computing Service Table (CST) is maintained by the C-PS and is
populated from C-SMA reports. It contains one entry per (CS-ID,
CSCI-ID) pair. Each entry contains the following fields:
+-------------------+------------------------------------------------+
| Field | Description |
+-------------------+------------------------------------------------+
| CS-ID | The CATS Service Identifier |
| CSCI-ID | The Service Contact Instance locator |
| | (e.g., IP:Port) |
| GAS | Global Available Slots (uint32, count) |
| Computing Time | Estimated processing time in ms (float32) |
| Price | Service price (optional, uint32) |
| Reputation | Quality score 0-10 (optional, uint8) |
| Security Level | Security score 0-10 (optional, uint8) |
| Last Updated | Timestamp of last C-SMA report |
| Expiry Time | Soft-state expiration time |
+-------------------+------------------------------------------------+
Zhang, et al. Expires 18 March 2027 [Page 14]
Internet-Draft CATS Service Metrics Operation September 2026
The CST is indexed by CS-ID for fast lookup of all candidate CSCI-IDs
for a given service. The C-PS MUST age out entries whose Expiry Time
has passed, treating them as unreachable (GAS = 0).
The CST is logically separate from the Network Service Table to
maintain separation of concerns between computing and network
domains.
6.2.2. Network Service Table Structure
The Network Service Table (NST) is maintained by the C-PS and is
populated from C-NMA reports. The NST is a logical data structure
maintained by the C-PS, providing a view of network metrics tailored
for CATS joint decision. In a SDN context, the NST is derived from
the SDN controller's Traffic Engineering Database (TEDB), which
aggregates network topology and performance information from the
underlay network via protocols such as BGP-LS [RFC8571] or IGP TE
extensions [RFC7471] [RFC8570].
In the reference architecture, the C-PS accesses the NST rather than
the raw TEDB, though implementations MAY co-locate these functions.
Instead, a NST Generator component performs the following steps:
1. Filtering: Extracts paths relevant to the CATS domain and the set
of Egress CATS-Forwarders.
2. Aggregation: Computes path-level metrics (e.g., one-way delay,
available bandwidth) from link-level TEDB data.
3. Indexing: Re-indexes the information by (Ingress CF, Egress CF)
pair for fast lookup.
The NST MAY be cached and periodically refreshed based on TEDB
updates, or MAY be generated on-the-fly based on the current TEDB
snapshot. The NST contains one entry per (Ingress, Egress) pair,
representing the network path from the client's Ingress CATS-
Forwarder to the Egress CATS-Forwarder that connects to the service
site. The specific implementation is a local matter.
Each entry contains the following fields:
Zhang, et al. Expires 18 March 2027 [Page 15]
Internet-Draft CATS Service Metrics Operation September 2026
+-------------------+------------------------------------------------+
| Field | Description |
+-------------------+------------------------------------------------+
| Ingress CF | Ingress CATS-Forwarder identifier |
| Egress CF | Egress CATS-Forwarder identifier |
| Network Delay | One-way delay in ms (uint32) |
| Jitter | Delay variation in ms (uint32, optional) |
| Bandwidth | Available bandwidth in Mbps (uint32, optional) |
| Loss Rate | Packet loss rate in ppm (uint32, optional) |
| Path Attributes | TE attributes (e.g., affinity, color) |
| Last Updated | Timestamp of last C-NMA report |
+-------------------+------------------------------------------------+
The service node may be outside the ingress domain, so this document
does not require measuring delay directly from the ingress to the
service node. Instead, the Network Delay represents the path from
the Ingress CATS-Forwarder to the Egress CATS-Forwarder.
This document expresses network delay in milliseconds for consistency
with Computing Time in the TST computation (see Section 6.2.3).
Network performance metrics such as delay, jitter, and loss are
typically distributed via IGP TE metric extensions for OSPF [RFC7471]
and IS-IS [RFC8570], or via BGP-LS TE performance metric extensions
[RFC8571], which use microseconds for delay values. When consuming
such advertisements, the C-PS SHOULD convert the received values to a
common time base (e.g., milliseconds) before populating the NST and
computing TST, to avoid unit mismatches.
The C-PS MUST ensure that the NST and CST are synchronized in time:
when evaluating a candidate, the C-PS SHOULD use NST entries whose
Last Updated timestamp is within a reasonable window of the CST
entry's Last Updated timestamp (e.g., within 30 seconds) to avoid
decisions based on stale combinations.
Network performance metrics such as delay, jitter, and loss can be
distributed via IGP TE metric extensions for OSPF [RFC7471] and IS-IS
[RFC8570], or via BGP-LS TE performance metric extensions [RFC8571].
The C-PS can consume these standard protocol advertisements to
populate the NST.
6.2.3. Joint Selection Algorithm
When a service request arrives at the Ingress CATS-Forwarder, the
C-PS executes the following Joint Selection Algorithm to determine
the optimal CSCI-ID:
Step 1: Service Lookup (Computing Filter) The C-PS queries the CST
Zhang, et al. Expires 18 March 2027 [Page 16]
Internet-Draft CATS Service Metrics Operation September 2026
using the requested CS-ID. It retrieves all entries matching the
CS-ID. Entries with GAS = 0 or expired entries are discarded.
This produces the Candidate Set:
Candidate_Set = { (CSCI-ID_i, GAS_i, CompTime_i, ...) |
CST[CS-ID, CSCI-ID_i] exists AND
CST.GAS > 0 AND
CST.Expiry > now }
Step 2: Computing Constraint Filtering (Hard Constraints) The C-PS
applies hard constraints to eliminate infeasible candidates:
a. Security Level: If the client or policy specifies a minimum
security label S_min, remove all candidates where
Security_Level < S_min.
b. Reputation: If the client or policy specifies a minimum
reputation R_min, remove all candidates where Reputation <
R_min.
c. Price: If the client or policy specifies a maximum price
M_max, remove all candidates where Price > M_max.
d. GAS Sufficiency: If local policy indicates a required session
count N_req, remove all candidates where GAS < N_req. (Note:
typically N_req = 1 for a single session.)
After constraint filtering, if the Candidate_Set is empty, the
C-PS proceeds to Fallback (Section 6.2.5).
Step 3: Network Path Lookup For each remaining candidate CSCI-ID_i,
the C-PS determines the corresponding Egress CATS-Forwarder
Egress_i (based on the CSCI-ID's network attachment point). It
then queries the NST for the path from the client's Ingress CATS-
Forwarder to Egress_i:
Path_i = NST[Ingress, Egress_i]
If no NST entry exists for a candidate, that candidate is removed
from the Candidate_Set.
Step 4: Total Service Time Computation For each remaining candidate,
the C-PS computes the Total Service Time (TST):
TST_i = Computing_Time_i + Network_Delay_i
Where:
Zhang, et al. Expires 18 March 2027 [Page 17]
Internet-Draft CATS Service Metrics Operation September 2026
* Computing_Time_i is from the CST entry for CSCI-ID_i.
* Network_Delay_i is from the NST entry for Path_i.
TST is the CATS instance of the Level 1 Composed category (end-to-
end delay) of [I-D.ietf-cats-metric-definition-11], and
corresponds to the "Joint Performance Measurement" (total latency
= network transmission time + service processing time) defined in
the CATS OAM framework [I-D.ietf-cats-oam-fw]. Computing_Time_i
and Network_Delay_i MUST be expressed on the same time base (see
Section 6.2.2).
Step 5: Network Constraint Filtering (Hard Constraints) The C-PS
applies network-side hard constraints to eliminate infeasible
candidates:
a. Bandwidth: If the client or policy specifies a minimum
bandwidth BW_min, remove all candidates where Bandwidth <
BW_min.
b. Jitter: If the client or policy specifies a maximum jitter
J_max, remove all candidates where Jitter > J_max.
c. Loss Rate: If the client or policy specifies a maximum loss
rate LR_max, remove all candidates where Loss_Rate > LR_max.
d. Latency: If the client or policy specifies a maximum total
latency L_max, remove all candidates where TST_i > L_max.
After constraint filtering, if the Candidate_Set is empty, the
C-PS proceeds to Fallback (Section 6.2.5).
Step 6: Optimization Selection If multiple candidates remain after
all hard constraints have been applied, the C-PS performs
optimization selection. The client service requirement MAY
explicitly designate one or more metrics as optimization
objectives (i.e., find the best value for that metric), as opposed
to constraints. Optimization objectives MUST be expressed as an
explicit list in the client service requirement; they MUST NOT be
inferred from a reserved metric value such as 0, because values
such as Price = 0 (free service) or Security_Level = 0 (poorest
security) are legitimate metric values. The C-PS processes
optimization objectives in the following priority order:
1. Optimize Security Level: Optimal_CSCI-ID = argmax_{i in
Candidate_Set} (Security_Level_i)
Zhang, et al. Expires 18 March 2027 [Page 18]
Internet-Draft CATS Service Metrics Operation September 2026
2. Optimize Reputation: Optimal_CSCI-ID = argmax_{i in
Candidate_Set} (Reputation_i)
3. Optimize Price (minimize): Optimal_CSCI-ID = argmin_{i in
Candidate_Set} (Price_i)
4. Optimize GAS: Optimal_CSCI-ID = argmax_{i in Candidate_Set}
(GAS_i)
5. Optimize Bandwidth: Optimal_CSCI-ID = argmax_{i in
Candidate_Set} (Bandwidth_i)
6. Optimize Jitter (minimize): Optimal_CSCI-ID = argmin_{i in
Candidate_Set} (Jitter_i)
7. Optimize Loss Rate (minimize): Optimal_CSCI-ID = argmin_{i in
Candidate_Set} (Loss_Rate_i)
8. Optimize Latency (minimize): Optimal_CSCI-ID = argmin_{i in
Candidate_Set} (TST_i)
If no optimization objectives are specified (i.e., no reserved
zero values), the C-PS applies soft constraints and preference
rules listed in the client service requirement. The processing of
soft constraints follows the same logic as hard constraints, but
violation of a soft constraint does not eliminate a candidate;
instead, it contributes to a penalty in the candidate's score.
If still multiple candidates exist after optimization and soft-
constraint processing, the C-PS applies tie-breaking rules in the
following priority:
1. Highest GAS (prefer sites with more available capacity).
2. Lowest Price (prefer cheaper sites).
3. Highest Reputation (prefer higher-quality sites).
4. Random selection among remaining ties.
Step 7: Result Installation The C-PS returns the selected CSCI-ID to
the Ingress CATS-Forwarder. The Ingress CATS-Forwarder
encapsulates the client traffic and forwards it along the CATS-
computed path to the Egress CATS-Forwarder, which then delivers it
to the selected CSCI-ID.
The following figure illustrates the data flow and decision logic:
Zhang, et al. Expires 18 March 2027 [Page 19]
Internet-Draft CATS Service Metrics Operation September 2026
+-------------------------+ +-------------------------+
| Computing Service Table | | Network Service Table |
| (CS-ID, CSCI-ID, GAS, | | (Ingress, Egress, |
| Comp Time, Price, etc.) | | Delay, Jitter, BW) |
+-----------+-------------+ +-----------+-------------+
| |
| 1. Lookup by CS-ID | 3. Lookup by
| (filter GAS>0) | (Ingress, Egress)
v v
+----------------------------------------------------------+
| C-PS Joint Selector |
| |
| 2. Apply Computing Hard Constraints |
| (Security, Reputation, Price, GAS) |
| |
| 4. Compute TST = Comp Time + Network Delay |
| |
| 5. Apply Network Hard Constraints |
| (Bandwidth, Jitter, Loss, Latency) |
| |
| 6. Optimize / Tie-break |
| |
| 7. Return CSCI-ID to Ingress CATS-Forwarder |
+----------------------------------------------------------+
|
v
+---------+---------+
| Ingress CATS-FW |
| (Encapsulate & |
| Forward) |
+---------+---------+
|
v
+---------+---------+
| Egress CATS-FW |
| (Decapsulate & |
| Deliver to SCI) |
+-------------------+
Figure 2: Joint Selection Algorithm Data Flow
6.2.4. Multi-Objective Optimization and Constraints
The basic Joint Selection Algorithm executes according to the
client's service requirement parameters. However, production
deployments often require multi-objective optimization that balances
competing goals. This section defines extensions to the basic
algorithm.
Zhang, et al. Expires 18 March 2027 [Page 20]
Internet-Draft CATS Service Metrics Operation September 2026
Weighted Objective Function: The C-PS MAY use a weighted objective
function that combines multiple metrics:
Score_i = w1 * n(TST_i) + w2 * n(Price_i) + w3 * (1 - n(GAS_i))
+ w4 * (1 - n(Reputation_i)) + w5 * (1 - n(Security_Level_i))
+ w6 * (1 - n(Bandwidth_i)) + w7 * n(Loss_Rate_i)
+ w8 * n(Jitter_i)
Where w1, w2, w3, w4, w5, w6, w7, w8 are non-negative weights
configured by the manager, and n(x) denotes min-max normalization
of each metric to the range [0,1] based on implementation-
configured minimum and maximum expected values per metric (when
max = min, n(x) = 0.5). Terms for metrics that are maximized
(GAS, Reputation, Security Level, Bandwidth) are expressed as (1 -
n(value)) so that a better value contributes a lower score;
reciprocal terms such as 1/GAS are avoided because zero is a
legitimate value for some metrics (e.g., Security Level = 0, Price
= 0) and would cause division by zero. Because all terms are
unitless and bounded, weights can be compared and configured
meaningfully. The C-PS selects the candidate with the minimum
Score_i. By default, w1 = 1 and w2 = w3 = w4 = w5 = w6 = w7 = w8
= 0 (pure TST minimization). Weights are normalized such that
each term contributes proportionally to its configured priority.
Constraint-Based Selection: Instead of (or in addition to)
optimization, the C-PS MAY apply constraint-based selection:
* Delay Budget: TST_i <= TST_max. Remove candidates exceeding
the maximum acceptable total service time.
* Price Budget: Price_i <= Price_max. Remove candidates
exceeding the maximum acceptable price.
* Bandwidth Requirement: Bandwidth_i >= BW_min. Remove
candidates that cannot provide sufficient network bandwidth.
* Affinity Requirement: If the client requires session affinity
to a previously selected CSCI-ID, and that CSCI-ID is still in
the Candidate_Set, the C-PS MAY bypass the optimization and
select the affined CSCI-ID directly.
Hierarchical Selection: For scalability, the C-PS MAY perform
hierarchical selection:
1. First, select the best Egress CATS-Forwarder based on network
metrics alone (e.g., minimum Network Delay).
Zhang, et al. Expires 18 March 2027 [Page 21]
Internet-Draft CATS Service Metrics Operation September 2026
2. Then, among the SCIs reachable via that Egress CATS-Forwarder,
select the best CSCI-ID based on computing metrics.
This reduces the search space and simplifies the decision, but may
miss globally optimal solutions where a slightly longer network
path leads to a significantly better computing site.
Policy-Driven Override: The C-PS MAY support policy-driven overrides
that take precedence over the optimization algorithm:
* Geo-fencing: Always prefer service sites within a specific
geographic region.
* Provider preference: Always prefer a specific service provider.
* Maintenance avoidance: Avoid service sites under maintenance.
* Load balancing: Distribute traffic evenly across multiple sites
even if one has slightly better TST.
6.2.5. Fallback and Re-routing Policies
When the Joint Selection Algorithm cannot produce a valid candidate,
the C-PS MUST execute fallback procedures:
Fallback Level 1: Relax Soft Constraints If the Candidate_Set is
empty after applying constraints, the C-PS MAY apply some
implementation-specific relaxation policies, for example:
1. Increase the acceptable Price threshold by 20%.
2. Decrease the acceptable Security Level by 1 point.
3. Decrease the minimum Reputation threshold by 1 point.
4. Decrease the minimum GAS threshold by 1 point.
5. Decrease the acceptable Bandwidth threshold by 20%.
6. Increase the acceptable Jitter threshold by 20%.
7. Increase the acceptable Loss Rate threshold by 20%.
8. Increase the acceptable Latency threshold by 20%.
9. Accept DEGRADED service sites (if previously excluded).
Zhang, et al. Expires 18 March 2027 [Page 22]
Internet-Draft CATS Service Metrics Operation September 2026
10. Re-run the Joint Selection Algorithm with relaxed
constraints.
Fallback Level 2: Network-Only Steering If no computing metrics are
available (e.g., all CST entries expired), the C-PS falls back to
pure network-based steering: select the Egress CATS-Forwarder with
the minimum Network Delay to the destination, and let the Egress
CATS-Forwarder select a local CSCI-ID.
Fallback Level 3: Default Route If no network path is available, the
C-PS uses the default underlay routing (i.e., shortest-path IP
routing) without CATS optimization. The client request is
forwarded without CATS encapsulation.
Re-routing on Failure: If the selected CSCI-ID becomes unreachable
after the session is established (detected by C-PS via C-SMA
withdrawal or path failure), the C-PS:
1. Marks the CSCI-ID as unavailable in the CST (GAS = 0).
2. Re-runs the Joint Selection Algorithm for new requests.
3. For existing affined sessions, the C-PS MAY either:
a. Migrate the session to the new optimal CSCI-ID (if the
service protocol supports it), or
b. Terminate the session and require the client to re-
establish.
7. Use Case: Joint Service Selection and Path Computation
This section provides detailed use cases that illustrate the
integrated routing logic of the Joint Selection Algorithm. The
scenarios demonstrate how the C-PS combines the Computing Service
Table and the Network Service Table under different operational
conditions. In these examples, ARS, VRS, and LLMS denote an
Augmented Reality service, a Virtual Reality service, and a Large
Language Model inference service, respectively; they are illustrative
service names used as CS-IDs, not router models.
7.1. Service Distribution and Table Formation
Consider a CATS domain with three service sites providing computing
services. The topology is as follows:
Zhang, et al. Expires 18 March 2027 [Page 23]
Internet-Draft CATS Service Metrics Operation September 2026
Service Site 2 (SS2) Service Site 3 (SS3)
+------------------+ +------------------+
| SCI-1: ARS | | SCI-3: ARS |
| 188.3.67.3:67 | | 188.3.67.4:69 |
| GAS=400, CT=5 | | GAS=600, CT=6 |
| Price=10 | | Price=5 |
| | | |
| SCI-2: VRS | | SCI-4: LLMS |
| 188.3.67.3:68 | | 188.3.67.4:70 |
| GAS=100, CT=15 | | GAS=300, CT=12 |
| Price=20 | | Price=15 |
+--------+---------+ +--------+---------+
| |
Egress CF-2 Egress CF-3
(188.3.67.3) (188.3.67.4)
^ ^
| |
+--------------+-----------------------------------+-------------+
| Underlay Network |
| (P-routers) |
+--------------+-----------------------------------+-------------+
| |
| |
+-----+------+ +---+----------+
| C-NMA | | C-SMA#2 |
| | | (SS3) |
+------------+ +----------------+
^
|
+--------------+-----------------------------------+-------------+
| |
| +---------------------+ |
| | Ingress CATS-FW 1 | |
| | 10.0.0.1 (Client) | |
| | C-PS (co-located) | |
| +---------------------+ |
| |
+------------------------------------------------------------------+
The C-SMAs at each service site push their local service information
to the C-PS, forming the Computing Service Table (CST). The C-NMA
collects network information and pushes it to the C-PS, forming the
Network Service Table (NST).
Computing Service Table (CST):
Zhang, et al. Expires 18 March 2027 [Page 24]
Internet-Draft CATS Service Metrics Operation September 2026
+=======+===================+=====+===============+===================+
| CS-ID | CSCI-ID (IP:Port) | GAS | Comp Time(ms) | Price (Optional) |
+=======+===================+=====+===============+===================+
| ARS | 188.3.67.3:67 | 400 | 5 | 10 |
+-------+-------------------+-----+---------------+-------------------+
| VRS | 188.3.67.3:68 | 100 | 15 | 20 |
+-------+-------------------+-----+---------------+-------------------+
| ARS | 188.3.67.4:69 | 600 | 6 | 5 |
+-------+-------------------+-----+---------------+-------------------+
| LLMS | 188.3.67.4:70 | 300 | 12 | 15 |
+-------+-------------------+-----+---------------+-------------------+
Network Service Table (NST):
+========================+=======================+============+
| Ingress CATS-Forwarder | Egress CATS-Forwarder | Network |
| | | Delay (ms) |
+========================+=======================+============+
| 10.0.0.1 | 188.3.67.3 (CF-2) | 8 |
+------------------------+-----------------------+------------+
| 10.0.0.1 | 188.3.67.4 (CF-3) | 6 |
+------------------------+-----------------------+------------+
Note: In this example, the Egress CATS-Forwarder identifiers are
represented by their attachment IP addresses for simplicity. In a
real deployment, they would be router IDs or loopback addresses.
7.2. Scenario A: Normal Operation with Balanced Load
A client at Ingress CATS-Forwarder 1 (10.0.0.1) requests the ARS
service with the requirement for the shortest Total Service Time.
Step 1: Service Lookup (Computing Filter) The C-PS queries the CST
for CS-ID = "ARS". Candidates:
* CSCI-ID 188.3.67.3:67 (SS2, GAS=400, CT=5ms, Price=10)
* CSCI-ID 188.3.67.4:69 (SS3, GAS=600, CT=6ms, Price=5)
Both have GAS > 0 and are not expired.
Step 2: Constraint Filtering No hard constraints are applied in this
scenario (no minimum security label, reputation, or price limits).
Both candidates remain.
Step 3: Network Path Lookup
* For 188.3.67.3:67, the Egress CATS-Forwarder is 188.3.67.3.
NST[10.0.0.1, 188.3.67.3] -> Network Delay = 8 ms.
Zhang, et al. Expires 18 March 2027 [Page 25]
Internet-Draft CATS Service Metrics Operation September 2026
* For 188.3.67.4:69, the Egress CATS-Forwarder is 188.3.67.4.
NST[10.0.0.1, 188.3.67.4] -> Network Delay = 6 ms.
Step 4: Total Service Time Computation
* Candidate 188.3.67.3:67: TST = 5 ms + 8 ms = 13 ms.
* Candidate 188.3.67.4:69: TST = 6 ms + 6 ms = 12 ms.
Step 5: Optimization Selection The C-PS compares TST values:
* 188.3.67.4:69 has TST = 12 ms (optimal).
* 188.3.67.3:67 has TST = 13 ms.
The C-PS selects 188.3.67.4:69 (Service Site 3) because it offers
the shortest Total Service Time, even though its computing time (6
ms) is slightly higher than candidate 188.3.67.3:67 (5 ms). The
shorter network path (6 ms vs. 8 ms) compensates for the slightly
higher computing time.
Step 6: Result Installation The C-PS returns CSCI-ID 188.3.67.4:69
to Ingress CATS-Forwarder 1. The Ingress CATS-Forwarder
encapsulates the client packets and forwards them along the CATS-
computed path to Egress CATS-Forwarder 3 (188.3.67.4). The Egress
CATS-Forwarder decapsulates and delivers the packets to SCI-3 at
188.3.67.4:69.
This scenario demonstrates that CATS selects the globally optimal
combination of computing and network performance, not just the best
computing site or the best network path in isolation.
7.3. Scenario B: Network Congestion Impact
Suppose the network path to Service Site 3 experiences congestion,
and the C-NMA updates the NST:
Updated Network Service Table (NST):
+========================+=======================+============+
| Ingress CATS-Forwarder | Egress CATS-Forwarder | Network |
| | | Delay (ms) |
+========================+=======================+============+
| 10.0.0.1 | 188.3.67.3 (CF-2) | 8 |
+------------------------+-----------------------+------------+
| 10.0.0.1 | 188.3.67.4 (CF-3) | 20 | <-- changed
+------------------------+-----------------------+------------+
The C-PS re-evaluates the ARS request:
Zhang, et al. Expires 18 March 2027 [Page 26]
Internet-Draft CATS Service Metrics Operation September 2026
Step 4 (Re-evaluation): Total Service Time Computation
* Candidate 188.3.67.3:67: TST = 5 ms + 8 ms = 13 ms.
* Candidate 188.3.67.4:69: TST = 6 ms + 20 ms = 26 ms.
Step 5: Optimization Selection Now 188.3.67.3:67 (TST = 13 ms) is
optimal, while 188.3.67.4:69 (TST = 26 ms) is penalized by the
congested network path.
The C-PS dynamically re-selects 188.3.67.3:67 (Service Site 2) and
updates the forwarding rules at Ingress CATS-Forwarder 1. New client
requests for ARS are steered to Service Site 2 until the network
congestion to Service Site 3 subsides.
This scenario demonstrates CATS's ability to dynamically adapt to
network condition changes and re-steer traffic to maintain optimal
Total Service Time.
7.4. Scenario C: Service Site Degradation and Failover
Suppose Service Site 3 experiences a partial failure: SCI-3 (ARS)
becomes DEGRADED, and its GAS drops from 600 to 50. The C-SMA at
Service Site 3 reports the updated metrics to the C-PS:
Updated Computing Service Table (CST):
+=======+===================+=====+===============+===================+
| CS-ID | CSCI-ID (IP:Port) | GAS | Comp Time(ms) | Price (Optional) |
+=======+===================+=====+===============+===================+
| ARS | 188.3.67.3:67 | 400 | 5 | 10 |
+-------+-------------------+-----+---------------+-------------------+
| VRS | 188.3.67.3:68 | 100 | 15 | 20 |
+-------+-------------------+-----+---------------+-------------------+
| ARS | 188.3.67.4:69 | 50 | 25 | 5 | <-- changed
+-------+-------------------+-----+---------------+-------------------+
| LLMS | 188.3.67.4:70 | 300 | 12 | 15 |
+-------+-------------------+-----+---------------+-------------------+
Note: Computing Time increased to 25 ms due to degraded performance.
The C-PS re-evaluates the ARS request:
Step 1: Service Lookup Candidates: 188.3.67.3:67 (GAS=400) and
188.3.67.4:69 (GAS=50). Both have GAS > 0, so both remain.
Step 4: Total Service Time Computation (using original NST delays)
* Candidate 188.3.67.3:67: TST = 5 ms + 8 ms = 13 ms.
Zhang, et al. Expires 18 March 2027 [Page 27]
Internet-Draft CATS Service Metrics Operation September 2026
* Candidate 188.3.67.4:69: TST = 25 ms + 6 ms = 31 ms.
Step 5: Optimization Selection 188.3.67.3:67 (TST = 13 ms) is
clearly optimal. Even without the network congestion from
Scenario B, the degraded computing performance at Service Site 3
makes it an inferior choice.
Now suppose the failure worsens: SCI-3 becomes UNHEALTHY, and GAS
drops to 0. The C-SMA reports the withdrawal:
Updated Computing Service Table (CST):
+=======+===================+=====+===============+===================+
| CS-ID | CSCI-ID (IP:Port) | GAS | Comp Time(ms) | Price (Optional) |
+=======+===================+=====+===============+===================+
| ARS | 188.3.67.3:67 | 400 | 5 | 10 |
+-------+-------------------+-----+---------------+-------------------+
| VRS | 188.3.67.3:68 | 100 | 15 | 20 |
+-------+-------------------+-----+---------------+-------------------+
| ARS | 188.3.67.4:69 | 0 | 25 | 5 | <-- GAS=0
+-------+-------------------+-----+---------------+-------------------+
| LLMS | 188.3.67.4:70 | 300 | 12 | 15 |
+-------+-------------------+-----+---------------+-------------------+
Step 1: Service Lookup (Computing Filter) Candidate 188.3.67.4:69
has GAS = 0 and is filtered out. Only 188.3.67.3:67 remains.
The C-PS selects 188.3.67.3:67 as the only available candidate. This
scenario demonstrates automatic failover when a service site becomes
unavailable.
If ALL ARS candidates have GAS = 0 (e.g., both sites fail), the C-PS
triggers Fallback Level 2 (Section 6.2.5): it falls back to pure
network-based steering or returns a "Service Unavailable" indication
to the client.
7.5. Scenario D: Multi-Objective Optimization with Price Constraint
Consider a client request for ARS with the following policy:
* Primary objective: Minimize Total Service Time.
* Hard constraint: Price <= 8.
* Secondary objective: Maximize GAS (prefer sites with more
available capacity).
The CST and NST are as in the initial state (Scenario A):
Zhang, et al. Expires 18 March 2027 [Page 28]
Internet-Draft CATS Service Metrics Operation September 2026
Computing Service Table (CST):
+=======+===================+=====+===============+===================+
| CS-ID | CSCI-ID (IP:Port) | GAS | Comp Time(ms) | Price (Optional) |
+=======+===================+=====+===============+===================+
| ARS | 188.3.67.3:67 | 400 | 5 | 10 |
+-------+-------------------+-----+---------------+-------------------+
| ARS | 188.3.67.4:69 | 600 | 6 | 5 |
+-------+-------------------+-----+---------------+-------------------+
Network Service Table (NST):
+========================+=======================+============+
| Ingress CATS-Forwarder | Egress CATS-Forwarder | Network |
| | | Delay (ms) |
+========================+=======================+============+
| 10.0.0.1 | 188.3.67.3 (CF-2) | 8 |
+------------------------+-----------------------+------------+
| 10.0.0.1 | 188.3.67.4 (CF-3) | 6 |
+------------------------+-----------------------+------------+
Step 1: Service Lookup Candidates: 188.3.67.3:67 and 188.3.67.4:69.
Step 2: Constraint Filtering (Hard Constraints) Apply Price <= 8:
* 188.3.67.3:67 has Price = 10 -> EXCLUDED.
* 188.3.67.4:69 has Price = 5 -> RETAINED.
Candidate_Set = { 188.3.67.4:69 }.
Step 3-5: The C-PS computes TST for the remaining candidate: TST = 6
ms + 6 ms = 12 ms. Only one candidate remains, so 188.3.67.4:69
is selected.
This scenario demonstrates how hard constraints (Price <= 8) filter
out expensive candidates before optimization. Even though
188.3.67.3:67 has a slightly better computing time (5 ms vs. 6 ms),
it is excluded due to price.
Now suppose the client policy changes to Price <= 12 (relaxing the
constraint). Both candidates are eligible:
Step 4: Total Service Time Computation
* 188.3.67.3:67: TST = 5 ms + 8 ms = 13 ms.
* 188.3.67.4:69: TST = 6 ms + 6 ms = 12 ms.
Zhang, et al. Expires 18 March 2027 [Page 29]
Internet-Draft CATS Service Metrics Operation September 2026
Step 5: Optimization Selection 188.3.67.4:69 has lower TST (12 ms
vs. 13 ms) and is selected.
However, if the policy includes a secondary objective (maximize GAS)
and both candidates have the same TST (e.g., due to a network change
making both paths equal), the tie-breaker rule selects the candidate
with higher GAS. If 188.3.67.4:69 has GAS = 600 and 188.3.67.3:67
has GAS = 400, the C-PS prefers 188.3.67.4:69.
This scenario demonstrates the interaction between hard constraints,
primary optimization (TST), and secondary tie-breaking (GAS).
8. Update Control in Large-Scale Deployments
In large-scale deployments with hundreds of service sites and
thousands of service instances, unconstrained metric updates can
overwhelm the C-PS and the control-plane network. This section
defines update control mechanisms. These mechanisms are consistent
with the scalability considerations of
[I-D.ietf-cats-metric-definition-11] (Section 3.1) and with the CATS
OAM framework [I-D.ietf-cats-oam-fw] (O-REQ-1: balanced periodic and
threshold-triggered reporting; O-REQ-4: freshness handling).
Delta-Threshold Reporting: Each C-SMA maintains a local metric
cache. Per-session GAS changes are accumulated locally. The
C-SMA reports an update only when:
* GAS changes by more than a configured absolute threshold (e.g.,
50 slots) or relative threshold (e.g., 10%).
* Computing Time changes by more than a configured relative
threshold (e.g., 20%).
* Health status changes (HEALTHY <-> DEGRADED <-> UNHEALTHY).
* A periodic heartbeat interval expires (e.g., every 60 seconds).
Hierarchical Aggregation: In deployments with many SCIs per site,
the C-SMA MAY aggregate per-SCI metrics into a single per-site
advertisement. This reduces the number of entries in the CST and
the control-plane update load. However, per-SCI granularity is
lost, and the Egress CATS-Forwarder must perform local CSCI-ID
selection.
Rate Limiting and Dampening: The C-PS SHOULD implement rate limiting
Zhang, et al. Expires 18 March 2027 [Page 30]
Internet-Draft CATS Service Metrics Operation September 2026
on incoming C-SMA reports to prevent update storms during network
events (e.g., flash crowds, DDoS attacks). If a C-SMA exceeds the
allowed update rate, the C-PS MAY drop excess updates or throttle
the C-SMA.
Soft-State Aging: The C-PS ages out CST entries whose Expiry Time
has passed. The default expiry time SHOULD be 3x the C-SMA
heartbeat interval. If no update is received within the expiry
time, the C-PS sets GAS = 0 for that entry and triggers re-
computation for affected sessions.
9. Security Considerations
This section complements the general security requirements for CATS
metrics defined in Section 7 of [I-D.ietf-cats-metric-definition-11]:
integrity (SEC-1), authenticity (SEC-2), controllability (SEC-3),
freshness (SEC-4), and confidentiality (SEC-5). The requirements
below are specific to the Computing Service Metrics and the Joint
Selection Algorithm defined in this document; they MUST be applied in
addition to, and consistent with, the general requirements.
The dynamic reporting of Service Metrics introduces potential attack
vectors. Authentication mechanisms between service sites and C-SMAs
MUST be enforced. The Security Level (Section 5.4.3) can be utilized
by the C-PS to prevent routing sensitive traffic to compromised
sites.
Service Metric reports influence service selection and therefore need
integrity protection, source authentication, and authorization
checks. Deployments should protect against forged, replayed, or
stale metric reports, for example by using freshness information and
aging out old metric state. Implementations should also consider
rate limiting or aggregation policies so that abnormal local events
do not create excessive update bursts toward the C-PS.
The Joint Selection Algorithm relies on the integrity of both the CST
and the NST. If an attacker injects false network delays into the
NST or false computing times into the CST, traffic may be misdirected
to suboptimal or compromised service sites. Therefore, both the
C-NMA and C-SMA MUST authenticate their reports to the C-PS, and the
C-PS MUST validate the freshness and plausibility of all inputs.
Specific threats related to individual Computing Service Metrics
include:
GAS Inflation: A malicious or compromised service site could
Zhang, et al. Expires 18 March 2027 [Page 31]
Internet-Draft CATS Service Metrics Operation September 2026
advertise artificially high GAS values to attract more traffic
than it can handle, leading to overload and service degradation
for all clients. The C-PS SHOULD implement plausibility checks
(e.g., comparing reported GAS against historical capacity, or
validating against observed session success rates) and SHOULD
penalize sites that consistently fail to honor their advertised
GAS.
Computing Time Under-reporting: A service site could under-report
Computing Time to appear more attractive in the TST calculation.
The C-PS SHOULD maintain a moving average of observed response
times and SHOULD flag sites whose reported Computing Time deviates
significantly from observed values.
Reputation Gaming: Malicious users or coordinated botnets could
submit fake positive feedback to inflate a site's reputation
score, or fake negative feedback to damage a competitor. The C-PS
SHOULD implement anti-gaming measures such as rate limiting on
feedback submissions, identity verification, outlier detection,
and weighting feedback by client trust level.
Price Manipulation: While Price is self-defined by the service site,
a provider could temporarily set an artificially low price to
capture market share and then raise it abruptly. The C-PS MAY
implement price-change dampening (e.g., ignoring price increases
above a threshold within a short time window) to protect clients
from bait-and-switch tactics.
Security Level Misrepresentation: The Security Level is self-
reported by the service site. A compromised site could claim a
high security score while actually being vulnerable. The C-PS
SHOULD verify security claims through independent audits, trusted
third-party attestations, or automated security scanning where
available. A Security Level without external validation SHOULD be
treated as a hint rather than a guarantee.
CST/NST Poisoning: If an attacker gains control of a C-SMA or C-NMA,
or injects false reports into the control channel, both the CST
and NST can be poisoned. This could lead to systematic mis-
steering of traffic. All control-plane channels between C-SMA/
C-NMA and C-PS MUST be integrity-protected (e.g., using TLS or
IPsec) and mutually authenticated.
Finally, the C-PS itself is a critical security component. If
compromised, it could steer all traffic to an attacker-controlled
service site. The C-PS SHOULD run in a hardened environment, and its
policy configuration SHOULD be protected against unauthorized
modification.
Zhang, et al. Expires 18 March 2027 [Page 32]
Internet-Draft CATS Service Metrics Operation September 2026
10. IANA Considerations
This section follows the guidelines in [RFC8126].
10.1. CATS Computing Service Metrics
[I-D.ietf-cats-metric-definition-11] requests IANA to create the
"CATS Metrics" registry under the "Computing-Aware Traffic Steering
(CATS)" heading. To keep a single point of registration for CATS
metrics, this document does not request a separate registry.
Instead, the service-oriented metric entries defined in this document
(GAS, Computing Time, Price, Reputation, and Security Level) are
registered as entries in the "CATS Metrics" registry, in a dedicated
"Computing Service Metrics" section of that registry.
Each registry entry contains the following fields:
* Identifier: A unique integer assigned by IANA.
* Name: The formal metric name.
* URI: A stable URI reference for the metric entry.
* Description: A brief description of the metric.
* Change Controller: The entity responsible for the metric
definition (IETF for entries defined in this document and its
companion registry document).
* Version: The version of the metric definition.
The registration policy for these entries is "IETF Review" [RFC8126],
consistent with the CATS metric framework, because the entries
influence traffic steering decisions. The policy is aligned between
this document and the companion registry document
[I-D.zhangb-cats-service-metric-registry-entries].
The initial entries are listed below. Full registry definitions
(including Summary, Metric Definition, Method of Measurement, Output,
and Administrative Items) are provided in the companion document
[I-D.zhangb-cats-service-metric-registry-entries], which serves as
the authoritative specification for the initial entries. The naming
convention follows the pattern defined in that document ("Svc_"
prefix), extending the "Norm_"/"Comb_" naming of
[I-D.ietf-cats-metric-definition-11] to service-oriented metrics that
are not normalized scores (e.g., GAS) or that are score attributes
(e.g., Reputation).
Zhang, et al. Expires 18 March 2027 [Page 33]
Internet-Draft CATS Service Metrics Operation September 2026
+------------+---------------------------------------+
| Identifier | Metric Name (short) |
+------------+---------------------------------------+
| TBD1 | GAS |
| TBD2 | Computing Time |
| TBD3 | Price |
| TBD4 | Reputation |
| TBD5 | Security Level |
+------------+---------------------------------------+
Note: The allocation of identifiers and the exact relationship
between this registry section and the "CATS Metrics" registry are to
be finalized in coordination with the CATS working group before
publication.
11. References
11.1. Normative References
[I-D.ietf-cats-framework-24]
Li, C., Du, Z., Boucadair, M., Contreras, L. M., and J.
Drake, "A Framework for Computing-Aware Traffic Steering
(CATS)", Work in Progress, Internet-Draft, draft-ietf-
cats-framework-24, April 2026,
<https://datatracker.ietf.org/doc/html/draft-ietf-cats-
framework-24>.
[I-D.ietf-cats-metric-definition-11]
Kehan, Y., Li, C., Contreras, L. M., Ros-Giralt, J., and
G. Zeng, "CATS Metrics Definition", Work in Progress,
Internet-Draft, draft-ietf-cats-metric-definition-11, 4
September 2026, <https://datatracker.ietf.org/doc/html/
draft-ietf-cats-metric-definition-11>.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997,
<https://www.rfc-editor.org/info/rfc2119>.
[RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for
Writing an IANA Considerations Section in RFCs", RFC 8126,
June 2017, <https://www.rfc-editor.org/info/rfc8126>.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", BCP 14, RFC 8174, May 2017,
<https://www.rfc-editor.org/info/rfc8174>.
11.2. Informative References
Zhang, et al. Expires 18 March 2027 [Page 34]
Internet-Draft CATS Service Metrics Operation September 2026
[I-D.ietf-cats-oam-fw]
Fu, H., Xiong, Q., Du, Z., Liu, B., and Z. Li, "Computing-
Aware Traffic Steering (CATS) Operations, Administration,
and Maintenance (OAM) Framework", Work in Progress,
Internet-Draft, draft-ietf-cats-oam-fw-01, 21 July 2026,
<https://datatracker.ietf.org/doc/html/draft-ietf-cats-
oam-fw-01>.
[I-D.yl-cats-data-model]
Yao, H., Lin, C., Li, Z., Xiong, Q., and L. M. Contreras,
"Data Model for Computing-Aware Traffic Steering (CATS)",
Work in Progress, Internet-Draft, draft-yl-cats-data-
model-07, 6 July 2026,
<https://datatracker.ietf.org/doc/html/draft-yl-cats-data-
model-07>.
[I-D.yxl-cats-protocols-applicability]
Yao, H., Dunbar, L., Xiong, Q., and C. Lin, "Protocols
Applicability for Computing-Aware Traffic Steering
(CATS)", Work in Progress, Internet-Draft, draft-yxl-cats-
protocols-applicability-01, 2 July 2026,
<https://datatracker.ietf.org/doc/html/draft-yxl-cats-
protocols-applicability-01>.
[I-D.zhangb-cats-cmas-04]
Zhang, B., Dai, Y., Du, Z., Li, C., and C. Miao, "Public
Service Platform for Computing-Aware Traffic Steering
(CATS)", Work in Progress, Internet-Draft, draft-zhangb-
cats-cmas-04, 13 May 2026,
<https://datatracker.ietf.org/doc/html/draft-zhangb-cats-
cmas-04>.
[I-D.zhangb-cats-service-metric-registry-entries]
Zhang, B., Dai, Y., Du, Z., and C. Miao, "IANA Registry
Entries for CATS Computing Service Metrics", Work in
Progress, Internet-Draft, draft-zhangb-cats-service-
metric-registry-entries, 23 August 2026,
<https://datatracker.ietf.org/doc/html/draft-zhangb-cats-
service-metric-registry-entries>.
[RFC4760] Bates, T., Chandra, R., Katz, D., and Y. Rekhter,
"Multiprotocol Extensions for BGP-4", RFC 4760, January
2007, <https://www.rfc-editor.org/info/rfc4760>.
[RFC7149] Boucadair, M. and C. Jacquenet, "Software-Defined
Networking: A Perspective from within a Service Provider
Environment", RFC 7149, March 2014,
<https://www.rfc-editor.org/info/rfc7149>.
Zhang, et al. Expires 18 March 2027 [Page 35]
Internet-Draft CATS Service Metrics Operation September 2026
[RFC7426] Haleplidis, E., Ed., Pentikousis, K., Ed., Denazis, S.,
Salim, J. H., Meyer, D., and O. Koufopavlou, "Software-
Defined Networking (SDN): Layers and Architecture
Terminology", RFC 7426, January 2015,
<https://www.rfc-editor.org/info/rfc7426>.
[RFC7471] Giacalone, S., Ward, D., Drake, J., Atlas, A., and S.
Previdi, "OSPF Traffic Engineering (TE) Metric
Extensions", RFC 7471, March 2015,
<https://www.rfc-editor.org/info/rfc7471>.
[RFC8570] Ginsberg, L., Ed., Previdi, S., Ed., Giacalone, S., Ward,
D., Drake, J., and Q. Wu, "IS-IS Traffic Engineering (TE)
Metric Extensions", RFC 8570, March 2019,
<https://www.rfc-editor.org/info/rfc8570>.
[RFC8571] Ginsberg, L., Ed., Previdi, S., Wu, Q., Tantsura, J., and
C. Filsfils, "BGP - Link State (BGP-LS) Advertisement of
IGP Traffic Engineering Performance Metric Extensions",
RFC 8571, March 2019,
<https://www.rfc-editor.org/info/rfc8571>.
[RFC8911] Bagnulo, M., Claise, B., Eardley, P., Morton, A., and A.
Akhter, "Registry for Performance Metrics", RFC 8911,
November 2021, <https://www.rfc-editor.org/info/rfc8911>.
[RFC8990] Bormann, C., Carpenter, B., Ed., and B. Liu, Ed., "GeneRic
Autonomic Signaling Protocol (GRASP)", RFC 8990, March
2021, <https://www.rfc-editor.org/info/rfc8990>.
Authors' Addresses
Bin Zhang (editor)
Pengcheng Laboratory
Email: zhangb@pcl.ac.cn
Yina Dai (editor)
Sun Yat-sen University
Email: daiyn5@mail2.sysu.edu.cn
Zongpeng Du (editor)
China Mobile
Email: duzongpeng@chinamobile.com
Zhang, et al. Expires 18 March 2027 [Page 36]
Internet-Draft CATS Service Metrics Operation September 2026
Guanming Zeng
Huawei Technologies
Email: zengguanming@huawei.com
Chuanyang Miao (editor)
ZTE Corporation
Email: miao.chuanyang@zte.com.cn
Zhang, et al. Expires 18 March 2027 [Page 37]