idnits 2.17.1 draft-ietf-pce-stateful-hpce-12.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (September 03, 2019) is 1696 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- -- Obsolete informational reference (is this intentional?): RFC 7525 (Obsoleted by RFC 9325) == Outdated reference: A later version (-10) exists of draft-litkowski-pce-state-sync-06 == Outdated reference: A later version (-23) exists of draft-ietf-pce-pcep-yang-12 == Outdated reference: A later version (-04) exists of draft-dugeon-pce-stateful-interdomain-02 == Outdated reference: A later version (-11) exists of draft-ietf-pce-lsp-control-request-08 == Outdated reference: A later version (-13) exists of draft-ietf-pce-enhanced-errors-06 Summary: 0 errors (**), 0 flaws (~~), 6 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 PCE Working Group D. Dhody 3 Internet-Draft Huawei Technologies 4 Intended status: Informational Y. Lee 5 Expires: March 06, 2020 Futurewei Technologies 6 D. Ceccarelli 7 Ericsson 8 J. Shin 9 SK Telecom 10 D. King 11 Lancaster University 12 September 03, 2019 14 Hierarchical Stateful Path Computation Element (PCE). 15 draft-ietf-pce-stateful-hpce-12 17 Abstract 19 A Stateful Path Computation Element (PCE) maintains information on 20 the current network state, including: computed Label Switched Path 21 (LSPs), reserved resources within the network, and pending path 22 computation requests. This information may then be considered when 23 computing new traffic engineered LSPs, and for associated and 24 dependent LSPs, received from Path Computation Clients (PCCs). The 25 Path computation response from a PCE is helpful for the PCC to 26 gracefully establish the computed LSP. 28 The Hierarchical Path Computation Element (H-PCE) architecture, 29 provides an architecture to allow the optimum sequence of 30 inter-connected domains to be selected, and network policy to be 31 applied if applicable, via the use of a hierarchical relationship 32 between PCEs. 34 Combining the capabilities of Stateful PCE and the Hierarchical PCE 35 would be advantageous. This document describes general considerations 36 and use cases for the deployment of Stateful, and not Stateless, PCEs 37 using the Hierarchical PCE architecture. 39 Status of This Memo 41 This Internet-Draft is submitted in full conformance with the 42 provisions of BCP 78 and BCP 79. 44 Internet-Drafts are working documents of the Internet Engineering 45 Task Force (IETF). Note that other groups may also distribute 46 working documents as Internet-Drafts. The list of current Internet- 47 Drafts is at https://datatracker.ietf.org/drafts/current/. 48 Internet-Drafts are draft documents valid for a maximum of six months 49 and may be updated, replaced, or obsoleted by other documents at any 50 time. It is inappropriate to use Internet-Drafts as reference 51 material or to cite them other than as "work in progress." 53 This Internet-Draft will expire on December 18, 2019. 55 Copyright Notice 57 Copyright (c) 2019 IETF Trust and the persons identified as the 58 document authors. All rights reserved. 60 This document is subject to BCP 78 and the IETF Trust's Legal 61 Provisions Relating to IETF Documents 62 (https://trustee.ietf.org/license-info) in effect on the date of 63 publication of this document. Please review these documents 64 carefully, as they describe your rights and restrictions with respect 65 to this document. Code Components extracted from this document must 66 include Simplified BSD License text as described in Section 4.e of 67 the Trust Legal Provisions and are provided without warranty as 68 described in the Simplified BSD License. 70 Table of Contents 72 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 73 1.1. Background . . . . . . . . . . . . . . . . . . . . . . . . 3 74 1.2. Use-cases and Applicability of Hierarchical Stateful PCE . 4 75 1.2.1. Applicability to ACTN . . . . . . . . . . . . . . . . 5 76 1.2.2. End-to-End Contiguous LSP . . . . . . . . . . . . . . 5 77 1.2.3. Applicability of a Stateful P-PCE . . . . . . . . . . 6 78 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 6 79 2.1. Requirement Language . . . . . . . . . . . . . . . . . . . 7 80 3. Hierarchical Stateful PCE . . . . . . . . . . . . . . . . . . 7 81 3.1. Passive Operations . . . . . . . . . . . . . . . . . . . . 9 82 3.2. Active Operations . . . . . . . . . . . . . . . . . . . . 11 83 3.3. PCE Initiation of LSPs . . . . . . . . . . . . . . . . . . 12 84 3.3.1. Per Domain Stitched LSP . . . . . . . . . . . . . . . 13 85 4. Security Considerations . . . . . . . . . . . . . . . . . . . 15 86 5. Manageability Considerations . . . . . . . . . . . . . . . . . 16 87 5.1. Control of Function and Policy . . . . . . . . . . . . . . 16 88 5.2. Information and Data Models . . . . . . . . . . . . . . . 16 89 5.3. Liveness Detection and Monitoring . . . . . . . . . . . . 16 90 5.4. Verify Correct Operations . . . . . . . . . . . . . . . . 16 91 5.5. Requirements On Other Protocols . . . . . . . . . . . . . 16 92 5.6. Impact On Network Operations . . . . . . . . . . . . . . . 17 93 5.7. Error Handling between PCEs . . . . . . . . . . . . . . . 17 95 6. Other Considerations . . . . . . . . . . . . . . . . . . . . . 17 96 6.1. Applicability to Inter-Layer Traffic Engineering . . . . . 17 97 6.2. Scalability Considerations . . . . . . . . . . . . . . . . 18 98 6.3. Confidentiality . . . . . . . . . . . . . . . . . . . . . 18 99 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 18 100 8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 18 101 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 18 102 9.1. Normative References . . . . . . . . . . . . . . . . . . . 18 103 9.2. Informative References . . . . . . . . . . . . . . . . . . 19 104 Contributors . . . . . . . . . . . . . . . . . . . . . . . . . . . 21 105 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 22 107 1. Introduction 109 1.1. Background 111 The Path Computation Element communication Protocol (PCEP) [RFC5440] 112 provides mechanisms for Path Computation Elements (PCEs) to perform 113 path computations in response to Path Computation Clients' (PCCs) 114 requests. 116 A stateful PCE is capable of considering, for the purposes of path 117 computation, not only the network state in terms of links and nodes 118 (referred to as the Traffic Engineering Database or TED) but also the 119 status of active services (previously computed paths, and currently 120 reserved resources, stored in the Label Switched Paths Database 121 (LSP-DB). 123 [RFC8051] describes general considerations for a stateful PCE 124 deployment and examines its applicability and benefits, as well as 125 its challenges and limitations through a number of use cases. 127 [RFC8231] describes a set of extensions to PCEP to provide stateful 128 control. A stateful PCE has access to not only the information 129 carried by the network's Interior Gateway Protocol (IGP), but also 130 the set of active paths and their reserved resources for its 131 computations. The additional state allows the PCE to compute 132 constrained paths while considering individual LSPs and their 133 interactions. [RFC8281] describes the setup, maintenance and 134 teardown of PCE-initiated LSPs under the stateful PCE model. 136 [RFC8231] also describes the active stateful PCE. The active PCE 137 functionality allows a PCE to reroute an existing LSP or make changes 138 to the attributes of an existing LSP, or delegate control of specific 139 LSPs to a new PCE. 141 The ability to compute shortest constrained TE LSPs in Multiprotocol 142 Label Switching (MPLS) and Generalized MPLS (GMPLS) networks across 143 multiple domains has been identified as a key motivation for PCE 144 development. [RFC6805] describes a Hierarchical PCE (H-PCE) 145 architecture which can be used for computing end-to-end paths for 146 inter-domain MPLS Traffic Engineering (TE) and GMPLS Label Switched 147 Paths (LSPs). Within the Hierarchical PCE (H-PCE) architecture 148 [RFC6805], the Parent PCE (P-PCE) is used to compute a multi-domain 149 path based on the domain connectivity information. A Child PCE 150 (C-PCE) may be responsible for a single domain or multiple domains, 151 it is used to compute the intra-domain path based on its domain 152 topology information. 154 This document presents general considerations for stateful PCEs, and 155 not Stateless PCEs, in the hierarchical PCE architecture. In 156 particular, the behavior changes and additions to the existing 157 stateful PCE mechanisms (including PCE-initiated LSP setup and active 158 PCE usage) in the context of networks using the H-PCE architecture. 160 In this document, Sections 3.1 and 3.2 focus on end to end (E2E) 161 inter-domain TE LSP. Section 3.3.1 describes the operations for 162 stitching Per Domain LSPs. 164 1.2. Use-cases and Applicability of Hierarchical Stateful PCE 166 As per [RFC6805], in the hierarchical PCE architecture, a P-PCE 167 maintains a domain topology map that contains the child domains and 168 their interconnections. Usually, the P-PCE has no information about 169 the content of the child domains. But if the PCE is applied to the 170 Abstraction and Control of TE Networks (ACTN) [RFC8453] as described 171 in [RFC8637], the Provisioning Network Controller (PNC) can provide 172 an abstract topology to the Multi-Domain Service Coordinator (MDSC). 173 Thus the P-PCE in MDSC could be aware of topology information in much 174 more detail than just the domain topology. 176 In a PCEP session between a PCC (Ingress) and a C-PCE, the C-PCE acts 177 as per the stateful PCE operations described in [RFC8231] and 178 [RFC8281]. The same C-PCE behaves as a PCC on the PCEP session 179 towards the P-PCE. The P-PCE is stateful in nature and thus maintains 180 the state of the inter-domain LSPs that are reported to it. The 181 inter-domain LSP could also be delegated by the C-PCE to the P-PCE, 182 so that the P-PCE could update the inter-domain path. The trigger for 183 this update could be the LSP state change reported for this LSP or 184 any other LSP. It could also be a change in topology at the P-PCE 185 such as inter-domain link status change. In case of use of stateful 186 H-PCE in ACTN, a change in abstract topology learned by the P-PCE 187 could also trigger the update. Some other external factors (such as a 188 measurement probe) could also be a trigger at the P-PCE. Any such 189 update would require an inter-domain path recomputation as described 190 in [RFC6805]. 192 The inter-domain LSP could be set up using the end-to-end signaling 193 as described in [RFC6805]. Additionally a per-domain stitched LSP 194 model is also applicable in a P-PCE initiation model. Section 3.1, 195 Section 3.2, and Section 3.3 describe the end-to-end Contiguous LSP 196 setup, whereas Section 3.3.1 describe the per-domain stitching. 198 1.2.1. Applicability to ACTN 200 [RFC8453] describes a framework for the Abstraction and Control of TE 201 Networks (ACTN), where each Provisioning Network Controller (PNC) is 202 equivalent to a C-PCE, and the P-PCE is the Multi-Domain Service 203 Coordinator (MDSC). The Per Domain stitched LSP as per the 204 Hierarchical PCE architecture described in Section 3.3.1 and Section 205 4.1 is well suited for ACTN deployments. 207 [RFC8637] examines the applicability of PCE to the ACTN framework. To 208 support the function of multi domain coordination via hierarchy, the 209 hierarchy of stateful PCEs play a crucial role. 211 In the ACTN framework, a Customer Network Controller (CNC) can 212 request the MDSC to check whether there is a possibility to meet 213 Virtual Network (VN) requirements before requesting for the VN to be 214 provisioned. The H-PCE architecture as described in [RFC6805] can 215 support this function using PCReq and PCRep messages between the 216 P-PCE and C-PCEs. When the CNC requests for VN provisioning, the MDSC 217 decompose this request into multiple inter-domain LSP provisioning 218 requests, which might be further decomposed to per-domain path 219 segments. This is described in Section 3.3.1. The MDSC uses the LSP 220 Initiate Request (PCInitiate) message from the P-PCE towards the 221 C-PCE, and the C-PCE reports the state back to the P-PCE via a Path 222 Computation State Report (PCRpt) message. The P-PCE could make 223 changes to the LSP via the use of a Path Computation Update Request 224 (PCUpd) message. 226 In this case, the P-PCE (as MDSC) interacts with multiple C-PCEs (as 227 PNCs) along the inter-domain path of the LSP. 229 1.2.2. End-to-End Contiguous LSP 231 Different signaling methods for inter-domain RSVP-TE signaling are 232 identified in [RFC4726]. Contiguous LSPs are achieved using the 233 procedures of [RFC3209] and [RFC3473] to create a single end-to-end 234 LSP that spans all domains. [RFC6805] describes the technique to 235 establish the optimum path when the sequence of domains is not known 236 in advance. It shows how the PCE architecture can be extended to 237 allow the optimum sequence of domains to be selected, and the optimum 238 end-to-end path to be derived. 240 In case of a stateful P-PCE, the stateful P-PCE has to be aware of 241 the inter-domain LSPs for it to consider them during path 242 computation. For example, a domain diverse path from another LSP. 243 This is the Passive Stateful P-PCE as described in Section 3.1. 244 Additionally, the inter-domain LSP could be delegated to the P-PCE, 245 so that P-PCE could trigger an update via a PCUpd message. The update 246 could be triggered on receipt of the PCRpt message that indicates a 247 status change of this LSP or some other LSP. The other LSP could be 248 an associated LSP (such as protection) or an unrelated LSP whose 249 resource change leads to re-optimization at the P-PCE. This is the 250 Active Stateful Operation as described in Section 3.2. Further, the 251 P-PCE could be instructed to create an inter-domain LSP on its own 252 using the PCInitiate message for an E2E contiguous LSP. The P-PCE 253 would send the PCInitiate message to the Ingress domain C-PCE, which 254 would further instruct the Ingress PCC. 256 In this document, for the Contiguous LSP, the above interactions are 257 only between the ingress domain C-PCE and the P-PCE. The use of 258 stateful operations for an inter-domain LSP between the 259 transit/egress domain C-PCEs towards the P-PCE is out of scope of 260 this document. 262 1.2.3. Applicability of a Stateful P-PCE 264 [RFC8051] describes general considerations for a stateful PCE 265 deployment and examines its applicability and benefits, as well as 266 its challenges and limitations, through a number of use cases. These 267 are also applicable to the stateful P-PCE when used for the inter- 268 domain LSP path computation and setup. It should be noted that though 269 the stateful P-PCE has limited direct visibility inside the child 270 domain, it could still trigger re-optimization with the help of child 271 PCEs based on LSP state changes, abstract topology changes, or some 272 other external factors. 274 The C-PCE would delegate control of the inter-domain LSP to the P-PCE 275 so that the P-PCE can make changes to it. Note that, if the C-PCE 276 becomes aware of a topology change that is hidden from the P-PCE, it 277 could take back the delegation from the P-PCE to act on it itself. 278 Similarly, a P-PCE could also request for delegation if it needs to 279 make a change to the LSP (refer to 280 [I-D.ietf-pce-lsp-control-request]). 282 2. Terminology 283 The terminology is as per [RFC4655], [RFC5440], [RFC6805], [RFC8051], 284 [RFC8231], and [RFC8281]. 286 Some key terms are listed below for easy reference. 288 ACTN: Abstraction and Control of Traffic Engineering Networks 290 CNC: Customer Network Controller 292 C-PCE: Child Path Computation Element 294 H-PCE: Hierarchical Path Computation Element 296 IGP: Interior Gateway Protocol 298 LSP: Label Switched Path 300 LSP-DB: Label Switched Path Database 302 LSR: Label Switching Router 304 MDSC: Multi-Domain Service Coordinator 306 PCC: Path Computation Client 308 PCE: Path Computation Element 310 PCEP: Path Computation Element communication Protocol 312 PNC: Provisioning Network Controller 314 P-PCE: Parent Path Computation Element 316 TED: Traffic Engineering Database 318 VN: Virtual Network 320 2.1. Requirement Language 322 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 323 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 324 "OPTIONAL" in this document are to be interpreted as described in BCP 325 14 [RFC2119] [RFC8174] when, and only when, they appear in all 326 capitals, as shown here. 328 3. Hierarchical Stateful PCE 330 As described in [RFC6805], in the hierarchical PCE architecture, a 331 P-PCE maintains a domain topology map that contains the child domains 332 (seen as vertices in the topology) and their interconnections (links 333 in the topology). The P-PCE has no information about the content of 334 the child domains. Each child domain has at least one PCE capable of 335 computing paths across the domain. These PCEs are known as C-PCEs 336 and have a direct relationship with the P-PCE. The P-PCE builds the 337 domain topology map either via direct configuration (allowing network 338 policy to also be applied) or from learned information received from 339 each C-PCE. 341 Note that, in the scope of this document, both the C-PCEs and the P- 342 PCE are stateful in nature. 344 [RFC8231] specifies new functions to support a stateful PCE. It also 345 specifies that a function can be initiated either from a PCC towards 346 a PCE (C-E) or from a PCE towards a PCC (E-C). 348 This document extends these functions to support H-PCE Architecture 349 from a C-PCE towards P-PCE (EC-EP) or from a P-PCE towards C-PCE 350 (EP-EC). All PCE types herein (i.e., EC-EP or EP-EC) are assumed to 351 be "stateful PCE". 353 A number of interactions are expected in the Hierarchical Stateful 354 PCE architecture, these include: 356 LSP State Report (EC-EP): a child stateful PCE sends an LSP state 357 report to a Parent Stateful PCE whenever the state of a LSP 358 changes. 360 LSP State Synchronization (EC-EP): after the session between the 361 Child and Parent stateful PCEs is initialized, the P-PCE must 362 learn the state of C-PCE's TE LSPs. 364 LSP Control Delegation (EC-EP,EP-EC): a C-PCE grants to the P-PCE 365 the right to update LSP attributes on one or more LSPs; the C-PCE 366 may withdraw the delegation or the P-PCE may give up the 367 delegation at any time. 369 LSP Update Request (EP-EC): a stateful P-PCE requests modification 370 of attributes on a C-PCE's TE LSP. 372 PCE LSP Initiation Request (EP-EC): a stateful P-PCE requests C-PCE 373 to initiate a TE LSP. 375 Note that this hierarchy is recursive and thus a Label Switching 376 Router (LSR), as a PCC could delegate the control to a PCE, which may 377 delegate to its parent, which may further delegate it to its parent 378 (if it exist or needed). Similarly update operations could also be 379 applied recursively. 381 [I-D.ietf-pce-hierarchy-extensions] defines the H-PCE Capability TLV 382 that is used in the Open message to advertise the H-PCE capability. 383 [RFC8231] defines the Stateful PCE Capability TLV used in the Open 384 message to indicate stateful support. The presence of both TLVs in 385 an Open message indicates the support for stateful H-PCE operations 386 as described in this document. 388 Further consideration may be made for optional procedures for 389 stateful communication coordination between PCEs, including 390 procedures to minimise computational loops. The procedures described 391 in [I-D.litkowski-pce-state-sync] facilitate stateful communication 392 between PCEs for various use-cases. The procedures and extensions as 393 described in Section 3 of [I-D.litkowski-pce-state-sync] are also 394 applicable to Child and Parent PCE communication. The 395 SPEAKER-IDENTITY-TLV (defined in [RFC8232]) is included in the LSP 396 object to identify the Ingress (PCC). The PLSP-ID used in the 397 forwarded PCRpt by the C-PCE to P-PCE is same as the original one 398 used by the PCC. 400 3.1. Passive Operations 402 Procedures as described in [RFC6805] are applied, where the ingress 403 PCC triggers a path computation request for the destination towards 404 the C-PCE in the domain where the LSP originates. The C-PCE further 405 forwards the request to the P-PCE. The P-PCE selects a set of 406 candidate domain paths based on the domain topology and the state of 407 the inter-domain links. It then sends computation requests to the C- 408 PCEs responsible for each of the domains on the candidate domain 409 paths. Each C-PCE computes a set of candidate path segments across 410 its domain and sends the results to the P-PCE. The P-PCE uses this 411 information to select path segments and concatenate them to derive 412 the optimal end-to-end inter-domain path. The end-to-end path is 413 then sent to the C-PCE that received the initial path request, and 414 this C-PCE passes the path on to the PCC that issued the original 415 request. 417 As per [RFC8231], PCC sends an LSP State Report carried on a PCRpt 418 message to the C-PCE, indicating the LSP's status. The C-PCE may 419 further propagate the State Report to the P-PCE. A local policy at 420 C-PCE may dictate which LSPs to be reported to the P-PCE. The PCRpt 421 message is sent from C-PCE to P-PCE. 423 State synchronization mechanism as described in [RFC8231] and 424 [RFC8232] are applicable to a PCEP session between C-PCE and P-PCE as 425 well. 427 We use the sample hierarchical domain topology example from [RFC6805] 428 as the reference topology for the entirety of this document. It is 429 shown in Figure 1. 430 ----------------------------------------------------------------- 431 | Domain 5 | 432 | ----- | 433 | |PCE 5| | 434 | ----- | 435 | | 436 | ---------------- ---------------- ---------------- | 437 | | Domain 1 | | Domain 2 | | Domain 3 | | 438 | | | | | | | | 439 | | ----- | | ----- | | ----- | | 440 | | |PCE 1| | | |PCE 2| | | |PCE 3| | | 441 | | ----- | | ----- | | ----- | | 442 | | | | | | | | 443 | | ----| |---- ----| |---- | | 444 | | |BN11+---+BN21| |BN23+---+BN31| | | 445 | | - ----| |---- ----| |---- - | | 446 | | |S| | | | | |D| | | 447 | | - ----| |---- ----| |---- - | | 448 | | |BN12+---+BN22| |BN24+---+BN32| | | 449 | | ----| |---- ----| |---- | | 450 | | | | | | | | 451 | | ---- | | | | ---- | | 452 | | |BN13| | | | | |BN33| | | 453 | -----------+---- ---------------- ----+----------- | 454 | \ / | 455 | \ ---------------- / | 456 | \ | | / | 457 | \ |---- ----| / | 458 | ----+BN41| |BN42+---- | 459 | |---- ----| | 460 | | | | 461 | | ----- | | 462 | | |PCE 4| | | 463 | | ----- | | 464 | | | | 465 | | Domain 4 | | 466 | ---------------- | 467 | | 468 ----------------------------------------------------------------- 470 Figure 1: Sample Hierarchical Domain Topology 472 Steps 1 to 11 are exactly as described in section 4.6.2 of [RFC6805] 473 (Hierarchical PCE End-to-End Path Computation Procedure), the 474 following additional steps are added for stateful PCE to be executed 475 at the end: 477 (A) The Ingress LSR initiates the setup of the LSP as per the path 478 and reports to the PCE1 the LSP status ("GOING-UP"). 480 (B) The PCE1 further reports the status of the LSP to the P-PCE 481 (PCE5). 483 (C) The Ingress LSR notifies the LSP state to PCE1 when the state is 484 "UP". 486 (D) The PCE1 further reports the status of the LSP to the P-PCE 487 (PCE5). 489 The Ingress LSR could trigger path re-optimization by sending the 490 path computation request as described in [RFC6805], at this time it 491 can include the LSP object in the PCReq message as described in 492 [RFC8231]. 494 3.2. Active Operations 496 [RFC8231] describes the case of active stateful PCE. The active PCE 497 functionality uses two specific PCEP messages: 499 o Update Request (PCUpd) 501 o State Report (PCRpt) 503 The first is sent by the PCE to a PCC for modifying LSP attributes. 504 The PCC sends back a PCRpt to acknowledge the requested operation or 505 report any change in LSP's state. 507 As per [RFC8051], Delegation is an operation to grant a PCE, 508 temporary rights to modify a subset of LSP parameters on one or more 509 PCC's LSPs. The C-PCE may further choose to delegate to P-PCE based 510 on a local policy. The PCRpt message with "D" (delegate) flag is 511 sent from C-PCE to P-PCE. 513 To update an LSP, a PCE sends an LSP Update Request to the PCC using 514 a PCUpd message. For LSP delegated to the P-PCE via the child PCE, 515 the P-PCE can use the same PCUpd message to request change to the C- 516 PCE (the Ingress domain PCE), the PCE further propagates the update 517 request to the PCC. 519 The P-PCE uses the same mechanism described in Section 3.1 to compute 520 the end to end path using PCReq and PCRep messages. 522 For active operations, the following steps are required when 523 delegating the LSP, again using the reference architecture described 524 in Figure 1 (Sample Hierarchical Domain Topology). 526 (A) The Ingress LSR delegates the LSP to the PCE1 via PCRpt message 527 with D flag set. 529 (B) The PCE1 further delegates the LSP to the P-PCE (PCE5). 531 (C) Steps 4 to 10 of section 4.6.2 of [RFC6805] are executed at P- 532 PCE (PCE5) to determine the end to end path. 534 (D) The P-PCE (PCE5) sends the update request to the C-PCE (PCE1) 535 via PCUpd message. 537 (E) The PCE1 further updates the LSP to the Ingress LSR (PCC). 539 (F) The Ingress LSR initiates the setup of the LSP as per the path 540 and reports to the PCE1 the LSP status ("GOING-UP"). 542 (G) The PCE1 further reports the status of the LSP to the P-PCE 543 (PCE5). 545 (H) The Ingress LSR notifies the LSP state to PCE1 when the state is 546 "UP". 548 (I) The PCE1 further reports the status of the LSP to the P-PCE 549 (PCE5). 551 3.3. PCE Initiation of LSPs 553 [RFC8281] describes the setup, maintenance and teardown of PCE- 554 initiated LSPs under the stateful PCE model, without the need for 555 local configuration on the PCC, thus allowing for a dynamic network 556 that is centrally controlled and deployed. To instantiate or delete 557 an LSP, the PCE sends the Path Computation LSP Initiate Request 558 (PCInitiate) message to the PCC. In case of inter-domain LSP in 559 Hierarchical PCE architecture, the initiation operations can be 560 carried out at the P-PCE. In which case after P-PCE finishes the E2E 561 path computation, it can send the PCInitiate message to the C-PCE 562 (the Ingress domain PCE), the PCE further propagates the initiate 563 request to the PCC. 565 The following steps are performed, for PCE initiated operations, 566 again using the reference architecture described in Figure 1 (Sample 567 Hierarchical Domain Topology): 569 (A) The P-PCE (PCE5) is requested to initiate a LSP. Steps 4 to 10 570 of section 4.6.2 of [RFC6805] are executed to determine the end 571 to end path. 573 (B) The P-PCE (PCE5) sends the initiate request to the child PCE 574 (PCE1) via PCInitiate message. 576 (C) The PCE1 further propagates the initiate message to the Ingress 577 LSR (PCC). 579 (D) The Ingress LSR initiates the setup of the LSP as per the path 580 and reports to the PCE1 the LSP status ("GOING-UP"). 582 (E) The PCE1 further reports the status of the LSP to the P-PCE 583 (PCE5). 585 (F) The Ingress LSR notifies the LSP state to PCE1 when the state is 586 "UP". 588 (G) The PCE1 further reports the status of the LSP to the P-PCE 589 (PCE5). 591 The Ingress LSR (PCC) would generate the PLSP-ID for the LSP and 592 inform the C-PCE, which is propagated to the P-PCE. 594 3.3.1. Per Domain Stitched LSP 596 The Hierarchical PCE architecture as per [RFC6805] is primarily used 597 for E2E LSP. With PCE-Initiated capability, another mode of 598 operation is possible, where multiple intra-domain LSPs are initiated 599 in each domain which are further stitched to form an E2E LSP. The 600 P-PCE sends PCInitiate message to each C-PCE separately to initiate 601 individual LSP segments along the domain path. These individual per 602 domain LSP are stitched together by some mechanism, which is out of 603 scope of this document (Refer [I-D.dugeon-pce-stateful- 604 interdomain]). 606 The following steps are performed, for the Per Domain stitched LSP 607 operation, again using the reference architecture described in Figure 608 1 (Sample Hierarchical Domain Topology): 610 (A) The P-PCE (PCE5) is requested to initiate a LSP. Steps 4 to 10 611 of section 4.6.2 of [RFC6805] are executed to determine the end 612 to end path, which are broken into per-domain LSPs say - 614 o S-BN41 616 o BN41-BN33 617 o BN33-D 619 It should be noted that the P-PCE may use other mechanisms to 620 determine the suitable per-domain LSPs (apart from [RFC6805]). 622 For LSP (BN33-D) 624 (B) The P-PCE (PCE5) sends the initiate request to the child PCE 625 (PCE3) via PCInitiate message for LSP (BN33-D). 627 (C) The PCE3 further propagates the initiate message to BN33. 629 (D) BN33 initiates the setup of the LSP as per the path and reports 630 to the PCE3 the LSP status ("GOING-UP"). 632 (E) The PCE3 further reports the status of the LSP to the P-PCE 633 (PCE5). 635 (F) The node BN33 notifies the LSP state to PCE3 when the state is 636 "UP". 638 (G) The PCE3 further reports the status of the LSP to the P-PCE 639 (PCE5). 641 For LSP (BN41-BN33) 643 (H) The P-PCE (PCE5) sends the initiate request to the child PCE 644 (PCE4) via PCInitiate message for LSP (BN41-BN33). 646 (I) The PCE4 further propagates the initiate message to BN41. 648 (J) BN41 initiates the setup of the LSP as per the path and reports 649 to the PCE4 the LSP status ("GOING-UP"). 651 (K) The PCE4 further reports the status of the LSP to the P-PCE 652 (PCE5). 654 (L) The node BN41 notifies the LSP state to PCE4 when the state is 655 "UP". 657 (M) The PCE4 further reports the status of the LSP to the P-PCE 658 (PCE5). 660 For LSP (S-BN41) 662 (N) The P-PCE (PCE5) sends the initiate request to the child PCE 663 (PCE1) via PCInitiate message for LSP (S-BN41). 665 (O) The PCE1 further propagates the initiate message to node S. 667 (P) S initiates the setup of the LSP as per the path and reports to 668 the PCE1 the LSP status ("GOING-UP"). 670 (Q) The PCE1 further reports the status of the LSP to the P-PCE 671 (PCE5). 673 (R) The node S notifies the LSP state to PCE1 when the state is 674 "UP". 676 (S) The PCE1 further reports the status of the LSP to the P-PCE 677 (PCE5). 679 Additionally: 681 (T) Once P-PCE receives report of each per-domain LSP, it should use 682 suitable stitching mechanism, which is out of scope of this 683 document. In this step, P-PCE (PCE5) could also initiate an E2E 684 LSP (S-D) by sending the PCInitiate message to Ingress C-PCE 685 (PCE1). 687 Note that each per-domain LSP can be setup in parallel. Further, it 688 is also possible to stitch the per-domain LSP at the same time as the 689 per-domain LSPs are initiated. This option is defined in 690 [I-D.dugeon-pce-stateful-interdomain]. 692 4. Security Considerations 694 The security considerations listed in [RFC8231],[RFC6805] and 695 [RFC5440] apply to this document as well. As per [RFC6805], it is 696 expected that the parent PCE will require all child PCEs to use full 697 security when communicating with the parent. 699 Any multi-domain operation necessarily involves the exchange of 700 information across domain boundaries. This is bound to represent a 701 significant security and confidentiality risk especially when the 702 child domains are controlled by different commercial concerns. PCEP 703 allows individual PCEs to maintain confidentiality of their domain 704 path information using path-keys [RFC5520], and the hierarchical PCE 705 architecture is specifically designed to enable as much isolation of 706 domain topology and capabilities information as is possible. The LSP 707 state in the PCRpt message must continue to maintain the internal 708 domain confidentiality when required. 710 The security consideration for PCE-Initiated LSP as per [RFC8281] is 711 also applicable from P-PCE to C-PCE. 713 Further, section 6.3 describes the use of path-key [RFC5520] for 714 confidentiality between C-PCE and P-PCE. 716 Thus it is RECOMMENDED to secure the PCEP session (between the P-PCE 717 and the C-PCE) using either Transport Layer Security (TLS) [RFC8253] 718 per the recommendations and best current practices in [RFC7525] or 719 TCP Authentication Option (TCP-AO) [RFC5925]. 721 5. Manageability Considerations 723 All manageability requirements and considerations listed in 724 [RFC5440], [RFC6805], [RFC8231], and [RFC8281] apply to Stateful H- 725 PCE defined in this document. In addition, requirements and 726 considerations listed in this section apply. 728 5.1. Control of Function and Policy 730 Support of the hierarchical procedure will be controlled by the 731 management organization responsible for each child PCE. The parent 732 PCE must only accept path computation requests from authorized child 733 PCEs. If a parent PCE receives report from an unauthorized child 734 PCE, the report should be dropped. All mechanism as described in 735 [RFC8231] and [RFC8281] continue to apply. 737 5.2. Information and Data Models 739 An implementation should allow the operator to view the stateful and 740 H-PCE capabilities advertised by each peer. The PCEP YANG module 741 [I-D.ietf-pce-pcep-yang] may be extended to include details for 742 stateful H-PCE deployment and operation, exact attributes to be 743 modeled is out of scope for this document. 745 5.3. Liveness Detection and Monitoring 747 Mechanisms defined in this document do not imply any new liveness 748 detection and monitoring requirements in addition to those already 749 listed in [RFC5440]. 751 5.4. Verify Correct Operations 753 Mechanisms defined in this document do not imply any new operation 754 verification requirements in addition to those already listed in 755 [RFC5440] and [RFC8231]. 757 5.5. Requirements On Other Protocols 759 Mechanisms defined in this document do not imply any new requirements 760 on other protocols. 762 5.6. Impact On Network Operations 764 Mechanisms defined in [RFC5440] and [RFC8231] also apply to PCEP 765 extensions defined in this document. 767 The stateful H-PCE technique brings the applicability of stateful PCE 768 as described in [RFC8051], for the LSP traversing multiple domains. 770 5.7. Error Handling between PCEs 772 Error types and notifications useful for correct PCEP operation may 773 be implemented for managing parent and child PCE interaction. PCEP 774 Error behavior propagation, notification and error criticality level, 775 are further defined in [I-D.ietf-pce-enhanced-errors]. 777 6. Other Considerations 779 6.1. Applicability to Inter-Layer Traffic Engineering 781 [RFC5623] describes a framework for applying the PCE-based 782 architecture to inter-layer (G)MPLS traffic engineering. The H-PCE 783 Stateful architecture with stateful P-PCE coordinating with the 784 stateful C-PCEs of higher and lower layer is shown in the figure 785 below. 787 +----------+ 788 | Parent | 789 /| PCE | 790 / +----------+ 791 / / Stateful 792 / / P-PCE 793 / / 794 / / 795 Stateful+-----+ / / 796 C-PCE | PCE |/ / 797 Hi | Hi | / 798 +-----+ / 799 +---+ +---+ / +---+ +---+ 800 + LSR +--+ LSR +........................+ LSR +--+ LSR + 801 + H1 + + H2 + / + H3 + + H4 + 802 +---+ +---+\ +-----+/ /+---+ +---+ 803 \ | PCE | / 804 \ | Lo | / 805 Stateful \ +-----+ / 806 C-PCE \ / 807 Lo \+---+ +---+/ 808 + LSR +--+ LSR + 809 + L1 + + L2 + 810 +---+ +---+ 812 Figure 2: Sample Inter-Layer Topology 814 All procedures described in Section 3 are applicable to inter-layer 815 (and therefore separate domains) path setup as well. 817 6.2. Scalability Considerations 819 It should be noted that if all the C-PCEs would report all the LSPs 820 in their domain, it could lead to scalability issues for the P-PCE. 821 Thus it is recommended to only report the LSPs which are involved in 822 H-PCE, i.e. the LSPs which are either delegated to the P-PCE or 823 initiated by the P-PCE. Scalability considerations for PCEP as per 824 [RFC8231] continue to apply for the PCEP session between child and 825 parent PCE. 827 6.3. Confidentiality 829 As described in section 4.2 of [RFC6805], information about the 830 content of child domains is not shared for both scaling and 831 confidentiality reasons. Along with the confidentiality during path 832 computation, the child PCE could also conceal the path information, a 833 C-PCE may replace a path segment with a path-key [RFC5520], 834 effectively hiding the content of a segment of a path. 836 7. IANA Considerations 838 There are no IANA considerations. 840 8. Acknowledgments 842 Thanks to Manuela Scarella, Haomian Zheng, Sergio Marmo, Stefano 843 Parodi, Giacomo Agostini, Jeff Tantsura, Rajan Rao, Adrian Farrel and 844 Haomian Zheng, for their reviews and suggestions. 846 Thanks to Tal Mazrahi for the RTGDIR review, Paul Kyzivat for the 847 GENART review, and Stephen Farrell for SECDIR review. 849 9. References 851 9.1. Normative References 853 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 854 Requirement Levels", BCP 14, RFC 2119, DOI 855 10.17487/RFC2119, March 1997, 856 . 858 [RFC4655] Farrel, A., Vasseur, J., and J. Ash, "A Path Computation 859 Element (PCE)-Based Architecture", RFC 4655, DOI 860 10.17487/RFC4655, August 2006, 861 . 863 [RFC5440] Vasseur, JP., Ed. and JL. Le Roux, Ed., "Path Computation 864 Element (PCE) Communication Protocol (PCEP)", RFC 5440, 865 DOI 10.17487/RFC5440, March 2009, 866 . 868 [RFC5520] Bradford, R., Ed., Vasseur, JP., and A. Farrel, 869 "Preserving Topology Confidentiality in Inter-Domain Path 870 Computation Using a Path-Key-Based Mechanism", RFC 5520, 871 DOI 10.17487/RFC5520, April 2009, 872 . 874 [RFC6805] King, D., Ed. and A. Farrel, Ed., "The Application of the 875 Path Computation Element Architecture to the Determination 876 of a Sequence of Domains in MPLS and GMPLS", RFC 6805, DOI 877 10.17487/RFC6805, November 2012, 878 . 880 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 881 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 882 May 2017, . 884 [RFC8231] Crabbe, E., Minei, I., Medved, J., and R. Varga, "Path 885 Computation Element Communication Protocol (PCEP) 886 Extensions for Stateful PCE", RFC 8231, 887 DOI 10.17487/RFC8231, September 2017, 888 . 890 [RFC8281] Crabbe, E., Minei, I., Sivabalan, S., and R. Varga, "Path 891 Computation Element Communication Protocol (PCEP) 892 Extensions for PCE-Initiated LSP Setup in a Stateful PCE 893 Model", RFC 8281, DOI 10.17487/RFC8281, December 2017, 894 . 896 9.2. Informative References 898 [RFC3209] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V., 899 and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP 900 Tunnels", RFC 3209, DOI 10.17487/RFC3209, December 2001, 901 . 903 [RFC3473] Berger, L., Ed., "Generalized Multi-Protocol Label 904 Switching (GMPLS) Signaling Resource ReserVation Protocol- 905 Traffic Engineering (RSVP-TE) Extensions", RFC 3473, 906 DOI 10.17487/RFC3473, January 2003, 907 . 909 [RFC4726] Farrel, A., Vasseur, J., and A. Ayyangar, "A Framework for 910 Inter-Domain Multiprotocol Label Switching Traffic 911 Engineering", RFC 4726, DOI 10.17487/RFC4726, November 912 2006, . 914 [RFC5623] Oki, E., Takeda, T., Le Roux, JL., and A. Farrel, 915 "Framework for PCE-Based Inter-Layer MPLS and GMPLS 916 Traffic Engineering", RFC 5623, DOI 10.17487/RFC5623, 917 September 2009, 918 . 920 [RFC5925] Touch, J., Mankin, A., and R. Bonica, "The TCP 921 Authentication Option", RFC 5925, DOI 10.17487/RFC5925, 922 June 2010, . 924 [RFC7525] Sheffer, Y., Holz, R., and P. Saint-Andre, 925 "Recommendations for Secure Use of Transport Layer 926 Security (TLS) and Datagram Transport Layer Security 927 (DTLS)", BCP 195, RFC 7525, DOI 10.17487/RFC7525, May 928 2015, . 930 [RFC8051] Zhang, X., Ed. and I. Minei, Ed., "Applicability of a 931 Stateful Path Computation Element (PCE)", RFC 8051, 932 DOI 10.17487/RFC8051, January 2017, 933 . 935 [RFC8232] Crabbe, E., Minei, I., Medved, J., Varga, R., Zhang, X., 936 and D. Dhody, "Optimizations of Label Switched Path State 937 Synchronization Procedures for a Stateful PCE", RFC 8232, 938 DOI 10.17487/RFC8232, September 2017, 939 . 941 [RFC8253] Lopez, D., Gonzalez de Dios, O., Wu, Q., and D. Dhody, 942 "PCEPS: Usage of TLS to Provide a Secure Transport for the 943 Path Computation Element Communication Protocol (PCEP)", 944 RFC 8253, DOI 10.17487/RFC8253, October 2017, 945 . 947 [RFC8453] Ceccarelli, D., Ed. and Y. Lee, Ed., "Framework for 948 Abstraction and Control of TE Networks (ACTN)", RFC 8453, 949 DOI 10.17487/RFC8453, August 2018, 950 . 952 [RFC8637] Dhody, D., Lee, Y., and D. Ceccarelli, "Applicability of 953 the Path Computation Element (PCE) to the Abstraction and 954 Control of TE Networks (ACTN)", RFC 8637, DOI 955 10.17487/RFC8637, July 2019, 956 . 958 [I-D.litkowski-pce-state-sync] 959 Litkowski, S., Sivabalan, S., and D. Dhody, "Inter 960 Stateful Path Computation Element communication 961 procedures", draft-litkowski-pce-state-sync-06 (work in 962 progress), July 2019. 964 [I-D.ietf-pce-hierarchy-extensions] 965 Zhang, F., Zhao, Q., Dios, O., Casellas, R., and D. King, 966 "Extensions to Path Computation Element Communication 967 Protocol (PCEP) for Hierarchical Path Computation Elements 968 (PCE)", draft-ietf-pce-hierarchy-extensions-11 (work in 969 progress), June 2019. 971 [I-D.ietf-pce-pcep-yang] 972 Dhody, D., Hardwick, J., Beeram, V., and J. Tantsura, "A 973 YANG Data Model for Path Computation Element 974 Communications Protocol (PCEP)", 975 draft-ietf-pce-pcep-yang-12 (work in progress), July 2019. 977 [I-D.dugeon-pce-stateful-interdomain] 978 Dugeon, O., Meuric, J., Lee, Y., Dhody, D., and D. 979 Ceccarelli, "PCEP Extension for Stateful Inter-Domain 980 Tunnels", draft-dugeon-pce-stateful-interdomain-02 (work 981 in progress), March 2019. 983 [I-D.ietf-pce-lsp-control-request] 984 Raghuram, A., Goddard, A., Yadlapalli, C., Karthik, J., 985 Sivabalan, S., Parker, J., and M. Negi, "Ability for a 986 stateful Path Computation Element (PCE) to request and 987 obtain control of a LSP", draft-ietf-pce-lsp-control- 988 request-08 (work in progress), August 2019. 990 [I-D.ietf-pce-enhanced-errors] 991 Pouyllau, et al., "Extensions to PCEP for Enhanced Errors" 992 , draft-ietf-pce-enhanced-errors-06 (work in progress), 993 August 2019. 995 Contributors 997 Avantika 998 ECI Telecom 999 India 1001 EMail: avantika.srm@gmail.com 1003 Xian Zhang 1004 Huawei Technologies 1005 Bantian, Longgang District 1006 Shenzhen, Guangdong 518129 1007 P.R.China 1009 EMail: zhang.xian@huawei.com 1011 Udayasree Palle 1013 EMail: udayasreereddy@gmail.com 1015 Oscar Gonzalez de Dios 1016 Telefonica I+D 1017 Don Ramon de la Cruz 82-84 1018 Madrid, 28045 1019 Spain 1020 Phone: +34913128832 1022 EMail: oscar.gonzalezdedios@telefonica.com 1024 Authors' Addresses 1026 Dhruv Dhody 1027 Huawei Technologies 1028 Divyashree Techno Park, Whitefield 1029 Bangalore, Karnataka 560066 1030 India 1032 EMail: dhruv.ietf@gmail.com 1034 Young Lee 1035 Futurewei Technologies 1036 5340 Legacy Drive, Building 3 1037 Plano, TX 75023 1038 USA 1040 EMail: younglee.tx@gmail.com 1042 Daniele Ceccarelli 1043 Ericsson 1044 Torshamnsgatan,48 1045 Stockholm 1046 Sweden 1048 EMail: daniele.ceccarelli@ericsson.com 1050 Jongyoon Shin 1051 SK Telecom 1052 6 Hwangsaeul-ro, 258 beon-gil, Bundang-gu, Seongnam-si, 1053 Gyeonggi-do 463-784 1054 Republic of Korea 1056 EMail: jongyoon.shin@sk.com 1058 Daniel King 1059 Lancaster University 1060 UK 1062 EMail: d.king@lancaster.ac.uk