Internet-Draft CATS Computing Service Metric Registry E August 2026
Zhang & Yang Expires 25 February 2027 [Page]
Workgroup:
CATS
Published:
Intended Status:
Standards Track
Expires:
Authors:
B. Zhang, Ed.
Pengcheng Laboratory
R. Yang, Ed.
Pengcheng Laboratory

CATS Computing Service Metric Registry Entries

Abstract

This document defines the initial set of registry entries for Computing Service Metrics used in Computing-Aware Traffic Steering (CATS). These metrics, including Global Available Slots (GAS), Computing Time, Cost, Reputation, Security Label, and Capability, provide service-oriented abstractions that complement the existing CATS Level 0/Level 1/Level 2 normalized metric framework defined in [I-D.ietf-cats-metric-definition].

This document follows the registry format and separation pattern established by [RFC8911] and [RFC8912], populating a new IANA registry titled "CATS Computing Service Metrics" with formal entries for each metric defined in [I-D.zhangb-cats-service-metrics-op].

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 25 February 2027.

▲

Table of Contents

1. Introduction

The Computing-Aware Traffic Steering (CATS) framework [I-D.ietf-cats-framework] introduces a multi-level metric framework [I-D.ietf-cats-metric-definition] that organizes computing and communication metrics into three abstraction levels (Level 0, Level 1, and Level 2). While this framework provides a solid theoretical baseline, mapping diverse hardware capabilities into normalized scores is highly complex and provider-dependent.

To bridge the gap between theoretical metric definitions and practical operational execution, [I-D.zhangb-cats-service-metrics-op] defines a set of Computing Service Metrics. These metrics are service-oriented abstractions that describe the concrete ability of a service site to handle specific services, including Global Available Slots (GAS), Computing Time, Cost, Reputation, Security Label, and Capability.

This document follows the pattern established by [RFC8911] and [RFC8912]: [RFC8911] defines the format for the IANA Registry of Performance Metrics, while [RFC8912] populates that registry with the initial set of entries. Similarly, [I-D.ietf-cats-metric-definition] establishes the CATS metric framework and registry structure, and this document populates the "CATS Computing Service Metrics" registry with the initial set of entries for Computing Service Metrics.

The registry entries defined in this document provide the formal specification required for IANA assignment of identifiers, ensuring interoperability across CATS implementations that use these service-oriented metrics for traffic steering decisions.

2. Terminology

This document makes use of the terms defined in [I-D.ietf-cats-framework] and [I-D.ietf-cats-metric-definition].

In particular:

Additionally, the following terms are used as defined in [I-D.zhangb-cats-service-metrics-op]:

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

This document defines entries for the "CATS Computing Service Metrics" registry. Each registry entry follows the structure defined in [I-D.ietf-cats-metric-definition] Section 6, which aligns with the Performance Metrics Registry format specified in [RFC8911].

Each registry entry contains the following top-level categories:

The naming convention for Computing Service Metrics follows the pattern:

   <Type>_<Method>_CATS-Service_<Name>_RFCXXXXsecY_<Unit>_<Output>
Figure 1

Where:

4. CATS Computing Service Metric Registry Entries

This section defines the formal registry entries for the initial set of Computing Service Metrics. These metrics are divided into Mandatory Metrics (Section 4.1 and Section 4.2) and Optional Extension Metrics (Section 4.3 through Section 4.6), consistent with the classification in [I-D.zhangb-cats-service-metrics-op].

4.1. Global Available Slots (GAS)

4.1.1. Summary

4.1.1.1. ID (Identifier)

IANA has allocated the Identifier TBD1 for this Named Metric Entry. See Section 5 for the mapping to Names.

4.1.1.2. Name

Svc_Passive_CATS-Service_GAS_RFCXXXXsecY_Count_Singleton

4.1.1.3. URI

To-be-assigned.

4.1.1.4. Description

Global Available Slots (GAS) represents the maximum number of concurrent clients that a service site is willing and able to serve for a specific CS-ID through a specific CSCI-ID at a given time.

GAS acts as a direct abstraction layer over complex and fluctuating raw computing metrics (CPU, GPU, Memory, Storage) and status metrics (load and health). Instead of exposing highly dynamic raw metrics to the network, the service site absorbs these variations internally and reports a single, actionable capacity indicator.

