CATS Metrics Definition

CATS Metrics Definition China Mobile

China yaokehan@chinamobile.com

Huawei Technologies

China c.l@huawei.com

Telefonica

luismiguel.contrerasmurillo@telefonica.com

Qualcomm Europe, Inc.

jros@qti.qualcomm.com

Huawei Technologies

China zengguanming@huawei.com

Routing Computing-Aware Traffic Steering CATS, metrics 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.

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

Conventions and Definitions This document uses the following terms defined in :

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)

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 when, and only when, they appear in all capitals, as shown here.

Design Principles

Three-Level Metrics As outlined in , 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.
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.

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. 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, and define various network performance metrics and their associated registries, while 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.

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 and for the definitions and examples of aggregation functions and normalization functions, respectively. Refer to 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.

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. further describes default policies for implementations. Figure 1 provides a summary of the logical relationships between metrics across the three levels of abstraction.

Logic of CATS Metrics in levels

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

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 . 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.
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 , "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.
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 . 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 .

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.

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

Aggregation function | | +-----------+ | Aggregation | +------------+ ... | Function |---->| Metric n+1 | +-----------+ | | +------------+ | Metric n |---->| | +-----------+ +-------------------+ Input: Multiple values Output: A single value ]]>

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 :

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.

Normalization function | Normalization Function |---->| Metric 2 | +----------+ +------------------------+ +----------+ Input: Value with or without units Output: Unitless value ]]>

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.

Level 0 Metrics Level 0 metrics are raw metrics that are not standardized in this document. See for examples of Level 0 metrics defined in the compute and communication industries and by other standardization organizations such as the .

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.

Level 1 Computing Metrics The Metric Type for Level 1 computing metrics is level1_computing. Example A: Aggregation-derived (with units) Example B: Normalized (unitless)

Examples of Level 1 computing metrics

Level 1 Communication Metrics The Metric Type for Level 1 communication metrics is level1_communication. Example A: Aggregation-derived (with units) Example B: Normalized (unitless)

Examples of Level 1 communication metrics

Level 1 Service Metrics The Metric Type for Level 1 service metrics is level1_service. Example A: Aggregation-derived (with units) Example B: Normalized (unitless)

Examples of Level 1 service metrics

Level 1 Composed Metrics The Metric Type for Level 1 composed metrics is level1_composed. Example A: Aggregation-derived (with units) Example B: Normalized (unitless)

Examples of Level 1 composed metrics

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.

Example of a normalized Level 2 metric

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. Comparison among Metrics Levels

Level	Encoding Complexity	Extensibility	Stability	Accuracy
Level 0	High	Low	Low	High
Level 1	Medium	Medium	Medium	Medium
Level 2	Low	High	High	Low

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

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

CATS Level 2 Metric Registry Entry This section gives an initial Registry Entry for the CATS Level 2 metric.

Summary This category includes multiple indexes to the Registry Entry: the element ID, Metric Name, URI, Metric Description, Metric Controller, and Metric Version.

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.

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)
Unitless: Metric has no units
Singleton: Metric is a single value

URI To-be-assigned.

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.

Change Controller IETF

Version 1.0

Metric Definition

Reference Definition Referenced sections of this document: on Level 2 metric definition and on aggregation and normalization functions.

Fixed Parameters

Normalization score range: 0-10 (0 indicates the poorest capability, 10 indicates the optimal capability)
Data precision: non-negative integer

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.

Reference Methods Raw Metrics collection: Collect Level 0 service and compute raw metrics using platform-specific management protocols or tools (e.g., Prometheus in Kubernetes). Collect Level 0 network performance raw metrics using existing standardized protocols (e.g., NETCONF , IPFIX ). Aggregation logic: Refer to . Normalization logic: Refer to . 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.

Packet Stream Generation N/A

Traffic Filtering (Observation) Details N/A

Sampling Distribution Sampling method: Continuous sampling (e.g., collect Level 0 metrics every 10 seconds)

Runtime Parameters and Data Format CATS Service Contact Instance ID (CSCI-ID): an identifier of CATS service contact instance. According to , a unicast IP address can be an example of identifier. (format: ipv4-address-no-zone or ipv6-address-no-zone, complying with ) Service_Instance_IP: Service instance IP address (format: ipv4-address-no-zone or ipv6-address-no-zone, complying with ) Measurement_Window: Metric measurement time window (Units: seconds, milliseconds; Format: uint64; Default: 10 seconds)

