]> China Mobile

yaohuijuan@chinamobile.com

Futurewei

ldunbar@futurewei.com

ZTE Corporation

xiong.quan@zte.com.cn

New H3C Technologies

linchangwang.04414@h3c.com

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

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

Conventions Used in This Document

Terminology The terms defined in 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 and .

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 when, and only when, they appear in all capitals, as shown here.

CATS Applicability Overview As defined in , 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 Applicability Analysis The control plane protocols are used to distribute the CATS metrics of service,then to chose forwarding paths to the CATS service's destinatios. Based on , various relevant computing metrics are defined in [I-D.ietf-cats-metric-definition], which can be used in CATS. However, the protocols and technologies for distributing metrics from the egress gateway to the ingress gateway are still under research.Extensible protocols include YANG, BGP existing attribute, new BGP address family, FlowSpec, or BGP-LS. In addition, The FlowSpec protocol can be extended to accommodate the selection of CATS service paths. In addition, the control protocols are capable of controlling traffic classification include FlowSpec and YANG model. The FlowSpec is a distributed control method, while the YANG model is a centralized control method. These two protocol models can be extended to classify CATS data traffics.

Management Plane Applicability Analysis Management plane protocols are used to manage and configure CATS systems. Existing PING and TRACE protocols may be utilized in CATS networks. These protocols could be extended to operate on specific CATS Service Identifiers (CS‑IDs). Alternatively, YANG models could be extended to report statistical information about CATS flows for monitoring purposes.

Data Plane Applicability Analysis The data plane protocols are used to forward the CATS traffiic to the corresponding destination by existing rotocols IPv4/IPv6 or IPv4/IPv6 over SRv6.

Protocols Applicability to CATS

BGP Applicability for Metrics Distribution As defined in 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 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.

IGP and BGP-LS Applicability for Metrics Distribution

IGP Applicability As defined in , 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 and the IS-IS TE metric extensions defined in , 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 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.

BGP-LS Applicability BGP Link State (BGP-LS) 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.

PCEP Applicability for Service-aware Computing As defined in 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) 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 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 ) 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.

BGP-FS Applicability for Service Mapping As defined in 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 for IPv4 and for IPv6, which defines the base protocol mechanisms for distributing flow specifications. Flow specification version 2 (FSv2) extensions that provide additional matching capabilities relevant for service identification. MPLS label matching and actions , for integration with MPLS-based CATS deployments. SRv6 policy steering mechanisms 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.

BGP SR Policy Applicability for Service-aware Candidate Paths As defined in 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 for defining and distributing Segment Routing policies, including the BGP SR Policy SAFI and associated NLRI format. Candidate path selection mechanisms that allow for multiple paths to the same destination with different characteristics and preferences. BGP-based policy distribution mechanisms that provide scalable propagation of SR policies across a network domain. Segment routing architecture capabilities 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.

Yang Model Applicability for Service Configuration and Management As per 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 . 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.

Data plane Protocols Applicability for Forwarding CATS Packets As per 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.

Security Considerations The security considerations described in 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.

IANA Considerations Currently this document does not make an IANA requests.

