]> China mobile

zhumengfei@cmdi.chinamobile.com

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

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 . Related requirements and OAM work identify update, stability, service-continuity, consistency, and black-holing concerns . 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. 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.

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

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. Assurance exposure: The extent to which degraded metric consumption, inconsistency, or fallback behavior is visible to OAM or management systems.

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.

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.

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.

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

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.

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.

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.

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

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.

Operational implications

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.

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.

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.

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

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 the underlying observation or aggregated condition is no longer suitable for the current steering use. The two concerns are complementary .

IANA considerations This document has no IANA actions.

Informative References IETF CATS Working Group n.d. IETF CATS Working Group n.d. IETF CATS Working Group n.d. IETF n.d.

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.

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.

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.

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.

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

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