Computing-Aware Traffic Steering (CATS) Operations, Administration, and Maintenance (OAM) Framework
draft-ietf-cats-oam-fw-01

CATS                                                               H. Fu
Internet-Draft                                                  Q. Xiong
Intended status: Informational                           ZTE Corporation
Expires: 22 January 2027                                           Z. Du
                                                                  B. Liu
                                                                   Z. Li
                                                            China Mobile
                                                            21 July 2026

Computing-Aware Traffic Steering (CATS) Operations, Administration, and
                      Maintenance (OAM) Framework
                       draft-ietf-cats-oam-fw-01

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.

Copyright Notice

   Copyright (c) 2026 IETF Trust and the persons identified as the
   document authors.  All rights reserved.

Fu, et al.               Expires 22 January 2027                [Page 1]
Internet-Draft   Computing-Aware Traffic Steering (CATS)       July 2026

   This document is subject to BCP 78 and the IETF Trust's Legal
   Provisions Relating to IETF Documents (https://trustee.ietf.org/
   license-info) in effect on the date of publication of this document.
   Please review these documents carefully, as they describe your rights
   and restrictions with respect to this document.  Code Components
   extracted from this document must include Revised BSD License text as
   described in Section 4.e of the Trust Legal Provisions and are
   provided without warranty as described in the Revised BSD License.

Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   2
   2.  Requirements Language . . . . . . . . . . . . . . . . . . . .   3
   3.  Terminology . . . . . . . . . . . . . . . . . . . . . . . . .   3
   4.  Motivation and Problem Statement  . . . . . . . . . . . . . .   4
   5.  CATS OAM Framework  . . . . . . . . . . . . . . . . . . . . .   5
     5.1.  CATS OAM Layering Model . . . . . . . . . . . . . . . . .   5
     5.2.  CATS OAM Components . . . . . . . . . . . . . . . . . . .   7
       5.2.1.  Instance OAM Component  . . . . . . . . . . . . . . .   7
       5.2.2.  Service OAM Component . . . . . . . . . . . . . . . .   8
   6.  CATS OAM Requirements . . . . . . . . . . . . . . . . . . . .   8
     6.1.  Operation . . . . . . . . . . . . . . . . . . . . . . . .   9
     6.2.  Administration  . . . . . . . . . . . . . . . . . . . . .   9
     6.3.  Maintenance . . . . . . . . . . . . . . . . . . . . . . .  10
   7.  CATS OAM Deployment Consideration . . . . . . . . . . . . . .  10
     7.1.  Deployment Locations  . . . . . . . . . . . . . . . . . .  10
     7.2.  Configuration Parameters  . . . . . . . . . . . . . . . .  11
   8.  Security Considerations . . . . . . . . . . . . . . . . . . .  11
     8.1.  Protection of OAM Metric Reporting Channel  . . . . . . .  11
     8.2.  OAM-Specific Considerations . . . . . . . . . . . . . . .  12
   9.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .  12
   10. Acknowledgements  . . . . . . . . . . . . . . . . . . . . . .  12
   11. References  . . . . . . . . . . . . . . . . . . . . . . . . .  12
     11.1.  Normative References . . . . . . . . . . . . . . . . . .  12
     11.2.  Informative References . . . . . . . . . . . . . . . . .  13
   Contributors  . . . . . . . . . . . . . . . . . . . . . . . . . .  14
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  15

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.

Fu, et al.               Expires 22 January 2027                [Page 2]
Internet-Draft   Computing-Aware Traffic Steering (CATS)       July 2026

   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.

Fu, et al.               Expires 22 January 2027                [Page 3]
Internet-Draft   Computing-Aware Traffic Steering (CATS)       July 2026

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:

   *  Distinguishing Network Reachability from Service Availability:
      Traditional network OAM protocols (e.g., Bidirectional Forwarding
      Detection (BFD) [RFC5880], Internet Control Message
      Protocol(ICMP) [RFC4443], Two-Way Active Measurement Protocol
      (TWAMP) [RFC5357]) 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), 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.