As the number of concurrent users increases, the GAS value naturally decreases. The site monitoring system dynamically reduces the GAS value upon detecting abnormal status metrics, such as load changes, health changes, or reachability issues. When GAS drops to 0, the instance cannot allocate any more resources, and no new requests will be steered to it.

4.1.2. Metric Definition

4.1.2.1. Reference Definition

[I-D.zhangb-cats-service-metrics-op]

Core referenced sections: Section 4.2.1 (Global Available Slots)

4.1.2.2. Fixed Parameters
  • Metric type: "gas"
  • Level: Service-oriented (L0/TBD)
  • Data type: non-negative integer
  • Metric units: Count (number of concurrent client slots)
  • Initial value: Derived from service reference information and local resource allocation

4.1.3. Method of Measurement

4.1.3.1. Reference Methods

GAS is derived from basic resource metrics, status metrics, service requirements, and local policy at the service site. The specific derivation algorithm is a local matter and is not standardized by this document. However, the following reference method is provided as an example:

   GAS = SUM_over_instances(max_capacity_i - active_sessions_i)
         for all healthy instances i
Figure 2

Where:

  • max_capacity_i is the maximum concurrent request capacity of instance i, derived from resource allocation and reference GAS information.
  • active_sessions_i is the current active session count of instance i.
  • Only healthy instances contribute to the GAS calculation; unhealthy instances contribute 0.

The Metric Aggregator (MA) MAY apply a local policy factor (e.g., a safety margin of 80%) to prevent over-subscription.

The service site can initially provide a GAS value based on its fixed resource allocation and service reference information, and then adjust it according to local policy and real-time monitoring.

4.1.3.4. Sampling Distribution

Sampling method: Event-driven and periodic sampling. The service site monitors internal instances continuously. GAS updates are reported when they become operationally significant (e.g., crossing a configured threshold, health status changes). A periodic heartbeat or soft-state synchronization MAY be used to refresh the C-PS view.

4.1.3.5. Runtime Parameters and Data Format

CS-ID: CATS Service Identifier (format as defined in [I-D.ietf-cats-framework])

CSCI-ID: CATS Service Contact Instance Identifier (format: ipv4-address-no-zone or ipv6-address-no-zone, complying with [RFC9911])

max_capacity: Maximum concurrent request capacity per instance (Units: count; Format: uint32)

active_sessions: Current active session count (Units: count; Format: uint32)

health_status: Instance health status (Format: boolean or enumerated value)

policy_factor: Local policy safety margin (Units: percentage; Format: decimal; Default: 1.0)

4.1.3.6. Roles

C-SMA (via Metric Aggregator): Collects instance-level metrics, calculates GAS according to local policy, and reports significant changes to the C-PS.

C-PS: Receives GAS values, maintains the Computing Service Table, and uses GAS for admission control and traffic steering decisions.

4.1.4. Output

4.1.4.1. Type

Singleton value

4.1.4.2. Reference Definition

Output format: A single non-negative integer representing the number of available concurrent client slots.

Score semantics:

  • GAS > 0: The service site can accept new requests.
  • GAS = 0: The service site is at capacity; no new requests should be steered to this CSCI-ID.
4.1.4.3. Metric Units

Count (number of concurrent client slots)

4.1.4.4. Calibration

Calibration method: The service site SHOULD validate GAS accuracy through controlled load testing. The deviation between reported GAS and actual observed capacity SHOULD be minimized (e.g., within 5% under representative workload profiles).

4.1.5. Administrative Items

4.1.5.2. Requester

IETF CATS Working Group

4.1.5.5. Comments and Remarks

This is a mandatory Computing Service Metric. GAS is the core metric that enables direct admission control in CATS traffic steering.

4.2. Computing Time

4.2.1. Summary

4.2.1.1. ID (Identifier)

IANA has allocated the Identifier TBD2 for this Named Metric Entry. See Section 5 for the mapping to Names.

4.2.1.2. Name

Svc_Passive_CATS-Service_ComputingTime_RFCXXXXsecY_Milliseconds_Singleton

4.2.1.3. URI

To-be-assigned.

4.2.1.4. Description

Computing Time represents the time required for a service site to perform one service request. It is a service-oriented metric that abstracts the processing delay of the deployed service instance.

The service site can initialize this metric based on service reference information (e.g., Reference Computing Time from a public service platform) and then measure or estimate it according to the runtime behavior of the deployed service instance. The service site dynamically adjusts this metric based on real-time load and local policy.

