Protocols Applicability for Computing-Aware Traffic Steering (CATS)

Internet-Draft	Protocols Applicability for CATS	July 2026
Yao, et al.	Expires 3 January 2027	[Page]

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.¶

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.¶

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 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:¶

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.¶

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.¶

* 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 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.¶

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.¶

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.¶

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.¶

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>.

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>.
[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>.
[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>.

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.¶

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 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.¶

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.¶

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.¶