References Normative References Huawei Technologies China Mobile Orange Telefonica Independent This document describes a framework for Computing-Aware Traffic Steering (CATS). Specifically, the document identifies a set of CATS functional components, describes their interactions, and provides illustrative workflows of the control and data planes. Informative References L. Dunbar, et al C. Li, et al In many standards track documents several words are used to signify the requirements in the specification. These words are often capitalized. This document defines these words as they should be interpreted in IETF documents. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements. RFC 2119 specifies common key words that may be used in protocol specifications. This document aims to reduce the ambiguity by clarifying that only UPPERCASE usage of the key words have the defined special meanings. In certain networks, such as, but not limited to, financial information networks (e.g., stock market data providers), network performance information (e.g., link propagation delay) is becoming critical to data path selection. This document describes common extensions to RFC 3630 "Traffic Engineering (TE) Extensions to OSPF Version 2" and RFC 5329 "Traffic Engineering Extensions to OSPF Version 3" to enable network performance information to be distributed in a scalable fashion. The information distributed using OSPF TE Metric Extensions can then be used to make path selection decisions based on network performance. Note that this document only covers the mechanisms by which network performance information is distributed. The mechanisms for measuring network performance information or using that information, once distributed, are outside the scope of this document. In certain networks, such as, but not limited to, financial information networks (e.g., stock market data providers), network-performance criteria (e.g., latency) are becoming as critical to data-path selection as other metrics. This document describes extensions to IS-IS Traffic Engineering Extensions (RFC 5305). These extensions provide a way to distribute and collect network-performance information in a scalable fashion. The information distributed using IS-IS TE Metric Extensions can then be used to make path-selection decisions based on network performance. Note that this document only covers the mechanisms with which network-performance information is distributed. The mechanisms for measuring network performance or acting on that information, once distributed, are outside the scope of this document. This document obsoletes RFC 7810. This document defines new BGP - Link State (BGP-LS) TLVs in order to carry the IGP Traffic Engineering Metric Extensions defined in the IS-IS and OSPF protocols. This document discusses the Border Gateway Protocol (BGP), which is an inter-Autonomous System routing protocol. The primary function of a BGP speaking system is to exchange network reachability information with other BGP systems. This network reachability information includes information on the list of Autonomous Systems (ASes) that reachability information traverses. This information is sufficient for constructing a graph of AS connectivity for this reachability from which routing loops may be pruned, and, at the AS level, some policy decisions may be enforced. BGP-4 provides a set of mechanisms for supporting Classless Inter-Domain Routing (CIDR). These mechanisms include support for advertising a set of destinations as an IP prefix, and eliminating the concept of network "class" within BGP. BGP-4 also introduces mechanisms that allow aggregation of routes, including aggregation of AS paths. This document obsoletes RFC 1771. [STANDARDS-TRACK] Retired HPE Hickory Hill Consulting HPE This document discusses the Border Gateway Protocol (BGP), which is an inter-Autonomous System routing protocol. The primary function of a BGP-speaking system is to exchange network reachability information with other BGP systems. This network reachability information includes information on the list of Autonomous Systems (ASes) that reachability information traverses. This information is sufficient for constructing a graph of AS connectivity for this reachability from which routing loops may be pruned, and, at the AS level, some policy decisions may be enforced. BGP-4 provides a set of mechanisms for supporting Classless Inter- Domain Routing (CIDR). These mechanisms include support for advertising a set of destinations as an IP prefix, and eliminating the concept of network "class" within BGP. BGP-4 also introduces mechanisms that allow aggregation of routes, including aggregation of AS paths. This document obsoletes RFC 4271. This document specifies the Path Computation Element (PCE) Communication Protocol (PCEP) for communications between a Path Computation Client (PCC) and a PCE, or between two PCEs. Such interactions include path computation requests and path computation replies as well as notifications of specific states related to the use of a PCE in the context of Multiprotocol Label Switching (MPLS) and Generalized MPLS (GMPLS) Traffic Engineering. PCEP is designed to be flexible and extensible so as to easily allow for the addition of further messages and objects, should further requirements be expressed in the future. [STANDARDS-TRACK] This document defines a Border Gateway Protocol Network Layer Reachability Information (BGP NLRI) encoding format that can be used to distribute (intra-domain and inter-domain) traffic Flow Specifications for IPv4 unicast and IPv4 BGP/MPLS VPN services. This allows the routing system to propagate information regarding more specific components of the traffic aggregate defined by an IP destination prefix. It also specifies BGP Extended Community encoding formats, which can be used to propagate Traffic Filtering Actions along with the Flow Specification NLRI. Those Traffic Filtering Actions encode actions a routing system can take if the packet matches the Flow Specification. This document obsoletes both RFC 5575 and RFC 7674. "Dissemination of Flow Specification Rules" (RFC 8955) provides a Border Gateway Protocol (BGP) extension for the propagation of traffic flow information for the purpose of rate limiting or filtering IPv4 protocol data packets. This document extends RFC 8955 with IPv6 functionality. It also updates RFC 8955 by changing the IANA Flow Spec Component Types registry. Segment Routing (SR) leverages the source routing paradigm. A node steers a packet through an ordered list of instructions, called "segments". A segment can represent any instruction, topological or service based. A segment can have a semantic local to an SR node or global within an SR domain. SR provides a mechanism that allows a flow to be restricted to a specific topological path, while maintaining per-flow state only at the ingress node(s) to the SR domain. SR can be directly applied to the MPLS architecture with no change to the forwarding plane. A segment is encoded as an MPLS label. An ordered list of segments is encoded as a stack of labels. The segment to process is on the top of the stack. Upon completion of a segment, the related label is popped from the stack. SR can be applied to the IPv6 architecture, with a new type of routing header. A segment is encoded as an IPv6 address. An ordered list of segments is encoded as an ordered list of IPv6 addresses in the routing header. The active segment is indicated by the Destination Address (DA) of the packet. The next active segment is indicated by a pointer in the new routing header. Segment Routing (SR) allows a node to steer a packet flow along any path. Intermediate per-path states are eliminated thanks to source routing. SR Policy is an ordered list of segments (i.e., instructions) that represent a source-routed policy. Packet flows are steered into an SR Policy on a node where it is instantiated called a headend node. The packets steered into an SR Policy carry an ordered list of segments associated with that SR Policy. This document updates RFC 8402 as it details the concepts of SR Policy and steering into an SR Policy. A Segment Routing (SR) Policy is an ordered list of segments (also referred to as "instructions") that define a source-routed policy. An SR Policy consists of one or more Candidate Paths (CPs), each comprising one or more segment lists. A headend can be provisioned with these CPs using various mechanisms such as Command-Line Interface (CLI), Network Configuration Protocol (NETCONF), Path Computation Element Communication Protocol (PCEP), or BGP. This document specifies how BGP can be used to distribute SR Policy CPs. It introduces a BGP SAFI for advertising a CP of an SR Policy and defines sub-TLVs for the Tunnel Encapsulation Attribute to signal information related to these CPs. Furthermore, this document updates RFC 9012 by extending the Color Extended Community to support additional steering modes over SR Policy. This document specifies three YANG modules and one submodule. Together, they form the core routing data model that serves as a framework for configuring and managing a routing subsystem. It is expected that these modules will be augmented by additional YANG modules defining data models for control-plane protocols, route filters, and other functions. The core routing data model provides common building blocks for such extensions -- routes, Routing Information Bases (RIBs), and control-plane protocols. The YANG modules in this document conform to the Network Management Datastore Architecture (NMDA). This document obsoletes RFC 8022. Hickory Hill Consulting Futurewei Technologies ATT Verizon BGP flow specification version 1 (FSv1), defined in RFC 8955, RFC 8956, and RFC 9117 describes the distribution of traffic filter policy (traffic filters and actions) distributed via BGP. Multiple applications have used BGP FSv1 to distribute traffic filter policy. These applications include the following: mitigation of denial of service (DoS), enabling traffic filtering in BGP/MPLS VPNs, centralized traffic control of router firewall functions, and SFC traffic insertion. During the deployment of BGP FSv1 a number of issues were detected due to lack of consistent TLV encoding for rules for flow specifications, lack of user ordering of filter rules and/or actions, and lack of clear definition of interaction with BGP peers not supporting FSv1. Version 2 of the BGP flow specification (FSv2) protocol addresses these features. In order to provide a clear demarcation between FSv1 and FSv2, a different NLRI encapsulates FSv2. Huawei Huawei Huawei Huawei This draft proposes BGP flow specification rules that are used to filter MPLS labeled packets. Huawei Huawei Huawei Nozomi Cisco Systems This document specifies a method in which the label mapping information for a particular FlowSpec rule is piggybacked in the same Border Gateway Protocol (BGP) Update message that is used to distribute the FlowSpec rule. Based on the proposed method, the Label Switching Routers (LSRs) (except the ingress LSR) on the Label Switched Path (LSP) can use label to indentify the traffic matching a particular FlowSpec rule; this facilitates monitoring and traffic statistics for FlowSpec rules. China Mobile China Mobile Huawei Technologies Verizon Communications Inc. Huawei Technologies BGP Flow Specification (FlowSpec) [RFC8955] and [RFC8956] has been proposed to distribute BGP [RFC4271] FlowSpec NLRI to FlowSpec clients to mitigate (distributed) denial-of-service attacks, and to provide traffic filtering in the context of a BGP/MPLS VPN service. Recently, traffic steering applications in the context of SR-MPLS and SRv6 using FlowSpec are being used in networks. This document introduces the usage of BGP FlowSpec to steer packets into an SR Policy. In many environments, a component external to a network is called upon to perform computations based on the network topology and the current state of the connections within the network, including Traffic Engineering (TE) information. This is information typically distributed by IGP routing protocols within the network. This document describes a mechanism by which link-state and TE information can be collected from networks and shared with external components using the BGP routing protocol. This is achieved using a BGP Network Layer Reachability Information (NLRI) encoding format. The mechanism applies to physical and virtual (e.g., tunnel) IGP links. The mechanism described is subject to policy control. Applications of this technique include Application-Layer Traffic Optimization (ALTO) servers and Path Computation Elements (PCEs). This document obsoletes RFC 7752 by completely replacing that document. It makes some small changes and clarifications to the previous specification. This document also obsoletes RFC 9029 by incorporating the updates that it made to RFC 7752. The Hierarchical Path Computation Element (H-PCE) architecture is defined in RFC 6805. It provides a mechanism to derive an optimum end-to-end path in a multi-domain environment by using a hierarchical relationship between domains to select the optimum sequence of domains and optimum paths across those domains. This document defines extensions to the Path Computation Element Communication Protocol (PCEP) to support H-PCE procedures. Futurewei Futurewei China Telecom This draft describes using additional site capacity and preference related metrics to influence the SPF and using Flexible Algorithms to indicate the topologies those metrics are applied. The purpose is to differentiate multiple paths with similar routing distance to one destination in 5G Local Data Network (LDN)to achieve optimal performance.

BGP Edge Metadata Path Applicability

Summary of 5G Edge Service Metadata Mechanism

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.

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.

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:

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.

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.

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.

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.

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

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.

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.

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.

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.

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.

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: China Mobile

liupengyjy@chinamobile.com