Computing Time is used by the C-PS to calculate total service time (computing time plus network delay) for traffic steering decisions.

4.2.2. Metric Definition

4.2.2.1. Reference Definition

[I-D.zhangb-cats-service-metrics-op]

Core referenced sections: Section 4.2.2 (Computing Time)

4.2.2.2. Fixed Parameters
  • Metric type: "comp_time"
  • Level: Service-oriented (L0/TBD)
  • Data type: non-negative integer or floating-point
  • Metric units: Milliseconds (ms)
  • Initial value: Derived from service reference information or benchmark measurement

4.2.3. Method of Measurement

4.2.3.1. Reference Methods

Computing Time is measured or estimated by the service site based on the runtime behavior of the deployed service instance. The specific measurement method is a local matter, but the following approaches are common:

  • Weighted average of instance response times, weighted by instance load.
  • Median or percentile (e.g., p95) of instance response times to account for outliers.
  • Dynamically adjusted estimate based on current load and historical trends.

The service site MAY also report min/max computing time and the associated input token counts for reference (e.g., in AI inference services).

The service site dynamically adjusts this metric based on real-time load and local policy.

4.2.3.4. Sampling Distribution

Sampling method: Continuous sampling with event-driven updates. The service site monitors response times continuously. Updates are reported when Computing Time deviates beyond a configured percentage band or when significant load changes occur.

4.2.3.5. Runtime Parameters and Data Format

CS-ID: CATS Service Identifier (format as defined in [I-D.ietf-cats-framework])

CSCI-ID: CATS Service Contact Instance Identifier (format: ipv4-address-no-zone or ipv6-address-no-zone, complying with [RFC9911])

response_time_samples: Array of observed response times (Units: ms; Format: array of uint32 or float)

load_factor: Current load factor affecting response time (Units: percentage; Format: decimal)

input_size: Size of input data for reference (e.g., token count for LLM services) (Units: count; Format: uint32; Optional)

4.2.3.6. Roles

Service Contact Instance / C-SMA: Measures or estimates Computing Time based on runtime behavior and reports significant changes to the C-PS.

C-PS: Receives Computing Time values, combines them with network delay from the Network Service Table to calculate total service time for traffic steering.

4.2.4. Output

4.2.4.1. Type

Singleton value (with optional min/max range)

4.2.4.2. Reference Definition

Output format: A single non-negative value representing the expected computing time in milliseconds. Implementations MAY also provide minimum and maximum observed values.

Score semantics:

  • Lower values indicate faster service processing.
  • Higher values indicate slower service processing.
  • The C-PS uses Computing Time together with network delay to select the optimal CSCI-ID.
4.2.4.3. Metric Units

Milliseconds (ms)

4.2.4.4. Calibration

Calibration method: The service site SHOULD benchmark Computing Time using representative workload profiles. The reported value SHOULD reflect the expected response time under current load conditions with a deviation target of less than 10% from observed values.

4.2.5. Administrative Items

4.2.5.2. Requester

IETF CATS Working Group

4.2.5.5. Comments and Remarks

This is a mandatory Computing Service Metric. Computing Time is essential for calculating total service time in CATS traffic steering decisions.

4.3. Cost

4.3.1. Summary

4.3.1.1. ID (Identifier)

IANA has allocated the Identifier TBD3 for this Named Metric Entry. See Section 5 for the mapping to Names.

4.3.1.2. Name

Svc_Passive_CATS-Service_Cost_RFCXXXXsecY_Unitless_Singleton

4.3.1.3. URI

To-be-assigned.

4.3.1.4. Description

Cost represents the self-defined price set by the service site to apply administrative or economic billing policies. It is an optional extension metric that enables cost-aware traffic steering.

The cost value is determined entirely by the service provider's local policy and may reflect factors such as resource scarcity, energy prices, service level agreements, or competitive pricing.

4.3.2. Metric Definition

4.3.2.1. Reference Definition

[I-D.zhangb-cats-service-metrics-op]

Core referenced sections: Section 4.3.1 (Cost)

4.3.2.2. Fixed Parameters
  • Metric type: "cost"
  • Level: Service-oriented (L0/TBD)
  • Data type: non-negative integer or floating-point
  • Metric units: Unitless (provider-defined currency or pricing unit)
  • Initial value: Defined by service provider policy

