]> ZTE Corporation

fu.huakai@zte.com.cn

ZTE Corporation

xiong.quan@zte.com.cn

China Mobile

duzongpeng@chinamobile.com

China Mobile

liubo@chinamobile.com

China Mobile

lizhenqiang@chinamobile.com

CATS This document describes the Operations, Administration, and Maintenance (OAM) framework and requirements for Computing-Aware Traffic Steering (CATS). The framework defines the CATS OAM layering model and functional components. It also specifies the requirements to enable fault management and performance monitoring for CATS end-to-end connections across clients, network paths, and service instances within a single domain. This document does not define concrete OAM protocol designs or protocol extensions.

Introduction As described in , edge computing provides lower response time and higher transmission rate than cloud computing by moving computing resources to the network edge. To meet the requirements of users that are highly distributive, service providers deploy the same type of service instances at multiple edge sites, which involves steering traffic from clients to the most appropriate computing instance. Computing-Aware Traffic Steering (CATS) provides a traffic engineering approach that incorporates the dynamic states of both computing and network resources to optimize service instance selection. While such policies rely on multi-dimensional metrics to achieve service assurance, existing network-centric Operations, Administration, and Maintenance (OAM) technologies are insufficient as they focus solely on infrastructure-layer maintenance and fail to provide E2E (end-to-end) visibility from the client to the service instance. Consequently, a dedicated CATS OAM framework is required to bridge the gap between network reachability and service availability, transforming CATS steering logic into a manageable, carrier-grade service capable of sustaining performance in distributed computing environments. To this end, and aligned with the single domain model defined in , this document specifies the OAM framework and requirements for CATS. It establishes a layering OAM model and defines the functional components to monitor the system. Furthermore, it outlines the requirements for fault management and performance monitoring of the CATS service, covering the connection from the client through the network to the final service instance. Specific OAM protocol design, protocol extensions, and inter-domain operations are out of scope.

Requirements Language The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 when, and only when, they appear in all capitals, as shown here.

Terminology This document makes use of the terms defined in and defines the following terms.

CATS Domain:

A single network and compute administrative domain controlled by one service provider, in alignment with the single domain model of the CATS framework.

CS-ID:

CATS Service Identifier, identifier for a CATS service instance.

C-PS:

CATS Path Selector, the component that makes traffic-steering decisions.

C-SMA:

CATS Service Metric Agent, responsible for collecting and reporting service-related metrics.

SI:

Service Instance, instantiated service workload in CATS.

IOAM:

In-situ Operations, Administration, and Maintenance. A mechanism that records OAM and telemetry data in the packet while it traverses a path, as defined in .

In-Band Flow Detection:

A Service OAM mode in which OAM data is carried in, or derived from, service traffic along the actual forwarding path. Representative techniques include data-carrying on-path telemetry (e.g., in-situ OAM) and marking-based passive/hybrid measurement (e.g., Alternate Marking).

Alternate Marking:

A passive or hybrid performance measurement technique that uses a marking bit (e.g., a color bit) to partition service traffic into blocks, enabling measurement of packet loss, delay, and delay variation on live traffic, as defined in .

Push Mode:

A mode of operation where OAM data, after being locally aggregated by the OAM node, is periodically pushed to a receiving entity (e.g., collector, analyzer, or controller) without an explicit request from the receiver.

Pull Mode:

A mode of operation where OAM data is pulled by a receiving entity on-demand, rather than being proactively sent by the OAM node.

Motivation and Problem Statement Existing OAM mechanisms, such as those defined in , are primarily optimized for network-layer connectivity verification and path-level performance monitoring. However, the CATS introduces a multidimensional decision-making process. An OAM framework is required to be capable of perceiving both network transport characteristics and service-level operational capabilities. The primary objective of a CATS-specific OAM framework is to ensure that traffic steering decisions are aligned with the real-time operational status of distributed computing resources. This is critical to prevent "service black-holing" (i.e., traffic reaches a network-reachable node but hits a functionally non-functional service instance), a condition where traffic is steered to a service instance that remains reachable at the network layer, but is functionally unresponsive or degraded at the application level. In the absence of a dedicated OAM framework for CATS, several critical gaps persist:

• Distinguishing Network Reachability from Service Availability: Traditional network OAM protocols (e.g., Bidirectional Forwarding Detection (BFD) , Internet Control Message Protocol (ICMP) , Two-Way Active Measurement Protocol (TWAMP) ) verify the liveness of the routing path and the operational status of the node's IP interface on network nodes. However, these mechanisms operate at the network layer and lack the necessary granularity to assess the health of a specific service instance hosted on a given node. As a result, the CATS Path Selector (C-PS) may continue to direct traffic toward a node that remains network-reachable, even when the application process on that node has crashed, deadlocked, or exhausted its resource limits, ultimately rendering the service unavailable.
• Addressing the Volatility of Computing Metrics: Computing metrics (e.g., CPU utilization, active thread count, and task queue depth) exhibit significantly higher volatility compared to network topology states. Standard control-plane advertisement or polling-based collection mechanisms are often unable to provide the update frequency required to capture such transient spikes (i.e., micro-bursts, transient short-term load spikes), thereby introducing stale telemetry data. This synchronization latency can, in turn, lead to sub-optimal steering decisions, increased traffic flapping, and degraded consistency of client experience.
• Precise Localization of End-to-end Faults: When E2E service degradation occurs (e.g., increased response latency), current OAM tools cannot natively distinguish between network-induced bottlenecks (e.g., path congestion) and compute-induced bottlenecks (e.g., resource exhaustion at the Service Instance (SI)). This ambiguity hampers rapid fault localization, significantly increases the Mean Time to Repair (MTTR), and complicates Service Level Agreement (SLA) enforcement in deployments spanning multi-vendor environments within a single CATS domain.
• Verifying the Network and Computing Metrics: Network metrics (e.g., one-way delay, jitter, packet loss) and computing metrics (e.g., CPU utilization, memory watermark) characterize fundamentally distinct dimensions of service delivery. The verification results serve for the C-PS, ensuring that the computed composite cost accurately reflects the real-time operational status of both the network and computing metrics. Such validation is critical to preserving the determinism and overall reliability of path computation in CATS.

CATS OAM Framework

CATS OAM Layering Model The CATS OAM hierarchical model leverages the principles of Maintenance Domain (MD) levels, as defined in IEEE 802.1ag and ITU-T Y.1731, to extend traditional connectivity and performance management into the computing environment. This framework enables CATS-Forwarders and underlying network nodes to perform integrated anomaly detection and performance monitoring. Based on the scope of awareness and functional granularity, the CATS OAM mechanisms are organized into four distinct layers: Link OAM, Path OAM, Instance OAM, and Service OAM. The architecture is illustrated in Figure 1.

CATS OAM Layering Model

In Figure 1, Service OAM (TRACE) performs hop-by-hop inspection over the forwarding path between ingress CATS-Forwarder and service instance.

• Link OAM: This layer is targeted at the detection of the operational status of physical links or single-hop IP interfaces, serving as the foundational underlay infrastructure in the CATS framework . It covers both internal links within the operator's infrastructure and external interfaces interconnecting network and compute environments. The primary objective is to monitor the health and availability of the link between two adjacent devices, so as to ensure basic IP reachability. Common detection tools include IEEE 802.3ah (Ethernet EFM), ICMP , and single-hop BFD . These tools serve complementary roles: EFM monitors the physical layer status of the Ethernet link, ICMP provides basic reachability verification, and BFD enables rapid failure detection for IP connectivity.
• Path OAM: This layer focuses on the monitoring of the paths between an ingress CATS-Forwarder and an egress CATS-Forwarder in CATS framework . As an aggregate path which typically carries multiple services, Path OAM is critical for ensuring that network-layer faults or resource contention from traffic multiplexing do not degrade specific service performance. Fault detection and performance monitoring are executed at the Label Switched Path (LSP) or Segment Routing (SR) path layer to facilitate rapid service protection. The existing detection mechanisms include ITU-T Y.1711, MPLS Loss and Delay Measurement (LM-DM) , and BFD for LSP.
• Instance OAM: This layer is dedicated to the status monitoring of computing resource and the operational health of service instances in CATS framework . The metrics collected at this layer, such as CPU load and memory availability, are defined in . Monitoring mechanisms MUST support flexible implementation modes, including a Push Mode, where computing nodes report dynamic load status in real-time, and a Pull Mode, where the egress CATS-Forwarder proactively retrieves computing metrics by extending the existing OAM mechanisms. The two modes can be deployed independently or enabled simultaneously.
• Service OAM: This layer provides either E2E or trace performance measurement and fault detection between the ingress CATS-Forwarder and the target SI, as defined in the CATS framework . In addition to basic reachability verification, it is responsible to monitor the service-specific liveness, transaction success rates, and application-layer latency, thereby ensuring consistent end-to-end Quality of Experience (QoE). In trace mode, it can be used for fault localization. The supported mechanisms include active probes, such as TWAMP , STAMP (including optional extensions ), application-aware probing, and HTTP-based health checks, as well as in-band flow detection. In-band flow detection includes both data-carrying on-path telemetry, such as In-situ OAM (IOAM) (see deployment considerations in ), and marking-based passive/hybrid measurement, such as Alternate Marking (coloring) . Active probe mode is suitable for on-demand reachability, liveness verification, and synthetic SLA measurement. In-band flow detection observes or derives OAM data from the actual service traffic along the forwarding path, and is suitable for continuous performance measurement, path/trace correlation, and fault localization when synthetic probes are insufficient or unsuitable. Active probe mode and in-band flow detection mode can be deployed independently or enabled simultaneously. The mechanism set is designed to be extensible to accommodate emerging application-specific requirements.

