idnits 2.17.1 draft-zhao-pce-pcep-extension-for-pce-controller-07.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 (March 4, 2018) is 2244 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 (-10) exists of draft-ietf-pce-lsp-setup-type-08 == Outdated reference: A later version (-23) exists of draft-ietf-pce-pcep-yang-06 == Outdated reference: A later version (-09) exists of draft-zhao-pce-pcep-extension-pce-controller-sr-01 == Outdated reference: A later version (-03) exists of draft-palle-pce-controller-labeldb-sync-02 Summary: 1 error (**), 0 flaws (~~), 6 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: September 5, 2018 S. Karunanithi 6 Huawei Technologies 7 A. Farrel 8 Juniper Networks, Inc 9 C. Zhou 10 Cisco Systems 11 March 4, 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-07 17 Abstract 19 In certain networks deployment scenarios, service providers would 20 like to keep all the existing MPLS functionalities in both MPLS and 21 GMPLS while removing the complexity of existing signaling protocols 22 such as LDP and RSVP-TE. PCE has been proposed to be used as a 23 central controller (PCECC) so that LSP can be calculated/setup/ 24 initiated and label forwarding entries are downloaded through a 25 centralized PCE server to each network devices along the path while 26 leveraging the existing PCE technologies as much as possible. 28 This draft specify the procedures and PCEP protocol extensions for 29 using the PCE as the central controller, where LSPs are 30 calculated/setup/initiated and label forwarding entries are 31 downloaded through extending PCEP. 33 Status of This Memo 35 This Internet-Draft is submitted in full conformance with the 36 provisions of BCP 78 and BCP 79. 38 Internet-Drafts are working documents of the Internet Engineering 39 Task Force (IETF). Note that other groups may also distribute 40 working documents as Internet-Drafts. The list of current Internet- 41 Drafts is at https://datatracker.ietf.org/drafts/current/. 43 Internet-Drafts are draft documents valid for a maximum of six months 44 and may be updated, replaced, or obsoleted by other documents at any 45 time. It is inappropriate to use Internet-Drafts as reference 46 material or to cite them other than as "work in progress." 48 This Internet-Draft will expire on September 5, 2018. 50 Copyright Notice 52 Copyright (c) 2018 IETF Trust and the persons identified as the 53 document authors. All rights reserved. 55 This document is subject to BCP 78 and the IETF Trust's Legal 56 Provisions Relating to IETF Documents 57 (https://trustee.ietf.org/license-info) in effect on the date of 58 publication of this document. Please review these documents 59 carefully, as they describe your rights and restrictions with respect 60 to this document. Code Components extracted from this document must 61 include Simplified BSD License text as described in Section 4.e of 62 the Trust Legal Provisions and are provided without warranty as 63 described in the Simplified BSD License. 65 Table of Contents 67 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 68 1.1. Requirements Language . . . . . . . . . . . . . . . . . . 4 69 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5 70 3. Basic PCECC Mode . . . . . . . . . . . . . . . . . . . . . . 5 71 4. PCEP Requirements . . . . . . . . . . . . . . . . . . . . . . 5 72 5. Procedures for Using the PCE as the Central Controller 73 (PCECC) . . . . . . . . . . . . . . . . . . . . . . . . . . . 6 74 5.1. Stateful PCE Model . . . . . . . . . . . . . . . . . . . 6 75 5.2. New LSP Functions . . . . . . . . . . . . . . . . . . . . 6 76 5.3. PCECC Capability Advertisement . . . . . . . . . . . . . 7 77 5.4. LSP Operations . . . . . . . . . . . . . . . . . . . . . 8 78 5.4.1. Basic PCECC LSP Setup . . . . . . . . . . . . . . . . 8 79 5.4.2. Label Operations . . . . . . . . . . . . . . . . . . 9 80 5.4.2.1. Label Download . . . . . . . . . . . . . . . . . 10 81 5.4.2.2. Label Cleanup . . . . . . . . . . . . . . . . . . 10 82 5.4.3. PCE Initiated PCECC LSP . . . . . . . . . . . . . . . 11 83 5.4.4. PCECC LSP Update . . . . . . . . . . . . . . . . . . 12 84 5.4.5. Session Termination . . . . . . . . . . . . . . . . . 13 85 5.4.6. LABEL-DB Synchronization . . . . . . . . . . . . . . 14 86 5.4.6.1. LABEL-DB Synchronization procedure . . . . . . . 14 87 5.4.7. PCECC LSP State Report . . . . . . . . . . . . . . . 17 88 6. PCEP messages . . . . . . . . . . . . . . . . . . . . . . . . 17 89 6.1. Label Operations . . . . . . . . . . . . . . . . . . . . 17 90 6.1.1. The PCLabelUpd message . . . . . . . . . . . . . . . 17 91 6.1.2. The PCLabelRpt message . . . . . . . . . . . . . . . 18 92 6.1.3. The PCInitiate message . . . . . . . . . . . . . . . 20 93 7. PCEP Objects . . . . . . . . . . . . . . . . . . . . . . . . 20 94 7.1. OPEN Object . . . . . . . . . . . . . . . . . . . . . . . 20 95 7.1.1. PCECC Capability sub-TLV . . . . . . . . . . . . . . 20 96 7.2. PATH-SETUP-TYPE TLV . . . . . . . . . . . . . . . . . . . 21 97 7.3. Label Object . . . . . . . . . . . . . . . . . . . . . . 21 98 7.3.1. Address TLVs . . . . . . . . . . . . . . . . . . . . 22 99 7.4. Extension of SRP object . . . . . . . . . . . . . . . . . 23 100 8. Security Considerations . . . . . . . . . . . . . . . . . . . 23 101 8.1. Malicious PCE . . . . . . . . . . . . . . . . . . . . . . 23 102 9. Manageability Considerations . . . . . . . . . . . . . . . . 24 103 9.1. Control of Function and Policy . . . . . . . . . . . . . 24 104 9.2. Information and Data Models . . . . . . . . . . . . . . . 24 105 9.3. Liveness Detection and Monitoring . . . . . . . . . . . . 24 106 9.4. Verify Correct Operations . . . . . . . . . . . . . . . . 24 107 9.5. Requirements On Other Protocols . . . . . . . . . . . . . 24 108 9.6. Impact On Network Operations . . . . . . . . . . . . . . 24 109 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 24 110 10.1. PCLabelUpd-PCLabelRpt message . . . . . . . . . . . . . 25 111 10.2. PCEP TLV Type Indicators . . . . . . . . . . . . . . . . 25 112 10.3. New Path Setup Type Registry . . . . . . . . . . . . . . 25 113 10.4. PCEP Object . . . . . . . . . . . . . . . . . . . . . . 25 114 10.5. LABEL Object Flag Field . . . . . . . . . . . . . . . . 25 115 10.6. SRP Object Flag Field . . . . . . . . . . . . . . . . . 26 116 10.7. PCEP-Error Object . . . . . . . . . . . . . . . . . . . 26 117 11. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 27 118 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 27 119 12.1. Normative References . . . . . . . . . . . . . . . . . . 27 120 12.2. Informative References . . . . . . . . . . . . . . . . . 28 121 Appendix A. Using existing PCEP message . . . . . . . . . . . . 30 122 Appendix B. Contributor Addresses . . . . . . . . . . . . . . . 31 123 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 32 125 1. Introduction 127 In certain network deployment scenarios, service providers would like 128 to have the ability to dynamically adapt to a wide range of 129 customer's requests for the sake of flexible network service 130 delivery, Software-Defined Networks (SDN) has provides additional 131 flexibility in how the network is operated compared to the 132 traditional network. 134 The existing networking ecosystem has become awfully complex and 135 highly demanding in terms of robustness, performance, scalability, 136 flexibility, agility, etc. By migrating to the SDN enabled network 137 from the existing network, service providers and network operators 138 must have a solution which they can evolve easily from the existing 139 network into the SDN enabled network while keeping the network 140 services remain scalable, guarantee robustness and availability etc. 142 Taking the smooth transition between traditional network and the new 143 SDN enabled network into account, especially from a cost impact 144 assessment perspective, using the existing PCE components from the 145 current network to function as the central controller of the SDN 146 network is one choice, which not only achieves the goal of having a 147 centralized controller, but also leverage the existing PCE network 148 components. 150 The Path Computation Element communication Protocol (PCEP) provides 151 mechanisms for Path Computation Elements (PCEs) to perform route 152 computations in response to Path Computation Clients (PCCs) requests. 153 PCEP Extensions for PCE-initiated LSP Setup in a Stateful PCE Model 154 [RFC8231] describes a set of extensions to PCEP to enable active 155 control of MPLS-TE and GMPLS tunnels. 157 [RFC8281] describes the setup and tear down of PCE-initiated LSPs 158 under the active stateful PCE model, without the need for local 159 configuration on the PCC, thus allowing for a dynamic MPLS network 160 that is centrally controlled and deployed. 162 [RFC8283] introduces the architecture for PCE as a central 163 controller, examines the motivations and applicability for PCEP as a 164 Southbound Interface (SBI), and introduces the implications for the 165 protocol. [I-D.ietf-teas-pcecc-use-cases] describes the use cases 166 for the PCECC architecture. 168 This draft specify the procedures and PCEP protocol extensions for 169 using the PCE as the central controller and user cases where LSPs are 170 calculated/setup/initiated/downloaded through extending the existing 171 PCE architectures and PCEP. 173 The extension for PCECC in Segment Routing (SR) is specified in a 174 seperate draft [I-D.zhao-pce-pcep-extension-pce-controller-sr]. 176 [Important Note - Note that this document achieves this by defining a 177 new PCEP message. The authors and WG also debated on the use of 178 existing PCEP messages. Section 5 defines the first approach where 179 as Appendix A defines the latter. The authors are open to either of 180 the approach and will follow the direction of the WG.] 182 1.1. Requirements Language 184 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 185 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 186 "OPTIONAL" in this document are to be interpreted as described in BCP 187 14 [RFC2119] [RFC8174] when, and only when, they appear in all 188 capitals, as shown here. 190 2. Terminology 192 Terminologies used in this document is same as described in the draft 193 [RFC8283] and [I-D.ietf-teas-pcecc-use-cases]. 195 3. Basic PCECC Mode 197 In this mode LSPs are provisioned as explicit label instructions at 198 each hop on the end-to-end path. Each router along the path must be 199 told what label forwarding instructions to program and what resources 200 to reserve. The controller uses PCEP to communicate with each router 201 along the path of the end-to-end LSP. 203 Note that the PCE-based controller will take responsibility for 204 managing some part of the MPLS label space for each of the routers 205 that it controls, and may taker wider responsibility for partitioning 206 the label space for each router and allocating different parts for 207 different uses. This is also described in section 3.1.2. of 208 [RFC8283]. For the purpose of this document, it is assumed that 209 label range to be used by a PCE is known and set on both PCEP peers. 210 A future extension MAY add capability to advertise the range via 211 possible PCEP extensions as well. The rest of processing is similar 212 to the existing stateful PCE mechanism. 214 4. PCEP Requirements 216 Following key requirements associated PCECC should be considered when 217 designing the PCECC based solution: 219 1. PCEP speaker supporting this draft MUST have the capability to 220 advertise its PCECC capability to its peers. 222 2. PCEP speaker not supporting this draft MUST be able to reject 223 PCECC related extentions with a reason code that indicates no 224 support for PCECC. 226 3. PCEP SHOULD provide a means to identify PCECC based LSP in the 227 PCEP messages. 229 4. PCEP SHOULD provide a means to update (or cleanup) the label- 230 download entry to the PCC. 232 5. PCEP SHOULD provide a means to synchronize the labels between PCE 233 to PCC in PCEP messages. 235 5. Procedures for Using the PCE as the Central Controller (PCECC) 237 5.1. Stateful PCE Model 239 Active stateful PCE is described in [RFC8231]. PCE as a central 240 controller (PCECC) reuses existing Active stateful PCE mechanism as 241 much as possible to control the LSP. 243 5.2. New LSP Functions 245 This document defines the following new PCEP messages and extends the 246 existing messages to support PCECC: 248 (PCRpt): a PCEP message described in [RFC8231]. PCRpt message is 249 used to send PCECC LSP Reports. 251 (PCInitiate): a PCEP message described in [RFC8281]. PCInitiate 252 message is used to setup PCE-Initiated LSP based on PCECC 253 mechanism. 255 (PCUpd): a PCEP message described in [RFC8231]. PCUpd message is 256 used to send PCECC LSP Update. 258 (PCLabelUpd): a new PCEP message sent by a PCE to a PCC to download 259 or cleanup the Label entry. The PCLabelUpd message described in 260 Section 6.1.1. 262 (PCLabelRpt): a new PCEP message sent by a PCC to a PCE to report 263 the set of labels for which explicit action is required from PCE 264 to update or cleanup or do nothing for these Label entries. The 265 PCLabelRpt message described in Section 6.1.2. 267 [Editor's Note: This document defines new messages PCLabelUpd and 268 PCLabelRpt. The authors and WG also debated on the use of existing 269 PCEP messages. See Appendix A on how the existing messages can be 270 extended to add this functionality. WG needs to decide the final 271 direction i.e. new specific messages are needed or existing PCEP 272 messages can be extended.] 274 The new LSP functions defined in this document are mapped onto the 275 messages as shown in the following table. 277 +----------------------------------------+--------------------------+ 278 | Function | Message | 279 +----------------------------------------+--------------------------+ 280 | PCECC Capability advertisement | Open | 281 | Label entry Update | PCLabelUpd | 282 | | (or PCInitiate) | 283 | Label entry Cleanup | PCLabelUpd | 284 | | (or PCInitiate) | 285 | PCECC Initiated LSP | PCInitiate | 286 | PCECC LSP Update | PCUpd | 287 | PCECC LSP State Report | PCRpt | 288 | PCECC LSP Delegation | PCRpt | 289 | PCECC Label Report | PCLabelRpt | 290 | | (or PCRpt) | 291 +----------------------------------------+--------------------------+ 293 5.3. PCECC Capability Advertisement 295 During PCEP Initialization Phase, PCEP Speakers (PCE or PCC) 296 advertise their support of PCECC extensions. 298 This document defines a new Path Setup Type (PST) 299 [I-D.ietf-pce-lsp-setup-type] for PCECC, as follows: 301 o PST = TBD: Path is setup via PCECC mode. 303 A PCEP speaker SHOULD indicate its support of the function described 304 in this document by sending a PATH-SETUP-TYPE-CAPABILITY TLV in the 305 OPEN object with this new PST included in the PST list. 307 This document also defines the PCECC Capability sub-TLV 308 Section 7.1.1. PCEP speakers use this sub-TLV to exchange 309 information about their PCECC capability. If a PCEP speaker includes 310 PST=TBD in the PST List of the PATH-SETUP-TYPE-CAPABILITY TLV then it 311 MUST also include the PCECC Capability sub-TLV inside the PATH-SETUP- 312 TYPE-CAPABILITY TLV. 314 The presence of the PST and PCECC Capability sub-TLV in PCC's OPEN 315 Object indicates that the PCC is willing to function as a PCECC 316 client. 318 The presence of the PST and PCECC Capability sub-TLV in PCE's OPEN 319 message indicates that the PCE is interested in function as a PCECC 320 server. 322 The PCEP protocol extensions for PCECC MUST NOT be used if one or 323 both PCEP Speakers have not included the PST or the PCECC Capability 324 sub-TLV in their respective OPEN message. If the PCEP Speakers 325 support the extensions of this draft but did not advertise this 326 capability then a PCErr message with Error-Type=19(Invalid Operation) 327 and Error-Value=TBD (Attempted LSP setup/download/label-range 328 reservation if PCECC capability was not advertised) will be generated 329 and the PCEP session will be terminated. 331 A PCC or a PCE MUST include both PCECC-CAPABILITY sub-TLV and 332 STATEFUL-PCE-CAPABILITY TLV ([RFC8231]) in OPEN Object to support the 333 extensions defined in this document. If PCECC-CAPABILITY sub-TLV is 334 advertised and STATEFUL-PCE-CAPABILITY TLV is not advertised in OPEN 335 Object, it SHOULD send a PCErr message with Error-Type=19 (Invalid 336 Operation) and Error-value=TBD (stateful PCE capability was not 337 advertised) and terminate the session. 339 5.4. LSP Operations 341 The PCEP messages pertaining to PCECC MUST include PATH-SETUP-TYPE 342 TLV [I-D.ietf-pce-lsp-setup-type] in the SRP object to clearly 343 identify the PCECC LSP is intended. 345 5.4.1. Basic PCECC LSP Setup 347 In order to setup a LSP based on PCECC mechanism, a PCC MUST delegate 348 the LSP by sending a PCRpt message with PST set for PCECC (see 349 Section 7.2) and D (Delegate) flag (see [RFC8231]) set in the LSP 350 object. 352 LSP-IDENTIFIER TLV MUST be included for PCECC LSP, the LSP-ID MAY be 353 generated by the PCE for PCECC LSP, in that case the first PCRpt 354 message of PCECC LSP, LSP-ID of LSP-IDENTIFIER TLV is set to zero. 355 The LSP-ID is further used during label download and this 356 relationship is useful for maintainability reasons. 358 When a PCE receives PCRpt message with D flags and PST Type set, it 359 MAY generates LSP ID; calculates the path and assigns labels along 360 the path; and set up the path by sending PCLabelUpd message to each 361 node along the path of the LSP. [Note: See Appendix A for how we 362 could use PCInitiate message instead.] 364 In response to the delegate PCRpt message, the PCE SHOULD send the 365 PCUpd message with the same PLSP-ID to the Ingress PCC. 367 The PCECC LSPs MUST be delegated to a PCE at all times. 369 LSP deletion operation for PCECC LSP is same as defined in [RFC8231]. 370 If the PCE receives PCRpt message for LSP deletion then it does Label 371 cleanup operation as described in Section 5.4.2.2 for the 372 corresponding LSP. 374 The Basic PCECC LSP setup sequence is as shown below using a new 375 message PCLabelUpd. 377 +-------+ +-------+ 378 |PCC | | PCE | 379 |Ingress| +-------+ 380 +------| | | 381 | PCC +-------+ | 382 | Transit| | | 383 +------| | |-- PCRpt,PLSP-ID=1, PST=TBD, D=1---->| PCECC LSP 384 |PCC +--------+ | (LSP ID=0) |(LSPID=1) 385 |Egress | | | | 386 +--------+ | | | 387 | | | | 388 |<------ PCLabelUpd,PLSP-ID=1 -------------------- | Label 389 | | | (LSP ID=1) | download 390 | | | | 391 | |<----- PCLabelUpd,PLSP-ID=1 ------------- | Label 392 | | | (LSP ID=1) | download 393 | | | | 394 | | |<--- PCLabelUpd,PLSP-ID=1 --------- | Label 395 | | | (LSP ID=1) | download 396 | | | | 397 | | |<-- PCUpd,PLSP-ID=1,PST=TBD, D=1-----| PCECC LSP 398 | | | (LSP ID=1) | Update 399 | | | | 401 Figure 2: Using PCLabelUpd For Label Operations 403 The PCECC LSP are considered to be 'up' by default. The Ingress MAY 404 further choose to deploy a data plane check mechanism and report the 405 status back to the PCE via PCRpt message. 407 5.4.2. Label Operations 409 The new label operations in PCEP can be done via a new PCLabelUpd 410 message and by defining new PCEP Objects for Label operations. Local 411 label range of each PCC can be configured at PCE and PCE. [Note: See 412 Appendix A for how we could use PCInitiate message instead.] 414 5.4.2.1. Label Download 416 In order to setup an LSP based on PCECC, the PCE sends a PCLabelUpd 417 message to each node of the LSP to download the Label entry as 418 described in Section 5.4.1. [Note: See Appendix A for how we could 419 use PCInitiate message instead.] 421 The LSP object in PCLabelUpd MUST include the LSP-IDENTIFIER TLV. 423 If a node (PCC) receives a PCLabelUpd message with a Label, out of 424 the range set aside for the PCE, it MUST send a PCErr message with 425 Error-type=TBD (label download failure) and Error-value=TBD (Label 426 out of range) and MUST include the SRP object to specify the error is 427 for the corresponding label update. If a PCC receives a PCLabelUpd 428 message but failed to download the Label entry, it MUST send a PCErr 429 message with Error-type=TBD (label download failure) and Error- 430 value=TBD (label failed to be download)and MUST include the SRP 431 object to specify the error is for the corresponding label update. 433 New PCEP object for LABEL is defined in Section 7.3 to encode the 434 Label operations. 436 5.4.2.2. Label Cleanup 438 In order to delete an LSP based on PCECC, the PCE sends a PCLabelUpd 439 message to each node along the path of the LSP to cleanup the Label 440 entry. [Note: See Appendix A for how we could use PCInitiate message 441 instead.] 443 If the PCC receives a PCLabelUpd message but does not recognize the 444 label, the PCC MUST generate a PCErr message with Error-Type 445 19(Invalid operation) and Error-Value=TBD, "Unknown Label" and MUST 446 include the SRP object to specify the error is for the corresponding 447 label cleanup. 449 The R flag in SRP object defined in [RFC8281] specifies the deletion 450 of Label Entry in the new PCLabelUpd message. 452 +-------+ +-------+ 453 |PCC | | PCE | 454 |Ingress| +-------+ 455 +------| | | 456 | PCC +-------+ | 457 | Transit| | | 458 +------| | |-- PCRpt,PLSP-ID=1,PST=TBD,D=1,R=1--->| PCECC LSP 459 |PCC +--------+ | (LSP ID=1) | remove 460 |Egress | | | | 461 +--------+ | | | 462 | | | | 463 |<------ PCLabelUpd, PLSP-ID=1 --------------------- | Label 464 | | | (LSP ID=1, R=1) | cleanup 465 | | | | 466 | |<----- PCLabelUpd, PLSP-ID=1 -------------- | Label 467 | | | (LSP ID=1, R=1) | cleanup 468 | | | | 469 | | |<--- PCLabelUpd, PLSP-ID=1 ---------- | Label 470 | | | (LSP ID=1, R=1) | cleanup 471 | | | | 473 5.4.3. PCE Initiated PCECC LSP 475 The LSP Instantiation operation is same as defined in [RFC8281]. 477 In order to setup a PCE Initiated LSP based on PCECC mechanism, a PCE 478 sends PCInitiate message with Path Setup Type set for PCECC (see 479 Section 7.2) to the Ingress PCC. 481 The Ingress PCC MUST also set D (Delegate) flag (see [RFC8231]) and C 482 (Create) flag (see [RFC8281]) in LSP object of PCRpt message. The 483 PCC responds with first PCRpt message with the status as "GOING-UP" 484 and assigned PLSP-ID. 486 The rest of the PCECC LSP setup operations are same as those 487 described in Section 5.4.1. 489 The LSP deletion operation for PCE Initiated PCECC LSP is same as 490 defined in [RFC8281]. The PCE should further perform Label entry 491 cleanup operation as described in Section 5.4.2.2 for the 492 corresponding LSP. 494 The PCE Initiated PCECC LSP setup sequence is shown below using a new 495 PCLabelUpd message. 497 +-------+ +-------+ 498 |PCC | | PCE | 499 |Ingress| +-------+ 500 +------| | | 501 | PCC +-------+ | 502 | Transit| | | 503 +------| | |<--PCInitiate,PLSP-ID=0,PST=TBD,D=1---| PCECC LSP 504 |PCC +--------+ | | Initiate 505 |Egress | | |--- PCRpt,PLSP-ID=2,P=1,D=1,C=1---> | PCECC LSP 506 +--------+ | | (LSP ID=0,GOING-UP) |(LSPID=2 507 | | | | assigned) 508 |<------ PCLabelUpd, PLSP-ID=2 --------------------- | Label 509 | | | (LSP ID=2) | download 510 | | | | 511 | |<----- PCLabelUpd, PLSP-ID=2 -------------- | Label 512 | | | (LSP ID=2) | download 513 | | | | 514 | | |<--- PCLabelUpd, PLSP-ID=2 ---------- | Label 515 | | | (LSP ID=2) | download 516 | | | | 517 | | |<-- PCUpd, PLSP-ID=2, PST=TBD, D=1--- | PCECC LSP 518 | | | (LSP ID=2) | Update 519 | | | | 521 [Note: See Appendix A for how we could use PCInitiate message instead 522 of PCLabelUpd message.] 524 5.4.4. PCECC LSP Update 526 In case of a modification of PCECC LSP with a new path, a PCE sends a 527 PCUpd message to the Ingress PCC. 529 When a PCC receives a PCUpd message for an existing LSP, a PCC MUST 530 follow the make-before-break procedure i.e. first download labels for 531 the updated LSP and then switch traffic, before cleaning up the old 532 labels. On successful traffic switch over to the new LSP, PCC sends 533 a PCRpt message to the PCE for the deletion of old LSP. Further the 534 PCE does cleanup operation for the old LSP as described in 535 Section 5.4.2.2. 537 The PCECC LSP Update and make-before-break sequence is shown below 538 using a new PCLabelUpd message. 540 +-------+ +-------+ 541 |PCC | | PCE | 542 |Ingress| +-------+ 543 +------| | | 544 | PCC +-------+ | 545 | Transit| | | 546 +------| | | | 547 |PCC +--------+ | | 548 |Egress | | | | 549 +--------+ | | | 550 | | | | Modify LSP 551 |<------ PCLabelUpd, PLSP-ID=1 ------------------- | (LSPID=3 552 | | | (LSP ID=3) | assigned) 553 | | | | 554 | |<----- PCLabelUpd, PLSP-ID=1------------- | Label 555 | | | (LSP ID=3) | download 556 | | | | 557 | | |<--- PCLabelUpd, PLSP-ID=1 -------- | Label 558 | | | (LSP ID=3) | download 559 | | | | 560 | | |<-- PCUpd, PLSP-ID=1, PST=TBD, D=1-- | PCECC 561 | | | (LSP ID=3) | LSP Update 562 | | | | 563 | | |-- PCRpt,PLSP-ID=1,PST=TBD,D=1,R=1-->| Delete 564 | | | (LSP ID=1) | old LSP 565 | | | | 566 |<------ PCLabelUpd, PLSP-ID=1 ------------------- | Label 567 | | | (LSP ID=1, R=1) | cleanup 568 | | | | 569 | |<----- PCLabelUpd, PLSP-ID=1 ------------ | Label 570 | | | (LSP ID=1, R=1) | cleanup 571 | | | | 572 | | |<--- PCLabelUpd, PLSP-ID=1 -------- | Label 573 | | | (LSP ID=1, R=1) | cleanup 575 The modified PCECC LSP are considered to be 'up' by default. The 576 Ingress MAY further choose to deploy a data plane check mechanism and 577 report the status back to the PCE via PCRpt message. 579 [Note: We could use PCInitiate message instead of PCLabelUpd message, 580 See Appendix A] 582 5.4.5. Session Termination 584 PCC MUST mark all labels that were previously reported by this PCE as 585 stale on session down. [RFC8231] defines the State Timeout Interval. 586 The labels which are marked stale and provisioned for the Basic PCECC 587 LSP on this session MUST be cleaned up at the expiration of the State 588 Timeout Interval. The labels will be retained when the Infinite 589 State Timeout Interval is used. 591 5.4.6. LABEL-DB Synchronization 593 The purpose of LABEL-DB synchronization is to make sure that the 594 PCE's view of LABEL-DB matches with the PCC's LABEL-DB. The LABEL- 595 DB synchronization MUST be performed from PCE to PCC immediately 596 after the LSP state synchronization. [RFC8231] describes the basic 597 mechanism for LSP state synchronization. [RFC8233] describes the 598 optimizations for LSP state synchronization. 600 LABEL-DB synchronization is a two phase procedure. In first phase, 601 immediately after the LSP state synchronization PCE MUST synchronize 602 its LABEL-DB to PCC. In second phase, PCC MUST report all the stale 603 marked labels to the PCE. 605 [Note: This section currently describe procedure based on new 606 messages, suitable modification can be made if existing message are 607 used instead Appendix A. In the case, some modifications needs to be 608 made to the existing LSP-DB synchronization mechanism to also handle 609 the label synchronization.] 611 5.4.6.1. LABEL-DB Synchronization procedure 613 During LABEL-DB Synchronization, a PCE first takes a snapshot of the 614 label database for the session, then sends this snapshot to the PCC 615 in a sequence of Label Update message (PCLabelUpd message). Each 616 PCLabelUpd message sent during LABEL-DB Synchronization has the SYNC 617 Flag in the SRP Object(see Section 7.4) set to 1. 619 The end of synchronization marker is a PCLabelUpd message with the 620 SYNC Flag set to 0 for SRP Object and Label equal to a reserved value 621 of 0 in the LABEL object (Section 7.3). If the PCE has no label to 622 synchronize, it will only send the end of synchronization marker. 624 PCC MUST remove the stale marking for the all labels on receipt of 625 corresponding PCLabelUpd message during the LABEL-DB Synchronization 626 phase. The remaining stale marked labels after the LABEL-DB 627 synchronization process MUST be reported to PCE in a sequence of 628 Label Report message (PCLabelRpt message) with the SYNC Flag in the 629 SRP Object(see Section 7.4) set to 1. 631 The end of report synchronization marker is a PCLabelRpt message with 632 the SYNC Flag set to 0 for SRP Object with Label equal to reserved 633 value 0 in the LABEL object ((Section 7.3)). If the PCC has no label 634 to report, it will only send the end of report synchronization 635 marker. 637 Either the PCE or the PCC MAY terminate the session using the PCEP 638 session termination procedures during the LABEL-DB synchronization 639 phase. The session reestablishment MUST be re-attempted as per the 640 procedures defined in [RFC5440], including use of a back-off timer. 642 The PCC does not send positive acknowledgments for properly received 643 label database synchronization messages. It MUST respond with a 644 PCErr message with Error-type TBD1 (Label Database Synchronization 645 Error) and Error-value 1 (indicating an error in processing the 646 PCLabelUpd) if it encounters a problem with the Label Update it 647 received from the PCE and it MUST terminate the session. 649 If the PCE encounters a problem which prevents it from completing the 650 label transfer, it MUST send a PCErr message with Error-type TBD1 651 (Label Database Synchronization Error) and Error-value 2 (indicating 652 an internal PCE Error) to the PCC and terminate the session. 654 PCE MUST respond with a PCErr message with Error-type TBD1 (Label 655 Database Report Synchronization Error) and Error-value 1 (indicating 656 an error in processing the PCLabelRpt) if it encounters a problem 657 with the Label Report it received from the PCC and it MUST terminate 658 the session. 660 The successful LABEL-DB Synchronization sequence is shown below. 662 + +-+-+-+- + +-+-+-+- 663 | | | PCC | 664 | PCE | | Transit| 665 | | | Node | 666 +-+-+-+-+- +-+-+-+-+- 667 | | 668 | | 669 | . | 670 | . | 671 | | 672 |------- PCLabelUpd, PLSP-ID=2----->|(Label 673 | (LSP ID=2) | Download 674 | | for LSP's) 675 |------- PCLabelUpd, PLSP-ID=3----->| 676 | (LSP ID=3) | 677 | | 678 |------- PCLabelUpd, PLSP-ID=4----->| 679 | (LSP ID=4) | 680 | . | 681 | . |(Session 682 | | down, mark 683 |------- Session Down---------X | all label's 684 | | Stale of this 685 | . | Session) 686 | . | 687 |<------ Session Re-established---->|(Session up) 688 | . | 689 | . | 690 |<-----PCRpt, SYNC=0----------------| (No LSP to SYNC) 691 | | 692 |----PCLabelUpd,PLSP-ID=2,SYNC=1--->|(LABEL-DB 693 |----PCLabelUpd,PLSP-ID=3,SYNC=1--->| SYNC, unmark 694 | | stale label) 695 |------PCLabelUpd, SYNC=0---------->| 696 | |(End of LABEL-DB 697 | | SYNC) 698 | | 699 |<-----PCLabelRpt,PLSP-ID=4,SYNC=1--|(Report all stale 700 | | Labels of this 701 |<-----PCLabelRpt,SYNC=0------------| Session) 702 | | 703 |------- PCLabelUpd, PLSP-ID=4 ---->|Label Cleanup 704 | (LSP ID=4, R=1) | 705 | | 706 | | 708 See [I-D.palle-pce-controller-labeldb-sync] for the optimizations for 709 LABEL-DB synchronization procedure. 711 5.4.7. PCECC LSP State Report 713 As mentioned before, an Ingress PCC MAY choose to apply any OAM 714 mechanism to check the status of LSP in the Data plane and MAY 715 further send its status in PCRpt message to the PCE. 717 6. PCEP messages 719 As defined in [RFC5440], a PCEP message consists of a common header 720 followed by a variable-length body made of a set of objects that can 721 be either mandatory or optional. An object is said to be mandatory 722 in a PCEP message when the object must be included for the message to 723 be considered valid. For each PCEP message type, a set of rules is 724 defined that specify the set of objects that the message can carry. 725 An implementation MUST form the PCEP messages using the object 726 ordering specified in this document. 728 LSP-IDENTIFIERS TLV MUST be included in the LSP object for PCECC LSP. 730 6.1. Label Operations 732 [Editor's Note: This document defines new messages PCLabelUpd and 733 PCLabelRpt. The authors and WG also debated on the use of existing 734 PCEP messages. See Appendix A on how the existing messages can be 735 extended to add this functionality. WG needs to decide the final 736 direction i.e. new specific messages are needed or existing PCEP 737 messages can be extended.] 739 6.1.1. The PCLabelUpd message 741 A new Label Update Message (also referred to as PCLabelUpd) is a PCEP 742 message sent by a PCE to a PCC to download label or update the label 743 map. The same message is also used to cleanup the Label entry. The 744 Message-Type field of the PCEP common header for the PCLabelUpd 745 message is set to TBD. 747 The format of the PCLabelUpd message is as follows: 749 ::= 750 751 Where: 752 ::= 753 [] 755 ::= 757 Where: 758 ::= 759 760 762 ::=