]> Ciena Corporation

mkoldych@proton.me

Ciena Corporation

ssivabal@ciena.com

Huawei Technologies

pengshuping@huawei.com

Nokia

diego.achaval@nokia.com

Juniper Networks, Inc

hkotni@juniper.net

Nokia

andrew.stone@nokia.com

Path Computation Element This document clarifies certain operational behavior aspects of the PCEP protocol. The content of this document has been compiled based on several interop exercises. Discussion Venues Discussion of this document takes place on the Path Computation Element mailing list (pce@ietf.org), which is archived at . Source for this draft and an issue tracker can be found at .

Introduction Due to different interpretations of PCEP standards, it was found that implementations often had to adjust their behavior in order to interoperate. The current document serves to clarify certain aspects of PCEP to make it easier to produce interoperable implementations of PCEP.

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.

Terminology The following terminologies are used in this document: PCC: Path Computation Client. Any client application requesting a path computation to be performed by a Path Computation Element. PCE: Path Computation Element. An entity (component, application, or network node) that is capable of computing a network path or route based on a network graph and applying computational constraints. PCEP: Path Computation Element Protocol. MBB: Make-Before-Break. A procedure during which the head-end of a traffic-engineered path wishes to move traffic to a new path without losing any traffic, by first "making" a new path and then "breaking" the old path. Association parameters: As described in , the combination of the mandatory fields Association type, Association ID and Association Source in the ASSOCIATION object uniquely identify the association group. If the optional TLVs - Global Association Source or Extended Association ID are included, then they are included in combination with mandatory fields to uniquely identify the association group. Association information: As described in , the ASSOCIATION object could also include other optional TLVs based on the association types, that provides 'information' related to the association type. ERO: Explicit Route Object is the path of the LSP encoded into a PCEP object. In this document, an empty ERO object, i.e., without any subobjects, is represented with notation "ERO={}". An ERO object containing a given sequence of subobjects is represented as "ERO={A}". PCRPT-LSP-DB: PCEP Reported Label Switched Path Database. A logical datastore that captures the reported state information of Label Switched Paths (LSPs) within a PCEP speaker. This term is not defined in the PCE architecture; however, it is used in this document to describe how a PCEP speaker internally maintains LSP-related state information reported via PCRpt messages. EXTENDED-LSP-DB: Extended Label Switched Path Database. An implementation-specific logical datastore used to capture information related to a Label Switched Path. It may be keyed using the same identifiers as the PCRPT-LSP-DB. This term is not defined in the PCE architecture; however is used in this document to refer to a conceptual datastore that can include additional attributes—such as desired state, telemetry data, and other information not defined within IETF PCE working group documents. PLSP-ID (Path LSP Identifier): Introduced in . A unique identifier used in PCEP to distinguish a specific LSP between a PCC and a PCE which is constant for the lifetime of a PCEP session.

PCEP LSP Database This document uses the concept of the PCRPT-LSP-DB, a database of actual LSP state in the network, to illustrate the internal state of PCEP speakers in response to PcRpt messages. Note that the term "LSP", which stands for "Label Switched Path", if taken too literally, would restrict the discussion to the MPLS dataplane only. In this document, the term "LSP" is applied to non-MPLS paths as well, to avoid renaming the term. Alternatively, the term "LSP" could be replaced with "Instance".

Structure The distinction between Tunnels and LSPs in the PCRPT-LSP-DB is essential for accurately modeling state information in PCEP, including procedures such as make-before-break, and for maintaining consistent state management across PCEP speakers. The PCRPT-LSP-DB contains two types of information: LSPs and Tunnels. An LSP is identified by the LSP-IDENTIFIERS TLV, while a Tunnel is identified by the PLSP-ID in the LSP object and/or the SYMBOLIC-NAME (see ). A Tunnel may or may not correspond to an actual tunnel on the router. For example, working and protect paths can be implemented as a single tunnel interface, but in PCEP, these are represented as two different Tunnels with different PLSP-IDs. An LSP can be viewed as an instance of a Tunnel. In steady state, a Tunnel typically has a single LSP; however, during make-before-break procedures (see ), multiple LSPs may exist simultaneously to represent both the new and old instances during the transition.