CATS OAM Components In accordance with Section 5.2 of the CATS framework , the CATS OAM layering model is designed to flexibly accommodate diverse OAM detection mechanisms. As described in Section 5.1, among the four OAM layers, Link OAM and Path OAM are already supported by existing mechanisms. Accordingly, this document proposes two new sets of components corresponding to the remaining two layers, namely, Instance OAM and Service OAM. These two newly introduced components can be integrated, upon deployment, with the existing entities defined in the CATS framework . Furthermore, the specific protocol implementations for Instance OAM and Service OAM are outside the scope of this document. In principle, however, existing protocols and their corresponding extensions should be preferred whenever possible.

Instance OAM Component The Instance OAM component is responsible for monitoring the operational status and computing capabilities of individual service instances. It facilitates granular perception of service instance availability and performance. Its key functions include:

• Status Monitoring: The mechanism is responsible for periodically verifying the availability and operational state (e.g., active, inactive, or maintenance mode) of a specific service instance. This process is executed between an egress CATS-Forwarder and its associated service instance to ensure real-time reachability and prevent traffic from being steered to an unavailable or degraded target.
• Computing Metric Collection: The process is responsible for gathering real-time computing resource telemetry from the service instance or its hosting environment. Relevant metrics are defined in . Note that Instance OAM can also be the data source and enabler for the CATS Service Metric Agent (C-SMA), acting as the measurement executor while C-SMA serves as the information reporter. It provides normalized computing telemetry to the C-SMA. This function ensures that raw resource data is translated into a consistent format to support the dynamic update of computing-aware traffic steering policies within the CATS control plane.

As specified in Section 5.1, Instance OAM supports both Push Mode and Pull Mode. When inconsistencies are detected between the values obtained via the two modes, the system MUST be capable of detecting such inconsistency. This document does not mandate a single conflict resolution strategy, as the optimal approach depends on deployment scenarios. It is RECOMMENDED to log inconsistency events before applying any resolution actions. Instance OAM does not instrument application-internal logic. It monitors the operational status and computing resource telemetry exposed by the service instance or its hosting environment (e.g., VM, container, or orchestrator). Instance OAM does not inspect application payload or internal business logic; it only consumes monitoring data exposed by platform interfaces. Active probes from the egress CATS-Forwarder verify endpoint liveness and reachability, not application-internal behavior. In virtualized environments, computing metrics are collected via platform management interfaces or sidecar agents, rather than by probing application internals.

Service OAM Component The Service OAM component provides E2E visibility and performance assessment for a CATS service across the entire delivery path, originating from an ingress CATS-Forwarder to the target service instances. Its key functions include:

• Policy Verification: Ensuring that the actual traffic forwarding path from the ingress CATS-Forwarder to the selected service instance aligns with the steering decisions made by the C-PS.
• Joint Performance Measurement: Measuring E2E performance metrics, such as total latency (the sum of network transmission time and service processing time) and jitter, to verify SLA compliance.
• Multi-Layer Fault Isolation: Correlating Link OAM, Path OAM, Instance OAM, and Service OAM within a single CATS domain to differentiate whether service degradation is caused by network transport bottlenecks (e.g., path congestion, link failure) or computing resource exhaustion (e.g., CPU saturation, memory depletion) at the Service Instance.

CATS OAM Workflows and Mechanisms Considerations This section provides a non-exhaustive mapping of candidate mechanisms considerations per OAM layer and illustrates how Instance OAM and Service OAM function together to enable CATS-specific fault isolation and policy verification.

