CATS Metrics Definition
draft-ietf-cats-metric-definition-13
| Document | Type | Active Internet-Draft (cats WG) | |
|---|---|---|---|
| Authors | Kehan Yao , Cheng Li , Luis M. Contreras , Jordi Ros-Giralt , Guanming Zeng | ||
| Last updated | 2026-09-29 | ||
| Replaces | draft-ysl-cats-metric-definition | ||
| RFC stream | Internet Engineering Task Force (IETF) | ||
| Intended RFC status | (None) | ||
| Formats | |||
| Reviews |
OPSDIR Early review
(of
-10)
by Fung Lim
Has issues
PERFMETRDIR Early Review due 2026-10-18
Incomplete
RTGDIR Early Review due 2026-10-18
Incomplete
|
||
| Additional resources | Mailing list discussion | ||
| Stream | WG state | WG Document | |
| Associated WG milestones |
|
||
| Document shepherd | (None) | ||
| IESG | IESG state | I-D Exists | |
| Consensus boilerplate | Unknown | ||
| Telechat date | (None) | ||
| Responsible AD | (None) | ||
| Send notices to | (None) |
draft-ietf-cats-metric-definition-13
Computing-Aware Traffic Steering Y. Kehan
Internet-Draft China Mobile
Intended status: Standards Track C. Li
Expires: 3 April 2027 Huawei Technologies
L. M. Contreras
Telefonica
J. Ros-Giralt
Qualcomm Europe, Inc.
G. Zeng
Huawei Technologies
30 September 2026
CATS Metrics Definition
draft-ietf-cats-metric-definition-13
Abstract
Computing-Aware Traffic Steering (CATS) is a traffic engineering
approach that optimizes the steering of traffic to a service instance
by considering the dynamic state of computing and network resources.
To enable such decisions, CATS components exchange metrics that
describe resource conditions affecting service instance selection.
This document focuses on compute and communication metrics for CATS
and defines a hierarchical abstraction of these metrics to improve
interoperability, scalability, and operational simplicity. It does
not aim to standardize raw infrastructure (Level 0) metrics; instead,
it specifies higher-level representations that can be derived from
raw measurements using aggregation and normalization functions.
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 3 April 2027.
Kehan, et al. Expires 3 April 2027 [Page 1]
Internet-Draft CATS Metrics September 2026
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. Conventions and Definitions . . . . . . . . . . . . . . . . . 4
3. Design Principles . . . . . . . . . . . . . . . . . . . . . . 5
3.1. Three-Level Metrics . . . . . . . . . . . . . . . . . . . 5
3.2. Level 0: Raw Metrics . . . . . . . . . . . . . . . . . . 6
3.3. Level 1: Metrics Combined in Categories . . . . . . . . . 7
3.4. Level 2: A Single Normalized Metric . . . . . . . . . . . 8
4. CATS Metrics Framework and Specification . . . . . . . . . . 8
4.1. CATS Metric Fields . . . . . . . . . . . . . . . . . . . 9
4.2. Aggregation and Normalization Functions . . . . . . . . . 11
4.2.1. Aggregation . . . . . . . . . . . . . . . . . . . . . 12
4.2.2. Normalization . . . . . . . . . . . . . . . . . . . . 13
4.3. Level Metric Representations . . . . . . . . . . . . . . 14
4.3.1. Level 0 Metrics . . . . . . . . . . . . . . . . . . . 14
4.3.2. Level 1 Metrics . . . . . . . . . . . . . . . . . . . 14
4.3.3. Level 2 Global Metric . . . . . . . . . . . . . . . . 17
5. Comparison among Metric Levels . . . . . . . . . . . . . . . 17
6. CATS Metric Registry Entries . . . . . . . . . . . . . . . . 19
6.1. CATS Level 2 Metric Registry Entry . . . . . . . . . . . 19
6.1.1. Summary . . . . . . . . . . . . . . . . . . . . . . . 19
6.1.2. Metric Definition . . . . . . . . . . . . . . . . . . 20
6.1.3. Method of Measurement . . . . . . . . . . . . . . . . 20
6.1.4. Output . . . . . . . . . . . . . . . . . . . . . . . 22
6.1.5. Administrative Items . . . . . . . . . . . . . . . . 22
6.2. CATS Level 1 Metric Registry Entry: Computing . . . . . . 23
6.2.1. Summary . . . . . . . . . . . . . . . . . . . . . . . 23
6.2.2. Metric Definition . . . . . . . . . . . . . . . . . . 24
6.2.3. Method of Measurement . . . . . . . . . . . . . . . . 25
6.2.4. Output . . . . . . . . . . . . . . . . . . . . . . . 26
6.2.5. Administrative Items . . . . . . . . . . . . . . . . 26
6.3. CATS Level 1 Metric Registry Entry: Communication . . . . 27
6.3.1. Summary . . . . . . . . . . . . . . . . . . . . . . . 27
Kehan, et al. Expires 3 April 2027 [Page 2]
Internet-Draft CATS Metrics September 2026
6.3.2. Metric Definition . . . . . . . . . . . . . . . . . . 28
6.3.3. Method of Measurement . . . . . . . . . . . . . . . . 29
6.3.4. Output . . . . . . . . . . . . . . . . . . . . . . . 30
6.3.5. Administrative Items . . . . . . . . . . . . . . . . 31
6.4. CATS Level 1 Metric Registry Entry: Service . . . . . . . 31
6.4.1. Summary . . . . . . . . . . . . . . . . . . . . . . . 31
6.4.2. Metric Definition . . . . . . . . . . . . . . . . . . 33
6.4.3. Method of Measurement . . . . . . . . . . . . . . . . 33
6.4.4. Output . . . . . . . . . . . . . . . . . . . . . . . 35
6.4.5. Administrative Items . . . . . . . . . . . . . . . . 35
6.5. CATS Level 1 Metric Registry Entry: Composed . . . . . . 36
6.5.1. Summary . . . . . . . . . . . . . . . . . . . . . . . 36
6.5.2. Metric Definition . . . . . . . . . . . . . . . . . . 37
6.5.3. Method of Measurement . . . . . . . . . . . . . . . . 38
6.5.4. Output . . . . . . . . . . . . . . . . . . . . . . . 39
6.5.5. Administrative Items . . . . . . . . . . . . . . . . 40
7. Operational Considerations . . . . . . . . . . . . . . . . . 41
7.1. Negotiation of Normalization and Aggregation Functions in
Multi-Vendor Environments . . . . . . . . . . . . . . . . 41
7.2. Metric Level Selection and Update Frequency Trade-offs . 42
7.3. Metric Collection Failures, Fallback Behavior, and Fault
Alarms . . . . . . . . . . . . . . . . . . . . . . . . . 43
7.4. Validation of Metric Values . . . . . . . . . . . . . . . 44
7.5. Management Interoperability . . . . . . . . . . . . . . . 44
8. Security Considerations . . . . . . . . . . . . . . . . . . . 45
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 46
10. References . . . . . . . . . . . . . . . . . . . . . . . . . 47
10.1. Normative References . . . . . . . . . . . . . . . . . . 47
10.2. Informative References . . . . . . . . . . . . . . . . . 49
Appendix A. Level 0 Metric Examples . . . . . . . . . . . . . . 50
A.1. Compute Raw Metrics . . . . . . . . . . . . . . . . . . . 50
A.2. Communication Raw Metrics . . . . . . . . . . . . . . . . 50
A.3. Delay Raw Metrics . . . . . . . . . . . . . . . . . . . . 51
Appendix B. Acknowledgements . . . . . . . . . . . . . . . . . . 51
Contributors . . . . . . . . . . . . . . . . . . . . . . . . . . 51
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 52
1. Introduction
Service providers are deploying computing capabilities across the
network for hosting applications such as distributed AI workloads,
AR/VR and driverless vehicles, among others. In these deployments,
multiple service instances are replicated across various sites to
ensure sufficient capacity for maintaining the required Quality of
Experience (QoE) expected by the application. To support the
selection of these instances, a framework called Computing-Aware
Traffic Steering (CATS) is introduced in [I-D.ietf-cats-framework].
Kehan, et al. Expires 3 April 2027 [Page 3]
Internet-Draft CATS Metrics September 2026
CATS is a traffic engineering approach that optimizes the steering of
traffic to a given service instance by considering the dynamic nature
of computing and network resources. To achieve this, CATS components
require performance metrics for both communication and compute
resources. Since these resources are deployed by multiple providers,
standardized metrics are essential to ensure interoperability and
enable precise traffic steering decisions, thereby optimizing
resource utilization and enhancing overall system performance.
There are already well-defined network metrics for traffic steering,
such as Traffic Engineering (TE) metrics and IGP metrics (e.g., link
delay, link delay variation)[RFC7471], which have been in use in
network systems for a long time. In the context of CATS, computing
metrics need to be introduced to enable joint TE decisions. [DMTF]
defines some fine-grained computing metrics, such as CPU utilization,
but directly using these fine-grained computing metrics lacks
scalability.
This document does not attempt to standardize low-level fine-grained
performance metrics. Instead, it organizes computing and
communication metrics into three abstraction levels and defines a
metric framework based on aggregation and normalization functions.
The framework specifies four categories of Level 1 metrics and a
normalized Level 2 metric, balancing metric expressiveness with
scalability and ease of use.
2. Conventions and Definitions
This document uses the following terms defined in
[I-D.ietf-cats-framework]:
* Computing-Aware Traffic Steering (CATS)
* Service
* Service site
* Service contact instance
* CATS Service Contact Instance ID (CSCI-ID)
* CATS Service Metric Agent (C-SMA)
* CATS Network Metric Agent (C-NMA)
* CATS Path Selector (C-PS)
Kehan, et al. Expires 3 April 2027 [Page 4]
Internet-Draft CATS Metrics September 2026
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.
3. Design Principles
3.1. Three-Level Metrics
As outlined in [I-D.ietf-cats-usecases-requirements], the resource
model that defines CATS metrics MUST be scalable, ensuring that its
implementation remains within a reasonable and sustainable cost. To
that end, a CATS system should select the most appropriate metrics
for instance selection, recognizing that different metrics may
influence outcomes in distinct ways depending on the specific use
case.
Defining metrics requires carefully balancing multiple
considerations, including metric diversity, granularity, and rate of
change (e.g., update frequency or advertisement churn). An excessive
number of metrics, overly fine granularity, or high update frequency
can lead to significant signaling overhead, reducing scalability of
the metric distribution protocol. In contrast, metrics that are too
few, too coarse-grained, or updated too infrequently may fail to
provide sufficient information to support effective operational
decisions.
Conceptually, it is necessary to define at least two fundamental
levels of metrics: one comprising all raw metrics, and the other
representing a simplified form---consisting of a single value that
encapsulates the overall capability of a service instance.
However, such a definition may reduce implementation flexibility
across diverse CATS use cases. Implementers typically seek balanced
approaches that carefully manage trade-offs among encoding
complexity, accuracy, scalability, and extensibility.
To ensure scalability while providing sufficient detail for effective
decision-making, this document provides a definition of metrics that
incorporates three levels of abstraction:
* *Level 0: Raw metrics.* These metrics are presented without
abstraction, with each metric using its own unit and format as
defined by the underlying resource.
Kehan, et al. Expires 3 April 2027 [Page 5]
Internet-Draft CATS Metrics September 2026
* *Level 1: Metrics combined into categories.* These metrics are
derived from Level 0 metrics by applying aggregation functions
and, optionally, normalization functions to form category-specific
metrics, such as computing and communication.
* *Level 2: A single normalized metric.* This metric is computed by
aggregating lower-level metrics (Level 0 or Level 1) and applying
normalization to produce a single, unitless Level 2 score within a
defined range.
3.2. Level 0: Raw Metrics
Level 0 metrics represent detailed, raw measurements collected from
underlying resources. These metrics are typically service-specific
and are not abstracted.
Examples of Level 0 metrics include, but are not limited to:
* *CPU:* Base frequency, boosted frequency, number of cores, core
utilization, memory bandwidth, memory capacity, memory
utilization, and power consumption.
* *GPU:* Frequency, number of processing units, memory bandwidth,
memory capacity, memory utilization, core utilization, and power
consumption.
* *NPU:* Computational capacity, utilization, and power consumption.
* *Communication:* Throughput, bandwidth, link utilization, packet
loss, delay, jitter, traffic counters (bytes and packets), and
other network performance indicators.
* *Storage:* Available capacity, read throughput, and write
throughput.
* *Service-specific metrics:* Request rate (e.g., requests per
second), output rate (e.g., tokens per second), and other
application-level performance indicators.
Level 0 metrics serve as the foundational inputs for the metric
hierarchy. Some metrics are derived from monitoring systems (e.g.,
telemetry or counters), others reflect dynamic runtime state, and
others may correspond to relatively static properties of the
underlying infrastructure. These metrics provide the basic
information required to derive higher-level metrics, as described in
the following sections.
Kehan, et al. Expires 3 April 2027 [Page 6]
Internet-Draft CATS Metrics September 2026
Level 0 metrics can be encoded and exposed using an Application
Programming Interface (API), such as a RESTful API, and can be
technology- and implementation-specific. Different resources can
have their own metrics, each conveying unique information about their
status. These metrics can generally have units, such as bits per
second (bps) or floating point instructions per second (flops), or be
unitless, such as CPU utilization.
As examples, [RFC8911] and [RFC8912] define various network
performance metrics and their associated registries, while [DMTF]
defines a set of computing metrics. These Level 0 metrics are not
standardized in this document; rather, they serve as foundational
inputs that can be used within CATS to derive higher-level metrics.
3.3. Level 1: Metrics Combined in Categories
Level 1 metrics are grouped into four categories: computing,
communication, service, and composed, with the possibility of
additional categories being defined in future specifications. For
each category, a single Level 1 metric is derived through an
aggregation function and, when appropriate, further normalized to
yield a unitless score reflecting the performance of the underlying
resources. The Level 1 categories are described as follows:
* *Computing:* A value derived from aggregating one or more
computing-related Level 0 metrics, such as CPU, GPU, and NPU
utilization.
* *Communication:* A value derived from aggregating one or more
communication-related Level 0 metrics, such as communication
throughput.
* *Service:* A value derived from aggregating one or more service-
related Level 0 metrics, such as tokens per second and service
availability
* *Composed:* A value derived from aggregating a combination of
computing, communication, and service metrics.
Refer to Section 4.2.1 and Section 4.2.2 for the definitions and
examples of aggregation functions and normalization functions,
respectively. Refer to Section 7 for the default policies and
guidance provided to implementations.
Level 1 metrics allow to focus solely on the metric categories and
their simple values, thereby avoiding the need to process solution-
specific Level 0 metrics.
Kehan, et al. Expires 3 April 2027 [Page 7]
Internet-Draft CATS Metrics September 2026
3.4. Level 2: A Single Normalized Metric
The Level 2 metric is a single, normalized score derived from lower-
level metrics (Level 0 and/or Level 1) through the application of
aggregation and normalization functions. Different implementations
may apply different functions to characterize the overall performance
of the underlying computing and communication resources. By
consolidating multiple lower-level metrics into a single score, the
Level 2 metric significantly reduces the complexity associated with
metric collection and distribution. Section 7 further describes
default policies for implementations.
Figure 1 provides a summary of the logical relationships between
metrics across the three levels of abstraction.
+--------+
Level 2 Metric: | M2 |
+---^----+
|
+-------------+-----------+------------+
| | | |
+---+----+ | +---+----+ +---+----+
Level 1 Metrics: | M1-1 | | | M1-2 | | M1-3 | (...)
+---^----+ | +---^----+ +----^---+
| | | |
+----+---+ | +---+----+ |
| | | | | |
+--+---+ +--+---+ +---+--+ +--+---+ +--+---+ +--+---+
Level 0 Metrics:| M0-1 | | M0-2 | | M0-3 | | M0-4 | | M0-5 | | M0-6 | (...)
+------+ +------+ +------+ +------+ +------+ +------+
Figure 1: Logic of CATS Metrics in levels
4. CATS Metrics Framework and Specification
The CATS metrics framework defines how metrics are encoded and
transmitted over the network. The representation should be flexible
enough to accommodate various types of metrics along with their
respective units and precision levels, yet simple enough to enable
easy implementation and deployment across heterogeneous edge
environments.
The design of the CATS metrics framework is guided by the following
principles:
* *Semantic granularity and extensibility:* The framework adopts a
layered abstraction of metrics to balance expressiveness and
scalability. By organizing metrics into multiple levels of
Kehan, et al. Expires 3 April 2027 [Page 8]
Internet-Draft CATS Metrics September 2026
increasing abstraction (e.g., raw, aggregated, and normalized), it
enables implementations to select the appropriate level of detail
for their use case. This approach allows fine-grained metrics to
be preserved at lower levels while exposing more compact and
semantically meaningful representations at higher levels. In
addition, the layered design supports extensibility by allowing
new metrics and categories to be introduced without disrupting
existing deployments.
* *Interoperability and flexibility:* The framework allows
implementation-specific aggregation and normalization functions to
accommodate diverse deployment scenarios and operational
objectives within a single administrative domain. At the same
time, it defines common metric structures and introduces default
policies to guide interpretation, ensuring a consistent
understanding of metrics across vendors. This combination of
flexibility and guidance enables interoperability while preserving
innovation and adaptability in metric computation and usage.
* *Metric provenance and transparency:* The framework explicitly
captures the origin and context of metrics by introducing a
"Source" field, following the model defined in [RFC9439]. This
field distinguishes whether a metric value is derived from direct
measurement, estimation, aggregation, or normalization. By
identifying the source of each metric, the framework improves
transparency and enables implementations to better assess the
reliability, accuracy, and semantics of the reported values.
4.1. CATS Metric Fields
Each CATS metric is expressed as a structured set of fields, with
each field describing a specific property of the metric. The
following definition introduces the fields used in the CATS metric
representations.
* *Metric_Type*: This field specifies the category or kind of CATS
metric being reported, such as computational resources, storage
capacity, or network bandwidth. It acts as a label that enables
network devices to identify the purpose of the metric.
* *Level*: This field specifies the level at which the metric is
measured. It is used to categorize the metric based on its
granularity and scope. There are only three valid metric levels
defined in Section 3.1. This field can take three values: 0 for
Level 0, 1 for Level 1, and 2 for Level 2.
* *Format*: This field indicates the data encoding format of the
metric, such as uint, ieee_754_float.
Kehan, et al. Expires 3 April 2027 [Page 9]
Internet-Draft CATS Metrics September 2026
* *Length*: This field indicates the size of the value field
measured in octets (bytes). It specifies how many bytes are used
to store the value of the metric. The length field is important
for memory allocation and data handling, ensuring that the value
is stored and retrieved correctly.
* *Unit*: This field defines the measurement units for the metric,
such as hertz (Hz) for frequency, bytes (B) for data size, or bits
per seconds (bps) for data transfer rate. It is usually
associated with the metric to provide context for the value.
* *Source*: This field describes the origin of the information used
to obtain the metric. It may include one or more of the following
non-mutually exclusive values:
- 'nominal'. Similar to [RFC9439], "a 'nominal' metric indicates
that the metric value is statically configured by the
underlying devices. For example, bandwidth can indicate the
maximum transmission rate of the involved device.
- 'estimation'. The 'estimation' source indicates that the
metric value is computed through an estimation process.
- 'directly measured'. This source indicates that the metric is
obtained directly from the underlying device and it is not
estimated.
- 'normalization'. The 'normalization' source indicates that the
metric value is normalized. This type of metrics does not have
units. This document specifies that the normalized value range
for each metric is 0 to 10, where 0 indicates the poorest
compute/composed capability, and 10 indicates the optimal
compute/composed capability.
- 'aggregation'. This source indicates that the metric value is
obtained by using an aggregation function.
Nominal metrics have inherent physical meanings and specific units
without any additional processing. Aggregated metrics may or may
not have physical meanings, but they retain their significance
relative to the directly measured metrics. Normalized metrics, on
the other hand, might have physical meanings but lack units.
Kehan, et al. Expires 3 April 2027 [Page 10]
Internet-Draft CATS Metrics September 2026
* *Statistics*: This field provides additional details about the
metrics, particularly if there is any pre-computation performed on
the metrics before they are collected. This field is optional.
It is useful for services that require specific statistics for
service instance selection. The 'Statistics' field must be used
together with the 'Measurement_Window' parameter to indicate the
sampling time interval. There are four kinds of statistics:
- 'max'. The maximum value of the data collected over the
intervals.
- 'min'. The minimum value of the data collected over the
intervals.
- 'mean'. The average value of the data collected over the
intervals.
- 'cur'. The current value of the data collected.
* *Value*: This field represents the actual numerical value of the
metric being measured. It provides the specific data point for
the metric in question.
* *Observation_Time*: This field indicates the instant to which the
value refers, expressed as a date and time in the format defined
in [RFC3339]. This field is optional.
* *Validity_Interval*: This field indicates the period, beginning at
'Observation_Time', during which the metric value remains usable
for instance selection. This field is optional, and where it is
absent, the usable lifetime of the value is determined by local
policy.
The value assignment and encoding rules for these fields are
specified in Section Section 4.3.
4.2. Aggregation and Normalization Functions
In the context of CATS metric processing, aggregation and
normalization are two fundamental operations that transform raw and
derived metrics into forms suitable for decision-making and
comparison across heterogeneous systems.
Kehan, et al. Expires 3 April 2027 [Page 11]
Internet-Draft CATS Metrics September 2026
4.2.1. Aggregation
Aggregation functions combine multiple values into a single
representative value. Aggregation functions can be applied at all
metric levels. This document supports the spatial aggregation and
temporal aggregation that are defined in [RFC5835], and further
defines cross-category aggregation which can aggregate metrics from
different types into a single value. The following are aggregation
examples supported by CATS:
* Spatial or temporal aggregation of multiple metrics of the same
type to produce a derived metric. In this case, because the input
metrics are homogeneous, the resulting metric may retain the same
units as the inputs. For example, CPU utilization measurements
(expressed in percentage) collected from multiple service
instances (spatial aggregation) or averaged over consecutive time
intervals (temporal aggregation) can be aggregated to produce a
representative CPU utilization metric. Such aggregation concepts
are consistent with those described in [RFC5835].
* Aggregation of multiple metrics of different types to produce a
higher-level metric that captures combined behavior across
resource dimensions. In this case, because the input metrics use
different units, the resulting metric cannot retain physical units
and must be expressed as a unitless value. For example, CPU
capacity (expressed in Hz) and available memory (expressed in
bytes) can be combined through aggregation to generate a single
computing-time metric that characterizes overall processing
capability.
Some common aggregation functions include:
* Mean: Computes the arithmetic mean of a set of input values.
* Minimum / Maximum: Selects the lowest or highest value from a set
of input values.
* Weighted average: Computes an average by applying weights to
individual values according to their relative importance or
priority.
Aggregation functions are not standardized in this document. They
are implementation-specific and controlled by operator policies.
Kehan, et al. Expires 3 April 2027 [Page 12]
Internet-Draft CATS Metrics September 2026
+-----------+ +-------------------+
| Metric 1 |---->| |
+-----------+ | Aggregation | +------------+
... | Function |---->| Metric n+1 |
+-----------+ | | +------------+
| Metric n |---->| |
+-----------+ +-------------------+
Input: Multiple values Output: A single value
Figure 2: Aggregation function
4.2.2. Normalization
Normalization functions convert a metric value (with or without
units) into a unitless normalized score. Normalized metrics
facilitate composite scoring and ranking, and can be used to produce
Level 1 and Level 2 metrics. The following are normalization
examples supported by CATS:
* Normalizing a single Level 0 metric to generate a Level 1 or Level
2 normalized metric;
* Normalizing the output of aggregating multiple Level 0 metrics, to
generate a Level 1 normalized metric.
Normalization functions are commonly used to transform metric values
into a bounded range (e.g., an integer scale from 0 to 10) using
techniques such as sigmoid function and min-max scaling
[Min-max-sigmoid]:
* Sigmoid function: Smoothly maps input values to a bounded range.
* Min-max scaling: Rescales values based on known minimum and
maximum bounds.
These normalization functions are also not standardized in this
document. They are implementation-specific and controlled by
operator policies.
+----------+ +------------------------+ +----------+
| Metric 1 |---->| Normalization Function |---->| Metric 2 |
+----------+ +------------------------+ +----------+
Input: Value with or without units Output: Unitless value
Figure 3: Normalization function
Kehan, et al. Expires 3 April 2027 [Page 13]
Internet-Draft CATS Metrics September 2026
4.3. Level Metric Representations
This section specifies the representation format and constraints for
Level 1 and Level 2 metrics, ensuring consistent encoding and
interoperability across implementations.
4.3.1. Level 0 Metrics
Level 0 metrics are raw metrics that are not standardized in this
document. See Appendix A for examples of Level 0 metrics defined in
the compute and communication industries and by other standardization
organizations such as the [DMTF].
4.3.2. Level 1 Metrics
Level 1 metrics are derived from Level 0 metrics through the
application of aggregation functions and, when appropriate,
normalization functions. Depending on how they are formed, Level 1
metrics MAY retain physical units inherited from their inputs or MAY
be expressed as unitless values.
Level 1 metrics are organized into semantic categories such as
computing, communication, service, and composed metrics. This
categorization provides context and meaning to the resulting metrics
and enables consistent interpretation across implementations.
The Source field indicates how the metric value is derived. For
Level 1 metrics, typical values include:
* aggregation: The value is obtained by combining Level 0 metrics
without normalization and MAY retain a physical unit.
* normalization: The value is mapped into a unitless score.
4.3.2.1. Level 1 Computing Metrics
The Metric Type for Level 1 computing metrics is level1_computing.
*Example A: Aggregation-derived (with units)*
Fields:
Metric_type: level1_computing
Level: Level 1
Format: unsigned integer
Length: two octets
Unit: mhz
Source: aggregation
Value: 2400
Kehan, et al. Expires 3 April 2027 [Page 14]
Internet-Draft CATS Metrics September 2026
*Example B: Normalized (unitless)*
Fields:
Metric_type: level1_computing
Level: Level 1
Format: unsigned integer
Length: one octet
Source: normalization
Value: 5
Figure 4: Examples of Level 1 computing metrics
4.3.2.2. Level 1 Communication Metrics
The Metric Type for Level 1 communication metrics is
level1_communication.
*Example A: Aggregation-derived (with units)*
Fields:
Metric_type: level1_communication
Level: Level 1
Format: unsigned integer
Length: two octets
Unit: mbps
Source: aggregation
Value: 800
*Example B: Normalized (unitless)*
Fields:
Metric_type: level1_communication
Level: Level 1
Format: unsigned integer
Length: one octet
Source: normalization
Value: 1
Figure 5: Examples of Level 1 communication metrics
4.3.2.3. Level 1 Service Metrics
The Metric Type for Level 1 service metrics is level1_service.
*Example A: Aggregation-derived (with units)*
Kehan, et al. Expires 3 April 2027 [Page 15]
Internet-Draft CATS Metrics September 2026
Fields:
Metric_type: level1_service
Level: Level 1
Format: unsigned integer
Length: two octets
Unit: rps
Source: aggregation
Value: 45
*Example B: Normalized (unitless)*
Fields:
Metric_type: level1_service
Level: Level 1
Format: unsigned integer
Length: one octet
Source: normalization
Value: 7
Figure 6: Examples of Level 1 service metrics
4.3.2.4. Level 1 Composed Metrics
The Metric Type for Level 1 composed metrics is level1_composed.
*Example A: Aggregation-derived (with units)*
Fields:
Metric_type: level1_composed
Level: Level 1
Format: unsigned integer
Length: two octets
Unit: ms
Source: aggregation
Value: 20
*Example B: Normalized (unitless)*
Fields:
Metric_type: level1_composed
Level: Level 1
Format: unsigned integer
Length: one octet
Source: normalization
Value: 8
Figure 7: Examples of Level 1 composed metrics
Kehan, et al. Expires 3 April 2027 [Page 16]
Internet-Draft CATS Metrics September 2026
4.3.3. Level 2 Global Metric
A Level 2 metric is a single-value, normalized metric that does not
carry any inherent physical unit. While each provider may employ its
own internal methods to compute this value, all providers MUST adhere
to the representation defined in this section to ensure consistent
encoding and interoperable interpretation of the normalized output.
The Metric Type is level2_global and the Source must be
normalization.
Fields:
Metric_type: level2_global
Level: Level 2
Format: unsigned integer
Length: one octet
Source: normalization
Value: 1
Figure 8: Example of a normalized Level 2 metric
5. Comparison among Metric Levels
Metrics are progressively consolidated from Level 0 to Level 1 and
then to Level 2, with each level offering an increasing degree of
abstraction to address the diverse requirements of different
services. Table 1 provides a comparative overview of the defined
metric levels.
+=======+============+===============+===========+==========+
| Level | Encoding | Extensibility | Stability | Accuracy |
| | Complexity | | | |
+=======+============+===============+===========+==========+
| Level | High | Low | Low | High |
| 0 | | | | |
+-------+------------+---------------+-----------+----------+
| Level | Medium | Medium | Medium | Medium |
| 1 | | | | |
+-------+------------+---------------+-----------+----------+
| Level | Low | High | High | Low |
| 2 | | | | |
+-------+------------+---------------+-----------+----------+
Table 1: Comparison among Metrics Levels
Since Level 0 metrics are raw and service-specific, individual
services may define their own metric sets, potentially resulting in
hundreds or even thousands of distinct metrics across deployments.
Kehan, et al. Expires 3 April 2027 [Page 17]
Internet-Draft CATS Metrics September 2026
This diversity introduces significant complexity in protocol encoding
and standardization. Consequently, Level 0 metrics are confined to
bespoke implementations tailored to specific service needs, rather
than being standardized for broad protocol use. In contrast, Level 1
metrics organize raw data into standardized categories, each
consolidated into a single value. This structure makes them more
suitable for protocol encoding and standardization. The Level 2
metric takes simplification a step further by consolidating all
relevant information into a single normalized value, making them the
easiest to encode, transmit, and standardize.
Therefore, from the perspective of encoding complexity, Level 1 and
Level 2 metrics are recommended.
When considering extensibility, Level 0 metrics allow new services to
define their own custom metrics. However, this flexibility requires
corresponding protocol extensions, and the proliferation of metric
types can introduce significant overhead, ultimately reducing the
protocol's extensibility. In contrast, Level 1 metrics introduce
only a limited set of standardized categories, making protocol
extensions more manageable. Level 2 metrics go even further by
consolidating all information into a single normalized value, placing
the least burden on the protocol.
Therefore, from an extensibility standpoint, Level 1 and Level 2
metrics are recommended.
Regarding stability, Level 0 raw metrics would require frequent
protocol extensions as new metrics are introduced, leading to an
unstable and evolving protocol format. For this reason,
standardizing Level 0 metrics within the protocol is not recommended.
In contrast, Level 1 metrics involve only a limited set of predefined
categories, and Level 2 metrics rely on a single consolidated value,
both of which contribute to a more stable and maintainable protocol
design.
Therefore, from a stability standpoint, Level 1 and Level 2 metrics
are preferred.
In conclusion, for CATS, Level 2 metrics are recommended due to their
simplicity and minimal protocol overhead. If more advanced
scheduling capabilities are required, Level 1 metrics offer a
balanced approach with manageable complexity. While Level 0 metrics
are the most detailed and dynamic, their high overhead makes them
unsuitable for direct transmission to network devices and thus not
recommended for standard protocol integration.
Kehan, et al. Expires 3 April 2027 [Page 18]
Internet-Draft CATS Metrics September 2026
6. CATS Metric Registry Entries
This section defines the formal registry entries for one CATS Level 2
metric and four Level 1 metrics, intended for registration with IANA.
The Level 1 registry entries in this section register only the
unitless representations of the Level 1 category metrics. As
described in Section 4.3.2, Level 1 metrics may be unitless or may
retain physical units. Unitless Level 1 metrics may result from
normalization or cross-category aggregation. Level 1 metrics that
retain physical units (e.g., those derived from spatial or temporal
aggregation of Level 0 metrics) are implementation-specific and are
not registered by this document.
By providing a common template that specifies the metric's summary,
definition, method of measurement, output, and administrative items,
this section ensures interoperability among different
implementations.
6.1. CATS Level 2 Metric Registry Entry
This section gives an initial Registry Entry for the CATS Level 2
metric.
6.1.1. Summary
This category includes multiple indexes to the Registry Entry: the
element ID, Metric Name, URI, Metric Description, Metric Controller,
and Metric Version.
6.1.1.1. ID (Identifier)
IANA has allocated the Identifier TBD_1 for the Named Metric Entry in
this section. See the next Section for mapping to Names.
6.1.1.2. Name
Norm_Passive_CATS-Level 2_RFCXXXXsecY_Unitless_Singleton
Naming Rule Explanation
* Norm: Metric type (Normalized Score)
* Passive: Measurement method
* CATS-Level 2: Metric level (CATS Metric Framework Level 2)
* RFCXXXXsecY: Specification reference (To-be-assigned RFC number
and section number)
Kehan, et al. Expires 3 April 2027 [Page 19]
Internet-Draft CATS Metrics September 2026
* Unitless: Metric has no units
* Singleton: Metric is a single value
6.1.1.3. URI
To-be-assigned.
6.1.1.4. Description
This metric represents a single normalized score used within CATS
(Level 2). It is derived by aggregating one or more CATS Level 0
and/or Level 1 metrics, followed by a normalization process that
produces a unitless value. The resulting score provides a concise
assessment of the overall capability of a service instance, enabling
rapid comparison across instances and supporting efficient traffic
steering decisions.
6.1.1.5. Change Controller
IETF
6.1.1.6. Version
1.0
6.1.2. Metric Definition
6.1.2.1. Reference Definition
Referenced sections of this document: Section 3.4 on Level 2 metric
definition and Section 4.2 on aggregation and normalization
functions.
6.1.2.2. Fixed Parameters
* Normalization score range: 0-10 (0 indicates the poorest
capability, 10 indicates the optimal capability)
* Data precision: non-negative integer
6.1.3. Method of Measurement
This category includes columns for references to relevant sections of
the RFC(s) and any supplemental information needed to ensure an
unambiguous method for implementations.
Kehan, et al. Expires 3 April 2027 [Page 20]
Internet-Draft CATS Metrics September 2026
6.1.3.1. Reference Methods
Raw Metrics collection: Collect Level 0 service and compute raw
metrics using platform-specific management protocols or tools (e.g.,
Prometheus [Prometheus] in Kubernetes). Collect Level 0 network
performance raw metrics using existing standardized protocols (e.g.,
NETCONF [RFC6241], IPFIX [RFC7011]).
Aggregation logic: Refer to Section 4.2.1.
Normalization logic: Refer to Section 4.2.2.
The reference method aggregates and normalizes Level 0 metrics to
generate Level 1 metrics in different categories, and further
calculates a Level 2 singleton score for ultimate normalization.
6.1.3.2. Packet Stream Generation
N/A
6.1.3.3. Traffic Filtering (Observation) Details
N/A
6.1.3.4. Sampling Distribution
Sampling method: Continuous sampling (e.g., collect Level 0 metrics
every 10 seconds)
6.1.3.5. Runtime Parameters and Data Format
CATS Service Contact Instance ID (CSCI-ID): an identifier of CATS
service contact instance. According to [I-D.ietf-cats-framework], a
unicast IP address can be an example of identifier. (format: ipv4-
address-no-zone or ipv6-address-no-zone, complying with [RFC9911])
Service_Instance_IP: Service instance IP address (format: ipv4-
address-no-zone or ipv6-address-no-zone, complying with [RFC9911])
Measurement_Window: Metric measurement time window (Units: seconds,
milliseconds; Format: uint64; Default: 10 seconds)
6.1.3.6. Roles
C-SMA: Collects Level 0 service and compute raw metrics, and
optionally calculates Level 1 metrics according to service-specific
strategies.
Kehan, et al. Expires 3 April 2027 [Page 21]
Internet-Draft CATS Metrics September 2026
C-NMA: Collects Level 0 network performance raw metrics, and
optionally calculates Level 1 metrics according to service-specific
strategies.
C-PS: Aggregate all Level 1 metrics collected from C-NMA and C-SMA to
calculate the Level 2 metric.
6.1.4. Output
This category specifies all details of the output of measurements
using the metric.
6.1.4.1. Type
Singleton value
6.1.4.2. Reference Definition
Output format: Refer to Section 4.3.3 of this document.
Score semantics: 0-3 (Low capability, not recommended for steering),
4-7 (Medium capability, optional for steering), 8-10 (High
capability, priority for steering)
6.1.4.3. Metric Units
Unitless
6.1.4.4. Calibration
Calibration method: Conduct benchmark calibration based on standard
test sets (fixed workload) to ensure the output score deviation of
C-SMA and C-NMA is lower than 0.1 (one abnormal score in every ten
test rounds).
6.1.5. Administrative Items
6.1.5.1. Status
Current
6.1.5.2. Requester
To-be-assgined
Kehan, et al. Expires 3 April 2027 [Page 22]
Internet-Draft CATS Metrics September 2026
6.1.5.3. Revision
1.0
6.1.5.4. Revision Date
2026-01-20
6.1.5.5. Comments and Remarks
None
6.2. CATS Level 1 Metric Registry Entry: Computing
This section gives an initial Registry Entry for the CATS Level 1
metric in the _computing_ category.
6.2.1. Summary
This category includes multiple indexes to the Registry Entry: the
element ID, Metric Name, URI, Metric Description, Metric Controller,
and Metric Version.
6.2.1.1. ID (Identifier)
IANA has allocated the Identifier TBD_2 for the Named Metric Entry in
this section. See the next Section for mapping to Names.
6.2.1.2. Name
Comb_Passive_CATS-Level 1_Computing_RFCXXXXsecY_Unitless_Singleton
Naming Rule Explanation
* Comb: Metric type (Combined Score)
* Passive: Measurement method
* CATS-Level 1: Metric level (CATS Metric Framework Level 1)
* Computing: Metric category (Computing)
* RFCXXXXsecY: Specification reference (To-be-assigned RFC number
and section number)
* Unitless: Metric has no units
* Singleton: Metric is a single value for the computing category
Kehan, et al. Expires 3 April 2027 [Page 23]
Internet-Draft CATS Metrics September 2026
6.2.1.3. URI
To-be-assigned.
6.2.1.4. Description
This metric represents a single normalized score for the _computing_
category within CATS (Level 1). It is derived from one or more
computing-related Level 0 metrics (e.g., CPU/GPU/NPU utilization, CPU
frequency, memory utilization, or other computing resource
indicators) by applying an implementation-specific aggregation
function over the selected Level 0 computing metrics and then
applying a normalization function to produce a unitless score.
The resulting score provides a concise indication of the relative
computing capability (or headroom) of a service contact instance for
the purpose of instance selection and traffic steering. Higher
values indicate better computing capability according to the
provider's normalization strategy.
6.2.1.5. Change Controller
IETF
6.2.1.6. Version
1.0
6.2.2. Metric Definition
6.2.2.1. Reference Definition
Referenced sections of this document: Section 3.3 on Level 1
computing metric definition and Section 4.2 on aggregation and
normalization functions.
6.2.2.2. Fixed Parameters
* Normalization score range: 0-10 (0 indicates the poorest computing
capability, 10 indicates the optimal computing capability)
* Data precision: non-negative integer
* Metric type: "level1_computing"
* Level: Level 1
* Metric units: Unitless
Kehan, et al. Expires 3 April 2027 [Page 24]
Internet-Draft CATS Metrics September 2026
6.2.3. Method of Measurement
This category includes columns for references to relevant sections of
the RFC(s) and any supplemental information needed to ensure an
unambiguous method for implementations.
6.2.3.1. Reference Methods
Raw Metrics collection: Collect computing-related Level 0 raw metrics
(e.g., CPU/GPU/NPU, memory, and relevant platform counters) using
platform-specific management protocols or tools (e.g., Prometheus
[Prometheus] in Kubernetes or equivalent telemetry systems).
Aggregation logic (within computing category): Refer to Section 4.2.1
to combine selected Level 0 computing metrics into a single
intermediate value prior to normalization. The selection of Level 0
computing metrics and any weights used are implementation-specific.
Normalization logic: Refer to Section 4.2.2 to map the aggregated (or
directly selected) computing value into the fixed score range.
The reference method aggregates and normalizes Level 0 computing
metrics to generate a single Level 1 computing score
("level1_computing").
6.2.3.2. Packet Stream Generation
N/A
6.2.3.3. Traffic Filtering (Observation) Details
N/A
6.2.3.4. Sampling Distribution
Sampling method: Continuous sampling (e.g., collect underlying Level
0 computing metrics every 10 seconds)
6.2.3.5. Runtime Parameters and Data Format
CATS Service Contact Instance ID (CSCI-ID): an identifier of CATS
service contact instance. According to [I-D.ietf-cats-framework], a
unicast IP address can be an example of identifier. (format: ipv4-
address-no-zone or ipv6-address-no-zone, complying with [RFC9911])
Service_Instance_IP: Service instance IP address (format: ipv4-
address-no-zone or ipv6-address-no-zone, complying with [RFC9911])
Kehan, et al. Expires 3 April 2027 [Page 25]
Internet-Draft CATS Metrics September 2026
Measurement_Window: Metric measurement time window (Units: seconds,
milliseconds; Format: uint64; Default: 10 seconds)
6.2.3.6. Roles
C-SMA: Collects Level 0 compute raw metrics and calculates the Level
1 compute normalized score ("level1_computing") according to service/
provider-specific aggregation and normalization strategies.
C-NMA: Not required for this metric.
6.2.4. Output
This category specifies all details of the output of measurements
using the metric.
6.2.4.1. Type
Singleton value
6.2.4.2. Reference Definition
Output format: Refer to Section 4.3.2 of this document.
Score semantics: 0-3 (Low compute capability, not recommended for
steering), 4-7 (Medium compute capability, optional for steering),
8-10 (High compute capability, priority for steering)
6.2.4.3. Metric Units
Unitless
6.2.4.4. Calibration
Calibration method: Conduct benchmark calibration based on
representative compute workloads (fixed test workload profiles) to
align the mapping from Level 0 computing metrics to the Level 1
score, such that score deviation across measurement agents within the
same administrative domain is minimized (e.g., less than 0.1 over
repeated test rounds).
6.2.5. Administrative Items
6.2.5.1. Status
Current
Kehan, et al. Expires 3 April 2027 [Page 26]
Internet-Draft CATS Metrics September 2026
6.2.5.2. Requester
To-be-assgined
6.2.5.3. Revision
1.0
6.2.5.4. Revision Date
2026-01-20
6.2.5.5. Comments and Remarks
None
6.3. CATS Level 1 Metric Registry Entry: Communication
This section gives an initial Registry Entry for the CATS Level 1
metric in the _communication_ category.
6.3.1. Summary
This category includes multiple indexes to the Registry Entry: the
element ID, Metric Name, URI, Metric Description, Metric Controller,
and Metric Version.
6.3.1.1. ID (Identifier)
IANA has allocated the Identifier TBD_3 for the Named Metric Entry in
this section. See the next Section for mapping to Names.
6.3.1.2. Name
Comb_Passive_CATS-Level
1_Communication_RFCXXXXsecY_Unitless_Singleton
Naming Rule Explanation
* Comb: Metric type (Combined Score)
* Passive: Measurement method
* CATS-Level 1: Metric level (CATS Metric Framework Level 1)
* Communication: Metric category (Communication)
Kehan, et al. Expires 3 April 2027 [Page 27]
Internet-Draft CATS Metrics September 2026
* RFCXXXXsecY: Specification reference (To-be-assigned RFC number
and section number)
* Unitless: Metric has no units
* Singleton: Metric is a single value for the communication category
6.3.1.3. URI
To-be-assigned.
6.3.1.4. Description
This metric represents a single normalized score for the
_communication_ category within CATS (Level 1). It is derived from
one or more communication-related Level 0 metrics (e.g., throughput,
bandwidth, link utilization, loss, delay, jitter, bytes/packets
counters, and other network performance indicators) by applying an
implementation-specific aggregation function over the selected Level
0 communication metrics and then applying a normalization function to
produce a unitless score.
The resulting score provides a concise indication of the relative
communication capability (or headroom) associated with reaching a
service contact instance for the purpose of instance selection and
traffic steering. Higher values indicate better communication
capability according to the provider's normalization strategy.
6.3.1.5. Change Controller
IETF
6.3.1.6. Version
1.0
6.3.2. Metric Definition
6.3.2.1. Reference Definition
Referenced sections of this document: Section 3.3 on Level 1
communication metric definition and Section 4.2 on aggregation and
normalization functions.
Kehan, et al. Expires 3 April 2027 [Page 28]
Internet-Draft CATS Metrics September 2026
6.3.2.2. Fixed Parameters
* Normalization score range: 0-10 (0 indicates the poorest
communication capability, 10 indicates the optimal communication
capability)
* Data precision: non-negative integer
* Metric type: "level1_communication"
* Level: Level 1
* Metric units: Unitless
6.3.3. Method of Measurement
This category includes columns for references to relevant sections of
the RFC(s) and any supplemental information needed to ensure an
unambiguous method for implementations.
6.3.3.1. Reference Methods
Raw Metrics collection: Collect communication-related Level 0 raw
metrics using existing standardized protocols and telemetry systems
(e.g., NETCONF [RFC6241], IPFIX [RFC7011]), and/or using network
performance metric definitions and registries such as [RFC8911],
[RFC8912], and [RFC9439] where applicable.
Aggregation logic (within communication category): Refer to
Section 4.2.1 (e.g., Weighted Average Aggregation) to combine
selected Level 0 communication metrics into a single intermediate
value prior to normalization. The selection of Level 0 communication
metrics and any weights used are implementation-specific.
Normalization logic: Refer to Section 4.2.2 (e.g., Sigmoid
Normalization or Min-max scaling) to map the aggregated (or directly
selected) communication value into the fixed score range.
The reference method aggregates and normalizes Level 0 communication
metrics to generate a single Level 1 communication score
("level1_communication"). No cross-category aggregation is performed
for this metric (i.e., it does not incorporate compute or service
metrics).
6.3.3.2. Packet Stream Generation
N/A
Kehan, et al. Expires 3 April 2027 [Page 29]
Internet-Draft CATS Metrics September 2026
6.3.3.3. Traffic Filtering (Observation) Details
N/A
6.3.3.4. Sampling Distribution
Sampling method: Continuous sampling (e.g., collect underlying Level
0 communication metrics every 10 seconds)
6.3.3.5. Runtime Parameters and Data Format
CATS Service Contact Instance ID (CSCI-ID): an identifier of CATS
service contact instance. According to [I-D.ietf-cats-framework], a
unicast IP address can be an example of identifier. (format: ipv4-
address-no-zone or ipv6-address-no-zone, complying with [RFC9911])
Service_Instance_IP: Service instance IP address (format: ipv4-
address-no-zone or ipv6-address-no-zone, complying with [RFC9911])
Measurement_Window: Metric measurement time window (Units: seconds,
milliseconds; Format: uint64; Default: 10 seconds)
6.3.3.6. Roles
C-NMA: Collects Level 0 communication raw metrics and calculates the
Level 1 communication normalized score ("level1_communication")
according to provider-specific aggregation and normalization
strategies.
C-SMA: Not required for this metric.
6.3.4. Output
This category specifies all details of the output of measurements
using the metric.
6.3.4.1. Type
Singleton value
6.3.4.2. Reference Definition
Output format: Refer to Section 4.3.2 of this document.
Score semantics: 0-3 (Low communication capability, not recommended
for steering), 4-7 (Medium communication capability, optional for
steering), 8-10 (High communication capability, priority for
steering)
Kehan, et al. Expires 3 April 2027 [Page 30]
Internet-Draft CATS Metrics September 2026
6.3.4.3. Metric Units
Unitless
6.3.4.4. Calibration
Calibration method: Conduct benchmark calibration based on
representative network test profiles (e.g., fixed traffic mixes and
path conditions) to align the mapping from Level 0 communication
metrics to the Level 1 score, such that score deviation across
measurement agents within the same administrative domain is minimized
(e.g., less than 0.1 over repeated test rounds).
6.3.5. Administrative Items
6.3.5.1. Status
Current
6.3.5.2. Requester
To-be-assgined
6.3.5.3. Revision
1.0
6.3.5.4. Revision Date
2026-01-20
6.3.5.5. Comments and Remarks
None
6.4. CATS Level 1 Metric Registry Entry: Service
This section gives an initial Registry Entry for the CATS Level 1
metric in the _service_ category.
6.4.1. Summary
This category includes multiple indexes to the Registry Entry: the
element ID, Metric Name, URI, Metric Description, Metric Controller,
and Metric Version.
Kehan, et al. Expires 3 April 2027 [Page 31]
Internet-Draft CATS Metrics September 2026
6.4.1.1. ID (Identifier)
IANA has allocated the Identifier TBD_4 for the Named Metric Entry in
this section. See the next Section for mapping to Names.
6.4.1.2. Name
Comb_Passive_CATS-Level 1_Service_RFCXXXXsecY_Unitless_Singleton
Naming Rule Explanation
* Comb: Metric type (Combined Score)
* Passive: Measurement method
* CATS-Level 1: Metric level (CATS Metric Framework Level 1)
* Service: Metric category (Service)
* RFCXXXXsecY: Specification reference (To-be-assigned RFC number
and section number)
* Unitless: Metric has no units
* Singleton: Metric is a single value for the service category
6.4.1.3. URI
To-be-assigned.
6.4.1.4. Description
This metric represents a single normalized score for the _service_
category within CATS (Level 1). It is derived from one or more
service-related Level 0 metrics that characterize the health and
performance of the service instance itself (e.g., service
availability, request success rate, admission/overload indicators,
tokens per second and/or requests per second, application-level queue
depth, and other service KPIs) by applying an implementation-specific
aggregation function over the selected Level 0 service metrics and
then applying a normalization function to produce a unitless score.
The resulting score provides a concise indication of the relative
service capability (or headroom) of a service contact instance for
the purpose of instance selection and traffic steering. Higher
values indicate better service capability according to the provider's
normalization strategy.
Kehan, et al. Expires 3 April 2027 [Page 32]
Internet-Draft CATS Metrics September 2026
6.4.1.5. Change Controller
IETF
6.4.1.6. Version
1.0
6.4.2. Metric Definition
6.4.2.1. Reference Definition
Referenced sections of this document: Section 3.3 on Level 1 service
metric definition and Section 4.2 on aggregation and normalization
functions.
6.4.2.2. Fixed Parameters
* Normalization score range: 0-10 (0 indicates the poorest service
capability, 10 indicates the optimal service capability)
* Data precision: non-negative integer
* Metric type: "level1_service"
* Level: Level 1
* Metric units: Unitless
6.4.3. Method of Measurement
This category includes columns for references to relevant sections of
the RFC(s) and any supplemental information needed to ensure an
unambiguous method for implementations.
6.4.3.1. Reference Methods
Raw Metrics collection: Collect service-related Level 0 raw metrics
from the service runtime and service management plane using platform-
specific telemetry systems (e.g., Prometheus [Prometheus] in
Kubernetes or equivalent monitoring/observability tools). These
metrics are service-dependent and may include availability/health
status, success/error rates, overload or admission control signals,
and throughput indicators (e.g., tokens per second for AI inference
services), among others.
Kehan, et al. Expires 3 April 2027 [Page 33]
Internet-Draft CATS Metrics September 2026
Aggregation logic (within service category): Refer to Section 4.2.1
(e.g., Weighted Average Aggregation) to combine selected Level 0
service metrics into a single intermediate value prior to
normalization. The selection of Level 0 service metrics, any weights
used, and any gating logic (e.g., forcing the score to a low value
when the instance is unhealthy) are implementation-specific.
Normalization logic: Refer to Section 4.2.2 (e.g., Sigmoid
Normalization or Min-max scaling) to map the aggregated (or directly
selected) service value into the fixed score range.
The reference method aggregates and normalizes Level 0 service
metrics to generate a single Level 1 service score
("level1_service"). No cross-category aggregation is performed for
this metric (i.e., it does not incorporate compute or communication
metrics).
6.4.3.2. Packet Stream Generation
N/A
6.4.3.3. Traffic Filtering (Observation) Details
N/A
6.4.3.4. Sampling Distribution
Sampling method: Continuous sampling (e.g., collect underlying Level
0 service metrics every 10 seconds)
6.4.3.5. Runtime Parameters and Data Format
CATS Service Contact Instance ID (CSCI-ID): an identifier of CATS
service contact instance. According to [I-D.ietf-cats-framework], a
unicast IP address can be an example of identifier. (format: ipv4-
address-no-zone or ipv6-address-no-zone, complying with [RFC9911])
Service_Instance_IP: Service instance IP address (format: ipv4-
address-no-zone or ipv6-address-no-zone, complying with [RFC9911])
Measurement_Window: Metric measurement time window (Units: seconds,
milliseconds; Format: uint64; Default: 10 seconds)
6.4.3.6. Roles
C-SMA: Collects Level 0 service raw metrics and calculates the Level
1 service normalized score ("level1_service") according to service/
provider-specific aggregation and normalization strategies.
Kehan, et al. Expires 3 April 2027 [Page 34]
Internet-Draft CATS Metrics September 2026
C-NMA: Not required for this metric.
6.4.4. Output
This category specifies all details of the output of measurements
using the metric.
6.4.4.1. Type
Singleton value
6.4.4.2. Reference Definition
Output format: Refer to Section 4.3.2 of this document.
Score semantics: 0-3 (Low service capability, not recommended for
steering), 4-7 (Medium service capability, optional for steering),
8-10 (High service capability, priority for steering)
6.4.4.3. Metric Units
Unitless
6.4.4.4. Calibration
Calibration method: Conduct benchmark calibration based on
representative service workload profiles (fixed request mixes and
known-good baselines) to align the mapping from Level 0 service
metrics to the Level 1 score, such that score deviation across
measurement agents within the same administrative domain is minimized
(e.g., less than 0.1 over repeated test rounds). Calibration MAY
include failure/overload scenarios (e.g., simulated dependency
failures or saturation) to ensure score behavior is consistent with
operational intent.
6.4.5. Administrative Items
6.4.5.1. Status
Current
6.4.5.2. Requester
To-be-assigned
Kehan, et al. Expires 3 April 2027 [Page 35]
Internet-Draft CATS Metrics September 2026
6.4.5.3. Revision
1.0
6.4.5.4. Revision Date
2026-01-20
6.4.5.5. Comments and Remarks
None
6.5. CATS Level 1 Metric Registry Entry: Composed
This section gives an initial Registry Entry for the CATS Level 1
metric in the _composed_ category.
6.5.1. Summary
This category includes multiple indexes to the Registry Entry: the
element ID, Metric Name, URI, Metric Description, Metric Controller,
and Metric Version.
6.5.1.1. ID (Identifier)
IANA has allocated the Identifier TBD_5 for the Named Metric Entry in
this section. See the next Section for mapping to Names.
6.5.1.2. Name
Comb_Passive_CATS-Level 1_Composed_RFCXXXXsecY_Unitless_Singleton
Naming Rule Explanation
* Comb: Metric type (Combined Score)
* Passive: Measurement method
* CATS-Level 1: Metric level (CATS Metric Framework Level 1)
* Composed: Metric category (Composed)
* RFCXXXXsecY: Specification reference (To-be-assigned RFC number
and section number)
* Unitless: Metric has no units
* Singleton: Metric is a single value for the composed category
Kehan, et al. Expires 3 April 2027 [Page 36]
Internet-Draft CATS Metrics September 2026
6.5.1.3. URI
To-be-assigned.
6.5.1.4. Description
This metric represents a single normalized score for the _composed_
category within CATS (Level 1). A composed metric is derived by
combining multiple lower-level metrics that may span different
categories (e.g., compute, communication, and service) and/or
multiple components along the request path.
Typical examples of composed metrics include (but are not limited to)
end-to-end delay, application-level response time, or other
synthesized indicators that are computed as a function of multiple
contributing factors (e.g., the sum of compute processing delay and
network transmission delay along the selected path).
The composed Level 1 score is obtained by applying an implementation-
specific aggregation function over the selected contributing Level 0
metrics (and/or previously computed Level 1 category metrics),
followed by a normalization function that yields a unitless score.
Higher values indicate better composed capability according to the
provider's normalization strategy.
6.5.1.5. Change Controller
IETF
6.5.1.6. Version
1.0
6.5.2. Metric Definition
6.5.2.1. Reference Definition
Referenced sections of this document: Section 3.3 on Level 1 composed
metric definition and Section 4.2 on aggregation and normalization
functions.
6.5.2.2. Fixed Parameters
* Normalization score range: 0-10 (0 indicates the poorest composed
capability, 10 indicates the optimal composed capability)
* Data precision: non-negative integer
Kehan, et al. Expires 3 April 2027 [Page 37]
Internet-Draft CATS Metrics September 2026
* Metric type: "level1_composed"
* Level: Level 1
* Metric units: Unitless
6.5.3. Method of Measurement
This category includes columns for references to relevant sections of
the RFC(s) and any supplemental information needed to ensure an
unambiguous method for implementations.
6.5.3.1. Reference Methods
Raw Metrics collection: Collect contributing Level 0 raw metrics from
the relevant sources across categories. For example, compute- and
service-related Level 0 metrics may be collected by a C-SMA using
platform-specific telemetry systems (e.g., Prometheus [Prometheus]),
while communication-related Level 0 metrics may be collected by a
C-NMA using network telemetry and protocols (e.g., NETCONF [RFC6241],
IPFIX [RFC7011]), and/or using network performance metric definitions
and registries such as [RFC8911], [RFC8912], and [RFC9439] where
applicable.
Aggregation logic (within composed category): Refer to Section 4.2.1
(e.g., Weighted Average Aggregation) to combine selected contributing
metrics into a single intermediate value prior to normalization. The
aggregation function MAY combine Level 0 metrics directly, and/or MAY
take as input one or more Level 1 category metrics (e.g.,
"level1_computing" and "level1_communication"). The selection of
contributing metrics, any weights used, and the composition model
(e.g., sum of delays, bottleneck/maximum, or weighted utility) are
implementation-specific.
Normalization logic: Refer to Section 4.2.2 (e.g., Sigmoid
Normalization or Min-max scaling) to map the aggregated composed
value into the fixed score range.
The reference method aggregates and normalizes the selected
contributing metrics to generate a single Level 1 composed score
("level1_composed").
6.5.3.2. Packet Stream Generation
N/A
Kehan, et al. Expires 3 April 2027 [Page 38]
Internet-Draft CATS Metrics September 2026
6.5.3.3. Traffic Filtering (Observation) Details
N/A
6.5.3.4. Sampling Distribution
Sampling method: Continuous sampling (e.g., collect underlying
contributing metrics every 10 seconds)
6.5.3.5. Runtime Parameters and Data Format
CATS Service Contact Instance ID (CSCI-ID): an identifier of CATS
service contact instance. According to [I-D.ietf-cats-framework], a
unicast IP address can be an example of identifier. (format: ipv4-
address-no-zone or ipv6-address-no-zone, complying with [RFC9911])
Service_Instance_IP: Service instance IP address (format: ipv4-
address-no-zone or ipv6-address-no-zone, complying with [RFC9911])
Measurement_Window: Metric measurement time window (Units: seconds,
milliseconds; Format: uint64; Default: 10 seconds)
6.5.3.6. Roles
C-SMA: Collects Level 0 service and compute raw metrics that may
contribute to the composed score, and MAY calculate the Level 1
composed score ("level1_composed") when it has access to the required
inputs.
C-NMA: Collects Level 0 communication raw metrics that may contribute
to the composed score, and MAY calculate the Level 1 composed score
("level1_composed") when it has access to the required inputs.
CATS Controller (or other CATS component): MAY compute the Level 1
composed score when the contributing metrics originate from multiple
agents and are combined at a common computation point.
6.5.4. Output
This category specifies all details of the output of measurements
using the metric.
6.5.4.1. Type
Singleton value
Kehan, et al. Expires 3 April 2027 [Page 39]
Internet-Draft CATS Metrics September 2026
6.5.4.2. Reference Definition
Output format: Refer to Section 4.3.2 of this document.
Score semantics: 0-3 (Low composed capability, not recommended for
steering), 4-7 (Medium composed capability, optional for steering),
8-10 (High composed capability, priority for steering)
6.5.4.3. Metric Units
Unitless
6.5.4.4. Calibration
Calibration method: Conduct benchmark calibration based on
representative end-to-end test profiles (fixed request mixes and
controlled network/compute conditions) to align the mapping from
contributing metrics to the Level 1 composed score. The calibration
goal is to minimize score deviation across measurement agents and
computation points within the same administrative domain (e.g., less
than 0.1 over repeated test rounds). Calibration MAY include failure
and saturation scenarios (e.g., compute overload, network congestion,
and dependency failures) to ensure the composed score behavior is
consistent with operational intent.
6.5.5. Administrative Items
6.5.5.1. Status
Current
6.5.5.2. Requester
To-be-assigned
6.5.5.3. Revision
1.0
6.5.5.4. Revision Date
2026-01-20
6.5.5.5. Comments and Remarks
None
Kehan, et al. Expires 3 April 2027 [Page 40]
Internet-Draft CATS Metrics September 2026
7. Operational Considerations
This section describes operational aspects related to the deployment
and operation of CATS metrics in the network. Since CATS metrics
directly influence instance selection and traffic steering decisions,
operators should consider the following topics when planning,
deploying, and operating CATS systems. Accounting, billing, and SLA
export are out of scope of this document.
7.1. Negotiation of Normalization and Aggregation Functions in Multi-
Vendor Environments
Within a single administrative domain, if CATS components (C-SMA,
C-NMA, C-PS) are supplied by different vendors, it is essential to
ensure that all vendors have a consistent understanding of CATS
metric scores, otherwise, steering decisions may be biased. This is
also explicitly required in Section 5.4 of [I-D.ietf-cats-framework].
This subsection provides operational guidance for negotiating these
functions in scenarios where multi-vendor components within the same
domain need to interoperate.
** Key points for normalization function negotiation:
* Score range: It is recommended to choose a commonly used range
that is easy to read and facilitates subsequent processing, for
example, uniformly adopt 0-10.
* Normalization method type: All parties shall agree on using the
same type of method, for example, min-max scaling, and specify its
key parameters (e.g., upper/lower bounds, reference mean).
** Key points for aggregation function negotiation: aggregation
formula type and weighting coefficients, such as weighted sum,
weighted product, harmonic mean, along with their corresponding
parameters. The specific form and parameters shall be negotiated and
unified among all parties.
** Direction of comparison: explicitly specify whether a higher score
indicates better performance or a lower score indicates better
performance. It is recommended to adopt a uniform direction, or to
specify each metric category separately and clearly document it.
All negotiation results described above should be compiled into a
formal configuration manifest and synchronised, during the
initialisation phase and in an offline manner, to those CATS
components that require metrics for decision-making. The manifest
should be version-controlled to track changes.
Kehan, et al. Expires 3 April 2027 [Page 41]
Internet-Draft CATS Metrics September 2026
After the system goes live, each component must assume by default
that metric values received from other vendors have been processed
according to the agreed functions and are fully comparable, and no
runtime dynamic negotiation is required. To maintain this
comparability, operational calibration is still required. The
administrative-domain operator should run benchmark calibration: at
initial deployment, after changes to the agreed functions or
configuration manifest, and periodically according to operator
policy. Re-calibration should be triggered when score deviation for
the same metric type from different vendors exceeds the configured
threshold, when the proportion of abnormal scores exceeds the
configured limit, or when scores persistently diverge from
application QoE. Calibration methods, trigger thresholds, and
results should be logged and version-controlled together with the
configuration manifest.
7.2. Metric Level Selection and Update Frequency Trade-offs
As discussed in Section 5, the different levels have trade-offs in
encoding complexity, scalability, and stability. Level 1 metrics
(compute, communication, service, composed) retain independent
information per category, making them suitable for scenarios
requiring fine-grained visibility and complex steering policies, but
they increase signalling overhead and computational complexity. The
Level 2 global score provides a single composite value, simplifying
policies and reducing overhead, but it hides the contribution of each
category. Operators should choose based on policy complexity and the
desired granularity of visibility. The choice of metrics and update
frequency affect the control plane, and operators should consider
their network scale and policy responsiveness requirements to jointly
decide on the level and update parameters.
In multi-vendor deployments, the negotiation and calibration of
normalization and aggregation functions affect both Level 1 and Level
2 metrics. When a Level 1 metric of a given category is to be used
across vendors, negotiation and calibration should be performed for
that category. Level 1 preserves per-category information, which
facilitates per-category review and is generally more controllable
and less costly to negotiate than a single Level 2 metric. Level 2
metric should be used only after the aggregation functions of all
categories and the global normalization function have been agreed, so
as to simplify policy and reduce control-plane overhead. If
parameter negotiation cannot be completed, the parties may agree to
use a Level 0 metric of a specific category with explicit unit and
source for decision-making.
Kehan, et al. Expires 3 April 2027 [Page 42]
Internet-Draft CATS Metrics September 2026
** Advertisement rate limit: it is recommended to limit per-instance
metric updates to no more than once per measurement window (e.g., 10
seconds). When scaling to hundreds or thousands of instances, the
total control plane load must be evaluated.
** Strategies to reduce overhead: when the control plane becomes a
bottleneck, operators may:
* increase the measurement window (e.g., to 30 or 60 seconds) to
reduce update frequency.
* advertise only Level 2 global scores rather than full Level 1
category metrics.
* use statistical fields (max, min, mean, cur) to provide summarised
information without increasing the number of updates.
7.3. Metric Collection Failures, Fallback Behavior, and Fault Alarms
** When metrics are unavailable or fail freshness checks, the
following fallback actions are recommended:
* Use last known good value: C-PS may continue using the most recent
valid value for a limited period (e.g., 2 to 3 measurement
windows) while waiting for the metric source to recover.
* Downgrade or exclude the instance: if the metric source exceeds
the configured staleness threshold without recovery, the
associated instance should be downgraded or removed from steering
decisions until a fresh metric is received.
* Fallback to network-only steering: as a last resort, affected
instances may fall back to traditional network-aware steering
(ignoring computing metrics).
It should be noted that CATS Level 1 communication metrics are not
equivalent to generic network performance metrics such as IGP metrics
[RFC7471] or ALTO cost metrics [RFC9439], even if they may share the
same units. CATS Level 1 communication metrics represent the
communication dimension of a service site and are collected by the
C-SMA, whereas generic network performance metrics are collected by
the C-NMA. When CATS metrics and generic network performance metrics
coexist, the C-PS should apply an operator policy that assigns
different weights or priorities to these two types of metrics for
steering decisions. When falling back to network-only steering, the
C-PS should ignore CATS metrics and rely solely on generic network
performance metrics.
Kehan, et al. Expires 3 April 2027 [Page 43]
Internet-Draft CATS Metrics September 2026
** Operators should establish monitoring and alarm mechanisms for the
following conditions:
* Metric freshness failures: timeouts or invalid signatures as
defined in SEC-4 from Section 8 should trigger immediate alarms
* Component unavailability: session interruptions or publication
failures of C-SMA, C-NMA, or C-PS must trigger alarms.
* Score anomalies: including sudden large drops, stuck values, or
significant contradictions between Level 1 category scores and the
Level 2 composite score, and these should trigger alarms.
Upon alarm triggering, operators are required to identify root
causes, apply temporary mitigation policies, and log the event.
7.4. Validation of Metric Values
Operators should periodically validate that normalized or aggregated
metric values still reflect actual instance capabilities. Validation
goals include confirming consistency between metric values and
application performance, detecting implementation or configuration
anomalies, and providing input for re-calibration decisions.
Validation may include:
* Correlating metric value trends with observed application QoE/SLA
metrics.
* Comparing metric value distributions and trends against known-good
reference instances.
* Running fixed workloads to check for deviations from expected
baselines.
Validation frequency and deviation thresholds are determined by
operator policy. Persistent divergence between metric values and
application QoE should trigger re-calibration.
7.5. Management Interoperability
This document does not define a YANG model for CATS metric
configuration and management. The specific mapping of normalization
and aggregation parameters to the YANG model is defined separately in
[I-D.ietf-cats-data-model].
To help operators understand the management objects, this document
distinguishes the following three categories:
Kehan, et al. Expires 3 April 2027 [Page 44]
Internet-Draft CATS Metrics September 2026
* Configuration: normalization bounds, aggregation weights,
Measurement_Window, score range, comparison direction, and
configuration manifest version.
* Operational state: current Level 1 and Level 2 scores, Source,
Observation_Time, Validity_Interval, and freshness status.
* Statistics: max, min, mean, cur, and historical trends.
Standard management interfaces (e.g., NETCONF/RESTCONF with YANG) may
be used to configure and expose these objects.
8. Security Considerations
CATS metrics are not merely telemetry data, but are important inputs
to the traffic steering selection logic. Similar to routing metrics,
incorrect or manipulated metrics can directly affect the underlying
forwarding behaviour, potentially leading to service disruption,
denial-of-service, or policy violation. CATS metrics are dynamic and
sensitive. They may indirectly expose physical locations, health
status, or service topology information of CATS service contact
instances. Access to such metric would allow attackers to sample or
correlate metrics to infer internal service instance states and mount
targeted attacks. Therefore, the security properties of CATS metrics
- integrity, authenticity, controllability, freshness, and
confidentiality, are of critical importance. Adequate measures are
required to prevent these metrics are exposed to non authorized
entites.
_Integrity_: ensures that metric values have not been altered by
unauthorized entities during collection, distribution, or storage.
SEC-1: All metric messages MUST be protected with cryptographic
integrity mechanisms. Receivers MUST verify the integrity of every
metric message before using enclosed metrics for traffic steering
decisions. Any detected integrity violation MUST cause the relevant
metric message to be discarded and SHOULD trigger an alert absent
local policy.
_Authenticity_: ensures that a metric message genuinely originates
from the claimed service contact instance or a trusted publisher.
SEC-2: Each metric publisher MUST be authenticated using strong
cryptographic credentials. Metric messages MUST carry a verifiable
proof of origin that binds a metric to the publisher's identity.
Receivers MUST reject metric messages that cannot be authenticated,
regardless of their content.
Kehan, et al. Expires 3 April 2027 [Page 45]
Internet-Draft CATS Metrics September 2026
_Controllability_: ensures that only explicitly authorized entities
are allowed to publish metrics.
SEC-3: A CATS system MUST enforce fine-grained control policies that
authorize which publishers can report metrics for which services.
Unauthorized publication attempts MUST be rejected and logged.
_Freshness_: ensures that metric values are not stale or replayed.
Only sufficiently recent metric values are used for decision-making.
SEC-4: Each metric message MUST be protected against replay and stale
value. Receivers and C-PS MUST enforce freshness checks.
_Confidentiality_: ensures that metric values are not disclosed to
unauthorized entities during transmission.
SEC-5: Metric messages MUST be encrypted during transmission over any
network. Encryption keys MUST be managed securely and rotated
periodically.
9. IANA Considerations
This document defines several CATS metric registry entries. IANA is
requested to create a new registry titled "CATS Metrics" under a new
"Computing-Aware Traffic Steering (CATS)" registry group.
The initial entries for this registry are defined in Section 6 as
follows:
Kehan, et al. Expires 3 April 2027 [Page 46]
Internet-Draft CATS Metrics September 2026
+========+==============================================+=============+=========+
|Registry|Metric Name |Description |Reference|
| ID | | | |
+========+==============================================+=============+=========+
| TBD_1 |Norm_Passive_CATS-Level |Single |Section |
| |2_RFCXXXXsecY_Unitless_Singleton |normalized |6.1 |
| | |score | |
| | |aggregating | |
| | |Level 0 and/ | |
| | |or Level 1 | |
| | |metrics | |
+--------+----------------------------------------------+-------------+---------+
| TBD_2 |Comb_Passive_CATS-Level |Normalized |Section |
| |1_Computing_RFCXXXXsecY_Unitless_Singleton |score for the|6.2 |
| | |computing | |
| | |category | |
+--------+----------------------------------------------+-------------+---------+
| TBD_3 |Comb_Passive_CATS-Level |Normalized |Section |
| |1_Communication_RFCXXXXsecY_Unitless_Singleton|score for the|6.3 |
| | |communication| |
| | |category | |
+--------+----------------------------------------------+-------------+---------+
| TBD_4 |Comb_Passive_CATS-Level |Normalized |Section |
| |1_Service_RFCXXXXsecY_Unitless_Singleton |score for the|6.4 |
| | |service | |
| | |category | |
+--------+----------------------------------------------+-------------+---------+
| TBD_5 |Comb_Passive_CATS-Level |Normalized |Section |
| |1_Composed_RFCXXXXsecY_Unitless_Singleton |score for the|6.5 |
| | |composed | |
| | |category | |
+--------+----------------------------------------------+-------------+---------+
Table 2: Initial Contents of the CATS Metrics Registry
For each entry, IANA is requested to assign a unique Identifier
(defined in each subsection) from the registry's assignment pool.
All metric entries have the following common attributes: Change
Controller (IETF), and Version. The naming convention and structure
follow the definitions in each respective subsection of Section 6.
10. References
10.1. Normative References
Kehan, et al. Expires 3 April 2027 [Page 47]
Internet-Draft CATS Metrics September 2026
[I-D.ietf-cats-framework]
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, 2 April 2026,
<https://datatracker.ietf.org/doc/html/draft-ietf-cats-
framework-24>.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/rfc/rfc2119>.
[RFC3339] Klyne, G. and C. Newman, "Date and Time on the Internet:
Timestamps", RFC 3339, DOI 10.17487/RFC3339, July 2002,
<https://www.rfc-editor.org/rfc/rfc3339>.
[RFC5835] Morton, A., Ed. and S. Van den Berghe, Ed., "Framework for
Metric Composition", RFC 5835, DOI 10.17487/RFC5835, April
2010, <https://www.rfc-editor.org/rfc/rfc5835>.
[RFC6241] Enns, R., Ed., Bjorklund, M., Ed., Schoenwaelder, J., Ed.,
and A. Bierman, Ed., "Network Configuration Protocol
(NETCONF)", RFC 6241, DOI 10.17487/RFC6241, June 2011,
<https://www.rfc-editor.org/rfc/rfc6241>.
[RFC7011] Claise, B., Ed., Trammell, B., Ed., and P. Aitken,
"Specification of the IP Flow Information Export (IPFIX)
Protocol for the Exchange of Flow Information", STD 77,
RFC 7011, DOI 10.17487/RFC7011, September 2013,
<https://www.rfc-editor.org/rfc/rfc7011>.
[RFC7471] Giacalone, S., Ward, D., Drake, J., Atlas, A., and S.
Previdi, "OSPF Traffic Engineering (TE) Metric
Extensions", RFC 7471, DOI 10.17487/RFC7471, March 2015,
<https://www.rfc-editor.org/rfc/rfc7471>.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
May 2017, <https://www.rfc-editor.org/rfc/rfc8174>.
[RFC8911] Bagnulo, M., Claise, B., Eardley, P., Morton, A., and A.
Akhter, "Registry for Performance Metrics", RFC 8911,
DOI 10.17487/RFC8911, November 2021,
<https://www.rfc-editor.org/rfc/rfc8911>.
Kehan, et al. Expires 3 April 2027 [Page 48]
Internet-Draft CATS Metrics September 2026
[RFC8912] Morton, A., Bagnulo, M., Eardley, P., and K. D'Souza,
"Initial Performance Metrics Registry Entries", RFC 8912,
DOI 10.17487/RFC8912, November 2021,
<https://www.rfc-editor.org/rfc/rfc8912>.
[RFC9439] Wu, Q., Yang, Y., Lee, Y., Dhody, D., Randriamasy, S., and
L. Contreras, "Application-Layer Traffic Optimization
(ALTO) Performance Cost Metrics", RFC 9439,
DOI 10.17487/RFC9439, August 2023,
<https://www.rfc-editor.org/rfc/rfc9439>.
[RFC9911] Schönwälder, J., Ed., "Common YANG Data Types", RFC 9911,
DOI 10.17487/RFC9911, December 2025,
<https://www.rfc-editor.org/rfc/rfc9911>.
10.2. Informative References
[DMTF] "DMTF", 1998, <https://www.dmtf.org/>.
[I-D.ietf-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-ietf-cats-data-
model-00, 23 September 2026,
<https://datatracker.ietf.org/doc/html/draft-ietf-cats-
data-model-00>.
[I-D.ietf-cats-usecases-requirements]
Yao, K., Contreras, L. M., Shi, H., Zhang, S., and Q. An,
"Computing-Aware Traffic Steering (CATS) Problem
Statement, Use Cases, and Requirements", Work in Progress,
Internet-Draft, draft-ietf-cats-usecases-requirements-14,
2 February 2026, <https://datatracker.ietf.org/doc/html/
draft-ietf-cats-usecases-requirements-14>.
[Min-max-sigmoid]
"Data Mining: Concepts and Techniques (Fourth Edition)",
2023, <https://doi.org/10.1016/C2013-0-18660-6>.
[performance-metrics]
"performance-metrics", 19 March 2020,
<https://www.iana.org/assignments/performance-metrics/
performance-metrics.xhtml>.
[Prometheus]
"Prometheus", 2012, <https://prometheus.io/>.
Kehan, et al. Expires 3 April 2027 [Page 49]
Internet-Draft CATS Metrics September 2026
Appendix A. Level 0 Metric Examples
Several definitions have been developed within the compute and
communication industries, as well as through various standardization
efforts---such as those by the [DMTF]---that can serve as Level 0
metrics. This section provides illustrative examples.
A.1. Compute Raw Metrics
This section uses CPU frequency as an example to illustrate the
representation of raw computing metrics. The metric type is labeled
as compute_CPU_frequency, with the unit specified in GHz. The format
supports floating-point values. The corresponding metric fields are
defined as follows:
Fields:
Metric_Type: compute_CPU_frequency
Level: Level 0
Format: floating point
Length: four octets
Unit: GHz
Source: nominal
Value: 2.2
Figure 9: An Example for Compute Raw Metrics
A.2. Communication Raw Metrics
This section takes the total transmitted bytes (TxBytes) as an
example to show the representation of communication raw metrics.
TxBytes are named as "communication type_TxBytes". The unit is Mega
Bytes (MB). Format is unsigned integer. It will occupy 4 octets.
The source of the metric is "Directly measured" and the statistics is
"mean". Example:
Fields:
Metric_Type: "communication type_TXBytes"
Level: Level 0
Format: unsigned integer
Length: four octets
Unit: MB
Source: Directly measured
Statistics: mean
Value: 100
Figure 10: An Example for Communication Raw Metrics
Kehan, et al. Expires 3 April 2027 [Page 50]
Internet-Draft CATS Metrics September 2026
A.3. Delay Raw Metrics
Delay is a kind of synthesized metric which is influenced by
computing, storage access, and network transmission. Usually delay
refers to the overal processing duration between the arrival time of
a specific service request and the departure time of the
corresponding service response. It is named as "delay_raw". The
format supports floating point. Its unit is microseconds, and it
occupies 4 octets. For example:
Fields:
Metric_Type: "delay_raw"
Level: Level 0
Format: floating point
Length: four octets
Unit: microsecond
Source: aggregation
Statistics: max
Value: 231.5
Figure 11: An Example for Delay Raw Metrics
Appendix B. Acknowledgements
Authors would like to give special thanks to Adrian Farrel for
detailed review as working group chair.
Special thanks to Jacqueline McCall for Secdir early review, to Fung
Lim for Opsdir early review.
Contributors
Mohamed Boucadair
Orange
Email: mohamed.boucadair@orange.com
Zongpeng Du
China Mobile
Email: duzongpeng@chinamobile.com
Hang Shi
Huawei
Email: shihang9@huawei.com
Kehan, et al. Expires 3 April 2027 [Page 51]
Internet-Draft CATS Metrics September 2026
Saumya Dikshit
Aruba Networks, Hewlett Packard Enterprise
Email: saumya.dikshit@hpe.com
Mengfei Zhu
China Mobile
Email: zhumengfei@cmdi.chinamobile.com
Authors' Addresses
Kehan Yao
China Mobile
China
Email: yaokehan@chinamobile.com
Cheng Li
Huawei Technologies
China
Email: c.l@huawei.com
L. M. Contreras
Telefonica
Email: luismiguel.contrerasmurillo@telefonica.com
Jordi Ros-Giralt
Qualcomm Europe, Inc.
Email: jros@qti.qualcomm.com
Guanming Zeng
Huawei Technologies
China
Email: zengguanming@huawei.com
Kehan, et al. Expires 3 April 2027 [Page 52]