Synchronization Since the PCRPT-LSP-DB contains PCEP-specific information such as PLSP-IDs, which remain constant for the duration of a PCEP session, both the PCE and PCC maintain their own local copies of the PCRPT-LSP-DB. The PCE PCRPT-LSP-DB is only modified by PCRpt messages, no other PCEP message may modify the PCE PCRPT-LSP-DB. The PCC PCRPT-LSP-DB is built from actual forwarding state that PCC has installed. PCC uses PCRpt messages to synchronize its local PCRPT-LSP-DB to the PCE. The PCE is intended to act based on the most recent state available in the PCRPT-LSP-DB, which represents the actual state of Label Switched Paths (LSPs) in the network. This does not preclude the PCE from leveraging information obtained outside the PCRPT-LSP-DB. For example, implementation-specific mechanisms may be used to collect traffic statistics that can be considered during path computation. Such information is not part of the PCRPT-LSP-DB itself, but may reference it. Additional data such as desired state, telemetry, or operator-intended configurations—may be maintained in a separate, implementation-specific logical datastore referred to as the EXTENDED-LSP-DB. Both the PCE and PCC maintain a PCRPT-LSP-DB that reflects the reported (actual) state of LSPs. Implementations may choose to store desired state information or other attributes in the EXTENDED-LSP-DB. It is important to note that the PCRPT-LSP-DB reflects only the live view of the network and does not imply alignment with the desired state. For example, in the case of a PCE-initiated LSP, a change in the LSP configuration made by an operator represents a modification to the desired state. However, the actual state does not change until the PCE sends a PCInit or PCUpd message to the PCC. Upon receipt of such a message, the PCC may act on the request, update its local PCRPT-LSP-DB, and generate a PCRpt message to inform the PCE of the change. The PCE then updates its own PCRPT-LSP-DB accordingly. Once this exchange is complete, the PCRPT-LSP-DBs on both the PCC and the PCE are synchronized.

Make before Break (MBB) Due to variations in how different implementations interpret or handle MBB procedures—sometimes resulting in incorrect message processing or misinterpretation—the following section provides illustrative examples to clarify expected MBB behavior.