Fu, et al.               Expires 22 January 2027                [Page 4]
Internet-Draft   Computing-Aware Traffic Steering (CATS)       July 2026

   *  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 multi-
      domain or multi-vendor environments.

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

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

Fu, et al.               Expires 22 January 2027                [Page 5]
Internet-Draft   Computing-Aware Traffic Steering (CATS)       July 2026

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

Fu, et al.               Expires 22 January 2027                [Page 6]
Internet-Draft   Computing-Aware Traffic Steering (CATS)       July 2026

   *  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

Fu, et al.               Expires 22 January 2027                [Page 7]
Internet-Draft   Computing-Aware Traffic Steering (CATS)       July 2026

      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.

Fu, et al.               Expires 22 January 2027                [Page 8]
Internet-Draft   Computing-Aware Traffic Steering (CATS)       July 2026

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.

Fu, et al.               Expires 22 January 2027                [Page 9]
Internet-Draft   Computing-Aware Traffic Steering (CATS)       July 2026

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

Fu, et al.               Expires 22 January 2027               [Page 10]
Internet-Draft   Computing-Aware Traffic Steering (CATS)       July 2026

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

Fu, et al.               Expires 22 January 2027               [Page 11]
Internet-Draft   Computing-Aware Traffic Steering (CATS)       July 2026

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,
              15 March 2026, <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, 2 April 2026,
              <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, 15
              May 2026, <https://datatracker.ietf.org/doc/html/draft-
              ietf-cats-metric-definition-08>.

Fu, et al.               Expires 22 January 2027               [Page 12]
Internet-Draft   Computing-Aware Traffic Steering (CATS)       July 2026

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119,
              DOI 10.17487/RFC2119, March 1997,
              <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, September 2006,
              <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, June 2014,
              <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,
              May 2017, <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,
              July 2018, <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, March 2020,
              <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, April 2023,
              <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, 2 March 2026, <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

Fu, et al.               Expires 22 January 2027               [Page 13]
Internet-Draft   Computing-Aware Traffic Steering (CATS)       July 2026

              Statement, Use Cases, and Requirements", Work in Progress,
              Internet-Draft, draft-ietf-cats-usecases-requirements-14,
              2 February 2026, <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, March 2006,
              <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, October 2008,
              <https://www.rfc-editor.org/rfc/rfc5357>.

   [RFC5880]  Katz, D. and D. Ward, "Bidirectional Forwarding Detection
              (BFD)", RFC 5880, DOI 10.17487/RFC5880, June 2010,
              <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, June 2010,
              <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, September 2011,
              <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,
              May 2022, <https://www.rfc-editor.org/info/rfc9197>.

   [RFC9522]  Farrel, A., Ed., "Overview and Principles of Internet
              Traffic Engineering", RFC 9522, DOI 10.17487/RFC9522,
              January 2024, <https://www.rfc-editor.org/info/rfc9522>.

Contributors

   Daniel Huang
   ZTE Corporation
   Email: huang.guangping@zte.com.cn

   Cheng Huang
   ZTE Corporation

Fu, et al.               Expires 22 January 2027               [Page 14]
Internet-Draft   Computing-Aware Traffic Steering (CATS)       July 2026

   Email: huang.cheng13@zte.com.cn

   Wei Duan
   ZTE Corporation
   Email: duan.wei1@zte.com.cn

Authors' Addresses

   Huakai Fu
   ZTE Corporation
   Email: fu.huakai@zte.com.cn

   Quan Xiong
   ZTE Corporation
   Email: xiong.quan@zte.com.cn

   Zongpeng Du
   China Mobile
   Email: duzongpeng@chinamobile.com

   Bo Liu
   China Mobile
   Email: liubo@chinamobile.com

   Zhenqiang Li
   China Mobile
   Email: lizhenqiang@chinamobile.com

Fu, et al.               Expires 22 January 2027               [Page 15]