RFC 10054
Computing-Aware Traffic Steering (CATS) Problem Statement, Use Cases, and Requirements
RFC 10054: Computing-Aware Traffic Steering (CATS) Problem Statement, Use Cases, and Requirements ๐ฆ
Okay bestie, let's get into it ๐ This is RFC 10054, published by the IETF in October 2026 (ISSN 2070-1721). It's Informational, so it's here to explain things, not to be a standards-track spec ๐ธ The authors are K. Yao (China Mobile), L. M. Contreras (Telefonica), H. Shi (Huawei Technologies), S. Zhang (China Unicom), and Q. An (Alibaba Group). The title block doesn't list any RFCs it obsoletes or updates โจ
Abstract โจ
So the vibe here: distributed computing makes response times and energy efficiency way better by using lots of different computing facilities for compute-heavy, delay-sensitive services ๐ To optimize throughput and response time, Computing-Aware Traffic Steering (CATS) picks servers and directs traffic based on compute capabilities and resources, not just static dispatch or connectivity metrics alone. This doc lays out the problem statement and scenarios for CATS within a single domain, and it drives the requirements for the CATS framework ๐
Status of This Memo ๐
Main point: this document is not an Internet Standards Track specification. It's published for informational purposes ๐ง
It's a product of the Internet Engineering Task Force (IETF) and represents the consensus of the IETF community. It went through public review and got approved for publication by the Internet Engineering Steering Group (IESG). ngl, not every IESG-approved doc is a candidate for any level of Internet Standard, so check Section 2 of RFC 7841 if you want the deets ๐
For the current status, any errata, and how to send feedback, go to https://www.rfc-editor.org/info/rfc10054.
Copyright Notice ยฉ๏ธ
Copyright (c) 2026 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) as they're in effect on the publication date. Please read these carefully, because they spell out your rights and restrictions for 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 they're provided without warranty as described in the Revised BSD License ๐ซถ
Table of Contents ๐บ๏ธ
1. Introduction
2. Definition of Terms
3. Problem Statement
3.1. Multi-Deployment of Edge Service Sites and Service
3.2. Traffic Steering Among Edge Service Sites and Service
Instances
4. Use Cases
4.1. Overview of Use Cases
4.2. Example 1: Computing-Aware AR or VR
4.3. Example 2: Computing-Aware Intelligent Transportation
4.4. Example 3: Computing-Aware Digital Twin
4.5. Example 4: Computing-Aware SD-WAN
4.6. Example 5: Computing-Aware Distributed AI Training and
Inference
4.6.1. Distributed AI Inference
4.6.2. Distributed AI Training
5. Requirements
5.1. Support Dynamic and Effective Selection Among Multiple
Service Instances
5.2. Support Agreement on Metric Representation and Definition
5.3. Use of CATS Metrics
5.4. Support Instance Affinity
5.5. Preserve Communication Confidentiality
5.6. Correlation Between Use Cases and Requirements
6. Security Considerations
7. IANA Considerations
8. References
8.1. Normative References
8.2. Informative References
Appendix A. An Additional CATS Use Case
A.1. Integrated Sensing and Communications (ISAC)
A.1.1. Requirements
Acknowledgments
Contributors
Authors' Addresses1. Introduction โจ
Computing resources, especially edge computing resources, are showing up everywhere ๐ They're being deployed to support services that need low latency, high reliability, and dynamic resource scaling.
Diversified service demands have created some real challenges for service deployment and traffic scheduling ๐ญ A single-site service instance often doesn't have enough capacity to guarantee the quality of service it needs. This is especially true at peak hours, when local computing resources can't handle every incoming request, which means slower response times or even dropped requests. Expanding a single site on a regular basis is usually neither practical nor economical. And relying only on client devices getting more computing power can't meet the computing requirements of every application ๐
So it's necessary to deploy services across multiple sites, either edge or central nodes, to improve availability and scalability ๐ The idea is to steer traffic to the "best" service instance based on factors like current computing load. What counts as "best" is mostly decided by the application's requirements.
BUT (and this is the tea) existing routing schemes and traffic engineering methods often fall short here ๐ต The networking infrastructure that includes computing resources usually does relatively static service dispatching, or it depends only on connectivity metrics for traffic steering. It doesn't account for compute capabilities and resource status, and those are critical for meeting the quality requirements of modern services.
To fix this, choosing a service instance and network resources should also consider compute-oriented metrics, not just connectivity metrics ๐ The process of selecting service instances and locations based on metrics oriented toward compute capabilities and resources, and then directing traffic to them over chosen network resources, is called Computing-Aware Traffic Steering (CATS). Also, CATS isn't limited to edge computing scenarios. Section 3 of this document will focus on edge computing scenarios for the problem statement, though ๐ฆ
This document describes sample usage scenarios that drive CATS requirements. They'll also help identify candidate solution architectures and approaches ๐ Just so you know, the use cases and requirements here are limited to single-domain scenarios.
2. Definition of Terms ๐
This document uses the terms defined in [RFC10053], including service site, service instance, CATS Service ID (CS-ID), flow, and client.
Edge Computing: Edge computing is a computing pattern that moves computing infrastructures, i.e., servers, away from centralized data centers and instead places them close to the end users for low-latency communication ๐ง
Even though this document isn't a protocol specification, it still uses upper case key words to define requirements unambiguously ๐
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. Problem Statement ๐
3.1. Multi-Deployment of Edge Service Sites and Service
In edge computing environments, service instances usually adopt a multi-site deployment model ๐ธ Quick heads-up: specific service instance deployment strategies are not in CATS's scope. Still, deployment and traffic scheduling are closely connected, especially when it comes to defining and selecting core metrics like computing capabilities and resources. That's the dual applicability part: one common set of metrics can inform both traffic steering and higher-level service management decisions, without CATS having to define orchestration behavior ๐
So to present a clear and comprehensive problem statement, we first need to go over the relevant considerations for multi-edge service site deployment ๐ This sets up the rest of the CATS requirements and solutions.
Before deploying edge service sites, these factors need to be considered:
- Geographic location, including the number of users, differences in service types, and the number of connection requests from users. Edge service sites in densely populated areas with lots of users and service requests can get more service replicas than other areas ๐๏ธ
- The type, scale, and usage frequency of required computing resources. For example, distributed AI inference services need more Graphics Processing Unit (GPU) resources to be deployed ๐ค
- The status of network resources associated with computing resources, like network topology, network access methods, connectivity, link bandwidth, and path protection or redundancy information ๐
To improve overall quality of service, during the service deployment phase we need to analyze the approximate network and computing resource requirements of the service. Then we can put together a reasonable network and computing resource topology and nail down where the computing resources sit, how they're distributed overall, and how they're positioned relative to each other in the network topology ๐บ๏ธ This whole process depends on standardized consensus about metrics for computing and network resources. Honestly, that's the piece most closely tied to the problem space CATS traffic scheduling is trying to solve โจ
3.2. Traffic Steering Among Edge Service Sites and Service Instances โจ
okay so this section is about how today's edge computing setups don't fully cover what real-time (or near-real-time) services need ๐ญ. We have to steer traffic to different sites, bestie, because stuff keeps changing: where clients are, what time it is, what events are happening, how loaded the servers are, network capabilities, and other factors you can't directly measure (like properties of edge sites, such as their geographical location) ๐ง
It's assumed that service instances are deployed at multiple sites and that they can be reached through a network infrastructure ๐ธ
So when a client sends a request for a service it needs, that request gets steered to one of the available service instances ๐ . Each instance can also act as a client of another service, so its own outbound traffic gets steered to a suitable instance of that requested service, and so on. That's how service composition and chaining happen, iconic ๐
Picking one instance out of the set of candidates is done using traffic steering methods ๐
In edge computing, traffic usually goes to an edge service site that is "closest" or to one of a few "close" sites, using load balancing ๐ฆ. This steering can be started by the application layer or the network layer. At the application layer, the app may actively query for the optimal node and guide traffic with mechanisms like the Application-Layer Traffic Optimization (ALTO) protocol [RFC7285]. At the network layer, the network may use Anycast routing [RFC4786], where routing systems automatically distribute traffic according to routing tables, totally application-transparent ๐ซถ. But here's the tea: whether the app or the network is doing the steering, the core criteria for choosing "closest" or "close" sites often rely solely on communication metrics (such as physical distance, hop count, or network latency). That decision logic can easily lead to suboptimal choices, meaning the "closest" site isn't always the "best" one ๐. The reason is that the computing resources and states of edge service sites can change in real time:
- The closest site may not have sufficient resources.
- The closest site may not have the specific computing resources required.
So we need enhancements to traffic steering mechanisms to direct traffic to sites that can actually support the requested services โจ. Steering decisions may take into account more complex and possibly dynamic metric information, such as load of service instances, latency experienced, or similar, to select a more suitable service instance ๐ฅ
It's important to note that clients may move ๐โโ๏ธ. This means the service instance that was "best" at one moment might no longer be best when a new service request is issued. That creates a (physical) dynamicity that needs to be catered to, on top of the changes in server and network load. From a routing perspective, CATS is an application-transparent routing mechanism that can provide scheduling for both stateful and stateless services. However, in scenarios where clients move and the service is stateful, CATS requires the application to explicitly indicate whether it allows the routing system to enable CATS functionality. Otherwise, mid-session scheduling triggered by CATS may cause application context inconsistency among service sites, or even service interruption ๐ญ๐
Figure 1 shows a common way to deploy edge service sites in the metro ๐. Edge service sites are connected with Provider Edges (PEs). There's an edge data center for a metro area that has high computing resources and serves more User Equipment (UE) (UE1 to UEn) during working hours, because more office buildings are in the metro area ๐ผ. There are also some remote edge service sites with limited computing resources that serve the UE (UEa, UEb) close to them ๐ฟ.
Applications to meet service demands could be deployed in both the edge data center in the metro area and the remote edge service sites. In this case, the service request and the resource are matched well ๐. Some potential traffic steering may be needed just for a special service request or some small scheduling demand.
+----------------+ +---+ +------------+
+----------------+ |- - |UE1| +------------+ |
| +-----------+ | | +---+ +--| Edge | |
| |Edge server| | | +---+ +- - -|PE| | |
| +-----------+ | |- - |UE2| | +--| Site 1 |-+
| +-----------+ | | +---+ +------------+
| |Edge server| | | ... | |
| +-----------+ | +--+ Potential +---+ +---+
| +-----------+ | |PE|- - - - - - -+ |UEa| |UEb|
| |Edge server| | +--+ Steering +---+ +---+
| +-----------+ | | +---+ | |
| +-----------+ | |- - |UE3| +------------+
| | ... ... | | | +---+ | +------------+ |
| +-----------+ | | ... +--| Edge | |
| | | +---+ +- - -|PE| | |
|Edge data center|-+- - |UEn| +--| Site 2 |-+
+----------------+ +---+ +------------+
High computing resources Limited computing resources
and more UE at metro area and less UE at remote areaFigure 1: Common Deployment of Edge Service Sites ๐
Figure 2 shows that during non-working hours (e.g., weekends or at night), more UE moves to the remote areas that are close to their house (e.g., for weekend events) ๐. So there will be more service requests at remote areas, but with limited computing resources there, while the rich computing resources in the metro area might go unused with fewer UE around ๐ค. It's possible for lots of people to request services at the remote area, but with limited computing resources. On top of that, as people move from the metro area to the remote area, the edge service sites that serve common services will also change, so it may be necessary to steer some traffic back to the metro data center ๐.
+----------------+ +------------+
+----------------+ | +------------+ |
| +-----------+ | | Steering traffic +--| Edge | |
| |Edge server| | | +-----------|PE| | |
| +-----------+ | | | +--| Site 1 |-+
| +-----------+ | |- - - - - - - -+ +-+----------+
| |Edge server| | | | | | |
| +-----------+ | +--+ | +---+ +---+ +---+ +---+ +---+
| +-----------+ | |PE|-------+ |UEa| |UEb| |UE1| |...| |UEn|
| |Edge server| | +--+ | +---+ +---+ +---+ +---+ +---+
| +-----------+ | | | | |
| +-----------+ | |- - - - - - - - - - -+ +------+
| | ... ... | | | | +------------+ |
| +-----------+ | | | +--| Edge | |
| | | +-----------|PE| | |
|Edge data center|-+ Steering traffic +--| Site 2 |-+
+----------------+ +------------+
High computing resources Limited computing resources
and less UE at metro area and more UE at remote areaFigure 2: Steering Traffic Among Edge Service Sites ๐
There's also the common variable of network and computing resources for someone who isn't moving but sometimes experiences poor latency ๐ฅบ. Because other UE are moving, there will be a large number of requests for temporary events (e.g., vocal concerts, shopping festivals, and so on), and there will also be the normal change of network and computing resource status. So for some fixed UE, the traffic is also expected to be steered to appropriate sites dynamically ๐.
All of this means traffic needs to be steered among different edge service sites, because of UE mobility and the common variable of network and computing resources ๐ซถ. Plus, some use cases in the following section require both low latency and high computing resource usage, or specific computing hardware capabilities (such as a local GPU). Hence, joint optimization of network and computing resources is needed to guarantee the Quality of Experience (QoE) ๐โจ.
4. Use Cases ๐ฌ
4.1. Overview of Use Cases ๐
The five use cases outlined below are examples that show the need for CATS ๐. In particular, while these use cases may be solved in a simplistic way with current tools, CATS adds the ability to make dynamic selection between service sites and service instances, taking into account network capabilities and status, compute capabilities and current load, and to achieve load balancing โ๏ธ.
Since these use cases are enough to derive common requirements, this document only includes these five use cases in the main body ๐ง . There have been more similar use cases proposed in the CATS Working Group (e.g., [CATS-REQS]), though. The applicability of CATS may be further extended in future use cases brought to the working group, and may possibly arise from work in other standards bodies such as ETSI and 3GPP ๐. But it is believed that the five use cases presented here are sufficient to drive the requirements expressed in this document and future applicability ๐ฆ.
If new use cases do raise additional requirements, they will need to be documented separately and might necessitate modifications to the CATS framework [RFC10053] ๐ ๏ธ.
Further potential use cases are attached in Appendix A of this document ๐.
4.2. Example 1: Computing-Aware AR or VR โจ
Okay so cloud VR and AR are giving "let the cloud do the heavy lifting" energy ๐. The edge cloud helps encode/decode and render content ๐ซถ. It's just cloud computing sitting at the edge of the network so it's closer to users and applications ๐ธ. The client device usually only uploads posture or control information to the edge cloud, and then the VR/AR contents get rendered there โจ. The video and audio outputs from the edge cloud get encoded, compressed, and sent back to the client device, or further transmitted to a central data center over high-bandwidth networks ๐ฆ.
Cloud VR is super delay sensitive ๐ญ, and it's influenced by both network and computing resources. So the edge service site that runs the service has to be carefully picked to make sure it has sufficient computing resources and good network conditions to guarantee the end-to-end service delay ๐ . For example, an entry-level cloud VR (panoramic 8K 2D video) with 110-degree Field of View (FOV) transmission has typical network requirements of a bandwidth of 40Mbps, a 20ms motion-to-photon latency, and a packet loss rate of 2.4E-5 ๐. The typical computing requirements are 8K H.265 real-time decoding and 2K H.264 real-time encoding. Further, the 20ms latency can be categorized like this ๐:
- The sensor sampling delay (client) ๐, which is considered imperceptible by users, is less than 1.5ms including an extra 0.5ms for digitalization and client device processing.
- The display refresh delay (client) takes 7.9ms based on the 144Hz display refreshing rate and a 1ms extra delay to light up ๐ก.
- The image/frame rendering delay (server) could be reduced to 5.5ms.
- The round-trip network delay, which is the remaining latency budget, is 5.1ms, calculated as 20-1.5-5.5-7.9 = 5.1ms.
So the budgets for the server (computing) delay and the network delay are almost equivalent, which means it makes sense to consider both the delay for computing and the network ๐ง . Plus, it could not meet the total delay requirements or find the best choice by either optimizing the network or computing resource alone ๐.
Based on the analysis, here are some further assumptions. As Figure 3 shows, the client could request any service instance among 3 edge service sites. The delay of the client could be the same, and the differences of edge service sites and corresponding network paths have different delays:
- Edge service site 1: The computing delay is 4ms based on a light load, and the corresponding network delay is 9ms based on heavy traffic.
- Edge service site 2: The computing delay is 10ms based on a heavy load, and the corresponding network delay is 4ms based on light traffic.
- Edge service site 3: The computing delay is 5ms based on a normal load, and the corresponding network delay is 5ms based on normal traffic.
In this case, the optimal network and computing delay total cannot be achieved if choosing the resource only based on either computing or network status ๐ค:
- The edge service site based on the best computing delay will be the edge service site 1, and the end-to-end (E2E) delay is 22.4ms.
- The edge service site based on the best network delay will be the edge service site 2, and the E2E delay is 23.4ms.
- The edge service site based on both of the statuses will be the edge service site 3, and the E2E delay is 19.4ms.
Therefore, the best choice is edge service site 3, which has an E2E delay of 19.4ms and is less than 20ms โญ. The differences between the E2E delays are only 3-4ms among the three, but some of them will meet the application demand while the others do not. Lowkey wild, right? ๐ญ
In conclusion, AR/VR clients are increasingly produced as low-end devices with reduced compute capabilities, while the AR/VR services required are ever more complex and need more computation ๐. It makes sense, therefore, to perform at least some of the computation on specialized servers across the network. As the computation work gets larger, it may make sense to break it into components that are processed at different and more specialized sites. All of the computations must, however, be performed in a way that enables the resulting streams to be delivered in a timely way. Thus, it is necessary to select service sites that can cooperate, can perform the correct work, are not already overloaded, and have sufficiently good network connectivity with the client. This needs to be coordinated through a CATS system ๐.
Light Load Heavy Load Normal Load
+------------+ +------------+ +------------+
| Edge | | Edge | | Edge |
| Site 1 | | Site 2 | | Site 3 |
+-----+------+ +------+-----+ +------+-----+
computing|delay(4ms) | computing|delay(5ms)
| computing|delay(10ms) |
+----+-----+ +-----+----+ +-----+----+
| Egress | | Egress | | Egress |
| Router 1 | | Router 2 | | Router 3 |
+----+-----+ +-----+----+ +-----+----+
network|delay(9ms) network|delay(4ms) network|delay(5ms)
| | |
| +--------+--------+ |
+-----------| Infrastructure |-----------+
+--------+--------+
|
+----+----+
| Ingress |
+---------------| Router |--------------+
| +----+----+ |
| | |
+--+--+ +--+---+ +---+--+
+------+| +------+ | +------+ |
|Client|+ |Client|-+ |Client|-+
+------+ +------+ +------+
Client delay is 1.5 + 7.9 = 9.4ms
Figure 3: Computing-Aware AR or VRFurthermore, specific techniques may be employed to divide the overall rendering into base assets that are common across a number of clients participating in the service, while the client-specific input data is being utilized to render additional assets. When being delivered to the client, those two assets are being combined into the overall content being consumed by the client. The requirements for sending the client input data as well as the requests for the base assets may be different in terms of which service instances may serve the request. Base assets may be served from any nearby service instance (since those base assets may be served without requiring cross-request state being maintained), while the client-specific input data is being processed by a stateful service instance that changes, if at all, only slowly over time due to the stickiness of the service that is being created by the client-specific data. Other splits of rendering and input tasks can be found in [TR22.874] for further reading ๐.
When it comes to the service instances themselves, those may be instantiated on demand (e.g., driven by network or client demand metrics), while resources may also be released (e.g., after an idle timeout) to free up resources for other services. Depending on the utilized node technologies, the lifetime of such a "function as a service" may range from a scale of many minutes down to the millisecond ๐ง. Therefore, computing resources across participating edges exhibit a distributed (in terms of location) as well as a dynamic (in terms of resource availability) nature. In order to achieve a satisfying service quality to end users, a service request will need to be sent to and served by an edge with sufficient computing resources and a good network path ๐.
4.3. Example 2: Computing-Aware Intelligent Transportation ๐
Urban intelligent transportation relies on a large number of high-quality video capture devices and light detection and ranging (LiDAR) devices, whose data needs to be processed at edge service sites (e.g., pedestrian flow statistics, vehicle tracking) ๐น. This imposes stringent requirements on the computing capabilities of edge service sites and network performance, including high throughput for concurrent video stream decoding and AI inference, as well as low latency for real-time decision making. CATS can address the issue by coordinating network and computing resources ๐ฅ.
In auxiliary driving scenarios (for example, "Extended Electronic Horizon" [HORITA]), edge service sites collect road and traffic data via Vehicle to Everything (V2X) to address blind spot and collision risks, and provide real-time warnings and maneuver guidance. Requests are typically sent preferentially to the closest edge node. However, if the closest node becomes overloaded, it may lead to response delays and safety risks, which requires CATS to perform traffic steering ๐ฆ.
Specifically, delay-insensitive services (e.g., in-vehicle entertainment) can be offloaded via CATS to edge service sites with lighter loads (even if they are farther away), while delay-sensitive assisted driving services are preferentially processed at local service sites. As mentioned in the Problem Statement section (Section 3), CATS is an application-transparent network-layer solution. Unlike ALTO [RFC7285], it enables coordinated scheduling of network and computing resources without requiring application modifications. For moving vehicles, CATS supports smooth and proactive context migration between edge nodes, provided that the application allows it, to maintain service continuity. In addition, vehicle speed is a key factor: Faster movement requires higher frequency of metric updates (detailed in Section 5) to ensure that CATS steering decisions remain valid as vehicles switch services among base stations or edge service sites ๐๏ธ.
In video recognition scenarios, traffic surges (e.g., during rush hours or weekends) can easily overload the closest edge service sites. CATS addresses this scalability challenge by steering excess service requests to other appropriate sites, ensuring that processing capacity matches user demand ๐.
4.4. Example 3: Computing-Aware Digital Twin
Okay so the Digital Twin (DT) concept is basically everywhere right now ๐คโจ A bunch of industry groups like the Industrial Digital Twin Association or the Digital Twin Consortium <https://www.digitaltwinconsortium.org/> were literally founded to push it for smart cities, transportation, industrial control, and more. The core idea is the "administrative shell" [Industry4.0], which is basically a digital representation of the info and technical functionality for the "assets" (an industrial machine, a vehicle, something in a smart city, etc.) that you want to manage, control, and actuate. It's giving main character energy ๐
For industrial control, the programmable logic controller (PLC) can be virtualized, with its functionality pulled together across a bunch of physical assets into one administrative shell so you can manage them all at once ๐ PLCs get virtualized so their capabilities move from the physical assets up to the edge cloud. You might have several PLC instances for load balancing and fail-over, which also lets the asset physically move around and still connect to a suitable "nearby" PLC instance ๐ฆ So traffic dynamicity can look a lot like the connected car scenario from the previous subsection.
Here's the crucial part, bestie ๐ญ High availability and bounded latency are everything. If the overall PLC functionality fails, a production line can stop, and if latency goes outside its bounds, processes can lose synchronization with each other, which can ultimately mean production faults, tool failures, or similar messes ๐
Data storage is a huge deal in DT scenarios ๐ง Decentralization plays a big role here, and it's not just because of the scenario (like localized reasoning over data coming from driving vehicles in the connected car case). Proposed platform solutions, such as those in [GAIA-X], push it too. With decentralization, the endpoint relationships between a client and its (storage) service instances may change frequently ๐ธ
So in this use case, CATS is required for selecting the optimal PLC instance and storage node ๐ซถ That keeps latency low and reliability high for data processing in industrial scenarios, and it keeps latency low for data reading and writing during twin control processes ๐ฅ
4.5. Example 4: Computing-Aware SD-WAN
Software-Defined Wide-Area Network (SD-WAN) is an overlay connectivity service that optimizes IP packet transport over one or more underlay connectivity services ๐ It does this by recognizing applications and deciding forwarding behavior by applying policies [MEF70.2]. Service providers and enterprises can both deploy SD-WAN to connect branch sites, data centers, and cloud environments. Applications or services can be deployed at multiple locations to hit performance, resiliency, or cost goals โจ
Right now, SD-WAN forwarding decisions are mostly based on network metrics like available bandwidth, latency, packet loss, or path availability. The thing is, these decisions usually have zero visibility into the computing resources at the destination sites, like CPU or GPU utilization, memory pressure, or other composite cost metrics ๐
CATS metrics can complement those SD-WAN network metrics by sharing info about the availability and condition of computing resources tied to service instances at edge or cloud sites ๐ A centralized SD-WAN controller can consume these metrics when it derives policies or computes preferred paths, and SD-WAN edge devices can use them to make distributed, real-time traffic steering decisions among service instances that are already deployed ๐ฆ Either way, the goal is to steer application traffic toward the service instances and sites that best meet application requirements by considering network and computing conditions together ๐
For enterprises deploying apps in the cloud, SD-WAN gives centralized control over the Customer Premises Equipment (CPE) in branch offices and the virtual CPE (vCPE) in the clouds ๐ The CPE connects clients in branch offices to application servers in the clouds. The same application server running in different clouds is called an application instance, and different application instances have different computing resources ๐ง
SD-WAN is aware of the computing resources of apps deployed in the clouds through vCPE, and it picks which application instance a client visits based on computing power and the WAN's network state ๐
To keep things cost-effective, SD-WAN may also consider cost (for example, energy prices incurred or energy sources used) when choosing one specific application instance over another ๐ฟ For this to work, suitable metric information would need to be exposed (by the cloud provider, for example) in terms of utilized energy or incurred energy costs per computing resource ๐
Figure 4 below shows computing-aware SD-WAN for enterprise cloudification ๐ซถ
+---------------+
+-------+ +----------+ | Cloud1 |
|Client1| /---------| WAN1 |------| vCPE1 APP1 |
+-------+ / +----------+ +---------------+
+-------+ +-------+
|Client2| ------ | CPE |
+-------+ +-------+ +---------------+
+-------+ \ +----------+ | Cloud2 |
|Client3| \---------| WAN2 |------| vCPE2 APP1 |
+-------+ +----------+ +---------------+
Figure 4: Illustration of Computing-Aware SD-WAN for Enterprise
CloudificationHere's the current computing load status of the application APP1 in Cloud1 and Cloud2 ๐
- Each application uses 6 virtual CPUs (vCPUs).
- The load of the application in Cloud1 is 50%.
- The load of the application in Cloud2 is 20%.
- The computing resources of APP1 are collected by vCPE1 and vCPE2, respectively.
- Client1 and Client2 are visiting APP1 in Cloud1.
- WAN1 and WAN2 have the same network states.
- Considering a lightly loaded application, SD-WAN selects APP1 in Cloud2 for the Client3 in the branch office ๐
- The traffic of Client3 follows this path: Client3 -> CPE -> WAN2 -> Cloud2 vCPE1 -> Cloud2 APP1.
4.6. Example 5: Computing-Aware Distributed AI Training and Inference
Okay, AI large models are the big, complex, compute-hungry models ๐ค They're super important in lots of fields, like natural language processing for text classification, computer vision for image classification and object detection, and speech recognition ๐
An AI large model has two key phases: training and inference ๐ง Training is when you develop an AI model by feeding it huge amounts of data and optimizing it so it learns and gets better at its job. Inference is when you use the trained model to make predictions or decisions based on new input data โจ
4.6.1. Distributed AI Inference
With the fast development of AI large language models, lighter models can be deployed at edge service sites ๐ธ Figure 5 shows what that deployment can look like ๐
AI inference has two major steps: prefilling and decoding ๐ Prefilling processes a user's prompt to generate the first token of the response in one step. After that, decoding generates the subsequent tokens step by step until the termination token shows up. Both stages eat up a lot of computing resources ๐ฅ The big metrics for AI inference are processor cores, which turn prompts into tokens, and memory resources, which store key values and cache tokens ๐ง Generating and processing tokens shows how capable an AI inference system is ๐ A single site doing both prefilling and decoding might not have enough resources when lots of clients are sending requests (prompts) to use the AI inference service ๐ญ
More generally, cost information is also being used, specifically the cost of the energy spent on AI inferencing for the overall AI-based service, as a possible criterion for steering traffic ๐ The idea is that AI service tiers could be exposed to end users, so they can prioritize "greener energy costs" as a key criterion for service fulfillment ๐ The system would use metric information (like the energy mix used at AI inference sites and energy costs) to prioritize a "greener" site over another while still providing similar response times ๐ฆ
+----------------------------------------------------------+
| +--------------+ +--------------+ +--------------+ |
| | Edge | | Edge | | Edge | |
| | +----------+ | | +----------+ | | +----------+ | |
| | | Prefill | | | | Prefill | | | | Prefill | | |
| | +----------+ | | +----------+ | | +----------+ | |
| | +----------+ | | +----------+ | | +----------+ | |
| | | Decode | | | | Decode | | | | Decode | | |
| | +----------+ | | +----------+ | | +----------+ | |
| +--------------+ +--------------+ +--------------+ |
+----------+-----------------------------+-----------------+
| Prompt | Prompt
| |
+----+-----+ +-+--------+
| Client_1 | ... | Client_2 |
+----------+ +----------+
Figure 5: Illustration of Computing-Aware AI Large Model Inference4.6.2. Distributed AI Training ๐ง โจ
Okay so, large language models are nowadays stuck being trained in very large centers with tons of computing power, often GPU-based ๐ญ. But platforms for federated or distributed training are being positioned as an alternative, especially when they use edge computing resources [CAFL]. Slay for them ๐ .
Those approaches have their own (collective) communication method for steering the training and gradient data toward the various (often edge) computing sites, but we also see a case for CATS traffic steering here ๐ฆ. The training clusters themselves may be multi-site, meaning they combine resources from more than one site, but they act as service instances in a CATS sense. Each one provides its training round as a service to the overall distributed or federated learning platform, and the CATS system is responsible for selecting service instances and steering traffic to them.
One (cluster) site can be selected over another based on compute metrics, network metrics, cost metrics, or a combination of them ๐. For instance, training may be constrained by the network resources so that the required training and gradient information gets delivered to the cluster site on time. Computational load may also be considered, especially when the cluster sites are multi-homed, which means they host more than one application and can therefore become (temporarily) overloaded ๐ซถ. Just like with our inferencing use case in the previous section, the overall training service may also be constrained by cost, especially energy aspects. Think about when the service using the trained model is advertising its "green" credentials to end users ๐ฟ. For this, costs based on energy pricing (over time) as well as the energy mix may be considered. One could foresee, for instance, coupling surplus energy from renewable resources to a cost metric. Traffic could then be steered preferably to those cluster sites that are only consuming surplus energy and not grid energy โก.
Storage is also a must-have for distributed or federated learning, and there are a few key reasons why ๐. First, it is needed to store model checkpoints produced throughout the training process, which allows for progress tracking and recovery in case of interruptions. Storage is also used to keep samples of the dataset used to train the model, and those often come from distributed sensors such as cameras, microphones, and so on ๐ธ. Storage is further required to hold the models themselves, which can be very large and complex ๐งฉ. Knowing the storage performance metrics is important too. For instance, understanding the I/O transfer rate of the storage helps in determining the latency of accessing data from the disk. Knowing the size of the storage is relevant as well, since it tells you how many model checkpoints can be stored or the maximum size of the model that can be locally stored ๐พ.
5. Requirements ๐
In the following section, we outline the requirements for the CATS system to overcome the observed problems in the realization of the use cases above ๐ธ.
5.1. Support Dynamic and Effective Selection Among Multiple Service Instances ๐ฅ
The basic requirement of CATS is to support dynamic access to different service instances residing in multiple computing sites, and to be aware of their status. This is the fundamental model that enables traffic steering and further optimizes the network and computing services ๐. A specific service is identified by a CATS Service ID (CS-ID). All instances of a specific service use the same CS-ID no matter at which edge service site they are located. The CS-ID is unique for the service, so it unambiguously identifies the service. The mapping of this CS-ID to a network locator is basic to steering traffic to any of the service instances deployed in various edge service sites.
Moreover, according to CATS use cases, some applications require E2E low latency, which warrants a quick mapping of the service identifier to the network locator. This naturally leads to in-band methods, which involve considering metrics that are oriented toward compute capabilities and resources, and their correlation with services ๐ฆ. Therefore, a desirable system:
- R1: MUST provide a dynamic discovery and resolution method for mapping the CS-ID to one or more current service instance addresses, based on up-to-date system state assuming the CS-ID is valid.
- R2: MUST provide a method to dynamically assess the availability of service instances, based on up-to-date status metrics (e.g., health, load, reachability).
The term "up to date" herein refers to the latest metric information collected by the system in accordance with the preset metric update cycle. The principle for setting the cycle is generally pre-determined by the network. For example, based on historical statistical data, a relatively appropriate update cycle (either second level or millisecond level) is selected for a specific type or certain types of services โฑ๏ธ.
5.2. Support Agreement on Metric Representation and Definition ๐
Computing metrics can have many different semantics, particularly when they are service specific ๐ค. Even the notion of a "computing load" metric could be represented in many different ways, such as percentile-quantified metrics across various categories (e.g., latency, throughput). Such a representation may entail information on the semantics of the metric, or it may be purely one or more semantic-free numerals. Agreement on the chosen representation among all service and network elements participating in the service instance selection decision is important ๐ซถ. Therefore, in a desirable system:
- R3: The implementations MUST agree on using metrics that are oriented towards compute capabilities and resources and their representation among service instances in the participating edges, at both design time and runtime.
To better understand the meaning of different metrics and to better support appropriate use of metrics:
- R4: An information model of the compute and network resources MUST be defined. Such a model MUST characterize how metrics are abstracted out from the compute and network resources. We refer to this information model as the Resource Model.
- R5: The Resource Model MUST be implementable in an interoperable manner. That is, metrics generated by this resource model MUST be understood and interoperable across independent CATS implementations.
- R6: It MUST be possible to implement the Resource Model in a scalable manner. That is, the Resource Model MUST be capable of scaling in memory, energy, and processing no worse than linearly with an increase in the amount of CATS metrics and CATS service instances it supports.
We recognize that different network nodes (e.g., routers, switches, etc.) may have diversified capabilities, even in the same routing domain, let alone in different administrative domains and from different vendors ๐. Therefore, to work properly in a CATS system:
- R7: CATS systems MUST support staleness handling for CATS metrics and provide indications of when metrics should be refreshed, so that CATS components can know if a metric value is valid or not.
- R8: All metric information used in CATS MUST be produced and encoded in a standardized format that is understood by all participating CATS components. For metrics that CATS components do not understand or support, CATS components will ignore them.
- R9: CATS components SHOULD support a mechanism to advertise or negotiate supported metric types and encodings to ensure compatibility across implementations.
- R10: The computation and use of metrics in CATS MUST be designed to avoid introducing routing loops or path oscillations when metrics are distributed and used for path selection.
Compute metrics can change rapidly, which may lead to path oscillation if metrics are updated too frequently or become stale if updated too infrequently ๐ข. R10 ensures that CATS components can negotiate metric types for consistent interpretation, while R11 requires that metrics be used in a way that avoids routing loops and path instability. Together, they balance responsiveness with stability ๐.
5.3. Use of CATS Metrics โจ
Okay so, network path costs in the current routing system usually don't change very often ๐ธ Traffic engineering metrics like available bandwidth can change more often as traffic demands go up and down, but their updates are normally damped, so only significant changes trigger routing protocol messages ๐
Compute metrics, though? Totally different energy ๐ฅ They can be highly dynamic and change rapidly with the number of sessions, the CPU/GPU utilization, the memory consumption, and so on. Service providers must determine at what interval, or based on what events, this information needs to be distributed. Distributing too often with more accurate synchronization can cause unnecessary signaling overhead ๐
Depending on the service-related decision logic, one or more metrics need to be conveyed in a CATS domain (that's between the clients, services, decision-making points, and traffic steering elements working together to perform CATS functions). The frequency of that conveyance is a problem to think about, and so is which CATS component is the decision maker for service instance selection ๐ง So choosing the right protocols for conveying CATS metrics is important. Existing routing protocols can be a baseline for signaling metrics, like BGP extensions [RFC4760] and the GeneRic Autonomic Signaling Protocol (GRASP) [RFC8990]. These routing protocols may be more suitable for distributed systems. For centralized approaches to selecting CATS service instances, other means of conveying metrics can equally be chosen and even realized, such as leveraging RESTful APIs to publish CATS metrics to a centralized decision maker. Specifically, a desirable system:
R11: MUST provide mechanisms for metric collection, including specifying the responsible entity for collection.
Collecting metrics from all of the service instances can be a lot of overhead for decision makers ๐ญ Hierarchical aggregation helps with that by consolidating metrics at intermediate nodes, giving a more scalable and efficient view of resource conditions ๐ฆ
CATS components don't need to know how metrics are collected behind the aggregator, and the decision point may not be directly connected with service instances or metric collectors. Therefore, a system:
R12: MUST provide mechanisms to distribute the metrics.
Different computing metrics can update at different frequencies. Some are super dynamic, while others are relatively static, so different distribution methods may need to be picked for different update frequencies ๐ Therefore, a system:
R13: MUST continue to operate (even if sub-optimally) if metric updates are delayed by low-frequency updates or by problems with the mechanisms used to distribute the metrics.
Here's an example: in highly mobile scenarios, like the fast-moving vehicles mentioned in Section 4.3, compute metrics can get outdated really fast as the UE moves across base stations and edge service sites, which might mean more frequent updates. Still, updates should remain stable and avoid excessive overhead ๐ซถ
5.4. Support Instance Affinity ๐
In the CATS system, a service may be provided by one or more service instances deployed at different locations in the network. Each instance provides equivalent service functionality to its clients. The decision logic for instance selection is tied to packet-level communication, and packets are forwarded based on the operating status of both network and computing resources. That resource status will likely change over time, so individual packets could end up being sent to different network locations ๐ฌ That can segment individual service transactions and break service-level semantics. Also, when a client moves, its access point might change, which can lead to migration of service instances. If execution moves from one (e.g., virtualized) service instance to another, the state/context needs to be transferred to the new instance. Because that transfer is required, instance affinity as the default is desirable, since it removes the need for explicit context transfer, while still supporting an explicit state/context transfer (e.g., when metrics change significantly) ๐
How affinity works depends heavily on the nature of the service, and this relationship can be seen as an "instance affinity." The minimal affinity, a single request, represents a stateless service, where each service request may be responded to without any state being held at the service instance for fulfilling the request. Providing any necessary information/state in-band as part of the service request, such as in the form of a multi-form body in an HTTP request or through the URL provided as part of the request, is one way to achieve that stateless nature โจ
Alternatively, affinity to a particular service instance may span more than one request, like in the AR/VR use case, where the previous client input is needed to render subsequent frames ๐ฅฝ
Now the tricky part ๐ค A client (e.g., a mobile UE) may have many applications running. If all, or most, of those applications request CATS-based services, the runtime states that need to be created and maintained would require high granularity. In the extreme scenario, that granularity could reach per-UE, per-APP, and per-(sub)flow with regard to a service instance. Here, a "flow" is a logical grouping of packets during a time interval, identified by some fields from the packet header, such as the 5-tuple transport coordinates (source address and destination address, source and destination port numbers, and protocol) (see also [RFC10053]). Obviously, these fine-grained runtime states could place a heavy burden on network devices if they have to dynamically create and maintain them. On the flip side, it's not appropriate to put the state-keeping task on the clients themselves either ๐
There's also the case where the UE moves to a new (access) network, or the service instance gets migrated to another cloud. That can cause unreachability or inconvenience for the original service instance, so UE and service instance mobility also need to be considered ๐งญ
Therefore, a desirable system:
R14: MUST maintain instance affinity for stateful sessions and transactions on a per-flow basis.
R15: MUST avoid maintaining per-flow states for specific applications in network nodes for providing instance affinity.
R16: SHOULD support service continuity in the presence of UE or service instance mobility.
5.5. Preserve Communication Confidentiality ๐
Exposing CATS metrics to the network may lead to leakage of application privacy, and nobody wants that ๐ โโ๏ธ To prevent it, we need to think about methods for handling sensitive information. Examples include general anonymization methods, like hiding the key information that identifies devices, using an index to represent the service level of computing resources, or using customized information exposure strategies based on specific application requirements or network scheduling requirements. At the same time, once anonymity is achieved, the exposed computing information still has to be sufficient to enable effective traffic steering. So a CATS system:
R17: MUST preserve the confidentiality of the communication relation between a user and a service provider by minimizing the exposure of user-relevant information according to user's demands but allowing for regulatory requirements in the environment where CATS is deployed. See also Section 6 for a discussion of confidentiality.
5.6. Correlation Between Use Cases and Requirements ๐
Here's a table that shows how CATS use cases and requirements connect ๐ An "X" marks that the requirement can be derived from the corresponding use case.
+==========================+================================+
| | Use Cases |
+==========================+=======+=====+====+========+====+
| Requirements | AR/VR | ITS | DT | SD-WAN | AI |
+====================+=====+=======+=====+====+========+====+
| Instance Selection | R1 | X | X | X | X | X |
| +-----+-------+-----+----+--------+----+
| | R2 | X | X | X | X | X |
+--------------------+-----+-------+-----+----+--------+----+
| Metric Definition | R3 | X | X | X | X | X |
| +-----+-------+-----+----+--------+----+
| | R4 | X | X | X | X | X |
| +-----+-------+-----+----+--------+----+
| | R5 | X | X | X | X | X |
| +-----+-------+-----+----+--------+----+
| | R6 | X | X | X | X | X |
| +-----+-------+-----+----+--------+----+
| | R7 | X | X | X | X | X |
| +-----+-------+-----+----+--------+----+
| | R8 | X | X | X | X | X |
| +-----+-------+-----+----+--------+----+
| | R9 | X | X | X | X | X |
| +-----+-------+-----+----+--------+----+
| | R10 | X | X | X | X | X |
+--------------------+-----+-------+-----+----+--------+----+
| Use of Metrics | R11 | X | X | X | X | X |
| +-----+-------+-----+----+--------+----+
| | R12 | X | X | X | X | X |
| +-----+-------+-----+----+--------+----+
| | R13 | X | X | X | X | X |
+--------------------+-----+-------+-----+----+--------+----+
| Instance Affinity | R14 | X | X | X | X | X |
| +-----+-------+-----+----+--------+----+
| | R15 | X | X | X | X | X |
| +-----+-------+-----+----+--------+----+
| | R16 | X | X | | | X |
+--------------------+-----+-------+-----+----+--------+----+
| Confidentiality | R17 | X | X | X | X | X |
+--------------------+-----+-------+-----+----+--------+----+
Table 1: Mapping Between CATS Use Cases and Requirements6. Security Considerations ๐โจ
Okay bestie, so CATS decisions run on real-time computing and network status plus service info ๐ง . That means the security game has to be strong ๐ . We need robust safeguards for the risks that come with dynamic service and resource scheduling and cross-node data transmission ๐ก๏ธ.
Core security risks and requirements include:
User Privacy Leakage Risk ๐
Description: This one is a big deal. CATS touches user-related data, like access patterns and service requests, across edge service sites ๐. If user identifiers get disclosed, or someone tracks per-user behavior, that opens the door to profiling and identity theft ๐ญ. It's especially sensitive for personal or context-rich data (think AR/VR, vehicle trajectories, and AI prompts ๐ฅฝ๐๐ค). It can also violate regulations and totally erode trust ๐.
R18: User activity privacy MUST be preserved by anonymizing identifying information. Per-user behavior pattern tracking is prohibited ๐ซ.
Service Instance Identity Spoofing and Traffic Hijacking ๐ญ
Description: Attackers might fake legit service instance identities, or tamper with "CS-ID - instance address" mappings (per R1 ๐), and send traffic to malicious nodes ๐ฑ. That breaks CATS' core scheduling logic ๐ and can cause service disruptions, data leaks, and even potential physical harm in safety-critical scenarios ๐. Yikes.
R19: Service instances MUST be authenticated, and digital signatures SHOULD be used to provide proof of authentication. "CS-ID - instance address" mapping results MUST be encrypted ๐.
Tampering and False Reporting of CATS Metrics ๐
Description: Attackers could mess with core scheduling metrics or submit fake data (per R3-R17), which sends traffic steering decisions completely off course ๐งญ. The result is node overload, link congestion, or "resource exhaustion attacks", and that directly tanks Quality of Experience (QoE) ๐๐.
R20: Metric collection and distribution MUST employ integrity checks and encryption. Mechanisms for secondary validation and traceability of abnormal metrics MUST be supported, avoiding over-reliance on single-node reports ๐ต๏ธโโ๏ธ.
Security of Cross-Node Context Migration Data ๐
Description: When a user or terminal moves around (mobility!) ๐โโ๏ธ, session states and computing context, like AR rendering progress or vehicle status, could get intercepted or tampered with during cross-node migration ๐. That can break service continuity, leak sensitive data, or leave the state inconsistent ๐.
R21: Migration data MUST use end-to-end encryption, accessible only to authorized target instances using, for example, Authenticated Encryption with Associated Data (AEAD). Migration instructions MUST include integrity check codes ๐.
7. IANA Considerations ๐ง
This document has no IANA actions, so there's nothing for IANA to do here ๐.
8. References ๐
8.1. Normative References
[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/info/rfc2119.[RFC4760]Bates, T., Chandra, R., Katz, D., and Y. Rekhter, "Multiprotocol Extensions for BGP-4", RFC 4760, DOI 10.17487/RFC4760, January 2007,https://www.rfc-editor.org/info/rfc4760.[RFC4786]Abley, J. and K. Lindqvist, "Operation of Anycast Services", BCP 126, RFC 4786, DOI 10.17487/RFC4786, December 2006,https://www.rfc-editor.org/info/rfc4786.[RFC7285]Alimi, R., Ed., Penno, R., Ed., Yang, Y., Ed., Kiesel, S., Previdi, S., Roome, W., Shalunov, S., and R. Woundy, "Application-Layer Traffic Optimization (ALTO) Protocol", RFC 7285, DOI 10.17487/RFC7285, September 2014,https://www.rfc-editor.org/info/rfc7285.[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/info/rfc8174.[RFC8990]Bormann, C., Carpenter, B., Ed., and B. Liu, Ed., "GeneRic Autonomic Signaling Protocol (GRASP)", RFC 8990, DOI 10.17487/RFC8990, May 2021,https://www.rfc-editor.org/info/rfc8990.[RFC10053]Li, C., Ed., Du, Z., Boucadair, M., Ed., Contreras, L. M., and J. Drake, "A Framework for Computing-Aware Traffic Steering (CATS)", RFC 10053, DOI 10.17487/RFC10053, October 2026,https://www.rfc-editor.org/info/rfc10053.
8.2. Informative References
[CAFL]Gu, Q., Jiang, K., Zhao, L., Zhou, H., and T. Jiang, "Cost-Aware Federated Learning in Mobile Edge Networks", FedEdge '24: Proceedings of the 3rd Workshop on Data Privacy and Federated Learning Technologies for Mobile Edge Network, pp. 13-18, DOI 10.1145/3694908.3696173, 2024,https://doi.org/10.1145/3694908.3696173.[CATS-REQS]Ngแปc, T. M., Kiแปm, N. T., and Y. Kim, "Additional CATS requirements consideration for Service Segmentation-related use cases", Work in Progress, Internet-Draft, draft-dcn-cats-req-service-segmentation-03, 23 February 2026,https://datatracker.ietf.org/doc/html/draft-dcn-cats-req-service-segmentation-03.[ETSI-WI5]ETSI, "Details of 'DGR/ISC-005' Work Item", V0.1.0, ETSI GR ISC 005, 30 January 2025,https://portal.etsi.org/eWPM/index.html#/schedule?WKI_ID=74347.[GAIA-X]Gaia-X, "GAIA-X: A Federated Data Infrastructure for Europe", 2023,https://gaia-x.eu/.[HORITA]Horita, Y. and R. S. Schwartz, "Extended electronic horizon for automated driving", Proceedings of 14th International Conference on ITS Telecommunications (ITST), pp. 32-36, DOI 10.1109/ITST.2015.7377396, 2015,https://doi.org/10.1109/ITST.2015.7377396.[Industry4.0]Plattform Industrie 4.0, "Details of the Asset Administration Shell, Part 1", 2022.[MEF70.2]MEF, "SD-WAN Service Attributes and Service Framework", MEF Standard, MEF 70.2, 2023,https://www.mplify.net/wp-content/uploads/MEF-70.2.pdf.[TR22.874]3GPP, "5G System (5GS); Study on traffic characteristics and performance requirements for AI/ML model transfer", 3GPP TR 22.874,https://portal.3gpp.org/desktopmodules/Specifications/SpecificationDetails.aspx?specificationId=3721.
Appendix A. An Additional CATS Use Case ๐
This section spotlights an extra CATS use case that isn't in the main body of this document ๐. Why the hold-back? This use case could bring new requirements that the CATS Working Group's initial charter didn't consider ๐ค. Those requirements would affect the CATS framework design and might need further modification or enhancement to the initial CATS framework, which serves all the existing use cases in the main body. BUT the Integrated Sensing and Communications (ISAC) use case is super promising and has industry consensus ๐, so it might be considered in future work of the CATS Working Group ๐ฎ.
A.1. Integrated Sensing and Communications (ISAC) ๐ก
okay so ISAC (Integrated Sensing and Communications) is giving wireless networks a double life ๐ The same network can send data and sense the environment at the same time ๐ซถ In a distributed sensing setup, a bunch of network nodes (like base stations, access points, or edge devices) gather raw sensing data from the environment. That data can be radio frequency (RF) reflections, Doppler shifts, channel state information (CSI), or other physical-layer features, and they tell you stuff like object movement, material composition, or environmental conditions ๐
To actually get something useful out of that raw data, it has to be aggregated and processed by a designated computing node with enough computational resources. So you need efficient coordination between the sensing nodes and the computing resources to keep the analysis timely and accurate. That makes it a super relevant use case for Computing-Aware Traffic Steering (CATS) in the IETF ๐ฆ
This use case lines up with what's happening over at the ETSI ISAC Industry Specification Group (ISG), especially Work Item #5 (WI #5), titled "Integration of Computing with ISAC" [ETSI-WI5] ๐ง WI #5 digs into different ways computing can be integrated into ISAC systems, including sensing combined with computing, communications combined with computing, and the holistic integration of ISAC with computing. The considerations in this document complement ETSI's work by looking at how computing-aware networking solutions, as developed within CATS, can optimize the processing and routing of ISAC sensing data โจ
Picture a network domain with multiple sites that could host the ISAC computing "service", and each one has potentially different connectivity and computing characteristics ๐ข Figure 6 shows an exemplary scenario. If we consider the connectivity and computing latencies (just as an example of metrics), the best service site is #N-1 in the example used in Figure 6 ๐ Quick heads up: the figure still uses the old terminology, where "ICR" means "Ingress CATS-Forwarder" [RFC10053] and "ECR" means "Egress CATS-Forwarder" ๐
_______________
( -------- )
( | | )
( -------- | )
________________ ( | | | ) ________________
( -------- ) ( --------- | | ) ( -------- )
( | | ) ( |service | |- ) ( | | )
( -------- | ) ( |contact | | ) ( -------- | )
( | | | ) ( |instance|- ) ( | | | )
( -------- | | ) ( --------- ) ( -------- | | )
( |service | |- ) ( Serv. site #N-1 ) ( |service | |- )
( |contact | | ) -------+--------- ( |contact | | )
( |instance|- ) Computing \ ( |instance|- )
( -------- ) delay:4ms \ ( -------- )
( Serv. site #1 ) ------+-- ( Serv. site #N )
-------+------- ----| ECR#N-1 |---- ---------+-----
\ Computing -- --------- -- Computing /
\ delay:10ms Networking delay:5ms /
--+---- delay:7ms -----+-
( | ECR#1 | // | ECR#N | )
( ------- // ------- )
( Networking // Networking )
( delay:5ms // delay:15ms )
( // )
( // )
( // )
( // )
( // )
( ------- ------- )
-------| ICR#1 |---------------------| ICR#2 |--------
------- __ -------
(.) (.) / ( ) (.)
(.) ----- - ( ) (.)
(.) | UE2 | / (__) \ (.)
(.) ----- / - -----
(.) / (sensing) \ | UE3 |
----- ----------- -----
| UE1 | /
-----
Figure 6: Exemplary ISAC ScenarioIn the distributed sensing use case, the sensed data collected by multiple nodes has to be routed efficiently to a computing node that can actually process it ๐ง Which computing node gets picked depends on a few things, like computational load, network congestion, and latency constraints. CATS mechanisms can optimize the selection of the processing node by dynamically steering traffic based on computing resource availability and network conditions ๐ Also, sensing data is often time sensitive, so CATS can make sure low-latency paths exist while balancing the computational demands across different processing entities. That's essential for real-time stuff like cooperative perception for autonomous systems, industrial monitoring, and smart city infrastructure ๐
A.1.1. Requirements ๐
okay so on top of the CATS requirements we already covered in the main body of this doc, there are a few extra challenges that need sorting out for efficient distributed sensing in ISAC-enabled networks ๐
CATS systems should be able to select an instance where multiple nodes can steer traffic simultaneously, ensuring that packets arrive within a maximum time period. This is required because there are distributed tasks where multiple nodes act as sensors, producing sensing data that then has to be processed by a sensing processing function, typically hosted at the edge ๐ฅน That implies a multi-point to point kind of traffic direction, with connectivity and computing requirements attached (which can be very strict for some types of sensing schema) ๐ญ
CATS systems should provide mechanisms that implement per node/flow security and privacy policies to adapt to the nature of the sensitive information that might be exchanged in a sensing task. Main character energy, because sensing data can be seriously sensitive ๐๐ฅ
Acknowledgments ๐ซถ
bestie, huge thanks to Adrian Farrel, Peng Liu, Joel Halpern, Jim Guichard, Cheng Li, Luigi Iannone, Christian Jacquenet, Xiaodong Duan, Yuexia Fu, Huijuan Yao, Zongpeng Du, Jing Wang, Erum Welling, Ines Robles, Linda Dunbar, Jim Reid, Zaheduzzaman Sarker, Tim Bray, Samier Barguil, Daniel Migault, Roni Even, Roman Danyliw, Gorry Fairhurst, Ketan Talaulikar, Andy Newton, Deb Cooley, Erik Kline, and Paul Wouters for their valuable suggestions to this document ๐
The authors would also love to thank Yizhou Li for her early IETF work on Compute First Network (CFN) and Dynamic Anycast (Dyncast), which inspired the CATS work ๐
Contributors ๐ธ
these people substantially contributed to this document โจ
Yizhou Li, Huawei Technologies, Email: liyizhou@huawei.com
Dirk Trossen, Email: dirk@trossen.tech
Mohamed Boucadair, Orange, Email: mohamed.boucadair@orange.com
Carlos J. Bernardos, UC3M, Email: cjbc@it.uc3m.es
Peter Willis, Email: pjw7904@rit.edu
Philip Eardley, Email: ietf.philip.eardley@gmail.com
Tianji Jiang, China Mobile, Email: tianjijiang@chinamobile.com
Minh-Ngoc Tran, ETRI, Email: mipearlska@etri.re.kr
Markus Amend, Deutsche Telekom, Email: Markus.Amend@telekom.de
Guangping Huang, ZTE, Email: huang.guangping@zte.com.cn
Dongyu Yuan, ZTE, Email: yuan.dongyu@zte.com.cn
Xinxin Yi, China Unicom, Email: yixx3@chinaunicom.cn
Tao Fu, CAICT, Email: futao@caict.ac.cn
Jordi Ros-Giralt, Qualcomm Europe, Inc., Email: jros@qti.qualcomm.com
Jaehoon Paul Jeong, Sungkyunkwan University, Email: pauljeong@skku.edu
Yan Wang, Migu Culture Technology Co., Ltd, Email: wangyan_hy1@migu.chinamobile.com
Authors' Addresses ๐ฆ
Kehan Yao, China Mobile, Email: yaokehan@chinamobile.com
Luis M. Contreras, Telefonica, Email: luismiguel.contrerasmurillo@telefonica.com
Hang Shi, Huawei Technologies, Email: shihang9@huawei.com
Shuai Zhang, China Unicom, Email: zhangs366@chinaunicom.cn
Qing An, Alibaba Group, Email: anqing.aq@alibaba-inc.com
๐ฆ where this page comes from
- ietf: rfc10054 2026-10
- ๐ girlified by claude-haiku-5-5 on : a language model's rewrite of the original, under its terms