4.3.3. Method of Measurement

4.3.3.1. Reference Methods

Cost is self-defined by the service site based on local administrative or economic billing policies. It is not derived from raw hardware metrics but is set according to provider-specific factors such as:

  • Resource scarcity (e.g., edge GPUs may have higher cost than central cloud resources).
  • Energy prices and operational expenses.
  • Service Level Agreement (SLA) tiers.
  • Competitive market pricing.

The service site MAY adjust the cost value dynamically based on demand, time of day, or other business policies.

4.3.3.4. Sampling Distribution

Sampling method: Policy-driven updates. Cost changes are reported when the service site updates its pricing policy. A periodic heartbeat MAY be used to ensure consistency.

4.3.3.5. Runtime Parameters and Data Format

CS-ID: CATS Service Identifier (format as defined in [I-D.ietf-cats-framework])

CSCI-ID: CATS Service Contact Instance Identifier (format: ipv4-address-no-zone or ipv6-address-no-zone, complying with [RFC9911])

cost_value: The cost value (Format: uint32 or decimal; Unit: provider-defined)

currency_unit: Optional indicator of the pricing unit (Format: string; Optional)

4.3.3.6. Roles

Service Site / C-SMA: Defines and reports the cost value according to local policy.

C-PS: Receives cost values and MAY use them as a tie-breaker or primary criterion in traffic steering policies (e.g., selecting the lowest-cost eligible instance).

4.3.4. Output

4.3.4.1. Type

Singleton value

4.3.4.2. Reference Definition

Output format: A single non-negative value representing the cost.

Score semantics:

  • Lower values indicate lower cost.
  • Higher values indicate higher cost.
  • The C-PS MAY use cost to rank candidates after filtering by other criteria (e.g., GAS > 0, Computing Time within threshold).
4.3.4.3. Metric Units

Unitless (provider-defined pricing unit)

4.3.4.4. Calibration

N/A. Cost is a policy-defined nominal value, not a measured performance metric.

4.3.5. Administrative Items

4.3.5.2. Requester

IETF CATS Working Group

4.3.5.5. Comments and Remarks

This is an optional extension metric. Cost enables economic-aware traffic steering but is not required for basic CATS operation.

4.4. Reputation

4.4.1. Summary

4.4.1.1. ID (Identifier)

IANA has allocated the Identifier TBD4 for this Named Metric Entry. See Section 5 for the mapping to Names.

4.4.1.2. Name

Svc_Passive_CATS-Service_Reputation_RFCXXXXsecY_Score_Singleton

4.4.1.3. URI

To-be-assigned.

4.4.1.4. Description

Reputation represents a dynamic quality score based on user feedback and observed service performance. It reflects the historical quality of service provided by a service site.

Upon service completion, if a user experiences long delays or inaccurate results, feedback is returned to the C-PS along with the resource release message. The C-PS or service site aggregates this feedback into a reputation score.

4.4.2. Metric Definition

4.4.2.1. Reference Definition

[I-D.zhangb-cats-service-metrics-op]

Core referenced sections: Section 4.3.2 (Reputation)

4.4.2.2. Fixed Parameters
  • Metric type: "reputation"
  • Level: Service-oriented (L0/TBD)
  • Data type: non-negative integer
  • Metric units: Score (typically 0-10 or 0-100 scale)
  • Initial value: Default or bootstrap value set by provider

4.4.3. Method of Measurement

4.4.3.1. Reference Methods

Reputation is derived from user feedback and observed performance metrics. The specific aggregation algorithm is implementation-specific, but common approaches include:

  • Moving average of user satisfaction ratings.
  • Penalty-based scoring for timeout or error events.
  • Combination of objective metrics (success rate, delay compliance) and subjective user ratings.

Feedback is typically collected upon session completion and aggregated over a configurable time window.

4.4.3.4. Sampling Distribution

Sampling method: Event-driven sampling based on user feedback and session completion events. The reputation score is updated periodically (e.g., every hour or day) based on accumulated feedback.

4.4.3.5. Runtime Parameters and Data Format

CS-ID: CATS Service Identifier (format as defined in [I-D.ietf-cats-framework])

CSCI-ID: CATS Service Contact Instance Identifier (format: ipv4-address-no-zone or ipv6-address-no-zone, complying with [RFC9911])

