Internet-Draft Computing-Aware Traffic Steering (CATS) July 2026
Fu, et al. Expires 22 January 2027 [Page]
Workgroup:
CATS
Internet-Draft:
draft-ietf-cats-oam-fw-01
Published:
Intended Status:
Informational
Expires:
Authors:
H. Fu
ZTE Corporation
Q. Xiong
ZTE Corporation
Z. Du
China Mobile
B. Liu
China Mobile
Z. Li
China Mobile

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

Abstract

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.

Status of This Memo

This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.

Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet-Drafts is at https://datatracker.ietf.org/drafts/current/.

Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress."

This Internet-Draft will expire on 22 January 2027.

▲

Table of Contents

1. Introduction

As described in [I-D.ietf-cats-usecases-requirements], 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) [I-D.ietf-cats-framework] provides a traffic engineering approach [RFC9522] 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 from a theoretical steering logic into a manageable, carrier-grade service capable of sustaining performance in distributed computing environments.

To this end, and aligned with the architecture defined in [I-D.ietf-cats-framework], 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 and extensions are out of scope.

2. 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 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here.

3. Terminology

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

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.

4. Motivation and Problem Statement

Existing OAM mechanisms, such as those defined in [RFC7276], are primarily optimized for network-layer connectivity verification and path-level performance monitoring. However, the CATS [I-D.ietf-cats-framework] 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," 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:

