]> ZTE Corporation

xiong.quan@zte.com.cn

ZTE Corporation

fu.huakai@zte.com.cn

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

Introduction 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 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 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. discussed the PCEP applicability for CATS. This document proposes the PCEP extensions for selecting and distributing the paths for CATS services.

Conventions Used in This Document

Abbreviations

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.

C-PS as a PCE for CATS Service As per , 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.

PCEP Extensions

METRIC Object The METRIC object is defined in Section 7.8 of , comprising metric-value and metric-type (T field), and a flags field, comprising a number of bit flags (B bit and C bit). This document defines the Computing metric type for the METRIC object to represent the consideration of computing metric of CATS services. The extensions for Computing Metric are as following shown: *T=TBD1: Computing Metric. *The value of Computing Metric is the encoding in 32bits with units and values as defined in .

LSP Object The LSP Object is defined in Section 7.3 of . 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 . 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.

CS-ID TLV 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. where:

• Type: TBD2.
• Length: variable.
• CS-ID: indicates the identifier associated with the CATS service. 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.

CSCI-ID Sub-TLV The format of CSCI-ID Sub-TLV is shown in Figure 3 as follows: where:

• Type: TBD3.
• 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.

ERO Object The ERO (Explicit Route Object) specified in and 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 and SRv6-ERO subobject as per . 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.

Operations

CATS Service Path Computation When a PCC (e.g., an ingress CATS-Router) requires path computation for a CATS service, it sends a PCReq message to the PCE (C-PS). The LSP Object MUST include the C-flag set to 1 in the LSP-EXTENDED-FLAG TLV, indicating a request for CATS service path computation. The CS-ID TLV MAY be included to specify a particular CATS service identifier. The PCC MAY include a METRIC object in the PCReq message with the metric type set to Computing Metric (T=TBD1). By setting the B-flag, the PCC can indicate that this computing metric should be used as a bounded constraint for path computation; by setting the C-flag, the PCC can request the PCE to optimize this computing metric during path calculation. Upon receiving a CATS service path computation request, the PCE evaluates both network metrics (e.g., bandwidth, latency) and computing metrics (e.g., server load, computational capacity) collected from C-NMA and C-SMA. The PCE selects the optimal egress CATS-Router that connects to the appropriate service contact instance (CSCI-ID). The PCE computes the path from the ingress CATS-Router to the selected egress CATS-Router. In the PCRep message, the LSP Object MUST have the C-flag set to 1 in the LSP-EXTENDED-FLAG TLV. The CS-ID TLV MUST be included, containing the assigned or confirmed CATS service identifier. The CSCI-ID Sub-TLV MUST be included within the CS-ID TLV, identifying the selected service contact instance. The ERO Object MUST include the computed path, with the C-flag set to 1 in the sub-object representing the egress CATS-Router.

Stateful PCE Operations During LSP initialization (PCInitiate), the PCE MAY include CATS service parameters in the LSP Object to establish CATS service paths proactively. For LSP update (PCUpd), the PCE MAY modify existing CATS service paths based on changes in computing resource status or network conditions. The PCC SHOULD report LSP state (PCRpt) including CATS service parameters to enable the PCE to maintain synchronized state information.

Security Considerations The existing PCEP security considerations as described in , , and other relevant stateful PCEP specifications are also applicable to the PCEP extensions defined in this document.

IANA Considerations This document requests IANA to make the following allocations in the PCEP parameters registries.

METRIC Object Type Indicators IANA is requested to allocate a new value from the "PCEP METRIC Object Metric Types" registry:

PCEP TLV Type Indicators IANA is requested to allocate the following TLV Type values from the "PCEP TLV Type Indicators" registry:

LSP-EXTENDED-FLAG TLV Flag Field IANA is requested to allocate a new bit from the "LSP-EXTENDED-FLAG Object LSP-EXTENDED-FLAG Field" sub-registry of the "Path Computation Element Protocol (PCEP) Numbers" registry:

ERO Subobject Flags IANA is requested to allocate a new flag from the "ERO Subobject Flags" registry:

Contributors The following people have substantially contributed to this document:

Normative References 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. 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. 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] The Path Computation Element Communication Protocol (PCEP) provides mechanisms for Path Computation Elements (PCEs) to perform path computations in response to Path Computation Client (PCC) requests. Although PCEP explicitly makes no assumptions regarding the information available to the PCE, it also makes no provisions for PCE control of timing and sequence of path computations within and across PCEP sessions. This document describes a set of extensions to PCEP to enable stateful control of MPLS-TE and GMPLS Label Switched Paths (LSPs) via PCEP. RFC 8231 describes a set of extensions to the Path Computation Element Communication Protocol (PCEP) to enable stateful control of MPLS-TE and GMPLS Label Switched Paths (LSPs) via PCEP. One of the extensions is the LSP object, which includes a Flag field with a length of 12 bits. However, all bits of the Flag field have already been assigned. This document defines a new LSP-EXTENDED-FLAG TLV for the LSP object for an extended Flag field. This document describes the use of RSVP (Resource Reservation Protocol), including all the necessary extensions, to establish label-switched paths (LSPs) in MPLS (Multi-Protocol Label Switching). Since the flow along an LSP is completely identified by the label applied at the ingress node of the path, these paths may be treated as tunnels. A key application of LSP tunnels is traffic engineering with MPLS as specified in RFC 2702. [STANDARDS-TRACK] Segment Routing (SR) enables any head-end node to select any path without relying on a hop-by-hop signaling technique (e.g., LDP or RSVP-TE). It depends only on "segments" that are advertised by link-state Interior Gateway Protocols (IGPs). An SR path can be derived from a variety of mechanisms, including an IGP Shortest Path Tree (SPT), an explicit configuration, or a Path Computation Element (PCE). This document specifies extensions to the Path Computation Element Communication Protocol (PCEP) that allow a stateful PCE to compute and initiate Traffic-Engineering (TE) paths, as well as a Path Computation Client (PCC) to request a path subject to certain constraints and optimization criteria in SR networks. This document updates RFC 8408. Segment Routing (SR) can be used to steer packets through a network using the IPv6 or MPLS data plane, employing the source routing paradigm. An SR Path can be derived from a variety of mechanisms, including an IGP Shortest Path Tree (SPT), explicit configuration, or a Path Computation Element (PCE). Since SR can be applied to both MPLS and IPv6 data planes, a PCE should be able to compute an SR Path for both MPLS and IPv6 data planes. The Path Computation Element Communication Protocol (PCEP) extension and mechanisms to support SR-MPLS have been defined. This document outlines the necessary extensions to support SR for the IPv6 data plane within PCEP. 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. The framework covers only the case of a single service provider. China Mobile Huawei Technologies Telefonica Qualcomm Europe, Inc. Huawei Technologies Computing-Aware Traffic Steering (CATS) is a traffic engineering approach that optimizes the steering of traffic to a service instance by considering the dynamic state of computing and network resources. To enable such decisions, CATS components exchange metrics that describe resource conditions affecting service instance selection. This document focuses on compute and communication metrics for CATS and defines a hierarchical abstraction of these metrics to improve interoperability, scalability, and operational simplicity. It does not aim to standardize raw infrastructure (Level 0) metrics; instead, it specifies higher-level representations that can be derived from raw measurements using aggregation and normalization functions. China Mobile Futurewei ZTE Corporation New H3C Technologies 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.