feedback_score: Individual user feedback score (Format: integer; Range: 0-10 or 0-100)

success_indicator: Whether the session completed successfully (Format: boolean)

delay_compliance: Whether the delay SLA was met (Format: boolean)

aggregation_window: Time window for aggregating feedback (Units: seconds; Format: uint32; Default: 3600)

4.4.3.6. Roles

C-PS: Collects user feedback and session completion data, calculates reputation scores, and maintains reputation state.

Service Site: MAY provide objective performance data (success rates, delay statistics) to support reputation calculation.

4.4.4. Output

4.4.4.1. Type

Singleton value

4.4.4.2. Reference Definition

Output format: A single non-negative integer representing the reputation score.

Score semantics (example with 0-10 scale):

  • 0-3: Poor reputation, avoid if alternatives exist.
  • 4-7: Average reputation, acceptable for steering.
  • 8-10: Excellent reputation, preferred for steering.
4.4.4.3. Metric Units

Score (unitless, provider-defined scale)

4.4.4.4. Calibration

Calibration method: The reputation calculation algorithm SHOULD be validated to ensure it accurately reflects service quality. The C-PS SHOULD implement anti-gaming measures to prevent manipulation of reputation scores.

4.4.5. Administrative Items

4.4.5.2. Requester

IETF CATS Working Group

4.4.5.5. Comments and Remarks

This is an optional extension metric. Reputation enables quality-aware traffic steering based on historical performance.

4.5. Security Label

4.5.1. Summary

4.5.1.1. ID (Identifier)

IANA has allocated the Identifier TBD5 for this Named Metric Entry. See Section 5 for the mapping to Names.

4.5.1.2. Name

Svc_Passive_CATS-Service_SecurityLabel_RFCXXXXsecY_Score_Singleton

4.5.1.3. URI

To-be-assigned.

4.5.1.4. Description

Security Label reflects the security status of a service site. A higher score indicates a more secure site. It enables security-aware traffic steering, allowing the C-PS to prefer service sites with higher security posture.

The security label is evaluated by the service site based on local security policies, compliance status, threat intelligence, and security monitoring.

4.5.2. Metric Definition

4.5.2.1. Reference Definition

[I-D.zhangb-cats-service-metrics-op]

Core referenced sections: Section 4.3.3 (Security Label)

4.5.2.2. Fixed Parameters
  • Metric type: "security_label"
  • Level: Service-oriented (L0/TBD)
  • Data type: non-negative integer
  • Metric units: Score (0-10 scale)
  • Score range: 0-10 (0 indicates the poorest security; 10 indicates optimal security)

4.5.3. Method of Measurement

4.5.3.1. Reference Methods

Security Label is estimated by the service site based on local security assessment. The specific evaluation criteria are a local matter, but may include:

  • Compliance with security standards (e.g., ISO 27001, SOC 2).
  • Presence of security controls (firewalls, intrusion detection, encryption).
  • Threat intelligence and recent security incidents.
  • Vulnerability scan results and patch levels.
  • Physical security of the service site.
4.5.3.4. Sampling Distribution

Sampling method: Periodic reassessment. The service site SHOULD re-evaluate the Security Label periodically (e.g., daily or upon significant security events) and report changes to the C-PS.

4.5.3.5. Runtime Parameters and Data Format

CS-ID: CATS Service Identifier (format as defined in [I-D.ietf-cats-framework])

CSCI-ID: CATS Service Contact Instance Identifier (format: ipv4-address-no-zone or ipv6-address-no-zone, complying with [RFC9911])

security_score: The security label score (Format: uint8; Range: 0-10)

assessment_date: Timestamp of the last security assessment (Format: RFC 3339 timestamp)

compliance_flags: Optional bitmask indicating compliance with specific standards (Format: bit field; Optional)

4.5.3.6. Roles

Service Site / C-SMA: Evaluates and reports the Security Label based on local security assessment.

C-PS: Receives Security Label values and MAY use them to filter or rank service sites according to security policies (e.g., minimum security threshold).

4.5.4. Output

4.5.4.1. Type

Singleton value

4.5.4.2. Reference Definition

Output format: A single integer in the range 0-10 representing the security label.

Score semantics:

  • 0-3: Low security, not recommended for sensitive traffic.
  • 4-7: Medium security, acceptable for general traffic.
  • 8-10: High security, preferred for sensitive or regulated traffic.