5. CATS 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 domain. 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

              Figure 1: CATS OAM Layering Model

  • 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 [I-D.ietf-cats-framework]. It covers both internal links within the operator's infrastructure and external interfaces interconnecting network and compute domains. 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 [I-D.ietf-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 [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 [I-D.ietf-cats-framework]. 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.

  • 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 [I-D.ietf-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 detection mechanisms include the TWAMP [RFC5357], application-aware probing, and HTTP-based health checks. 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 [I-D.ietf-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 [I-D.ietf-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 prefered whenever possible.

5.2.1. Instance OAM Component

The Instance OAM component is responsible for monitoring the operational status and computing capabilities of individual service instances. It facilitates the granular perception of service instances 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  [I-D.ietf-cats-metric-definition]. 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. The capability is to provide 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.

5.2.2. 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-Router 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-Domain Fault Isolation: Correlating Link OAM, Path OAM, Instance OAM, and Service OAM to differentiate whether service degradation is caused by network congestion or computing resource exhaustion.

6. CATS OAM Requirements

This section specifies the OAM requirements for CATS, adhering to the operational and management guidelines defined in [I-D.draft-ietf-opsawg-rfc5706bis]. CATS OAM must bridge the gap between traditional network connectivity checks and the awareness of computing resource availability.

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 Mornitoring. 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 probes MUST be able to target 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 domain.

  • 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. CATS OAM Deployment Consideration

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 test packets carry a distinct CATS Service Identifier (CS-ID) to ensure that probing paths are fully aligned with service traffic, thereby enabling verification of the correctness of CATS traffic policies.

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

This section covers OAM-specific security. General CATS threats are addressed in [I-D.draft-wang-cats-security-considerations].

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 infomation (e.g., service instance locations).

  • OAM control messages must be protected against replay attacks.

8.2. OAM-Specific Considerations

  • When IOAM is employed for on-path OAM, it must not leak any client-identifiable information. Furthermore, implementations should adhere to the security guidelines, including integrity and encryption, as specified in [RFC9197].

  • OAM systems should collect only metrics necessary for the telemetry purpose.

9. IANA Considerations

This document does not currently require any IANA actions.

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

11. References

11.1. Normative References

[I-D.draft-ietf-opsawg-rfc5706bis]
Claise, B., Clarke, J., Farrel, A., Barguil, S., Pignataro, C., and R. Chen, "Guidelines for Considering Operations and Management in IETF Specifications", Work in Progress, Internet-Draft, draft-ietf-opsawg-rfc5706bis-04, , <https://datatracker.ietf.org/doc/html/draft-ietf-opsawg-rfc5706bis-04>.
[I-D.ietf-cats-framework]
Li, C., Du, Z., Boucadair, M., Contreras, L. M., and J. Drake, "A Framework for Computing-Aware Traffic Steering (CATS)", Work in Progress, Internet-Draft, draft-ietf-cats-framework-24, , <https://datatracker.ietf.org/doc/html/draft-ietf-cats-framework-24>.
[I-D.ietf-cats-metric-definition]
Yao, K., Li, C., Contreras, L. M., Ros-Giralt, J., and G. Zeng, "CATS Metrics Definition", Work in Progress, Internet-Draft, draft-ietf-cats-metric-definition-08, , <https://datatracker.ietf.org/doc/html/draft-ietf-cats-metric-definition-08>.
[RFC2119]
Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, , <https://www.rfc-editor.org/rfc/rfc2119>.
[RFC4656]
Shalunov, S., Teitelbaum, B., Karp, A., Boote, J., and M. Zekauskas, "A One-way Active Measurement Protocol (OWAMP)", RFC 4656, DOI 10.17487/RFC4656, , <https://www.rfc-editor.org/rfc/rfc4656>.
[RFC7276]
Mizrahi, T., Sprecher, N., Bellagamba, E., and Y. Weingarten, "An Overview of Operations, Administration, and Maintenance (OAM) Tools", RFC 7276, DOI 10.17487/RFC7276, , <https://www.rfc-editor.org/rfc/rfc7276>.
[RFC8174]
Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, , <https://www.rfc-editor.org/rfc/rfc8174>.
[RFC8402]
Filsfils, C., Ed., Previdi, S., Ed., Ginsberg, L., Decraene, B., Litkowski, S., and R. Shakir, "Segment Routing Architecture", RFC 8402, DOI 10.17487/RFC8402, , <https://www.rfc-editor.org/rfc/rfc8402>.
[RFC8754]
Filsfils, C., Ed., Dukes, D., Ed., Previdi, S., Leddy, J., Matsushima, S., and D. Voyer, "IPv6 Segment Routing Header (SRH)", RFC 8754, DOI 10.17487/RFC8754, , <https://www.rfc-editor.org/rfc/rfc8754>.
[RFC9378]
Brockners, F., Ed., Bhandari, S., Ed., Bernier, D., and T. Mizrahi, Ed., "In Situ Operations, Administration, and Maintenance (IOAM) Deployment", RFC 9378, DOI 10.17487/RFC9378, , <https://www.rfc-editor.org/rfc/rfc9378>.

11.2. Informative References

[I-D.draft-wang-cats-security-considerations]
Shi, J., Wang, C., and Y. Fu, "Security Considerations for Computing-Aware Traffic Steering", Work in Progress, Internet-Draft, draft-wang-cats-security-considerations-04, , <https://datatracker.ietf.org/doc/html/draft-wang-cats-security-considerations-04>.
[I-D.ietf-cats-usecases-requirements]
Yao, K., Contreras, L. M., Shi, H., Zhang, S., and Q. An, "Computing-Aware Traffic Steering (CATS) Problem Statement, Use Cases, and Requirements", Work in Progress, Internet-Draft, draft-ietf-cats-usecases-requirements-14, , <https://datatracker.ietf.org/doc/html/draft-ietf-cats-usecases-requirements-14>.
[RFC4443]
Conta, A., Deering, S., and M. Gupta, Ed., "Internet Control Message Protocol (ICMPv6) for the Internet Protocol Version 6 (IPv6) Specification", STD 89, RFC 4443, DOI 10.17487/RFC4443, , <https://www.rfc-editor.org/rfc/rfc4443>.
[RFC5357]
Hedayat, K., Krzanowski, R., Morton, A., Yum, K., and J. Babiarz, "A Two-Way Active Measurement Protocol (TWAMP)", RFC 5357, DOI 10.17487/RFC5357, , <https://www.rfc-editor.org/rfc/rfc5357>.
[RFC5880]
Katz, D. and D. Ward, "Bidirectional Forwarding Detection (BFD)", RFC 5880, DOI 10.17487/RFC5880, , <https://www.rfc-editor.org/rfc/rfc5880>.
[RFC5881]
Katz, D. and D. Ward, "Bidirectional Forwarding Detection (BFD) for IPv4 and IPv6 (Single Hop)", RFC 5881, DOI 10.17487/RFC5881, , <https://www.rfc-editor.org/rfc/rfc5881>.
[RFC6374]
Frost, D. and S. Bryant, "Packet Loss and Delay Measurement for MPLS Networks", RFC 6374, DOI 10.17487/RFC6374, , <https://www.rfc-editor.org/rfc/rfc6374>.
[RFC9197]
Brockners, F., Ed., Bhandari, S., Ed., and T. Mizrahi, Ed., "Data Fields for In Situ Operations, Administration, and Maintenance (IOAM)", RFC 9197, DOI 10.17487/RFC9197, , <https://www.rfc-editor.org/info/rfc9197>.
[RFC9522]
Farrel, A., Ed., "Overview and Principles of Internet Traffic Engineering", RFC 9522, DOI 10.17487/RFC9522, , <https://www.rfc-editor.org/info/rfc9522>.

Contributors

Daniel Huang
ZTE Corporation
Cheng Huang
ZTE Corporation
Wei Duan
ZTE Corporation

Authors' Addresses

Huakai Fu
ZTE Corporation
Quan Xiong
ZTE Corporation
Zongpeng Du
China Mobile
Bo Liu
China Mobile
Zhenqiang Li
China Mobile