idnits 2.17.1 draft-dhodylee-pce-stateful-hpce-01.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 (July 8, 2016) is 2848 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Outdated reference: A later version (-21) exists of draft-ietf-pce-stateful-pce-13 == Outdated reference: A later version (-11) exists of draft-ietf-pce-pce-initiated-lsp-05 == Outdated reference: A later version (-08) exists of draft-ietf-pce-stateful-pce-app-06 == Outdated reference: A later version (-10) exists of draft-ietf-pce-stateful-sync-optimizations-05 == Outdated reference: A later version (-15) exists of draft-ietf-teas-actn-framework-00 == Outdated reference: A later version (-02) exists of draft-dhody-pce-applicability-actn-00 Summary: 0 errors (**), 0 flaws (~~), 7 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: January 9, 2017 D. Ceccarelli 6 Ericsson 7 J. Shin 8 SK Telecom 9 D. King 10 Lancaster University 11 July 8, 2016 13 Hierarchical Stateful Path Computation Element (PCE). 14 draft-dhodylee-pce-stateful-hpce-01 16 Abstract 18 A Stateful Path Computation Element (PCE) maintains information on 19 the current network state, including: computed Label Switched Path 20 (LSPs), reserved resources within the network, and pending path 21 computation requests. This information may then be considered when 22 computing new traffic engineered LSPs, and for associated 23 and dependent LSPs, received from Path Computation Clients (PCCs). 25 The Hierarchical Path Computation Element (H-PCE) architecture, 26 provides an architecture to allow the optimum sequence of 27 inter-connected domains to be selected, and network policy to be 28 applied if applicable, via the use of a hierarchical relationship 29 between PCEs. 31 Combining the capabilities of Stateful PCE and the Hierarchical PCE 32 would be advantageous. This document describes general considerations 33 and use cases for the deployment of Stateful PCE(s) using the 34 Hierarchical PCE architecture. 36 Status of This Memo 38 This Internet-Draft is submitted in full conformance with the 39 provisions of BCP 78 and BCP 79. 41 Internet-Drafts are working documents of the Internet Engineering 42 Task Force (IETF). Note that other groups may also distribute 43 working documents as Internet-Drafts. The list of current Internet- 44 Drafts is at http://datatracker.ietf.org/drafts/current/. 46 Internet-Drafts are draft documents valid for a maximum of six months 47 and may be updated, replaced, or obsoleted by other documents at any 48 time. It is inappropriate to use Internet-Drafts as reference 49 material or to cite them other than as "work in progress." 51 Copyright Notice 53 Copyright (c) 2016 IETF Trust and the persons identified as the 54 document authors. All rights reserved. 56 This document is subject to BCP 78 and the IETF Trust's Legal 57 Provisions Relating to IETF Documents 58 (http://trustee.ietf.org/license-info) in effect on the date of 59 publication of this document. Please review these documents 60 carefully, as they describe your rights and restrictions with respect 61 to this document. Code Components extracted from this document must 62 include Simplified BSD License text as described in Section 4.e of 63 the Trust Legal Provisions and are provided without warranty as 64 described in the Simplified BSD License. 66 Table of Contents 68 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 69 1.1. Requirements Language . . . . . . . . . . . . . . . . . . 3 70 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 71 3. Hierarchical Stateful PCE . . . . . . . . . . . . . . . . . . 4 72 3.1. Passive Operations . . . . . . . . . . . . . . . . . . . 4 73 3.2. Active Operations . . . . . . . . . . . . . . . . . . . . 7 74 3.3. PCE Initiation Operation . . . . . . . . . . . . . . . . 8 75 3.3.1. Per Domain Stitched LSP . . . . . . . . . . . . . . . 8 76 4. Other Considerations . . . . . . . . . . . . . . . . . . . . 10 77 4.1. Applicability to Inter-Layer . . . . . . . . . . . . . . 10 78 4.2. Applicability to ACTN . . . . . . . . . . . . . . . . . . 11 79 5. Security Considerations . . . . . . . . . . . . . . . . . . . 12 80 6. Manageability Considerations . . . . . . . . . . . . . . . . 12 81 6.1. Control of Function and Policy . . . . . . . . . . . . . 12 82 6.2. Information and Data Models . . . . . . . . . . . . . . . 12 83 6.3. Liveness Detection and Monitoring . . . . . . . . . . . . 12 84 6.4. Verify Correct Operations . . . . . . . . . . . . . . . . 12 85 6.5. Requirements On Other Protocols . . . . . . . . . . . . . 12 86 6.6. Impact On Network Operations . . . . . . . . . . . . . . 12 87 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12 88 8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 12 89 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 12 90 9.1. Normative References . . . . . . . . . . . . . . . . . . 12 91 9.2. Informative References . . . . . . . . . . . . . . . . . 13 92 Appendix A. Contributor Addresses . . . . . . . . . . . . . . . 14 93 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 14 95 1. Introduction 97 The Path Computation Element communication Protocol (PCEP) provides 98 mechanisms for Path Computation Elements (PCEs) to perform path 99 computations in response to Path Computation Clients' (PCCs) 100 requests. 102 A stateful PCE is capable of considering, for the purposes of 103 path computation, not only the network state in terms of links and 104 nodes (referred to as the Traffic Engineering Database or TED) but 105 also the status of active services (previously computed paths, 106 and currently reserved resources, stored in the Label Switched 107 Paths Database (LSPDB). 109 [I-D.ietf-pce-stateful-pce-app] describes general considerations for 110 a stateful PCE deployment and examines its applicability and 111 benefits, as well as its challenges and limitations through a number 112 of use cases. 114 [I-D.ietf-pce-stateful-pce] describes a set of extensions to PCEP to 115 provide stateful control. A stateful PCE has access to not only the 116 information carried by the network's Interior Gateway Protocol (IGP), 117 but also the set of active paths and their reserved resources for its 118 computations. The additional state allows the PCE to compute 119 constrained paths while considering individual LSPs and their 120 interactions. [I-D.ietf-pce-pce-initiated-lsp] describes the setup, 121 maintenance and teardown of PCE-initiated LSPs under the stateful PCE 122 model. 124 [I-D.ietf-pce-stateful-pce] also describes the active stateful PCE. 125 The active PCE functionality allows a PCE to reroute an existing 126 LSP or make changes to the attributes of an existing LSP, or delegate 127 control of specific LSPs to a new PCE. 129 The ability to compute shortest constrained TE LSPs in Multiprotocol 130 Label Switching (MPLS) and Generalized MPLS (GMPLS) networks across 131 multiple domains has been identified as a key motivation for PCE 132 development. [RFC6805] describes a Hierarchical PCE (H-PCE) 133 architecture which can be used for computing end-to-end paths for 134 inter-domain MPLS Traffic Engineering (TE) and GMPLS Label Switched 135 Paths (LSPs). Within the Hierarchical PCE (H-PCE) architecture 136 [RFC6805], the Parent PCE (P-PCE) is used to compute a multi-domain 137 path based on the domain connectivity information. A Child PCE 138 (C-PCE) may be responsible for a single domain or multiple domains, 139 it is used to compute the intra-domain path based on its domain 140 topology information. 142 This document presents general considerations for stateful PCE(s) in 143 hierarchical PCE architecture. In particular, the behavior changes 144 and additions to the existing stateful PCE mechanisms (including PCE- 145 initiated LSP setup and active PCE usage) in the context of networks 146 using the H-PCE architecture. 148 1.1. Requirements Language 150 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 151 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 152 document are to be interpreted as described in [RFC2119]. 154 2. Terminology 156 The terminology is as per [RFC4655], [RFC5440], [RFC6805], and 157 [I-D.ietf-pce-stateful-pce]. 159 3. Hierarchical Stateful PCE 161 As described in [RFC6805], in the hierarchical PCE architecture, a 162 P-PCE maintains a domain topology map that contains the child domains 163 (seen as vertices in the topology) and their interconnections (links 164 in the topology). The P-PCE has no information about the content of 165 the child domains. Each child domain has at least one PCE capable of 166 computing paths across the domain. These PCEs are known as C-PCEs 167 and have a direct relationship with the P-PCE. The P-PCE builds the 168 domain topology map either via direct configuration (allowing network 169 policy to also be applied) or from learned information received from 170 each C-PCE. 172 [I-D.ietf-pce-stateful-pce] specifies new functions to support a 173 stateful PCE. It also specifies that a function can be initiated 174 either from a PCC towards a PCE (C-E) or from a PCE towards a PCC 175 (E-C). 177 This document extends these functions to support H-PCE Architecture 178 from a C-PCE towards a P-PCE (CE-PE) or from a P-PCE 179 towards a C-PCE (PE-CE). All PCE types herein (i.e., PE or CE) 180 are assumed to be 'stateful PCE'. 182 A number of interactions are expected in the Hierarchical Stateful 183 PCE architecture, these include: 185 LSP State Report (CE-PE): a child stateful PCE sends an LSP state 186 report to a Parent Stateful PCE whenever the state of a LSP 187 changes. 189 LSP State Synchronization (CE-PE): after the session between the 190 Child and Parent stateful PCEs is initialized, the P-PCE must 191 learn the state of C-PCE's TE LSPs. 193 LSP Control Delegation (CE-PE,PE-CE): a C-PCE grants to the 194 P-PCE the right to update LSP attributes on one or more LSPs; 195 the C-PCE may withdraw the delegation or the P-PCE may 196 give up the delegation at any time. 198 LSP Update Request (PE-CE): a stateful P-PCE requests 199 modification of attributes on a C-PCE's TE LSP. 201 PCE LSP Initiation Request (PE-CE): a stateful P-PCE requests 202 C-PCE to initiate a TE LSP. 204 3.1. Passive Operations 206 Procedures as described in [RFC6805] are applied, where the ingress 207 C-PCE sends a request to the P-PCE. The P-PCE selects 208 a set of candidate domain paths based on the domain topology and the 209 state of the inter-domain links. It then sends computation requests 210 to the C-PCEs responsible for each of the domains on the 211 candidate domain paths. Each C-PCE computes a set of candidate 212 path segments across its domain and sends the results to the P-PCE. 213 The P-PCE uses this information to select path segments 214 and concatenate them to derive the optimal end-to-end inter-domain 215 path. The end-to-end path is then sent to the C-PCE that 216 received the initial path request, and this C-PCE passes the path 217 on to the PCC that issued the original request. 219 As per [I-D.ietf-pce-stateful-pce], PCC sends an LSP State Report 220 carried on a PCRpt message to the C-PCE, indicating the LSP's 221 status. The C-PCE MAY further propagate the State Report to the 222 P-PCE. A local policy at C-PCE MAY dictate which LSPs to be 223 reported to the P-PCE. The PCRpt message is sent from C-PCE 224 to P-PCE. 226 State synchronization mechanism as described in 227 [I-D.ietf-pce-stateful-pce] and 228 [I-D.ietf-pce-stateful-sync-optimizations] are applicable to PCEP 229 session between C-PCE and P-PCE as well. 231 Taking the sample hierarchical domain topology example from [RFC6805] 232 as the reference topology for the entirety of this document. 234 ----------------------------------------------------------------- 235 | Domain 5 | 236 | ----- | 237 | |PCE 5| | 238 | ----- | 239 | | 240 | ---------------- ---------------- ---------------- | 241 | | Domain 1 | | Domain 2 | | Domain 3 | | 242 | | | | | | | | 243 | | ----- | | ----- | | ----- | | 244 | | |PCE 1| | | |PCE 2| | | |PCE 3| | | 245 | | ----- | | ----- | | ----- | | 246 | | | | | | | | 247 | | ----| |---- ----| |---- | | 248 | | |BN11+---+BN21| |BN23+---+BN31| | | 249 | | - ----| |---- ----| |---- - | | 250 | | |S| | | | | |D| | | 251 | | - ----| |---- ----| |---- - | | 252 | | |BN12+---+BN22| |BN24+---+BN32| | | 253 | | ----| |---- ----| |---- | | 254 | | | | | | | | 255 | | ---- | | | | ---- | | 256 | | |BN13| | | | | |BN33| | | 257 | -----------+---- ---------------- ----+----------- | 258 | \ / | 259 | \ ---------------- / | 260 | \ | | / | 261 | \ |---- ----| / | 262 | ----+BN41| |BN42+---- | 263 | |---- ----| | 264 | | | | 265 | | ----- | | 266 | | |PCE 4| | | 267 | | ----- | | 268 | | | | 269 | | Domain 4 | | 270 | ---------------- | 271 | | 272 ----------------------------------------------------------------- 274 Figure 1: Sample Hierarchical Domain Topology 276 Steps 1 to 11 are exactly as described in section 4.6.2 (Hierarchical 277 PCE End-to-End Path Computation Procedure) of [RFC6805], the 278 following additional steps are added for stateful PCE: 280 (1) The Ingress LSR initiates the setup of the LSP as per the path 281 and reports to the PCE1 the LSP status ("GOING-UP"). 283 (2) The PCE1 further reports the status of the LSP to the P-PCE 284 (PCE5). 286 (3) The Ingress LSR notifies the LSP state to PCE1 when the state is 287 "UP". 289 (4) The PCE1 further reports the status of the LSP to the P-PCE 290 (PCE5). 292 3.2. Active Operations 294 [I-D.ietf-pce-stateful-pce] describes the case of active stateful 295 PCE. The active PCE functionality uses two specific PCEP messages: 297 o Update Request (PCUpd) 298 o State Report (PCRpt) 300 The first is sent by the PCE to a Path Computation Client (PCC) for 301 modifying LSP attributes. The PCC sends back a PCRpt to acknowledge 302 the requested operation. PCRpt has the same structure of PCNtf 303 message. 305 As per [I-D.ietf-pce-stateful-pce], Delegation is an operation to 306 grant a PCE, temporary rights to modify a subset of LSP parameters on 307 one or more PCC's LSPs. The C-PCE may further choose to delegate 308 to P-PCE based on a local policy. The PCRpt message with "D" 309 (delegate) flag is sent from C-PCE to P-PCE. 311 To update an LSP, a PCE send to the PCC, an LSP Update Request using 312 a PCUpd message. For LSP delegated to the P-PCE via the child 313 PCE, the P-PCE can use the same PCUpd message to request change 314 to the C-PCE (the Ingress domain PCE), the PCE further propagates 315 the update request to the PCC. 317 The P-PCE uses the same mechanism described in Section 3.1 to compute 318 the end to end path using PCReq and PCRep messages. 320 The following additional steps are also initially performed, 321 for active operations, again using the reference architecture 322 described in Figure 1 (Sample Hierarchical Domain Topology). 324 (1) The Ingress LSR delegates the LSP to the PCE1 via PCRpt message 325 with D flag set. 327 (2) The PCE1 further delegates the LSP to the P-PCE (PCE5). 329 Steps 4 to 10 of section 4.6.2 of [RFC6805] are executed to determine 330 the end to end path. 332 (3) The P-PCE (PCE5) sends the update request to the C-PCE 333 (PCE1) via PCUpd message. 335 (4) The PCE1 further updates the LSP to the Ingress LSR (PCC). 337 (5) The Ingress LSR initiates the setup of the LSP as per the path 338 and reports to the PCE1 the LSP status ("GOING-UP"). 340 (6) The PCE1 further reports the status of the LSP to the P-PCE 341 (PCE5). 343 (7) The Ingress LSR notifies the LSP state to PCE1 when the state is 344 "UP". 346 (8) The PCE1 further reports the status of the LSP to the P-PCE 347 (PCE5). 349 3.3. PCE Initiation Operation 351 [I-D.ietf-pce-pce-initiated-lsp] describes the setup, maintenance and 352 teardown of PCE-initiated LSPs under the stateful PCE model, without 353 the need for local configuration on the PCC, thus allowing for a 354 dynamic network that is centrally controlled and deployed. To 355 instantiate or delete an LSP, the PCE sends the Path Computation LSP 356 Initiate Request (PCInitiate) message to the PCC. In case of inter- 357 domain LSP in Hierarchical PCE architecture, the initiation 358 operations can be carried out at the P-PCE. In which case after 359 P-PCE finishes the E2E path computation, it can send the 360 PCInitiate message to the C-PCE (the Ingress domain PCE), the PCE 361 further propagates the initiate request to the PCC. 363 The following additional steps are also initially performed, 364 for PCE initiated operations, again using the reference 365 architecture described in Figure 1 (Sample Hierarchical Domain 366 Topology): 368 (1) The P-PCE (PCE5) is requested to initiate a LSP. 370 Steps 4 to 10 of section 4.6.2 of [RFC6805] are executed to determine 371 the end to end path. 373 (2) The P-PCE (PCE5) sends the initiate request to the child 374 PCE (PCE1) via PCInitiate message. 376 (3) The PCE1 further propagates the initiate message to the Ingress 377 LSR (PCC). 379 (4) The Ingress LSR initiates the setup of the LSP as per the path 380 and reports to the PCE1 the LSP status ("GOING-UP"). 382 (5) The PCE1 further reports the status of the LSP to the P-PCE 383 (PCE5). 385 (6) The Ingress LSR notifies the LSP state to PCE1 when the state is 386 "UP". 388 (7) The PCE1 further reports the status of the LSP to the P-PCE 389 (PCE5). 391 3.3.1. Per Domain Stitched LSP 393 The hierarchical PCE architecture as per [RFC6805] is primarily used 394 for E2E LSP. With PCE-Initiated capability, another mode of 395 operation is possible, where multiple intra-domain LSP are initiated 396 in each domain which are further stitched to form an E2E LSP. The 397 P-PCE sends PCInitiate message to each C-PCE separately to 398 initiate individual LSP segments along the domain path. These 399 individual per domain LSP are stitched together by some mechanism, 400 which is out of scope of this document. 402 The following additional steps are also initially performed, 403 for the Per Domain stiched LSP operation, again using the reference 404 architecture described in Figure 1 (Sample Hierarchical Domain 405 Topology): 407 (1) The P-PCE (PCE5) is requested to initiate a LSP. 409 Steps 4 to 10 of section 4.6.2 of [RFC6805] are executed to determine 410 the end to end path, which are broken into per-domain LSPs say - 412 o S-BN41 414 o BN41-BN33 416 o BN33-D 418 It should be noted that the P-PCE MAY use other mechanisms to 419 determine the suitable per-domain LSPs (apart from [RFC6805]). 421 For LSP (BN33-D) 423 (2) The P-PCE (PCE5) sends the initiate request to the child 424 PCE (PCE3) via PCInitiate message for LSP (BN33-D). 426 (3) The PCE3 further propagates the initiate message to BN33. 428 (4) BN33 initiates the setup of the LSP as per the path and reports 429 to the PCE3 the LSP status ("GOING-UP"). 431 (5) The PCE3 further reports the status of the LSP to the P-PCE 432 (PCE5). 434 (6) The node BN33 notifies the LSP state to PCE3 when the state is 435 "UP". 437 (7) The PCE3 further reports the status of the LSP to the P-PCE 438 (PCE5). 440 For LSP (BN41-BN33) 442 (8) The P-PCE (PCE5) sends the initiate request to the child PCE 443 (PCE4) via PCInitiate message for LSP (BN41-BN33). 445 (9) The PCE4 further propagates the initiate message to BN41. 447 (10) BN41 initiates the setup of the LSP as per the path and reports 448 to the PCE4 the LSP status ("GOING-UP"). 450 (11) The PCE4 further reports the status of the LSP to the P-PCE 451 (PCE5). 453 (l2) The node BN41 notifies the LSP state to PCE4 when the state is 454 "UP". 456 (13) The PCE4 further reports the status of the LSP to the P-PCE 457 (PCE5). 459 For LSP (S-BN41) 461 (14) The P-PCE (PCE5) sends the initiate request to the child 462 PCE (PCE1) via PCInitiate message for LSP (S-BN41). 464 (15) The PCE1 further propagates the initiate message to node S. 466 (16) S initiates the setup of the LSP as per the path and reports to 467 the PCE1 the LSP status ("GOING-UP"). 469 (17) The PCE1 further reports the status of the LSP to the P-PCE 470 (PCE5). 472 (18) The node S notifies the LSP state to PCE1 when the state is 473 "UP". 475 (19) The PCE1 further reports the status of the LSP to the P-PCE 476 (PCE5). 478 Additionally: 480 (20) once P-PCE receives report of each per-domain LSP, it 481 should use some stitching mechanism, which is out of scope of 482 this document. 484 4. Other Considerations 486 4.1. Applicability to Inter-Layer 488 [RFC5623] describes a framework for applying the PCE-based 489 architecture to inter-layer (G)MPLS traffic engineering. The H-PCE 490 Stateful architecture with stateful P-PCE coordinating with the 491 stateful C-PCEs of higher and lower layer is shown in the figure 492 below. 494 +----------+ 495 /| Parent | 496 / | PCE | 497 / +----------+ 498 / / Stateful 499 / / 500 / / 501 / / 502 Stateful +---+/ / 503 Child + PCE + / 504 PCE Hi + Hi + / 505 +---+ / 506 +---+ +---+ / +---+ +---+ 507 + LSR +--+ LSR +........................+ LSR +--+ LSR + 508 + H1 + + H2 + / + H3 + + H4 + 509 +---+ +---+\ +---+/ /+---+ +---+ 510 \ + PCE + / 511 \ + Lo + / 512 Stateful \ +---+ / 513 C-PCE \ / 514 Lo \+---+ +---+/ 515 + LSR +--+ LSR + 516 + L1 + + L2 + 517 +---+ +---+ 519 Figure 2: Sample Inter-Layer Topology 521 All procedures described in Section 3 are applicable to inter-layer 522 path setup as well. 524 4.2. Applicability to ACTN 526 [I-D.ietf-teas-actn-framework] describes framework for 527 Abstraction and Control of TE Networks (ACTN), where each Physical 528 Network Controller (PNC) is equivalent to C-PCE and P-PCE is 529 the Multi-Domain Service Coordinator (MDSC). The Per domain stitched 530 LSP as per the Hierarchical PCE architecture described in 531 Section 3.3.1 and Section 4.1 is well suited for ACTN. 533 [I-D.dhody-pce-applicability-actn] examines the applicability of PCE 534 to the ACTN framework. To support the function of multi domain 535 coordination via hierarchy, the stateful hierarchy of PCEs plays a 536 crucial role. 538 In ACTN framework, Customer Network Controller (CNC) can request the 539 MDSC to check if there is a possibility to meet Virtual Network (VN) 540 requirements (before requesting for VN provision). The H-PCE 541 architecture as described in [RFC6805] can supports via the use of 542 PCReq and PCRep messages between the P-PCE and C-PCEs. 544 5. Security Considerations 546 6. Manageability Considerations 548 6.1. Control of Function and Policy 550 TBD. 552 6.2. Information and Data Models 554 TBD. 556 6.3. Liveness Detection and Monitoring 558 TBD. 560 6.4. Verify Correct Operations 562 TBD. 564 6.5. Requirements On Other Protocols 566 TBD. 568 6.6. Impact On Network Operations 570 TBD. 572 7. IANA Considerations 574 There are no IANA considerations. 576 8. Acknowledgments 578 Thanks to Manuela Scarella, Haomian Zheng, Sergio Marmo, Stefano 579 Parodi and Giacomo Agostini for suggestions. 581 9. References 583 9.1. Normative References 585 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 586 Requirement Levels", BCP 14, RFC 2119, 587 DOI 10.17487/RFC2119, March 1997, 588 . 590 [RFC5440] Vasseur, JP., Ed. and JL. Le Roux, Ed., "Path Computation 591 Element (PCE) Communication Protocol (PCEP)", RFC 5440, 592 DOI 10.17487/RFC5440, March 2009, 593 . 595 [RFC6805] King, D., Ed. and A. Farrel, Ed., "The Application of the 596 Path Computation Element Architecture to the Determination 597 of a Sequence of Domains in MPLS and GMPLS", RFC 6805, DOI 598 10.17487/RFC6805, November 2012, 599 . 601 [I-D.ietf-pce-stateful-pce] 602 Crabbe, E., Minei, I., Medved, J., and R. Varga, "PCEP 603 Extensions for Stateful PCE", draft-ietf-pce-stateful- 604 pce-13 (work in progress), December 2015. 606 [I-D.ietf-pce-pce-initiated-lsp] 607 Crabbe, E., Minei, I., Sivabalan, S., and R. Varga, "PCEP 608 Extensions for PCE-initiated LSP Setup in a Stateful PCE 609 Model", draft-ietf-pce-pce-initiated-lsp-05 (work in 610 progress), October 2015. 612 9.2. Informative References 614 [RFC4655] Farrel, A., Vasseur, J., and J. Ash, "A Path Computation 615 Element (PCE)-Based Architecture", RFC 4655, 616 DOI 10.17487/RFC4655, August 2006, 617 . 619 [RFC5623] Oki, E., Takeda, T., Le Roux, JL., and A. Farrel, 620 "Framework for PCE-Based Inter-Layer MPLS and GMPLS 621 Traffic Engineering", RFC 5623, DOI 10.17487/RFC5623, 622 September 2009, . 624 [I-D.ietf-pce-stateful-pce-app] 625 Zhang, X. and I. Minei, "Applicability of a Stateful Path 626 Computation Element (PCE)", draft-ietf-pce-stateful-pce- 627 app-06 (work in progress), July 2016. 629 [I-D.ietf-pce-stateful-sync-optimizations] 630 Crabbe, E., Minei, I., Medved, J., Varga, R., Zhang, X., 631 and D. Dhody, "Optimizations of Label Switched Path State 632 Synchronization Procedures for a Stateful PCE", draft- 633 ietf-pce-stateful-sync-optimizations-05 (work in 634 progress), April 2016. 636 [I-D.ietf-teas-actn-framework] 637 Ceccarelli D. and Y. Lee, "Framework for Abstraction and 638 Control of Transport Networks", draft-ietf-teas- 639 actn-framework-00 (work in progress), July 2016. 641 [I-D.dhody-pce-applicability-actn] 642 Dhody, D., Lee, Y., and D. Ceccarelli, "Applicability of 643 Path Computation Element (PCE) for Abstraction and Control 644 of TE Networks (ACTN)", draft-dhody-pce-applicability- 645 actn-00 (work in progress), July 2016. 647 Appendix A. Contributor Addresses 649 Avantika 650 Huawei Technologies 651 Divyashree Techno Park, Whitefield 652 Bangalore, Karnataka 560066 653 India 655 EMail: avantika.sushilkumar@huawei.com 657 Xian Zhang 658 Huawei Technologies 659 Bantian, Longgang District 660 Shenzhen, Guangdong 518129 661 P.R.China 663 EMail: zhang.xian@huawei.com 665 Authors' Addresses 667 Dhruv Dhody 668 Huawei Technologies 669 Divyashree Techno Park, Whitefield 670 Bangalore, Karnataka 560066 671 India 673 EMail: dhruv.ietf@gmail.com 675 Young Lee 676 Huawei Technologies 677 5340 Legacy Drive, Building 3 678 Plano, TX 75023 679 USA 681 EMail: leeyoung@huawei.com 683 Daniele Ceccarelli 684 Ericsson 685 Torshamnsgatan,48 686 Stockholm 687 Sweden 689 EMail: daniele.ceccarelli@ericsson.com 690 Jongyoon Shin 691 SK Telecom 692 6 Hwangsaeul-ro, 258 beon-gil, Bundang-gu, Seongnam-si, 693 Gyeonggi-do 463-784 694 Republic of Korea 696 EMail: jongyoon.shin@sk.com 698 Dan King 699 Lancaster University 700 UK 702 EMail: d.king@lancaster.ac.uk