RFC 8751
Hierarchical Stateful Path Computation Element (PCE)
📜 RFC 8751: Hierarchical Stateful Path Computation Element (PCE) 🦋
okay bestie, this is the title block and it's giving very official, very academic 💅. Here's the tea: it's an Informational doc (so NOT a Standards Track spec, no cap 🙈), published by the IETF in March 2020, with the ISSN 2070-1721. It's written by a squad of five: D. Dhody (Huawei Technologies), Y. Lee (Samsung Electronics), D. Ceccarelli (Ericsson), J. Shin (SK Telecom), and D. King (Lancaster University). 🫶 The title block doesn't list anything it obsoletes or updates, so this RFC doesn't replace or patch any earlier ones. Iconic self-contained energy ✨.
Abstract
okay so the abstract is literally the TL;DR 🍓. A stateful PCE keeps track of what's going on in the network. It knows about the network state it hears from its PCCs (Path Computation Clients), like the LSPs that already exist, the resources that are reserved, and the path requests that are still pending 👀. All that info gets used when it computes a path for a brand-new traffic-engineered LSP, or for any LSPs that are linked to it. The PCE's answer helps the PCC set up the computed LSP smoothly 🧚.
Then there's the Hierarchical PCE (H-PCE) architecture, which picks the best sequence of interconnected domains and applies network policy if it's relevant, all thanks to a parent-child relationship between PCEs 👑.
The main idea of the doc is that stateful PCE + hierarchical PCE is a power couple 💖. It talks about general considerations and use cases for deploying stateful PCEs (and NOT stateless ones 💀) inside the hierarchical PCE architecture.
Status of This Memo
this section is the legal-ish bit, but here's the gist 🌸. This document is not a Standards Track spec. It's published just for information. It is an IETF product that reflects IETF community consensus, got public review, and was approved by the IESG. Not every IESG-approved doc is up for any level of Internet Standard, so check Section 2 of RFC 7841 if you want the details 🔥. For current status, errata, or to send feedback, head to https://www.rfc-editor.org/info/rfc8751 🦋.
Copyright Notice
okay copyright time 💅. It's Copyright (c) 2020 IETF Trust and the persons identified as the document authors, all rights reserved. The doc is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info), as of the publication date. Read those carefully, bestie, because they spell out your rights and restrictions 📜. Any Code Components pulled from this doc must include the Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions, and they come with no warranty, as the Simplified BSD License says 🎀.
Table of Contents
Here's the whole map of the doc 🗺️✨:
1. Introduction
1.1. Background
1.2. Use Cases and Applicability of Hierarchical Stateful PCE
1.2.1. Applicability to ACTN
1.2.2. End-to-End Contiguous LSP
1.2.3. Applicability of a Stateful P-PCE
2. Terminology
2.1. Requirements Language
3. Hierarchical Stateful PCE
3.1. Passive Operations
3.2. Active Operations
3.3. PCE Initiation of LSPs
3.3.1. Per-Domain Stitched LSP
4. Security Considerations
5. Manageability Considerations
5.1. Control of Function and Policy
5.2. Information and Data Models
5.3. Liveness Detection and Monitoring
5.4. Verification of Correct Operations
5.5. Requirements on Other Protocols
5.6. Impact on Network Operations
5.7. Error Handling between PCEs
6. Other Considerations
6.1. Applicability to Interlayer Traffic Engineering
6.2. Scalability Considerations
6.3. Confidentiality
7. IANA Considerations
8. References
8.1. Normative References
8.2. Informative References
Acknowledgments
Contributors
Authors' Addresses1. Introduction 🌈
1.1. Background
okay so the Path Computation Element communication Protocol (PCEP) [RFC5440] gives PCEs a way to do path computations whenever Path Computation Clients (PCCs) ask for them 💖.
A stateful PCE can look at more than just the network state in terms of links and nodes (that's the Traffic Engineering Database, or TED). It also checks the status of active services, meaning previously computed paths and currently reserved resources stored in the Label Switched Paths Database (LSPDB) 👀.
[RFC8051] covers general considerations for a stateful PCE deployment. It also looks at how useful it is, plus its challenges and limits, through a bunch of use cases 🧚.
[RFC8231] describes a set of PCEP extensions that give you stateful control 💅. For its computations, a stateful PCE gets info from the network's Interior Gateway Protocol (IGP), and also from the set of active paths and their reserved resources. That extra state lets the PCE compute constrained paths while thinking about individual LSPs and how they interact 🔥. [RFC8281] describes how PCE-initiated LSPs are set up, maintained, and torn down in the stateful PCE model ✨.
[RFC8231] also describes the active stateful PCE. An active PCE can reroute an existing LSP, change the attributes of an existing LSP, or delegate control of specific LSPs to a new PCE 🦋.
Computing constrained paths for Traffic Engineering (TE) LSPs across multiple domains in Multiprotocol Label Switching (MPLS) and Generalized MPLS (GMPLS) networks is a major reason PCE was developed in the first place 👑. [RFC6805] describes a Hierarchical PCE (H-PCE) architecture for computing end-to-end paths for interdomain MPLS TE and GMPLS LSPs 🌸. In that architecture, the Parent PCE (P-PCE) computes a multidomain path using the domain connectivity info. A Child PCE (C-PCE) can be in charge of one domain or several 🧚. The C-PCE computes the intradomain path using its own domain topology info 💜.
This doc gives general considerations for stateful PCEs (NOT stateless ones 🙈) 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 networks that use the H-PCE architecture 💅.
In this document, Sections 3.1 and 3.2 focus on end-to-end (E2E) interdomain TE LSPs. Section 3.3.1 covers the operations for stitching per-domain LSPs 🎀.
1.2. Use Cases and Applicability of Hierarchical Stateful PCE
okay so per [RFC6805], in the hierarchical PCE architecture, a P-PCE keeps a domain topology map with the child domains and how they connect 🗺️. Usually the P-PCE doesn't know what's inside the child domains 🙈. BUT, if PCE is applied to the Abstraction and Control of TE Networks (ACTN) [RFC8453] as described in [RFC8637], the Provisioning Network Controller (PNC) can hand an abstract topology up to the Multi-Domain Service Coordinator (MDSC) 💖. So the P-PCE in the MDSC could know way more detail about the topology than just the domain map 🔥.
In a PCEP session between a PCC (ingress) and a C-PCE, the C-PCE acts the way stateful PCE operations are described in [RFC8231] and [RFC8281] 💅. That same C-PCE acts as a PCC on its PCEP session with the P-PCE 🦋. The P-PCE is stateful, so it keeps track of the state of the interdomain LSPs reported to it ✨. The C-PCE can also delegate an interdomain LSP to the P-PCE, so the P-PCE can update the interdomain path 🧚. The trigger for that update could be a state change reported for this LSP or for any other LSP 👀. It could also be a topology change at the P-PCE, like an interdomain link changing status 🌈. With stateful H-PCE in ACTN, a change in the abstract topology the P-PCE learned about can trigger an update too 👑. External factors, like a measurement probe, can also trigger it at the P-PCE 💜. Any such update would need an interdomain path recomputation, as described in [RFC6805] 🔥.
The end-to-end interdomain path computation and setup is described in [RFC6805] 🌸. On top of that, a per-domain stitched-LSP model also works in a P-PCE initiation model 🎀. Sections 3.1, 3.2, and 3.3 describe end-to-end contiguous LSP setup, and Section 3.3.1 describes per-domain stitching 💖.
1.2.1. Applicability to ACTN
[RFC8453] describes the ACTN framework, where each Provisioning Network Controller (PNC) is basically a C-PCE, and the P-PCE is the Multi-Domain Service Coordinator (MDSC) 👑. The per-domain stitched LSP fits ACTN deployments really well, per the hierarchical PCE architecture in Section 3.3.1 of this document and Section 4.1 of [RFC8453] ✨.
[RFC8637] looks at how PCE applies to the ACTN framework 🦋. To support multidomain coordination through hierarchy, the hierarchy of stateful PCEs is a crucial piece 💅.
In the ACTN framework, a Customer Network Controller (CNC) can ask the MDSC to check whether it's possible to meet Virtual Network (VN) requirements before it asks for the VN to be provisioned 🧚. The H-PCE architecture in [RFC6805] can support this using Path Computation Request and Reply (PCReq and PCRep) messages between the P-PCE and C-PCEs 🌸. When the CNC requests VN provisioning, the MDSC breaks that request into multiple interdomain LSP provisioning requests, which might be broken down further into per-domain path segments 🔥. That's covered in Section 3.3.1 💜. The MDSC uses the LSP initiate request (PCInitiate) message from the P-PCE toward the C-PCE, and the C-PCE reports the state back to the P-PCE with a Path Computation State Report (PCRpt) message 👀. The P-PCE can make changes to the LSP with a Path Computation Update Request (PCUpd) message 🎀.
In this case, the P-PCE (acting as MDSC) works with multiple C-PCEs (acting as PNCs) along the interdomain path of the LSP 🫶.
Part 1 of 5. More parts coming, so stay tuned, bestie 💖✨
1.2.2. End-to-End Contiguous LSP
Okay so, different signaling options for interdomain RSVP-TE are all lined up in [RFC4726] 🦋 Contiguous LSPs get built using the procedures from [RFC3209] and [RFC3473] to make one single end-to-end LSP that spans all the domains 🌸 And [RFC6805] explains the technique for finding the optimum path when you don't know the sequence of domains ahead of time 💅
That document shows how the PCE architecture can be extended so the optimum sequence of domains gets picked and the optimum end-to-end path can be derived ✨
Now here's the bestie part 🫶 A stateful P-PCE has to know about the interdomain LSPs for it to actually consider them during path computation. Like, when a domain-diverse path is needed from another LSP, the P-PCE needs to be aware of that LSP. This is the passive stateful P-PCE, which is described in Section 3.1 💜 The interdomain LSP can also be delegated to the P-PCE, so the P-PCE can trigger an update with a PCUpd message 🔥 That update could get triggered when a PCRpt message comes in showing a status change for this LSP or some other LSP. The other LSP could be an associated one (like a protection LSP [RFC8745]) or an unrelated LSP whose resource change leads to reoptimization at the P-PCE 🧚 This is the active stateful operation, described in Section 3.2 ⭐
And it gets even wilder: the P-PCE could be told 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, and that C-PCE 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 🎀 Using stateful operations for an interdomain LSP between the transit/egress domain C-PCEs and the P-PCE is out of scope for this document 🙈
1.2.3. Applicability of a Stateful P-PCE
Okay, so [RFC8051] covers the general considerations for a stateful PCE deployment 🌸 It looks at its applicability and benefits, plus its challenges and limitations, through a bunch of use cases 💅 All of that also applies to the stateful P-PCE when it's used for interdomain LSP path computation and setup ✨ Worth noting: even though the stateful P-PCE has limited direct visibility inside the child domain, it can 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 the P-PCE can make changes to it 🫶 Note that if the C-PCE becomes aware of a topology change that's hidden from the P-PCE, it can take the delegation back from the P-PCE and act on it itself 👑 Similarly, a P-PCE can also request delegation if it needs to make a change to the LSP (refer to [RFC8741]) 💖
- Terminology
The terminology is as per [RFC4655], [RFC5440], [RFC6805], [RFC8051], [RFC8231], and [RFC8281] 📚
Some key terms, listed below for easy reference 🎀
ACTN: Abstraction and Control of Traffic Engineering Networks
CNC: Customer Network Controller
C-PCE: Child Path Computation Element
H-PCE: Hierarchical Path Computation Element
IGP: Interior Gateway Protocol
LSP: Label Switched Path
LSPDB: Label Switched Path Database
LSR: Label Switching Router
MDSC: Multi-Domain Service Coordinator
PCC: Path Computation Client
PCE: Path Computation Element
PCEP: Path Computation Element communication Protocol
PNC: Provisioning Network Controller
P-PCE: Parent Path Computation Element
TED: Traffic Engineering Database
VN: Virtual Network2.1. 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 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here 🌈
3. Hierarchical Stateful PCE ✨
As described in [RFC6805], in the hierarchical PCE architecture, a P-PCE maintains a domain topology map 🗺️ That map contains the child domains (seen as vertices in the topology) and their interconnections (links in the topology) 🦋 Usually, the P-PCE has no information about what's inside the child domains 🙈 Each child domain has at least one PCE capable of computing paths across the domain 💅 These PCEs are known as Child PCEs (C-PCEs) [RFC6805], and they have a direct relationship with the P-PCE 🫶 The P-PCE builds the domain topology map either via direct configuration or from learned information received from each C-PCE 🎀 The network policy could be applied while building the domain topology map 👑 This has been described in detail in [RFC6805] 💜
Note that, in the scope of this document, both the C-PCEs and the P-PCE are stateful in nature 🔥
[RFC8231] specifies new functions to support a stateful PCE 🌸 It also specifies that a function can be initiated either from a PCC towards a PCE (C-E) or from a PCE towards a PCC (E-C) ⭐
This document extends these functions to support the H-PCE Architecture, from a C-PCE towards P-PCE (EC-EP) or from a P-PCE towards C-PCE (EP-EC) 🧚 All PCE types herein (EC-EP and EP-EC) are assumed to be "stateful PCE" 💖
A number of interactions are expected in the hierarchical stateful PCE architecture. These include:
LSP State Report (EC-EP): A child stateful PCE sends an LSP state report to a parent stateful PCE to indicate the state of an LSP 📣
LSP State Synchronization (EC-EP): After the session between the child and parent stateful PCEs is initialized, the P-PCE must learn the state of the C-PCE's TE LSPs 🌈
LSP Control Delegation (EC-EP, EP-EC): A C-PCE grants to the P-PCE the right to update LSP attributes on one or more LSPs. At any time, the C-PCE may withdraw the delegation or the P-PCE may give up the delegation 🦋
LSP Update Request (EP-EC): A stateful P-PCE requests modification of attributes on a C-PCE's TE LSP 🎀
PCE LSP Initiation Request (EP-EC): A stateful P-PCE requests a C-PCE to initiate a TE LSP ✨
Note that this hierarchy is recursive, so a Label Switching Router (LSR), as a PCC, could delegate control to a PCE 🫶 That PCE may, in turn, delegate to its parent, which may further delegate to its parent (if it exists) 👑 Similarly, update operations can also be applied recursively 💅
[RFC8685] defines the H-PCE-CAPABILITY TLV that is used in the Open message to advertise the H-PCE capability 🌸 [RFC8231] defines the STATEFUL-PCE-CAPABILITY TLV used in the Open message to indicate stateful support 💜 To indicate support for the stateful H-PCE operations described in this document, a PCEP speaker MUST include both TLVs in an Open message 🔥 It is RECOMMENDED that any implementation that supports stateful operations [RFC8231] and H-PCE [RFC8685] also implement the stateful H-PCE operations as described in this document 🙌
Further consideration may be made for optional procedures for stateful communication coordination between PCEs, including procedures to minimize computational loops 🧠 The procedures described in [PCE-STATE-SYNC] facilitate stateful communication between PCEs for various use cases 🌟 The procedures and extensions as described in Section 3 of [PCE-STATE-SYNC] are also applicable to child and parent PCE communication 🦋 The SPEAKER-IDENTITY-ID TLV (defined in [RFC8232]) is included in the LSP object to identify the ingress (PCC) 🎀 The PCEP-specific identifier for the LSP (PLSP-ID [RFC8231]) used in the forwarded PCRpt by the C-PCE to the P-PCE is the same as the original one used by the PCC 💖
3.1. Passive Operations ✨
Okay so passive is giving "the PCE just watches and reports" energy, but the path-finding part is still a whole production 🎬. [RFC6805] procedures apply here: the ingress PCC triggers a path computation request for the destination and sends it to the C-PCE in the domain where the LSP originates. That C-PCE forwards it to the P-PCE 🧚. The P-PCE picks a set of candidate domain paths based on the domain topology and the state of the interdomain links. Then it sends computation requests to the C-PCEs responsible for each domain on those candidate paths. Each C-PCE works out a set of candidate path segments across its own domain and sends the results back to the P-PCE. The P-PCE uses all of that to pick path segments and stitch them together into the optimal end-to-end interdomain path 👑. That end-to-end path goes to the C-PCE that got the original request, and that C-PCE passes it along to the PCC that asked in the first place 💌.
As per [RFC8231], the PCC sends an LSP State Report carried in a PCRpt message to the C-PCE, telling it the LSP's status 📊. The C-PCE may further propagate the State Report to the P-PCE. A local policy at the C-PCE may dictate which LSPs get reported to the P-PCE. The PCRpt message goes from C-PCE to P-PCE.
State synchronization mechanisms as described in [RFC8231] and [RFC8232] apply to a PCEP session between C-PCE and P-PCE too 🫶.
We use the hierarchical domain topology example from [RFC6805] as the reference topology for the entire document. It's shown in Figure 1 🗺️.
-----------------------------------------------------------------
| Domain 5 |
| ----- |
| |PCE 5| |
| ----- |
| |
| ---------------- ---------------- ---------------- |
| | Domain 1 | | Domain 2 | | Domain 3 | |
| | | | | | | |
| | ----- | | ----- | | ----- | |
| | |PCE 1| | | |PCE 2| | | |PCE 3| | |
| | ----- | | ----- | | ----- | |
| | | | | | | |
| | ----| |---- ----| |---- | |
| | |BN11+---+BN21| |BN23+---+BN31| | |
| | - ----| |---- ----| |---- - | |
| | |S| | | | | |D| | |
| | - ----| |---- ----| |---- - | |
| | |BN12+---+BN22| |BN24+---+BN32| | |
| | ----| |---- ----| |---- | |
| | | | | | | |
| | ---- | | | | ---- | |
| | |BN13| | | | | |BN33| | |
| -----------+---- ---------------- ----+----------- |
| \ / |
| \ ---------------- / |
| \ | | / |
| \ |---- ----| / |
| ----+BN41| |BN42+---- |
| |---- ----| |
| | | |
| | ----- | |
| | |PCE 4| | |
| | ----- | |
| | | |
| | Domain 4 | |
| ---------------- |
| |
----------------------------------------------------------------- Figure 1: Hierarchical Domain Topology ExampleSteps 1 to 11 are exactly as described in Section 4.6.2 of [RFC6805] ("Hierarchical PCE End-to-End Path Computation Procedure"). The following additional steps are added for stateful PCE and are executed at the end:
(A) The ingress LSR initiates the setup of the LSP as per the path and reports the LSP status to PCE1 ("GOING-UP").
(B) PCE1 further reports the status of the LSP to the P-PCE (PCE5).
(C) The ingress LSR notifies PCE1 of the LSP state when the state is "UP".
(D) PCE1 further reports the status of the LSP to the P-PCE (PCE5).
The ingress LSR could trigger path reoptimization by sending the path computation request as described in [RFC6805]. At this time, it can include the LSP object in the PCReq message, as described in [RFC8231] 🔁.
3.2. Active Operations 💅
[RFC8231] describes the case of an active stateful PCE. The active PCE functionality uses two specific PCEP messages:
- Update Request (PCUpd)
- State Report (PCRpt)
The first one is sent by the PCE to a PCC to modify LSP attributes. The PCC sends back a PCRpt to acknowledge the requested operation or to report any change in the LSP's state 🙌.
As per [RFC8051], delegation is an operation that grants a PCE temporary rights to modify a subset of LSP parameters on the LSPs of one or more PCCs. The C-PCE may further choose to delegate to its P-PCE based on a local policy. The PCRpt message with the "D" (delegate) flag is sent from C-PCE to P-PCE 🤝.
To update an LSP, a PCE sends an LSP Update Request to the PCC using a PCUpd message. For an LSP delegated to a P-PCE via the C-PCE, the P-PCE can use the same PCUpd message to request a change to the C-PCE (the ingress domain PCE). The C-PCE then propagates the update request to the PCC 📨.
The P-PCE uses the same mechanism described in Section 3.1 to compute the end-to-end path, using PCReq and PCRep messages 🧠.
For active operations, the following steps are required when delegating the LSP, again using the reference architecture described in Figure 1 ("Hierarchical Domain Topology Example") 🗺️:
(A) The ingress LSR delegates the LSP to PCE1 via a PCRpt message with the D flag set.
(B) PCE1 further delegates the LSP to the P-PCE (PCE5).
(C) Steps 4 to 10 in Section 4.6.2 of [RFC6805] are executed at P-PCE (PCE5) to determine the end-to-end path.
(D) The P-PCE (PCE5) sends the update request to the C-PCE (PCE1) via a PCUpd message.
(E) PCE1 further updates the LSP to the ingress LSR (PCC).
(F) The ingress LSR initiates the setup of the LSP as per the path and reports the LSP status to PCE1 ("GOING-UP").
(G) PCE1 further reports the status of the LSP to the P-PCE (PCE5).
(H) The ingress LSR notifies PCE1 of the LSP state when the state is "UP".
(I) PCE1 further reports the status of the LSP to the P-PCE (PCE5).
3.3. PCE Initiation of LSPs 🚀
[RFC8281] describes the setup, maintenance, and teardown of PCE-initiated LSPs under the stateful PCE model. This works without any need for local configuration on the PCC, which means a dynamic network that's centrally controlled and deployed 🌈. To instantiate or delete an LSP, the PCE sends the Path Computation LSP Initiate Request (PCInitiate) message to the PCC. In the case of an interdomain LSP in a hierarchical PCE architecture, the initiation operations can be carried out at the P-PCE. When that happens, after the P-PCE finishes the E2E path computation, it can send the PCInitiate message to the C-PCE (the ingress domain PCE), and the C-PCE then propagates the initiate request to the PCC 💖.
The following steps are performed for PCE-initiated operations, again using the reference architecture described in Figure 1 ("Hierarchical Domain Topology Example") 🦋:
(A) The P-PCE (PCE5) is requested to initiate an LSP. Steps 4 to 10 in Section 4.6.2 of [RFC6805] are executed to determine the end-to-end path.
(B) The P-PCE (PCE5) sends the initiate request to the child PCE (PCE1) via a PCInitiate message.
(C) PCE1 further propagates the initiate message to the ingress LSR (PCC).
(D) The ingress LSR initiates the setup of the LSP as per the path and reports to PCE1 the LSP status ("GOING-UP").
(E) PCE1 further reports the status of the LSP to the P-PCE (PCE5).
(F) The ingress LSR notifies PCE1 of the LSP state when the state is "UP".
(G) PCE1 further reports the status of the LSP to the P-PCE (PCE5).
The ingress LSR (PCC) generates the PLSP-ID for the LSP and informs the C-PCE, which then propagates it to the P-PCE 🔥.
3.3.1. Per-Domain Stitched LSP 🧩
okay so the hierarchical PCE setup from [RFC6805] is mainly used for E2E LSPs 💅 but once PCE-initiated capability is in the mix, there's a whole other mode. In this one, the P-PCE gets several intradomain LSPs started in each domain, and then they get stitched together into one E2E LSP 🦋 The P-PCE sends a PCInitiate message to each C-PCE separately so every one of them kicks off its own LSP segment along the domain path. How those per-domain LSPs get stitched together is a whole different mechanism that's out of scope for this doc (go check [STATEFUL-INTERDOMAIN] if you want the tea ☕).
Here's the play-by-play for the per-domain stitched LSP, still using the reference architecture from Figure 1 ("Hierarchical Domain Topology Example") 🌸
- (A) The P-PCE (PCE5) gets asked to initiate an LSP. Steps 4 to 10 in Section 4.6.2 of [RFC6805] run to figure out the end-to-end path, which then gets chopped into per-domain LSPs. For example:
S-BN41BN41-BN33BN33-D
ngl the P-PCE is allowed to use other ways of picking those per-domain LSPs too, not just [RFC6805] 🤷♀️
For LSP (BN33-D): 🌷
- (B) The P-PCE (PCE5) sends the initiate request to the child PCE (PCE3) in a
PCInitiatemessage for LSP (BN33-D). - (C) PCE3 passes the initiate message along to BN33.
- (D) BN33 starts setting up the LSP along the path and reports the LSP status to PCE3 as
"GOING-UP"🚀 - (E) PCE3 passes that status along to the P-PCE (PCE5).
- (F) Node BN33 tells PCE3 about the LSP state once it's
"UP"✨ - (G) PCE3 passes that status along to the P-PCE (PCE5).
For LSP (BN41-BN33): 🍓
- (H) The P-PCE (PCE5) sends the initiate request to the child PCE (PCE4) in a
PCInitiatemessage for LSP (BN41-BN33). - (I) PCE4 passes the initiate message along to BN41.
- (J) BN41 starts setting up the LSP along the path and reports the LSP status to PCE4 as
"GOING-UP"🚀 - (K) PCE4 passes that status along to the P-PCE (PCE5).
- (L) Node BN41 tells PCE4 about the LSP state once it's
"UP"✨ - (M) PCE4 passes that status along to the P-PCE (PCE5).
For LSP (S-BN41): 🧚
- (N) The P-PCE (PCE5) sends the initiate request to the child PCE (PCE1) in a
PCInitiatemessage for LSP (S-BN41). - (O) PCE1 passes the initiate message along to node S.
- (P) S starts setting up the LSP along the path and reports the LSP status to PCE1 as
"GOING-UP"🚀 - (Q) PCE1 passes that status along to the P-PCE (PCE5).
- (R) Node S tells PCE1 about the LSP state once it's
"UP"✨ - (S) PCE1 passes that status along to the P-PCE (PCE5).
Plus, one more thing: 💜
- (T) Once the P-PCE gets a report for each per-domain LSP, it should use a suitable stitching mechanism, which is out of scope for this doc. At this point, the P-PCE (PCE5) could also initiate an E2E LSP (S-D) by sending a
PCInitiatemessage to the ingress C-PCE (PCE1).
Also, each per-domain LSP can be set up in parallel 🏃♀️💨 and it's possible to stitch the per-domain LSPs at the same time they're being initiated. That option is defined in [STATEFUL-INTERDOMAIN] 👑
4. Security Considerations 🔐
okay bestie, this part is SERIOUS 😭 The security considerations from [RFC8231], [RFC6805], and [RFC5440] apply to this doc too. As per [RFC6805], the parent PCE is expected to require all child PCEs to use full security (aka the highest security mechanism PCEP has available) whenever they talk to it 🛡️
Any multidomain operation means info is getting exchanged across domain boundaries. That's bound to be a big security and confidentiality risk, especially when the child domains belong to different commercial companies 💀 PCEP lets each PCE keep its domain-path info private using path-keys [RFC5520], and the hierarchical PCE architecture is built specifically so that info about domain topology and capabilities stays as isolated as possible 🫶 The LSP state in the PCRpt message must continue to keep internal domain confidentiality when it's needed.
The security considerations for PCE-initiated LSPs in [RFC8281] also apply from the P-PCE to the C-PCE 🔥
Also, Section 6.3 describes using a path-key [RFC5520] for confidentiality between C-PCE and P-PCE 🤫
So, it is RECOMMENDED to secure the PCEP session between the P-PCE and the C-PCE using Transport Layer Security (TLS) [RFC8446] (following the recommendations and best current practices in BCP 195 [RFC7525]) and/or the TCP Authentication Option (TCP-AO) [RFC5925]. The guidance for implementing PCEP with TLS is in [RFC8253] 🔒
⚠️ Heads up, bestie: if you're using TLS, you need to be really careful when you expose X.509 certificate parameters, like subjectAltName:otherName (which is set to the Speaker Entity Identifier [RFC8232] as per [RFC8253]). Make sure they're unique and there's no mismatch, or things get messy 😭
5. Manageability Considerations 🛠️
All the manageability requirements and considerations in [RFC5440], [RFC6805], [RFC8231], and [RFC8281] apply to the stateful H-PCE defined in this doc. On top of that, the requirements and considerations in this section apply too 💖
5.1. Control of Function and Policy
Support for the hierarchical procedure is controlled by the management organization responsible for each child PCE. The parent PCE must only accept path-computation requests from authorized child PCEs. If a parent PCE gets a report from an unauthorized child PCE, the report should be dropped 🚫 All the mechanisms described in [RFC8231] and [RFC8281] keep applying too ✨
5.2. Information and Data Models
An implementation should let the operator view the stateful and H-PCE capabilities advertised by each peer 👀 The ietf-pcep PCEP YANG module is specified in [PCE-PCEP-YANG]. This YANG module will be required to be augmented so it also includes details for stateful H-PCE deployment and operation. The exact model and attributes are out of scope for this document 🍰
5.3. Liveness Detection and Monitoring
The mechanisms in this doc don't imply any new liveness-detection or monitoring requirements beyond the ones already listed in [RFC5440] 💅
5.4. Verification of Correct Operations
The mechanisms in this doc don't imply any new operation-verification requirements beyond the ones already listed in [RFC5440] and [RFC8231] 🎀
5.5. Requirements on Other Protocols
The mechanisms in this doc don't imply any new requirements on other protocols 🌈
5.6. Impact on Network Operations
The mechanisms in [RFC5440] and [RFC8231] also apply to the PCEP extensions defined in this doc 🦋
The stateful H-PCE technique brings the applicability of stateful PCE (described in [RFC8051]) to LSPs that traverse multiple domains 🌍
As described in Section 3, a PCEP speaker includes both the H-PCE-CAPABILITY TLV [RFC8685] and the STATEFUL-PCE-CAPABILITY TLV [RFC8231] to signal support for stateful H-PCE. Note that there's a possibility of a PCEP speaker that doesn't support the stateful H-PCE feature but does support stateful-PCE [RFC8231] and H-PCE [RFC8685]. That speaker will also include both TLVs. In this case, a PCEP peer could falsely assume that the stateful H-PCE feature is supported too 😬 On further PCEP message exchange, the stateful messages won't get propagated any further (as described in this doc), so stateful H-PCE "parent" control of the LSP won't happen. A PCEP peer should be prepared for this as part of normal procedures 🙈
5.7. Error Handling between PCEs
Apart from the basic error handling described in this doc, an implementation could also use the enhanced error and notification mechanism for stateful H-PCE operations described in [PCE-ENHANCED-ERRORS] ⚠️ Enhanced features like error-behavior propagation, notification, and error-criticality level are further defined in [PCE-ENHANCED-ERRORS] 🧠
6. Other Considerations 🌸
6.1. Applicability to Interlayer Traffic Engineering
[RFC5623] describes a framework for applying the PCE-based architecture to interlayer (G)MPLS traffic engineering 🪄 The H-PCE stateful architecture, with a stateful P-PCE coordinating with the stateful C-PCEs of the higher and lower layers, is shown in Figure 2 👇
+----------+
| Parent |
/| PCE |
/ +----------+
/ / Stateful
/ / P-PCE
/ /
/ /
Stateful+-----+ / /
C-PCE | PCE |/ /
Hi | Hi | /
+-----+ /
+---+ +---+ / +---+ +---+
+ LSR +--+ LSR +........................+ LSR +--+ LSR +
+ H1 + + H2 + / + H3 + + H4 +
+---+ +---+\ +-----+/ /+---+ +---+
\ | PCE | /
\ | Lo | /
Stateful \ +-----+ /
C-PCE \ /
Lo \+---+ +---+/
+ LSR +--+ LSR +
+ L1 + + L2 +
+---+ +---+
Figure 2: Sample Interlayer TopologyAll the procedures described in Section 3 also apply to interlayer path setup, and therefore to separate domains 🥰
6.2. Scalability Considerations
It's worth noting that if all the C-PCEs reported all the LSPs in their domain, it could lead to scalability issues for the P-PCE 📈 So, it is recommended to only report the LSPs that are involved in H-PCE, i.e., the LSPs that are either delegated to the P-PCE or initiated by the P-PCE 💜 Scalability considerations for PCEP as per [RFC8231] keep applying to the PCEP session between the child and parent PCE.
6.3. Confidentiality
As described in Section 4.2 of [RFC6805], info about the content of child domains isn't shared, for both scaling and confidentiality reasons 🤐 The child PCE can also hide the path info during path computation. A C-PCE may replace a path segment with a path-key [RFC5520], which effectively hides the content of that segment of the path 🦋
7. IANA Considerations 📋
This document has no IANA actions ✨
8. References 📚
8.1. Normative References ✨
okay bestie, these are the must-reads 📚 the stuff the spec leans on hard, with every detail kept so nothing gets lost 🫶
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/info/rfc2119>.
[RFC4655] Farrel, A., Vasseur, J.-P., and J. Ash, "A Path
Computation Element (PCE)-Based Architecture", RFC 4655,
DOI 10.17487/RFC4655, August 2006,
<https://www.rfc-editor.org/info/rfc4655>.
[RFC5440] Vasseur, JP., Ed. and JL. Le Roux, Ed., "Path Computation
Element (PCE) Communication Protocol (PCEP)", RFC 5440,
DOI 10.17487/RFC5440, March 2009,
<https://www.rfc-editor.org/info/rfc5440>.
[RFC5520] Bradford, R., Ed., Vasseur, JP., and A. Farrel,
"Preserving Topology Confidentiality in Inter-Domain Path
Computation Using a Path-Key-Based Mechanism", RFC 5520,
DOI 10.17487/RFC5520, April 2009,
<https://www.rfc-editor.org/info/rfc5520>.
[RFC5925] Touch, J., Mankin, A., and R. Bonica, "The TCP
Authentication Option", RFC 5925, DOI 10.17487/RFC5925,
June 2010, <https://www.rfc-editor.org/info/rfc5925>.
[RFC6805] King, D., Ed. and A. Farrel, Ed., "The Application of the
Path Computation Element Architecture to the Determination
of a Sequence of Domains in MPLS and GMPLS", RFC 6805,
DOI 10.17487/RFC6805, November 2012,
<https://www.rfc-editor.org/info/rfc6805>.
[RFC7525] Sheffer, Y., Holz, R., and P. Saint-Andre,
"Recommendations for Secure Use of Transport Layer
Security (TLS) and Datagram Transport Layer Security
(DTLS)", BCP 195, RFC 7525, DOI 10.17487/RFC7525, May
2015, <https://www.rfc-editor.org/info/rfc7525>.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
May 2017, <https://www.rfc-editor.org/info/rfc8174>.
[RFC8231] Crabbe, E., Minei, I., Medved, J., and R. Varga, "Path
Computation Element Communication Protocol (PCEP)
Extensions for Stateful PCE", RFC 8231,
DOI 10.17487/RFC8231, September 2017,
<https://www.rfc-editor.org/info/rfc8231>.
[RFC8253] Lopez, D., Gonzalez de Dios, O., Wu, Q., and D. Dhody,
"PCEPS: Usage of TLS to Provide a Secure Transport for the
Path Computation Element Communication Protocol (PCEP)",
RFC 8253, DOI 10.17487/RFC8253, October 2017,
<https://www.rfc-editor.org/info/rfc8253>.
[RFC8281] Crabbe, E., Minei, I., Sivabalan, S., and R. Varga, "Path
Computation Element Communication Protocol (PCEP)
Extensions for PCE-Initiated LSP Setup in a Stateful PCE
Model", RFC 8281, DOI 10.17487/RFC8281, December 2017,
<https://www.rfc-editor.org/info/rfc8281>.
[RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol
Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018,
<https://www.rfc-editor.org/info/rfc8446>.8.2. Informative References ✨
these ones are the extra reading 🧠 super useful for the full picture, all details intact 💅
[RFC3209] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V.,
and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP
Tunnels", RFC 3209, DOI 10.17487/RFC3209, December 2001,
<https://www.rfc-editor.org/info/rfc3209>.
[RFC3473] Berger, L., Ed., "Generalized Multi-Protocol Label
Switching (GMPLS) Signaling Resource ReserVation Protocol-
Traffic Engineering (RSVP-TE) Extensions", RFC 3473,
DOI 10.17487/RFC3473, January 2003,
<https://www.rfc-editor.org/info/rfc3473>.
[RFC4726] Farrel, A., Vasseur, J.-P., and A. Ayyangar, "A Framework
for Inter-Domain Multiprotocol Label Switching Traffic
Engineering", RFC 4726, DOI 10.17487/RFC4726, November
2006, <https://www.rfc-editor.org/info/rfc4726>.
[RFC5623] Oki, E., Takeda, T., Le Roux, JL., and A. Farrel,
"Framework for PCE-Based Inter-Layer MPLS and GMPLS
Traffic Engineering", RFC 5623, DOI 10.17487/RFC5623,
September 2009, <https://www.rfc-editor.org/info/rfc5623>.
[RFC8051] Zhang, X., Ed. and I. Minei, Ed., "Applicability of a
Stateful Path Computation Element (PCE)", RFC 8051,
DOI 10.17487/RFC8051, January 2017,
<https://www.rfc-editor.org/info/rfc8051>.
[RFC8232] Crabbe, E., Minei, I., Medved, J., Varga, R., Zhang, X.,
and D. Dhody, "Optimizations of Label Switched Path State
Synchronization Procedures for a Stateful PCE", RFC 8232,
DOI 10.17487/RFC8232, September 2017,
<https://www.rfc-editor.org/info/rfc8232>.
[RFC8453] Ceccarelli, D., Ed. and Y. Lee, Ed., "Framework for
Abstraction and Control of TE Networks (ACTN)", RFC 8453,
DOI 10.17487/RFC8453, August 2018,
<https://www.rfc-editor.org/info/rfc8453>.
[RFC8637] Dhody, D., Lee, Y., and D. Ceccarelli, "Applicability of
the Path Computation Element (PCE) to the Abstraction and
Control of TE Networks (ACTN)", RFC 8637,
DOI 10.17487/RFC8637, July 2019,
<https://www.rfc-editor.org/info/rfc8637>.
[RFC8685] Zhang, F., Zhao, Q., Gonzalez de Dios, O., Casellas, R.,
and D. King, "Path Computation Element Communication
Protocol (PCEP) Extensions for the Hierarchical Path
Computation Element (H-PCE) Architecture", RFC 8685,
DOI 10.17487/RFC8685, December 2019,
<https://www.rfc-editor.org/info/rfc8685>.
[RFC8741] Raghuram, A., Goddard, A., Karthik, J., Sivabalan, S., and
M. Negi, "Ability for a Stateful Path Computation Element
(PCE) to Request and Obtain Control of a Label Switched
Path (LSP)", RFC 8741, DOI 10.17487/RFC8741, March 2020,
<https://www.rfc-editor.org/info/rfc8741>.
[RFC8745] Ananthakrishnan, H., Sivabalan, S., Barth, C., Minei, I.,
and M. Negi, "Path Computation Element Communication
Protocol (PCEP) Extensions for Associating Working and
Protection Label Switched Paths (LSPs) with Stateful PCE",
RFC 8745, DOI 10.17487/RFC8745, March 2020,
<https://www.rfc-editor.org/info/rfc8745>.
[PCE-ENHANCED-ERRORS]
Poullyau, H., Theillaud, R., Meuric, J., Zheng, H., and X.
Zhang, "Extensions to the Path Computation Element
Communication Protocol for Enhanced Errors and
Notifications", Work in Progress, Internet-Draft, draft-
ietf-pce-enhanced-errors-06, 14 August 2019,
<https://tools.ietf.org/html/draft-ietf-pce-enhanced-
errors-06>.
[PCE-PCEP-YANG]
Dhody, D., Hardwick, J., Beeram, V., and J. Tantsura, "A
YANG Data Model for Path Computation Element
Communications Protocol (PCEP)", Work in Progress,
Internet-Draft, draft-ietf-pce-pcep-yang-13, 31 October
2019,
<https://tools.ietf.org/html/draft-ietf-pce-pcep-yang-13>.
[PCE-STATE-SYNC]
Litkowski, S., Sivabalan, S., Li, C., and H. Zheng, "Inter
Stateful Path Computation Element (PCE) Communication
Procedures.", Work in Progress, Internet-Draft, draft-
litkowski-pce-state-sync-07, 11 January 2020,
<https://tools.ietf.org/html/draft-litkowski-pce-state-
sync-07>.
[STATEFUL-INTERDOMAIN]
Dugeon, O., Meuric, J., Lee, Y., and D. Ceccarelli, "PCEP
Extension for Stateful Inter-Domain Tunnels", Work in
Progress, Internet-Draft, draft-dugeon-pce-stateful-
interdomain-02, 4 March 2019,
<https://tools.ietf.org/html/draft-dugeon-pce-stateful-
interdomain-02>.Acknowledgments 🫶
huge thank yous to Manuela Scarella, Haomian Zheng, Sergio Marmo, Stefano Parodi, Giacomo Agostini, Jeff Tantsura, Rajan Rao, Adrian Farrel, and Haomian Zheng for reviewing and suggesting things 💖 you all literally made this better
thanks also to Tal Mazrahi for the RTGDIR review, Paul Kyzivat for the GENART review, and Stephen Farrell for the SECDIR review 🌸
and a big shoutout to Barry Leiba, Martin Vigoureux, Benjamin Kaduk, and Roman Danyliw for the IESG review 👑
Contributors 🧚
these are the people who helped write the thing, contact info exactly as listed 💅
Avantika
ECI Telecom
India
Email: avantika.srm@gmail.com
Xian Zhang
Huawei Technologies
Bantian, Longgang District
Guangdong
Shenzhen, 518129
China
Email: zhang.xian@huawei.com
Udayasree Palle
Email: udayasreereddy@gmail.com
Oscar Gonzalez de Dios
Telefonica I+D
Don Ramon de la Cruz 82-84
28045 Madrid
Spain
Phone: +34913128832
Email: oscar.gonzalezdedios@telefonica.comAuthors' Addresses 🦋
and these are the authors, where to find them 🎀
Dhruv Dhody
Huawei Technologies
Divyashree Techno Park, Whitefield
Bangalore 560066
Karnataka
India
Email: dhruv.ietf@gmail.com
Young Lee
Samsung Electronics
Email: younglee.tx@gmail.com
Daniele Ceccarelli
Ericsson
Torshamnsgatan, 48
SE- Stockholm
Sweden
Email: daniele.ceccarelli@ericsson.com
Jongyoon Shin
SK Telecom
6 Hwangsaeul-ro, 258 beon-gil
Bundang-gu, Seongnam-si,
Gyeonggi-do
463-784
Republic of Korea
Email: jongyoon.shin@sk.com
Daniel King
Lancaster University
United Kingdom
Email: d.king@lancaster.ac.uk📦 where this page comes from
- ietf: rfc8751 2020-03
- 💖 girlified by claude-haiku-5-5 on : a language model's rewrite of the original, under its terms