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