Layer	Example mechanisms	Primary data/consumer
Link OAM	EFM, ICMP, single-hop BFD	Link state, reachability
Path OAM	Y.1711, MPLS LM/DM, BFD-LSP	Path loss/delay, path state
Instance OAM	Active liveness probe, Telemetry pull/push	SI state, CPU/mem/queue, reported to C-SMA
Service OAM	TWAMP, STAMP, HTTP-based health check, Application-aware probe; In-band: IOAM, Alternate Marking (coloring); Trace mode	E2E latency/loss, policy verification, localization

• Instance OAM Workflow: The egress CATS-Forwarder maintains the binding between the CS-ID and the target service instance endpoint, verifies the SI liveness, and collects computing metrics. The collected metrics are normalized and reported to the C-SMA, which makes them available to the C-PS. If Push Mode and Pull Mode yield inconsistent values, the SI SHOULD be marked as requiring revalidation and the inconsistency SHOULD be reported. This document does not specify revalidation timer values; revalidation timing is implementation- and configuration-driven.
• Service OAM Workflow: In active probe mode, the ingress CATS-Forwarder sends a Service OAM probe carrying the CS-ID toward the selected service instance. The probe follows the same steering policy as the service traffic. In in-band flow detection mode, OAM data is carried in, or derived from, the actual service traffic along the same path. For IOAM, telemetry data is recorded in the packet as it traverses the path; for Alternate Marking, service packets are marked/colored to form blocks, enabling passive or hybrid measurement of loss, delay, and delay variation on live traffic. E2E latency, jitter, loss, and service liveness are measured and compared with the SLA and the C-PS decision. When degradation is detected, Link OAM, Path OAM, Instance OAM, and Service OAM results are correlated by timestamp and CS-ID to classify the fault as network-induced, compute-induced, or compound.
• Forwarding Consistency Check: The OAM system compares the actual forwarding path and target SI with the C-PS decision. Any mismatch between the intended steering policy and the observed forwarding state MUST trigger an alarm and re-synchronization, as specified in Section 6.3 (M-REQ-3).

CATS OAM Requirements This section specifies the OAM requirements for CATS, adhering to the operational and management guidelines defined in . CATS OAM must bridge the gap between traditional network connectivity checks and the awareness of computing resource availability.

Operation The operation requirements include the generating and collecting metrics, as well as real-time reporting of the combined network and computing status.

• O-REQ-1: Multi-Dimensional Status Monitoring. The system MUST support the collection of both network metrics (latency, jitter, packet loss) and computing metrics (e.g., processing capacity, load, and availability) defined in . To balance precision and control plane overhead, the system SHOULD support both periodic and threshold-triggered reporting.
• O-REQ-2: Service ID and Location Mapping. The OAM component MUST maintain the binding between a Service ID (representing the service instance) and its specific network location (e.g., egress CATS-Forwarder). OAM mechanisms MUST be able to target or associate with specific service instances to verify that the traffic steering policy correctly reaches the intended destination.
• O-REQ-3: Telemetry Integration with C-SMA. All collected computing metrics SHOULD be reported to the C-SMA. This ensures that the C-PS has access to synchronized telemetry to perform real-time path computation and selection.
• O-REQ-4: Computing Metric Freshness Handling. Computing metrics SHOULD be accompanied by timestamps indicating the time of collection. This enables the C-SMA or C-PS to optionally configure a maximum acceptable staleness threshold for each metric type to determine subsequent handling.

Administration The administration requirements include policy definition, security boundary enforcement, and the configuration of steering behaviors.

• A-REQ-1: Policy-Based Steering Configuration. The system MUST allow administrators to define CATS-specific policies, such as weighting factors for network vs. computing metrics. These policies dictate how the C-PS interprets raw telemetry when calculating the "best" service instance.
• A-REQ-2: Differentiated Monitoring Intensity. Based on the SLA, the system SHOULD support variable OAM intensities. High-priority services (e.g., autonomous driving or remote surgery) may require millisecond-level BFD-like monitoring, while standard web services use lower-frequency heartbeats.
• A-REQ-3: Security and Metric Integrity. Reporting of computing and network metrics MUST be protected via encryption and authentication. This prevents malicious actors from injecting "fake" high-performance metrics to attract and intercept traffic (sinkhole attacks) or triggering oscillations in the CATS-Forwarder.

Maintenance The maintenance requirements include fault isolation, performance backtracking, and steering state consistency assurance.