4.5.4.3. Metric Units

Score (unitless, 0-10 scale)

4.5.4.4. Calibration

Calibration method: The service site SHOULD establish a consistent security assessment methodology. The mapping from security controls to the 0-10 score SHOULD be documented and reviewed periodically.

4.5.5. Administrative Items

4.5.5.2. Requester

IETF CATS Working Group

4.5.5.5. Comments and Remarks

This is an optional extension metric. Security Label enables security-aware traffic steering for sensitive workloads.

4.6. Capability (L1/L2 Compatibility)

4.6.1. Summary

4.6.1.1. ID (Identifier)

IANA has allocated the Identifier TBD6 for this Named Metric Entry. See Section 5 for the mapping to Names.

4.6.1.2. Name

Svc_Passive_CATS-Service_Capability_RFCXXXXsecY_Score_Singleton

4.6.1.3. URI

To-be-assigned.

4.6.1.4. Description

Capability represents the overall computing and storage capability allocated by the service site. It maintains compatibility with the Level 1 and Level 2 normalized metrics defined in [I-D.ietf-cats-metric-definition].

When a normalized L1 or L2 overall capability score is available at the service site, this metric carries that value. It allows C-PS implementations that prefer normalized scores to interoperate with service sites that also provide Computing Service Metrics.

4.6.2. Metric Definition

4.6.2.1. Reference Definition

[I-D.zhangb-cats-service-metrics-op]

Core referenced sections: Section 4.3.4 (Capability)

[I-D.ietf-cats-metric-definition]

Core referenced sections: Section 3.3 (Level 1 Metric Definition), Section 3.4 (Level 2 Metric Definition)

4.6.2.2. Fixed Parameters
  • Metric type: "site_cap"
  • Level: L1/L2 (as defined in [I-D.ietf-cats-metric-definition])
  • Data type: non-negative integer
  • Metric units: Score (unitless, typically 0-10 scale)
  • Normalization score range: 0-10 (0 indicates the poorest capability, 10 indicates the optimal capability)

4.6.3. Method of Measurement

4.6.3.1. Reference Methods

Capability is derived from the Level 1 or Level 2 normalized metrics defined in [I-D.ietf-cats-metric-definition]. The service site calculates the normalized score using the aggregation and normalization functions specified in that document:

  • Level 1 Capability: Aggregated and normalized score within a specific category (computing, communication, service, or composed).
  • Level 2 Capability: A single normalized score aggregating all relevant Level 0 and/or Level 1 metrics.

The specific aggregation and normalization functions are implementation-specific, as described in [I-D.ietf-cats-metric-definition] Section 4.2.

4.6.3.4. Sampling Distribution

Sampling method: Continuous sampling (e.g., collect underlying metrics every 10 seconds) with periodic reporting.

4.6.3.5. Runtime Parameters and Data Format

CS-ID: CATS Service Identifier (format as defined in [I-D.ietf-cats-framework])

CSCI-ID: CATS Service Contact Instance Identifier (format: ipv4-address-no-zone or ipv6-address-no-zone, complying with [RFC9911])

capability_level: Indicates whether this is L1 or L2 (Format: enumerated value; Values: "L1", "L2")

capability_category: For L1, indicates the category (Format: enumerated value; Values: "computing", "communication", "service", "composed"; N/A for L2)

normalized_score: The normalized capability score (Format: uint8; Range: 0-10)

4.6.3.6. Roles

C-SMA: Collects Level 0 raw metrics, calculates Level 1 or Level 2 normalized scores according to service/provider-specific strategies, and reports the Capability metric.

C-PS: Receives Capability values and MAY use them as an alternative or complement to other Computing Service Metrics for traffic steering.

4.6.4. Output

4.6.4.1. Type

Singleton value

4.6.4.2. Reference Definition

Output format: A single integer in the range 0-10 representing the normalized capability score.

Score semantics:

  • 0-3: Low capability, not recommended for steering.
  • 4-7: Medium capability, optional for steering.
  • 8-10: High capability, priority for steering.

These semantics align with the Level 1 and Level 2 metric definitions in [I-D.ietf-cats-metric-definition].

4.6.4.3. Metric Units

Unitless (0-10 scale)

4.6.4.4. Calibration

Calibration method: Conduct benchmark calibration based on representative workloads to align the mapping from Level 0 metrics to the normalized 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).

