Protocols Applicability for Computing-Aware Traffic Steering (CATS)
draft-yxl-cats-protocols-applicability-01
This document is an Internet-Draft (I-D).
Anyone may submit an I-D to the IETF.
This I-D is not endorsed by the IETF and has no formal standing in the
IETF standards process.
| Document | Type | Active Internet-Draft (individual) | |
|---|---|---|---|
| Authors | Huijuan Yao , Linda Dunbar , Quan Xiong , Changwang Lin | ||
| Last updated | 2026-07-02 | ||
| RFC stream | (None) | ||
| Intended RFC status | (None) | ||
| Formats | |||
| Stream | Stream state | (No stream defined) | |
| Associated None milestones |
|
||
| Consensus boilerplate | Unknown | ||
| RFC Editor Note | (None) | ||
| IESG | IESG state | I-D Exists | |
| Telechat date | (None) | ||
| Responsible AD | (None) | ||
| Send notices to | (None) |
draft-yxl-cats-protocols-applicability-01
cats H. Yao
Internet-Draft China Mobile
Intended status: Informational L. Dunbar
Expires: 3 January 2027 Futurewei
Q. Xiong
ZTE Corporation
C. Lin
New H3C Technologies
2 July 2026
Protocols Applicability for Computing-Aware Traffic Steering (CATS)
draft-yxl-cats-protocols-applicability-01
Abstract
This document analyzes the applicability of protocols related to a
CATS system, and describes how to build a CATS system by extending
existing IETF protocols.
Status of This Memo
This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
This Internet-Draft will expire on 3 January 2027.
Copyright Notice
Copyright (c) 2026 IETF Trust and the persons identified as the
document authors. All rights reserved.
Yao, et al. Expires 3 January 2027 [Page 1]
Internet-Draft Protocols Applicability for CATS July 2026
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents (https://trustee.ietf.org/
license-info) in effect on the date of publication of this document.
Please review these documents carefully, as they describe your rights
and restrictions with respect to this document. Code Components
extracted from this document must include Revised BSD License text as
described in Section 4.e of the Trust Legal Provisions and are
provided without warranty as described in the Revised BSD License.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Conventions Used in This Document . . . . . . . . . . . . . . 3
2.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3
2.2. Requirements Language . . . . . . . . . . . . . . . . . . 3
3. CATS Applicability Overview . . . . . . . . . . . . . . . . . 3
3.1. Control Plane Applicability Analysis . . . . . . . . . . 4
3.2. Management Plane Applicability Analysis . . . . . . . . . 4
3.3. Data Plane Applicability Analysis . . . . . . . . . . . . 4
4. Protocols Applicability to CATS . . . . . . . . . . . . . . . 4
4.1. BGP Applicability for Metrics Distribution . . . . . . . 4
4.2. IGP and BGP-LS Applicability for Metrics Distribution . . 6
4.2.1. IGP Applicability . . . . . . . . . . . . . . . . . . 6
4.2.2. BGP-LS Applicability . . . . . . . . . . . . . . . . 7
4.3. PCEP Applicability for Service-aware Computing . . . . . 8
4.4. BGP-FS Applicability for Service Mapping . . . . . . . . 9
4.5. BGP SR Policy Applicability for Service-aware Candidate
Paths . . . . . . . . . . . . . . . . . . . . . . . . . . 10
4.6. Yang Model Applicability for Service Configuration and
Management . . . . . . . . . . . . . . . . . . . . . . . 12
4.7. Data plane Protocols Applicability for Forwarding CATS
Packets . . . . . . . . . . . . . . . . . . . . . . . . . 13
5. Security Considerations . . . . . . . . . . . . . . . . . . . 13
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13
7. References . . . . . . . . . . . . . . . . . . . . . . . . . 13
7.1. Normative References . . . . . . . . . . . . . . . . . . 13
7.2. Informative References . . . . . . . . . . . . . . . . . 14
Appendix A. BGP Edge Metadata Path Applicability . . . . . . . . 17
A.1. Summary of 5G Edge Service Metadata Mechanism . . . . . . 17
A.1.1. Attribute Structure . . . . . . . . . . . . . . . . . 17
A.1.2. High-Level Distribution Behavior . . . . . . . . . . 17
A.2. Applicability of 5G Edge Metadata to CATS Metrics . . . . 17
A.2.1. Compute/Resource Capability (CATS L1/L2) . . . . . . 17
A.2.2. Compute/Resource Availability (CATS L1) . . . . . . . 18
A.2.3. Service Processing Delay (CATS L0 or L1) . . . . . . 18
A.2.4. Traffic Load / Utilization (CATS L0-L1/L2 . . . . . . 18
A.2.5. Site Preference (CATS L2 policy metric) . . . . . . . 18
A.2.6. Site Physical Availability (CATS Shared Resource) . . 18
Yao, et al. Expires 3 January 2027 [Page 2]
Internet-Draft Protocols Applicability for CATS July 2026
A.2.7. Expressiveness, Granularity, Update Semantics . . . . 19
A.3. Metric Lifetimes . . . . . . . . . . . . . . . . . . . . 19
A.4. Granularity Semantics Issues . . . . . . . . . . . . . . 20
A.5. Scalability and Churn Considerations . . . . . . . . . . 20
A.6. Gaps and Extensions Needed for CATS Compliance . . . . . 21
Contributors . . . . . . . . . . . . . . . . . . . . . . . . . . 21
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 21
1. Introduction
[I-D.ietf-cats-framework] introduces a framework for Computing-Aware
Traffic Steering (CATS). This document analyzes the corresponding
protocols in control plane, management plane and data plane, and
evaluates how far the existing protocols or be extended to support
CATS such as metrics distribution and their operational requirements.
2. Conventions Used in This Document
2.1. Terminology
The terms defined in [I-D.ietf-cats-framework] can be used in this
document.
This document uses the terms "Service Contact Instance (SCI)",
"Service", "Compute Resource", "Shared Resource", and "CATS Metric
Levels (L0/L1/L2)" as defined in [I-D.ietf-cats-framework] and
[I-D.ietf-cats-metric-definition].
2.2. Requirements Language
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described in BCP
14 [RFC2119] [RFC8174] when, and only when, they appear in all
capitals, as shown here.
3. CATS Applicability Overview
As defined in [I-D.ietf-cats-framework], the CATS framework structure
consists of the C-SMA (responsible for maintaining service metrics),
the C-NMA (responsible for maintaining network metrics), the C-PS
(responsible for maintaining forwarding table entries), and the C-TC
(responsible for traffic classification).
Yao, et al. Expires 3 January 2027 [Page 3]
Internet-Draft Protocols Applicability for CATS July 2026
3.1. Control Plane Applicability Analysis
The control plane protocols are used to distribute the CATS metrics
of service,then to chose forwarding paths to the CATS service's
destinatios. Based on [I-D.ietf-cats-framework], various relevant
computing metrics are defined in [I-D.ietf-cats-metric-definition],
which can be used in CATS. However, the protocols and technologies
for distributing metrics from the egress gateway to the ingress
gateway are still under research.Extensible protocols include YANG,
BGP existing attribute, new BGP address family, FlowSpec, or BGP-LS.
In addition, The FlowSpec protocol can be extended to accommodate the
selection of CATS service paths. In addition, the control protocols
are capable of controlling traffic classification include FlowSpec
and YANG model. The FlowSpec is a distributed control method, while
the YANG model is a centralized control method. These two protocol
models can be extended to classify CATS data traffics.
3.2. Management Plane Applicability Analysis
Management plane protocols are used to manage and configure CATS
systems. Existing PING and TRACE protocols may be utilized in CATS
networks. These protocols could be extended to operate on specific
CATS Service Identifiers (CS-IDs). Alternatively, YANG models could
be extended to report statistical information about CATS flows for
monitoring purposes.
3.3. Data Plane Applicability Analysis
The data plane protocols are used to forward the CATS traffiic to the
corresponding destination by existing rotocols IPv4/IPv6 or IPv4/IPv6
over SRv6.
4. Protocols Applicability to CATS
4.1. BGP Applicability for Metrics Distribution
As defined in [I-D.ietf-cats-framework] section 4.2, the CATS Service
Metric Agent (C-SMA) collects computing-related capabilities and
metrics, associates them with a CS-ID and/or one or more Service
Contact Instances (SCIs), and distributes the computing metrics to
the CATS Path Selectors (C-PSes). The CATS Network Metric Agent
(C-NMA) collects network-related capabilities and metrics and
distributes the network metrics to the C-PSes. The C-PSes use the
combination of computing and network metrics to determine the
appropriate egress CATS-Forwarder that provides access to a service
contact instance and invokes the compute function required by a
service request.
Yao, et al. Expires 3 January 2027 [Page 4]
Internet-Draft Protocols Applicability for CATS July 2026
BGP is applicable to CATS metric distribution when the metrics need
to be distributed among multiple routing or control-plane nodes
within a controlled administrative domain. BGP already provides
scalable mechanisms for distributing routing information, including
route reflection, policy-based propagation, incremental UPDATE
processing, and attribute filtering. Similar to the use of BGP-LS to
distribute link-state and traffic engineering information to external
consumers, BGP can be used in CATS to distribute service-related and
compute-related information from egress CATS-Forwarders, controllers,
or metric agents to the nodes that perform CATS path selection.
In a CATS deployment, BGP can be used to associate service or compute
metrics with reachability information for a service prefix, a CS-ID,
an SCI, an egress CATS-Forwarder, or a site. The Edge Metadata Path
Attribute defined in [I-D.ietf-idr-5g-edge-service-metadata] provides
an example BGP-based mechanism for advertising edge-service-related
metadata, including availability, preference, delay prediction, and
resource status. These metadata elements are relevant to CATS
because they can represent normalized compute capability, available
resource level, service processing delay, traffic load or
utilization, operator preference, and site or shared-resource
availability.
BGP is most suitable for distributing CATS metrics that are
relatively stable or moderately dynamic, especially abstracted L1/L2
metrics as defined by the CATS metric definition draft. Examples
include normalized compute capability, normalized available-resource
level, service delay prediction, site preference, and site physical
availability. Such metrics can be used by the C-PS or ingress CATS-
Forwarder to compare candidate service locations without exposing raw
infrastructure details.
BGP is less suitable for distributing highly dynamic raw L0
measurements, such as instantaneous CPU load, memory pressure, queue
depth, per-flow utilization, or other rapidly changing telemetry
values. Advertising such values directly through BGP could cause
excessive UPDATE churn and may negatively affect routing stability.
Therefore, highly dynamic measurements SHOULD be collected locally,
smoothed, thresholded, aggregated, or converted into normalized
metrics before being advertised through BGP. BGP SHOULD NOT be used
as a sub-second telemetry transport for CATS.
The applicability of BGP also depends on the granularity and scope of
the metric. A metric may apply to an individual SCI, to all
instances of a service at a site, to an egress CATS-Forwarder, to a
site, or to a shared resource such as a resource pool, accelerator
cluster, rack, room, or data center. When multiple SCIs are
reachable through the same anycast service prefix, the BGP encoding
Yao, et al. Expires 3 January 2027 [Page 5]
Internet-Draft Protocols Applicability for CATS July 2026
needs to make clear whether the metric applies to the aggregate
service, to a specific SCI, or to a shared resource that affects
multiple SCIs.
BGP-based CATS metric distribution is expected to be used primarily
within a limited domain. CATS service and compute metrics can expose
information about resource availability, site preference, or
operational state. Therefore, such information SHOULD be distributed
only to authorized CATS nodes. Existing BGP mechanisms, including
route filtering, route reflection policy, non-transitive attributes,
community-based controls, and administrative boundary filtering, can
be used to constrain propagation.
In summary, BGP is applicable to CATS when the objective is to
distribute abstracted service and compute metrics within a controlled
routing domain, reuse existing BGP scaling mechanisms, and
synchronize path-selection input across multiple C-PSes or ingress
CATS-Forwarders. However, additional CATS-specific BGP extensions or
encoding rules may be required to support explicit per-SCI metric
association, resource-type identification, metric freshness or
validity indication, and shared-resource scope identification.
Detailed analysis of the applicability of the BGP Edge Metadata Path
Attribute to CATS metrics is provided in Appendix A.
4.2. IGP and BGP-LS Applicability for Metrics Distribution
4.2.1. IGP Applicability
As defined in [I-D.ietf-cats-framework], the CATS Network Metric
Agent (C-NMA) maintains information about the state of the underlay
network. Existing IGP Traffic Engineering extensions, such as the
OSPF TE metric extensions defined in [RFC7471] and the IS-IS TE
metric extensions defined in [RFC8570], can advertise network
characteristics associated with links, nodes, and prefixes. These
characteristics include delay, delay variation, packet loss, residual
bandwidth, available bandwidth, and utilized bandwidth.
However, most CATS metrics describe the condition or capability of
the sites where services are hosted rather than the state of the
network. Previous work [I-D.dunbar-lsr-5g-edge-compute] explored the
use of IGP extensions to advertise site-capacity and site-preference
values and to make those values available to routing computations.
Feedback from the LSR WG concluded that IGP (OSPF, OSPF-TE, IS-IS) is
not suitable for distributing CATS metrics for the following reasons:
Yao, et al. Expires 3 January 2027 [Page 6]
Internet-Draft Protocols Applicability for CATS July 2026
IGP floods link-state information to every router in the domain.
CATS metrics from a specific service site or datacenter are only
relevant to C-PSes making forwarding decisions, not to every router
in the network.
IGP has no native mechanism to constrain which nodes receive which
information. CATS metrics from one operator's datacenter must not
leak to another operator's domain, and IGP has no capability to
enforce that boundary.
IGP was designed for topology and link metrics, not for frequently
changing compute/service metrics from potentially many service
instances. Flooding dynamic CATS metrics (CPU load, memory
availability, etc.) across an entire IGP domain would cause
significant churn and instability.
IGP metrics are fundamentally tied to links and nodes in the network
topology. CATS metrics are associated with services and compute
resources, which don't map naturally onto IGP's link-state model.
One exception worth noting is that aggregated values — such as a
single normalized service delay metric associated with a node — could
in principle be carried within existing IGP extensions without
requiring new semantic constructs. However, even in this limited
case, IGP would flood such values to all routers in the domain,
imposing processing and database overhead on every intermediate node
regardless of whether it participates in CATS forwarding decisions.
This u nnecessary burden on non-CATS routers further reinforces the
conclusion that IGP is a poor fit for distributing CATS metrics, even
in simplified aggregated form.
4.2.2. BGP-LS Applicability
BGP Link State (BGP-LS) [RFC9552] provides a mechanism for exporting
network topology and traffic engineering information collected by IGP
from within a routing domain to external consumers, such as a Path
Computation Element (PCE) or a Software Defined Networking (SDN)
controller, without those consumers needing to participate in the IGP
itself. In the CATS context, BGP-LS could be used to export network
metrics collected by the C-NMA to the C-PS.
Yao, et al. Expires 3 January 2027 [Page 7]
Internet-Draft Protocols Applicability for CATS July 2026
While BGP-LS addresses some of the IGP limitations described in
Section 4.2.1, i.e. by targeting specific consumers rather than
flooding to all routers , it inherits a fundamental constraint: BGP-
LS was designed to carry network topology and link-state information,
not compute or service metrics associated with sites and service
instances. Extending BGP-LS to carry CATS metrics would therefore
require new TLV definitions to represent service and compute
attributes that have no natural counterpart in the existing BGP-LS
schema.
Furthermore, BGP-LS does not natively support the administrative
boundary enforcement that CATS requires. CATS metrics originating
within one operator's datacenter must not leak into domains managed
by other operators. This can only be addressed if the BGP-LS
attribute carrying CATS metrics is marked as non-transitive, ensuring
that such metrics are automatically dropped at administrative
boundaries and do not propagate beyond the domain in which they
originated. Without this constraint, CATS metrics risk leaking
across operator boundaries, violating the privacy and policy
requirements of individual operators.
4.3. PCEP Applicability for Service-aware Computing
As defined in [I-D.ietf-cats-framework] section 3.4.4, C-PSes is
responsible for determining the best paths to forward traffic based
on computing and network metrics. A standalone C-PS can be
implemented as a Path Computation Element (PCE), leveraging the Path
Computation Element Protocol (PCEP) [RFC5440] to communicate with
Path Computation Clients (PCCs), such as ingress CATS-Forwarders.
PCEP applies primarily to the path computation function within the
CATS framework, specifically enabling the C-PS (acting as a PCE) to
compute and distribute optimal paths that consider both network
conditions (from the C-NMA) and computing metrics (from the C-SMA).
The protocol facilitates communication between the C-PS (PCE) and
ingress CATS-Forwarders (PCCs), ensuring that traffic is steered to
the most suitable egress CATS-Forwarder and Service Contact Instance
(SCI) based on composite metrics. PCEP may also be used by the C-PS
to distribute computed paths along with associated service
identifiers (e.g., CS-ID or CSCI-ID) to ingress nodes. PCEP carries
path computation requests and responses between PCCs and the PCE
(C-PS). In the context of CATS, these messages may include:
* Network topology and metric information (e.g., from C-NMA) for
underlay path computation.
Yao, et al. Expires 3 January 2027 [Page 8]
Internet-Draft Protocols Applicability for CATS July 2026
* Computing metrics (e.g., from C-SMA) associated with CS-IDs or
SCIs, such as normalized compute capability, resource availability,
service delay, or load conditions.
* Identifiers for the selected egress CATS-Forwarder, SCI, or shared
resource (e.g., CS-ID, CSCI-ID), to specify the service destination.
PCEP session establishment, maintenance, and error-handling
procedures is defined as per [RFC5440] and Path computation request
(PCReq) and response (PCRep) messages are designed for basic path
setup and delegation. Stateful PCEP [RFC8231] is applicable for
dynamic path management, updates, and synchronization between PCE and
PCC, which is useful for handling CATS metrics changes. Mechanisms
for multi-domain path computation (e.g., H-PCE [RFC8685] ) if CATS
spans multiple administrative domains.
PCEP is primarily designed for network path computation and does not
natively support computing metrics and the selection of service
instances. Without extensions, it cannot directly convey compute-
related parameters (e.g., CPU load or service delay) in path requests
or responses and cannot select the egress router associated with the
service instances. PCEP relies on a centralized PCE (C-PS) model,
which may become a scalability bottleneck in large-scale CATS
deployments with numerous ingress points, frequent metric updates, or
rapid service churn.
In summary, PCEP is applicable to CATS for path computation and
distribution, particularly in centralized deployments where the C-PS
acts as a PCE. Existing PCEP mechanisms provide a foundation for
reliable path setup, but extensions are required to handle computing-
aware metrics, service identifiers, and dynamic updates.
4.4. BGP-FS Applicability for Service Mapping
As defined in [I-D.ietf-cats-framework] section 3.4.4, a standalone
CATS Path Selector (C-PS) can be implemented as a functional
component of a centralized controller. BGP Flow Specification (BGP-
FS) provides a mechanism for distributing traffic steering policies
that can be leveraged by the C-PS to implement computing-aware
traffic steering decisions.
BGP-FS applies to the traffic classification and steering functions
within the CATS framework, specifically enabling the C-PS to
distribute fine-grained traffic steering policies to ingress CATS-
Forwarders. The protocol facilitates the mapping between service
characteristics (identified by CS-IDs or CSCI-ID) and the appropriate
forwarding actions that consider both network paths and computing
resource availability. BGP-FS allows the C-PS to implement
Yao, et al. Expires 3 January 2027 [Page 9]
Internet-Draft Protocols Applicability for CATS July 2026
distributed traffic steering policies that can react dynamically to
changes in computing resource conditions across multiple service
locations.
The BGP Flow Specification framework [RFC8955] for IPv4 and [RFC8956]
for IPv6, which defines the base protocol mechanisms for distributing
flow specifications. Flow specification version 2 (FSv2)
[I-D.ietf-idr-flowspec-v2] extensions that provide additional
matching capabilities relevant for service identification. MPLS
label matching and actions [I-D.ietf-idr-flowspec-mpls-match] ,
[I-D.ietf-idr-bgp-flowspec-label] for integration with MPLS-based
CATS deployments. SRv6 policy steering mechanisms
[I-D.ietf-idr-ts-flowspec-srv6-policy] for Segment Routing
environments. BGP's inherent route reflection and policy control
mechanisms for scalable distribution within a CATS domain.
BGP-FS is primarily designed for traffic filtering and redirection
based on layer 3/4 parameters, and does not natively support the
association of computing metrics with flow specifications. Without
extensions, it cannot directly encode compute-aware steering
decisions. The protocol may introduce scalability challenges when
dealing with fine-grained service mappings, as each CS-ID or SCI
might require distinct flow specifications, potentially leading to a
large number of BGP updates. BGP-FS policies are typically
distributed based on administrative boundaries, which may not align
perfectly with the dynamic, resource-aware boundaries required for
CATS operations.
In summary, BGP-FS is applicable to CATS for implementing distributed
traffic steering policies that can incorporate computing-aware
decisions. Existing BGP-FS mechanisms provide a robust foundation
for traffic classification and steering, but extensions are required
to fully integrate computing metrics, handle dynamic resource
conditions, and ensure scalable operation in large-scale CATS
deployments.
4.5. BGP SR Policy Applicability for Service-aware Candidate Paths
As defined in [I-D.ietf-cats-framework] section 3.4.4, a standalone
CATS Path Selector (C-PS) can be implemented as a functional
component of a centralized controller. BGP Segment Routing Policy
(SR Policy) provides a mechanism for distributing Segment Routing
policies that can be leveraged by the C-PS to implement computing-
aware path selection and traffic steering decisions in SR-MPLS and
SRv6 networks.
Yao, et al. Expires 3 January 2027 [Page 10]
Internet-Draft Protocols Applicability for CATS July 2026
BGP SR Policy applies to the path computation and traffic steering
functions within the CATS framework, specifically enabling the C-PS
to distribute service-aware candidate paths to ingress CATS-
Forwarders. The protocol facilitates the association between
computing resource availability and optimized network paths, allowing
for the creation of end-to-end paths that consider both network
conditions and computing metrics. BGP SR Policy enables the C-PS to
implement dynamic path selection that adapts to changes in both
network topology and computing resource distribution across service
locations.
The BGP SR Policy framework [RFC9256] for defining and distributing
Segment Routing policies, including the BGP SR Policy SAFI and
associated NLRI format. Candidate path selection mechanisms
[RFC9256] that allow for multiple paths to the same destination with
different characteristics and preferences. BGP-based policy
distribution mechanisms [RFC9830] that provide scalable propagation
of SR policies across a network domain. Segment routing architecture
capabilities [RFC8402] that enable flexible path programming through
segment lists. Color-aware routing mechanisms that can be extended
to represent computing-aware service classes or resource availability
levels.
BGP SR Policy is primarily designed for network path optimization and
does not natively support the integration of computing metrics into
path computation and selection processes. The protocol may introduce
scalability challenges when dealing with fine-grained service-to-path
mappings, particularly in environments with numerous SCIs and dynamic
computing conditions. Extensions to the candidate path selection and
distribution to incorporate computing metrics and service identifiers
as primary selection criteria alongside traditional candidate paths.
In summary, BGP SR Policy is applicable to CATS for distributing
service-aware candidate paths that can incorporate computing resource
considerations into the traffic steering decision process. Existing
BGP SR Policy mechanisms provide a robust foundation for flexible
path programming and distribution, but extensions are required to
fully integrate computing metrics, support dynamic service-aware path
selection, and ensure scalable operation in large-scale CATS
deployments with numerous service instances and rapidly changing
resource conditions.
Yao, et al. Expires 3 January 2027 [Page 11]
Internet-Draft Protocols Applicability for CATS July 2026
4.6. Yang Model Applicability for Service Configuration and Management
As per [I-D.ietf-cats-framework] section 3.3, the CATS management
plane is responsible for monitoring, configuring, and maintaining
CATS network devices. The CATS data may be required to be maintained
in the management plane and configured to the control plane, data
plane and C-SMA. A YANG data model may be required for the
configuration and management.
The routing data model and ietf-routing YANG model is defined for
configuring and managing a routing subsystem as per [RFC8349]. The
model contains all the basic network-related configuration parameters
to operate the CATS networks. The data model may be required to
augment for the CATS computing information.
In summary, the CATS data model requires configuration management
functionality, traffic steering policy configuration functionality,
service metric management functionality, and event reporting
functionality, as detailed below:
o It may provide interfaces for the functionality of the C-PS
component, which can be used for communication between the Control
Plane and the C-SMA, as well as for the interface between the Control
Plane and the CATS-Forwarder.
o It may provide interfaces for the functionality of the C-TC
component, which can be used for communication between the Control
Plane and the CATS-Forwarder. The Control Plane can directly
distribute the CATS traffic-classifier table to the CATS-Forwarder,
allowing the CATS-Forwarder to proactively select paths according to
forwarding policies.
o It may provide interfaces for the C-SMA component, which can be
used for communication between the Control Plane and the CATS-
Forwarder, as well as for transmitting service metric information
from the C-SMA to the Control Plane. It is also used for
distributing service metric information from the Control Plane to the
CATS-Forwarder.
o It may enable the CATS-Forwarder to report events to the Control
Plane.
Yao, et al. Expires 3 January 2027 [Page 12]
Internet-Draft Protocols Applicability for CATS July 2026
4.7. Data plane Protocols Applicability for Forwarding CATS Packets
As per [I-D.ietf-cats-framework] section 3.3, the CATS data plane is
responsible for computing-aware steering the packets along the paths
to the service contact instances. It needs to classify and forward
the packets in routing networks such as IPv6, SR-MPLS and SRv6
networks.
The ingress CATS-Router needs to encapsulate the corresponding
headers from itself to the egress CATS-Router. It is required to
indicate the interface associated to a specific service contact
instance which connected to the egress CATS-Router.
The egress CATS-Router decapsulates the encapsulation of the packets.
Since there might be multiple service instances which provide the
same service deployed under the same CATS-Router, a mechanism is
required to ensure that the packets are forwarded to a corresponding
service contact instance.
In summary, it should be noted that the client and service host
stacks are not modified. The Cats data plane needs to utilize the
existing forwarding mechanism to forward packets from the Ingress
CATS-Router to the Egress CATS-Router through appropriate
encapsulation. Then, on the Egress CATS-Router, the packets can be
forwarded to the corresponding service contact instance.
5. Security Considerations
The security considerations described in [I-D.ietf-cats-framework]
and related routing protocols are applicable to this document. This
document analyzed the applicability for some protocols which do not
introduce any new extensions and new security considerations.
6. IANA Considerations
Currently this document does not make an IANA requests.
7. References
7.1. Normative References
[I-D.ietf-cats-framework]
Li, C., Du, Z., Boucadair, M., Contreras, L. M., and J.
Drake, "A Framework for Computing-Aware Traffic Steering
(CATS)", Work in Progress, Internet-Draft, draft-ietf-
cats-framework-19, 20 November 2025,
<https://datatracker.ietf.org/doc/html/draft-ietf-cats-
framework-19>.
Yao, et al. Expires 3 January 2027 [Page 13]
Internet-Draft Protocols Applicability for CATS July 2026
7.2. Informative References
[I-D.dunbar-lsr-5g-edge-compute]
Dunbar, L., Chen, H., and A. Wang, "IGP Extension for 5G
Edge Computing Service", Work in Progress, Internet-Draft,
draft-dunbar-lsr-5g-edge-compute-07, 25 January 2022,
<https://datatracker.ietf.org/doc/html/draft-dunbar-lsr-
5g-edge-compute-07>.
[I-D.ietf-cats-metric-definition]
C. Li, et al, "CATS Metrics Definition", October 2025,
<https://datatracker.ietf.org/doc/draft-ietf-cats-metric-
definition/>.
[I-D.ietf-idr-5g-edge-service-metadata]
L. Dunbar, et al, "BGP Extension for 5G Edge Service
Metadata", September 2025,
<https://datatracker.ietf.org/doc/draft-ietf-idr-5g-edge-
service-metadata/>.
[I-D.ietf-idr-bgp4-rfc4271bis]
Rekhter, Y., Li, T., Hares, S., and J. Scudder, "A Border
Gateway Protocol 4 (BGP-4)", Work in Progress, Internet-
Draft, draft-ietf-idr-bgp4-rfc4271bis-00, 14 October 2025,
<https://datatracker.ietf.org/doc/html/draft-ietf-idr-
bgp4-rfc4271bis-00>.
[I-D.ietf-idr-bgp-flowspec-label]
liangqiandeng, Hares, S., You, J., Raszuk, R., and D. Ma,
"Carrying Label Information for BGP FlowSpec", Work in
Progress, Internet-Draft, draft-ietf-idr-bgp-flowspec-
label-02, 20 October 2022,
<https://datatracker.ietf.org/doc/html/draft-ietf-idr-bgp-
flowspec-label-02>.
[I-D.ietf-idr-flowspec-mpls-match]
Yong, L., Hares, S., liangqiandeng, and J. You, "BGP Flow
Specification Filter for MPLS Label", Work in Progress,
Internet-Draft, draft-ietf-idr-flowspec-mpls-match-02, 20
October 2022, <https://datatracker.ietf.org/doc/html/
draft-ietf-idr-flowspec-mpls-match-02>.
[I-D.ietf-idr-flowspec-v2]
Hares, S., Eastlake, D. E., Yadlapalli, C., and S.
Maduschke, "BGP Flow Specification Version 2", Work in
Progress, Internet-Draft, draft-ietf-idr-flowspec-v2-04,
28 April 2024, <https://datatracker.ietf.org/doc/html/
draft-ietf-idr-flowspec-v2-04>.
Yao, et al. Expires 3 January 2027 [Page 14]
Internet-Draft Protocols Applicability for CATS July 2026
[I-D.ietf-idr-ts-flowspec-srv6-policy]
Wenying, J., Liu, Y., Zhuang, S., Mishra, G. S., and S.
Chen, "Traffic Steering using BGP FlowSpec with SR
Policy", Work in Progress, Internet-Draft, draft-ietf-idr-
ts-flowspec-srv6-policy-07, 4 August 2025,
<https://datatracker.ietf.org/doc/html/draft-ietf-idr-ts-
flowspec-srv6-policy-07>.
[RFC768] Postel, J., "User Datagram Protocol", STD 6, RFC 768,
DOI 10.17487/RFC0768, August 1980,
<https://www.rfc-editor.org/rfc/rfc768>.
[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/rfc/rfc2119>.
[RFC4271] Rekhter, Y., Ed., Li, T., Ed., and S. Hares, Ed., "A
Border Gateway Protocol 4 (BGP-4)", RFC 4271,
DOI 10.17487/RFC4271, January 2006,
<https://www.rfc-editor.org/rfc/rfc4271>.
[RFC5440] Vasseur, JP., Ed. and JL. Le Roux, Ed., "Path Computation
Element (PCE) Communication Protocol (PCEP)", RFC 5440,
DOI 10.17487/RFC5440, March 2009,
<https://www.rfc-editor.org/rfc/rfc5440>.
[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/rfc/rfc7471>.
[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/rfc/rfc8174>.
[RFC8349] Lhotka, L., Lindem, A., and Y. Qu, "A YANG Data Model for
Routing Management (NMDA Version)", RFC 8349,
DOI 10.17487/RFC8349, March 2018,
<https://www.rfc-editor.org/rfc/rfc8349>.
[RFC8402] Filsfils, C., Ed., Previdi, S., Ed., Ginsberg, L.,
Decraene, B., Litkowski, S., and R. Shakir, "Segment
Routing Architecture", RFC 8402, DOI 10.17487/RFC8402,
July 2018, <https://www.rfc-editor.org/rfc/rfc8402>.
Yao, et al. Expires 3 January 2027 [Page 15]
Internet-Draft Protocols Applicability for CATS July 2026
[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/rfc/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/rfc/rfc8571>.
[RFC8685] Zhang, F., Zhao, Q., Gonzalez de Dios, O., Casellas, R.,
and D. King, "Path Computation Element Communication
Protocol (PCEP) Extensions for the Hierarchical Path
Computation Element (H-PCE) Architecture", RFC 8685,
DOI 10.17487/RFC8685, December 2019,
<https://www.rfc-editor.org/info/rfc8685>.
[RFC8955] Loibl, C., Hares, S., Raszuk, R., McPherson, D., and M.
Bacher, "Dissemination of Flow Specification Rules",
RFC 8955, DOI 10.17487/RFC8955, December 2020,
<https://www.rfc-editor.org/rfc/rfc8955>.
[RFC8956] Loibl, C., Ed., Raszuk, R., Ed., and S. Hares, Ed.,
"Dissemination of Flow Specification Rules for IPv6",
RFC 8956, DOI 10.17487/RFC8956, December 2020,
<https://www.rfc-editor.org/rfc/rfc8956>.
[RFC9256] Filsfils, C., Talaulikar, K., Ed., Voyer, D., Bogdanov,
A., and P. Mattes, "Segment Routing Policy Architecture",
RFC 9256, DOI 10.17487/RFC9256, July 2022,
<https://www.rfc-editor.org/rfc/rfc9256>.
[RFC9552] Talaulikar, K., Ed., "Distribution of Link-State and
Traffic Engineering Information Using BGP", RFC 9552,
DOI 10.17487/RFC9552, December 2023,
<https://www.rfc-editor.org/info/rfc9552>.
[RFC9830] Previdi, S., Filsfils, C., Talaulikar, K., Ed., Mattes,
P., and D. Jain, "Advertising Segment Routing Policies in
BGP", RFC 9830, DOI 10.17487/RFC9830, September 2025,
<https://www.rfc-editor.org/rfc/rfc9830>.
Yao, et al. Expires 3 January 2027 [Page 16]
Internet-Draft Protocols Applicability for CATS July 2026
Appendix A. BGP Edge Metadata Path Applicability
A.1. Summary of 5G Edge Service Metadata Mechanism
A.1.1. Attribute Structure
The Edge Metadata Path Attribute is an optional, non-transitive BGP
Path Attribute consisting of a set of Sub-TLVs. Each Sub-TLV carries
one metric or an abstracted value about the running environment or
capability of an edge service or its hosting site.
The base document defines Sub-TLVs including (but not limited to):
Site Preference Index, Site Physical Availability Index, Service
Delay Prediction, Raw Measurement, Service-Oriented Capability, and
Service-Oriented Available Resource.
The attribute is carried with selected service routes, typically
anycast service prefixes, and can also be used in standalone UPDATEs
for site-wide values.
A.1.2. High-Level Distribution Behavior
Edge Metadata is intended for limited-domain distribution. The
attribute is non-transitive and is expected to be filtered at
administrative boundaries. Route Reflectors (RRs) can further
constrain propagation using NO-ADVERTISE or an in-attribute AS-Scope
Sub-TLV.
The metadata is propagated in BGP UPDATEs, subject to a minimum
advertisement interval (default 30 seconds) to control churn.
A.2. Applicability of 5G Edge Metadata to CATS Metrics
The 5G Edge Metadata Path Attribute provides a ready-made container
to carry most CATS-defined compute and service metrics, especially
those that must be synchronized across ingress nodes for service-
instance selection. The mechanisms align with CATS in several
dimensions:
A.2.1. Compute/Resource Capability (CATS L1/L2)
The Service-Oriented Capability Sub-TLV is directly usable as a
normalized compute capability indicator.
It already conforms to the CATS requirement that compute metrics be
abstracted and comparable across heterogeneous hardware.
Yao, et al. Expires 3 January 2027 [Page 17]
Internet-Draft Protocols Applicability for CATS July 2026
A.2.2. Compute/Resource Availability (CATS L1)
The Available Resource Sub-TLV corresponds to CATS L1 availability
metrics such as CPU headroom, memory availability, or accelerator
capacity.
Where CATS defines a family of resource-type-specific primitives, the
5G mechanism provides a unified normalized format suitable for
routing-level decisions.
A.2.3. Service Processing Delay (CATS L0 or L1)
The Service Delay Prediction SubTLV supports both, raw time values
(L0), when expressed in milliseconds; and normalized delay scores
(L1/L2), when expressed as a 0-100 index.
This flexibility matches CATS' need for both precise measurements and
abstracted comparative metrics.
A.2.4. Traffic Load / Utilization (CATS L0-L1/L2
The Raw Measurement Sub-TLV offers input signals for evaluating
congestion, load, and resource pressure.
These serve as L0 primitives from which CATS-compliant L1 or L2
metrics can be derived.
A.2.5. Site Preference (CATS L2 policy metric)
Although not defined by CATS, the Site Preference Index aligns with
the CATS concept of operator-defined L2 composite metrics (e.g.,
policy-driven affinity, regulatory guidance, cost-based biasing).
A.2.6. Site Physical Availability (CATS Shared Resource)
Site Physical Availability Index (SPAI) Sub-TLV provides a
site/pod/row/floor/DC availability percentage that applies to a group
of routes sharing the same physical characteristic. This directly
aligns with the "Shared Resource" concept in [I.D.ll-idr-cats-bgp-
extension], where a single metric update should influence multiple
SCIs without per-service replication.
The SPAI is naturally suited for use as a CATS Shared Resource metric
because it reflects conditions that affect all service instances
within the same facility. SPAI represents substrate-level
constraints such as power redundancy, cooling capacity, rack/row
availability, and environmental health - factors that are not tied to
any individual service instance. When the physical state of a site
Yao, et al. Expires 3 January 2027 [Page 18]
Internet-Draft Protocols Applicability for CATS July 2026
changes, all hosted services are simultaneously impacted, meaning a
single SPAI update conveys a facility wide condition without
requiring per-service updates.
This behavior matches the CATS Shared Resource semantics defined in
[I-D.ll-idr-cats-bgp-extension], which aims to avoid churn by
enabling one update to apply to many SCIs. SPAI's value is also
normalized and abstracted (0-100), satisfying CATS's preference for
L1/L2 metrics that can be compared uniformly across egress nodes.
Additionally, SPAI is disseminated using the same limited domain,
non-transitive BGP propagation model recommended for CATS, without
requiring new identifiers or mapping constructs because the site
itself serves as the implicit shared resource boundary.
Therefore, SPAI can be used directly as a Shared Resource metric in
CATS deployments, helping reduce protocol overhead, avoiding per
service metric replication, and improving responsiveness to physical
site level events.
A.2.7. Expressiveness, Granularity, Update Semantics
CATS recommends distributing normalized L1/L2 metrics due to their
stability and comparability.
The 5G Edge Metadata model already restricts itself to abstracted
values, with raw L0 metrics not directly exposed except through Raw
Measurement.
Thus, the overall expressiveness aligns well with CATS' guidance and
operational constraints.
A.3. Metric Lifetimes
The Edge Metadata model uses BGP UPDATE propagation, with default
minimum advertisement interval of 30 seconds in iBGP domains. This
is consistent with typical CATS control plane expectations for
"moderately dynamic" metrics (seconds-to-minutes scale), but may be
insufficient for highly bursty L0 measurements unless operators apply
dampening and aggregation.
For L2-style normalized values (capability/availability/delay
prediction), BGP timeliness is generally adequate in a limited domain
where topology diameter is small. For raw L0-style signals (if added
later), asynchronous collection and local aggregation before BGP
export is RECOMMENDED.
Yao, et al. Expires 3 January 2027 [Page 19]
Internet-Draft Protocols Applicability for CATS July 2026
A.4. Granularity Semantics Issues
CATS separates metrics by scope: per-SCI (service instance), per-
service (aggregate over instances), per-site, and shared-resource.
The Edge Metadata mechanisms currently mix these scopes:
* Service-Oriented Capability and Available Resource are per-service
at a site (implicitly per-service aggregate over instances).
* Service Delay Prediction is per-service at a site, but can
represent either a normalized score or raw time; consistent
semantic interpretation across ingress nodes is required.
* Site Physical Availability Index is per-site or shared-resource
and supports standalone updates. This matches CATS shared
resource needs.
* Raw Measurement is a per-service route signal, not a standardized
CATS L0 set.
If CATS requires explicit per-SCI differentiation (e.g., for multiple
instances behind one anycast service prefix), the 5G Edge Metadata
encoding needs augmentation to carry an instance identifier or to
bind distinct metrics to distinct NLRIs.
A.5. Scalability and Churn Considerations
The 5G Edge Metadata draft deliberately limits scope to a small
subset of services in a limited domain, and applies a minimum
advertisement interval to avoid route churn. This is aligned with
CATS concerns about frequent metric updates causing cascading BGP
UPDATEs. Operators SHOULD:
* Prefer L1/L2 normalized metrics for distribution.
* Aggregate L0 signals locally and export only on meaningful change.
* Use shared-resource/site-wide updates (e.g., Site Physical
Availability Index) whenever possible.
In large deployments with many services per site, the per-service
Sub-TLV updates could still create noticeable churn. Mapping to the
generic CATS BGP metric container may reduce the need for new Sub-TLV
types and simplify extensibility.
Yao, et al. Expires 3 January 2027 [Page 20]
Internet-Draft Protocols Applicability for CATS July 2026
A.6. Gaps and Extensions Needed for CATS Compliance
The following additions would allow the 5G Edge Metadata mechanisms
to serve as a fully compliant CATS metric container:
Per-SCI Differentiation: Add an Instance-ID field or tie individual
metric Sub-TLVs to distinct NLRIs so ingress routers can
distinguish metrics for different service instances behind an
anycast prefix.
Explicit Resource-Type Identification (for L0->L1 transitions): CATS
defines specific raw metrics (CPU load, GPU usage, memory
pressure). Adding optional resource-type enumerations would allow
Raw Measurement or Capability TLVs to expose more structured CATS
L0 primitives when needed.
Metric Lifetime / Validity Interval: CATS defines explicit metric-
freshness semantics. The 5G Edge Metadata mechanism can be
extended with: TTL or "valid until" timestamps, change-threshold
indicators, or explicit "stale" flags.
Scope Identifier for Shared Resource Metrics: Allow SPAI-like
metrics to reference a named resource pool (e.g., "DC-Room-A",
"GPU-Cluster-2") when a site contains multiple independent shared
resources.
Support for More Dynamic Metric Classes: For highly dynamic CATS L0
metrics, support for sub-second updates is generally not
appropriate in BGP. Guidance should mandate local smoothing/
aggregation before exporting updates into the control plane.
Contributors
The following people have substantially contributed to this document:
Peng Liu
China Mobile
Email: liupengyjy@chinamobile.com
Authors' Addresses
Huijuan Yao
China Mobile
Email: yaohuijuan@chinamobile.com
Yao, et al. Expires 3 January 2027 [Page 21]
Internet-Draft Protocols Applicability for CATS July 2026
Linda Dunbar
Futurewei
Email: ldunbar@futurewei.com
Quan Xiong
ZTE Corporation
Email: xiong.quan@zte.com.cn
Changwang Lin
New H3C Technologies
Email: linchangwang.04414@h3c.com
Yao, et al. Expires 3 January 2027 [Page 22]