Outlining the Architecture and Basic Concepts of Computing-Aware Traffic Steering (CATS) Described in RFC 10053

About this article
This article was created using an automated generation workflow utilizing generative AI. While it is organized based on reference information, no physical device verification has been conducted by the author.

Verification Status: unverified (physical device not verified)

RFC 10053 is an Informational RFC that defines the basic framework for Computing-Aware Traffic Steering (CATS), which dynamically distributes traffic by taking into account not only network conditions but also fluctuations in edge and cloud computing resources (such as CPU and load status). This specification defines functional entities, identifiers, and plane interworking for guiding client service requests to the optimal service contact instance within a single service provider network.

Background of CATS Formulation and Challenges in Conventional Traffic Control

In recent years, computing services have transitioned from a single location to a cooperative configuration across multiple geographically distributed locations (such as on-premises and cloud provider environments). For immersive services requiring ultra-low latency, such as AR/VR, reducing response times and preventing resource exhaustion are essential.

However, conventional routing infrastructures tend to statically distribute traffic to the closest site from a routing perspective, or perform dispatching considering only conditions such as network congestion. This approach creates problems in maintaining appropriate processing performance when computing resources at the destination service site are constrained or when load imbalances occur between sites.

As stated in the primary source, CATS is a traffic engineering method that takes both the dynamic state metrics of computing resources (Compute/Storage) and network states as inputs to guide traffic to an instance suitable for processing a specific request. This aims to dynamically avoid resource limitations at specific sites and achieve optimal utilization of the entire infrastructure.

Key Identifiers and Basic Concepts Constituting CATS

Important for understanding the CATS framework are the conceptual model and identifiers that handle logical services and physical instances separately. The primary source defines the following key elements.

1. Classification of Identifiers (IDs)

• CS-ID (CATS Service ID)
  This ID is used by clients to identify the service they wish to access. It represents the entire identical service without requiring awareness of the deployment location or multiple instances running behind it. While global uniqueness is not required, uniqueness that allows identification without collision within the CATS system is necessary.

• CSCI-ID (CATS Service Contact Instance ID)
  This ID uniquely identifies a specific service contact instance. The primary source does not restrict its internal structure or semantics, citing unicast IP addresses as an example.

2. Functional Entities Constituting the Service

• Service Instance
  A collection of computing resources that operate according to service logic. One or more operate within a single service site.

• Service Contact Instance
  This is a frontend function that directly interfaces with clients. It directly receives service requests from clients and distributes processing to one or more underlying service instances (functioning like a load balancer). The internal configuration behind this contact instance is invisible to clients and CATS network components.

• Service Site
  A deployment location of a node or a group of nodes housing one or more service instances.

Plane Design and Functional Components of the CATS Architecture

Primary information classifies the entire CATS network into three layers: the management plane, the control plane, and the data plane, with dedicated functional components deployed in each.

Responsibilities of Each Plane

• CATS Management Plane
  Monitors, configures, and maintains network devices related to CATS.

• CATS Control Plane
  Performs service scheduling based on computing resource and network information. Determines packet forwarding policies and notifies the data plane.

• CATS Data Plane
  Responsible for packet classification, steering along the selected path, and forwarding processing toward the target service contact instance.

Key Functional Components

The roles of the main components described in the primary information are as follows.

• C-SMA (CATS Service Metric Agent)
  Collects resource information of service sites and servers, as well as the operational status of each service instance, and reports them to the C-PS.

• C-NMA (CATS Network Metric Agent)
  Collects network capability and status information, and reports them to the C-PS.

• C-PS (CATS Path Selector)
  An engine that selects the optimal service contact instance and path satisfying the requirements of the service request, based on the information obtained from C-SMA and C-NMA.

• C-TC (CATS Traffic Classifier)
  Identifies packets belonging to a specific service flow and injects them into the selected path in coordination with the Ingress CATS-Forwarder.

• CATS-Forwarder
  A network entity that forwards traffic based on the decisions made by the C-PS.

  • Ingress CATS-Forwarder: Receives client-side traffic and injects it into the CATS-computed path leading to the appropriate Egress CATS-Forwarder.

  • Egress CATS-Forwarder: Located at the termination of the CATS path and connects to the service site and service contact instances.

Control and Data Forwarding Sequence in CATS

Based on the primary information, the standard functional integration flow from metric collection to forwarding is shown in the sequence diagram below.

