A Framework for Computing-Aware Traffic Steering (CATS)

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 20 December 2025.¶

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

Computing service architectures have evolved from single service site to multiple, sometimes collaborative, service sites to address various issues such as long response times or suboptimal utilization of service and network resources (e.g., resource under-utilization or exhaustion).¶

The underlying networking infrastructures that include computing resources usually provide relatively static service dispatching, e.g., the selection of the service instances for a request. In such infrastructures, service-specific traffic is often directed to the closest service site from a routing perspective without considering the actual network state (e.g., traffic congestion conditions) or the service site state.¶

As described in [I-D.ietf-cats-usecases-requirements], traffic steering that takes into account computing resource metrics would benefit several services, including latency-sensitive services such as immersive services that rely upon the use of augmented reality or virtual reality (AR/VR) techniques. This document provides an architectural framework that aims at facilitating the making of compute- and network-aware traffic steering decisions in networking environments where computing service resources are deployed.¶

The Computing-Aware Traffic Steering (CATS) framework assumes that there might be multiple service instances that are providing one given service, which are running in one or more service sites. Each of these service instances can be accessed via a service contact instance, which is a client-facing service function instance. A single service site may host one or multiple service contact instances. A single service site may have limited computing resources available at a given time, whereas the various service sites may experience different resource availability issues over time. Therefore, steering traffic among different service sites can address the issues of lacking resources in a specific service site.¶

Steering in CATS is about selecting the appropriate service contact instance that will service a request according to a set of network and computing metrics. This selection may not necessarily reveal the actual service instance that will be invoked, e.g., in hierarchical or recursive contexts. Therefore, the metrics of the service contact instance may be the aggregated metrics from multiple service instances.¶

The CATS framework is an overlay framework for the selection of the suitable service contact instance(s) from a set of candidates. The exact characterization of 'suitable' is determined by a combination of networking and computing metrics.¶

Furthermore, this document describes a workflow of the main CATS procedures in Section 4, which are executed in both the control and data planes.¶

2. Terminology

This document makes use of the following terms:¶

Client:

An endpoint that is connected to a service provider network.¶

Flow:

A flow is identified by the 5-tuple transport coordinates (source address and destination address, source and destination port numbers, and protocol).¶

Computing-Aware Traffic Steering (CATS):

A traffic engineering approach [RFC9522] that takes into account the dynamic nature of computing resources (e.g., compute and storage) and network state to optimize service-specific traffic forwarding towards a given service contact instance. Various relevant metrics may be used to enable such computing-aware traffic steering policies.¶

Metric:

A piece of information that provides suitable input to a selection mechanism to determine a CATS egress node.¶

Computing metrics:

Computing metrics are the metrics that come specifically from the computing side of the system as distinct from other metrics that may be used in a CATS system, such as the metrics from network side.¶

Service:

An offering that is made available by a service provider by orchestrating a set of resources (networking, compute, storage, etc.).¶

Which and how these resources are used is part of the service logic which is internal to the service provider. For example, these resources may be:¶

• Exposed by one or multiple processes.¶

• Provided by virtual instances, physical, or a combination thereof.¶

• Hosted within the same or distinct nodes.¶

• Hosted within the same or multiple service sites.¶

• Chained to provide a service using a variety of means.¶

How a service is structured is out of the scope of CATS.¶

The same service can be provided in many locations; each of them constitutes a service instance.¶

Computing Service:

An offering is made available by a service provider by orchestrating a set of computing resources.¶

CATS Service ID (CS-ID):

An identifier representing a service, which the clients use to access it. See Section 3.2.¶

Service instance:

An instance of running resources according to a given service logic.¶

Many such instances can be enabled by a service provider. Instances that adhere to the same service logic provide the same service.¶

An instance is running in a service site. Clients' requests are serviced by one or more of these instances.¶

Service site:

A location that hosts the resources that are required to offer a service.¶

A service site may be a node or a set of nodes.¶

A CATS-serviced site is a service site that is connected to a CATS-Forwarder.¶

Service contact instance:

A client-facing service function instance that is responsible for receiving requests in the context of a given service.¶

A service contact instance can handle one or more service instances.¶

Steering beyond a service contact instance is hidden to both clients and CATS components.¶

A service request is processed according to the service logic (e.g., handle locally or solicit backend resources).¶

A service contact instance is reachable via at least one Egress CATS-Forwarder.¶

A service can be accessed via multiple service contact instances running at the same or different locations (service sites).¶

A service contact instance may dispatch service requests to one or more service instances (e.g., a service contact instance that behaves as a service load-balancer).¶

CATS Service Contact Instance ID (CSCI-ID):

An identifier of a specific service contact instance. See Section 3.2.¶

Service request:

A request to access or invoke a specific service. Such a request is steered to a service contact instance via CATS-Forwarders.¶

A service request is placed using service-specific protocols.¶

Service requests are not explicitly sent by clients to CATS-Forwarders.¶

CATS-Forwarder:

A network entity that steers traffic specific to a service request towards a corresponding yet selected service contact instance according to provisioned forwarding decisions. These decisions are supplied by a C-PS, which may or may not be on the CATS-Forwarder.¶

A CATS-Forwarder may behave as Ingress or Egress CATS-Forwarder.¶

Ingress CATS-Forwarder:

An entity that steers service-specific traffic along a CATS-computed path that leads to an Egress CATS-Forwarder that connects to the most suitable service site that host the service contact instance selected to satisfy the initial service request.¶

Egress CATS-Forwarder:

An entity that is located at the end of a CATS-computed path and which connects to a CATS-serviced site.¶

CATS Path Selector (C-PS):

A functional entity that selects paths towards service locations and instances and which accommodates the requirements of service requests. Such a path selection engine takes into account the service and network status information. See Section 3.4.4.¶

CATS Service Metric Agent (C-SMA):

A functional entity that is responsible for collecting service capabilities and status, and for reporting them to a CATS Path Selector (C-PS). See Section 3.4.2.¶

CATS Network Metric Agent (C-NMA):

A functional entity that is responsible for collecting network capabilities and status, and for reporting them to a C-PS. See Section 3.4.3.¶

CATS Traffic Classifier (C-TC):

A functional entity that is responsible for determining which packets belong to a traffic flow for a specific service request. It is also responsible for forwarding such packets along a C-PS computed path that leads to the relevant service contact instance. See Section 3.4.5.¶

3. CATS Framework and Components