Protocols Applicability for Computing-Aware Traffic Steering (CATS)
draft-yxl-cats-protocols-applicability-02
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-10-14 | ||
| 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-02
cats H. Yao
Internet-Draft China Mobile
Intended status: Informational L. Dunbar
Expires: 17 April 2027 Futurewei
Q. Xiong
ZTE Corporation
C. Lin
New H3C Technologies
14 October 2026
Protocols Applicability for Computing-Aware Traffic Steering (CATS)
draft-yxl-cats-protocols-applicability-02
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 17 April 2027.
Copyright Notice
Copyright (c) 2026 IETF Trust and the persons identified as the
document authors. All rights reserved.
Yao, et al. Expires 17 April 2027 [Page 1]
Internet-Draft Protocols Applicability for CATS October 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 . . . . . . . . . . . . . . . . . . 4
3. CATS Applicability Overview . . . . . . . . . . . . . . . . . 4
3.1. Control Plane Applicability Analysis . . . . . . . . . . 5
3.2. Management Plane Applicability Analysis . . . . . . . . . 6
3.3. Data Plane Applicability Analysis . . . . . . . . . . . . 6
4. Protocols Applicability to CATS . . . . . . . . . . . . . . . 6
4.1. BGP Applicability for Metrics Distribution . . . . . . . 6
4.1.1. CATS-Specific Requirements for BGP Extensions . . . . 7
4.1.2. Applicability of BGP for CATS Metric Distribution . . 9
4.2. IGP and BGP-LS Applicability for Metrics Distribution . . 10
4.2.1. IGP Applicability . . . . . . . . . . . . . . . . . . 11
4.2.2. BGP-LS Applicability . . . . . . . . . . . . . . . . 12
4.3. PCEP Applicability for Service-aware Computing . . . . . 12
4.3.1. CATS-Specific Requirements for PCEP Extensions . . . 13
4.3.2. Applicability of PCEP for CATS Service-aware
Computing . . . . . . . . . . . . . . . . . . . . . . 13
4.4. BGP-FS Applicability for Service Mapping . . . . . . . . 15
4.4.1. CATS-Specific Requirements for BGP-FS Extensions . . 15
4.4.2. Applicability of BGP-FS for CATS Service Mapping . . 16
4.5. BGP SR Policy Applicability for Service-aware Candidate
Paths . . . . . . . . . . . . . . . . . . . . . . . . . . 17
4.5.1. CATS-Specific Requirements for BGP SR Policy
Extensions . . . . . . . . . . . . . . . . . . . . . 17
4.5.2. Applicability of BGP SR-Policy for CATS Service-aware
Candidate Paths . . . . . . . . . . . . . . . . . . . 18
4.6. Yang Model Applicability for Service Configuration and
Management . . . . . . . . . . . . . . . . . . . . . . . 19
4.6.1. CATS specific Requirements for Service Configuration
and Management . . . . . . . . . . . . . . . . . . . 19
4.6.2. CATS specific Requirements for OAM (Operations,
Administration, and Maintenance) Support and
Enhancement . . . . . . . . . . . . . . . . . . . . . 20
4.7. Data plane Protocols Applicability for Forwarding CATS
Packets . . . . . . . . . . . . . . . . . . . . . . . . . 21
Yao, et al. Expires 17 April 2027 [Page 2]
Internet-Draft Protocols Applicability for CATS October 2026
5. Security Considerations . . . . . . . . . . . . . . . . . . . 21
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 21
7. References . . . . . . . . . . . . . . . . . . . . . . . . . 21
7.1. Normative References . . . . . . . . . . . . . . . . . . 21
7.2. Informative References . . . . . . . . . . . . . . . . . 22
Appendix A. BGP Edge Metadata Path Applicability . . . . . . . . 25
A.1. Summary of 5G Edge Service Metadata Mechanism . . . . . . 25
A.1.1. Attribute Structure . . . . . . . . . . . . . . . . . 25
A.1.2. High-Level Distribution Behavior . . . . . . . . . . 25
A.2. Applicability of 5G Edge Metadata to CATS Metrics . . . . 26
A.2.1. Compute/Resource Capability (CATS L1/L2) . . . . . . 26
A.2.2. Compute/Resource Availability (CATS L1) . . . . . . . 26
A.2.3. Service Processing Delay (CATS L0 or L1) . . . . . . 26
A.2.4. Traffic Load / Utilization (CATS L0-L1/L2 . . . . . . 26
A.2.5. Site Preference (CATS L2 policy metric) . . . . . . . 26
A.2.6. Site Physical Availability (CATS Shared Resource) . . 27
A.2.7. Expressiveness, Granularity, Update Semantics . . . . 27
A.3. Metric Lifetimes . . . . . . . . . . . . . . . . . . . . 28
A.4. Granularity Semantics Issues . . . . . . . . . . . . . . 28
A.5. Scalability and Churn Considerations . . . . . . . . . . 28
A.6. Gaps and Extensions Needed for CATS Compliance . . . . . 29
Contributors . . . . . . . . . . . . . . . . . . . . . . . . . . 29
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 30
1. Introduction
[RFC10053] 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 [RFC10053] 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 [RFC10053] and
[I-D.ietf-cats-metric-definition].
Yao, et al. Expires 17 April 2027 [Page 3]
Internet-Draft Protocols Applicability for CATS October 2026
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 [RFC10053], 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).
+-------------------------------+ +---------------------+
| Control Plane | | Management Plane |
| +------+ +-----+ +-----+ | | +-----+ +-------+ |
| | PCEP | |C-PS | |C-SMA| | | | OAM | | YANG | |
| | | | | | | | | | | | model | |
| +------+ +-----+ +-----+ | | +-----+ +-------+ |
+-------------------------------+ +---------------------+
^ ^ ^ ^
| | | | PING |
|BGP-LS |PCEP |BGP-FS |TRACERT |YANG
| | | |
V V V
------------------------------------------------------------------
Data Plane
+--------+ +----------+ +--------+ +----------+
|Ingress |----|Forwarder |----|Egress |<====>|Service |
+--------+ +----------+ +--------+ |Contact |
^ | +----------+
| IGP/BGP |
+------------------------------+
<postamble>:
Figure 1: CATS System Applicability
Figure 1 depicts a high-level CATS system architecture illustrating
component placement and representative control management plane
protocol interactions.
Yao, et al. Expires 17 April 2027 [Page 4]
Internet-Draft Protocols Applicability for CATS October 2026
Metrics Distribution:
Centralized mode (Controller as C-PS): The egress C-SMA advertises
Metrics to the C-PS via BGP-LS extension or YANG.
Distributed mode (Ingress as C-PS): The Egress C-SMA advertises
Metrics to the C-PS via IGP，BGP extension.
Path Selection:
Centralized mode: The controller-resident C-PS computes CATS?aware
optimal paths and delivers candidate paths to the Ingress CATS-
Forwarder via PCEP or BGP SR Policy or BGP-FS extensions.
Distributed mode: The C-PS resides locally on the Ingress node. It
computes optimal CATS-aware paths locally based on received metrics
without controller-driven path delivery.
OAM:The controller MAY leverage extended PING and Traceroute
mechanisms to perform CATS-specific OAM operations.
3.1. Control Plane Applicability Analysis
Control plane protocols realize two core CATS functions: metrics
distribution , and selection of forwarding paths for CATS service
destinations. Compute-related CATS metrics are formally defined in
[I-D.ietf-cats-metric-definition] as referenced by
[RFC10053].Nevertheless, standardized protocols and end-to-end
mechanisms for transporting metrics from egress gateways to ingress
gateways remain an area for further development.
For CATS traffic classification, two control-plane mechanisms are
applicable. BGP-FS acts as a distributed control mechanism for
service mapping and flow classification, while YANG models provide a
centralized control alternative. .Besides metric distribution and
traffic classification, control-plane protocols implement path-
selection and path-delivery functions for the C-PS. PCEP allows a
C-PS functioning as a Path Computation Element (PCE) to compute CATS-
aware paths and deliver them to ingress forwarders operating as Path
Computation Clients (PCCs). BGP SR-Policy enables a centralized C-PS
to advertise service-aware SR candidate paths to ingress nodes, where
each candidate path carries associated CATS-relevant context for
subsequent local evaluation.
Yao, et al. Expires 17 April 2027 [Page 5]
Internet-Draft Protocols Applicability for CATS October 2026
3.2. Management Plane Applicability Analysis
The management plane handles configuration, operational monitoring,
and lifecycle management for the full set of CATS functional
components. Existing diagnostic tools such as PING and Traceroute
MAY be extended to support CATS-specific troubleshooting, enabling
operations based on CATS Service Identifiers (CS-IDs). Complementing
control-plane functions, YANG models may be augmented for CATS to
expose flow level statistical data and support monitoring of CATS
service behaviors.
3.3. Data Plane Applicability Analysis
The data plane forwards CATS service traffic toward target servic-
contact instances leveraging mature existing forwarding protocols,
including native IPv4/IPv6 and IPv4/IPv6 over SRv6.
4. Protocols Applicability to CATS
4.1. BGP Applicability for Metrics Distribution
As defined in [RFC10053] 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.
BGP can be used as a distributed control plane mechanism for carrying
service and compute information among CATS nodes. However, CATS
introduces requirements that differ from conventional reachability
distribution. In particular, a CATS Path Selector may need
information for multiple candidate Service Contact Instances that
provide the same service, together with metrics whose scope,
lifetime, and update behavior differ from ordinary routing
information.
Section 4.1.1 describes the CATS-specific requirements that a BGP
extension for CATS metric distribution needs to address.
Section 4.1.2 discusses the applicability of BGP mechanisms to those
requirements.
Yao, et al. Expires 17 April 2027 [Page 6]
Internet-Draft Protocols Applicability for CATS October 2026
4.1.1. CATS-Specific Requirements for BGP Extensions
A BGP extension used for CATS metric distribution needs to provide
sufficient information for a C-PS to identify candidate service
instances and evaluate them using both computing and network
information. The specific encoding may be based on a BGP Path
Attribute, a new NLRI or SAFI, or another BGP extension mechanism.
Independent of the encoding choice, the following requirements apply.
-Candidate and metric association:
A CATS metric needs to be associated with the object to which it
applies. Depending on the deployment, a metric may apply to a CS-ID,
an individual SCI, an egress CATS-Forwarder, a site, or a shared
resource. The BGP encoding therefore needs to identify the scope of
the advertised metric unambiguously.
When multiple SCIs for the same service are reachable through the
same service prefix, the BGP mechanism needs to preserve information
for the individual service candidates required by the C-PS. Ordinary
BGP route selection may otherwise select a single best route and hide
alternative service locations that the C-PS needs to evaluate using
CATS metrics.
-Metric semantics and granularity:
The receiving CATS node needs to determine the type and granularity
of an advertised metric. As described in
[I-D.ietf-cats-metric-definition], CATS metrics may represent
different levels of abstraction, including L0, L1, and L2
information. The BGP extension therefore needs to provide sufficient
semantics to distinguish the metric type and the resource or service
scope to which it applies.
For example, an available-resource metric could apply to an
individual SCI, all instances of a service at a site, or a shared
accelerator or compute-resource pool. The encoding needs to avoid
ambiguity between these cases.
-Metric freshness and validity:
Compute and service information may change independently of service
reachability. A BGP extension for CATS therefore needs a mechanism
that enables the receiving CATS node to determine whether advertised
metric information remains valid.
Yao, et al. Expires 17 April 2027 [Page 7]
Internet-Draft Protocols Applicability for CATS October 2026
The mechanism needs to support updating or withdrawing stale
information when a metric changes, when an SCI becomes unavailable,
or when the originating node can no longer provide the metric. Where
metric validity is bounded in time, the encoding or associated
procedures need to provide sufficient information for the receiver to
identify expired or stale information.
-Independent metric and reachability updates:
A change in a CATS metric SHOULD be advertisable without
unnecessarily changing the underlying service reachability.
Conversely, withdrawal or invalidation of one metric SHOULD NOT
unintentionally withdraw unrelated service reachability or metrics
associated with other SCIs.
This separation is particularly important where multiple service
instances share the same service prefix but have different compute-
resource conditions.
-Scalability and update frequency:
CATS metrics can have different update frequencies. A BGP extension
needs to operate with BGP incremental UPDATE processing and route-
reflection mechanisms without introducing excessive control-plane
churn.
Highly dynamic raw L0 measurements, such as instantaneous CPU load,
memory pressure, queue depth, or rapidly changing utilization, SHOULD
be collected locally, smoothed, thresholded, aggregated, or converted
into normalized metrics before being distributed through BGP. BGP
SHOULD NOT be used as a sub-second telemetry transport for CATS.
Distribution scope and policy control:CATS service and compute
metrics may expose information about resource availability, site
preference, operational state, or shared-resource utilization. Such
information needs to be distributed only to authorized CATS nodes.
A BGP extension for CATS therefore needs to support policy-controlled
propagation and administrative scoping so that CATS information does
not unintentionally leak outside the domain in which it is intended
to be used. Existing BGP mechanisms such as route filtering, route-
reflection policy, community-based controls, and appropriately scoped
or non-transitive attributes can be used as part of such controls.
-Relationship to BGP route selection:
Yao, et al. Expires 17 April 2027 [Page 8]
Internet-Draft Protocols Applicability for CATS October 2026
CATS metrics are inputs to the CATS Path Selector. Unless a specific
BGP extension explicitly defines otherwise, CATS metrics SHOULD NOT
alter the normal BGP best-path selection procedure for the associated
reachability.
The BGP mechanism needs to make the relevant candidate information
available to the C-PS so that the C-PS can apply CATS-specific policy
and combine computing and network metrics when selecting an egress
CATS-Forwarder and SCI.
These requirements are independent of a particular BGP encoding.
They can therefore be used to evaluate existing BGP mechanisms as
well as proposed CATS-specific BGP extensions.
4.1.2. Applicability of BGP for CATS Metric Distribution
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.
Yao, et al. Expires 17 April 2027 [Page 9]
Internet-Draft Protocols Applicability for CATS October 2026
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
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
Yao, et al. Expires 17 April 2027 [Page 10]
Internet-Draft Protocols Applicability for CATS October 2026
4.2.1. IGP Applicability
As defined in [RFC10053], 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:
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.
Yao, et al. Expires 17 April 2027 [Page 11]
Internet-Draft Protocols Applicability for CATS October 2026
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.
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
Yao, et al. Expires 17 April 2027 [Page 12]
Internet-Draft Protocols Applicability for CATS October 2026
4.3.1. CATS-Specific Requirements for PCEP Extensions
As defined in [RFC10053] section 3.4.4, C-PSes can be used to
determine the best paths to forward traffic based on both computing
and network metrics. A standalone C-PS may be implemented as a Path
Computation Element (PCE), leveraging the Path Computation Element
Protocol (PCEP) [RFC5440] to communicate withPath Computation Clients
(PCCs), such as ingress CATS-Forwarders.
PCEP primarily supports 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
information (from the C-NMA) and computing metrics (from the C-SMA).
It needs to ensure that traffic is steered to the most suitable
egress CATS-Forwarder and Service Contact Instance (SCI) based on
composite metrics. It is required to convey compute- related
parameters (e.g., CPU load or service delay) in path requests or
responses, and select an egress router associated with the service
instances in CATS. The CATS-specific requirements for PCEP
extensions may consider:
o Network topology and metric information (e.g., from C-NMA) for
underlay path computation.
o 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.
o Identifiers for the selected egress CATS-Forwarder, SCI, or shared
resource (e.g., CS-ID, CSCI-ID), to specify the service destination.
4.3.2. Applicability of PCEP for CATS Service-aware Computing
PCEP is applicable to CATS service-aware computing when the C-PS is
realized as a centralized controller or PCE and needs to compute,
optimize, and deliver egress/SCI-aware paths to ingress CATS-
Forwarders acting as PCCs. PCEP [RFC5440] already provides request/
response messages, capability negotiation, metric and objective-
function objects, and ERO-based path delivery. Similar to PCEP
extensions for Traffic Engineering, PCEP can be extended for CATS so
that a PCE acting as C-PS combines underlay network information
(e.g., topology, delay, bandwidth, and other TE metrics obtained from
the C-NMA, BGP-LS and IGP) with computing metrics (e.g., normalized
capability, available resource, service processing delay, load, and
site preference obtained from the C-SMA) to select both an optimal
egress CATS-Forwarder and a specific Service Contact Instance (SCI).
Yao, et al. Expires 17 April 2027 [Page 13]
Internet-Draft Protocols Applicability for CATS October 2026
In a CATS deployment, PCEP can be used by an ingress CATS-Forwarder
to send a path computation request that identifies the target service
by CS-ID and, when required, by CSCI-ID, egress CATS-Forwarder, site,
or shared-resource scope. The request may carry network constraints
(e.g., bandwidth, latency bounds, SRLG or link diversity) together
with CATS computing constraints (e.g., minimum normalized compute
capability, maximum service delay prediction, maximum resource
utilization, or operator site preference). The PCE/C-PS returns one
or more computed paths, for example as an ERO or SR path/SID list,
and indicates the selected egress CATS-Forwarder and SCI identifiers
so that the ingress can steer service requests to the most suitable
compute endpoint. Where multiple SCIs provide the same service, PCEP
can return alternative or weighted candidate paths per SCI rather
than a single aggregated route, thereby preserving the candidate set
required by the C-PS.
PCEP is most suitable for applying relatively stable or moderately
dynamic, abstracted L1/L2 CATS metrics during path computation.
Examples include normalized compute capability, normalized available-
resource level, predicted service processing delay, site preference,
and shared-resource availability. Such metrics allow the C-PS to
perform composite optimization, for example minimizing a weighted
function of network delay and compute/service delay, without exposing
raw infrastructure telemetry to every forwarding element.
PCEP is less suitable for continuously distributing highly dynamic
raw L0 measurements, such as instantaneous CPU load, memory pressure,
GPU queue depth, per-flow utilization, or other rapidly changing
telemetry. Carrying or querying such values on every change would
cause excessive PCReq/PCRep exchanges and unnecessary PCE
recomputation churn. Therefore, highly dynamic L0 measurements
SHOULD be collected locally by the C-SMA, smoothed, thresholded,
aggregated, or converted into normalized L1/L2 metrics before being
supplied to the PCE or referenced in PCEP requests.
For multi-domain or multi-operator CATS scenarios, hierarchical PCEP
procedures may be used. A parent PCE can receive domain-level
network and abstracted compute summaries from child PCEs and compute
an inter-domain egress/SCI-aware path sequence, while child PCEs
compute intra- domain paths subject to local compute constraints.
This follows the H-PCE model [RFC8685] and limits leakage of detailed
compute and topology information across administrative boundaries.
PCEP-based CATS path computation is expected to be used primarily
within a controlled administrative domain or among authorized PCE/PCC
entities.
Yao, et al. Expires 17 April 2027 [Page 14]
Internet-Draft Protocols Applicability for CATS October 2026
In summary, PCEP is applicable to CATS when the objective is to
perform centralized, service-aware path computation that combines
network and computing metrics, deliver egress/SCI-bound paths to
ingress CATS- Forwarders, and support reoptimization as metrics
change within a controlled domain. However, additional CATS-specific
PCEP extensions or encoding rules may be required to support explicit
per-SCI identification, compute-metric types and objective functions,
shared-resource scope, metric freshness or validity indication, and
the return of selected SCI/egress information together with the
forwarding path.
4.4. BGP-FS Applicability for Service Mapping
4.4.1. CATS-Specific Requirements for BGP-FS Extensions
As defined in [RFC10053] section 3.4.4, a standalone C-PS may be
implemented as a functional component of a centralized controller.
The C-PS may apply the BGP Flow Specification (BGP- FS) for the
traffic classification and steering within the CATS framework. It
may enable the C-PS to distribute fine-grained traffic steering
policies to ingress CATS- Forwarders and facilitate 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 steering policies of C-PS to adapt dynamically as
computing resource conditions change across multiple SCIs. It is
required to distribute the compute-aware steering decisions and fine-
grained mappings for CATS services. The CATS-specific requirements
for BGP-FS extensions may consider:
o Traffic classification parameters for matching CATS service, such
as CATS service identifiers (e.g., CS-ID, CSCI-ID).
o Computing metrics (e.g., from the C-SMA) associated with CS-IDs or
SCIs, such as normalized compute capability, resource availability,
service delay, or load conditions.
o Forwarding actions toward the selected egress CATS-Forwarder and
SCI, such as redirection, marking, to specify the service
destination.
Yao, et al. Expires 17 April 2027 [Page 15]
Internet-Draft Protocols Applicability for CATS October 2026
4.4.2. Applicability of BGP-FS for CATS Service Mapping
BGP-FS is applicable to CATS service mapping when a centralized C-PS
or controller needs to distribute fine-grained, compute-aware traffic
classification and steering rules to ingress CATS-Forwarders. BGP-FS
[RFC8955] for IPv4/IPv4-VPN and [RFC8956] for IPv6 provides NLRI-
based matching on packet-header fields together with traffic-
filtering/forwarding actions carried as BGP attributes or extended
communities. BGP-FS can be extended for CATS to match CATS service
identifiers and to invoke forwarding actions toward selected egress
CATS-Forwarders and SCIs.
In a CATS deployment, BGP-FS can be used by the C-PS to install a
steering rule that matches one or more CATS identifiers, such as CS-
ID and, when required, CSCI-ID, together with optional network
classification fields (e.g., source/destination prefix, DSCP, VPN
context, MPLS label, or SRv6 SID). The rule may carry compute-aware
conditions derived from the C-SMA, for example minimum normalized
compute capability, maximum normalized resource utilization, maximum
service processing delay, load threshold, or operator site
preference, and may bind the matching traffic to an action such as
redirect to a specific egress CATS-Forwarder/SCI, marking/DSCP
rewrite, SID or Binding-SID association, or handoff to a precomputed
BGP SR Policy candidate path. This allows the controller-resident
C-PS to push per-service, per-instance steering policy to ingress
nodes without requiring every ingress to perform full metric-based
path computation.
BGP-FS is most suitable for distributing relatively stable or
moderately dynamic, abstracted L1/L2 CATS conditions as policy match
or action criteria. Examples include normalized compute-capability
thresholds, normalized available-resource levels, predicted service
delay ranges, site preference, and shared-resource availability.
Such rules enable ingress CATS-Forwarders to select among candidate
SCIs based on up-to-date compute posture while keeping the matching
space small and the installed rule set manageable.
BGP-FS is less suitable for expressing or continuously updating
highly dynamic raw L0 measurements, such as instantaneous CPU load,
memory pressure, GPU queue depth, per-flow utilization, or other
rapidly changing telemetry. Installing, modifying, or withdrawing
BGP-FS rules on every L0 change would cause excessive rule churn,
frequent policy recomputation on ingress nodes, and potential
forwarding instability. Therefore, highly dynamic L0 measurements
SHOULD be collected locally by the C-SMA, smoothed, thresholded,
aggregated, or converted into normalized L1/L2 conditions before
being reflected as BGP-FS matching criteria or as inputs to rule
regeneration.
Yao, et al. Expires 17 April 2027 [Page 16]
Internet-Draft Protocols Applicability for CATS October 2026
When multiple SCIs provide the same service behind a common anycast
prefix or shared network match, the BGP-FS encoding needs to
differentiate per-SCI rules (e.g., via CSCI-ID, instance-specific
label/SID, or distinct redirect action) rather than installing only
one aggregate rule, so that the ingress can still steer to the most
suitable instance.
In summary, BGP-FS is applicable to CATS when the objective is to
perform distributed, fine-grained service mapping and traffic
steering based on compute-aware conditions, to adapt forwarding
policy dynamically as SCI compute posture changes, and to deliver
egress/SCI- bound actions to ingress CATS-Forwarders. However,
additional CATS- specific BGP-FS extensions or encoding rules may be
required to support explicit CS-ID/CSCI-ID matching, compute-metric
thresholds and objective conditions, shared-resource scope, metric
freshness or validity indication, and forwarding actions that
identify the selected egress CATS-Forwarder and SCI.
4.5. BGP SR Policy Applicability for Service-aware Candidate Paths
4.5.1. CATS-Specific Requirements for BGP SR Policy Extensions
As defined in [RFC10053] section 3.4.4, a standalone C-PS) may be
implemented as a functional component of a centralized controller.
The C-PS may apply the BGP Segment Routing (SR) Policy to distribute
SR policies for computing- aware path selection and traffic steering
in SR-MPLS and SRv6 networks.
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. It 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. It is required to support the candidate path selection
and distribution to incorporate computing metrics and service
identifiers as primary selection criteria alongside traditional
candidate paths. The CATS-specific requirements for BGP SR Policy
extensions may consider:
o Identifiers and SR binding information for the selected egress
CATS-Forwarder and SCI, such as CS-ID, CSCI-ID, policy color,
endpoint SID, or Binding SID, to specify the service destination.
Yao, et al. Expires 17 April 2027 [Page 17]
Internet-Draft Protocols Applicability for CATS October 2026
o Update information reflecting changes in network topology and
computing resource distribution, so that the C-PS can dynamically
adjust candidate-path preference across multiple SCIs.
4.5.2. Applicability of BGP SR-Policy for CATS Service-aware Candidate
Paths
BGP SR Policy is applicable to CATS service-aware candidate paths
when a centralized C-PS or controller needs to compute, advertise,
and reoptimize SR-MPLS or SRv6 paths that bind a CATS service
destination to selected egress CATS-Forwarders and SCIs while taking
computing metrics into account. BGP SR Policy distribution is
specified in [RFC9830] and builds on the SR Policy architecture in
[RFC9256] and the Segment Routing base in [RFC8402]. BGP SR Policy
can be extended for CATS so that each candidate path carries service
identifiers and compute-aware context in addition to segment lists,
endpoint SIDs, Binding SIDs, and policy color, enabling an ingress
CATS-Forwarder to steer classified CATS flows onto the most suitable
compute-aware path.
In a CATS deployment, the C-PS/controller can originate one SR Policy
per CS-ID or per CS-ID together with an egress/SCI scope, and can
advertise multiple candidate paths toward different egress CATS-
Forwarders or SCIs. Each candidate path may be identified by the
policy tuple (headend, endpoint, color) and may include an SR-MPLS
label stack or SRv6 SID list that reaches the selected egress, a
Binding SID for local steering, and associated identifiers such as
CS-ID, CSCI-ID, endpoint SID, and color.
BGP SR Policy is most suitable for relatively stable or moderately
dynamic, abstracted L1/L2 CATS metrics that drive candidate-path
selection and periodic reoptimization. Examples include normalized
compute-capability and available-resource scores, predicted service
delay, site preference, and shared-resource status. Such metrics
allow the controller to optimize a weighted function of network and
compute criteria, for example minimizing combined underlay delay and
service processing delay, without exposing raw infrastructure
telemetry to every forwarding element. This keeps path computation
on the controller, limits installed segment-list churn on ingress
nodes, and reuses existing BGP propagation, route-reflection, and
policy filtering mechanisms.
BGP SR Policy is less suitable for continuously pushing highly
dynamic raw L0 measurements, such as instantaneous CPU load, memory
pressure, GPU queue depth, or per-flow utilization, on every change.
Frequent rewriting of segment lists and repeated BGP readvertisement
driven by L0 churn would cause unnecessary control-plane overhead,
route- reflector replication, and potential forwarding instability.
Yao, et al. Expires 17 April 2027 [Page 18]
Internet-Draft Protocols Applicability for CATS October 2026
Therefore, highly dynamic L0 measurements SHOULD be collected locally
by the C-SMA, smoothed, thresholded, aggregated, or converted into
L1/L2 metrics before influencing SR Policy candidate-path preference
or triggering updates.
In summary, BGP SR Policy is applicable to CATS when the objective is
to deliver centralized, service-aware SR candidate paths that bind
CS-ID/CSCI-ID to egress/SCI-specific segment lists, support weighted
or preference-ordered alternatives, and adapt path selection to
combined network and computing metrics within a controlled domain.
However, additional CATS-specific BGP SR Policy extensions or
metadata rules may be required to support explicit per-SCI
identification, compute-metric types and thresholds, shared-resource
scope, metric freshness or validity indication, and the association
between color/ Binding SID and the selected egress CATS-Forwarder/
SCI.
4.6. Yang Model Applicability for Service Configuration and Management
4.6.1. CATS specific Requirements for Service Configuration and
Management
As per [RFC10053] 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 for CATS system.
[I-D.ietf-cats-data-model] defines a YANG data model for the
management of Computing-Aware Traffic Steering (CATS) systems. The
model extends the "ietf-routing" YANG model defined in [RFC8349], is
agnostic to specific protocol extensions, and conforms to the
framework definition to serve as a critical diagnostic or control
mechanism.
The routing data model and ietf-routing YANG model primarily support
defined for the 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, and as detailed below the data model may consider:
Yao, et al. Expires 17 April 2027 [Page 19]
Internet-Draft Protocols Applicability for CATS October 2026
o It provides 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 provides 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 provides 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 enables the CATS-Forwarder to report events to the Control
Plane.
4.6.2. CATS specific Requirements for OAM (Operations, Administration,
and Maintenance) Support and Enhancement
Beyond the configuration and monitoring capabilities described above,
the CATS OAM effectively supporting both fault management and
performance management processes. Specifically:
o Fault Management: The model utilizes standardized notification
mechanisms (e.g., metric-limit-exceeded, connectivity-loss, etc.) to
report in real-time events such as service instance anomalies,
network path degradation, or resource overload. These proactive
notifications replace traditional polling, enabling the management
system to quickly locate the source of faults. Additionally, they
can be integrated with extended OAM tools such as PING/Traceroute to
perform CS-ID-based targeted diagnostics, thereby significantly
reducing Mean Time To Repair.
o Performance Management: The real-time state data provided by the
model (e.g., service processing latency, resource utilization,
traffic statistics, etc.) serves as the core data source for
performance monitoring. Performance thresholds can be defined
through the YANG model to trigger alarms or automatically adjust
policies. Furthermore, the model supports the collection and
reporting of CATS-specific performance metrics (e.g., traffic
distribution across different CSCI-IDs, variations in service
processing latency, etc.), providing data support for network
optimization.
Yao, et al. Expires 17 April 2027 [Page 20]
Internet-Draft Protocols Applicability for CATS October 2026
4.7. Data plane Protocols Applicability for Forwarding CATS Packets
As per [RFC10053] 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, and the CATS data
plane may consider:
o The egress CATS-Router decapsulates the encapsulation of the
packets.
o 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.
o Utilize the existing forwarding mechanism to forward packets from
the Ingress CATS-Router to the Egress CATS-Router through appropriate
encapsulation.
o On the Egress CATS-Router, the packets can be forwarded to the
corresponding service contact instance.
5. Security Considerations
The security considerations described in [RFC10053] 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
Yao, et al. Expires 17 April 2027 [Page 21]
Internet-Draft Protocols Applicability for CATS October 2026
[RFC10053] 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>.
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-data-model]
Yao, H., Lin, C., Li, Z., Xiong, Q., and L. M. Contreras,
"Data Model for Computing-Aware Traffic Steering (CATS)",
Work in Progress, Internet-Draft, draft-ietf-cats-data-
model-00, 23 September 2026,
<https://datatracker.ietf.org/doc/html/draft-ietf-cats-
data-model-00>.
[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>.
Yao, et al. Expires 17 April 2027 [Page 22]
Internet-Draft Protocols Applicability for CATS October 2026
[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>.
[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>.
Yao, et al. Expires 17 April 2027 [Page 23]
Internet-Draft Protocols Applicability for CATS October 2026
[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>.
[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>.
Yao, et al. Expires 17 April 2027 [Page 24]
Internet-Draft Protocols Applicability for CATS October 2026
[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>.
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.
Yao, et al. Expires 17 April 2027 [Page 25]
Internet-Draft Protocols Applicability for CATS October 2026
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.
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).
Yao, et al. Expires 17 April 2027 [Page 26]
Internet-Draft Protocols Applicability for CATS October 2026
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
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.
Yao, et al. Expires 17 April 2027 [Page 27]
Internet-Draft Protocols Applicability for CATS October 2026
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.
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:
Yao, et al. Expires 17 April 2027 [Page 28]
Internet-Draft Protocols Applicability for CATS October 2026
* 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.
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:
Yao, et al. Expires 17 April 2027 [Page 29]
Internet-Draft Protocols Applicability for CATS October 2026
Peng Liu
China Mobile
Email: liupengyjy@chinamobile.com
Authors' Addresses
Huijuan Yao
China Mobile
Email: yaohuijuan@chinamobile.com
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 17 April 2027 [Page 30]