Protocols Applicability for Computing-Aware Traffic Steering (CATS)

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

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

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

CATS-Specific Requirements for PCEP Extensions As defined in 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) 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.

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

BGP-FS Applicability for Service Mapping

CATS-Specific Requirements for BGP-FS Extensions As defined in 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.

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 for IPv4/IPv4-VPN and 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. 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.

BGP SR Policy Applicability for Service-aware Candidate Paths

CATS-Specific Requirements for BGP SR Policy Extensions As defined in 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. 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.

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 and builds on the SR Policy architecture in and the Segment Routing base in . 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. 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.

Yang Model Applicability for Service Configuration and Management

CATS specific Requirements 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 for CATS system. 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 , 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 . 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: 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.

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.

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

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.