idnits 2.17.1 draft-ietf-pce-stateful-hpce-15.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 (October 21, 2019) is 1620 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- ** Obsolete normative reference: 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 (-13) exists of draft-ietf-pce-enhanced-errors-06 Summary: 1 error (**), 0 flaws (~~), 5 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 Huawei Technologies 4 Intended status: Informational Y. Lee 5 Expires: April 23, 2020 SKKU 6 D. Ceccarelli 7 Ericsson 8 J. Shin 9 SK Telecom 10 D. King 11 Lancaster University 12 October 21, 2019 14 Hierarchical Stateful Path Computation Element (PCE) 15 draft-ietf-pce-stateful-hpce-15 17 Abstract 19 A Stateful Path Computation Element (PCE) maintains information on 20 the current network state received from the Path Computation Clients 21 (PCCs), including: computed Label Switched Path (LSPs), reserved 22 resources within the network, and pending path computation requests. 23 This information may then be considered when computing the path for a 24 new traffic-engineered LSP or for any associated/dependent LSPs. 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 April 23, 2020. 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 . . . . . . . . . . . . . . . . 17 91 5.5. Requirements On Other Protocols . . . . . . . . . . . . . 17 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 . . . . . 18 97 6.2. Scalability Considerations . . . . . . . . . . . . . . . . 18 98 6.3. Confidentiality . . . . . . . . . . . . . . . . . . . . . 19 99 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 19 100 8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 19 101 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 19 102 9.1. Normative References . . . . . . . . . . . . . . . . . . . 19 103 9.2. Informative References . . . . . . . . . . . . . . . . . . 20 104 Contributors . . . . . . . . . . . . . . . . . . . . . . . . . . . 22 105 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 23 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 constrained paths for 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 The C-PCE is used to compute the intra-domain path based on its 152 domain topology information. 154 This document presents general considerations for stateful PCEs, and 155 not Stateless PCEs, in the hierarchical PCE architecture. It focuses 156 on the behavior changes and additions to the existing stateful PCE 157 mechanisms (including PCE-initiated LSP setup and active stateful PCE 158 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 end-to-end inter-domain path computation and setup is described 193 in [RFC6805]. Additionally, a per-domain stitched LSP model is also 194 applicable in a P-PCE initiation model. Section 3.1, Section 3.2, and 195 Section 3.3 describe the end-to-end Contiguous LSP setup, whereas 196 Section 3.3.1 describes 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 plays 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 that the VN 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 VN provisioning, the MDSC 217 decomposes 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 options for inter-domain RSVP-TE are identified 232 in [RFC4726]. Contiguous LSPs are achieved using the procedures of 233 [RFC3209] and [RFC3473] to create a single end-to-end LSP that spans 234 all domains. [RFC6805] describes the technique to establish the 235 optimum path when the sequence of domains is not known in advance. 237 It shows how the PCE architecture can be extended to allow the 238 optimum sequence of domains to be selected, and the optimum 239 end-to-end path to be derived. 241 A stateful P-PCE has to be aware of the inter-domain LSPs for it to 242 consider them during path computation. For instance when a domain 243 diverse path is required from another LSP, the P-PCE needs to be 244 aware of the LSP. This is the Passive Stateful P-PCE as described in 245 Section 3.1. Additionally, the inter-domain LSP could be delegated to 246 the P-PCE, so that P-PCE could trigger an update via a PCUpd message. 247 The update could be triggered on receipt of the PCRpt message that 248 indicates a status change of this LSP or some other LSP. The other 249 LSP could be an associated LSP (such as protection 250 [I-D.ietf-pce-stateful-path-protection]) or an unrelated LSP whose 251 resource change leads to re-optimization at the P-PCE. This is the 252 Active Stateful Operation as described in Section 3.2. Further, the 253 P-PCE could be instructed to create an inter-domain LSP on its own 254 using the PCInitiate message for an E2E contiguous LSP. The P-PCE 255 would send the PCInitiate message to the Ingress domain C-PCE, which 256 would further instruct the Ingress PCC. 258 In this document, for the Contiguous LSP, the above interactions are 259 only between the ingress domain C-PCE and the P-PCE. The use of 260 stateful operations for an inter-domain LSP between the 261 transit/egress domain C-PCEs and the P-PCE is out of scope of this 262 document. 264 1.2.3. Applicability of a Stateful P-PCE 266 [RFC8051] describes general considerations for a stateful PCE 267 deployment and examines its applicability and benefits, as well as 268 its challenges and limitations, through a number of use cases. These 269 are also applicable to the stateful P-PCE when used for the inter- 270 domain LSP path computation and setup. It should be noted that though 271 the stateful P-PCE has limited direct visibility inside the child 272 domain, it could still trigger re-optimization with the help of child 273 PCEs based on LSP state changes, abstract topology changes, or some 274 other external factors. 276 The C-PCE would delegate control of the inter-domain LSP to the P-PCE 277 so that the P-PCE can make changes to it. Note that, if the C-PCE 278 becomes aware of a topology change that is hidden from the P-PCE, it 279 could take back the delegation from the P-PCE to act on it itself. 280 Similarly, a P-PCE could also request delegation if it needs to make 281 a change to the LSP (refer to [I-D.ietf-pce-lsp-control-request]). 283 2. Terminology 284 The terminology is as per [RFC4655], [RFC5440], [RFC6805], [RFC8051], 285 [RFC8231], and [RFC8281]. 287 Some key terms are listed below for easy reference. 289 ACTN: Abstraction and Control of Traffic Engineering Networks 291 CNC: Customer Network Controller 293 C-PCE: Child Path Computation Element 295 H-PCE: Hierarchical Path Computation Element 297 IGP: Interior Gateway Protocol 299 LSP: Label Switched Path 301 LSP-DB: Label Switched Path Database 303 LSR: Label Switching Router 305 MDSC: Multi-Domain Service Coordinator 307 PCC: Path Computation Client 309 PCE: Path Computation Element 311 PCEP: Path Computation Element communication Protocol 313 PNC: Provisioning Network Controller 315 P-PCE: Parent Path Computation Element 317 TED: Traffic Engineering Database 319 VN: Virtual Network 321 2.1. Requirement Language 323 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 324 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 325 "OPTIONAL" in this document are to be interpreted as described in BCP 326 14 [RFC2119] [RFC8174] when, and only when, they appear in all 327 capitals, as shown here. 329 3. Hierarchical Stateful PCE 331 As described in [RFC6805], in the hierarchical PCE architecture a 332 P-PCE maintains a domain topology map that contains the child domains 333 (seen as vertices in the topology) and their interconnections (links 334 in the topology). Usually, the P-PCE has no information about the 335 content of the child domains. Each child domain has at least one PCE 336 capable of computing paths across the domain. These PCEs are known 337 as Child PCEs (C-PCEs) [RFC6805] and have a direct relationship with 338 the P-PCE. The P-PCE builds the domain topology map either via 339 direct configuration or from learned information received from each 340 C-PCE. The network policy could be be applied while building the 341 domain topology map. This has been described in detail in [RFC6805]. 343 Note that, in the scope of this document, both the C-PCEs and the P- 344 PCE are stateful in nature. 346 [RFC8231] specifies new functions to support a stateful PCE. It also 347 specifies that a function can be initiated either from a PCC towards 348 a PCE (C-E) or from a PCE towards a PCC (E-C). 350 This document extends these functions to support H-PCE Architecture 351 from a C-PCE towards P-PCE (EC-EP) or from a P-PCE towards C-PCE 352 (EP-EC). All PCE types herein (EC-EP and EP-EC) are assumed to be 353 "Stateful PCE". 355 A number of interactions are expected in the Hierarchical Stateful 356 PCE architecture. These include: 358 LSP State Report (EC-EP): a child stateful PCE sends an LSP state 359 report to a Parent Stateful PCE to indicate the state of a LSP. 361 LSP State Synchronization (EC-EP): after the session between the 362 Child and Parent stateful PCEs is initialized, the P-PCE must 363 learn the state of C-PCE's TE LSPs. 365 LSP Control Delegation (EC-EP,EP-EC): a C-PCE grants to the P-PCE 366 the right to update LSP attributes on one or more LSPs; the C-PCE 367 may withdraw the delegation or the P-PCE may give up the 368 delegation at any time. 370 LSP Update Request (EP-EC): a stateful P-PCE requests modification 371 of attributes on a C-PCE's TE LSP. 373 PCE LSP Initiation Request (EP-EC): a stateful P-PCE requests C-PCE 374 to initiate a TE LSP. 376 Note that this hierarchy is recursive, so a Label Switching Router 377 (LSR), as a PCC, could delegate control to a PCE, which may in turn 378 delegate to its parent, which may further delegate to its parent (if 379 it exists). Similarly, update operations can also be applied 380 recursively. 382 [I-D.ietf-pce-hierarchy-extensions] defines the H-PCE Capability TLV 383 that is used in the Open message to advertise the H-PCE capability. 384 [RFC8231] defines the Stateful PCE Capability TLV used in the Open 385 message to indicate stateful support. To indicates the support for 386 stateful H-PCE operations described in this document, a PCEP speaker 387 MUST include both TLVs in an Open message. It is RECOMMENDED that any 388 implementation that supports stateful operations [RFC8231] and H-PCE 389 [I-D.ietf-pce-hierarchy-extensions] would also implements the 390 stateful H-PCE operations as described in this document. 392 Further consideration may be made for optional procedures for 393 stateful communication coordination between PCEs, including 394 procedures to minimize computational loops. The procedures described 395 in [I-D.litkowski-pce-state-sync] facilitate stateful communication 396 between PCEs for various use cases. The procedures and extensions as 397 described in Section 3 of [I-D.litkowski-pce-state-sync] are also 398 applicable to Child and Parent PCE communication. The 399 SPEAKER-IDENTITY-TLV (defined in [RFC8232]) is included in the LSP 400 object to identify the Ingress (PCC). The PLSP-ID (PCEP-specific 401 identifier for the LSP, as per [RFC8231]) used in the forwarded PCRpt 402 by the C-PCE to P-PCE is same as the original one used by the PCC. 404 3.1. Passive Operations 406 Procedures as described in [RFC6805] are applied, where the ingress 407 PCC triggers a path computation request for the destination towards 408 the C-PCE in the domain where the LSP originates. The C-PCE further 409 forwards the request to the P-PCE. The P-PCE selects a set of 410 candidate domain paths based on the domain topology and the state of 411 the inter-domain links. It then sends computation requests to the 412 C-PCEs responsible for each of the domains on the candidate domain 413 paths. Each C-PCE computes a set of candidate path segments across 414 its domain and sends the results to the P-PCE. The P-PCE uses this 415 information to select path segments and concatenate them to derive 416 the optimal end-to-end inter-domain path. The end-to-end path is 417 then sent to the C-PCE that received the initial path request, and 418 this C-PCE passes the path on to the PCC that issued the original 419 request. 421 As per [RFC8231], PCC sends an LSP State Report carried on a PCRpt 422 message to the C-PCE, indicating the LSP's status. The C-PCE may 423 further propagate the State Report to the P-PCE. A local policy at 424 C-PCE may dictate which LSPs are reported to the P-PCE. The PCRpt 425 message is sent from C-PCE to P-PCE. 427 State synchronization mechanisms as described in [RFC8231] and 428 [RFC8232] are applicable to a PCEP session between C-PCE and P-PCE as 429 well. 431 We use the hierarchical domain topology example from [RFC6805] as the 432 reference topology for the entirety of this document. It is shown in 433 Figure 1. 435 ----------------------------------------------------------------- 436 | Domain 5 | 437 | ----- | 438 | |PCE 5| | 439 | ----- | 440 | | 441 | ---------------- ---------------- ---------------- | 442 | | Domain 1 | | Domain 2 | | Domain 3 | | 443 | | | | | | | | 444 | | ----- | | ----- | | ----- | | 445 | | |PCE 1| | | |PCE 2| | | |PCE 3| | | 446 | | ----- | | ----- | | ----- | | 447 | | | | | | | | 448 | | ----| |---- ----| |---- | | 449 | | |BN11+---+BN21| |BN23+---+BN31| | | 450 | | - ----| |---- ----| |---- - | | 451 | | |S| | | | | |D| | | 452 | | - ----| |---- ----| |---- - | | 453 | | |BN12+---+BN22| |BN24+---+BN32| | | 454 | | ----| |---- ----| |---- | | 455 | | | | | | | | 456 | | ---- | | | | ---- | | 457 | | |BN13| | | | | |BN33| | | 458 | -----------+---- ---------------- ----+----------- | 459 | \ / | 460 | \ ---------------- / | 461 | \ | | / | 462 | \ |---- ----| / | 463 | ----+BN41| |BN42+---- | 464 | |---- ----| | 465 | | | | 466 | | ----- | | 467 | | |PCE 4| | | 468 | | ----- | | 469 | | | | 470 | | Domain 4 | | 471 | ---------------- | 472 | | 473 ----------------------------------------------------------------- 474 Figure 1: Hierarchical Domain Topology Example 476 Steps 1 to 11 are exactly as described in section 4.6.2 of [RFC6805] 477 (Hierarchical PCE End-to-End Path Computation Procedure), the 478 following additional steps are added for stateful PCE, to be executed 479 at the end: 481 (A) The Ingress LSR initiates the setup of the LSP as per the path 482 and reports to the PCE1 the LSP status ("GOING-UP"). 484 (B) The PCE1 further reports the status of the LSP to the P-PCE 485 (PCE5). 487 (C) The Ingress LSR notifies the LSP state to PCE1 when the state is 488 "UP". 490 (D) The PCE1 further reports the status of the LSP to the P-PCE 491 (PCE5). 493 The Ingress LSR could trigger path re-optimization by sending the 494 path computation request as described in [RFC6805], at this time it 495 can include the LSP object in the PCReq message as described in 496 [RFC8231]. 498 3.2. Active Operations 500 [RFC8231] describes the case of active stateful PCE. The active PCE 501 functionality uses two specific PCEP messages: 503 o Update Request (PCUpd) 505 o State Report (PCRpt) 507 The first is sent by the PCE to a PCC for modifying LSP attributes. 508 The PCC sends back a PCRpt to acknowledge the requested operation or 509 report any change in LSP's state. 511 As per [RFC8051], Delegation is an operation to grant a PCE temporary 512 rights to modify a subset of LSP parameters on one or more PCC's 513 LSPs. The C-PCE may further choose to delegate to its P-PCE based on 514 a local policy. The PCRpt message with the "D" (delegate) flag is 515 sent from C-PCE to P-PCE. 517 To update an LSP, a PCE sends an LSP Update Request to the PCC using 518 a PCUpd message. For an LSP delegated to a P-PCE via the C-PCE; the 519 P-PCE can use the same PCUpd message to request a change to the C-PCE 520 (the Ingress domain PCE). The C-PCE further propagates the update 521 request to the PCC. 523 The P-PCE uses the same mechanism described in Section 3.1 to compute 524 the end to end path using PCReq and PCRep messages. 526 For active operations, the following steps are required when 527 delegating the LSP, again using the reference architecture described 528 in Figure 1 (Hierarchical Domain Topology Example). 530 (A) The Ingress LSR delegates the LSP to the PCE1 via PCRpt message 531 with D flag set. 533 (B) The PCE1 further delegates the LSP to the P-PCE (PCE5). 535 (C) Steps 4 to 10 of section 4.6.2 of [RFC6805] are executed at 536 P-PCE (PCE5) to determine the end to end path. 538 (D) The P-PCE (PCE5) sends the update request to the C-PCE (PCE1) 539 via PCUpd message. 541 (E) The PCE1 further updates the LSP to the Ingress LSR (PCC). 543 (F) The Ingress LSR initiates the setup of the LSP as per the path 544 and reports to the PCE1 the LSP status ("GOING-UP"). 546 (G) The PCE1 further reports the status of the LSP to the P-PCE 547 (PCE5). 549 (H) The Ingress LSR notifies the LSP state to PCE1 when the state is 550 "UP". 552 (I) The PCE1 further reports the status of the LSP to the P-PCE 553 (PCE5). 555 3.3. PCE Initiation of LSPs 557 [RFC8281] describes the setup, maintenance and teardown of PCE- 558 initiated LSPs under the stateful PCE model, without the need for 559 local configuration on the PCC, thus allowing for a dynamic network 560 that is centrally controlled and deployed. To instantiate or delete 561 an LSP, the PCE sends the Path Computation LSP Initiate Request 562 (PCInitiate) message to the PCC. In case of an inter-domain LSP in 563 Hierarchical PCE architecture, the initiation operations can be 564 carried out at the P-PCE. In which case after the P-PCE finishes the 565 E2E path computation, it can send the PCInitiate message to the C-PCE 566 (the Ingress domain PCE), the C-PCE further propagates the initiate 567 request to the PCC. 569 The following steps are performed for PCE-initiated operations, again 570 using the reference architecture described in Figure 1 (Hierarchical 571 Domain Topology Example): 573 (A) The P-PCE (PCE5) is requested to initiate a LSP. Steps 4 to 10 574 of section 4.6.2 of [RFC6805] are executed to determine the end 575 to end path. 577 (B) The P-PCE (PCE5) sends the initiate request to the child PCE 578 (PCE1) via PCInitiate message. 580 (C) The PCE1 further propagates the initiate message to the Ingress 581 LSR (PCC). 583 (D) The Ingress LSR initiates the setup of the LSP as per the path 584 and reports to the PCE1 the LSP status ("GOING-UP"). 586 (E) The PCE1 further reports the status of the LSP to the P-PCE 587 (PCE5). 589 (F) The Ingress LSR notifies the LSP state to PCE1 when the state is 590 "UP". 592 (G) The PCE1 further reports the status of the LSP to the P-PCE 593 (PCE5). 595 The Ingress LSR (PCC) would generate the PLSP-ID for the LSP and 596 inform the C-PCE, which is propagated to the P-PCE. 598 3.3.1. Per-Domain Stitched LSP 600 The Hierarchical PCE architecture as per [RFC6805] is primarily used 601 for E2E LSP. With PCE-Initiated capability, another mode of 602 operation is possible, where multiple intra-domain LSPs are initiated 603 in each domain, which are further stitched to form an E2E LSP. The 604 P-PCE sends PCInitiate message to each C-PCE separately to initiate 605 individual LSP segments along the domain path. These individual Per- 606 Domain LSP are stitched together by some mechanism, which is out of 607 scope of this document (Refer [I-D.dugeon-pce-stateful- 608 interdomain]). 610 The following steps are performed for the Per-Domain stitched LSP 611 operation, again using the reference architecture described in Figure 612 1 (Hierarchical Domain Topology Example): 614 (A) The P-PCE (PCE5) is requested to initiate a LSP. Steps 4 to 10 615 of section 4.6.2 of [RFC6805] are executed to determine the end 616 to end path, which are broken into per-domain LSPs say - 618 o S-BN41 620 o BN41-BN33 622 o BN33-D 624 It should be noted that the P-PCE may use other mechanisms to 625 determine the suitable per-domain LSPs (apart from [RFC6805]). 627 For LSP (BN33-D) 629 (B) The P-PCE (PCE5) sends the initiate request to the child PCE 630 (PCE3) via PCInitiate message for LSP (BN33-D). 632 (C) The PCE3 further propagates the initiate message to BN33. 634 (D) BN33 initiates the setup of the LSP as per the path and reports 635 to the PCE3 the LSP status ("GOING-UP"). 637 (E) The PCE3 further reports the status of the LSP to the P-PCE 638 (PCE5). 640 (F) The node BN33 notifies the LSP state to PCE3 when the state is 641 "UP". 643 (G) The PCE3 further reports the status of the LSP to the P-PCE 644 (PCE5). 646 For LSP (BN41-BN33) 648 (H) The P-PCE (PCE5) sends the initiate request to the child PCE 649 (PCE4) via PCInitiate message for LSP (BN41-BN33). 651 (I) The PCE4 further propagates the initiate message to BN41. 653 (J) BN41 initiates the setup of the LSP as per the path and reports 654 to the PCE4 the LSP status ("GOING-UP"). 656 (K) The PCE4 further reports the status of the LSP to the P-PCE 657 (PCE5). 659 (L) The node BN41 notifies the LSP state to PCE4 when the state is 660 "UP". 662 (M) The PCE4 further reports the status of the LSP to the P-PCE 663 (PCE5). 665 For LSP (S-BN41) 667 (N) The P-PCE (PCE5) sends the initiate request to the child PCE 668 (PCE1) via PCInitiate message for LSP (S-BN41). 670 (O) The PCE1 further propagates the initiate message to node S. 672 (P) S initiates the setup of the LSP as per the path and reports to 673 the PCE1 the LSP status ("GOING-UP"). 675 (Q) The PCE1 further reports the status of the LSP to the P-PCE 676 (PCE5). 678 (R) The node S notifies the LSP state to PCE1 when the state is 679 "UP". 681 (S) The PCE1 further reports the status of the LSP to the P-PCE 682 (PCE5). 684 Additionally: 686 (T) Once P-PCE receives report of each per-domain LSP, it should use 687 suitable stitching mechanism, which is out of scope of this 688 document. In this step, P-PCE (PCE5) could also initiate an E2E 689 LSP (S-D) by sending the PCInitiate message to Ingress C-PCE 690 (PCE1). 692 Note that each per-domain LSP can be set up in parallel. Further, it 693 is also possible to stitch the per-domain LSP at the same time as the 694 per-domain LSPs are initiated. This option is defined in 695 [I-D.dugeon-pce-stateful-interdomain]. 697 4. Security Considerations 699 The security considerations listed in [RFC8231],[RFC6805] and 700 [RFC5440] apply to this document as well. As per [RFC6805], it is 701 expected that the parent PCE will require all child PCEs to use full 702 security (i.e. the highest security mechanism available for PCEP) 703 when communicating with the parent. 705 Any multi-domain operation necessarily involves the exchange of 706 information across domain boundaries. This is bound to represent a 707 significant security and confidentiality risk especially when the 708 child domains are controlled by different commercial concerns. PCEP 709 allows individual PCEs to maintain confidentiality of their domain 710 path information using path-keys [RFC5520], and the hierarchical PCE 711 architecture is specifically designed to enable as much isolation of 712 domain topology and capabilities information as is possible. The LSP 713 state in the PCRpt message must continue to maintain the internal 714 domain confidentiality when required. 716 The security consideration for PCE-Initiated LSP as per [RFC8281] is 717 also applicable from P-PCE to C-PCE. 719 Further, section 6.3 describes the use of path-key [RFC5520] for 720 confidentiality between C-PCE and P-PCE. 722 Thus it is RECOMMENDED to secure the PCEP session (between the P-PCE 723 and the C-PCE) using Transport Layer Security (TLS) [RFC8446] (per 724 the recommendations and best current practices in BCP 195 [RFC7525]) 725 and/or TCP Authentication Option (TCP-AO) [RFC5925]. The guidance for 726 implementing PCEP with TLS can be found in [RFC8253]. 728 In case of TLS, due care needs to be taken while exposing the 729 parameters of the X.509 certificate, such as subjectAltName:otherName 730 which is set to Speaker Entity Identifier [RFC8232] as per [RFC8253], 731 to ensure uniqueness and avoid any mismatch. 733 5. Manageability Considerations 735 All manageability requirements and considerations listed in 736 [RFC5440], [RFC6805], [RFC8231], and [RFC8281] apply to Stateful H- 737 PCE defined in this document. In addition, requirements and 738 considerations listed in this section apply. 740 5.1. Control of Function and Policy 742 Support of the hierarchical procedure will be controlled by the 743 management organization responsible for each child PCE. The parent 744 PCE must only accept path computation requests from authorized child 745 PCEs. If a parent PCE receives a report from an unauthorized child 746 PCE, the report should be dropped. All mechanisms as described in 747 [RFC8231] and [RFC8281] continue to apply. 749 5.2. Information and Data Models 751 An implementation should allow the operator to view the stateful and 752 H-PCE capabilities advertised by each peer. The "ietf-pcep" PCEP YANG 753 module is specified in [I-D.ietf-pce-pcep-yang]. This YANG module 754 will be required to be augmented to also include details for stateful 755 H-PCE deployment and operation. The exact model and attributes are 756 out of scope for this document. 758 5.3. Liveness Detection and Monitoring 759 Mechanisms defined in this document do not imply any new liveness 760 detection and monitoring requirements in addition to those already 761 listed in [RFC5440]. 763 5.4. Verify Correct Operations 765 Mechanisms defined in this document do not imply any new operation 766 verification requirements in addition to those already listed in 767 [RFC5440] and [RFC8231]. 769 5.5. Requirements On Other Protocols 771 Mechanisms defined in this document do not imply any new requirements 772 on other protocols. 774 5.6. Impact On Network Operations 776 Mechanisms defined in [RFC5440] and [RFC8231] also apply to PCEP 777 extensions defined in this document. 779 The stateful H-PCE technique brings the applicability of stateful PCE 780 as described in [RFC8051], for the LSP traversing multiple domains. 782 As described in Section 3, a PCEP speaker includes both the H-PCE 783 Capability TLV [I-D.ietf-pce-hierarchy-extensions] and Stateful PCE 784 Capability TLV [RFC8231] to indicate support for Stateful H-PCE. Note 785 that there is a possibility of a PCEP speaker that does not support 786 the Stateful H-PCE feature but does provide support for Stateful PCE 787 [RFC8231] and H-PCE [I-D.ietf-pce-hierarchy-extensions] features. 788 This PCEP speaker will also include both the TLVs and in this case a 789 PCEP peer could falsely assume that the stateful H-PCE feature is 790 also supported. On further PCEP message exchange, the stateful 791 messages will not get further propagated (as described in this 792 document) and a stateful H-PCE based 'parent' control of the LSP will 793 not happen. A PCEP peer should be prepared for this eventuality as a 794 part of normal procedures. 796 5.7. Error Handling between PCEs 798 Apart from the basic error handling described in this document, an 799 implementation could also use the enhanced error and notification 800 mechanism for stateful H-PCE operations as per [I-D.ietf-pce- 801 enhanced-errors]. Enhanced features such as error behavior 802 propagation, notification and error criticality level, are further 803 defined in [I-D.ietf-pce-enhanced-errors]. 805 6. Other Considerations 806 6.1. Applicability to Inter-Layer Traffic Engineering 808 [RFC5623] describes a framework for applying the PCE-based 809 architecture to inter-layer (G)MPLS traffic engineering. The H-PCE 810 Stateful architecture with stateful P-PCE coordinating with the 811 stateful C-PCEs of higher and lower layer is shown in the figure 812 below. 814 +----------+ 815 | Parent | 816 /| PCE | 817 / +----------+ 818 / / Stateful 819 / / P-PCE 820 / / 821 / / 822 Stateful+-----+ / / 823 C-PCE | PCE |/ / 824 Hi | Hi | / 825 +-----+ / 826 +---+ +---+ / +---+ +---+ 827 + LSR +--+ LSR +........................+ LSR +--+ LSR + 828 + H1 + + H2 + / + H3 + + H4 + 829 +---+ +---+\ +-----+/ /+---+ +---+ 830 \ | PCE | / 831 \ | Lo | / 832 Stateful \ +-----+ / 833 C-PCE \ / 834 Lo \+---+ +---+/ 835 + LSR +--+ LSR + 836 + L1 + + L2 + 837 +---+ +---+ 839 Figure 2: Sample Inter-Layer Topology 841 All procedures described in Section 3 are applicable to inter-layer 842 (and therefore separate domains) path setup as well. 844 6.2. Scalability Considerations 846 It should be noted that if all the C-PCEs would report all the LSPs 847 in their domain, it could lead to scalability issues for the P-PCE. 848 Thus it is recommended to only report the LSPs which are involved in 849 H-PCE, i.e. the LSPs which are either delegated to the P-PCE or 850 initiated by the P-PCE. Scalability considerations for PCEP as per 851 [RFC8231] continue to apply for the PCEP session between child and 852 parent PCE. 854 6.3. Confidentiality 856 As described in section 4.2 of [RFC6805], information about the 857 content of child domains is not shared for both scaling and 858 confidentiality reasons. The child PCE could also conceal the path 859 information during path computation. A C-PCE may replace a path 860 segment with a path-key [RFC5520], effectively hiding the content of 861 a segment of a path. 863 7. IANA Considerations 865 There are no IANA considerations. 867 8. Acknowledgments 869 Thanks to Manuela Scarella, Haomian Zheng, Sergio Marmo, Stefano 870 Parodi, Giacomo Agostini, Jeff Tantsura, Rajan Rao, Adrian Farrel and 871 Haomian Zheng, for their reviews and suggestions. 873 Thanks to Tal Mazrahi for the RTGDIR review, Paul Kyzivat for the 874 GENART review, and Stephen Farrell for SECDIR review. 876 Thanks to Barry Leiba, Martin Vigoureux, Benjamin Kaduk, and Roman 877 Danyliw for IESG review. 879 9. References 881 9.1. Normative References 883 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 884 Requirement Levels", BCP 14, RFC 2119, DOI 885 10.17487/RFC2119, March 1997, 886 . 888 [RFC4655] Farrel, A., Vasseur, J., and J. Ash, "A Path Computation 889 Element (PCE)-Based Architecture", RFC 4655, DOI 890 10.17487/RFC4655, August 2006, 891 . 893 [RFC5440] Vasseur, JP., Ed. and JL. Le Roux, Ed., "Path Computation 894 Element (PCE) Communication Protocol (PCEP)", RFC 5440, 895 DOI 10.17487/RFC5440, March 2009, 896 . 898 [RFC5520] Bradford, R., Ed., Vasseur, JP., and A. Farrel, 899 "Preserving Topology Confidentiality in Inter-Domain Path 900 Computation Using a Path-Key-Based Mechanism", RFC 5520, 901 DOI 10.17487/RFC5520, April 2009, 902 . 904 [RFC5925] Touch, J., Mankin, A., and R. Bonica, "The TCP 905 Authentication Option", RFC 5925, DOI 10.17487/RFC5925, 906 June 2010, . 908 [RFC6805] King, D., Ed. and A. Farrel, Ed., "The Application of the 909 Path Computation Element Architecture to the Determination 910 of a Sequence of Domains in MPLS and GMPLS", RFC 6805, DOI 911 10.17487/RFC6805, November 2012, 912 . 914 [RFC7525] Sheffer, Y., Holz, R., and P. Saint-Andre, 915 "Recommendations for Secure Use of Transport Layer 916 Security (TLS) and Datagram Transport Layer Security 917 (DTLS)", BCP 195, RFC 7525, DOI 10.17487/RFC7525, May 918 2015, . 920 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 921 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 922 May 2017, . 924 [RFC8231] Crabbe, E., Minei, I., Medved, J., and R. Varga, "Path 925 Computation Element Communication Protocol (PCEP) 926 Extensions for Stateful PCE", RFC 8231, 927 DOI 10.17487/RFC8231, September 2017, 928 . 930 [RFC8253] Lopez, D., Gonzalez de Dios, O., Wu, Q., and D. Dhody, 931 "PCEPS: Usage of TLS to Provide a Secure Transport for the 932 Path Computation Element Communication Protocol (PCEP)", 933 RFC 8253, DOI 10.17487/RFC8253, October 2017, 934 . 936 [RFC8281] Crabbe, E., Minei, I., Sivabalan, S., and R. Varga, "Path 937 Computation Element Communication Protocol (PCEP) 938 Extensions for PCE-Initiated LSP Setup in a Stateful PCE 939 Model", RFC 8281, DOI 10.17487/RFC8281, December 2017, 940 . 942 [RFC8446] Rescorla, E., "The Transport Layer Security (TLS) 943 Protocol Version 1.3", RFC 8446, DOI 10.17487/RFC8446, 944 August 2018, . 946 9.2. Informative References 948 [RFC3209] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V., 949 and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP 950 Tunnels", RFC 3209, DOI 10.17487/RFC3209, December 2001, 951 . 953 [RFC3473] Berger, L., Ed., "Generalized Multi-Protocol Label 954 Switching (GMPLS) Signaling Resource ReserVation Protocol- 955 Traffic Engineering (RSVP-TE) Extensions", RFC 3473, 956 DOI 10.17487/RFC3473, January 2003, 957 . 959 [RFC4726] Farrel, A., Vasseur, J., and A. Ayyangar, "A Framework for 960 Inter-Domain Multiprotocol Label Switching Traffic 961 Engineering", RFC 4726, DOI 10.17487/RFC4726, November 962 2006, . 964 [RFC5623] Oki, E., Takeda, T., Le Roux, JL., and A. Farrel, 965 "Framework for PCE-Based Inter-Layer MPLS and GMPLS 966 Traffic Engineering", RFC 5623, DOI 10.17487/RFC5623, 967 September 2009, 968 . 970 [RFC8051] Zhang, X., Ed. and I. Minei, Ed., "Applicability of a 971 Stateful Path Computation Element (PCE)", RFC 8051, 972 DOI 10.17487/RFC8051, January 2017, 973 . 975 [RFC8232] Crabbe, E., Minei, I., Medved, J., Varga, R., Zhang, X., 976 and D. Dhody, "Optimizations of Label Switched Path State 977 Synchronization Procedures for a Stateful PCE", RFC 8232, 978 DOI 10.17487/RFC8232, September 2017, 979 . 981 [RFC8453] Ceccarelli, D., Ed. and Y. Lee, Ed., "Framework for 982 Abstraction and Control of TE Networks (ACTN)", RFC 8453, 983 DOI 10.17487/RFC8453, August 2018, 984 . 986 [RFC8637] Dhody, D., Lee, Y., and D. Ceccarelli, "Applicability of 987 the Path Computation Element (PCE) to the Abstraction and 988 Control of TE Networks (ACTN)", RFC 8637, DOI 989 10.17487/RFC8637, July 2019, 990 . 992 [I-D.litkowski-pce-state-sync] 993 Litkowski, S., Sivabalan, S., and D. Dhody, "Inter 994 Stateful Path Computation Element communication 995 procedures", draft-litkowski-pce-state-sync-06 (work in 996 progress), July 2019. 998 [I-D.ietf-pce-hierarchy-extensions] 999 Zhang, F., Zhao, Q., Dios, O., Casellas, R., and D. King, 1000 "Extensions to Path Computation Element Communication 1001 Protocol (PCEP) for Hierarchical Path Computation Elements 1002 (PCE)", draft-ietf-pce-hierarchy-extensions-11 (work in 1003 progress), June 2019. 1005 [I-D.ietf-pce-pcep-yang] 1006 Dhody, D., Hardwick, J., Beeram, V., and J. Tantsura, "A 1007 YANG Data Model for Path Computation Element 1008 Communications Protocol (PCEP)", 1009 draft-ietf-pce-pcep-yang-12 (work in progress), July 2019. 1011 [I-D.dugeon-pce-stateful-interdomain] 1012 Dugeon, O., Meuric, J., Lee, Y., Dhody, D., and D. 1013 Ceccarelli, "PCEP Extension for Stateful Inter-Domain 1014 Tunnels", draft-dugeon-pce-stateful-interdomain-02 (work 1015 in progress), March 2019. 1017 [I-D.ietf-pce-lsp-control-request] 1018 Raghuram, A., Goddard, A., Yadlapalli, C., Karthik, J., 1019 Sivabalan, S., Parker, J., and M. Negi, "Ability for a 1020 stateful Path Computation Element (PCE) to request and 1021 obtain control of a LSP", draft-ietf-pce-lsp-control- 1022 request-11 (work in progress), October 2019. 1024 [I-D.ietf-pce-enhanced-errors] 1025 Pouyllau, et al., "Extensions to PCEP for Enhanced Errors" 1026 , draft-ietf-pce-enhanced-errors-06 (work in progress), 1027 August 2019. 1029 [I-D.ietf-pce-stateful-path-protection] 1030 Ananthakrishnan, H., Sivabalan, S., Barth, C., Minei, I., 1031 and M. Negi, "PCEP Extensions for Associating Working and 1032 Protection LSPs with Stateful PCE", draft-ietf-pce- 1033 stateful-path-protection-11 (work in progress), September 1034 2019. 1036 Contributors 1038 Avantika 1039 ECI Telecom 1040 India 1042 EMail: avantika.srm@gmail.com 1044 Xian Zhang 1045 Huawei Technologies 1046 Bantian, Longgang District 1047 Shenzhen, Guangdong 518129 1048 P.R.China 1050 EMail: zhang.xian@huawei.com 1052 Udayasree Palle 1054 EMail: udayasreereddy@gmail.com 1056 Oscar Gonzalez de Dios 1057 Telefonica I+D 1058 Don Ramon de la Cruz 82-84 1059 Madrid, 28045 1060 Spain 1061 Phone: +34913128832 1063 EMail: oscar.gonzalezdedios@telefonica.com 1065 Authors' Addresses 1067 Dhruv Dhody 1068 Huawei Technologies 1069 Divyashree Techno Park, Whitefield 1070 Bangalore, Karnataka 560066 1071 India 1073 EMail: dhruv.ietf@gmail.com 1075 Young Lee 1076 SKKU 1078 EMail: younglee.tx@gmail.com 1080 Daniele Ceccarelli 1081 Ericsson 1082 Torshamnsgatan,48 1083 Stockholm 1084 Sweden 1086 EMail: daniele.ceccarelli@ericsson.com 1088 Jongyoon Shin 1089 SK Telecom 1090 6 Hwangsaeul-ro, 258 beon-gil, Bundang-gu, Seongnam-si, 1091 Gyeonggi-do 463-784 1092 Republic of Korea 1093 EMail: jongyoon.shin@sk.com 1095 Daniel King 1096 Lancaster University 1097 UK 1099 EMail: d.king@lancaster.ac.uk