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

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 13 April 2026.¶

Copyright Notice

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

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

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

Compute-aware traffic steering (CATS) [I-D.ietf-cats-framework] is a traffic engineering approach as per [I-D.ietf-teas-rfc3272bis] developed to address the aforementioned traffic steering problem. This approach takes into account the dynamic nature of both the computing resources and the network states to optimize the way that traffic is forwarded towards a given service instance. Various metrics can be taken into account to devise and enforce such service-specific and computing-aware traffic steering policies.To achieve better service assurance, it is necessary to not only rapidly detect whether the QoS provided by the computing networks meets the SLA requirements of clients, but also dynamically trigger the calculation and the adjustment of both the computing and the networking services. There are some OAM technologies developed for networks, but they are only deployed to facilitate the operations and the maintenance of network operators, and cannot provide measurements of an end-to-end connection from a client to a service instance.¶

To this end, based on the CATS framework as per [I-D.ietf-cats-framework], this document describes the OAM framework and requirements for Computing-Aware Traffic Steering (CATS). The framework defines the CATS OAM layering model and OAM components. It also describes the requirements to enable the fault and the performance management of end-to-end connections from clients to networks and finally to services instances.The deployment considerations are also described as well.¶

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

• FM: Fault Management.¶

• PM: Performance Monitoring.¶

• SI-OAM: Service Instance OAM.¶

• TC-OAM: Traffic Classifier OAM.¶

• AF-OAM: Application Flow OAM.¶

• IOAM: In-situ OAM.¶

4. Motivation

The main objectives of OAM are to detect anomalies before they intensify, reduce the number of traffic flows impacted by these abnormalities, and ensure that network operators fulfill their QoS guarantee commitments to meet the Service Level Agreement(SLA) of clients.¶

As a traffic engineering method, computing-aware traffic steering (CATS) takes into account the dynamic nature of both the computing resources and the network states to optimize the way that traffic is forwarded toward a given service instance. However, existing OAM technologies cannot be used to collect metrics associated with the computing resources. Therefore, it is necessary to extend the existing OAM technologies to build an end-to-end OAM for CATS. Key objectives include:¶

• Convergence latency is compressed from the order of tens of seconds to sub-second timescale: In CATS,the status information of the computing instances is collected by the CATS Service Metric Agent (C-SMA) component and processed at the control plane for performance monitoring and failure detection. However, to limit control-plane load, such sensing mechanisms are typically engineered to operate on the order of tens of seconds.. Accordingly, rapid detection of data-plane degradation affecting both service instances and network states is mandatory, so that CATS Path Selector (C-PS) convergence is triggered and its latency compressed from tens of seconds to sub-second scale.¶

• Closed-loop network path evaluation : In CATS, the CATS Path Selector (C-PS) calculates and selects the paths towards appropriate egress PEs and computing service instances. In this process, it is necessary to verify whether the calculation and the selection results meet the SLA requirements of clients taking into account both the network states and the computing instance status.¶

• Closed-loop service SLAs guarantee for flows : In CATS, subsequent packets of service flows in an established session are forwarded through the CATS Traffic Classifier (C-TC) to the same service instance. However, during such a process, the computing/network performance may degrade. To ensure consistent experience for end users, it is necessary to measure the flow-level performance of service instances and make appropriate adjustments, e.g., change segments of routing paths or enable backup paths, according to the SLA requirements.¶

• Fault delimiting and troubleshooting: When user experience deteriorates, it is necessary to rapidly locate the fault on the end-to-end path from the user terminal through the network to the service instance to implement fast end-to-end fault location and troubleshooting.¶

5. CATS OAM Framework

  +------+ +--+--------+    +---+----+   +--------+--+ +--------+
  |client+-+  CATS-    +----+underlay+---+  CATS-    +-+service |
  |      | |Forwarder 1|    |  node  |   |Forwarder 2| |instance|
  +------+ +-----------+    +--------+   +-----------+ +----+---+

           o------------- Service OAM -----------o---------------o

           o------------- Tunnel OAM -----------o

                      o----o      o----o       o----o    Link OAM

                Figure 1: CATS OAM Layering Model

  +------+ +--+--------+    +---+----+   +--------+--+ +--------+
  |client+-+  CATS-    +----+underlay+---+  CATS-    +-+service |
  |      | |Forwarder 1|    |  node  |   |Forwarder 2| |instance|
  +------+ +-----------+    +--------+   +-----------+ +----+---+
      ^       ^                                   ^         |
      |       |                                   |         |
      |       |                               +---+----+    |
      |       |                               | SI_OAM |<-->|
      |    +--+-----+                         +--------+    |
      |    | TC_OAM |<------------------------------------->|
      |    +--+-----+                                       |
      |       |                                             |
      |    +--+-----+                                       |
      +----+ AF_OAM |<------------------------------------->|
           +--+-----+


              Figure 2: CATS OAM Functional Components

