| Internet-Draft | PCEP-OPERATIONAL | March 2025 |
| Koldychev, et al. | Expires 3 September 2025 | [Page] |
This document clarifies certain aspects of the PCEP protocol. The content of this document has been compiled based on several interop exercises.¶
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 3 September 2025.¶
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.¶
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.¶
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.¶
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 [RFC8697], 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 MUST be included in combination with mandatory fields to uniquely identify the association group.¶
Association information: As described in [RFC8697], 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. To represent an empty ERO object, i.e., without any subobjects, we use the notation "ERO={}". To represent an ERO object containing some given sequence of subobjects, we use the notation "ERO={A}".¶
We use the concept of the LSP-DB, as a database of actual LSP state in the network, to illustrate the internal state of PCEP speakers in response to various PCEP messages.¶
Note that the term "LSP", which stands for "Label Switched Path", if taken too literally would restrict our discussion to MPLS dataplane only. We take the term "LSP" to apply to non-MPLS paths as well, to avoid changing the name. Alternatively, we could rename LSP to "Instance".¶
LSP-DB contains two types of objects: LSPs and Tunnels. An LSP is identified by the LSP-IDENTIFIERS TLV. A Tunnel is identified by the PLSP-ID in the LSP object and/or the SYMBOLIC-NAME. See [RFC8231].¶
A Tunnel may or may not be an actual tunnel on the router. For example, working and protect paths can be implemented as a single tunnel interface, but in PCEP we would refer to them as two different Tunnels, because they would have different PLSP-IDs.¶
An LSP can be thought of as a instance of a Tunnel. In steady-state, a Tunnel has only one LSP, but during make-before-break (see [RFC3209]) it can have multiple LSPs, to represent both new and old instances that exist simultaneously for a time.¶
Both PCE and PCC maintain their separate copies of the LSP-DB. The PCE LSP-DB is only modified by PCRpt messages, no other PCEP message may modify the PCE LSP-DB. The PCC LSP-DB is built from actual forwarding state that PCC has installed. PCC uses PCRpt messages to synchronize its local LSP-DB to the PCE.¶
The PCE MUST always act on the latest state of the PCE LSP DB. Note that this does not mean that the PCE cannot use information from outside of LSP-DB. For example, the PCE can use other mechanisms to collect traffic statistics and use them in the computation. However, these traffic statistics are not part of the LSP-DB, but only reference it.¶
The LSP-DB on both the PCC and the PCE only stores the actual state in the network, it does not store the desired state. For example, consider the case of PCE Initiated LSP, configured on the PCE. When the operator modifies the configuration of this LSP, that is a change in desired state. The actual state has not yet changed, so LSP-DB is not modified yet. The LSP-DB is only modified after the PCE sends PCInit/PCUpd message to the PCC and the PCC decides to act on that message. When the PCC acts on a message from a PCE, it would update its own PCC LSP DB and send a PCRpt to the PCE(s) to synchronize the change. When the PCE receives the PCRpt msg, it updates its own PCE LSP DB. After this, the PCC LSP-DB and PCE LSP-DB are in sync.¶
Below we give an example of doing MBB to switch the Tunnel from one path to another. We represent the path encoded into the ERO object 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).¶
+---------------------------------------------------------------+
| TUNNEL | LSP |
+-----------------+---------------------------------------------+
| PLSP-ID=100 | LSP-ID=2, ERO={A}, OPER=UP |
+---------------------------------------------------------------+
Figure 1: Content of LSP DB
¶
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 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).¶
+---------------------------------------------------------------+
| TUNNEL | LSP |
+-----------------+---------------------------------------------+
| PLSP-ID=100 | LSP-ID=2, ERO={A}, OPER=UP |
| | LSP-ID=3, ERO={B}, OPER=UP |
+---------------------------------------------------------------+
Figure 2: Content of LSP DB
¶
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).¶
+---------------------------------------------------------------+
| TUNNEL | LSP |
+-----------------+---------------------------------------------+
| PLSP-ID=100 | LSP-ID=3, ERO={B}, OPER=UP |
+---------------------------------------------------------------+
Figure 3: Content of LSP DB
¶
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).¶
+---------------------------------------------------------------+
| TUNNEL | LSP |
+-----------------+---------------------------------------------+
| PLSP-ID=100 | LSP-ID=2, OPER=UP |
+---------------------------------------------------------------+
Figure 4: Content of LSP DB
¶
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).¶
+---------------------------------------------------------------+
| TUNNEL | LSP |
+-----------------+---------------------------------------------+
| PLSP-ID=100 | LSP-ID=2, OPER=UP |
| | LSP-ID=3, OPER=DOWN |
+---------------------------------------------------------------+
Figure 5: Content of LSP DB
¶
MBB procedure is aborted. PCC sends PCRpt(R-FLAG=1, PLSP-ID=100, LSP-ID=3).¶
+---------------------------------------------------------------+
| TUNNEL | LSP |
+-----------------+---------------------------------------------+
| PLSP-ID=100 | LSP-ID=2, OPER=UP |
+---------------------------------------------------------------+
Figure 6: Content of LSP DB
¶
PCEP Association is a group of zero or more LSPs.¶
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. The Association parameters contain many fields, so for convenience we will group all the fields into a single value. We will use ASSO_PARAM=A, ASSO_PARAM=B, to refer to different PCEP Associations: A and B, respectively.¶
Below, we give an example to illustrate 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).¶
+---------------------------------------------------------------+
| ASSO | LSP |
+-----------------+---------------------------------------------+
| ASSO_PARAM=A | PLSP-ID=100, LSP-ID=1 |
+---------------------------------------------------------------+
Figure 7: Content of PCE ASSO DB
¶
PCC creates the second LSP. PCC sends PCRpt(R-FLAG=0, PLSP-ID=200, LSP-ID=1, ASSO_PARAM=A, ASSO_R_FLAG=0).¶
+---------------------------------------------------------------+
| ASSO | LSP |
+-----------------+---------------------------------------------+
| ASSO_PARAM=A | PLSP-ID=100, LSP-ID=1 |
| | PLSP-ID=200, LSP-ID=1 |
+---------------------------------------------------------------+
Figure 8: Content of PCE ASSO DB
¶
PCC updates the first LSP, the PCC is NOT REQUIRED 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 [RFC8697] are to be followed.¶
+---------------------------------------------------------------+
| ASSO | LSP |
+-----------------+---------------------------------------------+
| ASSO_PARAM=A | PLSP-ID=100, LSP-ID=1 |
| | PLSP-ID=200, LSP-ID=1 |
+---------------------------------------------------------------+
Figure 9: Content of PCE ASSO DB
¶
PCC decides to delete the second LSP. PCC sends PCRpt(R-FLAG=1, PLSP-ID=200, LSP-ID=1).¶
+---------------------------------------------------------------+
| ASSO | LSP |
+-----------------+---------------------------------------------+
| ASSO_PARAM=A | PLSP-ID=100, LSP-ID=1 |
+---------------------------------------------------------------+
Figure 10: Content of PCE ASSO DB
¶
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.¶
+---------------------------------------------------------------+
| ASSO | LSP |
+-----------------+---------------------------------------------+
| ASSO_PARAM=A | |
+---------------------------------------------------------------+
Figure 11: Content of PCE ASSO DB
¶
Below, we give an example to illustrate 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).¶
+---------------------------------------------------------------+
| ASSO | LSP |
+-----------------+---------------------------------------------+
| ASSO_PARAM=A | PLSP-ID=100, LSP-ID=1 |
+---------------------------------------------------------------+
Figure 12: Content of PCE ASSO DB
¶
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).¶
+---------------------------------------------------------------+
| ASSO | LSP |
+-----------------+---------------------------------------------+
| ASSO_PARAM=A | PLSP-ID=100, LSP-ID=1 |
+---------------------------------------------------------------+
| ASSO_PARAM=B | PLSP-ID=100, LSP-ID=2 |
+---------------------------------------------------------------+
Figure 13: Content of PCE ASSO DB
¶
PCC deletes the old LSP. PCC sends PCRpt(R-FLAG=1, PLSP-ID=100, LSP- ID=1).¶
+---------------------------------------------------------------+
| ASSO | LSP |
+-----------------+---------------------------------------------+
| ASSO_PARAM=B | PLSP-ID=100, LSP-ID=2 |
+---------------------------------------------------------------+
Figure 14: Content of PCE ASSO DB
¶
For any PCEP object that does not have an explicit removal flag, the absence of that object indicates removal of the constraint specified by that object. For example, suppose the first state-report contains an LSPA object with some affinity constraints. Then if a subsequent state-report 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.¶
None at this time.¶
None at this time.¶
None at this time.¶
The authors would like to thank Adrian Farrel for useful review comments.¶
Dhruv Dhody Huawei Technologies Email: dhruv.ietf@gmail.com Samuel Sidor Cisco Systems Email: ssidor@cisco.com Mahendra Singh Negi RtBrick Inc Email: mahend.ietf@gmail.com¶