Computing-Aware Traffic Steering (CATS) Operations, Administration, and Maintenance (OAM) Framework

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

      +------+ +------------+   +----------+   +-----------+   +--------+
      |client+-+  CATS-     +---+underlay  +---+  CATS-    +---+service |
      |      | | Forwarder 1|   |  nodes   |   |Forwarder 2|   |instance|
      +------+ +------------+   +----------+   +-----------+   +--------+
               o-------------------- Service OAM(E2E)  ---------------o
               o------------o---o--- Service OAM(TRACE)--o---o--------o
                                             o---- Instance OAM ------o
               o--------------- Path OAM ----------------o
                            o---o        o---o           o---o Link OAM

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 [RFC10053]. 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 [RFC4443], and single-hop BFD [RFC5881]. 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 [RFC10053]. 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 [RFC8402] to facilitate rapid service protection. The existing detection mechanisms include ITU-T Y.1711, MPLS Loss and Delay Measurement (LM-DM) [RFC6374], 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 [RFC10053]. The metrics collected at this layer, such as CPU load and memory availability, are defined in [I-D.ietf-cats-metric-definition]. 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 [RFC10053]. 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 [RFC5357], STAMP [RFC8762] (including optional extensions [RFC8972]), 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) [RFC9197] (see deployment considerations in [RFC9378]), and marking-based passive/hybrid measurement, such as Alternate Marking (coloring) [RFC8321]. 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.¶

5.2. CATS OAM Components

In accordance with Section 5.2 of the CATS framework [RFC10053], 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 [RFC10053]. 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.¶

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

• 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).¶

6.1. 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 [I-D.ietf-cats-metric-definition]. 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.¶

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

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

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

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

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

8.2. 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 [RFC9197]. 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.¶