Computing-Aware Traffic Steering M. Zhu
Internet-Draft China mobile
Intended status: Informational 29 August 2026
Expires: 2 March 2027
Operational Semantics for CATS Metric Consumption
draft-zhu-cats-metric-semantics-01
Abstract
The CATS framework introduces computing-related information into
traffic steering decisions. Existing work defines how such metrics
are represented, distributed, and used within the CATS architecture.
However, it does not fully address whether a metric remains suitable
for use at the point of consumption.
This document introduces a set of operational semantics for CATS
metrics, including Freshness, Operational acceptability, and
Assurance exposure. These semantics describe whether a metric
remains temporally aligned with the underlying condition, whether it
remains suitable for operational use in steering, and whether
degraded consumption is externally visible to management or OAM
functions.
The document further explains how these semantics apply across
centralized, distributed, and hybrid deployments, including cases
where different metric sources contribute under different conditions.
The goal is to provide a consistent basis for interpreting metric
usability in CATS without introducing a new metric level or
prescribing a single derivation method.
Implementations may determine when degradation occurs, while the
resulting consumption condition can still be represented and
understood consistently across CATS 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/.
Zhu Expires 2 March 2027 [Page 1]
Internet-Draft CATS Metric Semantics August 2026
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
This Internet-Draft will expire on 2 March 2027.
Copyright Notice
Copyright (c) 2026 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents (https://trustee.ietf.org/
license-info) in effect on the date of publication of this document.
Please review these documents carefully, as they describe your rights
and restrictions with respect to this document. Code Components
extracted from this document must include Revised BSD License text as
described in Section 4.e of the Trust Legal Provisions and are
provided without warranty as described in the Revised BSD License.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Scope and positioning . . . . . . . . . . . . . . . . . . . . 4
3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5
4. Operational gap . . . . . . . . . . . . . . . . . . . . . . . 6
5. Operational semantics in different deployment modes . . . . . 7
5.1. Freshness . . . . . . . . . . . . . . . . . . . . . . . . 7
5.2. Operational acceptability . . . . . . . . . . . . . . . . 7
5.3. Assurance exposure . . . . . . . . . . . . . . . . . . . 8
5.4. Deployment-specific considerations . . . . . . . . . . . 8
5.4.1. Centralized deployments . . . . . . . . . . . . . . . 9
5.4.2. Distributed deployments . . . . . . . . . . . . . . . 9
5.4.3. Hybrid deployments . . . . . . . . . . . . . . . . . 10
6. Operational implications . . . . . . . . . . . . . . . . . . 10
6.1. Relationship to service continuity . . . . . . . . . . . 11
6.2. Control, management, and OAM relevance . . . . . . . . . 11
6.3. Lightweight signaling considerations . . . . . . . . . . 12
7. Illustrative example . . . . . . . . . . . . . . . . . . . . 12
8. Security Considerations . . . . . . . . . . . . . . . . . . . 13
9. IANA considerations . . . . . . . . . . . . . . . . . . . . . 14
10. Informative References . . . . . . . . . . . . . . . . . . . 14
Appendix A. Illustrative Evidence and State Derivation
Patterns . . . . . . . . . . . . . . . . . . . . . . . . 14
A.1. Temporal evidence . . . . . . . . . . . . . . . . . . . . 15
A.2. Non-temporal evidence . . . . . . . . . . . . . . . . . . 15
Appendix B. Illustrative Operational Mapping . . . . . . . . . . 15
Zhu Expires 2 March 2027 [Page 2]
Internet-Draft CATS Metric Semantics August 2026
B.1. YANG operational-state fragment . . . . . . . . . . . . . 16
B.2. Illustrative OAM diagnostic record . . . . . . . . . . . 16
Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 17
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 17
1. Introduction
Computing-Aware Traffic Steering (CATS) extends traffic steering
beyond traditional network reachability and path selection by
incorporating computing-related inputs into forwarding and service-
selection decisions. This change is not merely an incremental
extension of traditional routing inputs. Many computing-related
metrics vary more quickly, are aggregated and distributed through
more diverse paths, and lose operational meaning more rapidly. As a
result, the difficulty in CATS is not only how to define more
metrics, but also how to determine whether a received metric remains
suitable for operational consumption as a steering input.
Existing CATS work explains how metrics are represented, distributed,
and used [CATS-FRAMEWORK] [CATS-METRIC-DEFINITION]. Related
requirements and OAM work identify update, stability, service-
continuity, consistency, and black-holing concerns
[CATS-REQUIREMENTS] [CATS-OAM]. However, such metrics cannot always
be directly consumed by existing steering or routing protocols. Many
computing-related metrics evolve at timescales that are shorter than
those assumed by traditional control-plane mechanisms. Excessively
frequent metric updates may introduce instability or oscillation into
the steering process. Infrequent updates, by contrast, may cause
decisions to rely on stale conditions that no longer reflect the
current operational state.
This document addresses a related issue at the point of consumption:
whether a metric remains operationally suitable when it is consumed
for steering. A metric may remain visible and well-formed while no
longer remaining suitable for normal steering use. This problem is
more likely to arise when computing-related information changes
quickly, is collected and redistributed before use, or is consumed
under different deployment conditions.
Zhu Expires 2 March 2027 [Page 3]
Internet-Draft CATS Metric Semantics August 2026
In conventional routing, slightly outdated cost information often
leads only to a suboptimal path. In CATS, a decision may rely on
utilization, admission headroom, or service-state information that no
longer reflects the current operational condition. In centralized
deployments, this may result from control-loop delay. In distributed
deployments, it may result from divergence across local observations.
In hybrid deployments, it may result from the joint use of inputs
that do not share the same temporal behavior or operational
conditions. The result may be admission rejection, degraded service
continuity, or steering behavior resembling black-holing.
Distributed systems provide a useful design precedent for this
problem. Systems operating on replicated or asynchronously
propagated state commonly distinguish a value's timestamp from the
conditions under which it can be safely consumed, for example by
making bounded time uncertainty, version or revision progress, or
update continuity explicit. This document does not import
distributed-consistency mechanisms into CATS; it adopts the same
operational principle that metadata provides evidence, while
consumption suitability is interpreted at the consumer.
This document defines an orthogonal set of operational semantics that
can be associated with any CATS metric, regardless of abstraction
level. These semantics are intended to express whether a metric
remains sufficiently fresh, whether it remains operationally
acceptable for steering use, and whether degraded consumption becomes
externally visible to OAM or management functions.
The intent is not to standardize the threshold that causes
degradation, but to avoid leaving the resulting consumption condition
entirely implicit within implementation-specific steering logic.
2. Scope and positioning
The semantics are intended to complement the metric abstraction
model. Metric abstraction explains how raw measurements are
normalized or combined into higher-level indicators. This document
addresses a different dimension: the operational condition of a
metric at the point of consumption. More specifically, it defines
three orthogonal semantics, i.e., Freshness, Operational
acceptability, and Assurance exposure, to describe whether a metric
remains temporally suitable for use, whether it remains acceptable
for operational consumption in steering, and whether degraded
consumption or fallback become externally visible.
This distinction is also relevant when raw observations are
normalized or combined into higher-level CATS metrics. Contributing
inputs may have different observation times, update histories, or
Zhu Expires 2 March 2027 [Page 4]
Internet-Draft CATS Metric Semantics August 2026
validity behavior, and a higher-level metric may remain available
even when part of its contributing evidence no longer supports the
same steering role. Degradation may therefore need to be associated
with the metric, a contributing category, or another deployment-
specific scope rather than being assumed to apply uniformly to all
inputs.
These semantics are not tied to any single deployment model. They
can be applied across existing abstraction levels and across
centralized, distributed, and hybrid operation. This document also
does not define a new transport, encoding, or control-plane protocol.
Instead, it defines semantic information that may later be carried,
derived, or exposed by future protocol elements, data models,
management objects, or OAM procedures. A steering consumer may use
these semantics to determine whether a metric can still participate
in normal steering logic. A control, management, or OAM function may
use them to distinguish normal consumption from degraded consumption,
fallback behavior, or source-specific semantic degradation.
The conditions that cause a metric to be classified as degraded or
unacceptable may remain deployment- or implementation-specific. This
document instead defines the common meaning of the resulting
consumption condition: whether the metric can still participate in
normal steering, whether its use is restricted or excluded, what
scope is affected, and whether the condition is externally visible.
This allows proprietary derivation or steering logic to remain local
while avoiding incompatible interpretations of degraded consumption
across CATS functions.
3. Terminology
Metric-consuming decision point: A functional point at which CATS
metrics are consumed to derive or support steering, path-selection,
or service-selection decisions. Depending on the deployment model,
this function may be realized by a centralized CATS Path Selector
(C-PS), by an Ingress CATS-Forwarder with embedded decision logic, or
by a combination of both in hybrid deployments.
Metric evidence: Information available to a metric-consuming decision
point for assessing Freshness or Operational acceptability, such as
observation or update time, age, revision or sequence information,
validity information, or update continuity.
Freshness: The extent to which a metric remains temporally suitable
for its intended operational use.
Operational acceptability: The extent to which a metric remains
suitable for operational consumption at the current time.
Zhu Expires 2 March 2027 [Page 5]
Internet-Draft CATS Metric Semantics August 2026
Assurance exposure: The extent to which degraded metric consumption,
inconsistency, or fallback behavior is visible to OAM or management
systems.
4. Operational gap
The gap addressed in this document is the lack of an explicit
description of metric usability at the point of consumption. A
metric may remain visible and well-formed while no longer remaining
suitable for normal steering use.
This missing layer appears in three ways. First, a metric may lose
temporal alignment with the condition it is intended to describe
while still remaining available to the consumer. For example, a
controller-based deployment may continue to distribute a site-level
utilization metric that no longer reflects the current service load.
Second, a metric may remain present and syntactically valid while no
longer remaining suitable for normal operational consumption in
steering. For example, repeated delay, poor update continuity, or
inconsistency with other observations may make a metric unsuitable
for fine-grained steering even though it is still retained for
reduced-trust or fallback use.
Third, degraded metric consumption may remain invisible to management
or OAM even after steering shifted into fallback or reduced-trust
behavior. In such a case, the problem is not only metric degradation
itself, but also the lack of external visibility into the semantic
condition under which steering is proceeding.
An implementation can locally determine that a metric has become
degraded, but this alone does not provide an interoperable
consumption meaning. If the resulting state remains private, another
CATS function or an OAM system cannot distinguish normal steering
from reduced-trust use, exclusion, or fallback without understanding
the implementation's internal policy. The interoperability gap is
therefore not the absence of a common threshold, but the absence of a
common interpretation once metric consumption is no longer normal.
These gaps are amplified by deployment conditions. In centralized
operation, semantic degradation may be introduced within the control
loop before the metric is used. In distributed operation, different
decision points may rely on different local versions of what is
nominally the same condition. In hybrid operation, the problem is
further complicated by the joint use of metric inputs that do not
share the same temporal behavior or consumption assumptions.
Zhu Expires 2 March 2027 [Page 6]
Internet-Draft CATS Metric Semantics August 2026
5. Operational semantics in different deployment modes
This document introduces three operational semantics for CATS
metrics: Freshness, Operational acceptability, and Assurance
Exposure. They describe the operational condition of a metric at the
point of consumption. These semantics can support consistent
steering, path-selection, and service-selection decisions across
centralized, distributed, and hybrid deployments.
A derivation method for these semantics may depend on observable
factors such as metric age, revision or sequence progress, update
continuity, source consistency, and deployment-specific trust
conditions. These factors may be combined differently depending on
the dynamics of the metric and the operational objectives of the
deployment. Appendix A provides illustrative examples of such logic.
5.1. Freshness
Freshness captures whether a metric remains temporally aligned with
the condition it represents, particularly when update frequency does
not match the dynamics of the underlying system. In many
deployments, Freshness depends at least in part on the elapsed age of
the metric relative to the time sensitivity of the condition it
represents. A metric that is only a few seconds old may remain
operationally usable for relatively stable capability information,
while the same age may be excessive for rapidly varying utilization
or admission-related state. Freshness therefore concerns whether the
temporal separation between metric generation and metric consumption
remains consistent with the operational purpose for which the metric
is used.
A timestamp, age value, revision, sequence number, validity
information, or continuity indication is evidence from which
Freshness may be derived; none of these elements is by itself
equivalent to the Freshness semantic state.
5.2. Operational acceptability
Operational acceptability captures whether the metric remains
suitable for operational consumption in steering at the current time.
A metric may remain visible, syntactically valid, and even partially
informative while no longer remaining appropriate for normal fine-
grained steering use. For clarity, this document uses a lightweight
three-state interpretation: acceptable, degraded, and unacceptable.
More detailed state distinctions are possible, but they are outside
the scope of this document. An acceptable metric remains suitable
for normal steering input under the assumptions of the deployment. A
degraded metric no longer supports normal steering use, but may still
Zhu Expires 2 March 2027 [Page 7]
Internet-Draft CATS Metric Semantics August 2026
be retained for fallback or reduced-trust behavior. An unacceptable
metric is not suitable for steering input. A deployment may derive
these states from one or more factors, including metric age, update
continuity, source consistency, or other deployment-specific
conditions.
In particular, a degraded metric should not be silently treated as
normal steering input. An implementation may instead apply reduced-
trust, coarse-grained, refresh, or fallback behavior according to
local policy.
5.3. Assurance exposure
Assurance exposure captures whether degraded usage, inconsistency, or
fallback behavior is externally visible to management or OAM. A
system may continue to forward traffic and may continue to retain
metric values internally while no longer operating under the semantic
conditions that would justify normal steering. Assurance exposure
therefore concerns whether degraded consumption, semantic divergence,
or fallback-driven behavior can be distinguished from normal
operation by external functions for diagnosis, monitoring, or
operational control.
Such exposure does not require disclosure of proprietary steering
weights or derivation algorithms. It may instead expose the
resulting state, affected source or scope, degradation reason, and
whether fallback is in effect.
5.4. Deployment-specific considerations
The effect of these semantics depends on where metrics are consumed
for decisions and how metric-related information is exchanged among
CATS functional entities. In centralized deployments, decisions are
made primarily in a centralized CATS Path Selector (C-PS) or
equivalent control-side function. In distributed deployments,
decisions are made at, or near, an Ingress CATS-Forwarder. In hybrid
deployments, decision logic is split across centralized and ingress-
side functions.
In this document, communication among network elements refers mainly
to the exchange of metric information or decision-related
information, such as metric reporting from computing or service nodes
to a decision function, or decision distribution from a C-PS to an
Ingress CATS-Forwarder. These exchanges are distinct from data-plane
traffic, where user traffic is forwarded toward a selected service
instance. Degraded semantic conditions may also need to be exposed
through management or OAM functions.
Zhu Expires 2 March 2027 [Page 8]
Internet-Draft CATS Metric Semantics August 2026
5.4.1. Centralized deployments
In centralized deployments, metrics typically reach the decision
point only after collection, transport, processing, and possible
aggregation. Metric information may be reported from computing or
service nodes, possibly through metric agents, to a centralized C-PS
or equivalent control-side function. The resulting decision-related
information may then be provided to Ingress CATS-Forwarders for
steering execution. As a result, a metric may no longer accurately
reflect the condition on which the centralized decision is intended
to rely by the time it reaches the decision function.
In this setting, freshness helps determine whether the metric remains
temporally aligned with the underlying operational condition.
Operational acceptability helps determine whether the metric can
still be used as normal input to centralized steering logic, or
whether it should instead be treated as degraded or reduced-trust
input. Assurance exposure helps determine whether such degradation
in metric consumption is externally visible, even when the
centralized system continues to steer traffic and continues to
receive metrics from the underlying sources.
5.4.2. Distributed deployments
In distributed deployments, metrics are consumed at, or close to, the
ingress-side decision point. Metric information may be distributed
directly to an Ingress CATS-Forwarder or to a co-located decision
function, and the resulting steering decision may be applied locally.
The main issue is that different local decision points may consume
different observations, update histories, or local versions of what
is operationally treated as the same condition.
A locally available metric may remain fresh from the perspective of
one ingress decision point, while another ingress decision point has
shifted to a different view of the same service or resource
condition. In this setting, freshness helps determine whether the
locally available metric remains temporally suitable. Operational
acceptability helps determine whether that local metric can still
support normal steering at that decision point, or whether it should
instead be treated as degraded or reduced-trust input. Assurance
exposure helps determine whether divergence across local decision
points is externally visible, rather than remaining only an internal
difference among distributed observations.
Zhu Expires 2 March 2027 [Page 9]
Internet-Draft CATS Metric Semantics August 2026
This document does not require distributed decision points to hold
identical observations or to produce identical steering decisions.
Different local outcomes are not by themselves an error condition;
the concern addressed here is whether each decision point's evidence
condition is correctly interpreted and whether degraded consumption
is distinguishable from normal operation.
5.4.3. Hybrid deployments
In hybrid deployments, metric-consuming decisions are split across
centralized and ingress-side functions, and different metric sources
may be consumed at different layers of the same steering process.
Some metric information may be collected and interpreted by a
centralized C-PS, while other metric information may be consumed
directly by an Ingress CATS-Forwarder or local decision function.
The main issue is that jointly consumed inputs may not share the same
temporal behavior, trust conditions, or operational scope. A
relatively stable local metric may remain suitable for normal
steering use, while a centrally distributed dynamic metric may be
suitable only for degraded or reduced-trust use.
In this setting, freshness helps distinguish inputs whose temporal
validity differs across sources. Operational acceptability helps
distinguish source-specific degradation, so that one input may remain
acceptable while another is retained only for degraded use.
Assurance exposure helps determine whether such partial semantic
degradation is externally visible.
For this reason, a hybrid deployment should be able to distinguish
metrics that arrive from different sources and that do not share the
same consumption conditions. It should also support source-specific
degradation, so that one degraded input does not force all other
inputs into the same state, and one acceptable input does not hide
degradation in another.
The same principle applies to aggregated metrics: degradation in one
contributing category or evidence source need not imply identical
degradation of every other contribution, but the affected scope
should remain distinguishable when it matters to consumption.
6. Operational implications
Zhu Expires 2 March 2027 [Page 10]
Internet-Draft CATS Metric Semantics August 2026
6.1. Relationship to service continuity
In CATS, service continuity depends not only on whether traffic can
still be forwarded, but also on whether the selected service instance
or computing target remains suitable after the steering decision is
made. A steering outcome may therefore remain valid from a
forwarding perspective while no longer remaining valid from a service
perspective. At the same time, the steering decision itself may
depend on traffic- and service-related conditions whose validity is
highly sensitive to metric freshness. Excessively frequent metric
updates may introduce instability or oscillation into the steering
process. Infrequent updates, by contrast, may cause steering
decisions to rely on stale conditions that no longer reflect the
current operational state. For this reason, freshness is relevant
not only to the suitability of the selected service target, but also
to the continued validity of the steering decision that directs
traffic toward it. Explicit freshness semantics can also help avoid
unnecessary refreshes when an existing metric remains suitable for
its intended use, while allowing more timely updates when its
consumption condition degrades.
Freshness helps determine whether a metric reflects the service
condition on which continuity-related steering depends. Operational
acceptability helps determine whether that metric can support normal
continuity-sensitive steering or should instead be treated as
degraded or fallback input. Assurance exposure helps make
continuity-relevant degradation externally visible once the system
shifted away from normal semantic conditions.
These semantics do not themselves provide continuity procedures,
migration behavior, or affinity handling. They indicate when a
metric should no longer be treated as a normal input to continuity-
sensitive steering.
6.2. Control, management, and OAM relevance
These semantics are relevant not only at the metric-consuming
decision point, but also to control, management, and OAM functions
around it.
A control function may use these semantics to distinguish normal
metric use from degraded or fallback use in the steering process. A
management function may use them to determine whether steering is
operating under normal semantic conditions or shifted into reduced-
confidence behavior. An OAM function may use them to observe whether
degraded consumption, semantic divergence, or fallback handling is
operationally visible even though forwarding succeeds.
Zhu Expires 2 March 2027 [Page 11]
Internet-Draft CATS Metric Semantics August 2026
6.3. Lightweight signaling considerations
This document does not define protocol fields, but the semantics
above are intended to be protocol-ready and lightweight.
Freshness-related evidence could include a timestamp, an age value, a
revision or sequence, validity information, or an update-continuity
indication carried with or observed about the metric. A consumer may
derive Freshness and Operational acceptability from such evidence
under local policy. The resulting state may then be exposed through
an operational data model, OAM record, management object, telemetry
event, or troubleshooting signal.
This separates carried or observed evidence, consumer-derived
operational state, and external exposure. Not all semantics
therefore need to become new protocol fields. Such information may
occur on different paths depending on deployment, such as metric
reporting toward a decision function, decision distribution toward an
ingress forwarder, or exposure toward management and OAM systems.
Appendix B gives an illustrative mapping.
7. Illustrative example
Consider a hybrid deployment in which a consumer uses relatively
stable site capability information learned through one path and fast-
changing utilization information received through a centralized
controller path. At time T1, both inputs are current enough that the
consumer selects Site B for dynamic steering. At time T2, the
capability information remains unchanged, but the utilization
information distributed by the controller no longer reflects the
current service condition because the workload has changed since
observation. If the consumer continues to treat both inputs as
equally current, it may still perform fine-grained steering toward
Site B on the basis of an obsolete utilization condition.
The semantic decision flow can be illustrated as follows:
Zhu Expires 2 March 2027 [Page 12]
Internet-Draft CATS Metric Semantics August 2026
+------------------+
| Metric arrives |
+---------+--------+
|
v
+------------------+
| Check freshness |
+---------+--------+
|
v
+-----------------------------+
| Derive operational state |
| acceptable / degraded / |
| unacceptable |
+---------+-------------------+
|
+-----------+-----------+
| |
v v
+---------------+ +----------------------+
| steering uses | | fallback / reduced |
| normal input | | trust behavior |
+---------------+ +----------+-----------+
|
v
+-------------------------+
| expose condition to |
| management / OAM |
+-------------------------+
Under the semantics defined here, the capability information may
remain acceptable, while the utilization information is degraded or
even unacceptable. The consumer may therefore fall back to a coarser
policy, and that fallback can be exposed to management or OAM.
8. Security Considerations
If an attacker can manipulate freshness-related metadata,
acceptability state, or assurance visibility, traffic may be steered
on the basis of information that appears valid but is not. This can
amplify the impact of stale or falsified compute-related inputs and
may lead to traffic mis-steering, localized resource exhaustion, or
service disruption.
Protocol or security mechanisms that protect metric messages against
replay or stale-message delivery do not by themselves establish the
operational Freshness defined in this document. A metric message may
be authentic, recently delivered, and protected against replay while
Zhu Expires 2 March 2027 [Page 13]
Internet-Draft CATS Metric Semantics August 2026
the underlying observation or aggregated condition is no longer
suitable for the current steering use. The two concerns are
complementary [CATS-METRIC-DEFINITION].
9. IANA considerations
This document has no IANA actions.
10. Informative References
[CATS-FRAMEWORK]
IETF CATS Working Group, "A Framework for Computing-Aware
Traffic Steering (CATS)", n.d.,
.
[CATS-METRIC-DEFINITION]
IETF CATS Working Group, "Computing-Aware Traffic Steering
(CATS) Metrics Definition", n.d.,
.
[CATS-OAM] IETF, "CATS OAM Framework", n.d.,
.
[CATS-REQUIREMENTS]
IETF CATS Working Group, "Use Cases and Requirements for
Computing-Aware Traffic Steering (CATS)", n.d.,
.
Appendix A. Illustrative Evidence and State Derivation Patterns
This appendix provides non-normative examples of evidence that may
contribute to the acceptable, degraded, and unacceptable states
described in the main body. The examples do not define common
thresholds or a single derivation algorithm. They illustrate the
distributed-systems design principle adopted by this document: a
timestamp or other individual metadata item is evidence, while the
condition under which a value can be consumed is derived in context.
Zhu Expires 2 March 2027 [Page 14]
Internet-Draft CATS Metric Semantics August 2026
A.1. Temporal evidence
A consumer may consider temporal evidence such as observation time,
update time, metric age, or an associated validity interval. A
deployment may treat a metric as acceptable while the available
evidence remains compatible with the intended steering use, as
degraded when it no longer supports normal fine-grained use but
remains useful for reduced-trust or fallback behavior, and as
unacceptable when it no longer provides suitable steering evidence.
The applicable boundaries remain implementation- or deployment-
specific.
A.2. Non-temporal evidence
Elapsed time need not be the only indication that the condition of a
metric has changed. A consumer may also consider non-temporal
evidence such as revision or sequence progress, update discontinuity,
inconsistency with other observations, a material change in the
underlying condition, or missing context required for the intended
use.
For example, a recent timestamp does not necessarily indicate that
the consumer has observed the expected logical progress of a metric
source. A revision gap, missed or reordered update, source
divergence, or other relevant event may indicate that the current
metric no longer supports normal steering use even before an age-
based boundary is reached. Similarly, a material change in the
represented condition may make a previously acceptable metric
unsuitable for its intended use without waiting for a fixed validity
interval to expire.
These evidence types may be combined differently by different
implementations. The common semantic result is not the trigger or
formula used to derive the state, but whether the metric remains
acceptable, is consumed under degraded conditions, or is no longer
suitable for the corresponding steering use.
Appendix B. Illustrative Operational Mapping
The semantics in this document may be mapped to operational data
models or OAM records without exposing proprietary steering
algorithms. This appendix shows two illustrative forms. They are
not protocol specifications and do not define a required encoding.
Zhu Expires 2 March 2027 [Page 15]
Internet-Draft CATS Metric Semantics August 2026
B.1. YANG operational-state fragment
The following fragment illustrates how evidence and consumer-derived
state could be separated in an operational data model. It is
intentionally incomplete and is not a standalone YANG module.
container cats-metric-consumption-state {
list metric-state {
key "metric-name source-id";
leaf metric-name { type string; }
leaf source-id { type string; }
leaf last-observation-time { type yang:date-and-time; }
leaf revision { type uint64; }
leaf acceptability-state {
type enumeration {
enum acceptable;
enum degraded;
enum unacceptable;
}
}
leaf degradation-reason { type string; }
leaf fallback-in-effect { type boolean; }
}
}
In this example, last-observation-time and revision are metric
evidence, acceptability-state is derived by the consumer, and
degradation-reason and fallback-in-effect provide operational
visibility. A complete data model could carry additional evidence or
state without changing this separation.
B.2. Illustrative OAM diagnostic record
The following YAML-like rendering is used only for readability and
does not specify an encoding. It illustrates the type of information
that an operator could observe without access to proprietary steering
weights.
Zhu Expires 2 March 2027 [Page 16]
Internet-Draft CATS Metric Semantics August 2026
overall-state: degraded
fallback-in-effect: true
metrics:
- metric-name: compute-utilization
acceptability-state: degraded
degradation-reason: stale
- metric-name: network-latency
acceptability-state: acceptable
degradation-reason: none
The useful information is the semantic condition under which the
inputs were consumed and whether fallback was active. The local
thresholds, weights, and steering calculations that produced the
decision remain implementation-specific.
Acknowledgments
Author's Address
Mengfei Zhu
China mobile
Email: zhumengfei@cmdi.chinamobile.com
Zhu Expires 2 March 2027 [Page 17]