idnits 2.17.1 draft-zhao-pce-pcep-extension-for-pce-controller-06.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (October 26, 2017) is 2372 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-04 == Outdated reference: A later version (-23) exists of draft-ietf-pce-pcep-yang-05 == Outdated reference: A later version (-09) exists of draft-zhao-pce-pcep-extension-pce-controller-sr-00 == Outdated reference: A later version (-03) exists of draft-palle-pce-controller-labeldb-sync-01 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: April 29, 2018 S. Karunanithi 6 Huawei Technologies 7 A. Farrel 8 Juniper Networks, Inc 9 C. Zhou 10 Cisco Systems 11 October 26, 2017 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-06 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 April 29, 2018. 50 Copyright Notice 52 Copyright (c) 2017 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 . . . . . . . . . . . . . . . . . . . . . . . . . 4 70 3. Basic PCECC Mode . . . . . . . . . . . . . . . . . . . . . . 4 71 4. PCEP Requirements . . . . . . . . . . . . . . . . . . . . . . 5 72 5. Procedures for Using the PCE as the Central Controller 73 (PCECC) . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 74 5.1. Stateful PCE Model . . . . . . . . . . . . . . . . . . . 5 75 5.2. New LSP Functions . . . . . . . . . . . . . . . . . . . . 5 76 5.3. PCECC Capability Advertisement . . . . . . . . . . . . . 7 77 5.4. LSP Operations . . . . . . . . . . . . . . . . . . . . . 7 78 5.4.1. Basic PCECC LSP Setup . . . . . . . . . . . . . . . . 7 79 5.4.2. Label Operations . . . . . . . . . . . . . . . . . . 9 80 5.4.2.1. Label Download . . . . . . . . . . . . . . . . . 9 81 5.4.2.2. Label Cleanup . . . . . . . . . . . . . . . . . . 9 82 5.4.3. PCE Initiated PCECC LSP . . . . . . . . . . . . . . . 10 83 5.4.4. PCECC LSP Update . . . . . . . . . . . . . . . . . . 11 84 5.4.5. Session Termination . . . . . . . . . . . . . . . . . 12 85 5.4.6. LABEL-DB Synchronization . . . . . . . . . . . . . . 13 86 5.4.6.1. LABEL-DB Synchronization procedure . . . . . . . 13 87 5.4.7. PCECC LSP State Report . . . . . . . . . . . . . . . 16 88 6. PCEP messages . . . . . . . . . . . . . . . . . . . . . . . . 16 89 6.1. Label Operations . . . . . . . . . . . . . . . . . . . . 16 90 6.1.1. The PCLabelUpd message . . . . . . . . . . . . . . . 16 91 6.1.2. The PCLabelRpt message . . . . . . . . . . . . . . . 17 92 6.1.3. The PCInitiate message . . . . . . . . . . . . . . . 19 93 7. PCEP Objects . . . . . . . . . . . . . . . . . . . . . . . . 19 94 7.1. OPEN Object . . . . . . . . . . . . . . . . . . . . . . . 19 95 7.1.1. PCECC Capability TLV . . . . . . . . . . . . . . . . 19 96 7.2. PATH-SETUP-TYPE TLV . . . . . . . . . . . . . . . . . . . 20 97 7.3. Label Object . . . . . . . . . . . . . . . . . . . . . . 20 98 7.3.1. Address TLVs . . . . . . . . . . . . . . . . . . . . 21 99 7.4. Extension of SRP object . . . . . . . . . . . . . . . . . 22 100 8. Security Considerations . . . . . . . . . . . . . . . . . . . 22 101 8.1. Malicious PCE . . . . . . . . . . . . . . . . . . . . . . 22 102 9. Manageability Considerations . . . . . . . . . . . . . . . . 23 103 9.1. Control of Function and Policy . . . . . . . . . . . . . 23 104 9.2. Information and Data Models . . . . . . . . . . . . . . . 23 105 9.3. Liveness Detection and Monitoring . . . . . . . . . . . . 23 106 9.4. Verify Correct Operations . . . . . . . . . . . . . . . . 23 107 9.5. Requirements On Other Protocols . . . . . . . . . . . . . 23 108 9.6. Impact On Network Operations . . . . . . . . . . . . . . 23 109 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 23 110 10.1. PCLabelUpd-PCLabelRpt message . . . . . . . . . . . . . 24 111 10.2. PCEP TLV Type Indicators . . . . . . . . . . . . . . . . 24 112 10.3. New Path Setup Type Registry . . . . . . . . . . . . . . 24 113 10.4. PCEP Object . . . . . . . . . . . . . . . . . . . . . . 24 114 10.5. LABEL Object Flag Field . . . . . . . . . . . . . . . . 24 115 10.6. SRP Object Flag Field . . . . . . . . . . . . . . . . . 25 116 10.7. PCEP-Error Object . . . . . . . . . . . . . . . . . . . 25 117 11. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 26 118 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 26 119 12.1. Normative References . . . . . . . . . . . . . . . . . . 26 120 12.2. Informative References . . . . . . . . . . . . . . . . . 27 121 Appendix A. Using existing PCEP message . . . . . . . . . . . . 29 122 Appendix B. Contributor Addresses . . . . . . . . . . . . . . . 30 123 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 31 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 [I-D.ietf-pce-pce-initiated-lsp] describes the setup and tear down of 158 PCE-initiated LSPs under the active stateful PCE model, without the 159 need for local configuration on the PCC, thus allowing for a dynamic 160 MPLS network that is centrally controlled and deployed. 162 [I-D.ietf-teas-pce-central-control] introduces the architecture for 163 PCE as a central controller, examines the motivations and 164 applicability for PCEP as a southbound interface, and introduces the 165 implications for the protocol. [I-D.ietf-teas-pcecc-use-cases] 166 describes the use cases 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 1.1. Requirements Language 178 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 179 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 180 "OPTIONAL" in this document are to be interpreted as described in BCP 181 14 [RFC2119] [RFC8174] when, and only when, they appear in all 182 capitals, as shown here. 184 2. Terminology 186 Terminologies used in this document is same as described in the draft 187 [I-D.ietf-teas-pcecc-use-cases]. 189 3. Basic PCECC Mode 191 In this mode LSPs are provisioned as explicit label instructions at 192 each hop on the end-to-end path. Each router along the path must be 193 told what label forwarding instructions to program and what resources 194 to reserve. The controller uses PCEP to communicate with each router 195 along the path of the end-to-end LSP. 197 Note that the PCE-based controller will take responsibility for 198 managing some part of the MPLS label space for each of the routers 199 that it controls, and may taker wider responsibility for partitioning 200 the label space for each router and allocating different parts for 201 different uses. This is also described in section 3.1.2. of 202 [I-D.ietf-teas-pce-central-control]. For the purpose of this 203 document, it is assumed that label range to be used by a PCE is set 204 on both PCEP peers. A future extension MAY add capability to 205 advertise the range via possible PCEP extensions as well. The rest 206 of processing is similar to the existing stateful PCE mechanism. 208 4. PCEP Requirements 210 Following key requirements associated PCECC should be considered when 211 designing the PCECC based solution: 213 1. PCEP speaker supporting this draft MUST have the capability to 214 advertise its PCECC capability to its peers. 216 2. PCEP speaker not supporting this draft MUST be able to reject 217 PCECC related message with a reason code that indicates no 218 support for PCECC. 220 3. PCEP SHOULD provide a means to identify PCECC based LSP in the 221 PCEP messages. 223 4. PCEP SHOULD provide a means to update (or cleanup) the label- 224 download entry to the PCC. 226 5. PCEP SHOULD provide a means to synchronize the labels between PCE 227 to PCC in PCEP messages. 229 5. Procedures for Using the PCE as the Central Controller (PCECC) 231 5.1. Stateful PCE Model 233 Active stateful PCE is described in [RFC8231]. PCE as a central 234 controller (PCECC) reuses existing Active stateful PCE mechanism as 235 much as possible to control the LSP. 237 5.2. New LSP Functions 239 This document defines the following new PCEP messages and extends the 240 existing messages to support PCECC: 242 (PCRpt): a PCEP message described in [RFC8231]. PCRpt message MAYBE 243 used to send PCECC LSP Reports. 245 (PCInitiate): a PCEP message described in 246 [I-D.ietf-pce-pce-initiated-lsp]. PCInitiate message is used to 247 setup PCE-Initiated LSP based on PCECC mechanism. 249 (PCUpd): a PCEP message described in [RFC8231]. PCUpd message is 250 used to send PCECC LSP Update. 252 (PCLabelUpd): a new PCEP message sent by a PCE to a PCC to download 253 or cleanup the Label entry. The PCLabelUpd message described in 254 Section 6.1.1. 256 (PCLabelRpt): a new PCEP message sent by a PCC to a PCE to report 257 the set of labels for which explicit action is required from PCE 258 to update or cleanup or do nothing for these Label entries. The 259 PCLabelRpt message described in Section 6.1.2. 261 [Editor's Note: This document defines new messages PCLabelUpd and 262 PCLabelRpt. Questions where raised on the need for the new messages. 263 See Appendix A on how the existing messages can be extended to add 264 this functionality. WG needs to decide the final direction i.e. new 265 specific messages are needed or existing PCEP messages can be 266 extended.] 268 The new LSP functions defined in this document are mapped onto the 269 messages as shown in the following table. 271 +----------------------------------------+--------------------------+ 272 | Function | Message | 273 +----------------------------------------+--------------------------+ 274 | PCECC Capability advertisement | Open | 275 | Label entry Update | PCLabelUpd | 276 | Label entry Cleanup | PCLabelUpd | 277 | PCECC Initiated LSP | PCInitiate | 278 | PCECC LSP Update | PCUpd | 279 | PCECC LSP State Report | PCRpt | 280 | PCECC LSP Delegation | PCRpt | 281 | PCECC Label Report | PCLabelRpt | 282 +----------------------------------------+--------------------------+ 284 5.3. PCECC Capability Advertisement 286 During PCEP Initialization Phase, PCEP Speakers (PCE or PCC) 287 advertise their support of PCECC extensions. A PCEP Speaker includes 288 the "PCECC Capability" TLV, described in Section 7.1.1 of this 289 document, in the OPEN Object to advertise its support for PCECC 290 extensions. 292 The presence of the PCECC Capability TLV in PCC's OPEN Object 293 indicates that the PCC is willing to function as a PCECC client. 295 The presence of the PCECC Capability TLV in PCE's OPEN message 296 indicates that the PCE is interested in function as a PCECC server. 298 The PCEP protocol extensions for PCECC MUST NOT be used if one or 299 both PCEP Speakers have not included the PCECC Capability TLV in 300 their respective OPEN message. If the PCEP Speakers support the 301 extensions of this draft but did not advertise this capability then a 302 PCErr message with Error-Type=19(Invalid Operation) and Error- 303 Value=TBD (Attempted LSP setup/download/label-range reservation if 304 PCECC capability was not advertised) will be generated and the PCEP 305 session will be terminated. 307 A PCC or a PCE MUST include both PCECC-CAPABILITY TLV and STATEFUL- 308 PCE-CAPABILITY TLV ([RFC8231]) in OPEN Object to support the 309 extensions defined in this document. If PCECC-CAPABILITY TLV is 310 advertised and STATEFUL-PCE-CAPABILITY TLV is not advertised in OPEN 311 Object, it SHOULD send a PCErr message with Error-Type=19 (Invalid 312 Operation) and Error-value=TBD (stateful PCE capability was not 313 advertised) and terminate the session. 315 5.4. LSP Operations 317 The PCEP messages pertaining to PCECC MUST include PATH-SETUP-TYPE 318 TLV [I-D.ietf-pce-lsp-setup-type] in the SRP object to clearly 319 identify the PCECC LSP is intended. 321 5.4.1. Basic PCECC LSP Setup 323 In order to setup a LSP based on PCECC mechanism, a PCC MUST delegate 324 the LSP by sending a PCRpt message with Path Setup Type set for basic 325 PCECC (see Section 7.2) and D (Delegate) flag (see [RFC8231]) set in 326 the LSP object. 328 LSP-IDENTIFIER TLV MAY be included for PCECC LSP, the LSP-ID SHOULD 329 be generated by the PCE for PCECC LSP. In the first PCRpt message of 330 PCECC LSP, LSP ID of LSP-IDENTIFIER TLV is set to zero. 332 When a PCE receives PCRpt message with D flags and PST Type set, it 333 MAY generates LSP ID; calculates the path and assigns labels along 334 the path; and setups the path by sending PCLabelUpd message to each 335 node along the path of the LSP. 337 In response to the delegate PCRpt message, the PCE SHOULD send the 338 PCUpd message with the same PLSP-ID to the Ingress PCC. 340 The PCECC LSPs MUST be delegated to a PCE at all times. 342 LSP deletion operation for PCECC LSP is same as defined in [RFC8231]. 343 If the PCE receives PCRpt message for LSP deletion then it does Label 344 cleanup operation as described in Section 5.4.2.2 for the 345 corresponding LSP. 347 The Basic PCECC LSP setup sequence is as shown below using a new 348 message PCLabelUpd. 350 +-------+ +-------+ 351 |PCC | | PCE | 352 |Ingress| +-------+ 353 +------| | | 354 | PCC +-------+ | 355 | Transit| | | 356 +------| | |-- PCRpt,PLSP-ID=1, PST=TBD, D=1---->| PCECC LSP 357 |PCC +--------+ | (LSP ID=0) |(LSPID=1) 358 |Egress | | | | 359 +--------+ | | | 360 | | | | 361 |<------ PCLabelUpd,PLSP-ID=1 -------------------- | Label 362 | | | (LSP ID=1) | download 363 | | | | 364 | |<----- PCLabelUpd,PLSP-ID=1 ------------- | Label 365 | | | (LSP ID=1) | download 366 | | | | 367 | | |<--- PCLabelUpd,PLSP-ID=1 --------- | Label 368 | | | (LSP ID=1) | download 369 | | | | 370 | | |<-- PCUpd,PLSP-ID=1,PST=TBD, D=1-----| PCECC LSP 371 | | | (LSP ID=1) | Update 372 | | | | 374 Figure 2: Using PCLabelUpd For Label Operations 376 The PCECC LSP are considered to be 'up' by default. The Ingress MAY 377 further choose to deploy a data plane check mechanism and report the 378 status back to the PCE via PCRpt message. 380 5.4.2. Label Operations 382 The new label operations in PCEP can be done via a new PCLabelUpd 383 message and by defining new PCEP Objects for Label operations. Local 384 label range of each PCC can be configured at PCE and PCE. 386 5.4.2.1. Label Download 388 In order to setup an LSP based on PCECC, the PCE sends a PCLabelUpd 389 message to each node of the LSP to download the Label entry as 390 described in Section 5.4.1. 392 The LSP object in PCLabelUpd MUST include the LSP-IDENTIFIER TLV. 394 If a node (PCC) receives a PCLabelUpd message with a Label, out of 395 the range set aside for the PCE, it MUST send a PCErr message with 396 Error-type=TBD (label download failure) and Error-value=TBD (Label 397 out of range) and MUST include the SRP object to specify the error is 398 for the corresponding label update. If a PCC receives a PCLabelUpd 399 message but failed to download the Label entry, it MUST send a PCErr 400 message with Error-type=TBD (label download failure) and Error- 401 value=TBD (label failed to be download)and MUST include the SRP 402 object to specify the error is for the corresponding label update. 404 New PCEP object for LABEL is defined in Section 7.3 to encode the 405 Label operations. 407 5.4.2.2. Label Cleanup 409 In order to delete an LSP based on PCECC, the PCE sends a PCLabelUpd 410 message to each node along the path of the LSP to cleanup the Label 411 entry. 413 If the PCC receives a PCLabelUpd message but does not recognize the 414 label, the PCC MUST generate a PCErr message with Error-Type 415 19(Invalid operation) and Error-Value=TBD, "Unknown Label" and MUST 416 include the SRP object to specify the error is for the corresponding 417 label cleanup. 419 The R flag in SRP object defined in [I-D.ietf-pce-pce-initiated-lsp] 420 specifies the deletion of Label Entry in the new PCLabelUpd message. 422 +-------+ +-------+ 423 |PCC | | PCE | 424 |Ingress| +-------+ 425 +------| | | 426 | PCC +-------+ | 427 | Transit| | | 428 +------| | |-- PCRpt,PLSP-ID=1,PST=TBD,D=1,R=1--->| PCECC LSP 429 |PCC +--------+ | (LSP ID=1) | remove 430 |Egress | | | | 431 +--------+ | | | 432 | | | | 433 |<------ PCLabelUpd, PLSP-ID=1 --------------------- | Label 434 | | | (LSP ID=1, R=1) | cleanup 435 | | | | 436 | |<----- PCLabelUpd, PLSP-ID=1 -------------- | Label 437 | | | (LSP ID=1, R=1) | cleanup 438 | | | | 439 | | |<--- PCLabelUpd, PLSP-ID=1 ---------- | Label 440 | | | (LSP ID=1, R=1) | cleanup 441 | | | | 443 5.4.3. PCE Initiated PCECC LSP 445 The LSP Instantiation operation is same as defined in 446 [I-D.ietf-pce-pce-initiated-lsp]. 448 In order to setup a PCE Initiated LSP based on PCECC mechanism, a PCE 449 sends PCInitiate message with Path Setup Type set for basic PCECC 450 (see Section 7.2) to the Ingress PCC. 452 The Ingress PCC MUST also set D (Delegate) flag (see [RFC8231]) and C 453 (Create) flag (see [I-D.ietf-pce-pce-initiated-lsp]) in LSP object of 454 PCRpt message. The PCC responds with first PCRpt message with the 455 status as "GOING-UP" and assigned PLSP-ID. 457 The rest of the PCECC LSP setup operations are same as those 458 described in Section 5.4.1. 460 The LSP deletion operation for PCE Initiated PCECC LSP is same as 461 defined in [I-D.ietf-pce-pce-initiated-lsp]. The PCE should further 462 perform Label entry cleanup operation as described in Section 5.4.2.2 463 for the corresponding LSP. 465 The PCE Initiated PCECC LSP setup sequence is shown below using a new 466 PCLabelUpd message. 468 +-------+ +-------+ 469 |PCC | | PCE | 470 |Ingress| +-------+ 471 +------| | | 472 | PCC +-------+ | 473 | Transit| | | 474 +------| | |<--PCInitiate,PLSP-ID=0,PST=TBD,D=1---| PCECC LSP 475 |PCC +--------+ | | Initiate 476 |Egress | | |--- PCRpt,PLSP-ID=2,P=1,D=1,C=1---> | PCECC LSP 477 +--------+ | | (LSP ID=0,GOING-UP) |(LSPID=2 478 | | | | assigned) 479 |<------ PCLabelUpd, PLSP-ID=2 --------------------- | Label 480 | | | (LSP ID=2) | download 481 | | | | 482 | |<----- PCLabelUpd, PLSP-ID=2 -------------- | Label 483 | | | (LSP ID=2) | download 484 | | | | 485 | | |<--- PCLabelUpd, PLSP-ID=2 ---------- | Label 486 | | | (LSP ID=2) | download 487 | | | | 488 | | |<-- PCUpd, PLSP-ID=2, PST=TBD, D=1--- | PCECC LSP 489 | | | (LSP ID=2) | Update 490 | | | | 492 5.4.4. PCECC LSP Update 494 Incase of a modification of PCECC LSP with a new path, a PCE sends a 495 PCUpd message to the Ingress PCC. 497 When a PCC receives a PCUpd message for an existing LSP, a PCC MAY 498 follow the make-before-break procedure i.e. first download labels for 499 the updated LSP and then switch traffic, before cleaning up the old 500 labels. On successful traffic switch over to the new LSP, PCC sends 501 a PCRpt message to the PCE for the deletion of old LSP. Further the 502 PCE does cleanup operation for the old LSP as described in 503 Section 5.4.2.2. 505 The PCECC LSP Update and make-before-break sequence is shown below 506 using a new PCLabelUpd message. 508 +-------+ +-------+ 509 |PCC | | PCE | 510 |Ingress| +-------+ 511 +------| | | 512 | PCC +-------+ | 513 | Transit| | | 514 +------| | | | 515 |PCC +--------+ | | 516 |Egress | | | | 517 +--------+ | | | 518 | | | | Modify LSP 519 |<------ PCLabelUpd, PLSP-ID=1 ------------------- | (LSPID=3 520 | | | (LSP ID=3) | assigned) 521 | | | | 522 | |<----- PCLabelUpd, PLSP-ID=1------------- | Label 523 | | | (LSP ID=3) | download 524 | | | | 525 | | |<--- PCLabelUpd, PLSP-ID=1 -------- | Label 526 | | | (LSP ID=3) | download 527 | | | | 528 | | |<-- PCUpd, PLSP-ID=1, PST=TBD, D=1-- | PCECC 529 | | | (LSP ID=3) | LSP Update 530 | | | | 531 | | |-- PCRpt,PLSP-ID=1,PST=TBD,D=1,R=1-->| Delete 532 | | | (LSP ID=1) | old LSP 533 | | | | 534 |<------ PCLabelUpd, PLSP-ID=1 ------------------- | Label 535 | | | (LSP ID=1, R=1) | cleanup 536 | | | | 537 | |<----- PCLabelUpd, PLSP-ID=1 ------------ | Label 538 | | | (LSP ID=1, R=1) | cleanup 539 | | | | 540 | | |<--- PCLabelUpd, PLSP-ID=1 -------- | Label 541 | | | (LSP ID=1, R=1) | cleanup 543 The modified PCECC LSP are considered to be 'up' by default. The 544 Ingress MAY further choose to deploy a data plane check mechanism and 545 report the status back to the PCE via PCRpt message. 547 5.4.5. Session Termination 549 PCC MUST mark all labels that were previously reported by this PCE as 550 stale on session down. [RFC8231] defines the State Timeout Interval. 551 The labels which are marked stale and provisioned for the Basic PCECC 552 LSP on this session MUST be cleaned up at the expiration of the State 553 Timeout Interval. The labels will be retained when the Infinite 554 State Timeout Interval is used. 556 5.4.6. LABEL-DB Synchronization 558 The purpose of LABEL-DB synchronization is to make sure that the 559 PCE's view of LABEL-DB matches with the PCC's LABEL-DB. The LABEL- 560 DB synchronization MUST be performed from PCE to PCC immediately 561 after the LSP state synchronization. [RFC8231] describes the basic 562 mechanism for LSP state synchronization. [RFC8233] describes the 563 optimizations for LSP state synchronization. 565 LABEL-DB synchronization is a two phase procedure. In first phase, 566 immediately after the LSP state synchronization PCE MUST synchronize 567 its LABEL-DB to PCC. In second phase, PCC MUST report all the stale 568 marked labels to PCE. 570 5.4.6.1. LABEL-DB Synchronization procedure 572 During LABEL-DB Synchronization, a PCE first takes a snapshot of the 573 label database for the session, then sends this snapshot to the PCC 574 in a sequence of Label Update message (PCLabelUpd message). Each 575 PCLabelUpd message sent during LABEL-DB Synchronization has the SYNC 576 Flag in the SRP Object(see Section 7.4) set to 1. 578 The end of synchronization marker is a PCLabelUpd message with the 579 SYNC Flag set to 0 for SRP Object and Label equal to a reserved value 580 of 0 in the LABEL object (Section 7.3). If the PCE has no label to 581 synchronize, it will only send the end of synchronization marker. 583 PCC MUST remove the stale marking for the all labels on receipt of 584 corresponding PCLabelUpd message during the LABEL-DB Synchronization 585 phase. The remaining stale marked labels after the LABEL-DB 586 synchronization process MUST be reported to PCE in a sequence of 587 Label Report message (PCLabelRpt message) with the SYNC Flag in the 588 SRP Object(see Section 7.4) set to 1. 590 The end of report synchronization marker is a PCLabelRpt message with 591 the SYNC Flag set to 0 for SRP Object with Label equal to reserved 592 value 0 in the LABEL object ((Section 7.3)). If the PCC has no label 593 to report, it will only send the end of report synchronization 594 marker. 596 Either the PCE or the PCC MAY terminate the session using the PCEP 597 session termination procedures during the LABEL-DB synchronization 598 phase. The session reestablishment MUST be re-attempted as per the 599 procedures defined in [RFC5440], including use of a back-off timer. 601 The PCC does not send positive acknowledgments for properly received 602 label database synchronization messages. It MUST respond with a 603 PCErr message with Error-type TBD1 (Label Database Synchronization 604 Error) and Error-value 1 (indicating an error in processing the 605 PCLabelUpd) if it encounters a problem with the Label Update it 606 received from the PCE and it MUST terminate the session. 608 If the PCE encounters a problem which prevents it from completing the 609 label transfer, it MUST send a PCErr message with Error-type TBD1 610 (Label Database Synchronization Error) and Error-value 2 (indicating 611 an internal PCE Error) to the PCC and terminate the session. 613 PCE MUST respond with a PCErr message with Error-type TBD1 (Label 614 Database Report Synchronization Error) and Error-value 1 (indicating 615 an error in processing the PCLabelRpt) if it encounters a problem 616 with the Label Report it received from the PCC and it MUST terminate 617 the session. 619 The successful LABEL-DB Synchronization sequence is shown below. 621 + +-+-+-+- + +-+-+-+- 622 | | | PCC | 623 | PCE | | Transit| 624 | | | Node | 625 +-+-+-+-+- +-+-+-+-+- 626 | | 627 | | 628 | . | 629 | . | 630 | | 631 |------- PCLabelUpd, PLSP-ID=2----->|(Label 632 | (LSP ID=2) | Download 633 | | for LSP's) 634 |------- PCLabelUpd, PLSP-ID=3----->| 635 | (LSP ID=3) | 636 | | 637 |------- PCLabelUpd, PLSP-ID=4----->| 638 | (LSP ID=4) | 639 | . | 640 | . |(Session 641 | | down, mark 642 |------- Session Down---------X | all label's 643 | | Stale of this 644 | . | Session) 645 | . | 646 |<------ Session Re-established---->|(Session up) 647 | . | 648 | . | 649 |<-----PCRpt, SYNC=0----------------| (No LSP to SYNC) 650 | | 651 |----PCLabelUpd,PLSP-ID=2,SYNC=1--->|(LABEL-DB 652 |----PCLabelUpd,PLSP-ID=3,SYNC=1--->| SYNC, unmark 653 | | stale label) 654 |------PCLabelUpd, SYNC=0---------->| 655 | |(End of LABEL-DB 656 | | SYNC) 657 | | 658 |<-----PCLabelRpt,PLSP-ID=4,SYNC=1--|(Report all stale 659 | | Labels of this 660 |<-----PCLabelRpt,SYNC=0------------| Session) 661 | | 662 |------- PCLabelUpd, PLSP-ID=4 ---->|Label Cleanup 663 | (LSP ID=4, R=1) | 664 | | 665 | | 667 See [I-D.palle-pce-controller-labeldb-sync] for the optimizations for 668 LABEL-DB synchronization procedure. 670 5.4.7. PCECC LSP State Report 672 As mentioned before, an Ingress PCC MAY choose to apply any OAM 673 mechanism to check the status of LSP in the Data plane and MAY 674 further send its status in PCRpt message to the PCE. 676 6. PCEP messages 678 As defined in [RFC5440], a PCEP message consists of a common header 679 followed by a variable-length body made of a set of objects that can 680 be either mandatory or optional. An object is said to be mandatory 681 in a PCEP message when the object must be included for the message to 682 be considered valid. For each PCEP message type, a set of rules is 683 defined that specify the set of objects that the message can carry. 684 An implementation MUST form the PCEP messages using the object 685 ordering specified in this document. 687 LSP-IDENTIFIERS TLV MAY be included in the LSP object for PCECC LSP. 689 6.1. Label Operations 691 [Editor's Note: This document defines new messages PCLabelUpd and 692 PCLabelRpt. Questions where raised on the need for the new messages. 693 See Appendix A on how the existing messages can be extended to add 694 this functionality. WG needs to decide the final direction i.e. new 695 specific messages are needed or existing PCEP messages can be 696 extended.] 698 6.1.1. The PCLabelUpd message 700 A new Label Update Message (also referred to as PCLabelUpd) is a PCEP 701 message sent by a PCE to a PCC to download label or update the label 702 map. The same message is also used to cleanup the Label entry. The 703 Message-Type field of the PCEP common header for the PCLabelUpd 704 message is set to TBD. 706 The format of the PCLabelUpd message is as follows: 708 ::= 709 710 Where: 711 ::= 712 [] 714 ::= 716 Where: 717 ::= 718 719 721 ::=