| Internet-Draft | Protocols Applicability for CATS | January 2026 |
| Yao, et al. | Expires 13 July 2026 | [Page] |
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.¶
This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.¶
Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet-Drafts is at https://datatracker.ietf.org/drafts/current/.¶
Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress."¶
This Internet-Draft will expire on 13 July 2026.¶
Copyright (c) 2026 IETF Trust and the persons identified as the document authors. All rights reserved.¶
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Revised BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Revised BSD License.¶
[I-D.ietf-cats-framework] introduces a framework for Computing-Aware Traffic Steering (CATS). This document analyzes the corresponding protocols in control plane, management plane and data plane, and evaluates how far the existing protocols or be extended to support CATS such as metrics distribution and their operational requirements.¶
The terms defined in [I-D.ietf-cats-framework] can be used in this document.¶
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here.¶
As defined in [I-D.ietf-cats-framework], the CATS framework structure consists of the C-SMA (responsible for maintaining service metrics), the C-NMA (responsible for maintaining network metrics), the C-PS (responsible for maintaining forwarding table entries), and the C-TC (responsible for traffic classification).¶
The control plane protocols are used to distribute the CATS metrics of service,then to chose forwarding paths to the CATS service's destinatios. Based on [I-D.ietf-cats-framework], various relevant computing metrics are defined in [I-D.ietf-cats-metric-definition], which can be used in CATS. However, the protocols and technologies for distributing metrics from the egress gateway to the ingress gateway are still under research.Extensible protocols include YANG, BGP existing attribute, new BGP address family, FlowSpec, or BGP-LS. In addition, The FlowSpec protocol can be extended to accommodate the selection of CATS service paths. In addition, the control protocols are capable of controlling traffic classification include FlowSpec and YANG model. The FlowSpec is a distributed control method, while the YANG model is a centralized control method. These two protocol models can be extended to classify CATS data traffics.¶
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.¶
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.¶
As defined in [I-D.ietf-cats-framework] section 3.4.3, the CATS Network Metric Agent (C-NMA) is used to gather information about the state of the underlay network. The C-NMA could collect the network metrics leveraging the existing IGP (Interior Gateway Protocol) (e.g., OSPF-TE[RFC7471] and IS-IS TE [RFC8570]) and advertise them to the CATS Path Selector (C-PSes) through BGP-LS (Border Gateway Protocol Link State) [RFC8571].¶
As defined in [I-D.ietf-cats-framework] section 3.4.2, the CATS Service Metric Agent (C-SMA) is used to gather information about service sites and server resources, as well as the status of the different service instances. The C-SMA may collect the service information through private interfaces associated with multiple service contact instances and report them to the C-PSes through BGP-LS extensions for service metrics.¶
As defined in [I-D.ietf-cats-framework] section 4.2, the C-SMA needs to collect the computing-related capabilities and metrics, associate them with a CS-ID and distribute the computing metrics to the C-PSes. The C-NMA needs to collect the network-related capabilities and metrics, and distribute the network metrics to the C-PSes. The C-PSes could use the combination of computing and network metrics to determine the best Egress CATS-Forwarder to provide access to a service contact instance and invoke the compute function required by a service request.¶
BGP (Border Gateway Protocol) is an inter-Autonomous System (AS) routing protocol that enables the distribution of routing information across the networks. It operates between different AS, which are networks under a single administration to exchange network reachability information and determine the best paths for data transmission. The exsiting BGP technology (e.g., [RFC4271] and [I-D.ietf-idr-bgp4-rfc4271bis]) can be used to distribute the network metrics from the C-NMA to the C-PSes. The C-SMA may distribute the computing metrics to the C-PSes through BGP extensions for CATS.¶
As defined in [I-D.ietf-cats-framework] section 3.4.4, C-PSes determines the best paths to forward traffic after collecting the computing and network metrics. And a standalone C-PS can be a functional component of a PCE (Path Computation Element). The Path Computation Element Protocol (PCEP) as per [RFC5440] is used to enable computation of the path between a PCE and a Path Computation Client (PCC) (or other PCE).¶
The C-PSes which is viewed as a PCE can compute the best path from ingress CATS-Forwarder (which is viewed as a PCC)to egress CATS-Forwarder based on the network topology information from C-NMA. But in CATS, the C-PSes may firstly select the egress CATS-Forwarder and the related service instances and compute the path associated with the computing metric information from C-SMA. The C-PSes could also distribute the best path including the corresponding CS-ID and possibly CSCI-IDs through PCEP extensions.¶
A BGP Flow Specification (BGP-FS) is an n-tuple consisting of several matching criteria that can be applied to IP traffic such as BGP flow specification version 1 (FSv1) as per [RFC8955] and version 2 of the BGP flow specification (FSv2) as per [I-D.ietf-idr-flowspec-v2]. A service is identified by an prefix as defined in [RFC8955] and [RFC8956] can be used to steer the traffic in IP networks by L3 traffic filtering rules. The MPLS label filtering rules can be used to match the traffic in [I-D.ietf-idr-flowspec-mpls-match] and the MPLS label for a service mapping to a MPLS network can use the Label-action defined in [I-D.ietf-idr-bgp-flowspec-label]. It also could use the BGP FlowSpec to steer packets into an SR Policy as per [I-D.ietf-idr-ts-flowspec-srv6-policy].¶
As defined in [I-D.ietf-cats-framework] section 3.4.4, a standalone C-PS can be a functional component of a centralized controller. The BGP-FS may help the C-PSes to distribute the routes associated with computing metrics and steer the traffic for CATS services. The CATS services may be mapped to the corresponding CS-ID or SR Policy through BGP-FS extensions.¶
The ingress node can steer the packets into a specific path according to the Segment Routing Policy (SR Policy) as defined in [RFC9256] and the BGP SR Policy can be used to distribute SR policies to the headend as per [RFC9830].¶
As per [I-D.ietf-cats-framework] section 3.4.4, a standalone C-PS can be a functional component of a centralized controller. The C-PS may distribute SR policies to the CATS Ingress CATS-Router associated with computing metrics in SR-MPLS and SRv6 networks. The SR policy may be distributed to carry the identifiers of CATS services in candidate paths by the BGP SR Policy extensions.¶
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.¶
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 security considerations described in [I-D.ietf-cats-framework] and related routing protocols are applicable to this document. This document analyzed the applicability for some protocols which do not introduce any new extensions and new security considerations.¶
Currently this document does not make an IANA requests.¶
The following people have substantially contributed to this document:¶