4.6.5. Administrative Items

4.6.5.2. Requester

IETF CATS Working Group

4.6.5.5. Comments and Remarks

This is an optional extension metric. Capability provides backward compatibility with the L1/L2 normalized metric framework defined in [I-D.ietf-cats-metric-definition].

5. IANA Considerations

This document requests IANA to create a new registry titled "CATS Computing Service Metrics" under the existing "Computing-Aware Traffic Steering (CATS)" heading.

The initial entries for this registry are defined in Section 4 as follows:

Table 1: Initial Registry Entries
Identifier Name
TBD1 Svc_Passive_CATS-Service_GAS_RFCXXXXsecY_Count_Singleton
TBD2 Svc_Passive_CATS-Service_ComputingTime_RFCXXXXsecY_Milliseconds_Singleton
TBD3 Svc_Passive_CATS-Service_Cost_RFCXXXXsecY_Unitless_Singleton
TBD4 Svc_Passive_CATS-Service_Reputation_RFCXXXXsecY_Score_Singleton
TBD5 Svc_Passive_CATS-Service_SecurityLabel_RFCXXXXsecY_Score_Singleton
TBD6 Svc_Passive_CATS-Service_Capability_RFCXXXXsecY_Score_Singleton

For each entry, IANA is requested to assign a unique Identifier from the registry's assignment pool. Each registry entry contains the following fields:

The registration policy for this registry is "IETF Review" [RFC8126], meaning new entries require publication of an RFC or an IESG-approved document.

6. Security Considerations

Computing Service Metrics, like all CATS metrics, are important inputs to traffic steering selection logic. Incorrect or manipulated metrics can directly affect forwarding behavior, potentially leading to service disruption, denial-of-service, or policy violation [I-D.ietf-cats-metric-definition].

Specific considerations for Computing Service Metrics include:

General security requirements for CATS metrics, including authenticity, integrity, freshness, and confidentiality, are defined in [I-D.ietf-cats-metric-definition] Section 7.

7. Normative References

[RFC2119]
Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, , <https://www.rfc-editor.org/info/rfc2119>.
[RFC8126]
Cotton, M., Leiba, B., and T. Narten, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 8126, DOI 10.17487/RFC8126, , <https://www.rfc-editor.org/info/rfc8126>.
[RFC8174]
Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, , <https://www.rfc-editor.org/info/rfc8174>.
[RFC8911]
Ciavattone, L., Geib, R., Morton, A., and M. Wieser, "Registry for Performance Metrics", RFC 8911, DOI 10.17487/RFC8911, , <https://www.rfc-editor.org/info/rfc8911>.
[I-D.ietf-cats-framework]
Li, C., Du, Z., Boucadair, M., Contreras, L. M., and J. Drake, "A Framework for Computing-Aware Traffic Steering (CATS)", Work in Progress, Internet-Draft, draft-ietf-cats-framework-24, , <https://datatracker.ietf.org/doc/html/draft-ietf-cats-framework-24>.
[I-D.ietf-cats-metric-definition]
Yao, K., Li, C., Contreras, L. M., Ros-Giralt, J., and G. Zeng, "CATS Metrics Definition", Work in Progress, Internet-Draft, draft-ietf-cats-metric-definition-10, , <https://datatracker.ietf.org/doc/html/draft-ietf-cats-metric-definition-10>.
[I-D.zhangb-cats-service-metrics-op]
Zhang, B., Dai, Y., Du, Z., Zeng, G., and C. Miao, "Computing Service Metric Definitions and Operation under CATS", Work in Progress, Internet-Draft, draft-zhangb-cats-service-metrics-op-03, , <https://datatracker.ietf.org/doc/html/draft-zhangb-cats-service-metrics-op-03>.

8. Informative References

[RFC8912]
Morton, A., Geib, R., and L. Ciavattone, "Initial Performance Metrics Registry Entries", RFC 8912, DOI 10.17487/RFC8912, , <https://www.rfc-editor.org/info/rfc8912>.
[RFC9911]
Schönwälder, J., "RFC 9911: Common YANG Data Types", RFC 9911, <https://www.rfc-editor.org/info/rfc9911>.

Authors' Addresses

Bin Zhang (editor)
Pengcheng Laboratory
Shenzhen
China
Rongwei Yang (editor)
Pengcheng Laboratory
Shenzhen
China