6. CATS OAM Requirements

7. Deployment Considerations

To demonstrate the complete CATS OAM procedure, a proper OAM detection tool needs to be selected and deployed on the network and service instance hosts of the CATS OAM architecture. The selection of OAM detection tools is out of the scope of this document.¶

                             +-------------------------+
                  +--------------+ Intelligent controller  +-------------+
                  |              +-------------------+-----+             |
                  |                                   |                  |
                  v                                   v                  v
            +-----------+                        +-----------+       +--------+
            |  CATS-    |                        |  CATS-    |       |  Edge  |
            |Forwarder 1|                        |Forwarder 2|       |  Site  |
            |           |                        |           |Service|        |
+--------+  |+---------+|                        |+---------+|Metrics|S-ID 1  |
| client |  ||  C-PS   ||       +--------+       ||  C-SMA  |<-------|SI-ID 1 |
|        |  |+---------+|Network|        |Network|+---------+|       |        |
|+------+|  |  ^    ^   |Metrics|Underlay|Metrics|       ^   |       |S-ID 1  |
||AF-OAM|+--+  |    |   |<------+ domain |<------|       |   |-------|SI-ID 2 |
|+--+---+|  |  |    |   |       +--------+       |   +---+--+| OWAMP |        |
|   |    |  |  |    |   |                        |   |SI-OAM|<------>|S-ID 2  |
+---+----+  |  |+---+--+|           OWAMP        |   +------+|       |SI-ID 1 |
    |       |  ||TC-OAM|+------------------------+-----------+------>|        |
    |       |  |+------+|                        |           |       |S-ID 2  |
    |       | ++-------+|           IOAM         |           |       |SI-ID 2 |
    |       | | AF-OAM |+------------------------+-----------+------>|        |
    |       | +--------+|           IOAM         |           |       |        |
    +-------+-----------+------------------------+-----------+------>|        |
            +-----------+                        +-----------+       +--------+

             Figure 3: An Example Of CATS OAM Deployment

As illustrated in Fig. 3, the OWAMP and the IOAM tools are selected as examples to describe how the CATS OAM component works with these detection tools to fulfill the four objectives :¶

• Convergence latency is compressed from the order of tens of seconds to sub-second timescale: The SI-OAM component is deployed on the CATS-Forwarder 2 and the OWAMP tool is used to measure the delay and packet loss from the CATS-Forwarder 2 to the associated service instance. The source and the destination IP of the detection packets are the CATS-Forwarder 2 interface IP and the service instance IP, respectively.According to the returned packets, the status and the metrics of both the service instance and the network that connects the service instance with the clients are obtained. The SI-OAM component feeds back the measurement results to the C-SMA component, which further spreads the computing resource information in the CATS network to accelerate CATS Path Selector(C-PS) convergence to avoid black holes.¶

• Closed-loop network SLA guarantee: The TC-OAM component is deployed on the CATS-Forwarder 1 and the OWAMP tool is used to measure the delay and packet loss from the CATS-Forwarder 1 to the associated service instance. To ensure OWAMP packets are delivered according to the table item of TC, the source and the destination IP addresses of the detection packets are set to the IP address of the interface of CATS-Forwarder 1 and the IP address corresponding to the service ID, respectively. OWAMP packets usually pass through the tunnel to the egress network and are forwarded to the service instance. According to the returned OWAMP packets, the TC-OAM obtains the measurement results and feeds back the results to the C-PS component. If the measurement results deviate from the expected SLAs, recalculation is triggered to fulfill the closed-loop network SLA guarantee for the service ID.¶

• Closed-loop SLA guarantee for service flow: for service flows that have been initiated, the flow affinity function is executed to guarantee that subsequent packets reach the same service instance as the first packet. To conduct measuring and performance monitoring for the entire end-to-end flows, the flow-based detection tool such as IOAM is selected and the AF-OAM component is deployed on the CATS-Forwarder 1. Note that the PostCard or the PassPort modes are generally used in the flow-based detection and a centralized collector is required to obtain the measurement results and feed the results back to the C-PS. The network path can be adjusted according to the difference between the OAM measurement results and the SLA requirements to ensure a consistent user experience.¶

• Service fault delimiting and troubleshooting: For fast delimitation and troubleshooting under user experience degradation, the AF-OAM component can be deployed on a user terminal when a flow detection tool such as IOAM is performed.The IOAM can use the postcard mode and can directly report the location where packet loss or longer delay occurs according to the measurement results obtained by a centralized collector. This is a typical scenario of IOAM, and details are not described herein.¶

For different detection targets, flexible choices of detection protocols and mechanisms can be made, which will not be elaborated upon here.¶

8. Security Considerations

To be discussed in future versions of this document.¶

9. Acknowledgements

To be added upon contributions, comments and suggestions.¶

10. IANA Considerations

TBD.¶

11. References

Contributors

Authors' Addresses