idnits 2.17.1 draft-zhao-pce-pcep-extension-for-pce-controller-08.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (June 18, 2018) is 2137 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) ** Obsolete normative reference: RFC 7525 (Obsoleted by RFC 9325) == Outdated reference: A later version (-13) exists of draft-ietf-teas-pcecc-use-cases-01 == Outdated reference: A later version (-23) exists of draft-ietf-pce-pcep-yang-07 == Outdated reference: A later version (-09) exists of draft-zhao-pce-pcep-extension-pce-controller-sr-02 Summary: 1 error (**), 0 flaws (~~), 4 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 PCE Working Group Q. Zhao 3 Internet-Draft Z. Li 4 Intended status: Standards Track D. Dhody 5 Expires: December 20, 2018 S. Karunanithi 6 Huawei Technologies 7 A. Farrel 8 Juniper Networks, Inc 9 C. Zhou 10 Cisco Systems 11 June 18, 2018 13 PCEP Procedures and Protocol Extensions for Using PCE as a Central 14 Controller (PCECC) of LSPs 15 draft-zhao-pce-pcep-extension-for-pce-controller-08 17 Abstract 19 The Path Computation Element (PCE) is a core component of Software- 20 Defined Networking (SDN) systems. It can compute optimal paths for 21 traffic across a network and can also update the paths to reflect 22 changes in the network or traffic demands. 24 PCE was developed to derive paths for MPLS Label Switched Paths 25 (LSPs), which are supplied to the head end of the LSP using the Path 26 Computation Element Communication Protocol (PCEP). But SDN has a 27 broader applicability than signaled (G)MPLS traffic-engineered (TE) 28 networks, and the PCE may be used to determine paths in a range of 29 use cases. PCEP has been proposed as a control protocol for use in 30 these environments to allow the PCE to be fully enabled as a central 31 controller. 33 A PCE-based central controller (PCECC) can simplify the processing of 34 a distributed control plane by blending it with elements of SDN and 35 without necessarily completely replacing it. Thus, the LSP can be 36 calculated/setup/initiated and the label forwarding entries can also 37 be downloaded through a centralized PCE server to each network 38 devices along the path while leveraging the existing PCE technologies 39 as much as possible. 41 This document specifies the procedures and PCEP protocol extensions 42 for using the PCE as the central controller. 44 Status of This Memo 46 This Internet-Draft is submitted in full conformance with the 47 provisions of BCP 78 and BCP 79. 49 Internet-Drafts are working documents of the Internet Engineering 50 Task Force (IETF). Note that other groups may also distribute 51 working documents as Internet-Drafts. The list of current Internet- 52 Drafts is at https://datatracker.ietf.org/drafts/current/. 54 Internet-Drafts are draft documents valid for a maximum of six months 55 and may be updated, replaced, or obsoleted by other documents at any 56 time. It is inappropriate to use Internet-Drafts as reference 57 material or to cite them other than as "work in progress." 59 This Internet-Draft will expire on December 20, 2018. 61 Copyright Notice 63 Copyright (c) 2018 IETF Trust and the persons identified as the 64 document authors. All rights reserved. 66 This document is subject to BCP 78 and the IETF Trust's Legal 67 Provisions Relating to IETF Documents 68 (https://trustee.ietf.org/license-info) in effect on the date of 69 publication of this document. Please review these documents 70 carefully, as they describe your rights and restrictions with respect 71 to this document. Code Components extracted from this document must 72 include Simplified BSD License text as described in Section 4.e of 73 the Trust Legal Provisions and are provided without warranty as 74 described in the Simplified BSD License. 76 Table of Contents 78 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 79 1.1. Requirements Language . . . . . . . . . . . . . . . . . . 5 80 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5 81 3. Basic PCECC Mode . . . . . . . . . . . . . . . . . . . . . . 5 82 4. PCEP Requirements . . . . . . . . . . . . . . . . . . . . . . 5 83 5. Procedures for Using the PCE as the Central Controller 84 (PCECC) . . . . . . . . . . . . . . . . . . . . . . . . . . . 6 85 5.1. Stateful PCE Model . . . . . . . . . . . . . . . . . . . 6 86 5.2. New LSP Functions . . . . . . . . . . . . . . . . . . . . 6 87 5.3. PCECC Capability Advertisement . . . . . . . . . . . . . 7 88 5.4. LSP Operations . . . . . . . . . . . . . . . . . . . . . 8 89 5.4.1. Basic PCECC LSP Setup . . . . . . . . . . . . . . . . 8 90 5.4.2. Central Control Instructions . . . . . . . . . . . . 10 91 5.4.2.1. Label Download . . . . . . . . . . . . . . . . . 10 92 5.4.2.2. Label Cleanup . . . . . . . . . . . . . . . . . . 11 93 5.4.3. PCE Initiated PCECC LSP . . . . . . . . . . . . . . . 12 94 5.4.4. PCECC LSP Update . . . . . . . . . . . . . . . . . . 14 95 5.4.5. Re Delegation and Cleanup . . . . . . . . . . . . . . 16 96 5.4.6. Synchronization of Central Controllers Instructions . 16 97 5.4.7. PCECC LSP State Report . . . . . . . . . . . . . . . 16 98 6. PCEP messages . . . . . . . . . . . . . . . . . . . . . . . . 16 99 6.1. The PCInitiate message . . . . . . . . . . . . . . . . . 17 100 6.2. The PCRpt message . . . . . . . . . . . . . . . . . . . . 18 101 7. PCEP Objects . . . . . . . . . . . . . . . . . . . . . . . . 19 102 7.1. OPEN Object . . . . . . . . . . . . . . . . . . . . . . . 19 103 7.1.1. PCECC Capability sub-TLV . . . . . . . . . . . . . . 19 104 7.2. PATH-SETUP-TYPE TLV . . . . . . . . . . . . . . . . . . . 20 105 7.3. CCI Object . . . . . . . . . . . . . . . . . . . . . . . 20 106 7.3.1. Address TLVs . . . . . . . . . . . . . . . . . . . . 21 107 8. Security Considerations . . . . . . . . . . . . . . . . . . . 23 108 8.1. Malicious PCE . . . . . . . . . . . . . . . . . . . . . . 23 109 9. Manageability Considerations . . . . . . . . . . . . . . . . 23 110 9.1. Control of Function and Policy . . . . . . . . . . . . . 23 111 9.2. Information and Data Models . . . . . . . . . . . . . . . 23 112 9.3. Liveness Detection and Monitoring . . . . . . . . . . . . 23 113 9.4. Verify Correct Operations . . . . . . . . . . . . . . . . 23 114 9.5. Requirements On Other Protocols . . . . . . . . . . . . . 23 115 9.6. Impact On Network Operations . . . . . . . . . . . . . . 24 116 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 24 117 10.1. PCEP TLV Type Indicators . . . . . . . . . . . . . . . . 24 118 10.2. New Path Setup Type Registry . . . . . . . . . . . . . . 24 119 10.3. PCEP Object . . . . . . . . . . . . . . . . . . . . . . 24 120 10.4. CCI Object Flag Field . . . . . . . . . . . . . . . . . 24 121 10.5. PCEP-Error Object . . . . . . . . . . . . . . . . . . . 25 122 11. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 25 123 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 25 124 12.1. Normative References . . . . . . . . . . . . . . . . . . 25 125 12.2. Informative References . . . . . . . . . . . . . . . . . 26 126 Appendix A. Contributor Addresses . . . . . . . . . . . . . . . 29 127 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 29 129 1. Introduction 131 The Path Computation Element (PCE) [RFC4655] was developed to offload 132 path computation function from routers in an MPLS traffic-engineered 133 network. Since then, the role and function of the PCE has grown to 134 cover a number of other uses (such as GMPLS [RFC7025]) and to allow 135 delegated control [RFC8231] and PCE-initiated use of network 136 resources [RFC8281]. 138 According to [RFC7399], Software-Defined Networking (SDN) refers to a 139 separation between the control elements and the forwarding components 140 so that software running in a centralized system, called a 141 controller, can act to program the devices in the network to behave 142 in specific ways. A required element in an SDN architecture is a 143 component that plans how the network resources will be used and how 144 the devices will be programmed. It is possible to view this 145 component as performing specific computations to place traffic flows 146 within the network given knowledge of the availability of network 147 resources, how other forwarding devices are programmed, and the way 148 that other flows are routed. This is the function and purpose of a 149 PCE, and the way that a PCE integrates into a wider network control 150 system (including an SDN system) is presented in [RFC7491]. 152 In early PCE implementations, where the PCE was used to derive paths 153 for MPLS Label Switched Paths (LSPs), paths were requested by network 154 elements (known as Path Computation Clients (PCCs)), and the results 155 of the path computations were supplied to network elements using the 156 Path Computation Element Communication Protocol (PCEP) [RFC5440]. 157 This protocol was later extended to allow a PCE to send unsolicited 158 requests to the network for LSP establishment [RFC8281]. 160 [RFC8283] introduces the architecture for PCE as a central controller 161 as an extension of the architecture described in [RFC4655] and 162 assumes the continued use of PCEP as the protocol used between PCE 163 and PCC. [RFC8283] further examines the motivations and 164 applicability for PCEP as a Southbound Interface (SBI), and 165 introduces the implications for the protocol. 166 [I-D.ietf-teas-pcecc-use-cases] describes the use cases for the PCECC 167 architecture. 169 A PCE-based central controller (PCECC) can simplify the processing of 170 a distributed control plane by blending it with elements of SDN and 171 without necessarily completely replacing it. Thus, the LSP can be 172 calculated/setup/initiated and the label forwarding entries can also 173 be downloaded through a centralized PCE server to each network 174 devices along the path while leveraging the existing PCE technologies 175 as much as possible. 177 This draft specify the procedures and PCEP protocol extensions for 178 using the PCE as the central controller for static LSPs, where LSPs 179 can be provisioned as explicit label instructions at each hop on the 180 end-to-end path. Each router along the path must be told what label- 181 forwarding instructions to program and what resources to reserve. 182 The PCE-based controller keeps a view of the network and determines 183 the paths of the end-to-end LSPs, and the controller uses PCEP to 184 communicate with each router along the path of the end-to-end LSP. 186 The extension for PCECC in Segment Routing (SR) is specified in a 187 separate draft [I-D.zhao-pce-pcep-extension-pce-controller-sr]. 189 1.1. Requirements Language 191 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 192 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 193 "OPTIONAL" in this document are to be interpreted as described in BCP 194 14 [RFC2119] [RFC8174] when, and only when, they appear in all 195 capitals, as shown here. 197 2. Terminology 199 Terminologies used in this document is same as described in the draft 200 [RFC8283] and [I-D.ietf-teas-pcecc-use-cases]. 202 3. Basic PCECC Mode 204 In this mode LSPs are provisioned as explicit label instructions at 205 each hop on the end-to-end path. Each router along the path must be 206 told what label forwarding instructions to program and what resources 207 to reserve. The controller uses PCEP to communicate with each router 208 along the path of the end-to-end LSP. 210 Note that the PCE-based controller will take responsibility for 211 managing some part of the MPLS label space for each of the routers 212 that it controls, and may taker wider responsibility for partitioning 213 the label space for each router and allocating different parts for 214 different uses. This is also described in section 3.1.2. of 215 [RFC8283]. For the purpose of this document, it is assumed that 216 label range to be used by a PCE is known and set on both PCEP peers. 217 A future extension could add this capability to advertise the range 218 via possible PCEP extensions as well. The rest of processing is 219 similar to the existing stateful PCE mechanism. 221 4. PCEP Requirements 223 Following key requirements associated PCECC should be considered when 224 designing the PCECC based solution: 226 1. PCEP speaker supporting this draft MUST have the capability to 227 advertise its PCECC capability to its peers. 229 2. PCEP speaker not supporting this draft MUST be able to reject 230 PCECC related extensions with a error reason code that indicates 231 that this feature is not supported. 233 3. PCEP speaker MUST provide a means to identify PCECC based LSP in 234 the PCEP messages. 236 4. PCEP procedures SHOULD provide a means to update (or cleanup) the 237 label- download entry to the PCC. 239 5. PCEP procedures SHOULD provide a means to synchronize the labels 240 between PCE to PCC in PCEP messages. 242 5. Procedures for Using the PCE as the Central Controller (PCECC) 244 5.1. Stateful PCE Model 246 Active stateful PCE is described in [RFC8231]. PCE as a central 247 controller (PCECC) reuses existing Active stateful PCE mechanism as 248 much as possible to control the LSP. 250 5.2. New LSP Functions 252 This document defines the following new PCEP messages and extends the 253 existing messages to support PCECC: 255 (PCRpt): a PCEP message described in [RFC8231]. PCRpt message is 256 used to send PCECC LSP Reports. It is also extended to report the 257 set of Central Controller's Instructions (CCI) (label forwarding 258 instructions in the context of this document) received from the 259 PCE. See Section 5.4.6 for more details. 261 (PCInitiate): a PCEP message described in [RFC8281]. PCInitiate 262 message is used to setup PCE-Initiated LSP based on PCECC 263 mechanism. It is also extended for Central Controller's 264 Instructions (CCI) (download or cleanup the Label forwarding 265 instructions in the context of this document) on all nodes along 266 the path. 268 (PCUpd): a PCEP message described in [RFC8231]. PCUpd message is 269 used to send PCECC LSP Update. 271 The new LSP functions defined in this document are mapped onto the 272 messages as shown in the following table. 274 +----------------------------------------+--------------------------+ 275 | Function | Message | 276 +----------------------------------------+--------------------------+ 277 | PCECC Capability advertisement | Open | 278 | Label entry Add | PCInitiate | 279 | Label entry Cleanup | PCInitiate | 280 | PCECC Initiated LSP | PCInitiate | 281 | PCECC LSP Update | PCUpd | 282 | PCECC LSP State Report | PCRpt | 283 | PCECC LSP Delegation | PCRpt | 284 | PCECC Label Report | PCRpt | 285 +----------------------------------------+--------------------------+ 287 This document specify a new object CCI (see Section 7.3) for the 288 encoding of central controller's instructions. In the scope of this 289 document this is limited to Label forwarding instructions. The CC-ID 290 is the unique identifier for the central controller's instructions in 291 PCEP. The PCEP messages are extended in this document to handle the 292 PCECC operations. 294 5.3. PCECC Capability Advertisement 296 During PCEP Initialization Phase, PCEP Speakers (PCE or PCC) 297 advertise their support of PCECC extensions. 299 This document defines a new Path Setup Type (PST) 300 [I-D.ietf-pce-lsp-setup-type] for PCECC, as follows: 302 o PST = TBD: Path is setup via PCECC mode. 304 A PCEP speaker MUST indicate its support of the function described in 305 this document by sending a PATH-SETUP-TYPE-CAPABILITY TLV in the OPEN 306 object with this new PST included in the PST list. 308 This document also defines the PCECC Capability sub-TLV 309 Section 7.1.1. PCEP speakers use this sub-TLV to exchange 310 information about their PCECC capability. If a PCEP speaker includes 311 PST=TBD in the PST List of the PATH-SETUP-TYPE-CAPABILITY TLV then it 312 MUST also include the PCECC Capability sub-TLV inside the PATH-SETUP- 313 TYPE-CAPABILITY TLV. 315 The presence of the PST and PCECC Capability sub-TLV in PCC's OPEN 316 Object indicates that the PCC is willing to function as a PCECC 317 client. 319 The presence of the PST and PCECC Capability sub-TLV in PCE's OPEN 320 message indicates that the PCE is interested in function as a PCECC 321 server. 323 The PCEP protocol extensions for PCECC MUST NOT be used if one or 324 both PCEP Speakers have not included the PST or the PCECC Capability 325 sub-TLV in their respective OPEN message. If the PCEP Speakers 326 support the extensions of this draft but did not advertise this 327 capability then a PCErr message with Error-Type=19(Invalid Operation) 328 and Error-Value=TBD (Attempted PCECC operations when PCECC capability 329 was not advertised) will be generated and the PCEP session will be 330 terminated. 332 A PCC or a PCE MUST include both PCECC-CAPABILITY sub-TLV and 333 STATEFUL-PCE-CAPABILITY TLV ([RFC8231]) (with I flag set [RFC8281]) 334 in OPEN Object to support the extensions defined in this document. 335 If PCECC-CAPABILITY sub-TLV is advertised and STATEFUL-PCE-CAPABILITY 336 TLV is not advertised in OPEN Object, it SHOULD send a PCErr message 337 with Error-Type=19 (Invalid Operation) and Error-value=TBD (stateful 338 PCE capability was not advertised) and terminate the session. 340 5.4. LSP Operations 342 The PCEP messages pertaining to PCECC MUST include PATH-SETUP-TYPE 343 TLV [I-D.ietf-pce-lsp-setup-type] in the SRP object to clearly 344 identify the PCECC LSP is intended. 346 5.4.1. Basic PCECC LSP Setup 348 In order to setup a LSP based on PCECC mechanism, a PCC MUST delegate 349 the LSP by sending a PCRpt message with PST set for PCECC (see 350 Section 7.2) and D (Delegate) flag (see [RFC8231]) set in the LSP 351 object. 353 LSP-IDENTIFIER TLV MUST be included for PCECC LSP, the tuple uniquely 354 identifies the LSP in the network. The LSP object is included in 355 central controller's instructions (label download) to identify the 356 PCECC LSP for this instruction. The PLSP-ID is the original 357 identifier used by the ingress PCC, so the transit LSR could have 358 multiple central controller instructions that have the same PLSP-ID. 359 The PLSP-ID in combination with the source (in LSP-IDENTIFIER TLV) 360 MUST be unique. The PLSP-ID is included for maintainability reasons. 361 As per [RFC8281], the LSP object could include SPEAKER-ENTITY-ID TLV 362 to identify the PCE that initiated these instructions. Also the CC- 363 ID is unique on the PCEP session as described in Section 7.3. 365 When a PCE receives PCRpt message with D flags and PST Type set, it 366 calculates the path and assigns labels along the path; and set up the 367 path by sending PCInitiate message to each node along the path of the 368 LSP. The PCC generates a Path Computation State Report (PCRpt) and 369 include the central controller's instruction (CCI) and the identified 370 LSP. The CC-ID is uniquely identify the central controller's 371 instruction within PCEP. The PCC further responds with the PCRpt 372 messages including the CCI and LSP objects. 374 Once the central controller's instructions (label operations) are 375 completed, the PCE SHOULD send the PCUpd message to the Ingress PCC. 376 The PCUpd message is as per [RFC8231] SHOULD include the path 377 information as calculated by the PCE. 379 Note that the PCECC LSPs MUST be delegated to a PCE at all times. 381 LSP deletion operation for PCECC LSP is same as defined in [RFC8231]. 382 If the PCE receives PCRpt message for LSP deletion then it does Label 383 cleanup operation as described in Section 5.4.2.2 for the 384 corresponding LSP. 386 The Basic PCECC LSP setup sequence is as shown below. 388 +-------+ +-------+ 389 |PCC | | PCE | 390 |Ingress| +-------+ 391 +------| | | 392 | PCC +-------+ | 393 | Transit| | | 394 +------| | |-- PCRpt,PLSP-ID=1, PST=TBD, D=1---->| PCECC LSP 395 |PCC +--------+ | | 396 |Egress | | | | 397 +--------+ | | | 398 | | | | 399 |<------ PCInitiate,CC-ID=X,PLSP-ID=1 ------------ | Label 400 | | | | download 401 |------- PCRpt,CC-ID=X,PLSP-ID=1 ----------------->| 402 | | | | 403 | |<----- PCInitiate,CC-ID=Y,PLSP-ID=1 ----- | Label 404 | | | | download 405 | |----- PCRpt,CC-ID=Y,PLSP-ID=1 ---------->| 406 | | | | 407 | | |<--- PCInitiate,CC-ID=Z,PLSP-ID=1 - | Label 408 | | | | download 409 | | |---- PCRpt,CC-ID=Z,PLSP-ID=1 ------>| 410 | | | | 411 | | |<-- PCUpd,PLSP-ID=1,PST=TBD, D=1-----| PCECC LSP 412 | | | | Update 413 | | | | 415 Figure 2: Basic PCECC LSP setup 417 The PCECC LSP are considered to be 'up' by default (on receipt of 418 PCUpd message from PCE). The Ingress MAY further choose to deploy a 419 data plane check mechanism and report the status back to the PCE via 420 PCRpt message. 422 5.4.2. Central Control Instructions 424 The new central controller's instructions (CCI) for the label 425 operations in PCEP is done via the PCInitiate message, by defining a 426 new PCEP Objects for CCI operations. Local label range of each PCC 427 is assumed to be known at both the PCC and the PCE. 429 5.4.2.1. Label Download 431 In order to setup an LSP based on PCECC, the PCE sends a PCInitiate 432 message to each node along the path to download the Label instruction 433 as described in Section 5.4.1. 435 The CCI object MUST be included, along with the LSP object in the 436 PCInitiate message. The LSP-IDENTIFIER TLV MUST be included in LSP 437 object. The SPEAKER-ENTITY-ID TLV SHOULD be included in LSP object. 439 If a node (PCC) receives a PCInitiate message which includes a Label 440 to download as part of CCI, that is out of the range set aside for 441 the PCE, it MUST send a PCErr message with Error-type=TBD (PCECC 442 failure) and Error-value=TBD (Label out of range) and MUST include 443 the SRP object to specify the error is for the corresponding label 444 update via PCInitiate message. If a PCC receives a PCInitiate 445 message but failed to download the Label entry, it MUST send a PCErr 446 message with Error-type=TBD (PCECC failure) and Error-value=TBD 447 (instruction failed) and MUST include the SRP object to specify the 448 error is for the corresponding label update via PCInitiate message. 450 New PCEP object for central control instructions (CCI) is defined in 451 Section 7.3. 453 5.4.2.2. Label Cleanup 455 In order to delete an LSP based on PCECC, the PCE sends a central 456 controller instructions via a PCInitiate message to each node along 457 the path of the LSP to cleanup the Label forwarding instruction. 459 If the PCC receives a PCInitiate message but does not recognize the 460 label in the CCI, the PCC MUST generate a PCErr message with Error- 461 Type 19(Invalid operation) and Error-Value=TBD, "Unknown Label" and 462 MUST include the SRP object to specify the error is for the 463 corresponding label cleanup (via PCInitiate message). 465 The R flag in the SRP object defined in [RFC8281] specifies the 466 deletion of Label Entry in the PCInitiate message. 468 +-------+ +-------+ 469 |PCC | | PCE | 470 |Ingress| +-------+ 471 +------| | | 472 | PCC +-------+ | 473 | Transit| | | 474 +------| | |-- PCRpt,PLSP-ID=1,PST=TBD,D=1,R=1--->| PCECC LSP 475 |PCC +--------+ | | remove 476 |Egress | | | | 477 +--------+ | | | 478 | | | | 479 |<------ PCInitiate,CC-ID=X,PLSP-ID=1 ------------ | Label 480 | | | R=1 | cleanup 481 |------- PCRpt,CC-ID=X,PLSP-ID=1 ------------------>| 482 | | | | 483 | |<----- PCInitiate,CC-ID=Y,PLSP-ID=1 ------ | Label 484 | | | R=1 | cleanup 485 | |----- PCRpt,CC-ID=Y,PLSP-ID=1 ----------->| 486 | | | | 487 | | |<--- PCInitiate,CC-ID=Z,PLSP-ID=1 -- | Label 488 | | | R=1 | cleanup 489 | | |---- PCRpt,CC-ID=Z,PLSP-ID=1 ------->| 490 | | | | 492 As per [RFC8281], following the removal of the Label forwarding 493 instruction, the PCC MUST send a PCRpt message. The SRP object in 494 the PCRpt MUST include the SRP-ID-number from the PCInitiate message 495 that triggered the removal. The R flag in the SRP object MUST be 496 set. 498 5.4.3. PCE Initiated PCECC LSP 500 The LSP Instantiation operation is same as defined in [RFC8281]. 502 In order to setup a PCE Initiated LSP based on the PCECC mechanism, a 503 PCE sends PCInitiate message with Path Setup Type set for PCECC (see 504 Section 7.2) to the Ingress PCC. 506 The Ingress PCC MUST also set D (Delegate) flag (see [RFC8231]) and C 507 (Create) flag (see [RFC8281]) in LSP object of PCRpt message. The 508 PCC responds with first PCRpt message with the status as "GOING-UP" 509 and assigned PLSP-ID. 511 Note that the label forwarding instructions from PCECC are send after 512 the initial PCInitiate and PCRpt exchange. This is done so that the 513 PLSP-ID and other LSP identifiers can be obtained from the ingress 514 and can be included in the label forwarding instruction in the next 515 PCInitiate message. The rest of the PCECC LSP setup operations are 516 same as those described in Section 5.4.1. 518 The LSP deletion operation for PCE Initiated PCECC LSP is same as 519 defined in [RFC8281]. The PCE should further perform Label entry 520 cleanup operation as described in Section 5.4.2.2 for the 521 corresponding LSP. 523 The PCE Initiated PCECC LSP setup sequence is shown below - 525 +-------+ +-------+ 526 |PCC | | PCE | 527 |Ingress| +-------+ 528 +------| | | 529 | PCC +-------+ | 530 | Transit| | | 531 +------| | |<--PCInitiate,PLSP-ID=0,PST=TBD,D=1---| PCECC LSP 532 |PCC +--------+ | | Initiate 533 |Egress | | |--- PCRpt,PLSP-ID=2,P=1,D=1,C=1---> | PCECC LSP 534 +--------+ | | (GOING-UP) | 535 | | | | 536 |<------ PCInitiate,CC-ID=X,PLSP-ID=2 -------------- | Label 537 | | | | download 538 |------- PCRpt,CC-ID=X,PLSP-ID=2 ------------------>| 539 | | | | 540 | |<----- PCInitiate,CC-ID=Y,PLSP-ID=2 ------- | Label 541 | | | | download 542 | |----- PCRpt,CC-ID=Y,PLSP-ID=2 ----------->| 543 | | | | 544 | | |<--- PCInitiate,CC-ID=Z,PLSP-ID=2 --- | Label 545 | | | | download 546 | | |---- PCRpt,CC-ID=Z,PLSP-ID=2 ------->| 547 | | | | 548 | | |<-- PCUpd, PLSP-ID=2, PST=TBD, D=1--- | PCECC LSP 549 | | | (UP) | Update 550 | | |--- PCRpt,PLSP-ID=2,P=1,D=1,C=1---> | 551 | | | (UP) | 553 Once the label operations are completed, the PCE SHOULD send the 554 PCUpd message to the Ingress PCC. The PCUpd message is as per 555 [RFC8231]. 557 5.4.4. PCECC LSP Update 559 In case of a modification of PCECC LSP with a new path, a PCE sends a 560 PCUpd message to the Ingress PCC. But to follow the make-before- 561 break procedures, the PCECC first update new instructions based on 562 the updated LSP and then update to ingress to switch traffic, before 563 cleaning up the old instructions. A new CC-ID is used to identify 564 the updated instruction, the existing identifiers in the LSP object 565 identify the existing LSP. Once new instructions are downloaded, the 566 PCE further updates the new path at the ingress which triggers the 567 traffic switch on the updated path. The Ingress PCC acknowledges 568 with a PCRpt message, on receipt of PCRpt message, the PCE does 569 cleanup operation for the old LSP as described in Section 5.4.2.2. 571 The PCECC LSP Update sequence is shown below - 572 +-------+ +-------+ 573 |PCC | | PCE | 574 |Ingress| +-------+ 575 +------| | | 576 | PCC +-------+ | 577 | Transit| | | 578 +------| | | | 579 |PCC +--------+ | | 580 |Egress | | | | 581 +--------+ | | | 582 | | | | New Path for 583 |<------ PCInitiate,CC-ID=XX,PLSP-ID=1 ----------- | LSP trigger 584 | | | | new instruct 585 |------- PCRpt,CC-ID=XX,PLSP-ID=1 ---------------->| 586 | | | | 587 | |<----- PCInitiate,CC-ID=YY,PLSP-ID=1------ | Label 588 | | | | download 589 | |----- PCRpt,CC-ID=YY,PLSP-ID=1 --------->| 590 | | | | 591 | | |<--- PCInitiate,CC-ID=ZZ,PLSP-ID=1 - | Label 592 | | | | download 593 | | |---- PCRpt,CC-ID=ZZ,PLSP-ID=1 ----->| 594 | | | | 595 | | |<-- PCUpd, PLSP-ID=1, PST=TBD, D=1-- | PCECC 596 | | | SRP=S | LSP Update 597 | | | | 598 | | |-- PCRpt,PLSP-ID=1,PST=TBD,D=1 -->| Trigger 599 | | | (SRP=S) | Delete old 600 | | | | instruct 601 | | | | 602 |<------ PCInitiate,CC-ID=X, PLSP-ID=1 ----------- | Label 603 | | | R=1 | cleanup 604 |------- PCRpt,CC-ID=X, PLSP-ID=1 ---------------->| 605 | | | | 606 | |<----- PCInitiate,CC-ID=Y, PLSP-ID=1 ----- | Label 607 | | | R=1 | cleanup 608 | |----- PCRpt,CC-ID=Y, PLSP-ID=1 --------->| 609 | | | | 610 | | |<--- PCInitiate,CC-ID=Z, PLSP-ID=1 - | Label 611 | | | R=1 | cleanup 612 | | |---- PCRpt,CC-ID=Z, PLSP-ID=1 ----->| 613 | | | | 615 The modified PCECC LSP are considered to be 'up' by default. The 616 Ingress MAY further choose to deploy a data plane check mechanism and 617 report the status back to the PCE via PCRpt message. 619 5.4.5. Re Delegation and Cleanup 621 As described in [RFC8281], a new PCE can gain control over the 622 orphaned LSP. In case of PCECC LSP, the new PCE MUST also gain 623 control over the central controllers instructions in the same way by 624 sending a PCInitiate message that includes the SRP, LSP and CCI 625 objects and carries the CC-ID and PLSP-ID identifying the 626 instruction, it wants to take control of. 628 Further, as described in [RFC8281], the State Timeout Interval timer 629 ensures that a PCE crash does not result in automatic and immediate 630 disruption for the services using PCE-initiated LSPs. Similarly the 631 central controller instructions are not removed immediately upon PCE 632 failure. Instead, they are cleaned up on the expiration of this 633 timer. This allows for network cleanup without manual intervention. 634 The PCC MUST support removal of CCI as one of the behaviors applied 635 on expiration of the State Timeout Interval timer. 637 5.4.6. Synchronization of Central Controllers Instructions 639 The purpose of Central Controllers Instructions synchronization 640 (labels in the context of this document) is to make sure that the 641 PCE's view of CCI (Labels) matches with the PCC's Label allocation. 642 This synchronization is performed as part of the LSP state 643 synchronization as described in [RFC8231] and [RFC8233]. 645 As per LSP State Synchronization [RFC8231], a PCC reports the state 646 of its LSPs to the PCE using PCRpt messages and as per [RFC8281], PCE 647 would initiate any missing LSPs and/or remove any LSPs that are not 648 wanted. The same PCEP messages and procedure is also used for the 649 Central Controllers Instructions synchronization. The PCRpt message 650 includes the CCI and the LSP object to report the label forwarding 651 instructions. The PCE would further remove any unwanted instructions 652 or initiate any missing instructions. 654 5.4.7. PCECC LSP State Report 656 As mentioned before, an Ingress PCC MAY choose to apply any OAM 657 mechanism to check the status of LSP in the Data plane and MAY 658 further send its status in PCRpt message to the PCE. 660 6. PCEP messages 662 As defined in [RFC5440], a PCEP message consists of a common header 663 followed by a variable-length body made of a set of objects that can 664 be either mandatory or optional. An object is said to be mandatory 665 in a PCEP message when the object must be included for the message to 666 be considered valid. For each PCEP message type, a set of rules is 667 defined that specify the set of objects that the message can carry. 668 An implementation MUST form the PCEP messages using the object 669 ordering specified in this document. 671 LSP-IDENTIFIERS TLV MUST be included in the LSP object for PCECC LSP. 673 6.1. The PCInitiate message 675 The PCInitiate message [RFC8281] can be used to download or remove 676 the labels, the message has been extended as shown below - 678 ::= 679 680 Where: 681 is defined in [RFC5440] 683 ::= 684 [] 686 ::= 687 (| 688 | 689 ) 691 ::= 692 693 695 ::= 696 [] 698 Where: 699 and 700 are as per 701 [RFC8281]. 703 The LSP and SRP object is defined in [RFC8231]. 705 When PCInitiate message is used for central controller's instructions 706 (labels), the SRP, LSP and CCI objects MUST be present. The SRP 707 object is defined in [RFC8231] and if the SRP object is missing, the 708 receiving PCC MUST send a PCErr message with Error-type=6 (Mandatory 709 Object missing) and Error-value=10 (SRP object missing). The LSP 710 object is defined in [RFC8231] and if the LSP object is missing, the 711 receiving PCC MUST send a PCErr message with Error-type=6 (Mandatory 712 Object missing) and Error-value=8 (LSP object missing). The CCI 713 object is defined in Section 7.3 and if the CCI object is missing, 714 the receiving PCC MUST send a PCErr message with Error-type=6 715 (Mandatory Object missing) and Error-value=TBD (CCI object missing). 716 More than one CCI object MAY be included in the PCInitiate message 717 for the transit LSR. 719 To cleanup the SRP object must set the R (remove) bit. 721 At max two instances of CCI object would be included in case of 722 transit LSR to encode both in-coming and out-going label forwarding 723 instructions. Other instances MUST be ignored. 725 6.2. The PCRpt message 727 The PCRpt message can be used to report the labels that were 728 allocated by the PCE, to be used during the state synchronization 729 phase. 731 ::= 732 733 Where: 735 ::= [] 737 ::= (| 738 ) 740 ::= [] 741 742 744 ::= [] 745 746 748 ::= 749 [] 751 Where: 752 is as per [RFC8231] and the LSP and SRP object are 753 also defined in [RFC8231]. 755 When PCRpt message is used to report the central controller's 756 instructions (labels), the LSP and CCI objects MUST be present. The 757 LSP object is defined in [RFC8231] and if the LSP object is missing, 758 the receiving PCE MUST send a PCErr message with Error-type=6 759 (Mandatory Object missing) and Error-value=8 (LSP object missing). 761 The CCI object is defined in Section 7.3 and if the CCI object is 762 missing, the receiving PCC MUST send a PCErr message with Error- 763 type=6 (Mandatory Object missing) and Error-value=TBD (CCI object 764 missing). Two CCI object can be included in the PCRpt message for 765 the transit LSR. 767 7. PCEP Objects 769 The PCEP objects defined in this document are compliant with the PCEP 770 object format defined in [RFC5440]. 772 7.1. OPEN Object 774 This document defines a new optional TLVs for use in the OPEN Object. 776 7.1.1. PCECC Capability sub-TLV 778 The PCECC-CAPABILITY sub-TLV is an optional TLV for use in the OPEN 779 Object for PCECC capability advertisement in PATH-SETUP-TYPE- 780 CAPABILITY TLV. Advertisement of the PCECC capability implies 781 support of LSPs that are setup through PCECC as per PCEP extensions 782 defined in this document. 784 Its format is shown in the following figure: 786 0 1 2 3 787 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 788 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 789 | Type=TBD | Length=4 | 790 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 791 | Flags | 792 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 794 The type of the TLV is TBD and it has a fixed length of 4 octets. 796 The value comprises a single field - Flags (32 bits). 798 No flags are assigned right now. 800 Unassigned bits are considered reserved. They MUST be set to 0 on 801 transmission and MUST be ignored on receipt. 803 7.2. PATH-SETUP-TYPE TLV 805 The PATH-SETUP-TYPE TLV is defined in [I-D.ietf-pce-lsp-setup-type]; 806 this document defines a new PST value: 808 o PST = TBD: Path is setup via PCECC mode. 810 On a PCRpt/PCUpd/PCInitiate message, the PST=TBD in PATH-SETUP-TYPE 811 TLV in SRP object indicates that this LSP was setup via a PCECC based 812 mechanism. 814 7.3. CCI Object 816 The Central Control Instructions (CCI) Object is used by the PCE to 817 specify the forwarding instructions (Label information in the context 818 of this document) to the PCC, and MAY be carried within PCInitiate or 819 PCRpt message for label download. 821 CCI Object-Class is TBD. 823 CCI Object-Type is 1 for the MPLS Label. 825 0 1 2 3 826 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 827 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 828 | CC-ID | 829 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 830 | Reserved | Flags |O| 831 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 832 | Label | Reserved | 833 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 834 | | 835 // Optional TLV // 836 | | 837 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 839 The fields in the CCI object are as follows: 841 CC-ID: A PCEP-specific identifier for the CCI information. A PCE 842 creates an CC-ID for each instruction, the value is unique within 843 the scope of the PCE and is constant for the lifetime of a PCEP 844 session. The values 0 and 0xFFFFFFFF are reserved and MUST NOT be 845 used. 847 Flags: is used to carry any additional information pertaining to the 848 CCI. Currently, the following flag bit is defined: 850 * O bit(Out-label) : If the bit is set, it specifies the label is 851 the OUT label and it is mandatory to encode the next-hop 852 information (via IPV4-ADDRESS TLV or IPV6-ADDRESS TLV or 853 UNNUMBERED-IPV4-ID-ADDRESS TLV in the CCI object). If the bit 854 is not set, it specifies the label is the IN label and it is 855 optional to encode the local interface information (via 856 IPV4-ADDRESS TLV or IPV6-ADDRESS TLV or UNNUMBERED-IPV4-ID- 857 ADDRESS TLV in the CCI object). 859 Label (20-bit): The Label information. 861 Reserved (12 bit): Set to zero while sending, ignored on receive. 863 7.3.1. Address TLVs 865 This document defines the following TLVs for the CCI object to 866 associate the next-hop information in case of an outgoing label and 867 local interface information in case of an incoming label. 869 IPV4-ADDRESS TLV: 871 0 1 2 3 872 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 873 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 874 | Type=TBD | Length = 4 | 875 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 876 | IPv4 address | 877 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 879 IPV6-ADDRESS TLV: 881 0 1 2 3 882 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 883 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 884 | Type=TBD | Length = 16 | 885 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 886 | | 887 // IPv6 address (16 bytes) // 888 | | 889 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 891 UNNUMBERED-IPV4-ID-ADDRESS TLV: 893 0 1 2 3 894 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 895 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 896 | Type=TBD | Length = 8 | 897 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 898 | Node-ID | 899 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 900 | Interface ID | 901 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 903 The address TLVs are as follows: 905 IPV4-ADDRESS TLV: an IPv4 address. 907 IPV6-ADDRESS TLV: an IPv6 address. 909 UNNUMBERED-IPV4-ID-ADDRESS TLV: a pair of Node ID / Interface ID 910 tuples. 912 8. Security Considerations 914 The security considerations described in [RFC8231] and [RFC8281] 915 apply to the extensions described in this document. Additional 916 considerations related to a malicious PCE are introduced. 918 8.1. Malicious PCE 920 PCE has complete control over PCC to update the labels and can cause 921 the LSP's to behave inappropriate and cause cause major impact to the 922 network. As a general precaution, it is RECOMMENDED that these PCEP 923 extensions only be activated on authenticated and encrypted sessions 924 across PCEs and PCCs belonging to the same administrative authority, 925 using Transport Layer Security (TLS) [RFC8253], as per the 926 recommendations and best current practices in [RFC7525]. 928 9. Manageability Considerations 930 9.1. Control of Function and Policy 932 A PCE or PCC implementation SHOULD allow to configure to enable/ 933 disable PCECC capability as a global configuration. 935 9.2. Information and Data Models 937 [RFC7420] describes the PCEP MIB, this MIB can be extended to get the 938 PCECC capability status. 940 The PCEP YANG module [I-D.ietf-pce-pcep-yang] could be extended to 941 enable/disable PCECC capability. 943 9.3. Liveness Detection and Monitoring 945 Mechanisms defined in this document do not imply any new liveness 946 detection and monitoring requirements in addition to those already 947 listed in [RFC5440]. 949 9.4. Verify Correct Operations 951 Mechanisms defined in this document do not imply any new operation 952 verification requirements in addition to those already listed in 953 [RFC5440] and [RFC8231]. 955 9.5. Requirements On Other Protocols 957 PCEP extensions defined in this document do not put new requirements 958 on other protocols. 960 9.6. Impact On Network Operations 962 PCEP extensions defined in this document do not put new requirements 963 on network operations. 965 10. IANA Considerations 967 10.1. PCEP TLV Type Indicators 969 IANA is requested to confirm the early allocation of the following 970 TLV Type Indicator values within the "PCEP TLV Type Indicators" sub- 971 registry of the PCEP Numbers registry, and to update the reference in 972 the registry to point to this document, when it is an RFC: 974 Value Meaning Reference 975 TBD PCECC-CAPABILITY This document 976 TBD IPV4-ADDRESS TLV This document 977 TBD IPV6-ADDRESS TLV This document 978 TBD UNNUMBERED-IPV4-ID-ADDRESS TLV This document 980 10.2. New Path Setup Type Registry 982 IANA is requested to allocate new PST Field in PATH- SETUP-TYPE TLV. 983 The allocation policy for this new registry should be by IETF 984 Consensus. The new registry should contain the following value: 986 Value Description Reference 987 TBD Traffic engineering path is This document 988 setup using PCECC mode 990 10.3. PCEP Object 992 IANA is requested to allocate new registry for CCI PCEP object. 994 Object-Class Value Name Reference 995 TBD CCI Object-Type This document 996 1 MPLS Label 998 10.4. CCI Object Flag Field 1000 IANA is requested to create a registry to manage the Flag field of 1001 the CCI object. 1003 One bit to be defined for the CCI Object flag field in this document: 1005 Codespace of the Flag field (CCI Object) 1006 Bit Description Reference 1007 7 Specifies label This document 1008 is out label 1010 10.5. PCEP-Error Object 1012 IANA is requested to allocate new error types and error values within 1013 the "PCEP-ERROR Object Error Types and Values" sub-registry of the 1014 PCEP Numbers registry for the following errors: 1016 Error-Type Meaning 1017 ---------- ------- 1018 19 Invalid operation. 1020 Error-value = TBD : Attempted PCECC 1021 operations when 1022 PCECC capability 1023 was not advertised 1024 Error-value = TBD : Stateful PCE 1025 capability was not 1026 advertised 1027 Error-value = TBD : Unknown Label 1028 6 Mandatory Object missing. 1030 Error-value = TBD : CCI object missing 1031 TBD PCECC failure. 1033 Error-value = TBD : Label out of range. 1034 Error-value = TBD : Instruction failed. 1036 11. Acknowledgments 1038 We would like to thank Robert Tao, Changjing Yan, Tieying Huang and 1039 Avantika for their useful comments and suggestions. 1041 12. References 1043 12.1. Normative References 1045 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1046 Requirement Levels", BCP 14, RFC 2119, 1047 DOI 10.17487/RFC2119, March 1997, 1048 . 1050 [RFC5440] Vasseur, JP., Ed. and JL. Le Roux, Ed., "Path Computation 1051 Element (PCE) Communication Protocol (PCEP)", RFC 5440, 1052 DOI 10.17487/RFC5440, March 2009, 1053 . 1055 [RFC7420] Koushik, A., Stephan, E., Zhao, Q., King, D., and J. 1056 Hardwick, "Path Computation Element Communication Protocol 1057 (PCEP) Management Information Base (MIB) Module", 1058 RFC 7420, DOI 10.17487/RFC7420, December 2014, 1059 . 1061 [RFC7525] Sheffer, Y., Holz, R., and P. Saint-Andre, 1062 "Recommendations for Secure Use of Transport Layer 1063 Security (TLS) and Datagram Transport Layer Security 1064 (DTLS)", BCP 195, RFC 7525, DOI 10.17487/RFC7525, May 1065 2015, . 1067 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 1068 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 1069 May 2017, . 1071 [RFC8231] Crabbe, E., Minei, I., Medved, J., and R. Varga, "Path 1072 Computation Element Communication Protocol (PCEP) 1073 Extensions for Stateful PCE", RFC 8231, 1074 DOI 10.17487/RFC8231, September 2017, 1075 . 1077 [RFC8233] Dhody, D., Wu, Q., Manral, V., Ali, Z., and K. Kumaki, 1078 "Extensions to the Path Computation Element Communication 1079 Protocol (PCEP) to Compute Service-Aware Label Switched 1080 Paths (LSPs)", RFC 8233, DOI 10.17487/RFC8233, September 1081 2017, . 1083 [RFC8281] Crabbe, E., Minei, I., Sivabalan, S., and R. Varga, "Path 1084 Computation Element Communication Protocol (PCEP) 1085 Extensions for PCE-Initiated LSP Setup in a Stateful PCE 1086 Model", RFC 8281, DOI 10.17487/RFC8281, December 2017, 1087 . 1089 12.2. Informative References 1091 [RFC4655] Farrel, A., Vasseur, J., and J. Ash, "A Path Computation 1092 Element (PCE)-Based Architecture", RFC 4655, 1093 DOI 10.17487/RFC4655, August 2006, 1094 . 1096 [RFC7025] Otani, T., Ogaki, K., Caviglia, D., Zhang, F., and C. 1097 Margaria, "Requirements for GMPLS Applications of PCE", 1098 RFC 7025, DOI 10.17487/RFC7025, September 2013, 1099 . 1101 [RFC7399] Farrel, A. and D. King, "Unanswered Questions in the Path 1102 Computation Element Architecture", RFC 7399, 1103 DOI 10.17487/RFC7399, October 2014, 1104 . 1106 [RFC7491] King, D. and A. Farrel, "A PCE-Based Architecture for 1107 Application-Based Network Operations", RFC 7491, 1108 DOI 10.17487/RFC7491, March 2015, 1109 . 1111 [RFC8253] Lopez, D., Gonzalez de Dios, O., Wu, Q., and D. Dhody, 1112 "PCEPS: Usage of TLS to Provide a Secure Transport for the 1113 Path Computation Element Communication Protocol (PCEP)", 1114 RFC 8253, DOI 10.17487/RFC8253, October 2017, 1115 . 1117 [RFC8283] Farrel, A., Ed., Zhao, Q., Ed., Li, Z., and C. Zhou, "An 1118 Architecture for Use of PCE and the PCE Communication 1119 Protocol (PCEP) in a Network with Central Control", 1120 RFC 8283, DOI 10.17487/RFC8283, December 2017, 1121 . 1123 [I-D.ietf-teas-pcecc-use-cases] 1124 Zhao, Q., Li, Z., Khasanov, B., Ke, Z., Fang, L., Zhou, 1125 C., Communications, T., and A. Rachitskiy, "The Use Cases 1126 for Using PCE as the Central Controller(PCECC) of LSPs", 1127 draft-ietf-teas-pcecc-use-cases-01 (work in progress), May 1128 2017. 1130 [I-D.ietf-pce-lsp-setup-type] 1131 Sivabalan, S., Tantsura, J., Minei, I., Varga, R., and J. 1132 Hardwick, "Conveying path setup type in PCEP messages", 1133 draft-ietf-pce-lsp-setup-type-10 (work in progress), May 1134 2018. 1136 [I-D.ietf-pce-pcep-yang] 1137 Dhody, D., Hardwick, J., Beeram, V., and J. Tantsura, "A 1138 YANG Data Model for Path Computation Element 1139 Communications Protocol (PCEP)", draft-ietf-pce-pcep- 1140 yang-07 (work in progress), March 2018. 1142 [I-D.zhao-pce-pcep-extension-pce-controller-sr] 1143 Zhao, Q., Li, Z., Dhody, D., Karunanithi, S., Farrel, A., 1144 and C. Zhou, "PCEP Procedures and Protocol Extensions for 1145 Using PCE as a Central Controller (PCECC) of SR-LSPs", 1146 draft-zhao-pce-pcep-extension-pce-controller-sr-02 (work 1147 in progress), March 2018. 1149 Appendix A. Contributor Addresses 1151 Udayasree Palle 1152 Huawei Technologies 1153 Divyashree Techno Park, Whitefield 1154 Bangalore, Karnataka 560066 1155 India 1157 EMail: udayasreereddy@gmail.com 1159 Mahendra Singh Negi 1160 Huawei Technologies 1161 Divyashree Techno Park, Whitefield 1162 Bangalore, Karnataka 560066 1163 India 1165 EMail: mahendrasingh@huawei.com 1167 Katherine Zhao 1168 Huawei Technologies 1169 2330 Central Expressway 1170 Santa Clara, CA 95050 1171 USA 1173 EMail: katherine.zhao@huawei.com 1175 Boris Zhang 1176 Telus Ltd. 1177 Toronto 1178 Canada 1180 EMail: boris.zhang@telus.com 1182 Authors' Addresses 1184 Quintin Zhao 1185 Huawei Technologies 1186 125 Nagog Technology Park 1187 Acton, MA 01719 1188 USA 1190 EMail: quintin.zhao@huawei.com 1191 Zhenbin Li 1192 Huawei Technologies 1193 Huawei Bld., No.156 Beiqing Rd. 1194 Beijing 100095 1195 China 1197 EMail: lizhenbin@huawei.com 1199 Dhruv Dhody 1200 Huawei Technologies 1201 Divyashree Techno Park, Whitefield 1202 Bangalore, Karnataka 560066 1203 India 1205 EMail: dhruv.ietf@gmail.com 1207 Satish Karunanithi 1208 Huawei Technologies 1209 Divyashree Techno Park, Whitefield 1210 Bangalore, Karnataka 560066 1211 India 1213 EMail: satishk@huawei.com 1215 Adrian Farrel 1216 Juniper Networks, Inc 1217 UK 1219 EMail: adrian@olddog.co.uk 1221 Chao Zhou 1222 Cisco Systems 1224 EMail: choa.zhou@cisco.com