Computing Service Metric Definitions and Operation under CATS
draft-zhangb-cats-service-metrics-op-03
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-06-30 | ||
| 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-03
Computing-Aware Traffic Steering B. Zhang, Ed.
Internet-Draft Pengcheng Laboratory
Intended status: Standards Track Y. Dai, Ed.
Expires: 2 January 2027 Sun Yat-sen University
Z. Du, Ed.
China Mobile
G. Zeng
Huawei Technologies
C. Miao, Ed.
ZTE Corporation
1 July 2026
Computing Service Metric Definitions and Operation under CATS
draft-zhangb-cats-service-metrics-op-03
Abstract
Computing-Aware Traffic Steering (CATS) optimizes traffic forwarding
by considering both computing and networking metrics. While the
existing framework and metric drafts provide theoretical models
(e.g., L1/L2 normalized metrics), they face significant challenges to
achieve direct operational execution in real-world deployments.
Normalization methods vary across providers, and aggregated unitless
scores often lose critical operational information, making it
difficult for routers to make precise decisions.
This document is proposed to fill this gap by providing an executable
approach. It defines a set of Computing Service Metrics and their
operations under the CATS framework. Instead of transmitting low-
level raw hardware metrics, service sites dynamically evaluate and
report service-oriented metrics (e.g., Global Available Slots) to the
control plane. The document also clarifies how such service-oriented
metrics can be derived from basic resource information, service
reference information, and local policy, and how updates can be
controlled in large-scale deployments. This enables efficient and
precise traffic-steering policies without negating the value of
existing normalized metrics.
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/.
Zhang, et al. Expires 2 January 2027 [Page 1]
Internet-Draft Computing Service Metrics and Operation July 2026
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 2 January 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 . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Motivation and Problem Statement . . . . . . . . . . . . . . 4
4. Service Information and Metrics Definition . . . . . . . . . 5
4.1. Derivation from Basic and Reference Information . . . . . 5
4.2. Mandatory Computing Service Information . . . . . . . . . 5
4.2.1. Global Available Slots (GAS) . . . . . . . . . . . . 5
4.2.2. Computing Time . . . . . . . . . . . . . . . . . . . 6
4.3. Optional Extension Metrics . . . . . . . . . . . . . . . 7
4.3.1. Cost . . . . . . . . . . . . . . . . . . . . . . . . 7
4.3.2. Reputation . . . . . . . . . . . . . . . . . . . . . 7
4.3.3. Security Label . . . . . . . . . . . . . . . . . . . 7
4.3.4. Capability (L1/L2 Compatibility) . . . . . . . . . . 8
5. Operation under CATS Framework . . . . . . . . . . . . . . . 8
5.1. Dynamic Metric Reporting . . . . . . . . . . . . . . . . 8
5.2. Information Collection and Routing Policies . . . . . . . 9
6. Use Case Example . . . . . . . . . . . . . . . . . . . . . . 10
6.1. Service Distribution and Table Formation . . . . . . . . 10
6.2. Service Consumption and Resource Allocation . . . . . . . 12
7. Security Considerations . . . . . . . . . . . . . . . . . . . 14
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14
9. References . . . . . . . . . . . . . . . . . . . . . . . . . 14
9.1. Informative References . . . . . . . . . . . . . . . . . 14
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 15
Zhang, et al. Expires 2 January 2027 [Page 2]
Internet-Draft Computing Service Metrics and Operation July 2026
1. Introduction
The Computing-Aware Traffic Steering (CATS)
[I-D.ietf-cats-framework-24] architecture aims to steer service
traffic to the most suitable service contact instance by evaluating
both network state and computing resource availability. To achieve
this, CATS Service Metric Agents (C-SMAs) collect computing metrics
and advertise them to CATS Path Selectors (C-PSes).
[I-D.ietf-cats-metric-definition-10] introduces a multi-level metric
framework (Level 0, Level 1, Level 2) and proposes normalizing
heterogeneous computing metrics into unitless scores (e.g.,
compute_norm). While this establishes a solid theoretical baseline,
mapping diverse hardware capabilities (CPUs, GPUs, NPUs) into a
single normalized score is highly complex and provider-dependent. In
practice, additional service-oriented abstractions are useful for
expressing the actual service capacity needed for fine-grained
traffic steering.
To fill the gap between theoretical metric definitions and practical
implementation, this document introduces a set of Computing Service
Metrics. By decoupling the service capacity from hardware-specific
raw metrics, service sites can directly expose actionable metrics
that describe their concrete ability to handle specific services.
These metrics complement the existing normalized metric framework and
focus on operational use under the CATS architecture.
2. Terminology
This document makes use of the terms defined in
[I-D.ietf-cats-framework-24] and
[I-D.ietf-cats-metric-definition-10]. 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
clients 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.
Zhang, et al. Expires 2 January 2027 [Page 3]
Internet-Draft Computing Service Metrics and Operation July 2026
* 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.
3. 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 works introduce a comprehensive framework that
categorizes computing metrics into Raw Metrics (Level 0) and
Normalized Metrics (Level 1 and Level 2). However, a critical gap
remains: how exactly to use these hardware-centric metrics to
effectively steer traffic in operational networks.
This document does not negate the value of L1/L2 normalized metrics;
rather, it identifies that relying solely on the normalization of raw
hardware metrics poses operational challenges during routing
execution:
1. The Implementation Gap (HOW to normalize?): In a real-world
multi-vendor network, computing resources are highly
heterogeneous. It is extremely difficult to establish a unified
mathematical model that fairly normalizes a GPU's capacity and a
CPU's capacity into the same 0-10 score.
2. The Information Loss Gap (WHY disseminate raw features?):
Normalizing diverse hardware capabilities into a single unitless
score results in the loss of actionable information. A
normalized compute score of "7" cannot explicitly guarantee a
client's <10 ms delay requirement.
3. The Routing Mechanism Gap (WHO uses this data?): Routers (C-PS)
do not need to know whether a service is backed by a CPU or a
GPU. They only care about routing parameters: "Is there
capacity?", "How long will it take?", and "Where is the
destination?".
To bridge this gap, CATS requires a Service-Oriented Abstraction. We
explicitly divide the required service information into Mandatory
Computing Service Metrics and Optional Extension Metrics to support
executable traffic-steering policies.
Zhang, et al. Expires 2 January 2027 [Page 4]
Internet-Draft Computing Service Metrics and Operation July 2026
4. 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. This document focuses on the
semantics and operational use of these metrics, rather than defining
new routing, transport, signaling, or wire-encoding mechanisms.
4.1. Derivation from Basic and Reference Information
The Computing Service Metrics defined in this document are not raw
hardware readings. They are service-oriented abstractions 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.
4.2. 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.
4.2.1. Global Available Slots (GAS)
GAS is the core contribution of this metric framework. It represents
the maximum number of concurrent clients that a service site is
willing and able to serve for a specific CS-ID through a specific
CSCI-ID at a given time.
Zhang, et al. Expires 2 January 2027 [Page 5]
Internet-Draft Computing Service Metrics and Operation July 2026
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.
As the number of concurrent users 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: L0/TBD
Value: 500
Source: estimation
Encoding details, including field length and wire format, are TBD.
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.
Zhang, et al. Expires 2 January 2027 [Page 6]
Internet-Draft Computing Service Metrics and Operation July 2026
Basic fields:
Metric Type: comp_time
Level: L0/TBD
Unit: ms
Value: 5
Source: estimation
Encoding details, including field length and wire format, are TBD.
4.3. Optional Extension Metrics
To accommodate advanced traffic-steering scenarios and maintain
backward compatibility, the following optional fields are defined.
4.3.1. Cost
Self-defined by the service site to apply administrative or economic
billing policies.
Basic fields:
Metric Type: cost
Level: L0/TBD
Value: 100
Source: nominal
Encoding details, including field length and wire format, are TBD.
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*.
Basic fields:
Metric Type: reputation
Level: L0/TBD
Value: 8
Source: estimation (user feedback)
Encoding details, including field length and wire format, are TBD.
4.3.3. Security Label
The Security Label reflects the security status of a service site. A
higher score indicates a more secure site.
Score range: 0-10 (0 indicates the poorest security; 10 indicates
optimal security).
Zhang, et al. Expires 2 January 2027 [Page 7]
Internet-Draft Computing Service Metrics and Operation July 2026
Basic fields:
Metric Type: security_label
Level: L0/TBD
Value: 9
Source: estimation
Encoding details, including field length and wire format, are TBD.
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: L1/L2/TBD
Value: 7
Source: normalization
Encoding details, including field length and wire format, are TBD.
5. Operation under CATS Framework
5.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.
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
Zhang, et al. Expires 2 January 2027 [Page 8]
Internet-Draft Computing Service Metrics and Operation July 2026
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.
5.2. Information Collection and Routing Policies
To ensure separation of concerns between computing resources and
network states, the C-PS maintains two distinct data structures.
Network metrics do not need to be normalized or redefined in CATS;
they rely on existing network mechanisms.
* Computing Service Table: Formed by the C-SMA. It gathers service
identifiers and service-oriented metrics (GAS, Computing Time,
etc.) and is indexed by CS-ID.
* Network Service Table (e.g., TEDB in SDN controller): Formed by
the C-NMA. C-NMA leverages existing techniques (e.g.,[RFC7471],
[RFC8570], and [RFC8571]) to generate it. The Network Service
Table contains network topology and link information (including
delay, jitter, bandwidth, and availability). As an example, when
the C-PS is implemented using an SDN Controller, the Network
Service Table corresponds to the TEDB in the SDN control plane.
When a user request arrives, the C-PS combines the Computing Service
Table and the Network Service Table (e.g., TEDB in SDN controller).
The routing policy works by first querying the Computing Service
Table to find candidate CSCI-IDs that meet the service requirements.
Then, it queries the Network Service Table to determine the path and
delay from the user's Ingress CATS-Forwarder to the candidate Egress
CATS-Forwarder. 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. Finally, the C-PS selects the optimal
CSCI-ID by minimizing the total service time, i.e., computing time
plus ingress-to-egress network delay.
+-------------------------+ +-------------------------+
| Computing Service Table | | Network Service Table |
| (CS-ID, CSCI-ID, GAS, | | (Ingress, Egress, |
| Comp Time) | | delay, jitter, bw) |
+-----------+-------------+ +-----------+-------------+
| |
v v
+----------------------------------------------------------+
| C-PS |
| 1. Query Computing Service Table for candidates |
| 2. Query Network Service Table for ingress-egress path |
| 3. Select CSCI-ID by computing time plus network delay |
+----------------------------------------------------------+
Zhang, et al. Expires 2 January 2027 [Page 9]
Internet-Draft Computing Service Metrics and Operation July 2026
Figure 1: Service Selection Process Combining Computing and Network
Metrics
6. Use Case Example
To illustrate the integrated routing logic of Service Metrics,
consider a scenario where the C-PS combines both computing and
network information. In this example, the C-PS filters candidates
based on CS-ID and Computing Time, and combines that with the network
delay between the Ingress and Egress CATS-Forwarders.
6.1. Service Distribution and Table Formation
Multiple service sites deploy various instances (e.g., AR1, AR2,
LLM1). During deployment, a service site can use reference
information from a public service table, such as the one described in
[I-D.zhangb-cats-cmas-04], together with local resource allocation
and policy to derive the service-oriented metrics that it reports.
The C-SMA at each site pushes its local service information to the
C-PS in the message format (CS-ID, CSCI-ID, Computing Time, GAS,
[Optional Metrics]), forming the following unified Computing Service
Table:
Figure 2 illustrates the metric dissemination process across the
network:
Zhang, et al. Expires 2 January 2027 [Page 10]
Internet-Draft Computing Service Metrics and Operation July 2026
AR1, 188.3.67.3:67, 5ms, 400, cost=10
AR2, 188.3.67.3:68, 15ms, 100, cost=20
:<----------------------:
: : +---------+
: : | AR1 |
: : .--|CSCI-ID 1|
: +----------------+ | +---------+
: | C-SMA |----| Service Site 2
: +----------------+ | +---------+
: |CATS-Forwarder 2| '--| AR2 |
+--------+ : +----------------+ |CSCI-ID 2|
| Client | : | +---------+
+--------+ : Network +----------------------+
| : delay | +-------+ |
| : :<---------| C-NMA | |
| : : | +-------+ |
+---------------------+ | |
|CATS-Forwarder 1|C-PS|----| |
+---------------------+ | Underlay |
:Computing | Infrastructure | +---------+
:Service | | | AR1 |
:Table +----------------------+ .---|CSCI-ID 3|
: | | +---------+
: +----------------+ +------+
: |CATS-Forwarder 3|--|C-SMA | Service Site 3
: +----------------+ +------+
: : |
: : | +-----------+
: : '---| LLM1 |
:<-------------------------------: |CSCI-ID 4 |
AR1, 188.3.67.4:69, 6ms, 600, cost=5 +-----------+
LLM1, 188.3.67.4:70, 12ms, 300, cost=15
Figure 2: An Example of Service Metric Dissemination under CATS
The C-PS stores the C-SMA reports in the Computing Service Table:
Zhang, et al. Expires 2 January 2027 [Page 11]
Internet-Draft Computing Service Metrics and Operation July 2026
+=======+===================+=====+===============+=================+
| CS-ID | CSCI-ID (IP:Port) | GAS | Comp Time(ms) | Cost |
| | | | | (Optional) |
+=======+===================+=====+===============+=================+
| AR1 | 188.3.67.3:67 | 400 | 5 | 10 |
+-------+-------------------+-----+---------------+-----------------+
| AR2 | 188.3.67.3:68 | 100 | 15 | 20 |
+-------+-------------------+-----+---------------+-----------------+
| AR1 | 188.3.67.4:69 | 600 | 6 | 5 |
+-------+-------------------+-----+---------------+-----------------+
| LLM1 | 188.3.67.4:70 | 300 | 12 | 15 |
+-------+-------------------+-----+---------------+-----------------+
Table 1
The C-PS also maintains the Network Service Table (e.g., TEDB in an
SDN controller) for network path information. An example subset
relevant to the Ingress CATS-Forwarder is shown below:
+========================+=======================+============+
| Ingress CATS-Forwarder | Egress CATS-Forwarder | Network |
| | | Delay (ms) |
+========================+=======================+============+
| 10.0.0.1 | 188.3.67.3 | 8 |
+------------------------+-----------------------+------------+
| 10.0.0.1 | 188.3.67.4 | 6 |
+------------------------+-----------------------+------------+
Table 2
Network delay information is maintained in the Network Service
Table rather than being merged into the Computing Service Table. In
this example, network delay refers to the Ingress-to-Egress delay.
6.2. Service Consumption and Resource Allocation
A client requests the AR1 service with a requirement for the shortest
total service time (computing time plus Ingress-to-Egress network
delay). Cost is omitted in this example to focus on the combined
metric.
1. Match CS-ID (Control Plane): The C-PS scans the Computing Service
Table and isolates entries matching CS-ID = AR1. Candidates:
188.3.67.3:67 (Comp Time = 5ms) and 188.3.67.4:69 (Comp Time =
6ms).
Zhang, et al. Expires 2 January 2027 [Page 12]
Internet-Draft Computing Service Metrics and Operation July 2026
2. Query Network Service Table for Network Delay: The C-PS queries
the Network Service Table (e.g., TEDB in an SDN controller) using
the user's Ingress CATS-Forwarder and each candidate Egress CATS-
Forwarder: path to the egress attached to 188.3.67.3 has a
network delay of 8 ms; path to the egress attached to 188.3.67.4
has a network delay of 6 ms.
3. Calculate Total Service Time: The C-PS sums computing time and
Ingress-to-Egress network delay for each candidate: candidate
188.3.67.3:67 has 5 ms + 8 ms = 13 ms; candidate 188.3.67.4:69
has 6 ms + 6 ms = 12 ms. The C-PS selects 188.3.67.4:69 because
it offers the shortest total service time (12 ms), even though
its computing time is slightly higher than candidate 67.
4. Allocate: The selected service site or its C-SMA updates the
local GAS value for 188.3.67.4:69 according to its local resource
allocation policy. The C-SMA does not need to report every per-
session adjustment to the C-PS when the change is operationally
insignificant; it may report aggregated or threshold-based
updates.
5. Return Contact IP (Control Plane): The C-PS sends the selected
contact IP (188.3.67.4:69) to the Ingress CATS-Forwarder (CATS-
Forwarder 1). The Ingress CATS-Forwarder then forwards this
information to the client. The internal metrics (computing time,
network delay, cost, etc.) are shielded from the user.
6. Data Plane Establishment: The client sends the concrete service
data to the Ingress CATS-Forwarder (CATS-Forwarder 1). The
Ingress CATS-Forwarder encapsulates the packets and forwards them
over the CATS-computed path to the selected Egress CATS-Forwarder
(e.g., CATS-Forwarder 2 or 3). The Egress CATS-Forwarder
decapsulates the packets and sends them to the target service
site. After processing, the service site returns the response to
the same Egress CATS-Forwarder, which forwards it back to the
Ingress CATS-Forwarder and then to the client.
7. Release: Once the service session is completed, the selected
service site or its C-SMA restores the local GAS value according
to its local resource release policy. The updated value is
synchronized to the C-PS according to the same local reporting
policy, threshold, or aggregation interval.
Zhang, et al. Expires 2 January 2027 [Page 13]
Internet-Draft Computing Service Metrics and Operation July 2026
7. Security Considerations
The dynamic reporting of Service Metrics introduces potential attack
vectors. Authentication mechanisms between service sites and C-SMAs
MUST be enforced. The Security Label (Section 4.3.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.
8. IANA Considerations
This document has no IANA actions at this time.
9. References
9.1. Informative 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)", April 2026,
<https://datatracker.ietf.org/doc/html/draft-ietf-cats-
framework-24>.
[I-D.ietf-cats-metric-definition-10]
Kehan, Y., Li, C., Contreras, L. M., Ros-Giralt, J., and
G. Zeng, "CATS Metrics Definition", 22 June 2026,
<https://datatracker.ietf.org/doc/html/draft-ietf-cats-
metric-definition-10>.
[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)", 13 May 2026,
<https://datatracker.ietf.org/doc/html/draft-zhangb-cats-
cmas-04>.
[RFC4760] Bates, T., Chandra, R., Katz, D., and Y. Rekhter,
"Multiprotocol Extensions for BGP-4", January 2007,
<https://www.rfc-editor.org/info/rfc4760>.
Zhang, et al. Expires 2 January 2027 [Page 14]
Internet-Draft Computing Service Metrics and Operation July 2026
[RFC8990] Bormann, C., Carpenter, B., Ed., and B. Liu, Ed., "GeneRic
Autonomic Signaling Protocol (GRASP)", March 2021,
<https://www.rfc-editor.org/info/rfc8990>.
[RFC7471] Giacalone, S., Ward, D., Drake, J., Atlas, A., and S.
Previdi, "OSPF Traffic Engineering (TE) Metric
Extensions", 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", 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",
March 2019, <https://www.rfc-editor.org/info/rfc8571>.
[RFC7149] Boucadair, M. and C. Jacquenet, "Software-Defined
Networking: A Perspective from within a Service Provider
Environment", March 2014,
<https://www.rfc-editor.org/info/rfc7149>.
[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", January 2015,
<https://www.rfc-editor.org/info/rfc7426>.
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 2 January 2027 [Page 15]
Internet-Draft Computing Service Metrics and Operation July 2026
Guanming Zeng
Huawei Technologies
China
Email: zengguanming@huawei.com
Chuanyang Miao (editor)
ZTE Corporation
Email: miao.chuanyang@zte.com.cn
Zhang, et al. Expires 2 January 2027 [Page 16]