| Internet-Draft | PCEP Extensions for CATS Service | December 2025 |
| Xiong & Fu | Expires 7 June 2026 | [Page] |
The CATS (Computing-Aware Traffic Steering) can steer traffic between clients of a service and sites offering the service. The C-PS may be deployed as a PCE and the ingress CATS-Router could be viewed as a PCC. This document proposes the PCEP extensions for selecting and distributing the paths for CATS services.¶
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 7 June 2026.¶
Copyright (c) 2025 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.¶
[RFC5440] describes the Path Computation Element Protocol (PCEP) which is used between a Path Computation Element (PCE) and a Path Computation Client (PCC) (or other PCE) to enable computation of Multi-protocol Label Switching (MPLS) for Traffic Engineering Label Switched Path (TE LSP). PCEP Extensions for the Stateful PCE Model [RFC8231] describes a set of extensions to PCEP to enable active control of MPLS-TE and Generalized MPLS (GMPLS) tunnels.¶
The CATS (Computing-Aware Traffic Steering) as per [I-D.ietf-cats-framework] can steer traffic between clients of a service and sites offering the service. The CATS service may be steered from an Ingress CATS-Router to an Egress CATS-Router while using an anycast IP address as the Computing-aware Service ID (CS-ID) associated with a service. And the CATS Service Contact Instance ID (CSCI-ID) is representing a specific service contact instance which serves the service request. The C-PS may be deployed as a PCE and the ingress CATS-Router could be viewed as a PCC. This document proposes the PCEP extensions for selecting and distributing the paths for CATS services.¶
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 per [I-D.ietf-cats-framework], a standalone C-PS can be a functional component of a centralized controller or PCE. And C-PS will collect the metric information from C-SMA and C-NMA and also determine the best paths to forward traffic. The metric information from C-NMA may include the topology information. The C-PS may compute the path associated with the computing metric information.¶
The Figure 1 shows an example of C-PS which is deployed as a PCE to select the best path for CATS service. The compute information (e.g anycast IP addresses) will be distributed from the Service Sites to the C-PS through BGP extensions. The PCE may select the egress router based on this information and compute the best path from ingress router to the egress node. For example, the path is selected from CATS-Forwarder 1 as ingress node to CATS-Forwarder 2 as egress node for the CATS service refereed as CS-ID 1 which is also allocated by PCE. Two service sites with service contact instances represented with CSCI-ID 1 and CSCI-ID 2 are connected to the CATS-Forwarder 2 from the output interfaces.¶
+------+
:<------| C-PS |
: | (PCE)|<------+ Service Site 1
: +------+ | +---------+
: ^ | +---|CS-ID 1 |
: | | | |CSCI-ID 1|
: | +----------------+ | +---------+
: | | C-SMA |---| Service Site 2
: | +----------------+ | +---------+
: | |CATS-Forwarder 2| +---|CS-ID 1 |
: | +----------------+ |CSCI-ID 2|
+--------+ : | | +---------+
| Client | : Network | +----------------------+
+--------+ : metrics | | +-------+ |
| : +----| C-NMA | |
| : | +-------+ |
+----------------+ | | |
|CATS-Forwarder 1|<-----------+ |
|(PCC) |-------| |
+----------------+ | Underlay |
| Infrastructure |
| |
+----------------------+
Figure 1: Example of PCE to Select Service Path for CATS
¶
The LSP Object is defined in Section 7.3 of [RFC8231]. This document defines a new flag (C-flag) to present the CATS service path for the LSP-EXTENDED-FLAG TLV carried in LSP Object as defined in [RFC9357].¶
C (Request for CATS Service Path) : If the bit is set to 1, it indicates that the PCC requests PCE to compute the CATS service path. A PCE would also set this bit to 1 to indicate that the CATS service path is included by PCE and encoded in the PCRep, PCUpd or PCInitiate message.¶
The CS-ID TLV is an optional TLV for use in the LSP Object for the allocation of CATS service identification. The format is as shown below.¶
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ CS-ID ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ sub-TLVs ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 2: CS-ID TLV
¶
where:¶
The format of CSCI-ID Sub-TLV is shown in Figure 3 as follows:¶
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length | Flags | RESERVED |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ CSCI-ID ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 3: CSCI-ID Sub-TLV
¶
where:¶
Type: TBD.¶
Length: variable.¶
Flags: 1 octet of flags. None are defined at this stage. Flags SHOULD be set to zero on transmission and MUST be ignored on receipt.¶
RESERVED: 1 octet of reserved bits. SHOULD be set to zero on transmission and MUST be ignored on receipt.¶
CSCI-ID: indicates the identifier for a specific service contact instance. It is 4 octets which carry a 32-bit unsigned non-zero number in IPv4 networks and 16 octets which carry a 128-bit unsigned non-zero number in IPv6 networks.¶
The ERO (Explicit Route Object) specified in [RFC3209] and [RFC5440] can be used to carry a set of computed paths. The SR-TE and SRv6-TE paths can be specified by means of SR-ERO subobject as per [RFC8664] and SRv6-ERO subobject as per [RFC9603]. This document defines a new flag (C-flag) to present the CATS service path for the PCC to identify the egress router associated with the service instances.¶
C (Indicate the egress router for CATS service) : If the bit is set to 1, it
indicates that this node is the egress router associated with the service instances.
For example, in SR networks, it indicates the service SID for the egress router in CATS
when the C is set to 1 which is carried in SR-ERO subobject.¶
To be discussed in future versions of this document.¶
To be discussed in future versions of this document.¶
TBD.¶