Roles C-SMA: Collects Level 0 service and compute raw metrics, and optionally calculates Level 1 metrics according to service-specific strategies. 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.

Output This category specifies all details of the output of measurements using the metric.

Type Singleton value

Reference Definition Output format: Refer to 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)

Metric Units Unitless

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

Administrative Items

Status Current

Requester To-be-assgined

Revision 1.0

Revision Date 2026-01-20

Comments and Remarks None

CATS Level 1 Metric Registry Entry: Computing This section gives an initial Registry Entry for the CATS Level 1 metric in the computing category.

Summary This category includes multiple indexes to the Registry Entry: the element ID, Metric Name, URI, Metric Description, Metric Controller, and Metric Version.

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.

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

URI To-be-assigned.

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.

Change Controller IETF

Version 1.0

Metric Definition

Reference Definition Referenced sections of this document: on Level 1 computing metric definition and on aggregation and normalization functions.

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

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.

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 in Kubernetes or equivalent telemetry systems). Aggregation logic (within computing category): Refer to 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 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").

Packet Stream Generation N/A

Traffic Filtering (Observation) Details N/A

Sampling Distribution Sampling method: Continuous sampling (e.g., collect underlying Level 0 computing metrics every 10 seconds)

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.

Output This category specifies all details of the output of measurements using the metric.

Type Singleton value

Reference Definition Output format: Refer to 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)

Metric Units Unitless

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

Administrative Items

Status Current

Requester To-be-assgined

Revision 1.0

Revision Date 2026-01-20

Comments and Remarks None

CATS Level 1 Metric Registry Entry: Communication This section gives an initial Registry Entry for the CATS Level 1 metric in the communication category.

Summary This category includes multiple indexes to the Registry Entry: the element ID, Metric Name, URI, Metric Description, Metric Controller, and Metric Version.

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.

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

URI To-be-assigned.

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.

Change Controller IETF

Version 1.0

Metric Definition

Reference Definition Referenced sections of this document: on Level 1 communication metric definition and on aggregation and normalization functions.

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

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.

Reference Methods Raw Metrics collection: Collect communication-related Level 0 raw metrics using existing standardized protocols and telemetry systems (e.g., NETCONF , IPFIX ), and/or using network performance metric definitions and registries such as , , and where applicable. Aggregation logic (within communication category): Refer to (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 (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).

Packet Stream Generation N/A

Traffic Filtering (Observation) Details N/A

Sampling Distribution Sampling method: Continuous sampling (e.g., collect underlying Level 0 communication metrics every 10 seconds)

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.

Output This category specifies all details of the output of measurements using the metric.

Type Singleton value

Reference Definition Output format: Refer to 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)

Metric Units Unitless

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

Administrative Items

Status Current

Requester To-be-assgined

Revision 1.0

Revision Date 2026-01-20

Comments and Remarks None

CATS Level 1 Metric Registry Entry: Service This section gives an initial Registry Entry for the CATS Level 1 metric in the service category.

Summary This category includes multiple indexes to the Registry Entry: the element ID, Metric Name, URI, Metric Description, Metric Controller, and Metric Version.

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.

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

URI To-be-assigned.

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.

Change Controller IETF

Version 1.0

Metric Definition

Reference Definition Referenced sections of this document: on Level 1 service metric definition and on aggregation and normalization functions.

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

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.

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 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. Aggregation logic (within service category): Refer to (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 (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).

Packet Stream Generation N/A

Traffic Filtering (Observation) Details N/A

Sampling Distribution Sampling method: Continuous sampling (e.g., collect underlying Level 0 service metrics every 10 seconds)

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. C-NMA: Not required for this metric.

Output This category specifies all details of the output of measurements using the metric.

Type Singleton value

Reference Definition Output format: Refer to 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)

Metric Units Unitless

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.

Administrative Items

Status Current

Requester To-be-assigned

Revision 1.0

Revision Date 2026-01-20

Comments and Remarks None

CATS Level 1 Metric Registry Entry: Composed This section gives an initial Registry Entry for the CATS Level 1 metric in the composed category.

