idnits 2.17.1 draft-ietf-pce-stateful-hpce-09.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 (June 10, 2019) is 1781 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Outdated reference: A later version (-10) exists of draft-litkowski-pce-state-sync-05 == Outdated reference: A later version (-23) exists of draft-ietf-pce-pcep-yang-11 == 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-04 == Outdated reference: A later version (-13) exists of draft-ietf-pce-enhanced-errors-05 Summary: 0 errors (**), 0 flaws (~~), 6 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 PCE Working Group D. Dhody 3 Internet-Draft Y. Lee 4 Intended status: Informational Huawei Technologies 5 Expires: December 12, 2019 D. Ceccarelli 6 Ericsson 7 J. Shin 8 SK Telecom 9 D. King 10 Lancaster University 11 O. Gonzalez de Dios 12 Telefonica I+D 13 June 10, 2019 15 Hierarchical Stateful Path Computation Element (PCE). 16 draft-ietf-pce-stateful-hpce-09 18 Abstract 20 A Stateful Path Computation Element (PCE) maintains information on 21 the current network state, including: computed Label Switched Path 22 (LSPs), reserved resources within the network, and pending path 23 computation requests. This information may then be considered when 24 computing new traffic engineered LSPs, and for associated and 25 dependent LSPs, received from Path Computation Clients (PCCs). The 26 Path computation response from a PCE is helpful for the PCC to 27 gracefully establish the computed LSP. 29 The Hierarchical Path Computation Element (H-PCE) architecture, 30 provides an architecture to allow the optimum sequence of 31 inter-connected domains to be selected, and network policy to be 32 applied if applicable, via the use of a hierarchical relationship 33 between PCEs. 35 Combining the capabilities of Stateful PCE and the Hierarchical PCE 36 would be advantageous. This document describes general considerations 37 and use cases for the deployment of Stateful, and not Stateless, PCEs 38 using the Hierarchical PCE architecture. 40 Status of This Memo 42 This Internet-Draft is submitted in full conformance with the 43 provisions of BCP 78 and BCP 79. 45 Internet-Drafts are working documents of the Internet Engineering 46 Task Force (IETF). Note that other groups may also distribute 47 working documents as Internet-Drafts. The list of current Internet- 48 Drafts is at https://datatracker.ietf.org/drafts/current/. 50 Internet-Drafts are draft documents valid for a maximum of six months 51 and may be updated, replaced, or obsoleted by other documents at any 52 time. It is inappropriate to use Internet-Drafts as reference 53 material or to cite them other than as "work in progress." 55 This Internet-Draft will expire on December 12, 2019. 57 Copyright Notice 59 Copyright (c) 2019 IETF Trust and the persons identified as the 60 document authors. All rights reserved. 62 This document is subject to BCP 78 and the IETF Trust's Legal 63 Provisions Relating to IETF Documents 64 (https://trustee.ietf.org/license-info) in effect on the date of 65 publication of this document. Please review these documents 66 carefully, as they describe your rights and restrictions with respect 67 to this document. Code Components extracted from this document must 68 include Simplified BSD License text as described in Section 4.e of 69 the Trust Legal Provisions and are provided without warranty as 70 described in the Simplified BSD License. 72 Table of Contents 74 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 75 1.1. Use-cases and Applicability of Hierarchical Stateful PCE . 4 76 1.1.1 Applicability to ACTN . . . . . . . . . . . . . . . . . 5 77 1.1.2 End-to-End Contiguous LSP . . . . . . . . . . . . . . . 5 78 1.1.3 Applicability of a Stateful P-PCE . . . . . . . . . . . 6 79 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 6 80 3. Hierarchical Stateful PCE . . . . . . . . . . . . . . . . . . 7 81 3.1. Passive Operations . . . . . . . . . . . . . . . . . . . . 8 82 3.2. Active Operations . . . . . . . . . . . . . . . . . . . . 10 83 3.3. PCE Initiation of LSPs . . . . . . . . . . . . . . . . . . 11 84 3.3.1. Per Domain Stitched LSP . . . . . . . . . . . . . . . 12 85 4. Security Considerations . . . . . . . . . . . . . . . . . . . 14 86 5. Manageability Considerations . . . . . . . . . . . . . . . . . 15 87 5.1. Control of Function and Policy . . . . . . . . . . . . . . 15 88 5.2. Information and Data Models . . . . . . . . . . . . . . . 15 89 5.3. Liveness Detection and Monitoring . . . . . . . . . . . . 15 90 5.4. Verify Correct Operations . . . . . . . . . . . . . . . . 15 91 5.5. Requirements On Other Protocols . . . . . . . . . . . . . 15 92 5.6. Impact On Network Operations . . . . . . . . . . . . . . . 15 93 5.7. Error Handling between PCEs . . . . . . . . . . . . . . . 16 94 6. Other Considerations . . . . . . . . . . . . . . . . . . . . . 16 95 6.1. Applicability to Inter-Layer Traffic Engineering . . . . . 16 96 6.2. Scalability Considerations . . . . . . . . . . . . . . . . 17 97 6.3. Confidentiality . . . . . . . . . . . . . . . . . . . . . 17 98 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 17 99 8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 17 100 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 17 101 9.1. Normative References . . . . . . . . . . . . . . . . . . . 17 102 9.2. Informative References . . . . . . . . . . . . . . . . . . 18 103 Contributors . . . . . . . . . . . . . . . . . . . . . . . . . . . 21 104 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 21 106 1. Introduction 108 The Path Computation Element communication Protocol (PCEP) [RFC5440] 109 provides mechanisms for Path Computation Elements (PCEs) to perform 110 path computations in response to Path Computation Clients' (PCCs) 111 requests. 113 A stateful PCE is capable of considering, for the purposes of path 114 computation, not only the network state in terms of links and nodes 115 (referred to as the Traffic Engineering Database or TED) but also the 116 status of active services (previously computed paths, and currently 117 reserved resources, stored in the Label Switched Paths Database 118 (LSP-DB). 120 [RFC8051] describes general considerations for a stateful PCE 121 deployment and examines its applicability and benefits, as well as 122 its challenges and limitations through a number of use cases. 124 [RFC8231] describes a set of extensions to PCEP to provide stateful 125 control. A stateful PCE has access to not only the information 126 carried by the network's Interior Gateway Protocol (IGP), but also 127 the set of active paths and their reserved resources for its 128 computations. The additional state allows the PCE to compute 129 constrained paths while considering individual LSPs and their 130 interactions. [RFC8281] describes the setup, maintenance and 131 teardown of PCE-initiated LSPs under the stateful PCE model. 133 [RFC8231] also describes the active stateful PCE. The active PCE 134 functionality allows a PCE to reroute an existing LSP or make changes 135 to the attributes of an existing LSP, or delegate control of specific 136 LSPs to a new PCE. 138 The ability to compute shortest constrained TE LSPs in Multiprotocol 139 Label Switching (MPLS) and Generalized MPLS (GMPLS) networks across 140 multiple domains has been identified as a key motivation for PCE 141 development. [RFC6805] describes a Hierarchical PCE (H-PCE) 142 architecture which can be used for computing end-to-end paths for 143 inter-domain MPLS Traffic Engineering (TE) and GMPLS Label Switched 144 Paths (LSPs). Within the Hierarchical PCE (H-PCE) architecture 145 [RFC6805], the Parent PCE (P-PCE) is used to compute a multi-domain 146 path based on the domain connectivity information. A Child PCE 147 (C-PCE) may be responsible for a single domain or multiple domains, 148 it is used to compute the intra-domain path based on its domain 149 topology information. 151 This document presents general considerations for stateful PCEs, and 152 not Stateless PCEs, in the hierarchical PCE architecture. In 153 particular, the behavior changes and additions to the existing 154 stateful PCE mechanisms (including PCE-initiated LSP setup and active 155 PCE usage) in the context of networks using the H-PCE architecture. 157 In this document, Sections 3.1 and 3.2 focus on end to end (E2E) 158 inter-domain TE LSP. Section 3.3.1 describes the operations for 159 stitching Per Domain LSPs. 161 1.1. Use-cases and Applicability of Hierarchical Stateful PCE 163 As per [RFC6805], in the hierarchical PCE architecture, a P-PCE 164 maintains a domain topology map that contains the child domains and 165 their interconnections. Usually, the P-PCE has no information about 166 the content of the child domains. But if the PCE is applied to the 167 Abstraction and Control of TE Networks (ACTN) [RFC8453] as described 168 in [I-D.ietf-pce-applicability-actn], the Provisioning Network 169 Controller (PNC) can provide an abstract topology to the Multi-Domain 170 Service Coordinator (MDSC). Thus the P-PCE in MDSC could be aware of 171 topology information in much more detail than just the domain 172 topology. 174 In a PCEP session between a PCC (Ingress) and a C-PCE, the C-PCE acts 175 as per the stateful PCE operations described in [RFC8231] and 176 [RFC8281]. The same C-PCE behaves as a PCC on the PCEP session 177 towards the P-PCE. The P-PCE is stateful in nature and thus maintains 178 the state of the inter-domain LSPs that are reported to it. The 179 inter-domain LSP could also be delegated by the C-PCE to the P-PCE, 180 so that the P-PCE could update the inter-domain path. The trigger for 181 this update could be the LSP state change reported for this LSP or 182 any other LSP. It could also be a change in topology at the P-PCE 183 such as inter-domain link status change. In case of use of stateful 184 H-PCE in ACTN, a change in abstract topology learned by the P-PCE 185 could also trigger the update. Some other external factors (such as a 186 measurement probe) could also be a trigger at the P-PCE. Any such 187 update would require an inter-domain path recomputation as described 188 in [RFC6805]. 190 The inter-domain LSP could be set up using the end-to-end signaling 191 as described in [RFC6805]. Additionally a per-domain stitched LSP 192 model is also applicable in a P-PCE initiation model. Section 3.1, 193 Section 3.2, and Section 3.3 describe the end-to-end Contiguous LSP 194 setup, whereas Section 3.3.1 describe the per-domain stitching. 196 1.1.1 Applicability to ACTN 198 [RFC8453] describes a framework for the Abstraction and Control of TE 199 Networks (ACTN), where each Provisioning Network Controller (PNC) is 200 equivalent to a C-PCE, and the P-PCE is the Multi-Domain Service 201 Coordinator (MDSC). The Per Domain stitched LSP as per the 202 Hierarchical PCE architecture described in Section 3.3.1 and Section 203 4.1 is well suited for ACTN deployments. 205 [I-D.ietf-pce-applicability-actn] examines the applicability of PCE 206 to the ACTN framework. To support the function of multi domain 207 coordination via hierarchy, the hierarchy of stateful PCEs play a 208 crucial role. 210 In the ACTN framework, a Customer Network Controller (CNC) can 211 request the MDSC to check whether there is a possibility to meet 212 Virtual Network (VN) requirements before requesting for the VN to be 213 provisioned. The H-PCE architecture as described in [RFC6805] can 214 support this function using PCReq and PCRep messages between the 215 P-PCE and C-PCEs. When the CNC requests for VN provisioning, the MDSC 216 decompose this request into multiple inter-domain LSP provisioning 217 requests, which might be further decomposed to per-domain path 218 segments. This is described in Section 3.3.1. The MDSC uses the LSP 219 Initiate Request (PCInitiate) message from the P-PCE towards the 220 C-PCE, and the C-PCE reports the state back to the P-PCE via a Path 221 Computation State Report (PCRpt) message. The P-PCE could make 222 changes to the LSP via the use of a Path Computation Update Request 223 (PCUpd) message. 225 In this case, the P-PCE (as MDSC) interacts with multiple C-PCEs (as 226 PNCs) along the inter-domain path of the LSP. 228 1.1.2 End-to-End Contiguous LSP 230 Different signaling methods for inter-domain RSVP-TE signaling are 231 identified in [RFC4726]. Contiguous LSPs are achieved using the 232 procedures of [RFC3209] and [RFC3473] to create a single end-to-end 233 LSP that spans all domains. [RFC6805] describes the technique to 234 establish the optimum path when the sequence of domains is not known 235 in advance. It shows how the PCE architecture can be extended to 236 allow the optimum sequence of domains to be selected, and the optimum 237 end-to-end path to be derived. 239 In case of a stateful P-PCE, the stateful P-PCE has to be aware of 240 the inter-domain LSPs for it to consider them during path 241 computation. For example, a domain diverse path from another LSP. 242 This is the Passive Stateful P-PCE as described in Section 3.1. 243 Additionally, the inter-domain LSP could be delegated to the P-PCE, 244 so that P-PCE could trigger an update via a PCUpd message. The update 245 could be triggered on receipt of the PCRpt message that indicates a 246 status change of this LSP or some other LSP. The other LSP could be 247 an associated LSP (such as protection) or an unrelated LSP whose 248 resource change leads to re-optimization at the P-PCE. This is the 249 Active Stateful Operation as described in Section 3.2. Further, the 250 P-PCE could be instructed to create an inter-domain LSP on its own 251 using the PCInitiate message for an E2E contiguous LSP. The P-PCE 252 would send the PCInitiate message to the Ingress domain C-PCE, which 253 would further instruct the Ingress PCC. 255 In this document, for the Contiguous LSP, the above interactions are 256 only between the ingress domain C-PCE and the P-PCE. The use of 257 stateful operations for an inter-domain LSP between the 258 transit/egress domain C-PCEs towards the P-PCE is out of scope of 259 this document. 261 1.1.3 Applicability of a Stateful P-PCE 263 [RFC8051] describes general considerations for a stateful PCE 264 deployment and examines its applicability and benefits, as well as 265 its challenges and limitations, through a number of use cases. These 266 are also applicable to the stateful P-PCE when used for the inter- 267 domain LSP path computation and setup. It should be noted that though 268 the stateful P-PCE has limited direct visibility inside the child 269 domain, it could still trigger re-optimization with the help of child 270 PCEs based on LSP state changes, abstract topology changes, or some 271 other external factors. 273 The C-PCE would delegate control of the inter-domain LSP to the P-PCE 274 so that the P-PCE can make changes to it. Note that, if the C-PCE 275 becomes aware of a topology change that is hidden from the P-PCE, it 276 could take back the delegation from the P-PCE to act on it itself. 277 Similarly, a P-PCE could also request for delegation if it needs to 278 make a change to the LSP (refer to 279 [I-D.ietf-pce-lsp-control-request]). 281 2. Terminology 283 The terminology is as per [RFC4655], [RFC5440], [RFC6805], [RFC8051], 284 [RFC8231], and [RFC8281]. 286 3. Hierarchical Stateful PCE 288 As described in [RFC6805], in the hierarchical PCE architecture, a 289 P-PCE maintains a domain topology map that contains the child domains 290 (seen as vertices in the topology) and their interconnections (links 291 in the topology). The P-PCE has no information about the content of 292 the child domains. Each child domain has at least one PCE capable of 293 computing paths across the domain. These PCEs are known as C-PCEs 294 and have a direct relationship with the P-PCE. The P-PCE builds the 295 domain topology map either via direct configuration (allowing network 296 policy to also be applied) or from learned information received from 297 each C-PCE. 299 Note that, in the scope of this document, both the C-PCEs and the P- 300 PCE are stateful in nature. 302 [RFC8231] specifies new functions to support a stateful PCE. It also 303 specifies that a function can be initiated either from a PCC towards 304 a PCE (C-E) or from a PCE towards a PCC (E-C). 306 This document extends these functions to support H-PCE Architecture 307 from a C-PCE towards P-PCE (EC-EP) or from a P-PCE towards C-PCE 308 (EP-EC). All PCE types herein (i.e., EC-EP or EP-EC) are assumed to 309 be "stateful PCE". 311 A number of interactions are expected in the Hierarchical Stateful 312 PCE architecture, these include: 314 LSP State Report (EC-EP): a child stateful PCE sends an LSP state 315 report to a Parent Stateful PCE whenever the state of a LSP 316 changes. 318 LSP State Synchronization (EC-EP): after the session between the 319 Child and Parent stateful PCEs is initialized, the P-PCE must 320 learn the state of C-PCE's TE LSPs. 322 LSP Control Delegation (EC-EP,EP-EC): a C-PCE grants to the P-PCE 323 the right to update LSP attributes on one or more LSPs; the C-PCE 324 may withdraw the delegation or the P-PCE may give up the 325 delegation at any time. 327 LSP Update Request (EP-EC): a stateful P-PCE requests modification 328 of attributes on a C-PCE's TE LSP. 330 PCE LSP Initiation Request (EP-EC): a stateful P-PCE requests C-PCE 331 to initiate a TE LSP. 333 Note that this hierarchy is recursive and thus a Label Switching 334 Router (LSR), as a PCC could delegate the control to a PCE, which may 335 delegate to its parent, which may further delegate it to its parent 336 (if it exist or needed). Similarly update operations could also be 337 applied recursively. 339 [I-D.ietf-pce-hierarchy-extensions] defines the H-PCE Capability TLV 340 that is used in the OPEN message to advertise the H-PCE capability. 341 [RFC8231] defines the Stateful PCE Capability TLV used in the OPEN 342 message to indicate stateful support. The presence of both TLVs in 343 an OPEN message indicates the support for stateful H-PCE operations 344 as described in this document. 346 Further consideration may be made for optional procedures for 347 stateful communication coordination between PCEs, including 348 procedures to minimise computational loops. The procedures described 349 in [I-D.litkowski-pce-state-sync] facilitate stateful communication 350 between PCEs for various use-cases. The procedures and extensions as 351 described in Section 3 of [I-D.litkowski-pce-state-sync] are also 352 applicable to Child and Parent PCE communication. The 353 SPEAKER-IDENTITY-TLV (defined in [RFC8232]) is included in the LSP 354 object to identify the Ingress (PCC). The PLSP-ID used in the 355 forwarded PCRpt by the C-PCE to P-PCE is same as the original one 356 used by the PCC. 358 3.1. Passive Operations 360 Procedures as described in [RFC6805] are applied and where the 361 ingress C-PCE (Child PCE), triggers a path computation request for 362 the LER in the domain where the LSP originates, sends a request to 363 the P-PCE. The P-PCE selects a set of candidate domain paths based on 364 the domain topology and the state of the inter-domain links. It then 365 sends computation requests to the C-PCEs responsible for each of the 366 domains on the candidate domain paths. Each C-PCE computes a set of 367 candidate path segments across its domain and sends the results to 368 the P-PCE. The P-PCE uses this information to select path segments 369 and concatenate them to derive the optimal end-to-end inter-domain 370 path. The end-to-end path is then sent to the C-PCE that received 371 the initial path request, and this C-PCE passes the path on to the 372 PCC that issued the original request. 374 As per [RFC8231], PCC sends an LSP State Report carried on a PCRpt 375 message to the C-PCE, indicating the LSP's status. The C-PCE may 376 further propagate the State Report to the P-PCE. A local policy at 377 C-PCE may dictate which LSPs to be reported to the P-PCE. The PCRpt 378 message is sent from C-PCE to P-PCE. 380 State synchronization mechanism as described in [RFC8231] and 381 [RFC8232] are applicable to a PCEP session between C-PCE and P-PCE as 382 well. 384 We use the sample hierarchical domain topology example from [RFC6805] 385 as the reference topology for the entirety of this document. It is 386 shown in Figure 1. 387 ----------------------------------------------------------------- 388 | Domain 5 | 389 | ----- | 390 | |PCE 5| | 391 | ----- | 392 | | 393 | ---------------- ---------------- ---------------- | 394 | | Domain 1 | | Domain 2 | | Domain 3 | | 395 | | | | | | | | 396 | | ----- | | ----- | | ----- | | 397 | | |PCE 1| | | |PCE 2| | | |PCE 3| | | 398 | | ----- | | ----- | | ----- | | 399 | | | | | | | | 400 | | ----| |---- ----| |---- | | 401 | | |BN11+---+BN21| |BN23+---+BN31| | | 402 | | - ----| |---- ----| |---- - | | 403 | | |S| | | | | |D| | | 404 | | - ----| |---- ----| |---- - | | 405 | | |BN12+---+BN22| |BN24+---+BN32| | | 406 | | ----| |---- ----| |---- | | 407 | | | | | | | | 408 | | ---- | | | | ---- | | 409 | | |BN13| | | | | |BN33| | | 410 | -----------+---- ---------------- ----+----------- | 411 | \ / | 412 | \ ---------------- / | 413 | \ | | / | 414 | \ |---- ----| / | 415 | ----+BN41| |BN42+---- | 416 | |---- ----| | 417 | | | | 418 | | ----- | | 419 | | |PCE 4| | | 420 | | ----- | | 421 | | | | 422 | | Domain 4 | | 423 | ---------------- | 424 | | 425 ----------------------------------------------------------------- 427 Figure 1: Sample Hierarchical Domain Topology 429 Steps 1 to 11 are exactly as described in section 4.6.2 (Hierarchical 430 PCE End-to-End Path Computation Procedure) of [RFC6805], the 431 following additional steps are added for stateful PCE: 433 (A) The Ingress LSR initiates the setup of the LSP as per the path 434 and reports to the PCE1 the LSP status ("GOING-UP"). 436 (B) The PCE1 further reports the status of the LSP to the P-PCE 437 (PCE5). 439 (C) The Ingress LSR notifies the LSP state to PCE1 when the state is 440 "UP". 442 (D) The PCE1 further reports the status of the LSP to the P-PCE 443 (PCE5). 445 The Ingress LSR could trigger path re-optimization by sending the 446 path computation request as described in [RFC6805], at this time it 447 can include the LSP object in the PCReq message as described in 448 [RFC8231]. 450 3.2. Active Operations 452 [RFC8231] describes the case of active stateful PCE. The active PCE 453 functionality uses two specific PCEP messages: 455 o Update Request (PCUpd) 457 o State Report (PCRpt) 459 The first is sent by the PCE to a Path Computation Client (PCC) for 460 modifying LSP attributes. The PCC sends back a PCRpt to acknowledge 461 the requested operation or report any change in LSP's state. 463 As per [RFC8051], Delegation is an operation to grant a PCE, 464 temporary rights to modify a subset of LSP parameters on one or more 465 PCC's LSPs. The C-PCE may further choose to delegate to P-PCE based 466 on a local policy. The PCRpt message with "D" (delegate) flag is 467 sent from C-PCE to P-PCE. 469 To update an LSP, a PCE sends an LSP Update Request to the PCC using 470 a PCUpd message. For LSP delegated to the P-PCE via the child PCE, 471 the P-PCE can use the same PCUpd message to request change to the C- 472 PCE (the Ingress domain PCE), the PCE further propagates the update 473 request to the PCC. 475 The P-PCE uses the same mechanism described in Section 3.1 to compute 476 the end to end path using PCReq and PCRep messages. 478 For active operations, the following steps are required when 479 delegating the LSP, again using the reference architecture described 480 in Figure 1 (Sample Hierarchical Domain Topology). 482 (A) The Ingress LSR delegates the LSP to the PCE1 via PCRpt message 483 with D flag set. 485 (B) The PCE1 further delegates the LSP to the P-PCE (PCE5). 487 (C) Steps 4 to 10 of section 4.6.2 of [RFC6805] are executed to 488 determine the end to end path. 490 (D) The P-PCE (PCE5) sends the update request to the C-PCE (PCE1) 491 via PCUpd message. 493 (E) The PCE1 further updates the LSP to the Ingress LSR (PCC). 495 (F) The Ingress LSR initiates the setup of the LSP as per the path 496 and reports to the PCE1 the LSP status ("GOING-UP"). 498 (G) The PCE1 further reports the status of the LSP to the P-PCE 499 (PCE5). 501 (H) The Ingress LSR notifies the LSP state to PCE1 when the state is 502 "UP". 504 (I) The PCE1 further reports the status of the LSP to the P-PCE 505 (PCE5). 507 3.3. PCE Initiation of LSPs 509 [RFC8281] describes the setup, maintenance and teardown of PCE- 510 initiated LSPs under the stateful PCE model, without the need for 511 local configuration on the PCC, thus allowing for a dynamic network 512 that is centrally controlled and deployed. To instantiate or delete 513 an LSP, the PCE sends the Path Computation LSP Initiate Request 514 (PCInitiate) message to the PCC. In case of inter-domain LSP in 515 Hierarchical PCE architecture, the initiation operations can be 516 carried out at the P-PCE. In which case after P-PCE finishes the E2E 517 path computation, it can send the PCInitiate message to the C-PCE 518 (the Ingress domain PCE), the PCE further propagates the initiate 519 request to the PCC. 521 The following steps are performed, for PCE initiated operations, 522 again using the reference architecture described in Figure 1 (Sample 523 Hierarchical Domain Topology): 525 (A) The P-PCE (PCE5) is requested to initiate a LSP. Steps 4 to 10 526 of section 4.6.2 of [RFC6805] are executed to determine the end 527 to end path. 529 (B) The P-PCE (PCE5) sends the initiate request to the child PCE 530 (PCE1) via PCInitiate message. 532 (C) The PCE1 further propagates the initiate message to the Ingress 533 LSR (PCC). 535 (D) The Ingress LSR initiates the setup of the LSP as per the path 536 and reports to the PCE1 the LSP status ("GOING-UP"). 538 (E) The PCE1 further reports the status of the LSP to the P-PCE 539 (PCE5). 541 (F) The Ingress LSR notifies the LSP state to PCE1 when the state is 542 "UP". 544 (G) The PCE1 further reports the status of the LSP to the P-PCE 545 (PCE5). 547 The Ingress LSR (PCC) would generate the PLSP-ID for the LSP and 548 inform the C-PCE, which is propagated to the P-PCE. 550 3.3.1. Per Domain Stitched LSP 552 The Hierarchical PCE architecture as per [RFC6805] is primarily used 553 for E2E LSP. With PCE-Initiated capability, another mode of 554 operation is possible, where multiple intra-domain LSPs are initiated 555 in each domain which are further stitched to form an E2E LSP. The 556 P-PCE sends PCInitiate message to each C-PCE separately to initiate 557 individual LSP segments along the domain path. These individual per 558 domain LSP are stitched together by some mechanism, which is out of 559 scope of this document (Refer [I-D.dugeon-pce-stateful- 560 interdomain]). 562 The following steps are performed, for the Per Domain stitched LSP 563 operation, again using the reference architecture described in Figure 564 1 (Sample Hierarchical Domain Topology): 566 (A) The P-PCE (PCE5) is requested to initiate a LSP. Steps 4 to 10 567 of section 4.6.2 of [RFC6805] are executed to determine the end 568 to end path, which are broken into per-domain LSPs say - 570 o S-BN41 572 o BN41-BN33 573 o BN33-D 575 It should be noted that the P-PCE may use other mechanisms to 576 determine the suitable per-domain LSPs (apart from [RFC6805]). 578 For LSP (BN33-D) 580 (B) The P-PCE (PCE5) sends the initiate request to the child PCE 581 (PCE3) via PCInitiate message for LSP (BN33-D). 583 (C) The PCE3 further propagates the initiate message to BN33. 585 (D) BN33 initiates the setup of the LSP as per the path and reports 586 to the PCE3 the LSP status ("GOING-UP"). 588 (E) The PCE3 further reports the status of the LSP to the P-PCE 589 (PCE5). 591 (F) The node BN33 notifies the LSP state to PCE3 when the state is 592 "UP". 594 (G) The PCE3 further reports the status of the LSP to the P-PCE 595 (PCE5). 597 For LSP (BN41-BN33) 599 (H) The P-PCE (PCE5) sends the initiate request to the child PCE 600 (PCE4) via PCInitiate message for LSP (BN41-BN33). 602 (I) The PCE4 further propagates the initiate message to BN41. 604 (J) BN41 initiates the setup of the LSP as per the path and reports 605 to the PCE4 the LSP status ("GOING-UP"). 607 (K) The PCE4 further reports the status of the LSP to the P-PCE 608 (PCE5). 610 (L) The node BN41 notifies the LSP state to PCE4 when the state is 611 "UP". 613 (M) The PCE4 further reports the status of the LSP to the P-PCE 614 (PCE5). 616 For LSP (S-BN41) 618 (N) The P-PCE (PCE5) sends the initiate request to the child PCE 619 (PCE1) via PCInitiate message for LSP (S-BN41). 621 (O) The PCE1 further propagates the initiate message to node S. 623 (P) S initiates the setup of the LSP as per the path and reports to 624 the PCE1 the LSP status ("GOING-UP"). 626 (Q) The PCE1 further reports the status of the LSP to the P-PCE 627 (PCE5). 629 (R) The node S notifies the LSP state to PCE1 when the state is 630 "UP". 632 (S) The PCE1 further reports the status of the LSP to the P-PCE 633 (PCE5). 635 Additionally: 637 (T) Once P-PCE receives report of each per-domain LSP, it should use 638 suitable stitching mechanism, which is out of scope of this 639 document. In this step, P-PCE (PCE5) could also initiate an E2E 640 LSP (S-D) by sending the PCInitiate message to Ingress C-PCE 641 (PCE1). 643 Note that each per-domain LSP can be setup in parallel. Further, it 644 is also possible to stitch the per-domain LSP at the same time as the 645 per-domain LSPs are initiated. This option is defined in 646 [I-D.dugeon-pce-stateful-interdomain]. 648 4. Security Considerations 650 The security considerations listed in [RFC8231],[RFC6805] and 651 [RFC5440] apply to this document as well. As per [RFC6805], it is 652 expected that the parent PCE will require all child PCEs to use full 653 security when communicating with the parent. 655 Any multi-domain operation necessarily involves the exchange of 656 information across domain boundaries. This is bound to represent a 657 significant security and confidentiality risk especially when the 658 child domains are controlled by different commercial concerns. PCEP 659 allows individual PCEs to maintain confidentiality of their domain 660 path information using path-keys [RFC5520], and the hierarchical PCE 661 architecture is specifically designed to enable as much isolation of 662 domain topology and capabilities information as is possible. The LSP 663 state in the PCRpt message must continue to maintain the internal 664 domain confidentiality when required. 666 The security consideration for PCE-Initiated LSP as per [RFC8281] is 667 also applicable from P-PCE to C-PCE. 669 Thus securing the PCEP session (between the P-PCE and the C-PCE) 670 using the TCP Authentication Option (TCP-AO) [RFC5925] or Transport 671 Layer Security (TLS) [RFC8253] mechanisms are recommended. 673 5. Manageability Considerations 675 All manageability requirements and considerations listed in 676 [RFC5440], [RFC6805], [RFC8231], and [RFC8281] apply to Stateful H- 677 PCE defined in this document. In addition, requirements and 678 considerations listed in this section apply. 680 5.1. Control of Function and Policy 682 Support of the hierarchical procedure will be controlled by the 683 management organization responsible for each child PCE. The parent 684 PCE must only accept path computation requests from authorized child 685 PCEs. If a parent PCE receives report from an unauthorized child 686 PCE, the report should be dropped. All mechanism as described in 687 [RFC8231] and [RFC8281] continue to apply. 689 5.2. Information and Data Models 691 An implementation should allow the operator to view the stateful and 692 H-PCE capabilities advertised by each peer. The PCEP YANG module 693 [I-D.ietf-pce-pcep-yang] may be extended to include details for 694 stateful H-PCE deployment and operation, exact attributes to be 695 modeled is out of scope for this document. 697 5.3. Liveness Detection and Monitoring 699 Mechanisms defined in this document do not imply any new liveness 700 detection and monitoring requirements in addition to those already 701 listed in [RFC5440]. 703 5.4. Verify Correct Operations 705 Mechanisms defined in this document do not imply any new operation 706 verification requirements in addition to those already listed in 707 [RFC5440] and [RFC8231]. 709 5.5. Requirements On Other Protocols 711 Mechanisms defined in this document do not imply any new requirements 712 on other protocols. 714 5.6. Impact On Network Operations 716 Mechanisms defined in [RFC5440] and [RFC8231] also apply to PCEP 717 extensions defined in this document. 719 The stateful H-PCE technique brings the applicability of stateful PCE 720 as described in [RFC8051], for the LSP traversing multiple domains. 722 5.7. Error Handling between PCEs 724 Error types and notifications useful for correct PCEP operation may 725 be implemented for managing parent and child PCE interaction. PCEP 726 Error behavior propagation, notification and error criticality level, 727 are further defined in [I-D.ietf-pce-enhanced-errors]. 729 6. Other Considerations 731 6.1. Applicability to Inter-Layer Traffic Engineering 733 [RFC5623] describes a framework for applying the PCE-based 734 architecture to inter-layer (G)MPLS traffic engineering. The H-PCE 735 Stateful architecture with stateful P-PCE coordinating with the 736 stateful C-PCEs of higher and lower layer is shown in the figure 737 below. 739 +----------+ 740 | Parent | 741 /| PCE | 742 / +----------+ 743 / / Stateful 744 / / P-PCE 745 / / 746 / / 747 Stateful+-----+ / / 748 C-PCE | PCE |/ / 749 Hi | Hi | / 750 +-----+ / 751 +---+ +---+ / +---+ +---+ 752 + LSR +--+ LSR +........................+ LSR +--+ LSR + 753 + H1 + + H2 + / + H3 + + H4 + 754 +---+ +---+\ +-----+/ /+---+ +---+ 755 \ | PCE | / 756 \ | Lo | / 757 Stateful \ +-----+ / 758 C-PCE \ / 759 Lo \+---+ +---+/ 760 + LSR +--+ LSR + 761 + L1 + + L2 + 762 +---+ +---+ 764 Figure 2: Sample Inter-Layer Topology 766 All procedures described in Section 3 are applicable to inter-layer 767 (and therefore separate domains) path setup as well. 769 6.2. Scalability Considerations 771 It should be noted that if all the C-PCEs would report all the LSPs 772 in their domain, it could lead to scalability issues for the P-PCE. 773 Thus it is recommended to only report the LSPs which are involved in 774 H-PCE, i.e. the LSPs which are either delegated to the P-PCE or 775 initiated by the P-PCE. Scalability considerations for PCEP as per 776 [RFC8231] continue to apply for the PCEP session between child and 777 parent PCE. 779 6.3. Confidentiality 781 As described in section 4.2 of [RFC6805], information about the 782 content of child domains is not shared for both scaling and 783 confidentiality reasons. Along with the confidentiality during path 784 computation, the child PCE could also conceal the path information, a 785 C-PCE may replace a path segment with a path-key [RFC5520], 786 effectively hiding the content of a segment of a path. 788 7. IANA Considerations 790 There are no IANA considerations. 792 8. Acknowledgments 794 Thanks to Manuela Scarella, Haomian Zheng, Sergio Marmo, Stefano 795 Parodi, Giacomo Agostini, Jeff Tantsura, Rajan Rao, Adrian Farrel and 796 Haomian Zheng, for their reviews and suggestions. 798 9. References 800 9.1. Normative References 802 [RFC4655] Farrel, A., Vasseur, J., and J. Ash, "A Path Computation 803 Element (PCE)-Based Architecture", RFC 4655, 804 DOI 10.17487/RFC4655, August 2006, 805 . 807 [RFC5440] Vasseur, JP., Ed. and JL. Le Roux, Ed., "Path Computation 808 Element (PCE) Communication Protocol (PCEP)", RFC 5440, 809 DOI 10.17487/RFC5440, March 2009, 810 . 812 [RFC5520] Bradford, R., Ed., Vasseur, JP., and A. Farrel, 813 "Preserving Topology Confidentiality in Inter-Domain Path 814 Computation Using a Path-Key-Based Mechanism", RFC 5520, 815 DOI 10.17487/RFC5520, April 2009, 816 . 818 [RFC6805] King, D., Ed. and A. Farrel, Ed., "The Application of the 819 Path Computation Element Architecture to the Determination 820 of a Sequence of Domains in MPLS and GMPLS", RFC 6805, DOI 821 10.17487/RFC6805, November 2012, 822 . 824 [RFC8231] Crabbe, E., Minei, I., Medved, J., and R. Varga, "Path 825 Computation Element Communication Protocol (PCEP) 826 Extensions for Stateful PCE", RFC 8231, 827 DOI 10.17487/RFC8231, September 2017, 828 . 830 [RFC8281] Crabbe, E., Minei, I., Sivabalan, S., and R. Varga, "Path 831 Computation Element Communication Protocol (PCEP) 832 Extensions for PCE-Initiated LSP Setup in a Stateful PCE 833 Model", RFC 8281, DOI 10.17487/RFC8281, December 2017, 834 . 836 9.2. Informative References 838 [RFC3209] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V., 839 and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP 840 Tunnels", RFC 3209, DOI 10.17487/RFC3209, December 2001, 841 . 843 [RFC3473] Berger, L., Ed., "Generalized Multi-Protocol Label 844 Switching (GMPLS) Signaling Resource ReserVation Protocol- 845 Traffic Engineering (RSVP-TE) Extensions", RFC 3473, 846 DOI 10.17487/RFC3473, January 2003, 847 . 849 [RFC4726] Farrel, A., Vasseur, J., and A. Ayyangar, "A Framework for 850 Inter-Domain Multiprotocol Label Switching Traffic 851 Engineering", RFC 4726, DOI 10.17487/RFC4726, November 852 2006, . 854 [RFC5623] Oki, E., Takeda, T., Le Roux, JL., and A. Farrel, 855 "Framework for PCE-Based Inter-Layer MPLS and GMPLS 856 Traffic Engineering", RFC 5623, DOI 10.17487/RFC5623, 857 September 2009, . 859 [RFC5925] Touch, J., Mankin, A., and R. Bonica, "The TCP 860 Authentication Option", RFC 5925, DOI 10.17487/RFC5925, 861 June 2010, . 863 [RFC8051] Zhang, X., Ed. and I. Minei, Ed., "Applicability of a 864 Stateful Path Computation Element (PCE)", RFC 8051, 865 DOI 10.17487/RFC8051, January 2017, 866 . 868 [RFC8232] Crabbe, E., Minei, I., Medved, J., Varga, R., Zhang, X., 869 and D. Dhody, "Optimizations of Label Switched Path State 870 Synchronization Procedures for a Stateful PCE", RFC 8232, 871 DOI 10.17487/RFC8232, September 2017, 872 . 874 [RFC8253] Lopez, D., Gonzalez de Dios, O., Wu, Q., and D. Dhody, 875 "PCEPS: Usage of TLS to Provide a Secure Transport for the 876 Path Computation Element Communication Protocol (PCEP)", 877 RFC 8253, DOI 10.17487/RFC8253, October 2017, 878 . 880 [RFC8453] Ceccarelli, D., Ed. and Y. Lee, Ed., "Framework for 881 Abstraction and Control of TE Networks (ACTN)", RFC 8453, 882 DOI 10.17487/RFC8453, August 2018, 883 . 885 [I-D.ietf-pce-applicability-actn] 886 Dhody, D., Lee, Y., and D. Ceccarelli, "Applicability of 887 Path Computation Element (PCE) for Abstraction and 888 Control of TE Networks (ACTN)", draft-ietf-pce- 889 applicability-actn-12 (work in progress), May 2019. 891 [I-D.litkowski-pce-state-sync] 892 Litkowski, S., Sivabalan, S., and D. Dhody, "Inter 893 Stateful Path Computation Element communication 894 procedures", draft-litkowski-pce-state-sync-05 (work in 895 progress), March 2019. 897 [I-D.ietf-pce-hierarchy-extensions] 898 Zhang, F., Zhao, Q., Dios, O., Casellas, R., and D. King, 899 "Extensions to Path Computation Element Communication 900 Protocol (PCEP) for Hierarchical Path Computation Elements 901 (PCE)", draft-ietf-pce-hierarchy-extensions-11 (work in 902 progress), June 2019. 904 [I-D.ietf-pce-pcep-yang] 905 Dhody, D., Hardwick, J., Beeram, V., and j. 906 jefftant@gmail.com, "A YANG Data Model for Path 907 Computation Element Communications Protocol (PCEP)", 908 draft-ietf-pce-pcep-yang-11 (work in progress), 909 March 2019. 911 [I-D.dugeon-pce-stateful-interdomain] 912 Dugeon, O., Meuric, J., Lee, Y., Dhody, D., and D. 913 Ceccarelli, "PCEP Extension for Stateful Inter-Domain 914 Tunnels", draft-dugeon-pce-stateful-interdomain-02 (work 915 in progress), March 2019. 917 [I-D.ietf-pce-lsp-control-request] 918 Raghuram, A., Goddard, A., Yadlapalli, C., Karthik, J., 919 Sivabalan, S., Parker, J., and M. Negi, "Ability for a 920 stateful Path Computation Element (PCE) to request and 921 obtain control of a LSP", draft-ietf-pce-lsp-control- 922 request-04 (work in progress), June 2019. 924 [I-D.ietf-pce-enhanced-errors] 925 Pouyllau, et al., "Extensions to PCEP for Enhanced Errors" 926 , draft-ietf-pce-enhanced-errors-05 (work in progress), 927 February 2019. 929 Contributors 931 Avantika 932 ECI Telecom 933 India 935 EMail: avantika.srm@gmail.com 937 Xian Zhang 938 Huawei Technologies 939 Bantian, Longgang District 940 Shenzhen, Guangdong 518129 941 P.R.China 943 EMail: zhang.xian@huawei.com 945 Udayasree Palle 947 EMail: udayasreereddy@gmail.com 949 Authors' Addresses 951 Dhruv Dhody 952 Huawei Technologies 953 Divyashree Techno Park, Whitefield 954 Bangalore, Karnataka 560066 955 India 957 EMail: dhruv.ietf@gmail.com 959 Young Lee 960 Futurewei 961 5340 Legacy Drive, Building 3 962 Plano, TX 75023 963 USA 965 EMail: younglee.tx@gmail.com 967 Daniele Ceccarelli 968 Ericsson 969 Torshamnsgatan,48 970 Stockholm 971 Sweden 973 EMail: daniele.ceccarelli@ericsson.com 974 Jongyoon Shin 975 SK Telecom 976 6 Hwangsaeul-ro, 258 beon-gil, Bundang-gu, Seongnam-si, 977 Gyeonggi-do 463-784 978 Republic of Korea 980 EMail: jongyoon.shin@sk.com 982 Daniel King 983 Lancaster University 984 UK 986 EMail: d.king@lancaster.ac.uk 988 Oscar Gonzalez de Dios 989 Telefonica I+D 990 Don Ramon de la Cruz 82-84 991 Madrid, 28045 992 Spain 994 Phone: +34913128832 995 Email: oscar.gonzalezdedios@telefonica.com