Computing-Aware Traffic Steering Y. Kehan Internet-Draft China Mobile Intended status: Standards Track C. Li Expires: 23 April 2027 Huawei Technologies L. M. Contreras Telefonica J. Ros-Giralt Qualcomm Europe, Inc. G. Zeng Huawei Technologies 20 October 2026 CATS Metrics Definition draft-ietf-cats-metric-definition-14 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 23 April 2027. Kehan, et al. Expires 23 April 2027 [Page 1] Internet-Draft CATS Metrics October 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 . . . . . . . . . . . . . . . . . . . . . . . . 4 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 . . . . . . . . . 12 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 . . . . . . . . . . . . . . . 18 6. CATS Metric Registry Entries . . . . . . . . . . . . . . . . 19 6.1. CATS Level 2 Metric Registry Entry . . . . . . . . . . . 20 6.1.1. Summary . . . . . . . . . . . . . . . . . . . . . . . 20 6.1.2. Metric Definition . . . . . . . . . . . . . . . . . . 21 6.1.3. Method of Measurement . . . . . . . . . . . . . . . . 22 6.1.4. Output . . . . . . . . . . . . . . . . . . . . . . . 23 6.1.5. Administrative Items . . . . . . . . . . . . . . . . 24 6.2. CATS Level 1 Metric Registry Entry: Computing . . . . . . 24 6.2.1. Summary . . . . . . . . . . . . . . . . . . . . . . . 24 6.2.2. Metric Definition . . . . . . . . . . . . . . . . . . 26 6.2.3. Method of Measurement . . . . . . . . . . . . . . . . 26 6.2.4. Output . . . . . . . . . . . . . . . . . . . . . . . 28 6.2.5. Administrative Items . . . . . . . . . . . . . . . . 29 6.3. CATS Level 1 Metric Registry Entry: Communication . . . . 29 6.3.1. Summary . . . . . . . . . . . . . . . . . . . . . . . 29 Kehan, et al. Expires 23 April 2027 [Page 2] Internet-Draft CATS Metrics October 2026 6.3.2. Metric Definition . . . . . . . . . . . . . . . . . . 31 6.3.3. Method of Measurement . . . . . . . . . . . . . . . . 31 6.3.4. Output . . . . . . . . . . . . . . . . . . . . . . . 33 6.3.5. Administrative Items . . . . . . . . . . . . . . . . 34 6.4. CATS Level 1 Metric Registry Entry: Service . . . . . . . 34 6.4.1. Summary . . . . . . . . . . . . . . . . . . . . . . . 34 6.4.2. Metric Definition . . . . . . . . . . . . . . . . . . 36 6.4.3. Method of Measurement . . . . . . . . . . . . . . . . 36 6.4.4. Output . . . . . . . . . . . . . . . . . . . . . . . 38 6.4.5. Administrative Items . . . . . . . . . . . . . . . . 39 6.5. CATS Level 1 Metric Registry Entry: Composed . . . . . . 39 6.5.1. Summary . . . . . . . . . . . . . . . . . . . . . . . 39 6.5.2. Metric Definition . . . . . . . . . . . . . . . . . . 41 6.5.3. Method of Measurement . . . . . . . . . . . . . . . . 41 6.5.4. Output . . . . . . . . . . . . . . . . . . . . . . . 43 6.5.5. Administrative Items . . . . . . . . . . . . . . . . 44 7. Operational Considerations . . . . . . . . . . . . . . . . . 44 7.1. Negotiation of Normalization and Aggregation Functions in Multi-Vendor Environments . . . . . . . . . . . . . . . . 44 7.2. Metric Level Selection and Update Frequency Trade-offs . 45 7.3. Metric Collection Failures, Fallback Behavior, and Fault Alarms . . . . . . . . . . . . . . . . . . . . . . . . . 46 7.4. Validation of Metric Values . . . . . . . . . . . . . . . 47 7.5. Management Interoperability . . . . . . . . . . . . . . . 48 8. Security Considerations . . . . . . . . . . . . . . . . . . . 48 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 49 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 51 10.1. Normative References . . . . . . . . . . . . . . . . . . 51 10.2. Informative References . . . . . . . . . . . . . . . . . 53 Appendix A. Level 0 Metric Examples . . . . . . . . . . . . . . 54 A.1. Compute Raw Metrics . . . . . . . . . . . . . . . . . . . 54 A.2. Communication Raw Metrics . . . . . . . . . . . . . . . . 54 A.3. Delay Raw Metrics . . . . . . . . . . . . . . . . . . . . 55 Appendix B. Examples on Implementations of Normalization and Aggregation Functions . . . . . . . . . . . . . . . . . . 55 B.1. Implementations of Normalization Functions . . . . . . . 56 B.2. Implementations of Aggregation Functions . . . . . . . . 56 B.2.1. Spatial Aggregation Using Arithmetic Mean . . . . . . 56 B.2.2. Temporal Aggregation Using Weighted Average . . . . . 57 B.2.3. Cross-Category Aggregation Using Weighted Sum . . . . 57 Appendix C. Acknowledgements . . . . . . . . . . . . . . . . . . 57 Contributors . . . . . . . . . . . . . . . . . . . . . . . . . . 57 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 58 Kehan, et al. Expires 23 April 2027 [Page 3] Internet-Draft CATS Metrics October 2026 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 [RFC10053]. 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 [RFC10053]: * Computing-Aware Traffic Steering (CATS) * Service * Service site * Service contact instance Kehan, et al. Expires 23 April 2027 [Page 4] Internet-Draft CATS Metrics October 2026 * 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 [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 [RFC10054], 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: Kehan, et al. Expires 23 April 2027 [Page 5] Internet-Draft CATS Metrics October 2026 * *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. 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. Network performance metrics and their measurement methods are classified in [RFC7799]. * *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 Kehan, et al. Expires 23 April 2027 [Page 6] Internet-Draft CATS Metrics October 2026 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, [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. Kehan, et al. Expires 23 April 2027 [Page 7] Internet-Draft CATS Metrics October 2026 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. 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: Kehan, et al. Expires 23 April 2027 [Page 8] Internet-Draft CATS Metrics October 2026 * *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 [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. Kehan, et al. Expires 23 April 2027 [Page 9] Internet-Draft CATS Metrics October 2026 * *Measurement_Method*: This optional field indicates the measurement method of the metric as classified in [RFC7799] ('active', 'passive', or 'hybrid'). Registry entries in Section 6 are separated by measurement method. When this field is present, its value must match the measurement method of the selected registry entry. For Level 1 and Level 2 metrics, the method is inherited from the contributing Level 0 metrics: a derived metric is 'passive' only if all inputs are passively collected, otherwise it is 'active' or 'hybrid'. * *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 [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. Kehan, et al. Expires 23 April 2027 [Page 10] Internet-Draft CATS Metrics October 2026 - '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 [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. Kehan, et al. Expires 23 April 2027 [Page 11] Internet-Draft CATS Metrics October 2026 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. 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 [RFC5644], 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. Kehan, et al. Expires 23 April 2027 [Page 12] Internet-Draft CATS Metrics October 2026 Aggregation functions are not standardized in this document. They are implementation-specific and controlled by operator policies. +-----------+ +-------------------+ | 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 Kehan, et al. Expires 23 April 2027 [Page 13] Internet-Draft CATS Metrics October 2026 Figure 3: Normalization function 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)* Kehan, et al. Expires 23 April 2027 [Page 14] Internet-Draft CATS Metrics October 2026 Fields: Metric_type: level1_computing Level: Level 1 Measurement_Method: passive Format: unsigned integer Length: two octets Unit: mhz Source: aggregation Value: 2400 *Example B: Normalized (unitless)* Fields: Metric_type: level1_computing Level: Level 1 Measurement_Method: passive 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 Measurement_Method: active Format: unsigned integer Length: two octets Unit: mbps Source: aggregation Value: 800 *Example B: Normalized (unitless)* Kehan, et al. Expires 23 April 2027 [Page 15] Internet-Draft CATS Metrics October 2026 Fields: Metric_type: level1_communication Level: Level 1 Measurement_Method: hybrid 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)* Fields: Metric_type: level1_service Level: Level 1 Measurement_Method: passive Format: unsigned integer Length: two octets Unit: rps Source: aggregation Value: 45 *Example B: Normalized (unitless)* Fields: Metric_type: level1_service Level: Level 1 Measurement_Method: passive 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)* Kehan, et al. Expires 23 April 2027 [Page 16] Internet-Draft CATS Metrics October 2026 Fields: Metric_type: level1_composed Level: Level 1 Measurement_Method: hybrid Format: unsigned integer Length: two octets Unit: ms Source: aggregation Value: 20 *Example B: Normalized (unitless)* Fields: Metric_type: level1_composed Level: Level 1 Measurement_Method: passive Format: unsigned integer Length: one octet Source: normalization Value: 8 Figure 7: Examples of Level 1 composed metrics 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 Measurement_Method: hybrid Format: unsigned integer Length: one octet Source: normalization Value: 1 Figure 8: Example of a normalized Level 2 metric Kehan, et al. Expires 23 April 2027 [Page 17] Internet-Draft CATS Metrics October 2026 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. 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. Kehan, et al. Expires 23 April 2027 [Page 18] Internet-Draft CATS Metrics October 2026 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. 6. CATS Metric Registry Entries This section defines the formal registry entries for CATS Level 1 and Level 2 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. Kehan, et al. Expires 23 April 2027 [Page 19] Internet-Draft CATS Metrics October 2026 Registry entries are separated by measurement method as classified in [RFC7799]. The Level 1 communication metric supports 'active', 'passive', and 'hybrid' measurement, and therefore three entries are registered for it. The Level 1 computing, service, and composed metrics, as well as the Level 2 metric, support 'passive' and 'hybrid' measurement, and therefore two entries are registered for each of them. Pure active measurement is not defined for these categories because their values cannot be inferred solely from probe traffic. The detailed measurement procedures for each method are described in the method of measurement subsections of the corresponding registry entries, Section 6.1.3, Section 6.2.3, Section 6.3.3, Section 6.4.3, and Section 6.5.3. 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 and TBD_2 for the Named Metric Entries in this section. See the next Section for mapping to Names. 6.1.1.2. Name Norm_Passive_CATS-Level 2_RFCXXXXsecY_Unitless_Singleton and Norm_Hybrid_CATS-Level 2_RFCXXXXsecY_Unitless_Singleton Naming Rule Explanation * Norm: Metric type (Normalized Score) * Passive or Hybrid: Measurement method Kehan, et al. Expires 23 April 2027 [Page 20] Internet-Draft CATS Metrics October 2026 * 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 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 Kehan, et al. Expires 23 April 2027 [Page 21] Internet-Draft CATS Metrics October 2026 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. 6.1.3.1. Reference Methods Passive measurement: 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]). Aggregate and normalize the collected Level 0 metrics to generate Level 1 category metrics, and further calculate the Level 2 singleton score. No active probe is used. Hybrid measurement: In addition to passive collection, a C-PS may initiate a probe using an extended network performance measurement protocol such as TWAMP [RFC5357] or STAMP [RFC8762] toward a C-SMA. The receiving agent acts as a reflector: it parses the probe, computes or attaches the relevant Level 1 category scores from locally collected Level 0 metrics, and returns them to the C-PS. The C-PS then aggregates and normalizes these scores to derive the Level 2 metric. 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 Passive measurement: N/A. Hybrid measurement: The C-PS generates probe packets using an extended TWAMP [RFC5357] or STAMP [RFC8762] mechanism. The C-SMA reflects the probe packets and returns the relevant Level 1 scores. 6.1.3.3. Traffic Filtering (Observation) Details N/A Kehan, et al. Expires 23 April 2027 [Page 22] Internet-Draft CATS Metrics October 2026 6.1.3.4. Sampling Distribution Passive measurement: continuous sampling (e.g., every 10 seconds). Hybrid measurement: on-demand, triggered by C-PS probes. 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 [RFC10053], 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. In hybrid measurement, it may act as a reflector and return the relevant Level 1 scores. 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. In hybrid measurement, it may initiate probes to obtain the relevant Level 1 scores. 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. Kehan, et al. Expires 23 April 2027 [Page 23] Internet-Draft CATS Metrics October 2026 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 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 initial Registry Entries 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. Kehan, et al. Expires 23 April 2027 [Page 24] Internet-Draft CATS Metrics October 2026 6.2.1.1. ID (Identifier) IANA has allocated the Identifier TBD_3 and TBD_4 for the Named Metric Entries in this section. See the next Section for mapping to Names. 6.2.1.2. Name TBD_3: Comb_Passive_CATS-Level 1_Computing_RFCXXXXsecY_Unitless_Singleton TBD_4: Comb_Hybrid_CATS-Level 1_Computing_RFCXXXXsecY_Unitless_Singleton Naming Rule Explanation * Comb: Metric type (Combined Score) * Passive or Hybrid: 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 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. Kehan, et al. Expires 23 April 2027 [Page 25] Internet-Draft CATS Metrics October 2026 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 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). Kehan, et al. Expires 23 April 2027 [Page 26] Internet-Draft CATS Metrics October 2026 Passive measurement: C-SMA collects Level 0 computing metrics (e.g., CPU/GPU/NPU utilization, frequency, memory utilization) using platform telemetry such as Prometheus [Prometheus] in Kubernetes. The metrics are aggregated and normalized according to Section 4.2.1 and Section 4.2.2 to derive the Level 1 computing score. No active probe is used. Hybrid measurement: A C-PS initiates a probe using an extended network performance measurement protocol such as TWAMP [RFC5357] or STAMP [RFC8762] toward a C-SMA. The C-SMA acts as a reflector: it parses the probe, collects the required Level 0 computing metrics locally, computes the Level 1 computing score, and returns the score to the C-PS. 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 Passive measurement: N/A. Hybrid measurement: The C-PS generates probe packets using the extended TWAMP [RFC5357] or STAMP [RFC8762] mechanism. The C-SMA reflects the probe packets and returns the Level 1 computing score. 6.2.3.3. Traffic Filtering (Observation) Details N/A 6.2.3.4. Sampling Distribution Passive measurement: continuous sampling (e.g., every 10 seconds). Hybrid measurement: on-demand, triggered by C-PS probes. Kehan, et al. Expires 23 April 2027 [Page 27] Internet-Draft CATS Metrics October 2026 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 [RFC10053], 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.2.3.6. Roles C-SMA: In passive mode, collects Level 0 computing metrics and calculates the Level 1 computing score. In hybrid mode, acts as a reflector and returns the Level 1 computing score. C-PS: In passive mode, uses the Level 1 computing score for steering decisions. In hybrid mode, initiates probes to obtain the Level 1 computing score. 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 Kehan, et al. Expires 23 April 2027 [Page 28] Internet-Draft CATS Metrics October 2026 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 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_5, TBD_6, and TBD_7 for the Named Metric Entries in this section. See the next Section for mapping to Names. Kehan, et al. Expires 23 April 2027 [Page 29] Internet-Draft CATS Metrics October 2026 6.3.1.2. Name TBD_5: Comb_Active_CATS-Level 1_Communication_RFCXXXXsecY_Unitless_Singleton TBD_6: Comb_Passive_CATS-Level 1_Communication_RFCXXXXsecY_Unitless_Singleton TBD_7: Comb_Hybrid_CATS-Level 1_Communication_RFCXXXXsecY_Unitless_Singleton Naming Rule Explanation * Comb: Metric type (Combined Score) * Active, Passive, or Hybrid: 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 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. Kehan, et al. Expires 23 April 2027 [Page 30] Internet-Draft CATS Metrics October 2026 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. 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 Passive measurement: C-NMA collects Level 0 communication metrics using existing standardized protocols and telemetry systems (e.g., NETCONF [RFC6241], IPFIX [RFC7011]). The metrics are aggregated and normalized according to Section 4.2.1 and Section 4.2.2 to derive the Level 1 communication score. No active probe is used. Kehan, et al. Expires 23 April 2027 [Page 31] Internet-Draft CATS Metrics October 2026 Active measurement: A C-PS or C-NMA initiates active probes using TWAMP [RFC5357] or STAMP [RFC8762] toward a C-NMA. The C-NMA acts as a measurement endpoint or reflector and returns the measured communication metrics. The Level 1 communication score is derived according to Section 4.2.1 and Section 4.2.2. Hybrid measurement: C-PS or C-NMA initiates probes using TWAMP [RFC5357] or STAMP [RFC8762], and the active measurement results are combined with passively collected Level 0 communication metrics. The combined metrics are aggregated and normalized to derive the Level 1 communication score. 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 Passive measurement: N/A. Active and hybrid measurement: The C-PS or C-NMA generates probe packets using TWAMP [RFC5357] or STAMP [RFC8762]. The C-NMA acts as the measurement endpoint or reflector for the active portion. 6.3.3.3. Traffic Filtering (Observation) Details N/A 6.3.3.4. Sampling Distribution Passive measurement: continuous sampling (e.g., every 10 seconds). Active and hybrid measurement: on-demand or periodic active probing, as configured by operator policy. Kehan, et al. Expires 23 April 2027 [Page 32] Internet-Draft CATS Metrics October 2026 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 [RFC10053], 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: In passive mode, collects Level 0 communication metrics and calculates the Level 1 communication score. In active and hybrid modes, acts as a measurement endpoint or reflector and returns the Level 1 communication score. C-PS: In passive mode, uses the Level 1 communication score for steering decisions. In active and hybrid modes, initiates probes to obtain the Level 1 communication score. 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) 6.3.4.3. Metric Units Unitless Kehan, et al. Expires 23 April 2027 [Page 33] Internet-Draft CATS Metrics October 2026 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 initial Registry Entries 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. 6.4.1.1. ID (Identifier) IANA has allocated the Identifier TBD_8 and TBD_9 for the Named Metric Entry in this section. See the next Section for mapping to Names. Kehan, et al. Expires 23 April 2027 [Page 34] Internet-Draft CATS Metrics October 2026 6.4.1.2. Name TBD_8: Comb_Passive_CATS-Level 1_Service_RFCXXXXsecY_Unitless_Singleton TBD_9: Comb_Hybrid_CATS-Level 1_Service_RFCXXXXsecY_Unitless_Singleton Naming Rule Explanation * Comb: Metric type (Combined Score) * Passive or Hybrid: 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 23 April 2027 [Page 35] Internet-Draft CATS Metrics October 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 Passive measurement: C-SMA collects Level 0 service metrics (e.g., availability, requests per second, tokens per second) using platform telemetry. The metrics are aggregated and normalized according to Section 4.2.1 and Section 4.2.2 to derive the Level 1 service score. No active probe is used. Hybrid measurement: A C-PS initiates a probe using TWAMP [RFC5357] or STAMP [RFC8762] toward a C-SMA. The C-SMA acts as a reflector: it parses the probe, collects the required Level 0 service metrics locally, computes the Level 1 service score, and returns the score to the C-PS. Kehan, et al. Expires 23 April 2027 [Page 36] Internet-Draft CATS Metrics October 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 Passive measurement: N/A. Hybrid measurement: The C-PS generates probe packets using TWAMP [RFC5357] or STAMP [RFC8762]. The C-SMA reflects the probe packets and returns the Level 1 service score. 6.4.3.3. Traffic Filtering (Observation) Details N/A 6.4.3.4. Sampling Distribution Passive measurement: continuous sampling (e.g., every 10 seconds). Hybrid measurement: on-demand, triggered by C-PS probes. 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 [RFC10053], 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) Kehan, et al. Expires 23 April 2027 [Page 37] Internet-Draft CATS Metrics October 2026 6.4.3.6. Roles C-SMA: In passive mode, collects Level 0 service metrics and calculates the Level 1 service score. In hybrid mode, acts as a reflector and returns the Level 1 service score. C-PS: In passive mode, uses the Level 1 service score for steering decisions. In hybrid mode, initiates probes to obtain the Level 1 service score. 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. Kehan, et al. Expires 23 April 2027 [Page 38] Internet-Draft CATS Metrics October 2026 6.4.5. Administrative Items 6.4.5.1. Status Current 6.4.5.2. Requester To-be-assigned 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 initial Registry Entries 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_10 and TBD_11 for the Named Metric Entries in this section. See the next Section for mapping to Names. 6.5.1.2. Name TBD_10: Comb_Passive_CATS-Level 1_Composed_RFCXXXXsecY_Unitless_Singleton TBD_11: Comb_Hybrid_CATS-Level 1_Composed_RFCXXXXsecY_Unitless_Singleton Naming Rule Explanation Kehan, et al. Expires 23 April 2027 [Page 39] Internet-Draft CATS Metrics October 2026 * Comb: Metric type (Combined Score) * Passive or Hybrid: 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 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 Kehan, et al. Expires 23 April 2027 [Page 40] Internet-Draft CATS Metrics October 2026 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 * 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 Passive measurement: C-PS aggregates passively collected Level 0 and/ or Level 1 metrics and applies normalization according to Section 4.2.1 and Section 4.2.2 to derive the Level 1 composed score. No active probe is used. Hybrid measurement: A C-PS initiates a probe using TWAMP [RFC5357] or STAMP [RFC8762] toward a C-SMA and/or C-NMA. The receiving agent acts as a reflector and returns the relevant contributing Level 1 scores. The C-PS aggregates and normalizes these scores according to Section 4.2.1 and Section 4.2.2 to derive the Level 1 composed score. Kehan, et al. Expires 23 April 2027 [Page 41] Internet-Draft CATS Metrics October 2026 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 Passive measurement: N/A. Hybrid measurement: The C-PS generates probe packets using TWAMP [RFC5357] or STAMP [RFC8762]. The C-SMA/C-NMA reflects the probe packets and returns the contributing Level 1 scores. 6.5.3.3. Traffic Filtering (Observation) Details N/A 6.5.3.4. Sampling Distribution Passive measurement: continuous sampling (e.g., every 10 seconds). Hybrid measurement: on-demand, triggered by C-PS probes. 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 [RFC10053], 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) Kehan, et al. Expires 23 April 2027 [Page 42] Internet-Draft CATS Metrics October 2026 6.5.3.6. Roles C-SMA/C-NMA: In passive mode, collect passively contributing metrics. In hybrid mode, act as a reflector for hybrid probes and return the relevant contributing Level 1 scores. C-PS: In passive mode, computes the Level 1 composed score from passively collected inputs. In hybrid mode, initiates probes and computes the Level 1 composed score from returned contributing scores. 6.5.4. Output This category specifies all details of the output of measurements using the metric. 6.5.4.1. Type Singleton value 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. Kehan, et al. Expires 23 April 2027 [Page 43] Internet-Draft CATS Metrics October 2026 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 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 [RFC10053]. 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. Kehan, et al. Expires 23 April 2027 [Page 44] Internet-Draft CATS Metrics October 2026 * 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. 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 Kehan, et al. Expires 23 April 2027 [Page 45] Internet-Draft CATS Metrics October 2026 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. 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. Kehan, et al. Expires 23 April 2027 [Page 46] Internet-Draft CATS Metrics October 2026 * 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. ** 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: Kehan, et al. Expires 23 April 2027 [Page 47] Internet-Draft CATS Metrics October 2026 * 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: * 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 Kehan, et al. Expires 23 April 2027 [Page 48] Internet-Draft CATS Metrics October 2026 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. 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. Kehan, et al. Expires 23 April 2027 [Page 49] Internet-Draft CATS Metrics October 2026 The initial entries for this registry are defined in Section 6 as follows: +========+==============================================+=============+=========+ |Registry|Metric Name |Description |Reference| | ID | | | | +========+==============================================+=============+=========+ | TBD_1 |Norm_Passive_CATS-Level |Passive |Section | | |2_RFCXXXXsecY_Unitless_Singleton |variant of |6.1 | | | |the Level 2 | | | | |normalized | | | | |score | | +--------+----------------------------------------------+-------------+---------+ | TBD_2 |Norm_Hybrid_CATS-Level |Hybrid |Section | | |2_RFCXXXXsecY_Unitless_Singleton |variant of |6.1 | | | |the Level 2 | | | | |normalized | | | | |score | | +--------+----------------------------------------------+-------------+---------+ | TBD_3 |Comb_Passive_CATS-Level |Passive |Section | | |1_Computing_RFCXXXXsecY_Unitless_Singleton |variant of |6.2 | | | |the Level 1 | | | | |computing | | | | |score | | +--------+----------------------------------------------+-------------+---------+ | TBD_4 |Comb_Hybrid_CATS-Level |Hybrid |Section | | |1_Computing_RFCXXXXsecY_Unitless_Singleton |variant of |6.2 | | | |the Level 1 | | | | |computing | | | | |score | | +--------+----------------------------------------------+-------------+---------+ | TBD_5 |Comb_Active_CATS-Level |Active |Section | | |1_Communication_RFCXXXXsecY_Unitless_Singleton|variant of |6.3 | | | |the Level 1 | | | | |communication| | | | |score | | +--------+----------------------------------------------+-------------+---------+ | TBD_6 |Comb_Passive_CATS-Level |Passive |Section | | |1_Communication_RFCXXXXsecY_Unitless_Singleton|variant of |6.3 | | | |the Level 1 | | | | |communication| | | | |score | | +--------+----------------------------------------------+-------------+---------+ | TBD_7 |Comb_Hybrid_CATS-Level |Hybrid |Section | | |1_Communication_RFCXXXXsecY_Unitless_Singleton|variant of |6.3 | | | |the Level 1 | | | | |communication| | | | |score | | Kehan, et al. Expires 23 April 2027 [Page 50] Internet-Draft CATS Metrics October 2026 +--------+----------------------------------------------+-------------+---------+ | TBD_8 |Comb_Passive_CATS-Level |Passive |Section | | |1_Service_RFCXXXXsecY_Unitless_Singleton |variant of |6.4 | | | |the Level 1 | | | | |service score| | +--------+----------------------------------------------+-------------+---------+ | TBD_9 |Comb_Hybrid_CATS-Level |Hybrid |Section | | |1_Service_RFCXXXXsecY_Unitless_Singleton |variant of |6.4 | | | |the Level 1 | | | | |service score| | +--------+----------------------------------------------+-------------+---------+ | TBD_10 |Comb_Passive_CATS-Level |Passive |Section | | |1_Composed_RFCXXXXsecY_Unitless_Singleton |variant of |6.5 | | | |the Level 1 | | | | |composed | | | | |score | | +--------+----------------------------------------------+-------------+---------+ | TBD_11 |Comb_Hybrid_CATS-Level |Hybrid |Section | | |1_Composed_RFCXXXXsecY_Unitless_Singleton |variant of |6.5 | | | |the Level 1 | | | | |composed | | | | |score | | +--------+----------------------------------------------+-------------+---------+ 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 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, . [RFC3339] Klyne, G. and C. Newman, "Date and Time on the Internet: Timestamps", RFC 3339, DOI 10.17487/RFC3339, July 2002, . Kehan, et al. Expires 23 April 2027 [Page 51] Internet-Draft CATS Metrics October 2026 [RFC5357] Hedayat, K., Krzanowski, R., Morton, A., Yum, K., and J. Babiarz, "A Two-Way Active Measurement Protocol (TWAMP)", RFC 5357, DOI 10.17487/RFC5357, October 2008, . [RFC5644] Stephan, E., Liang, L., and A. Morton, "IP Performance Metrics (IPPM): Spatial and Multicast", RFC 5644, DOI 10.17487/RFC5644, October 2009, . [RFC5835] Morton, A., Ed. and S. Van den Berghe, Ed., "Framework for Metric Composition", RFC 5835, DOI 10.17487/RFC5835, April 2010, . [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, . [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, . [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, . [RFC7799] Morton, A., "Active and Passive Metrics and Methods (with Hybrid Types In-Between)", RFC 7799, DOI 10.17487/RFC7799, May 2016, . [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, . [RFC8762] Mirsky, G., Jun, G., Nydell, H., and R. Foote, "Simple Two-Way Active Measurement Protocol", RFC 8762, DOI 10.17487/RFC8762, March 2020, . [RFC8911] Bagnulo, M., Claise, B., Eardley, P., Morton, A., and A. Akhter, "Registry for Performance Metrics", RFC 8911, DOI 10.17487/RFC8911, November 2021, . Kehan, et al. Expires 23 April 2027 [Page 52] Internet-Draft CATS Metrics October 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, . [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, . [RFC9911] Schönwälder, J., Ed., "Common YANG Data Types", RFC 9911, DOI 10.17487/RFC9911, December 2025, . [RFC10053] Li, C., Ed., Du, Z., Boucadair, M., Ed., Contreras, L. M., and J. Drake, "A Framework for Computing-Aware Traffic Steering (CATS)", RFC 10053, DOI 10.17487/RFC10053, October 2026, . 10.2. Informative References [DMTF] "DMTF", 1998, . [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, . [Min-max-sigmoid] "Data Mining: Concepts and Techniques (Fourth Edition)", 2023, . [performance-metrics] "performance-metrics", 19 March 2020, . [Prometheus] "Prometheus", 2012, . Kehan, et al. Expires 23 April 2027 [Page 53] Internet-Draft CATS Metrics October 2026 [RFC10054] Yao, K., Contreras, L. M., Shi, H., Zhang, S., and Q. An, "Computing-Aware Traffic Steering (CATS) Problem Statement, Use Cases, and Requirements", RFC 10054, DOI 10.17487/RFC10054, October 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 Measurement_Method: passive 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: Kehan, et al. Expires 23 April 2027 [Page 54] Internet-Draft CATS Metrics October 2026 Fields: Metric_Type: "communication type_TXBytes" Level: Level 0 Measurement_Method: active Format: unsigned integer Length: four octets Unit: MB Source: Directly measured Statistics: mean Value: 100 Figure 10: An Example for Communication Raw Metrics 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 Measurement_Method: hybrid 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. Examples on Implementations of Normalization and Aggregation Functions This section provides some examples on how to apply normalization functions and aggregation functions to derive Level 1 and Level 2 metric values in CATS system. Kehan, et al. Expires 23 April 2027 [Page 55] Internet-Draft CATS Metrics October 2026 B.1. Implementations of Normalization Functions This example shows how a C-PS derives a Level 2 metric from Level 1 scores using a sigmoid function. The weights and sigmoid parameters are implementation-specific and should be agreed in multi-vendor deployments as described in Section 7.1. Assume the C-PS receives: * 'level1_computing': 8 * 'level1_communication': 6 * 'level1_service': 9 Using a weighted sum with weights 0.4, 0.3, and 0.3: A = 0.4 * 8 + 0.3 * 6 + 0.3 * 9 = 7.7 Apply a sigmoid function with midpoint 'mu = 5' and slope 'k = 2': N(A) = 10 / (1 + exp(-(A - mu) / k)) = 10 / (1 + exp(-(7.7 - 5) / 2)) = 7.94 After rounding and clamping to 0-10, the Level 2 metric value is 8. B.2. Implementations of Aggregation Functions The following examples illustrate spatial, temporal, and cross- category aggregation. The functions and parameters are examples only. B.2.1. Spatial Aggregation Using Arithmetic Mean A C-SMA collects CPU utilization from four service instances: 40%, 60%, 80%, and 20%. Using the arithmetic mean: ** Spatial_CPU = (40 + 60 + 80 + 20) / 4 = 50% ** The result retains the input unit (percent) because the inputs are homogeneous. This value may be used as an implementation-specific aggregation-derived Level 1 computing metric, or as an input to a later normalization function. Kehan, et al. Expires 23 April 2027 [Page 56] Internet-Draft CATS Metrics October 2026 B.2.2. Temporal Aggregation Using Weighted Average A C-NMA collects delay samples over three measurement windows: 20 ms, 30 ms, and 40 ms. Using a weighted average with weights 0.2, 0.3, and 0.5: ** Temporal_delay = 0.2 * 20 + 0.3 * 30 + 0.5 * 40 = 33 ms ** Alternatively, 'max(20, 30, 40) = 40 ms' may be used for the worst- case temporal aggregation. B.2.3. Cross-Category Aggregation Using Weighted Sum After normalization, a C-PS has a computing score of 8, a communication score of 6, and a service score of 9. Using a weighted sum with weights 0.5, 0.3, and 0.2: ** Combined_score = 0.5 * 8 + 0.3 * 6 + 0.2 * 9 = 7.6 ** The result is unitless and can be further normalized to produce a Level 2 global metric. Other functions, such as weighted geometric mean and harmonic mean, may be used according to operator policy. Appendix C. 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, to Giuseppe Fioccola for Perfmetrdir 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 23 April 2027 [Page 57] Internet-Draft CATS Metrics October 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 23 April 2027 [Page 58]