Summary This category includes multiple indexes to the Registry Entry: the element ID, Metric Name, URI, Metric Description, Metric Controller, and Metric Version.

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.

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

URI To-be-assigned.

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.

Change Controller IETF

Version 1.0

Metric Definition

Reference Definition Referenced sections of this document: on Level 1 composed metric definition and on aggregation and normalization functions.

Fixed Parameters

Normalization score range: 0-10 (0 indicates the poorest composed capability, 10 indicates the optimal composed capability)
Data precision: non-negative integer
Metric type: "level1_composed"
Level: Level 1
Metric units: Unitless

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.

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 ), while communication-related Level 0 metrics may be collected by a C-NMA using network telemetry and protocols (e.g., NETCONF , IPFIX ), and/or using network performance metric definitions and registries such as , , and where applicable. Aggregation logic (within composed category): Refer to (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 (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").

Packet Stream Generation N/A

Traffic Filtering (Observation) Details N/A

Sampling Distribution Sampling method: Continuous sampling (e.g., collect underlying contributing metrics every 10 seconds)

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.

Output This category specifies all details of the output of measurements using the metric.

Type Singleton value

Reference Definition Output format: Refer to 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)

Metric Units Unitless

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.

Administrative Items

Status Current

Requester To-be-assigned

Revision 1.0

Revision Date 2026-01-20

Comments and Remarks None

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.

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

Metric Level Selection and Update Frequency Trade-offs As discussed in , 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. ** 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.

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 or ALTO cost metrics , 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. ** Operators should establish monitoring and alarm mechanisms for the following conditions:

Metric freshness failures: timeouts or invalid signatures as defined in SEC-4 from 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.

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.

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 . To help operators understand the management objects, this document distinguishes the following three categories:

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.

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

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 as follows: Initial Contents of the CATS Metrics Registry

Registry ID	Metric Name	Description
TBD_1	Norm_Passive_CATS-Level 2_RFCXXXXsecY_Unitless_Singleton	Single normalized score aggregating Level 0 and/or Level 1 metrics
TBD_2	Comb_Passive_CATS-Level 1_Computing_RFCXXXXsecY_Unitless_Singleton	Normalized score for the computing category
TBD_3	Comb_Passive_CATS-Level 1_Communication_RFCXXXXsecY_Unitless_Singleton	Normalized score for the communication category
TBD_4	Comb_Passive_CATS-Level 1_Service_RFCXXXXsecY_Unitless_Singleton	Normalized score for the service category
TBD_5	Comb_Passive_CATS-Level 1_Composed_RFCXXXXsecY_Unitless_Singleton	Normalized score for the composed category

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 .

References Normative References Key words for use in RFCs to Indicate Requirement Levels In many standards track documents several words are used to signify the requirements in the specification. These words are often capitalized. This document defines these words as they should be interpreted in IETF documents. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements. Date and Time on the Internet: Timestamps This document defines a date and time format for use in Internet protocols that is a profile of the ISO 8601 standard for representation of dates and times using the Gregorian calendar. Framework for Metric Composition This memo describes a detailed framework for composing and aggregating metrics (both in time and in space) originally defined by the IP Performance Metrics (IPPM), RFC 2330, and developed by the IETF. This new framework memo describes the generic composition and aggregation mechanisms. The memo provides a basis for additional documents that implement the framework to define detailed compositions and aggregations of metrics that are useful in practice. This document is not an Internet Standards Track specification; it is published for informational purposes. Network Configuration Protocol (NETCONF) The Network Configuration Protocol (NETCONF) defined in this document provides mechanisms to install, manipulate, and delete the configuration of network devices. It uses an Extensible Markup Language (XML)-based data encoding for the configuration data as well as the protocol messages. The NETCONF protocol operations are realized as remote procedure calls (RPCs). This document obsoletes RFC 4741. [STANDARDS-TRACK] Specification of the IP Flow Information Export (IPFIX) Protocol for the Exchange of Flow Information This document specifies the IP Flow Information Export (IPFIX) protocol, which serves as a means for transmitting Traffic Flow information over the network. In order to transmit Traffic Flow information from an Exporting Process to a Collecting Process, a common representation of flow data and a standard means of communicating them are required. This document describes how the IPFIX Data and Template Records are carried over a number of transport protocols from an IPFIX Exporting Process to an IPFIX Collecting Process. This document obsoletes RFC 5101. OSPF Traffic Engineering (TE) Metric Extensions In certain networks, such as, but not limited to, financial information networks (e.g., stock market data providers), network performance information (e.g., link propagation delay) is becoming critical to data path selection. This document describes common extensions to RFC 3630 "Traffic Engineering (TE) Extensions to OSPF Version 2" and RFC 5329 "Traffic Engineering Extensions to OSPF Version 3" to enable network performance information to be distributed in a scalable fashion. The information distributed using OSPF TE Metric Extensions can then be used to make path selection decisions based on network performance. Note that this document only covers the mechanisms by which network performance information is distributed. The mechanisms for measuring network performance information or using that information, once distributed, are outside the scope of this document. Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words RFC 2119 specifies common key words that may be used in protocol specifications. This document aims to reduce the ambiguity by clarifying that only UPPERCASE usage of the key words have the defined special meanings. Registry for Performance Metrics This document defines the format for the IANA Registry of Performance Metrics. This document also gives a set of guidelines for Registered Performance Metric requesters and reviewers. Initial Performance Metrics Registry Entries This memo defines the set of initial entries for the IANA Registry of Performance Metrics. The set includes UDP Round-Trip Latency and Loss, Packet Delay Variation, DNS Response Latency and Loss, UDP Poisson One-Way Delay and Loss, UDP Periodic One-Way Delay and Loss, ICMP Round-Trip Latency and Loss, and TCP Round-Trip Delay and Loss. Application-Layer Traffic Optimization (ALTO) Performance Cost Metrics The cost metric is a basic concept in Application-Layer Traffic Optimization (ALTO), and different applications may use different types of cost metrics. Since the ALTO base protocol (RFC 7285) defines only a single cost metric (namely, the generic "routingcost" metric), if an application wants to issue a cost map or an endpoint cost request in order to identify a resource provider that offers better performance metrics (e.g., lower delay or loss rate), the base protocol does not define the cost metric to be used. This document addresses this issue by extending the specification to provide a variety of network performance metrics, including network delay, delay variation (a.k.a. jitter), packet loss rate, hop count, and bandwidth. There are multiple sources (e.g., estimations based on measurements or a Service Level Agreement) available for deriving a performance metric. This document introduces an additional "cost-context" field to the ALTO "cost-type" field to convey the source of a performance metric. Common YANG Data Types This document defines a collection of common data types to be used with the YANG data modeling language. It includes several new type definitions and obsoletes RFC 6991. A Framework for Computing-Aware Traffic Steering (CATS) Huawei Technologies China Mobile Orange Telefonica Independent This document describes a framework for Computing-Aware Traffic Steering (CATS). Specifically, the document identifies a set of CATS functional components, describes their interactions, and provides illustrative workflows of the control and data planes. The framework covers only the case of a single service provider. Informative References Computing-Aware Traffic Steering (CATS) Problem Statement, Use Cases, and Requirements China Mobile Telefonica Huawei Technologies China Unicom Alibaba Group Distributed computing enhances service response time and energy efficiency by utilizing diverse computing facilities for compute- intensive and delay-sensitive services. To optimize throughput and response time, "Computing-Aware Traffic Steering" (CATS) selects servers and directs traffic based on compute capabilities and resources, rather than static dispatch or connectivity metrics alone. This document outlines the problem statement and scenarios for CATS within a single domain, and drives requirements for the CATS framework. Data Model for Computing-Aware Traffic Steering (CATS) China Mobile New H3C Technologies China Mobile ZTE Corporation Telefonica This document defines a YANG data model for the management of Computing-Aware Traffic Steering (CATS) systems. performance-metrics DMTF Prometheus Data Mining: Concepts and Techniques (Fourth Edition)

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 ---that can serve as Level 0 metrics. This section provides illustrative examples.

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:

An Example for Compute Raw Metrics

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:

An Example for Communication Raw Metrics

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:

An Example for Delay Raw Metrics

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 Orange

mohamed.boucadair@orange.com

China Mobile

duzongpeng@chinamobile.com

Huawei

shihang9@huawei.com

Aruba Networks, Hewlett Packard Enterprise

saumya.dikshit@hpe.com

China Mobile

zhumengfei@cmdi.chinamobile.com