• M-REQ-1: Joint Fault Demarcation. The system MUST be able to distinguish whether a service failure is caused by a network-layer issue (e.g., connectivity loss between CATS-Forwarders) or computing resource exhaustion at the Service Instance. This requires the correlation of multi-layer OAM data, including Link OAM, Path OAM, Instance OAM, and Service OAM, to accurately isolate the fault type.
• M-REQ-2: Historical Traceability. The OAM system SHOULD record historical snapshots of both network paths and computing status. This is critical for post-mortem analysis of "flapping" steering decisions where traffic frequently oscillates between different service instances.
• M-REQ-3: Forwarding Plane Consistency Check. The system MUST provide mechanisms to verify that the actual traffic path taken by a packet matches the decision made by the C-PS. Any inconsistency between the intended steering policy and the actual forwarding state MUST trigger an immediate alarm and re-synchronization.

CATS OAM Deployment Consideration

Deployment Locations Service OAM: Primarily deployed between the ingress CATS-Forwarder and the target Service Instance, providing end-to-end service quality measurement. In specific scenarios (e.g., fault localization), deployment or cooperative probing at intermediate nodes such as the egress CATS-Forwarder may be performed as appropriate. Instance OAM: Deployed between the egress CATS-Forwarder and its associated service instances. Its deployment modes are classified into active and passive:

• Active mode: The OAM originator resides at the egress CATS-Forwarder, while the reflector resides at the service instance.
• Passive mode: The deployment endpoint (either the egress CATS-Forwarder or the service instance) may be flexibly selected according to the specific implementation.

Configuration Parameters The specific configuration requirements for Service OAM are as follows:

• SLA Target Parameters: Define explicit performance objectives (e.g., latency, packet loss rate, throughput) for end-to-end paths, serving as the basis for policy verification and alarm triggering.
• Service ID Mapping: OAM mechanisms (e.g., active probes or in-band flow detection) MUST be associated with a distinct CATS Service Identifier (CS-ID) to ensure that OAM measurement is fully aligned with service traffic, thereby enabling verification of the correctness of CATS traffic policies. For in-band flow detection, the CS-ID may be associated through flow classification, encapsulation, or other binding mechanisms, which are outside the scope of this document.

The specific configuration requirements for Instance OAM are as follows:

• Instance Location and Identification: Configure the network address (IP address, port number, etc.) of the target Service Instance as the destination for OAM probing.
• Compute Metric Collection Policy: Configure the collection granularity (e.g., collection interval, sampling period) and reporting mode (Push or Pull) for compute resource metrics including CPU, GPU, and memory.

Security Considerations This section covers OAM-specific security. General CATS threats are addressed in .

Protection of OAM Metric Reporting Channel Per Section 6.2 (A-REQ-3), OAM implementations follow the metric security mechanisms:

• All OAM metric reports (e.g., Service OAM and Instance OAM) MUST be authenticated and integrity-protected.
• The reporting channel SHOULD provide confidentiality for sensitive information (e.g., service instance locations).
• OAM control messages MUST be protected against replay attacks.

OAM-Specific Considerations

• When in-band flow detection is employed for Service OAM, it MUST NOT leak any client-identifiable information. For IOAM, implementations SHOULD adhere to the security guidelines, including integrity and encryption, as specified in . For Alternate Marking, the marking bits and associated measurement data SHOULD be protected against tampering that could falsify loss or delay results.
• OAM systems SHOULD collect only metrics necessary for the telemetry purpose.

IANA Considerations This document does not currently require any IANA actions.

Acknowledgements The authors would like to thank Adrian Farrel, Peng Liu, Erum Welling, Cheng Li, Guanming Zeng, Haomian Zheng, Chuanyang Miao, Bin Zhang, Xueyan Mao, Jipeng Zhang and Shuai Zhang for their review, suggestions and comments to this document.

References Normative References This document describes a framework for Computing-Aware Traffic Steering (CATS). Specifically, the document identifies a set of CATS functional components, describes their interactions, and provides illustrative workflows of the control and data planes. The framework covers only the case of a single service provider. Distributed computing enhances service response time and energy efficiency by utilizing diverse computing facilities for compute-intensive and delay-sensitive services. To optimize throughput and response time, Computing-Aware Traffic Steering (CATS) selects servers and directs traffic based on compute capabilities and resources, rather than static dispatch or connectivity metrics alone. This document outlines the problem statement and scenarios for CATS within a single domain and drives requirements for the CATS framework. Informative References

Contributors ZTE Corporation

huang.guangping@zte.com.cn

ZTE Corporation

huang.cheng13@zte.com.cn

ZTE Corporation

duan.wei1@zte.com.cn