idnits 2.17.1 draft-zhao-pce-pcep-extension-for-pce-controller-05.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 30, 2017) is 2492 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 (-11) exists of draft-ietf-pce-pce-initiated-lsp-10 == Outdated reference: A later version (-05) exists of draft-ietf-teas-pce-central-control-03 == 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 (-18) exists of draft-ietf-pce-pceps-14 == Outdated reference: A later version (-23) exists of draft-ietf-pce-pcep-yang-04 == Outdated reference: A later version (-09) exists of draft-zhao-pce-pcep-extension-pce-controller-sr-00 Summary: 1 error (**), 0 flaws (~~), 8 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: January 1, 2018 S. Karunanithi 6 Huawei Technologies 7 A. Farrel 8 Juniper Networks, Inc 9 C. Zhou 10 Cisco Systems 11 June 30, 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-05 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 signalling 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 http://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 January 1, 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 (http://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 . . . . . . . . . . . . . 6 77 5.4. LSP Operations . . . . . . . . . . . . . . . . . . . . . 7 78 5.4.1. Basic PCECC LSP Setup . . . . . . . . . . . . . . . . 7 79 5.4.2. Label Operations . . . . . . . . . . . . . . . . . . 8 80 5.4.2.1. Label Download . . . . . . . . . . . . . . . . . 8 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 . . . . . . . . . . . . . . . 18 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 . . . . . . . . . . . . . . . . . . . 19 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 . . . . . . . . . . . . . 23 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. Contributor Addresses . . . . . . . . . . . . . . . 28 122 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 28 124 1. Introduction 126 In certain network deployment scenarios, service providers would like 127 to have the ability to dynamically adapt to a wide range of 128 customer's requests for the sake of flexible network service 129 delivery, Software Defined Networks(SDN) has provides additional 130 flexibility in how the network is operated compared to the 131 traditional network. 133 The existing networking ecosystem has become awfully complex and 134 highly demanding in terms of robustness, performance, scalability, 135 flexibility, agility, etc. By migrating to the SDN enabled network 136 from the existing network, service providers and network operators 137 must have a solution which they can evolve easily from the existing 138 network into the SDN enabled network while keeping the network 139 services remain scalable, guarantee robustness and availability etc. 141 Taking the smooth transition between traditional network and the new 142 SDN enabled network into account, especially from a cost impact 143 assessment perspective, using the existing PCE components from the 144 current network to function as the central controller of the SDN 145 network is one choice, which not only achieves the goal of having a 146 centralized controller, but also leverage the existing PCE network 147 components. 149 The Path Computation Element communication Protocol (PCEP) provides 150 mechanisms for Path Computation Elements (PCEs) to perform route 151 computations in response to Path Computation Clients (PCCs) requests. 152 PCEP Extensions for PCE-initiated LSP Setup in a Stateful PCE Model 153 [I-D.ietf-pce-stateful-pce] describes a set of extensions to PCEP to 154 enable active control of MPLS-TE and GMPLS tunnels. 156 [I-D.ietf-pce-pce-initiated-lsp] describes the setup and tear down of 157 PCE-initiated LSPs under the active stateful PCE model, without the 158 need for local configuration on the PCC, thus allowing for a dynamic 159 MPLS network that is centrally controlled and deployed. 161 [I-D.ietf-teas-pce-central-control] introduces the architecture for 162 PCE as a central controller, examines the motivations and 163 applicability for PCEP as a southbound interface, and introduces the 164 implications for the protocol. [I-D.ietf-teas-pcecc-use-cases] 165 describes the use cases for the PCECC architecture. 167 This draft specify the procedures and PCEP protocol extensions for 168 using the PCE as the central controller and user cases where LSPs are 169 calculated/setup/initiated/downloaded through extending the existing 170 PCE architectures and PCEP. 172 The extension for PCECC in Segment Routing (SR) is specified in a 173 seperate draft [I-D.zhao-pce-pcep-extension-pce-controller-sr]. 175 1.1. Requirements Language 177 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 178 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 179 document are to be interpreted as described in [RFC2119]. 181 2. Terminology 183 Terminologies used in this document is same as described in the draft 184 [I-D.ietf-teas-pcecc-use-cases]. 186 3. Basic PCECC Mode 188 In this mode LSPs are provisioned as explicit label instructions at 189 each hop on the end-to-end path. Each router along the path must be 190 told what label forwarding instructions to program and what resources 191 to reserve. The controller uses PCEP to communicate with each router 192 along the path of the end-to-end LSP. 194 Note that the PCE-based controller will take responsibility for 195 managing some part of the MPLS label space for each of the routers 196 that it controls, and may taker wider responsibility for partitioning 197 the label space for each router and allocating different parts for 198 different uses. This is also described in section 3.1.2. of 199 [I-D.ietf-teas-pce-central-control]. For the purpose of this 200 document, it is assumed that label range to be used by a PCE is set 201 on both PCEP peers. A future extention MAY add capability to 202 advertise the range via possible PCEP extention as well. The rest of 203 processing is similar to the existing stateful PCE mechanism. 205 4. PCEP Requirements 207 Following key requirements associated PCECC should be considered when 208 designing the PCECC based solution: 210 1. PCEP speaker supporting this draft MUST have the capability to 211 advertise its PCECC capability to its peers. 213 2. PCEP speaker not supporting this draft MUST be able to reject 214 PCECC related message with a reason code that indicates no 215 support for PCECC. 217 3. PCEP SHOULD provide a means to identify PCECC based LSP in the 218 PCEP messages. 220 4. PCEP SHOULD provide a means to update (or cleanup) the label- 221 download entry to the PCC. 223 5. PCEP SHOULD provide a means to synchronize the labels between PCE 224 to PCC in PCEP messages. 226 5. Procedures for Using the PCE as the Central Controller (PCECC) 228 5.1. Stateful PCE Model 230 Active stateful PCE is described in [I-D.ietf-pce-stateful-pce]. PCE 231 as a central controller (PCECC) reuses existing Active stateful PCE 232 mechanism as much as possible to control the LSP. 234 5.2. New LSP Functions 236 This document defines the following new PCEP messages and extends the 237 existing messages to support PCECC: 239 (PCRpt): a PCEP message described in [I-D.ietf-pce-stateful-pce]. 240 PCRpt message MAYBE used to send PCECC LSP Reports. 242 (PCInitiate): a PCEP message described in 243 [I-D.ietf-pce-pce-initiated-lsp]. PCInitiate message is used to 244 setup PCE-Initiated LSP based on PCECC mechanism. 246 (PCUpd): a PCEP message described in [I-D.ietf-pce-stateful-pce]. 247 PCUpd message is used to send PCECC LSP Update. 249 (PCLabelUpd): a new PCEP message sent by a PCE to a PCC to download 250 or cleanup the Label entry. The PCLabelUpd message described in 251 Section 6.1.1. 253 (PCLabelRpt): a new PCEP message sent by a PCC to a PCE to report 254 the set of labels for which explicit action is required from PCE 255 to update or cleanup or do nothing for these Label entries. The 256 PCLabelRpt message described in Section 6.1.2. 258 The new LSP functions defined in this document are mapped onto the 259 messages as shown in the following table. 261 +----------------------------------------+--------------------------+ 262 | Function | Message | 263 +----------------------------------------+--------------------------+ 264 | PCECC Capability advertisement | Open | 265 | Label entry Update | PCLabelUpd | 266 | Label entry Cleanup | PCLabelUpd | 267 | PCECC Initiated LSP | PCInitiate | 268 | PCECC LSP Update | PCUpd | 269 | PCECC LSP State Report | PCRpt | 270 | PCECC LSP Delegation | PCRpt | 271 | PCECC Label Report | PCLabelRpt | 272 +----------------------------------------+--------------------------+ 274 5.3. PCECC Capability Advertisement 276 During PCEP Initialization Phase, PCEP Speakers (PCE or PCC) 277 advertise their support of PCECC extensions. A PCEP Speaker includes 278 the "PCECC Capability" TLV, described in Section 7.1.1 of this 279 document, in the OPEN Object to advertise its support for PCECC 280 extensions. 282 The presence of the PCECC Capability TLV in PCC's OPEN Object 283 indicates that the PCC is willing to function as a PCECC client. 285 The presence of the PCECC Capability TLV in PCE's OPEN message 286 indicates that the PCE is interested in function as a PCECC server. 288 The PCEP protocol extensions for PCECC MUST NOT be used if one or 289 both PCEP Speakers have not included the PCECC Capability TLV in 290 their respective OPEN message. If the PCEP Speakers support the 291 extensions of this draft but did not advertise this capability then a 292 PCErr message with Error-Type=19(Invalid Operation) and Error- 293 Value=TBD (Attempted LSP setup/download/label-range reservation if 294 PCECC capability was not advertised) will be generated and the PCEP 295 session will be terminated. 297 A PCC or a PCE MUST include both PCECC-CAPABILITY TLV and STATEFUL- 298 PCE-CAPABILITY TLV ([I-D.ietf-pce-stateful-pce]) in OPEN Object to 299 support the extensions defined in this document. If PCECC-CAPABILITY 300 TLV is advertised and STATEFUL-PCE-CAPABILITY TLV is not advertised 301 in OPEN Object, it SHOULD send a PCErr message with Error-Type=19 302 (Invalid Operation) and Error-value=TBD(stateful PCE capability was 303 not advertised) and terminate the session. 305 5.4. LSP Operations 307 The PCEP messages pertaining to PCECC MUST include PATH-SETUP-TYPE 308 TLV [I-D.ietf-pce-lsp-setup-type] in the SRP object to clearly 309 identify the PCECC LSP is intended. 311 5.4.1. Basic PCECC LSP Setup 313 In order to setup a LSP based on PCECC mechanism, a PCC MUST delegate 314 the LSP by sending a PCRpt message with Path Setup Type set for basic 315 PCECC (see Section 7.2) and D (Delegate) flag (see 316 [I-D.ietf-pce-stateful-pce]) set in the LSP object. 318 LSP-IDENTIFIER TLV MAY be included for PCECC LSP, the LSP-ID SHOULD 319 be generated by the PCE for PCECC LSP. In the first PCRpt message of 320 PCECC LSP, LSP ID of LSP-IDENTIFIER TLV is set to zero. 322 When a PCE receives PCRpt message with D flags and PST Type set, it 323 MAY generates LSP ID; calculates the path and assigns labels along 324 the path; and setups the path by sending PCLabelUpd message to each 325 node along the path of the LSP. 327 In response to the delegate PCRpt message, the PCE SHOULD send the 328 PCUpd message with the same PLSP-ID to the Ingress PCC. 330 The PCECC LSPs MUST be delegated to a PCE at all times. 332 LSP deletion operation for PCECC LSP is same as defined in 333 [I-D.ietf-pce-stateful-pce]. If the PCE receives PCRpt message for 334 LSP deletion then it does Label cleanup operation as described in 335 Section 5.4.2.2 for the corresponding LSP. 337 The Basic PCECC LSP setup sequence is as shown below using a new 338 message PCLabelUpd. 340 +-------+ +-------+ 341 |PCC | | PCE | 342 |Ingress| +-------+ 343 +------| | | 344 | PCC +-------+ | 345 | Transit| | | 346 +------| | |-- PCRpt,PLSP-ID=1, PST=TBD, D=1---->| PCECC LSP 347 |PCC +--------+ | (LSP ID=0) |(LSPID=1) 348 |Egress | | | | 349 +--------+ | | | 350 | | | | 351 |<------ PCLabelUpd,PLSP-ID=1 -------------------- | Label 352 | | | (LSP ID=1) | download 353 | | | | 354 | |<----- PCLabelUpd,PLSP-ID=1 ------------- | Label 355 | | | (LSP ID=1) | download 356 | | | | 357 | | |<--- PCLabelUpd,PLSP-ID=1 --------- | Label 358 | | | (LSP ID=1) | download 359 | | | | 360 | | |<-- PCUpd,PLSP-ID=1,PST=TBD, D=1-----| PCECC LSP 361 | | | (LSP ID=1) | Update 362 | | | | 364 Figure 2: Using PCLabelUpd For Label Operations 366 The PCECC LSP are considered to be 'up' by default. The Ingress MAY 367 further choose to deploy a data plane check mechanism and report the 368 status back to the PCE via PCRpt message. 370 5.4.2. Label Operations 372 The new label operations in PCEP can be done via a new PCLabelUpd 373 message and by defining new PCEP Objects for Label operations. Local 374 label range of each PCC can be configured at PCE and PCE. 376 5.4.2.1. Label Download 378 In order to setup an LSP based on PCECC, the PCE sends a PCLabelUpd 379 message to each node of the LSP to download the Label entry as 380 described in Section 5.4.1. 382 The LSP object in PCLabelUpd MUST include the LSP-IDENTIFIER TLV. 384 If a node (PCC) receives a PCLabelUpd message with a Label, out of 385 the range set aside for the PCE, it MUST send a PCErr message with 386 Error-type=TBD (label download failure) and Error-value=TBD (Label 387 out of range) and MUST include the SRP object to specify the error is 388 for the corresponding label update. If a PCC receives a PCLabelUpd 389 message but failed to download the Label entry, it MUST send a PCErr 390 message with Error-type=TBD (label download failure) and Error- 391 value=TBD (label failed to be download)and MUST include the SRP 392 object to specify the error is for the corresponding label update. 394 New PCEP object for LABEL is defined in Section 7.3 to encode the 395 Label operations. 397 5.4.2.2. Label Cleanup 399 In order to delete an LSP based on PCECC, the PCE sends a PCLabelUpd 400 message to each node along the path of the LSP to cleanup the Label 401 entry. 403 If the PCC receives a PCLabelUpd message but does not recognize the 404 label, the PCC MUST generate a PCErr message with Error-Type 405 19(Invalid operation) and Error-Value=TBD, "Unknown Label" and MUST 406 include the SRP object to specify the error is for the corresponding 407 label cleanup. 409 The R flag in SRP object defined in [I-D.ietf-pce-pce-initiated-lsp] 410 specifies the deletion of Label Entry in the new PCLabelUpd message. 412 +-------+ +-------+ 413 |PCC | | PCE | 414 |Ingress| +-------+ 415 +------| | | 416 | PCC +-------+ | 417 | Transit| | | 418 +------| | |-- PCRpt,PLSP-ID=1,PST=TBD,D=1,R=1--->| PCECC LSP 419 |PCC +--------+ | (LSP ID=1) | remove 420 |Egress | | | | 421 +--------+ | | | 422 | | | | 423 |<------ PCLabelUpd, PLSP-ID=1 --------------------- | Label 424 | | | (LSP ID=1, R=1) | cleanup 425 | | | | 426 | |<----- PCLabelUpd, PLSP-ID=1 -------------- | Label 427 | | | (LSP ID=1, R=1) | cleanup 428 | | | | 429 | | |<--- PCLabelUpd, PLSP-ID=1 ---------- | Label 430 | | | (LSP ID=1, R=1) | cleanup 431 | | | | 433 5.4.3. PCE Initiated PCECC LSP 435 The LSP Instantiation operation is same as defined in 436 [I-D.ietf-pce-pce-initiated-lsp]. 438 In order to setup a PCE Initiated LSP based on PCECC mechanism, a PCE 439 sends PCInitiate message with Path Setup Type set for basic PCECC 440 (see Section 7.2) to the Ingress PCC. 442 The Ingress PCC MUST also set D (Delegate) flag (see 443 [I-D.ietf-pce-stateful-pce]) and C (Create) flag (see 444 [I-D.ietf-pce-pce-initiated-lsp]) in LSP object of PCRpt message. 445 The PCC responds with first PCRpt message with the status as "GOING- 446 UP" and assigned PLSP-ID. 448 The rest of the PCECC LSP setup operations are same as those 449 described in Section 5.4.1. 451 The LSP deletion operation for PCE Initiated PCECC LSP is same as 452 defined in [I-D.ietf-pce-pce-initiated-lsp]. The PCE should further 453 perform Label entry cleanup operation as described in Section 5.4.2.2 454 for the corresponding LSP. 456 The PCE Initiated PCECC LSP setup sequence is shown below using a new 457 PCLabelUpd message. 459 +-------+ +-------+ 460 |PCC | | PCE | 461 |Ingress| +-------+ 462 +------| | | 463 | PCC +-------+ | 464 | Transit| | | 465 +------| | |<--PCInitiate,PLSP-ID=0,PST=TBD,D=1---| PCECC LSP 466 |PCC +--------+ | | Initiate 467 |Egress | | |--- PCRpt,PLSP-ID=2,P=1,D=1,C=1---> | PCECC LSP 468 +--------+ | | (LSP ID=0,GOING-UP) |(LSPID=2 469 | | | | assigned) 470 |<------ PCLabelUpd, PLSP-ID=2 --------------------- | Label 471 | | | (LSP ID=2) | download 472 | | | | 473 | |<----- PCLabelUpd, PLSP-ID=2 -------------- | Label 474 | | | (LSP ID=2) | download 475 | | | | 476 | | |<--- PCLabelUpd, PLSP-ID=2 ---------- | Label 477 | | | (LSP ID=2) | download 478 | | | | 479 | | |<-- PCUpd, PLSP-ID=2, PST=TBD, D=1--- | PCECC LSP 480 | | | (LSP ID=2) | Update 481 | | | | 483 5.4.4. PCECC LSP Update 485 Incase of a modification of PCECC LSP with a new path, a PCE sends a 486 PCUpd message to the Ingress PCC. 488 When a PCC receives a PCUpd message for an existing LSP, a PCC MAY 489 follow the make-before-break procedure i.e. first download labels for 490 the updated LSP and then switch traffic, before cleaning up the old 491 labels. On successful traffic switch over to the new LSP, PCC sends 492 a PCRpt message to the PCE for the deletion of old LSP. Further the 493 PCE does cleanup operation for the old LSP as described in 494 Section 5.4.2.2. 496 The PCECC LSP Update and make-before-break sequence is shown below 497 using a new PCLabelUpd message. 499 +-------+ +-------+ 500 |PCC | | PCE | 501 |Ingress| +-------+ 502 +------| | | 503 | PCC +-------+ | 504 | Transit| | | 505 +------| | | | 506 |PCC +--------+ | | 507 |Egress | | | | 508 +--------+ | | | 509 | | | | Modify LSP 510 |<------ PCLabelUpd, PLSP-ID=1 ------------------- | (LSPID=3 511 | | | (LSP ID=3) | assigned) 512 | | | | 513 | |<----- PCLabelUpd, PLSP-ID=1------------- | Label 514 | | | (LSP ID=3) | download 515 | | | | 516 | | |<--- PCLabelUpd, PLSP-ID=1 -------- | Label 517 | | | (LSP ID=3) | download 518 | | | | 519 | | |<-- PCUpd, PLSP-ID=1, PST=TBD, D=1-- | PCECC 520 | | | (LSP ID=3) | LSP Update 521 | | | | 522 | | |-- PCRpt,PLSP-ID=1,PST=TBD,D=1,R=1-->| Delete 523 | | | (LSP ID=1) | old LSP 524 | | | | 525 |<------ PCLabelUpd, PLSP-ID=1 ------------------- | Label 526 | | | (LSP ID=1, R=1) | cleanup 527 | | | | 528 | |<----- PCLabelUpd, PLSP-ID=1 ------------ | Label 529 | | | (LSP ID=1, R=1) | cleanup 530 | | | | 531 | | |<--- PCLabelUpd, PLSP-ID=1 -------- | Label 532 | | | (LSP ID=1, R=1) | cleanup 534 The modified PCECC LSP are considered to be 'up' by default. The 535 Ingress MAY further choose to deploy a data plane check mechanism and 536 report the status back to the PCE via PCRpt message. 538 5.4.5. Session Termination 540 PCC MUST mark all labels that were previously reported by this PCE as 541 stale on session down. [I-D.ietf-pce-stateful-pce] defines the State 542 Timeout Interval. The labels which are marked stale and provisioned 543 for the Basic PCECC LSP on this session MUST be cleaned up at the 544 expiration of the State Timeout Interval. The labels will be 545 retained when the Infinite State Timeout Interval is used. 547 5.4.6. LABEL-DB Synchronization 549 The purpose of LABEL-DB synchronization is to make sure that the 550 PCE's view of LABEL-DB matches with the PCC's LABEL-DB. The LABEL- 551 DB synchronization MUST be performed from PCE to PCC immediately 552 after the LSP state synchronization. [I-D.ietf-pce-stateful-pce] 553 describes the basic mechanism for LSP state synchronization. 554 [I-D.ietf-pce-stateful-sync-optimizations] describes the 555 optimizations for LSP state synchronization. 557 LABEL-DB synchronization is a two phase procedure. In first phase, 558 immediately after the LSP state synchronization PCE MUST synchronize 559 its LABEL-DB to PCC. In second phase, PCC MUST report all the stale 560 marked labels to PCE. 562 5.4.6.1. LABEL-DB Synchronization procedure 564 During LABEL-DB Synchronization, a PCE first takes a snapshot of the 565 label database for the session, then sends this snapshot to the PCC 566 in a sequence of Label Update message (PCLabelUpd message). Each 567 PCLabelUpd message sent during LABEL-DB Synchronization has the SYNC 568 Flag in the SRP Object(see Section 7.4) set to 1. 570 The end of synchronization marker is a PCLabelUpd message with the 571 SYNC Flag set to 0 for SRP Object and Label equal to a reserved value 572 of 0 in the LABEL object (Section 7.3). If the PCE has no label to 573 synchronize, it will only send the end of synchronization marker. 575 PCC MUST remove the stale marking for the all labels on receipt of 576 correspoding PCLabelUpd message during the LABEL-DB Synchronization 577 phase. The remaining stale marked labels after the LABEL-DB 578 synchronization process MUST be reported to PCE in a sequence of 579 Label Report message (PCLabelRpt message) with the SYNC Flag in the 580 SRP Object(see Section 7.4) set to 1. 582 The end of report synchronization marker is a PCLabelRpt message with 583 the SYNC Flag set to 0 for SRP Object with Label equal to reserved 584 value 0 in the LABEL object ((Section 7.3)). If the PCC has no label 585 to report, it will only send the end of report synchronization 586 marker. 588 Either the PCE or the PCC MAY terminate the session using the PCEP 589 session termination procedures during the LABEL-DB synchronization 590 phase. The session reestablishment MUST be re-attempted as per the 591 procedures defined in [RFC5440], including use of a back-off timer. 593 The PCC does not send positive acknowledgements for properly received 594 label database synchronization messages. It MUST respond with a 595 PCErr message with Error-type TBD1 (Label Database Synchronization 596 Error) and Error-value 1 (indicating an error in processing the 597 PCLabelUpd) if it encounters a problem with the Label Update it 598 received from the PCE and it MUST terminate the session. 600 If the PCE encounters a problem which prevents it from completing the 601 label transfer, it MUST send a PCErr message with Error-type TBD1 602 (Label Database Synchronization Error) and Error-value 2 (indicating 603 an internal PCE Error) to the PCC and terminate the session. 605 PCE MUST respond with a PCErr message with Error-type TBD1 (Label 606 Database Report Synchronization Error) and Error-value 1 (indicating 607 an error in processing the PCLabelRpt) if it encounters a problem 608 with the Label Report it received from the PCC and it MUST terminate 609 the session. 611 The successful LABEL-DB Synchronization sequence is shown below. 613 + +-+-+-+- + +-+-+-+- 614 | | | PCC | 615 | PCE | | Transit| 616 | | | Node | 617 +-+-+-+-+- +-+-+-+-+- 618 | | 619 | | 620 | . | 621 | . | 622 | | 623 |------- PCLabelUpd, PLSP-ID=2----->|(Label 624 | (LSP ID=2) | Download 625 | | for LSP's) 626 |------- PCLabelUpd, PLSP-ID=3----->| 627 | (LSP ID=3) | 628 | | 629 |------- PCLabelUpd, PLSP-ID=4----->| 630 | (LSP ID=4) | 631 | . | 632 | . |(Session 633 | | down, mark 634 |------- Session Down---------X | all label's 635 | | Stale of this 636 | . | Session) 637 | . | 638 |<------ Session Re-established---->|(Session up) 639 | . | 640 | . | 641 |<-----PCRpt, SYNC=0----------------| (No LSP to SYNC) 642 | | 643 |----PCLabelUpd,PLSP-ID=2,SYNC=1--->|(LABEL-DB 644 |----PCLabelUpd,PLSP-ID=3,SYNC=1--->| SYNC, unmark 645 | | stale label) 646 |------PCLabelUpd, SYNC=0---------->| 647 | |(End of LABEL-DB 648 | | SYNC) 649 | | 650 |<-----PCLabelRpt,PLSP-ID=4,SYNC=1--|(Report all stale 651 | | Labels of this 652 |<-----PCLabelRpt,SYNC=0------------| Session) 653 | | 654 |------- PCLabelUpd, PLSP-ID=4 ---->|Label Cleanup 655 | (LSP ID=4, R=1) | 656 | | 657 | | 659 5.4.7. PCECC LSP State Report 661 As mentioned before, an Ingress PCC MAY choose to apply any OAM 662 mechanism to check the status of LSP in the Data plane and MAY 663 further send its status in PCRpt message to the PCE. 665 6. PCEP messages 667 As defined in [RFC5440], a PCEP message consists of a common header 668 followed by a variable-length body made of a set of objects that can 669 be either mandatory or optional. An object is said to be mandatory 670 in a PCEP message when the object must be included for the message to 671 be considered valid. For each PCEP message type, a set of rules is 672 defined that specify the set of objects that the message can carry. 673 An implementation MUST form the PCEP messages using the object 674 ordering specified in this document. 676 LSP-IDENTIFIERS TLV MAY be included in the LSP object for PCECC LSP. 678 6.1. Label Operations 680 6.1.1. The PCLabelUpd message 682 A new Label Update Message (also referred to as PCLabelUpd) is a PCEP 683 message sent by a PCE to a PCC to download label or update the label 684 map. The same message is also used to cleanup the Label entry. The 685 Message-Type field of the PCEP common header for the PCLabelUpd 686 message is set to TBD. 688 The format of the PCLabelUpd message is as follows: 690 ::= 691 692 Where: 693 ::= 694 [] 696 ::= 698 Where: 699 ::= 700 701 703 ::=