sequenceDiagram
    participant SMA as C-SMA
    participant NMA as C-NMA
    participant CPS as C-PS
    participant Client as Client
    participant Ingress as Ingress CATS-Forwarder / C-TC
    participant Egress as Egress CATS-Forwarder
    participant SCI as Service Contact Instance

    SMA->>CPS: サービス／計算メトリクスを通知
    NMA->>CPS: ネットワーク状態メトリクスを通知
    CPS->>Ingress: パス選択ポリシー／転送ルールを設定
    Client->>Ingress: サービス要求パケットを送信 (CS-ID宛て)
    Ingress->>Ingress: C-TCによるフロー識別と転送パス適用
    Ingress->>Egress: CATSオーバーレイカプセル化転送
    Egress->>SCI: サービス要求パケットを配送

In the control plane, the C-SMA collects metrics such as computing resource load and available capacity, while the C-NMA collects network delay and congestion status, aggregating them into the C-PS. The C-PS comprehensively evaluates these metrics, determines steering policies for each request, and instructs the Ingress CATS-Forwarder. In the data plane, the C-TC detects requests addressed to the CS-ID arriving from the client, performs overlay encapsulation along the designated path, and delivers them via the Egress CATS-Forwarder to the target service contact instance.

Network Environment and Boundary Conditions Assumed by CATS

In the primary information, several scopes and boundary conditions for applying this framework are clearly defined.

1. Assumption of a Single Service Provider Network
   The scope targeted by RFC 10053 is limited to a "Single Service Provider" network. Inter-domain coordination and cooperation across multiple operators are outside the scope of this specification.

2. Client-Side Unawareness of CATS
   The client terminal itself is not aware of the existence of CATS or the internal CATS-Forwarders. The client simply transmits requests addressed to the CS-ID in accordance with standard service protocols, and configurations where CATS functional entities reside within the client terminal are considered out of scope.

3. Adoption of the Overlay Approach
   Steering by CATS is implemented as an overlay network using encapsulation between CATS-Forwarders. It is designed to be deployed without requiring the entire physical topology of the underlying network to be overhauled exclusively for CATS.

4. Hiding of Internal Logic
   Which specific service instance executes processing downstream of a service contact instance is hidden from both the CATS component and the client. The primary source also mentions that metrics obtained from a contact instance may represent aggregated values from multiple internal instances.

Precautions When Utilizing and Considering the CATS Framework

When adopting or evaluating the CATS architecture, the following points must be kept in mind:

• Positioning as an Informational RFC
  RFC 10053 is published as an Informational document rather than a Standards Track document. It does not lock down a single specific protocol header format or concrete encapsulation protocol (such as SRv6, Geneve, or VXLAN), but rather outlines functional requirements and an architectural framework. Specific packet structures and transmission protocols require reference to individual extension specifications.

• Trade-offs Between Metric Collection Update Frequency and Overhead
  Computing resource states (such as CPU utilization and queue backlog) can fluctuate more rapidly and severely than network states. Excessively high reporting frequency from C-SMA to C-PS leads to increased control traffic and flapping, whereas excessively low frequency risks routing requests to overloaded sites based on outdated information.

• Session Consistency and Flow Identification
  While stateless communication allows the optimal site to be selected for each request, stateful communication that requires maintaining a series of transactions demands consideration to ensure that the same session is maintained to the same service contact instance based on flow identification (such as 5-tuple) by the C-TC.

Conclusion

The main points of RFC 10053 (the CATS framework) are as follows:

• Objective: To achieve dynamic traffic steering that considers not only network quality but also site computing resource status.

• Architecture: Composed of the collaboration among C-SMA (Computing Metric Agent), C-NMA (Network Metric Agent), C-PS (Path Selector), C-TC (Traffic Classifier), and CATS-Forwarder (Overlay Forwarder).

• Abstraction Layer: Clients send requests to the CS-ID, and internally they are encapsulated and forwarded to the service contact instance possessing the CSCI-ID, thereby hiding the concrete backend configuration.

When planning design or deployment, it is recommended to verify the following points:

• Whether the target network meets the requirements of a single-operator network.

• Whether the metric collection methods for C-SMA and C-NMA and the control plane load boundaries are properly designed.

• Is it consistent with the encapsulation technology and underlying network specifications used for actual data plane forwarding?

Reference Information

• RFC 10053: A Framework for Computing-Aware Traffic Steering (CATS)
  
  RFC 10053: A Framework for Computing-Aware Traffic Steering (CATS) | RFC Editor

  This document describes a framework for Computing-Aware Traffic Steering (CATS). Specifically, the document identifies a...

  www.rfc-editor.org