The Path Computation Element communication Protocol (PCEP) [RFC 5440
] provides mechanisms for Path Computation Elements (PCEs) to perform path computations in response to the requests of Path Computation Clients (PCCs).
A stateful PCE is capable of considering, for the purposes of path computation, not only the network state in terms of links and nodes (referred to as the Traffic Engineering Database or TED) but also the status of active services (previously computed paths, and currently reserved resources, stored in the Label Switched Paths Database (LSPDB).
] describes general considerations for a stateful PCE deployment; it also examines its applicability and benefits as well as its challenges and limitations through a number of use cases.
] describes a set of extensions to PCEP to provide stateful control. For its computations, a stateful PCE has access to not only the information carried by the network's Interior Gateway Protocol (IGP), but also the set of active paths and their reserved resources. The additional state allows the PCE to compute constrained paths while considering individual LSPs and their interactions. [RFC 8281
] describes the setup, maintenance, and teardown of PCE-initiated LSPs under the stateful PCE model.
] also describes the active stateful PCE. The active PCE functionality allows a PCE to reroute an existing LSP, make changes to the attributes of an existing LSP, or delegate control of specific LSPs to a new PCE.
The ability to compute constrained paths for Traffic Engineering (TE) LSPs in Multiprotocol Label Switching (MPLS) and Generalized MPLS (GMPLS) networks across multiple domains has been identified as a key motivation for PCE development. [RFC 6805
] describes a Hierarchical PCE (H-PCE) architecture that can be used for computing end-to-end paths for interdomain MPLS TE and GMPLS Label Switched Paths (LSPs). Within the H-PCE architecture [RFC 6805
], the Parent PCE (P-PCE) is used to compute a multidomain path based on the domain connectivity information. A Child PCE (C-PCE) may be responsible for a single domain or multiple domains. The C-PCE is used to compute the intradomain path based on its domain topology information.
This document presents general considerations for stateful PCEs, and not stateless PCEs, in the hierarchical PCE architecture. It focuses on the behavior changes and additions to the existing stateful PCE mechanisms (including PCE-initiated LSP setup and active stateful PCE usage) in the context of networks using the H-PCE architecture.
In this document, Sections [3.1
] and [3.2
] focus on end-to-end (E2E) interdomain TE LSP. Section 3.3.1
describes the operations for stitching per-domain LSPs.
As per [RFC 6805
], in the hierarchical PCE architecture, a P-PCE maintains a domain topology map that contains the child domains and their interconnections. Usually, the P-PCE has no information about the content of the child domains. But, if the PCE is applied to the Abstraction and Control of TE Networks (ACTN) [RFC 8453
] as described in [RFC 8637
], the Provisioning Network Controller (PNC) can provide an abstract topology to the Multi-Domain Service Coordinator (MDSC). Thus, the P-PCE in MDSC could be aware of topology information in much more detail than just the domain topology.
In a PCEP session between a PCC (ingress) and a C-PCE, the C-PCE acts as per the stateful PCE operations described in [RFC 8231
] and [RFC 8281
]. The same C-PCE behaves as a PCC on the PCEP session towards the P-PCE. The P-PCE is stateful in nature; thus, it maintains the state of the interdomain LSPs that are reported to it. The interdomain LSP could also be delegated by the C-PCE to the P-PCE, so that the P-PCE could update the interdomain path. The trigger for this update could be the LSP state change reported for this LSP or any other LSP. It could also be a change in topology at the P-PCE, such as interdomain link status change. In case of use of stateful H-PCE in ACTN, a change in abstract topology learned by the P-PCE could also trigger the update. Some other external factors (such as a measurement probe) could also be a trigger at the P-PCE. Any such update would require an interdomain path recomputation as described in [RFC 6805
The end-to-end interdomain path computation and setup is described in [RFC 6805
]. Additionally, a per-domain stitched-LSP model is also applicable in a P-PCE initiation model. Sections [3.1
], and [3.3
] describe the end-to-end contiguous LSP setup, whereas Section 3.3.1
describes the per-domain stitching.
] describes a framework for the Abstraction and Control of TE Networks (ACTN), where each Provisioning Network Controller (PNC) is equivalent to a C-PCE, and the P-PCE is the Multi-Domain Service Coordinator (MDSC). The per-domain stitched LSP is well suited for ACTN deployments, as per the hierarchical PCE architecture described in Section 3.3.1
of this document and Section 4.1
of RFC 8453
] examines the applicability of PCE to the ACTN framework. To support the function of multidomain coordination via hierarchy, the hierarchy of stateful PCEs plays a crucial role.
In the ACTN framework, a Customer Network Controller (CNC) can request the MDSC to check whether there is a possibility to meet Virtual Network (VN) requirements before requesting that the VN be provisioned. The H-PCE architecture as described in [RFC 6805
] can support this function using Path Computation Request and Reply (PCReq and PCRep, respectively) messages between the P-PCE and C-PCEs. When the CNC requests VN provisioning, the MDSC decomposes this request into multiple interdomain LSP provisioning requests, which might be further decomposed into per-domain path segments. This is described in Section 3.3.1
. The MDSC uses the LSP initiate request (PCInitiate) message from the P-PCE towards the C-PCE, and the C-PCE reports the state back to the P-PCE via a Path Computation State Report (PCRpt) message. The P-PCE could make changes to the LSP via the use of a Path Computation Update Request (PCUpd) message.
In this case, the P-PCE (as MDSC) interacts with multiple C-PCEs (as PNCs) along the interdomain path of the LSP.
Different signaling options for interdomain RSVP-TE are identified in [RFC 4726
]. Contiguous LSPs are achieved using the procedures of [RFC 3209
] and [RFC 3473
] to create a single end-to-end LSP that spans all domains. [RFC 6805
] describes the technique for establishing the optimum path when the sequence of domains is not known in advance.
That document shows how the PCE architecture can be extended to allow the optimum sequence of domains to be selected and the optimum end-to-end path to be derived.
A stateful P-PCE has to be aware of the interdomain LSPs for it to consider them during path computation. For instance, when a domain-diverse path is required from another LSP, the P-PCE needs to be aware of the LSP. This is the passive stateful P-PCE, as described in Section 3.1
. Additionally, the interdomain LSP could be delegated to the P-PCE, so that P-PCE could trigger an update via a PCUpd message. The update could be triggered on receipt of the PCRpt message that indicates a status change of this LSP or some other LSP. The other LSP could be an associated LSP (such as a protection LSP [RFC 8745
]) or an unrelated LSP whose resource change leads to reoptimization at the P-PCE. This is the active stateful operation, as described in Section 3.2
. Further, the P-PCE could be instructed to create an interdomain LSP on its own using the PCInitiate message for an E2E contiguous LSP. The P-PCE would send the PCInitiate message to the ingress domain C-PCE, which would further instruct the ingress PCC.
In this document, for the contiguous LSP, the above interactions are only between the ingress domain C-PCE and the P-PCE. The use of stateful operations for an interdomain LSP between the transit/egress domain C-PCEs and the P-PCE is out of the scope of this document.
] describes general considerations for a stateful PCE deployment and examines its applicability and benefits, as well as its challenges and limitations, through a number of use cases. These are also applicable to the stateful P-PCE when used for the interdomain LSP path computation and setup. It should be noted that though the stateful P-PCE has limited direct visibility inside the child domain, it could still trigger reoptimization with the help of child PCEs based on LSP state changes, abstract topology changes, or some other external factors.
The C-PCE would delegate control of the interdomain LSP to the P-PCE so that the P-PCE can make changes to it. Note that, if the C-PCE becomes aware of a topology change that is hidden from the P-PCE, it could take back the delegation from the P-PCE to act on it itself. Similarly, a P-PCE could also request delegation if it needs to make a change to the LSP (refer to [RFC 8741