RFC 10053
A Framework for Computing-Aware Traffic Steering (CATS)
A Framework for Computing-Aware Traffic Steering (CATS) 🦋
okay bestie, let's get you set up 💖 This is RFC 10053, and its title is "A Framework for Computing-Aware Traffic Steering (CATS)." It's Informational, so it's sharing info rather than a standards-track spec 📚. The ISSN is 2070-1721 and the date is October 2026 🎀. The authors are C. Li, Ed. (Huawei Technologies), Z. Du (China Mobile), M. Boucadair, Ed. (Orange), L. M. Contreras (Telefonica), and J. Drake (Independent) 👑. The title block doesn't list anything it obsoletes or updates, so nothing gets replaced or patched by this one 🫶.
Abstract ✨
This doc describes a framework for Computing-Aware Traffic Steering (CATS) 🌈. It identifies a set of CATS functional components, describes how they interact, and gives illustrative workflows for the control and data planes. It only covers the case of a single service provider 💅.
Status of This Memo 📜
This doc 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 got public review and was approved for publication by the Internet Engineering Steering Group (IESG) 🔥. Not every IESG-approved doc is a candidate for any level of Internet Standard, so check out Section 2 of RFC 7841 if you're curious 🙈.
For info on the current status, any errata, and how to send feedback, go to https://www.rfc-editor.org/info/rfc10053 🦋.
Copyright Notice 💅
Copyright (c) 2026 IETF Trust and the persons identified as the document authors. All rights reserved 🌸.
This doc is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) as in effect on the date of publication. Please review these carefully, because they spell out your rights and restrictions for this doc 🫶. Code Components extracted from this doc 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. Terminology
3. CATS Framework and Components
3.1. Assumptions
3.2. CATS Identifiers
3.3. Framework Overview
3.4. CATS Functional Components
3.4.1. Service Sites, Service Instances, and Service Contact
Instances
3.4.2. CATS Service Metric Agent (C-SMA)
3.4.3. CATS Network Metric Agent (C-NMA)
3.4.4. CATS Path Selector (C-PS)
3.4.5. CATS Traffic Classifier (C-TC)
3.4.6. CATS-Forwarders
3.4.7. Underlay Infrastructure
4. CATS Framework Workflow
4.1. Service Announcement
4.2. Metrics Distribution
4.3. Service Access Processing
4.4. Service Contact Instance Affinity
5. Operational Considerations
5.1. Provisioning of CATS Components
5.2. Supervision of CATS Components and CATS OAM
5.3. Deployment Considerations
5.4. Implementation Considerations on Using CATS Metrics
5.5. Verifying Correct Operations
5.6. Impact on Network Operations
6. Security Considerations
7. Privacy Considerations
8. IANA Considerations
9. Informative References
Appendix A. Deployment Examples
A.1. Distributed Model
A.2. Centralized Model
A.3. Hybrid Model
Acknowledgments
Contributors
Authors' Addresses1. Introduction ✨
Computing service architectures have evolved from a single service site into multiple sites, sometimes working together, to deal with things like long response times or service and network resources being used poorly (like under-utilized or totally exhausted) 😭.
The underlying networking infrastructures that include computing resources usually do pretty static service dispatching, like picking which service instances handle a request 🧚. In those setups, service-specific traffic often just gets sent to the closest service site from a routing point of view, without caring about the actual network state (like traffic congestion) or the service site state 🙈.
As [RFC10054] describes, traffic steering that takes computing resource metrics into account would help several services, including latency-sensitive ones like immersive services that use augmented reality or virtual reality (AR/VR) techniques 🦋. This doc gives an architectural framework for making compute- and network-aware traffic steering decisions in dynamic networking environments where computing service resources keep changing 💖.
Today, organizations often spread user services across on-premises and cloud service provider networks 🌈. For both redundancy and responsiveness, CATS supports single or multiple service instances providing one given service, which may live in one or more service sites 💜. Clients reach service instances through client-facing service functions called service contact instances 🫶. A single service site can host one or multiple service contact instances. A single service site may have limited computing resources at a given time, while different service sites may hit different resource availability issues over time. So steering traffic among different service sites can work around resource limits in one specific site 🔥.
Steering in CATS is all about selecting the right service contact instance to handle a request, based on a set of network and computing metrics 🎀. That selection might not reveal the actual service instance a client will invoke (e.g., in hierarchical or recursive contexts). So the metrics of a service contact instance may be aggregate metrics from multiple service instances 👑.
The CATS framework is an overlay framework for picking suitable service contact instances from a set of candidates ✨. The overlay is realized through encapsulation between CATS-Forwarders. A combo of networking and computing metrics decides exactly what counts as "suitable" 💅.
This doc also describes a workflow of the main CATS procedures (Section 4), executed in both the control and data planes 🦋. The framework covers only the case of a single service provider 🌸.
This doc assumes CATS functional elements are hosted in a provider network. So it's out of scope to discuss deployment options where those elements are co-located with a client 🙈.
It's also out of scope to provide a comprehensive list of CATS realization techniques, or to assess how existing mechanisms meet all CATS requirements 💜.
Part 1 of 8 is done, bestie 🎀✨ Part 2 is coming up next, so stay tuned 💖
2. Terminology 🎀
Okay so bestie, this section is basically the glossary, and honestly it's the cutest part because it sets up every single word we're about to throw around. Let's get into it 💅
Client: An endpoint that connects to a service provider network. Literally just the person (or device) asking for stuff 🫶
Flow: 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). Flow identification should also cover contexts where port numbers are not present (non-initial fragments, IP Encapsulating Security Payload (ESP) [RFC4303], etc.). So a flow is like a squad of packets that hang out together over a time window, and you know them by their 5-tuple vibes 🦋 Even when there are no port numbers (like non-initial fragments or ESP [RFC4303]), flow identification still has to be a thing ✨
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. The CATS framework leverages various metrics to enable CATS policies. CATS is the whole main character energy of this doc 👑 It's about steering traffic with computing resources AND network state in mind, all to get service traffic to the right service contact instance 🧚
Metric: A quantitative measure that provides suitable input to a selection mechanism for CATS decision making. It can be a network metric or a computing metric. Basically a number that helps CATS pick the best option 🌸
Computing metric: A metric specific to the computing resources in the underlying CATS systems as opposed to other metrics, such as network metrics. Examples of computing metrics are discussed in [CATS-METRICS]. These are the compute-side numbers, and you can check [CATS-METRICS] for examples 💜
Service: An offering that is made available by a service provider by orchestrating a set of resources (networking, compute, storage, etc.).
The service provider retains control of internal resources and the service logic. For example, these resources may be:
- Exposed by one or multiple processes.
- Provided by virtual instances, physical instances, 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 provider structures its services remains out of the scope of CATS. Not CATS's problem, periodt 💅
Service providers may provide the same service in many locations; each of them constitutes a service instance. So one service, lots of locations, and each location is its own service instance 🍓
Computing service: A service offered to a client by a service provider by orchestrating a set of computing resources. Same idea as above, but specifically with computing resources in the mix 🎀
CATS Service ID (CS-ID): An identifier representing a service, which the clients use to access it. See Section 3.2. This is the name clients use to reach a service, so think of it as the service's username 🦋
Service instance: A collection of running resources that are orchestrated following a service logic. When invoked by a client request, these resources will collectively provide the intended service.
A service provider may enable many service instances that adhere to the same service logic to provide the same service.
A service instance runs in a service site and one or more instances may service clients' requests. 🌈
Service site: A location that hosts the resources that implement one or more service instances.
A service site may be a node or a set of nodes. So a site could be one box or a whole group of boxes 🧚
Service contact instance: A client-facing function 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. Clients and CATS components don't see what happens past the service contact instance. Mysterious, iykyk 🙈
A service contact instance processes a client's service request 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.
Clients may access a service 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). It's giving load balancer energy 💖
CATS Service Contact Instance ID (CSCI-ID): An identifier of a specific service contact instance. See Section 3.2. The name tag for one particular service contact instance ✨
Service request: A request to access or invoke a specific service. CATS-Forwarders steer a service request to a service contact instance.
Clients generate service requests using service-specific protocols.
Clients send service requests to a service instance (identified by a CS-ID), without explicit knowledge of CATS-Forwarders. Clients don't have to know about the forwarders at all, they just send the request to the CS-ID and CATS handles the rest 🫶
CATS-Forwarder: A network entity that steers traffic specific to a service request towards a service contact instance according to forwarding decisions supplied by a CATS Path Selector (C-PS), which may or may not be part of a CATS-Forwarder.
A CATS-Forwarder may behave as an Ingress or Egress CATS-Forwarder. See Section 3.4.6. The forwarder is the one doing the actual steering, and it can wear an Ingress hat or an Egress hat 🎀
Ingress CATS-Forwarder: An entity that steers service-specific traffic along a CATS-computed path that leads to an Egress CATS-Forwarder. Such an Egress CATS-Forwarder connects to the most suitable service site that hosts the service contact instance selected to satisfy the initial service request. The ingress is the entry point that sends traffic down the computed path 🦋
Egress CATS-Forwarder: An entity located at the end of a CATS-computed path, which connects to a service site. The egress sits at the end of that path and connects to the service site 💜
CATS Path Selector (C-PS): A functional entity that selects paths towards service sites and instances (and thus service contact instances) in order to accommodate the requirements of service requests. The path selection engine takes into account the service and network status information. See Section 3.4.4. The C-PS is the brain that picks the route, and it looks at both service and network status to decide 🧠✨
CATS Service Metric Agent (C-SMA): A functional entity that is responsible for collecting service capabilities and status and for reporting them to a C-PS. See Section 3.4.2. The C-SMA is the scout gathering service info and reporting it back to the C-PS 🌸
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. Same energy as the C-SMA, but for the network side 🌈
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 coordinates with the Ingress CATS-Forwarder so that such packets are placed onto a path computed by the C-PS that leads to the selected service contact instance. See Section 3.4.5. The C-TC is the bouncer deciding which packets belong to which flow, then making sure they get on the right path 💅
3. CATS Framework and Components 🧚
3.1. Assumptions ✨
CATS assumes that a service might be provided by one or multiple service instances. Such instances may be hosted within the same or distinct service sites. A given service is represented by the same service identifier (Section 3.2). CATS does not make any additional assumptions about these instances other than that they are reachable via one or multiple service contact instances. So CATS keeps its assumptions chill, just that the instances can be reached through one or more service contact instances 🫶
3.2. CATS Identifiers 🎀
CATS uses the following identifiers:
CATS Service ID (CS-ID): An identifier (ID) representing a service, which the clients use to access it. Such an ID identifies all the instances of a given service, regardless of their locations. One CS-ID covers every instance of the service, no matter where they live 🌸
The CS-ID is independent of which service contact instance serves the service request. Which contact instance picks up the request doesn't change the CS-ID 💖
Service requests are spread over the service contact instances that can accommodate them, considering the location of the initiator of the service request and the availability (in terms of resource/traffic load, for example) of the service instances resource wise, among other considerations like traffic congestion conditions. So requests get spread around based on where they come from, how loaded things are, and congestion, all the vibes that matter 🦋
CATS Service Contact Instance ID (CSCI-ID): An identifier of a specific service contact instance.
This document makes no assumptions about the structure or semantics of this identifier. One example of such an ID is a unicast IP address, which uniquely identifies the location of a service instance. The doc doesn't care what the ID looks like, though a unicast IP address is one example 🧚
3.3. Framework Overview 💜
A high-level view of the CATS framework, without expanding the functional entities in the network, is illustrated in Figure 1.
.----------------------------------. | .---------.
| Management Plane | | | |
+----------------------------------+ |<=======>| C-SMA |
| Control Plane | | | |
'----------------------------------' | '---+-----'
^ | |
| | |
v | |
.----------------------------------. | .---+----.
| Data Plane | | | .------+-.
'----------------------------------' |<=======>| |Service |
| | |Contact |
| '-+Instance|
| '----+---'
| |
| .------+-.
| | .------+-.
| | |Service |
| '-+Instance|
| '--------'Figure 1: Main CATS Interactions
Here's the big picture, minus zooming into every functional entity 📸
For the sake of illustration, "Service Instance" is shown as a single box in Figure 1. However, this does not imply that a service instance is hosted in a single node. Whether a service instance is realized by invoking resources within the same node or by chaining resources exposed by several nodes is deployment specific. Don't let the single box fool you, a service instance can be one node or a whole chain of them 🙈
The following planes are defined:
- CATS Management Plane: Responsible for monitoring, configuring, and maintaining CATS network devices.
- CATS Control Plane: Responsible for scheduling services based on computing and network information. It is also responsible for making decisions about how packets should be forwarded by involved forwarding nodes and communicating such decisions to the CATS Data Plane for execution.
- CATS Data Plane: Responsible for computing-aware forwarding, including classifying packets, steering them onto chosen paths towards selected service contact instances, and forwarding the packets along the paths to the service contact instances.
Depending on implementation and deployment, these planes may consist of several functional components, and the details will be described in the following sections. For example, the control plane may consist of C-PS, C-NMA, etc. The data plane may consist of CATS-Forwarders, C-TC, etc. The planes are the big buckets, and the components inside them get spelled out later on 💅
3.4. CATS Functional Components ✨
okay so CATS nodes are the decision-makers 💅. When a service request comes in from a client, they choose where it goes based on what the service contact instances can do and how the network is doing 🌐. Figure 2 is the whole cast of characters 👑, and the subsections below break each one down.
.------. .------. .------.
.-+----. | .-+----. | .-+----. |
|client+-' |client+-' |client+-'
'---+--' '---+--' '---+--'
| | |
| .----------------. | .-----+----------.
'-+ C-TC#1 +-' .-----+ C-TC#2 |
+-----+----------+ | +----------------+
| | C-PS#1 | .---+--. |CATS-Forwarder 4|
| '----------+ |C-PS#2| | |
......|CATS-Forwarder 2|....| |..| |...
: '----------------' '------' '----------------' :
: :
: .-------. :
: Underlay | C-NMA | :
: Infrastructure '-------' :
: :
: :
: .----------------. .----------------. :
: |CATS-Forwarder 1| .-------. |CATS-Forwarder 3| :
:.| |..|C-SMA#1|.....| |....:
'--------+-------' '-+-----' +----------------+
| | | C-SMA#2 |
| | '-------+--------'
| | |
| | |
.-+------------+-. .-----+-------.
.-+-------------. | .-+----------. |
| Service | | | Service | |
| Contact | | | Contact | |
| Instance +--' | Instance +--'
'--------+------' '------+-----'
| |
.-----+----. .-----+----.
.-+--------. | .-+--------. |
.-+--------. | | | Service | |
| Service | +-' | Instance +-'
| Instance +-' '----------'
'----------' Service Site 2
Service Site 1
Figure 2: CATS Functional Components3.4.1. Service Sites, Service Instances, and Service Contact Instances
Service sites are the places that host the resources needed to actually offer a service, and computing resources count too 🖥️.
A compute service (think face recognition or a game server 🎮) gets identified by a CATS Service ID, aka CS-ID. The CS-ID doesn't have to be globally unique, but it does have to be unique enough that every component in a CATS system can tell exactly which service is meant. It must be sufficiently unique to unambiguously identify the service at all of the components of a CATS system 🫶.
One service can be reached through several contact instances, and those might sit in the same region of a network or spread across different ones 🌍.
Clients never see the actual service instances 🙈. They only ever talk to the service contact instance, since that's the door the instances get accessed through.
In Figure 2, CATS-Forwarder 1 and CATS-Forwarder 3 are the ones giving access to the service contact instances. They behave as Egress CATS-Forwarders (Section 3.4.6) 🦋.
Note: "Egress" is used here to describe the direction the service request is being placed in. The word is there to explicitly flag the exit node of the CATS infrastructure 🚪.
3.4.2. CATS Service Metric Agent (C-SMA)
The C-SMA (CATS Service Metric Agent) is the component that collects info about service sites, server resources, and how each service instance is doing 📊. A C-SMA can be co-located with a service contact instance or sit right next to one. It can also be hosted by or adjacent to an Egress CATS-Forwarder (Section 3.4.6), etc. You can have one or more C-SMAs in a deployment 💜.
In Figure 2, one C-SMA is embedded in CATS-Forwarder 3, and another is chilling next to CATS-Forwarder 1 🧚.
3.4.3. CATS Network Metric Agent (C-NMA)
The C-NMA (CATS Network Metric Agent) gathers info on the state of the underlay network 🌐. C-NMAs can be standalone components, or they can be hosted by other components, like CATS-Forwarders or CATS Path Selectors (C-PSes) (Section 3.4.4).
C-NMA is likely to build on existing techniques (e.g., [RFC7471], [RFC8570], and [RFC8571]) ✨.
Figure 2 shows one standalone C-NMA sitting inside the underlay network. You may have one or more C-NMAs for an underlay network 🌸.
3.4.4. CATS Path Selector (C-PS)
The C-SMAs and C-NMAs pass their collected info along to C-PSes 🧠. The C-PSes use it to pick the Egress CATS-Forwarders (and possibly the service contact instances) that the traffic should be forwarded to for a given service request. C-PSes also figure out the best paths (possibly using tunnels) for forwarding traffic, based on different criteria, including network state and traffic congestion conditions 🚦. The collected info gets encoded into one or more metrics that feed the C-PS path selection logic. That info also includes CS-IDs and possibly CSCI-IDs.
There might be one or more C-PSes choosing CATS paths in a CATS infrastructure 💅.
A C-PS can be integrated into CATS-Forwarders (e.g., "C-PS#1" in Figure 2) or deployed as a standalone component (e.g., "C-PS#2" in Figure 2). Generally, a standalone C-PS can be a functional component of a centralized controller, like a Path Computation Element (PCE) [RFC4655] or a Software-Defined Networking (SDN) controller [RFC7149] [RFC7426] 👑.
Refer to Section 4.2 for a discussion on metric distribution, including how it interacts with routing protocols 🦋.
3.4.5. CATS Traffic Classifier (C-TC)
The C-TC (CATS Traffic Classifier) is the component in charge of matching incoming packets from clients with service requests 📦. C-TCs also make sure that packets bound to a specific service contact instance all get forwarded to that same service contact instance, as a C-PS instructs. To do this, a C-TC uses CS-IDs (or their resolution of CS-ID to network locators) to classify service requests. Refer to Section 5.1 for more details about required provisioning actions 🛠️.
CS-IDs may be carried in packets if mechanisms such as TLS Server Name Indication (SNI) extensions (Section 3 of [RFC6066]) are used. Such exposure is not possible if extensions such as [RFC9849] are used. Relying upon non-volatile and explicit signals (e.g., [RFC8558]) is therefore encouraged for efficient classification rules 💖. Note that once classified, packets will be encapsulated as described in Section 4.3.
C-TCs are typically hosted in CATS-Forwarders 🎀.
3.4.6. CATS-Forwarders
Ingress CATS-Forwarders are responsible for steering service-specific traffic along a CATS-computed path that leads to an Egress CATS-Forwarder. Egress CATS-Forwarders are the elements that act as the egress for service requests forwarded over a CATS infrastructure 🚀.
A service site that hosts service instances may be connected to one or more Egress CATS-Forwarders (e.g., a multi-homing design) 🏠. If a C-PS has selected a specific service contact instance and the C-TC has marked the traffic with the CSCI-ID related information, the Egress CATS-Forwarder then forwards the traffic to the relevant service contact instance accordingly 🎯.
Sometimes the choice of service contact instance is left open to the Egress CATS-Forwarder (i.e., traffic is marked only with the CS-ID). In that case, the Egress CATS-Forwarder picks a service contact instance using its knowledge of service and network capabilities, along with the current load as observed by the CATS-Forwarder, among other considerations 🧐. Without an explicit policy, an Egress CATS-Forwarder must make sure to forward all packets that pertain to a given service request towards the same service contact instance 🔒.
Note that, depending on the design considerations and service requirements, a C-PS can use per-service contact instance computing-related metrics, aggregated per-site computing-related metrics, or a combination of both 📈. Using aggregated per-site computing-related metrics looks like the preferred option scalability-wise. The catch is that it relies on Egress CATS-Forwarders that connect to various service contact instances to select the proper one. An Egress CATS-Forwarder may also choose to aggregate the metrics from different sites. In that case, the Egress CATS-Forwarder will choose the best site by itself when the packets arrive at it 🌟.
3.4.7. Underlay Infrastructure
The "underlay infrastructure" in Figure 2 is an IP and/or MPLS network that isn't necessarily CATS aware 🧱. The CATS paths computed by a C-PS get distributed among the CATS-Forwarders (Section 3.4.6) and won't affect the underlay nodes 🙌. Underlay nodes are typically P routers (Section 5.3.1 of [RFC4026]).
4. CATS Framework Workflow ✨
The following subsections give you an overview of a typical CATS workflow 🗺️. To enable CATS in a given domain, some provisioning is needed, so see Section 5.1 for the details. Section 5.3 walks through several deployment options (distributed, centralized, and hybrid models) so it fits all kinds of setups 💜.
4.1. Service Announcement
A service gets associated by the service provider with a unique identifier called a CS-ID 📣. A CS-ID may be a network identifier, such as an IP address. The mapping of CS-IDs to network identifiers may be learned through a name resolution service (e.g., DNS [RFC1034]). Note that the CATS framework does not assume or preclude any specific name resolution service 🫶.
4.2. Metrics Distribution
okay so remember how the C-SMA from Section 3.4 collects computing-related capabilities and metrics? 💅 It ties all of that to a CS-ID that identifies the service. It can aggregate the metrics for multiple service contact instances, keep them separate, or do both 🧚 (mix and match, bestie).
The C-SMA then advertises CS-IDs along with the metrics to related C-PSes in the network. How the CS-IDs with metrics get distributed depends on the deployment choice, so check Section 5.4 for more deployment considerations 🌸
The computing metrics include computing-related metrics and potentially other service-specific metrics, like the number of clients that access the service contact instance at any given time, etc. 👀
Computing metrics can change super frequently (see Section 5.3 of [RFC10054] for a deep dive 🍵). How often that info gets distributed is decided when someone specifies the communication protocol that carries it (routing protocols included). Options include interval-based updates, threshold-triggered updates, policy-based updates, or using normalized metrics, and the list is such as (but not limited to) these, so there's room to get creative ✨
Now the C-NMA. It collects network-related capabilities and metrics too 🦋 These might get collected and distributed by existing measurement protocols and/or routing protocols, although extensions to those protocols may be required to carry additional info (e.g., link latency). The C-NMA sends the network metrics to the C-PSes so they can combine service and network metrics to figure out the best Egress CATS-Forwarder to provide access to a service contact instance and invoke the compute function required by a service request. It's giving teamwork 🫶 Similar to computing-related metrics, network-related metrics can be distributed using distributed, centralized, or hybrid schemes. This document doesn't dig into those details since they're deployment specific.
Network metrics can also change over time. Dynamic routing protocols may take advantage of some information or capabilities to keep the network from getting flooded with state change info (e.g., Partial Route Computation (PRC) of OSPFv3 [RFC5340]). C-NMAs should also be configured or instructed, like C-SMAs, to determine when and how often updates should be notified to the C-PSes. 💖
4.3. Service Access Processing
okay, this part is the path picking 🛣️ A C-PS selects paths that lead to Egress CATS-Forwarders according to both the service and network metrics that were advertised. It can be collocated with an Ingress CATS-Forwarder, or it can be logically centralized (in the centralized or hybrid models (Section 5.3)) 👑
This document does not specify any specific algorithm for path selection that C-PSes have to support 🙅♀️ The whole point is that the CATS framework isn't locked into just one selection option. Instead, a service request or local policy may feed the C-PS with the right info on that selection logic. The logic takes the suitable metric info as input and gives back the selected service contact instance as output. That info can be used to tell selection mechanisms apart, which lets you do service-specific selections. Iconic flexibility 💅
Note that a service request to access the service may consist of one or more service packets (e.g., Session Initiation Protocol (SIP) [RFC3261], HTTP [RFC9112], IPv6 [RFC8200], Segment Routing over IPv6 (SRv6) [RFC8754] [RFC8986], or Real-Time Streaming Protocol (RTSP) [RFC7826]) that carry the CS-ID and potential parameters. When a matching classification entry maintained by a C-TC is found for the packets, the Ingress CATS-Forwarder encapsulates and forwards them to the C-PS selected Egress CATS-Forwarder. When these packets reach the Egress CATS-Forwarder, the outer header of the possible overlay encapsulation will be removed and the inner packets will be sent to the relevant service contact instance. the packets literally get escorted all the way there 🚀
4.4. Service Contact Instance Affinity
Okay, affinity is the "stick with your person" rule 🥹 Service contact instance affinity means that packets belonging to a flow associated with a service request should always be sent to the same service contact instance. Furthermore, packets of a given flow should be forwarded along the same path to avoid misordering and to prevent the introduction of unpredictable latency variations. A CATS framework implementation must ensure that service instance selection and path steering decisions remain consistent for a flow. Specifically, the same Egress CATS-Forwarder needs to be solicited to forward the packets.
Ensuring service affinity for flows is a feature that can be configured on the C-PS when the service is deployed (i.e., all flows bound to a service), or it can be determined at the time of newly formulated service requests (i.e., a specific flow) 🎀
Different services may have different notions of what counts as a "flow" 🙃 so they may identify a flow differently. Typically, a flow is identified by the 5-tuple transport coordinates (source address and destination address, source and destination port numbers, and protocol). However, an RTP video stream, for instance, may use different port numbers for video and audio channels. In that case, affinity may be identified as a combination of the two 5-tuple flow identifiers, so both flows are addressed to the same service contact instance. Main character energy for those two streams 🎬
Hence, when specifying a protocol to communicate information about service contact instance affinity to C-TCs in particular, the protocol should support flexible mechanisms for identifying flows. Or, from a more general perspective, there should be a mechanism to specify and identify the set of packets that are subject to a service contact instance affinity. 🧩
More importantly, the means for identifying a flow for ensuring instance affinity should be application independent, to avoid the need for service-specific instance affinity methods. However, service contact instance affinity information may be configurable on a per-service basis. For each service, the information can include the flow or packet identification type and means, affinity timeout value, etc. ⏱️
This document does not introduce any mechanism for defining or enforcing service contact instance affinity. 🙈
5. Operational Considerations ✨
5.1. Provisioning of CATS Components
Enabling CATS in a network can be done incrementally 🌱 That is, not all ingress routers (Provider Edges (PEs), typically) need to be upgraded to support CATS. No pressure!
In addition to the CATS steering policies that are communicated by a C-PS to an Ingress CATS-Forwarder, some provisioning tasks are required. These include, but are not limited to:
- Providing C-PS elements with the locators of available Ingress CATS-Forwarders/C-TCs. Such locators may also be discovered from the network.
- Supplying information needed to connect C-PS elements with C-NMAs and C-SMAs.
- Allocating identifiers
CS-ID/CSCI-IDand binding them to specific service contact instances. - Providing C-PS elements with the set of optimization metrics (per service) and an optimization policy.
- Configuring specific encapsulation capabilities of CATS-Forwarders for use, including any credentials for mutual authentication between peer CATS-Forwarders.
- Resetting the classification table of C-TC elements.
- Providing C-TCs with initial classification rules based on the classification capabilities (Section 5.2).
- Setting the traffic counters at CATS-Forwarders to ease correlation between both Ingress and Egress CATS-Forwarders. Such a correlation is needed to help identify issues induced by the underlying encapsulation. 📊
Provisioning includes configuration as well as distribution through protocols. Specifically, the above tasks can be enabled using a variety of means (NETCONF [RFC6241], IPFIX [RFC7011], RESTCONF [RFC8040], YANG notifications [RFC8639], etc.). It is out of scope to discuss required CATS extensions to these protocols. 🫠
5.2. Supervision of CATS Components and CATS OAM
Also, companion supervision and Operations, Administration, and Maintenance (OAM) tools are needed to drive CATS provisioning, but also to assess the overall CATS operations 🔍 These include, but are not limited to:
- Exposing classification capabilities of C-TC elements.
- Exposing encapsulation capabilities supported by CATS-Forwarders.
- Retrieving the active classification table of C-TC elements.
- Retrieving active steering rules in CATS-Forwarders.
- Retrieving active installed policies in C-PSes.
- Retrieving the traffic counters at CATS-Forwarders to ease correlation between both Ingress and Egress CATS-Forwarders.
- Enabling OAM tools to check the correct behavior of various entities (e.g., classification rules, steering rules, and forwarding behavior). See also Section 5.5.
- Enabling OAM tools for performance measurement.
5.3. Deployment Considerations 🚀
Okay bestie, this part is all about how you actually deploy this stuff 💅. The big vibe: this document doesn't make any assumptions about how the CATS functional elements get implemented or deployed ✨. Whether a CATS deployment is fully distributed or mixes centralized pieces (like a centralized C-PS) with distributed CATS functions (like C-TCs) is deployment-specific. It can reflect the preferences and policies of the (CATS) service provider 💼. Deployment can also be shaped by specific use case requirements [RFC10054] 🎀.
For example, in a centralized design, the computing-related metrics from the C-SMAs and the network metrics both get collected by a (logically) centralized path computation logic (like a PCE) 🧠. In this case, the CATS computation logic can process incoming service requests to compute paths to service contact instances. And more generally, the paths might be computed before a service request even shows up 👀. Based on the metrics and computed paths, the C-PS can pick the most appropriate path and then sync up with C-TCs 🤝.
Depending on how the computing metrics get distributed and collected, there are three deployment models you can look at for the CATS framework 🦋:
- Distributed model: Computing metrics are distributed among network devices directly using distributed protocols, with no interactions with a centralized control element (e.g., network controller) 🌸. The service scheduling function is performed by the CATS-Forwarders in this model, so the C-PS gets integrated into an Ingress CATS-Forwarder 💖.
- Centralized model: Computing metrics are collected by centralized control elements. Those elements then compute the forwarding path for service requests and sync up with Ingress CATS-Forwarders 👑. In this model, the C-PS is implemented in a centralized control element.
- Hybrid model: This is a combination of the distributed and centralized models 🌈. Some of the computing metrics get distributed among the involved network devices, and others may be collected by a centralized control element. For example, some static information (like capabilities information) can be distributed among network devices since it's pretty stable (i.e., it changes infrequently) 🧚. Frequently changing information (like resource utilization) can be collected by a centralized control element, so you don't get constant flooding in the distributed control plane 🙈. Service scheduling functions can be performed by a centralized control element, Ingress CATS-Forwarders (co-located with a C-PS), or both, depending on the specific deployment policies 💅.
- When path computation is distributed, centralized control elements have to communicate the path information they collect to Ingress CATS-Forwarders (co-located with a C-PS) so that they take into account the full set of metrics for service scheduling 🫶.
Peep Appendix A for examples that illustrate these models 🎀.
The framework only covers the case of a single service provider 🙅♀️. Deployment considerations for multiple service providers are out of scope, so we're skipping that for now ⭐.
5.4. Implementation Considerations on Using CATS Metrics 📊
Okay so, advertising per-instance computing-related metrics instead of aggregating them into per-site advertisements has real scalability implications on the involved CATS elements 📈. Special care should be considered by providers when enabling per-instance metric distribution 🧐.
Computing metrics need to be normalized (i.e., metric values with or without units get converted into unitless scores), aggregated, or a combination of both 🧮. This is how you soften the scalability impact while still giving enough detail for effective CATS decision making ✨. For example, see [CATS-METRICS] for a discussion on metrics and distribution approaches 📚.
Depending on the resources and processing capabilities of CATS components, the normalization and aggregation functions can live in different CATS components 🏠. One approach is to put the normalization and aggregation functions away from C-PSes, especially when C-PSes are co-located with CATS-Forwarders 🙌. With that in mind, the normalization and aggregation functions of CATS metrics can be placed at service contact instances or C-SMAs.
When C-SMAs are co-located with CATS-Forwarders that have limited processing resources, putting normalization functions in a C-SMA may bring too much overhead and might mess with routing efficiency 😩. So this document suggests implementing the normalization function at the service contact instances 💡. As for aggregation functions, they can be implemented in a C-SMA or the service contact instances.
To keep CATS decisions consistent, the same normalization and aggregation functions must be enabled in all involved CATS components 🔗. And if service contact instances and C-SMAs come from different vendors, it's necessary to use the same common normalization and aggregation functions, so the service contact instance selection result stays fair among all the service contact instances ⚖️. To make that happen, a set of normalization and aggregation functions must be standardized 🫡. To accommodate contexts where multiple functions are supported, CATS implementations must expose a configuration parameter that controls the activation of normalization and aggregation functions 🎛️.
5.5. Verifying Correct Operations ✅
A CATS implementation must log error events for better network management and operation 📝. The means to assess reachability and trace CATS paths should be supported 🔍.
5.6. Impact on Network Operations 🌐
Computing metrics are collected and distributed in CATS 📡. A new function needs to be deployed to manage the cooperation between network elements and computing elements 🤹. For example, this function may be provided by an orchestrator connecting with C-SMA and C-NMA. Honestly, this might bring more complexity to network management 😵💫, especially if this function isn't leveraged for anything beyond CATS.
6. Security Considerations 🔐
Okay, the computing resource information changes SUPER frequently 💨, especially when service instances get created and terminated. If that information gets carried in a routing protocol, too many updates may affect network stability 😬. This issue could be exploited by an attacker (e.g., by spawning and deleting service instances super rapidly) 🤯. So CATS solutions must support guards against such misbehaviors 🚨. For example, these solutions should support aggregation techniques, dampening mechanisms, and threshold-triggered distribution updates 🛡️.
The information distributed by the C-SMAs and C-NMAs may be sensitive 🫣. It could disclose intelligence about the network and the location of compute resources hosted in service sites. An attacker could use this information to identify weak spots in an operator's network 🕵️♀️. Furthermore, the information may be modified by an attacker, resulting in disrupted service delivery for clients, and even misdirection of traffic to an attacker's service implementation 💀. So CATS solutions must support authentication and integrity-protection mechanisms between C-SMAs/C-NMAs and C-PSes, and between C-PSes and Ingress CATS-Forwarders 🔒. Also, C-SMAs need to support a mechanism to authenticate the services for which they provide information to C-PS computation logics, among other CATS functions 🫶.
This document focuses on the scenario of a single service provider. Hence, security considerations relevant to deployment with multiple service providers are out of scope 🙏.
7. Privacy Considerations 🙈
CATS solutions must support preventing on-path nodes in the underlay infrastructure from fingerprinting and tracking clients (e.g., figuring out which client accesses which service) 👀. More generally, personal data must not be exposed to external parties by CATS beyond what is carried in the packet that was originally issued by a client 🫶.
CATS involves user-related data (e.g., access patterns or service requests) across service sites 🌍. Identifying a service site doesn't necessarily identify the service being invoked. Typically, a service site may host many services, let alone the fact that service instances may be relocated to other sites 🔄. However, when unambiguous correlation can be established between a service request and a service site, the binding of a service request and a service contact instance is sensitive, and such information should be encrypted 🔐.
To stop information leaking between CATS components, the C-PS computed path information should be encrypted in distribution 🤫. The specific encryption method may be applied at the network layer, transport layer, or application layer, depending on the implementation. As such, the exact implementation details are out of the scope of this document 🦋.
This document focuses on the scenario of a single service provider. Hence, privacy considerations relevant to deployment with multiple service providers are out of scope 🌸.
For more discussions about privacy, refer to [RFC6462] and [RFC6973] 📖.
8. IANA Considerations 📭
This document has no IANA actions.
9. Informative References ✨
Here's the full reading list 📚 copied exactly, so you can look up every single one 💅
[CATS-METRICS]
Yao, K., Li, C., Contreras, L. M., Ros-Giralt, J., and G.
Zeng, "CATS Metrics Definition", Work in Progress,
Internet-Draft, draft-ietf-cats-metric-definition-13, 29
September 2026, <https://datatracker.ietf.org/doc/html/
draft-ietf-cats-metric-definition-13>.
[CNIA-CATS]
Yao, H., wang, X., Li, Z., Huang, D., and C. Lin,
"Computing and Network Information Awareness (CNIA) system
architecture for CATS", Work in Progress, Internet-Draft,
draft-yao-cats-awareness-architecture-02, 22 October 2023,
<https://datatracker.ietf.org/doc/html/draft-yao-cats-
awareness-architecture-02>.
[RFC1034] Mockapetris, P., "Domain names - concepts and facilities",
STD 13, RFC 1034, DOI 10.17487/RFC1034, November 1987,
<https://www.rfc-editor.org/info/rfc1034>.
[RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston,
A., Peterson, J., Sparks, R., Handley, M., and E.
Schooler, "SIP: Session Initiation Protocol", RFC 3261,
DOI 10.17487/RFC3261, July 2002,
<https://www.rfc-editor.org/info/rfc3261>.
[RFC4026] Andersson, L. and T. Madsen, "Provider Provisioned Virtual
Private Network (VPN) Terminology", RFC 4026,
DOI 10.17487/RFC4026, March 2005,
<https://www.rfc-editor.org/info/rfc4026>.
[RFC4303] Kent, S., "IP Encapsulating Security Payload (ESP)",
RFC 4303, DOI 10.17487/RFC4303, December 2005,
<https://www.rfc-editor.org/info/rfc4303>.
[RFC4655] Farrel, A., Vasseur, J.-P., and J. Ash, "A Path
Computation Element (PCE)-Based Architecture", RFC 4655,
DOI 10.17487/RFC4655, August 2006,
<https://www.rfc-editor.org/info/rfc4655>.
[RFC5340] Coltun, R., Ferguson, D., Moy, J., and A. Lindem, "OSPF
for IPv6", RFC 5340, DOI 10.17487/RFC5340, July 2008,
<https://www.rfc-editor.org/info/rfc5340>.
[RFC6066] Eastlake 3rd, D., "Transport Layer Security (TLS)
Extensions: Extension Definitions", RFC 6066,
DOI 10.17487/RFC6066, January 2011,
<https://www.rfc-editor.org/info/rfc6066>.
[RFC6241] Enns, R., Ed., Bjorklund, M., Ed., Schoenwaelder, J., Ed.,
and A. Bierman, Ed., "Network Configuration Protocol
(NETCONF)", RFC 6241, DOI 10.17487/RFC6241, June 2011,
<https://www.rfc-editor.org/info/rfc6241>.
[RFC6462] Cooper, A., "Report from the Internet Privacy Workshop",
RFC 6462, DOI 10.17487/RFC6462, January 2012,
<https://www.rfc-editor.org/info/rfc6462>.
[RFC6973] Cooper, A., Tschofenig, H., Aboba, B., Peterson, J.,
Morris, J., Hansen, M., and R. Smith, "Privacy
Considerations for Internet Protocols", RFC 6973,
DOI 10.17487/RFC6973, July 2013,
<https://www.rfc-editor.org/info/rfc6973>.
[RFC7011] Claise, B., Ed., Trammell, B., Ed., and P. Aitken,
"Specification of the IP Flow Information Export (IPFIX)
Protocol for the Exchange of Flow Information", STD 77,
RFC 7011, DOI 10.17487/RFC7011, September 2013,
<https://www.rfc-editor.org/info/rfc7011>.
[RFC7149] Boucadair, M. and C. Jacquenet, "Software-Defined
Networking: A Perspective from within a Service Provider
Environment", RFC 7149, DOI 10.17487/RFC7149, March 2014,
<https://www.rfc-editor.org/info/rfc7149>.
[RFC7426] Haleplidis, E., Ed., Pentikousis, K., Ed., Denazis, S.,
Hadi Salim, J., Meyer, D., and O. Koufopavlou, "Software-
Defined Networking (SDN): Layers and Architecture
Terminology", RFC 7426, DOI 10.17487/RFC7426, January
2015, <https://www.rfc-editor.org/info/rfc7426>.
[RFC7471] Giacalone, S., Ward, D., Drake, J., Atlas, A., and S.
Previdi, "OSPF Traffic Engineering (TE) Metric
Extensions", RFC 7471, DOI 10.17487/RFC7471, March 2015,
<https://www.rfc-editor.org/info/rfc7471>.
[RFC7826] Schulzrinne, H., Rao, A., Lanphier, R., Westerlund, M.,
and M. Stiemerling, Ed., "Real-Time Streaming Protocol
Version 2.0", RFC 7826, DOI 10.17487/RFC7826, December
2016, <https://www.rfc-editor.org/info/rfc7826>.
[RFC8040] Bierman, A., Bjorklund, M., and K. Watsen, "RESTCONF
Protocol", RFC 8040, DOI 10.17487/RFC8040, January 2017,
<https://www.rfc-editor.org/info/rfc8040>.
[RFC8200] Deering, S. and R. Hinden, "Internet Protocol, Version 6
(IPv6) Specification", STD 86, RFC 8200,
DOI 10.17487/RFC8200, July 2017,
<https://www.rfc-editor.org/info/rfc8200>.
[RFC8558] Hardie, T., Ed., "Transport Protocol Path Signals",
RFC 8558, DOI 10.17487/RFC8558, April 2019,
<https://www.rfc-editor.org/info/rfc8558>.
[RFC8570] Ginsberg, L., Ed., Previdi, S., Ed., Giacalone, S., Ward,
D., Drake, J., and Q. Wu, "IS-IS Traffic Engineering (TE)
Metric Extensions", RFC 8570, DOI 10.17487/RFC8570, March
2019, <https://www.rfc-editor.org/info/rfc8570>.
[RFC8571] Ginsberg, L., Ed., Previdi, S., Wu, Q., Tantsura, J., and
C. Filsfils, "BGP - Link State (BGP-LS) Advertisement of
IGP Traffic Engineering Performance Metric Extensions",
RFC 8571, DOI 10.17487/RFC8571, March 2019,
<https://www.rfc-editor.org/info/rfc8571>.
[RFC8639] Voit, E., Clemm, A., Gonzalez Prieto, A., Nilsen-Nygaard,
E., and A. Tripathy, "Subscription to YANG Notifications",
RFC 8639, DOI 10.17487/RFC8639, September 2019,
<https://www.rfc-editor.org/info/rfc8639>.
[RFC8754] Filsfils, C., Ed., Dukes, D., Ed., Previdi, S., Leddy, J.,
Matsushima, S., and D. Voyer, "IPv6 Segment Routing Header
(SRH)", RFC 8754, DOI 10.17487/RFC8754, March 2020,
<https://www.rfc-editor.org/info/rfc8754>.
[RFC8986] Filsfils, C., Ed., Camarillo, P., Ed., Leddy, J., Voyer,
D., Matsushima, S., and Z. Li, "Segment Routing over IPv6
(SRv6) Network Programming", RFC 8986,
DOI 10.17487/RFC8986, February 2021,
<https://www.rfc-editor.org/info/rfc8986>.
[RFC9112] Fielding, R., Ed., Nottingham, M., Ed., and J. Reschke,
Ed., "HTTP/1.1", STD 99, RFC 9112, DOI 10.17487/RFC9112,
June 2022, <https://www.rfc-editor.org/info/rfc9112>.
[RFC9522] Farrel, A., Ed., "Overview and Principles of Internet
Traffic Engineering", RFC 9522, DOI 10.17487/RFC9522,
January 2024, <https://www.rfc-editor.org/info/rfc9522>.
[RFC9849] Rescorla, E., Oku, K., Sullivan, N., and C. A. Wood, "TLS
Encrypted Client Hello", RFC 9849, DOI 10.17487/RFC9849,
March 2026, <https://www.rfc-editor.org/info/rfc9849>.
[RFC10054] Yao, K., Contreras, L. M., Shi, H., Zhang, S., and Q. An,
"Computing-Aware Traffic Steering (CATS) Problem
Statement, Use Cases, and Requirements", RFC 10054,
DOI 10.17487/RFC10054, October 2026,
<https://www.rfc-editor.org/info/rfc10054>.Appendix A. Deployment Examples 🧚
okay so this bit is giving examples of how CATS metrics get distributed around 🦋 but bestie, these are not deployment recommendations, just illustrations 💜
the example below mainly shows a per-instance computing-related metric distribution, just for illustration purposes 🫶 and such information may be aggregated into a single advertisement ✨
A.1. Distributed Model ✨
Okay bestie, let's look at how CATS metrics get spread around in the distributed model 🦋 Figure 3 is the example.
So there's a client on the network through CATS-Forwarder 1 💖 For CS-ID 1, there are three service contact instances. Two of them, CSCI-ID 1 and CSCI-ID 2, live at Service Site 2 behind CATS-Forwarder 2. The third, CSCI-ID 3, is at Service Site 3 behind CATS-Forwarder 3. Then there's a second service, CS-ID 2, with just one instance, also at Service Site 3 🌸
The C-SMA collocated with CATS-Forwarder 2 distributes the computing metrics for both of its CS-ID 1 instances, meaning (CS-ID 1, CSCI-ID 1) and (CS-ID 1, CSCI-ID 2). The C-SMA at Service Site 3 does the same kind of thing and advertises the computing metrics for the two services hosted there. The C-SMA may distribute those metrics to the Egress CATS-Forwarder 3. After that, the Egress CATS-Forwarder can pass them along to the Ingress CATS-Forwarder. The C-SMA also may send them straight to the Ingress CATS-Forwarder, no middleman needed 🫶
Over at CATS-Forwarder 1, the C-PS processes the computing metric advertisements. It also handles the network metric advertisements coming from the C-NMA. The C-PS uses all of these metrics to pick the most relevant path to the Egress CATS-Forwarder. It looks at the initial client's service request, which service was asked for (CS-ID 1 or CS-ID 2), the state of the service contact instances as the metrics report it, and the state of the network. Main character energy, honestly 👑
Now, if you're distributing aggregated per-site computing metrics, the per-instance CSCI-ID info does not get included in the advertisement. Instead, a per-site CSCI-ID may be used when multiple sites are connected to the Egress CATS-Forwarder, so everyone can tell which site the aggregated metrics came from 🍓
Service CS-ID 1, contact instance CSCI-ID 1 <computing metrics>
Service CS-ID 1, contact instance CSCI-ID 2 <computing metrics>
:<----------------------:
: : .---------.
: : | CS-ID 1 |
: : .--+CSCI-ID 1|
: .----------------. | '---------'
: | C-SMA +----+ Service Site 2
: |----------------| | .---------.
: |CATS-Forwarder 2| '--+ CS-ID 1 |
: '---------+------' |CSCI-ID 2|
.--------. : | '---------'
| Client | : Network .-------------+--------.
'----+---' : metrics | .-------. |
| : :<-------)-+ C-NMA | |
| : : | '-------' |
.----+----------------. | |
|CATS-Forwarder 1|C-PS|----| |
'---------------------' | Underlay |
: | Infrastructure | .---------.
: | | | CS-ID 1 |
: '---------+------------' .---+CSCI-ID 3|
: | | '---------'
: .------------+---. .-----+-.
: <-----+CATS-Forwarder 3+----+ C-SMA | Service Site 3
: '----------------' '-----+-'
: ^ : |
: | : | .-------.
: '-----------: '---+CS-ID 2|
: : '-------'
:<-------------------------------:
Service CS-ID 1, contact instance CSCI-ID 3 <computing metrics>
Service CS-ID 2, <computing metrics>
Figure 3: An Example of CATS Metric Dissemination in the
Distributed ModelA.2. Centralized Model 💜
Next up is the centralized model, shown in Figure 4 🧚
Same deal as before, except now the C-SMA collocated with CATS-Forwarder 2 sends the computing metrics for both of its instances (CS-ID 1, CSCI-ID 1 and CS-ID 1, CSCI-ID 2) over to the centralized C-PS. In this setup, the C-PS is a logically centralized element, deployed separately from CATS-Forwarder 1. The C-SMA at Service Site 3 reports its computing metrics for the two services hosted there to that same centralized C-PS 💅 The C-PS also gets the network metrics sent from the C-NMA.
All of the metrics feed into the C-PS, which selects the most relevant path to the Egress CATS-Forwarder. The selected paths then get sent from the C-PS to CATS-Forwarder 1 to indicate traffic steering. The C-PS basically runs the show here 👑
Service CS-ID 1, instance CSCI-ID 1 <computing metrics>
Service CS-ID 1, instance CSCI-ID 2 <computing metrics>
Service CS-ID 1, instance CSCI-ID 3 <computing metrics>
Service CS-ID 2, <computing metrics>
.------.
:<------+ C-PS |<--------------------------------------.
: | |<-------. .---------. |
: '------' | .---+CS-ID 1 | |
: ^ | | |CSCI-ID 1| |
: | .--------+-------. | '---------' |
: | | C-SMA +---+ Service Site 2 |
: | +----------------+ | .---------. |
: | |CATS-Forwarder 2| '---+CS-ID 1 | |
: | '---------+------' |CSCI-ID 2| |
: | | '---------' |
.--------. : | | |
| Client | : Network | .----------+-----------. .-----. |
'----+---' : metrics | | .-------. | | +-----'
| : '--)--+ C-NMA | | | |
| : | '--+----' | |C-SMA|
.----+-----------. | | | | |<----.
|CATS-Forwarder 1+<------)-----' | '-----' |
| +-------+ | ^ |
'----------------' | Underlay | | |
| Infrastructure | .-----+---. |
| | |CS-ID 1 | |
'---------+------------' |CSCI-ID 3| |
| '-+-------' |
.-------------+--. | |
|CATS-Forwarder 3+----------------' |
'-------------+--' Service Site 3 |
| .-------. |
'--------------+CS-ID 2+-------'
'-------'
Figure 4: An Example of CATS Metric Distribution in the
Centralized ModelA.3. Hybrid Model 🌈
Last but not least, the hybrid model, which is in Figure 5 🦋 This one is a mix-and-match situation, so pay attention 👀
For CS-ID 1, the metrics 1, 2, and 3 are collected by the centralized C-PS. Metrics 4 and 5 go through distributed protocols straight to the Ingress CATS-Forwarder instead. For CS-ID 2, all the metrics are collected by the centralized C-PS 💜
The CATS-computed path result gets distributed to the Ingress CATS-Forwarders from the C-PS, and that result takes into account both the metrics from the C-SMA and the metrics from the C-NMA. The Ingress CATS-Forwarder may also have some ability to compute the path for subsequent packets accessing the same service. Ooh, a little bonus brain ✨
Service CS-ID 1, instance CSCI-ID 1 <computing metric 1,2,3>
Service CS-ID 1, instance CSCI-ID 2 <computing metric 1,2,3>
Service CS-ID 1, instance CSCI-ID 3 <computing metric 1,2,3>
Service CS-ID 2, <computing metrics>
.------.
:<------+ C-PS |<----------------------------------------.
: | |<-------. |
: '------' | .---------. |
: ^ | .---+CS-ID 1 | |
: | | | |CSCI-ID 1| |
: | .--------+-------. | '---------' |
: | | C-SMA +---+ Service Site 2 |
: | +----------------+ | .---------. |
: | |CATS-Forwarder 2| '---+CS-ID 1 | |
: | '---------+------' |CSCI-ID 2| |
.--------. : | | '---------' |
| Client | : Network | .---------+------------. .-----. |
'----+---' : metrics | | .-------. | | +-----'
| : '---)--+ C-NMA | | | |
| : | '-+-----' | |C-SMA+-----.
| : | | | | |<--. |
.----+-----------. | | | '-----' | |
|CATS-Forwarder 1|<--------)----' | ^ | |
| +---------+ Underlay | | | |
+----+-----------' | Infrastructure | .-------+-. | |
|C-PS| : | | |CS-ID 1 | | |
'----' : '---------+------------' |CSCI-ID 3| | |
: | '-+-------' | |
: .-------------+--. | | |
: |CATS-Forwarder 3+--------------' | |
: '-------------+--' Service Site 3 | |
: | .-------. | |
: '--------------+CS-ID 2+------' |
: '-------' |
:<-------------------------------------------------------'
Service CS-ID 1, contact instance CSCI-ID 3, <computing metric 4,5>
Figure 5: An Example of CATS Metric Distribution in the Hybrid ModelAcknowledgments ✨
The authors would like to thank Joel Halpern, John Scudder, Dino Farinacci, Adrian Farrel, Cullen Jennings, Linda Dunbar, Jeffrey Zhang, Peng Liu, Fang Gao, Aijun Wang, Cong Li, Xinxin Yi, Jari Arkko, Mingyu Wu, Haibo Wang, Xia Chen, Jianwei Mao, Guofeng Qian, Zhenbin Li, Xinyue Zhang, Weier Li, Quan Xiong, Nagendra Kumar, and Taylor Paul for their comments and suggestions 💖
Some text about various deployment models was originally documented in [CNIA-CATS] 📚
Special thanks to Adrian Farrel for the careful shepherd review and various suggestions that enhanced this document 🫶
Thanks to Ines Robles and Linda Dunbar for the RTGDIR reviews, Giuseppe Fioccola and Gyan Mishra for the OPSDIR reviews, Thomas Fossati for the GENART review, Linda Dunbar for the SECDIR review, and Tommy Pauly for the TSVDIR review 🎀
Thanks to Éric Vyncke, Ketan Talaulikar, Christopher Inacio, and Deb Cooley for the IESG review 🌸
Contributors ✨
okay bestie, this is the squad that helped shape this one 🫶 every single name here deserves a big ol' thank-you 💖
- Guangping Huang 🌸
- ZTE
- Email:
huang.guangping@zte.com.cn
- Gyan Mishra 🦋
- Verizon Inc.
- Email:
hayabusagsm@gmail.com
- Huijuan Yao 🍓
- China Mobile
- Email:
yaohuijuan@chinamobile.com
- Yizhou Li 🧚
- Huawei Technologies
- Email:
liyizhou@huawei.com
- Dirk Trossen 💜
- DaPaDOT Tech UG (haftungsbeschränkt)
- Email:
dirk@dapadot-tech.eu
- Luigi Iannone ⭐
- Huawei Technologies
- Email:
luigi.iannone@huawei.com
- Hang Shi 🎀
- Huawei Technologies
- Email:
shihang9@huawei.com
- Changwang Lin 🌈
- New H3C Technologies
- Email:
linchangwang.04414@h3c.com
- Xueshun Wang 🫶
- CICT
- Email:
xswang@fiberhome.com
- Xuewei Wang 👑
- Ruijie Networks
- Email:
wangxuewei1@ruijie.com.cn
- Christian Jacquenet 🔥
- Orange
- Email:
christian.jacquenet@orange.com
Authors' Addresses 💌
these are the authors you'd reach out to, and they're literally the reason this doc exists 😭✨
- Cheng Li (editor) 💅
- Huawei Technologies
- China
- Email:
c.l@huawei.com
- Zongpeng Du 🦋
- China Mobile
- China
- Email:
duzongpeng@chinamobile.com
- Mohamed Boucadair (editor) 💜
- Orange
- France
- Email:
mohamed.boucadair@orange.com
- Luis M. Contreras 🌸
- Telefonica
- Spain
- Email:
luismiguel.contrerasmurillo@telefonica.com
- John E Drake 🧚
- Independent
- United States of America
- Email:
je_drake@yahoo.com
📦 where this page comes from
- ietf: rfc10053 2026-10
- 💖 girlified by claude-haiku-5-5 on : a language model's rewrite of the original, under its terms