Successful MBB Below is an example of performing MBB to switch a Tunnel from one path to another. The path encoded into the ERO object is represented as ERO={A} and ERO={B}. PCC has an existing LSP in UP state, with LSP-ID=2. PCC sends PCRpt(R-FLAG=0, PLSP-ID=100, LSP-ID=2, ERO={A}, OPER-FLAG=UP). PCC initiates the MBB procedure by creating a new LSP with LSP-ID=3. It does not matter what triggered the creation of the new LSP, it could have been due to a new path received via PCUpd (if the given Tunnel is delegated), or it could have been local computation on the PCC (if the Tunnel is locally computed on the PCC), or it could have been a change in configuration on the PCC (if the Tunnel's path is explicitly configured on the PCC). It is important to emphasize that the procedure for updating the PCRPT-LSP-DB is common, regardless of the trigger that caused the change. PCC sends PCRpt(R-FLAG=0, PLSP-ID=100, LSP-ID=3, ERO={B}, OPER- FLAG=UP). After traffic has successfully switched to the new LSP, the PCC cleans up the old LSP. PCC sends PCRpt(R-FLAG=1, PLSP-ID=100, LSP- ID=2).

Aborted MBB The MBB process can abort when the newly created LSP is destroyed before it is installed as traffic carrying. This scenario is described below. PCC has an existing LSP in UP state, with LSP-ID=2. PCC sends PCRpt(R-FLAG=0, OPER-FLAG=UP, PLSP-ID=100, LSP-ID=2). MBB procedure is initiated, a new LSP is created with LSP-ID=3. LSP is currently being established, so its oper state is DOWN. PCC sends PCRpt(R-FLAG=0, OPER-FLAG=DOWN, PLSP-ID=100, LSP-ID=3). MBB procedure is aborted. PCC sends PCRpt(R-FLAG=1, PLSP-ID=100, LSP-ID=3).

PCEP Association Database PCEP Association is the instantiate of a group containing at least one LSP. The PCE ASSO DB is populated by PCRpt messages and/or via configuration on the PCE itself. An Association is identified by the Association Parameters. As the Association Parameters contain many fields, all fields are grouped into a single value for convenience. The notation ASSO_PARAM=A and ASSO_PARAM=B is used to refer to different PCEP Associations: A and B, respectively.

LSPs in same Association The following example illustrates how LSPs join the same Association. PCC creates the first LSP. PCC sends PCRpt(R-FLAG=0, PLSP-ID=100, LSP-ID=1, ASSO_PARAM=A, ASSO_R_FLAG=0). PCC creates the second LSP. PCC sends PCRpt(R-FLAG=0, PLSP-ID=200, LSP-ID=1, ASSO_PARAM=A, ASSO_R_FLAG=0). PCC updates the first LSP. As indicates, subsequent PcRpt should include only the associations that are being modified or removed. Therefore it is optional as to send the ASSOCIATION object in this PCRpt, since the LSP is already in the Association. PCC sends PCRpt(R-FLAG=0, PLSP-ID=100, LSP-ID=1). The content of the PCE ASSO DB is unchanged. Note that the PCC sends the ASSOCIATION OBJECT in the first PCRpt during SYNC state, even if it has already issued a PCRpt with the association object sometime in the past with this PCE. The synchronization steps outlined in are to be followed. PCC decides to delete the second LSP. PCC sends PCRpt(R-FLAG=1, PLSP-ID=200, LSP-ID=1). PCC decides to remove the first LSP from the Association, but not delete the LSP itself. PCC sends PCRpt(R-FLAG=0, PLSP-ID=100, LSP- ID=1, ASSO_PARAM=A, ASSO_R_FLAG=1). The PCE ASSO DB is now empty.

Switch Association during MBB The following example illustrates how a Tunnel goes through MBB and switches from Association A to Association B. Each new LSP (identified by the LSP-ID) does not inherit the Association membership of any previous LSPs within the same Tunnel. This is so that a Tunnel can have two LSPs that are in different Associations, this may be done when switching from one Association to another. PCC creates the first LSP. PCC sends PCRpt(R-FLAG=0, PLSP-ID=100, LSP-ID=1, ASSO_PARAM=A, ASSO_R_FLAG=0). PCC creates the MBB LSP in a different Association. PCC sends PCRpt(R-FLAG=0, PLSP-ID=100, LSP-ID=2, ASSO_PARAM=B, ASSO_R_FLAG=0). PCC deletes the old LSP. PCC sends PCRpt(R-FLAG=1, PLSP-ID=100, LSP- ID=1).

Computation Constraints As well as reporting any state change in the network on a PCRpt message, a PCC may also change the parameters of a delegated LSP. For example, it may remove or modify the computation constraints that it wishes the PCE to apply as it computes any updated paths in the future. For any PCEP object that specifies a path computation constraint and that does not have a defined explicit removal flag, the absence of that entire object on a repeat or follow-up PcRpt message indicates removal of the constraint previously specified by that object. For example, suppose the first PcRpt contains an LSPA object with some affinity constraints. Then if a subsequent PcRpt does not contain an LSPA object, then this means that the previously specified affinity constraints do not apply anymore. Same applies to all PCEP objects, like METRIC, BANDWIDTH, etc., which do not have an explicit flag for removal. This simply ensures that it is possible to remove a constraint without using an explicit removal flag.

Overloaded PCE [RFC5440] defines the concept of an Overloaded PCE and explains how a PCE may signal to a PCC that it is congested, instructing that "no requests should be sent to that PCE until the overload state is cleared." In the case of an overloaded PCE, a PCC implementation could choose to wait for the PCE to no longer be overloaded or instead send a PcReq to a backup, non-overloaded PCE instead. builds upon [RFC5440] by introducing the concept of a Stateful PCE, which allows delegation of LSP control to a single PCE. However, it does not address the case of an overloaded PCE. According to , a PCE maintains delegation until it is revoked by the PCC or returned back to PCC by the PCE. The PCC may revoke delegation and re-assign it to another PCE. As a result, a PCE in an overload state still retains LSP delegation. For PCC-initiated LSPs, the PCC may revoke delegation from the overloaded PCE and maintain delegation for itself or delegate it to another PCE. For PCE-initiated LSPs, since the PCC cannot revoke delegation as per [RFC8281], the overloaded PCE may return the delegation to the PCC. The PCE will continue to send PcRpt messages to PCE even though it may indicate it is overloaded, otherwise the the PCRPT-LSP-DB on PCE may go out of sync.

Security Considerations None at this time.

Managability Considerations None at this time.

IANA Considerations None at this time.

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. 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. This document introduces a generic mechanism to create a grouping of Label Switched Paths (LSPs) in the context of a Path Computation Element (PCE). This grouping can then be used to define associations between sets of LSPs or between a set of LSPs and a set of attributes (such as configuration parameters or behaviors), and it is equally applicable to the stateful PCE (active and passive modes) and the stateless PCE. 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]

Acknowledgments The authors would like to thank Adrian Farrel and Tom Petch for useful review and feedback. comments.

Contributors