idnits 2.17.1 draft-ietf-pce-pcep-extension-for-pce-controller-01.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 (February 5, 2019) is 1906 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-02 == Outdated reference: A later version (-23) exists of draft-ietf-pce-pcep-yang-09 == Outdated reference: A later version (-09) exists of draft-zhao-pce-pcep-extension-pce-controller-sr-03 == Outdated reference: A later version (-16) exists of draft-li-pce-controlled-id-space-01 == Outdated reference: A later version (-07) exists of draft-sivabalan-pce-binding-label-sid-05 == Outdated reference: A later version (-08) exists of draft-li-pce-sr-path-segment-03 Summary: 1 error (**), 0 flaws (~~), 7 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 M. Negi 5 Expires: August 9, 2019 Huawei Technologies 6 C. Zhou 7 Cisco Systems 8 February 5, 2019 10 PCEP Procedures and Protocol Extensions for Using PCE as a Central 11 Controller (PCECC) of LSPs 12 draft-ietf-pce-pcep-extension-for-pce-controller-01 14 Abstract 16 The Path Computation Element (PCE) is a core component of Software- 17 Defined Networking (SDN) systems. It can compute optimal paths for 18 traffic across a network and can also update the paths to reflect 19 changes in the network or traffic demands. 21 PCE was developed to derive paths for MPLS Label Switched Paths 22 (LSPs), which are supplied to the head end of the LSP using the Path 23 Computation Element Communication Protocol (PCEP). But SDN has a 24 broader applicability than signaled (G)MPLS traffic-engineered (TE) 25 networks, and the PCE may be used to determine paths in a range of 26 use cases. PCEP has been proposed as a control protocol for use in 27 these environments to allow the PCE to be fully enabled as a central 28 controller. 30 A PCE-based central controller (PCECC) can simplify the processing of 31 a distributed control plane by blending it with elements of SDN and 32 without necessarily completely replacing it. Thus, the LSP can be 33 calculated/setup/initiated and the label forwarding entries can also 34 be downloaded through a centralized PCE server to each network 35 devices along the path while leveraging the existing PCE technologies 36 as much as possible. 38 This document specifies the procedures and PCEP protocol extensions 39 for using the PCE as the central controller. 41 Status of This Memo 43 This Internet-Draft is submitted in full conformance with the 44 provisions of BCP 78 and BCP 79. 46 Internet-Drafts are working documents of the Internet Engineering 47 Task Force (IETF). Note that other groups may also distribute 48 working documents as Internet-Drafts. The list of current Internet- 49 Drafts is at https://datatracker.ietf.org/drafts/current/. 51 Internet-Drafts are draft documents valid for a maximum of six months 52 and may be updated, replaced, or obsoleted by other documents at any 53 time. It is inappropriate to use Internet-Drafts as reference 54 material or to cite them other than as "work in progress." 56 This Internet-Draft will expire on August 9, 2019. 58 Copyright Notice 60 Copyright (c) 2019 IETF Trust and the persons identified as the 61 document authors. All rights reserved. 63 This document is subject to BCP 78 and the IETF Trust's Legal 64 Provisions Relating to IETF Documents 65 (https://trustee.ietf.org/license-info) in effect on the date of 66 publication of this document. Please review these documents 67 carefully, as they describe your rights and restrictions with respect 68 to this document. Code Components extracted from this document must 69 include Simplified BSD License text as described in Section 4.e of 70 the Trust Legal Provisions and are provided without warranty as 71 described in the Simplified BSD License. 73 Table of Contents 75 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 76 1.1. Requirements Language . . . . . . . . . . . . . . . . . . 5 77 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5 78 3. Basic PCECC Mode . . . . . . . . . . . . . . . . . . . . . . 5 79 4. PCEP Requirements . . . . . . . . . . . . . . . . . . . . . . 5 80 5. Procedures for Using the PCE as the Central Controller 81 (PCECC) . . . . . . . . . . . . . . . . . . . . . . . . . . . 6 82 5.1. Stateful PCE Model . . . . . . . . . . . . . . . . . . . 6 83 5.2. New LSP Functions . . . . . . . . . . . . . . . . . . . . 6 84 5.3. PCECC Capability Advertisement . . . . . . . . . . . . . 7 85 5.4. LSP Operations . . . . . . . . . . . . . . . . . . . . . 8 86 5.4.1. Basic PCECC LSP Setup . . . . . . . . . . . . . . . . 8 87 5.4.2. Central Control Instructions . . . . . . . . . . . . 12 88 5.4.2.1. Label Download . . . . . . . . . . . . . . . . . 12 89 5.4.2.2. Label Cleanup . . . . . . . . . . . . . . . . . . 12 90 5.4.3. PCE Initiated PCECC LSP . . . . . . . . . . . . . . . 13 91 5.4.4. PCECC LSP Update . . . . . . . . . . . . . . . . . . 15 92 5.4.5. Re Delegation and Cleanup . . . . . . . . . . . . . . 17 93 5.4.6. Synchronization of Central Controllers Instructions . 17 94 5.4.7. PCECC LSP State Report . . . . . . . . . . . . . . . 17 95 5.4.8. PCC Based Allocations . . . . . . . . . . . . . . . . 18 96 5.4.9. Binding Label . . . . . . . . . . . . . . . . . . . . 18 97 6. PCEP messages . . . . . . . . . . . . . . . . . . . . . . . . 19 98 6.1. The PCInitiate message . . . . . . . . . . . . . . . . . 19 99 6.2. The PCRpt message . . . . . . . . . . . . . . . . . . . . 21 100 7. PCEP Objects . . . . . . . . . . . . . . . . . . . . . . . . 21 101 7.1. OPEN Object . . . . . . . . . . . . . . . . . . . . . . . 22 102 7.1.1. PCECC Capability sub-TLV . . . . . . . . . . . . . . 22 103 7.2. PATH-SETUP-TYPE TLV . . . . . . . . . . . . . . . . . . . 22 104 7.3. CCI Object . . . . . . . . . . . . . . . . . . . . . . . 23 105 7.3.1. Address TLVs . . . . . . . . . . . . . . . . . . . . 24 106 8. Security Considerations . . . . . . . . . . . . . . . . . . . 26 107 8.1. Malicious PCE . . . . . . . . . . . . . . . . . . . . . . 26 108 9. Manageability Considerations . . . . . . . . . . . . . . . . 26 109 9.1. Control of Function and Policy . . . . . . . . . . . . . 26 110 9.2. Information and Data Models . . . . . . . . . . . . . . . 26 111 9.3. Liveness Detection and Monitoring . . . . . . . . . . . . 26 112 9.4. Verify Correct Operations . . . . . . . . . . . . . . . . 26 113 9.5. Requirements On Other Protocols . . . . . . . . . . . . . 26 114 9.6. Impact On Network Operations . . . . . . . . . . . . . . 27 115 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 27 116 10.1. PCEP TLV Type Indicators . . . . . . . . . . . . . . . . 27 117 10.2. New Path Setup Type Registry . . . . . . . . . . . . . . 27 118 10.3. PCEP Object . . . . . . . . . . . . . . . . . . . . . . 27 119 10.4. CCI Object Flag Field . . . . . . . . . . . . . . . . . 27 120 10.5. PCEP-Error Object . . . . . . . . . . . . . . . . . . . 28 121 11. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 28 122 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 28 123 12.1. Normative References . . . . . . . . . . . . . . . . . . 28 124 12.2. Informative References . . . . . . . . . . . . . . . . . 30 125 Appendix A. Contributor Addresses . . . . . . . . . . . . . . . 32 126 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 33 128 1. Introduction 130 The Path Computation Element (PCE) [RFC4655] was developed to offload 131 path computation function from routers in an MPLS traffic-engineered 132 network. Since then, the role and function of the PCE has grown to 133 cover a number of other uses (such as GMPLS [RFC7025]) and to allow 134 delegated control [RFC8231] and PCE-initiated use of network 135 resources [RFC8281]. 137 According to [RFC7399], Software-Defined Networking (SDN) refers to a 138 separation between the control elements and the forwarding components 139 so that software running in a centralized system, called a 140 controller, can act to program the devices in the network to behave 141 in specific ways. A required element in an SDN architecture is a 142 component that plans how the network resources will be used and how 143 the devices will be programmed. It is possible to view this 144 component as performing specific computations to place traffic flows 145 within the network given knowledge of the availability of network 146 resources, how other forwarding devices are programmed, and the way 147 that other flows are routed. This is the function and purpose of a 148 PCE, and the way that a PCE integrates into a wider network control 149 system (including an SDN system) is presented in [RFC7491]. 151 In early PCE implementations, where the PCE was used to derive paths 152 for MPLS Label Switched Paths (LSPs), paths were requested by network 153 elements (known as Path Computation Clients (PCCs)), and the results 154 of the path computations were supplied to network elements using the 155 Path Computation Element Communication Protocol (PCEP) [RFC5440]. 156 This protocol was later extended to allow a PCE to send unsolicited 157 requests to the network for LSP establishment [RFC8281]. 159 [RFC8283] introduces the architecture for PCE as a central controller 160 as an extension of the architecture described in [RFC4655] and 161 assumes the continued use of PCEP as the protocol used between PCE 162 and PCC. [RFC8283] further examines the motivations and 163 applicability for PCEP as a Southbound Interface (SBI), and 164 introduces the implications for the protocol. 165 [I-D.ietf-teas-pcecc-use-cases] describes the use cases for the PCECC 166 architecture. 168 A PCE-based central controller (PCECC) can simplify the processing of 169 a distributed control plane by blending it with elements of SDN and 170 without necessarily completely replacing it. Thus, the LSP can be 171 calculated/setup/initiated and the label forwarding entries can also 172 be downloaded through a centralized PCE server to each network 173 devices along the path while leveraging the existing PCE technologies 174 as much as possible. 176 This draft specify the procedures and PCEP protocol extensions for 177 using the PCE as the central controller for static LSPs, where LSPs 178 can be provisioned as explicit label instructions at each hop on the 179 end-to-end path. Each router along the path must be told what label- 180 forwarding instructions to program and what resources to reserve. 181 The PCE-based controller keeps a view of the network and determines 182 the paths of the end-to-end LSPs, and the controller uses PCEP to 183 communicate with each router along the path of the end-to-end LSP. 185 The extension for PCECC in Segment Routing (SR) is specified in a 186 separate draft [I-D.zhao-pce-pcep-extension-pce-controller-sr]. 188 1.1. Requirements Language 190 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 191 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 192 "OPTIONAL" in this document are to be interpreted as described in BCP 193 14 [RFC2119] [RFC8174] when, and only when, they appear in all 194 capitals, as shown here. 196 2. Terminology 198 Terminologies used in this document is same as described in the draft 199 [RFC8283] and [I-D.ietf-teas-pcecc-use-cases]. 201 3. Basic PCECC Mode 203 In this mode LSPs are provisioned as explicit label instructions at 204 each hop on the end-to-end path. Each router along the path must be 205 told what label forwarding instructions to program and what resources 206 to reserve. The controller uses PCEP to communicate with each router 207 along the path of the end-to-end LSP. 209 Note that the PCE-based controller will take responsibility for 210 managing some part of the MPLS label space for each of the routers 211 that it controls, and may taker wider responsibility for partitioning 212 the label space for each router and allocating different parts for 213 different uses. This is also described in section 3.1.2. of 214 [RFC8283]. For the purpose of this document, it is assumed that 215 label range to be used by a PCE is known and set on both PCEP peers. 216 A future extension could add this capability to advertise the range 217 via possible PCEP extensions as well (see 218 [I-D.li-pce-controlled-id-space]). The rest of processing is similar 219 to the existing stateful PCE mechanism. 221 This document also allow a case where the label space is maintained 222 by PCC itself, and the labels are allocated by the PCC, in this case, 223 the PCE should request the allocation from PCC as described in 224 Section 5.4.8. 226 4. PCEP Requirements 228 Following key requirements associated PCECC should be considered when 229 designing the PCECC based solution: 231 1. PCEP speaker supporting this draft MUST have the capability to 232 advertise its PCECC capability to its peers. 234 2. PCEP speaker not supporting this draft MUST be able to reject 235 PCECC related extensions with a error reason code that indicates 236 that this feature is not supported. 238 3. PCEP speaker MUST provide a means to identify PCECC based LSP in 239 the PCEP messages. 241 4. PCEP procedures SHOULD provide a means to update (or cleanup) the 242 label- download entry to the PCC. 244 5. PCEP procedures SHOULD provide a means to synchronize the labels 245 between PCE to PCC in PCEP messages. 247 5. Procedures for Using the PCE as the Central Controller (PCECC) 249 5.1. Stateful PCE Model 251 Active stateful PCE is described in [RFC8231]. PCE as a central 252 controller (PCECC) reuses existing Active stateful PCE mechanism as 253 much as possible to control the LSP. 255 5.2. New LSP Functions 257 This document defines the following new PCEP messages and extends the 258 existing messages to support PCECC: 260 (PCRpt): a PCEP message described in [RFC8231]. PCRpt message is 261 used to send PCECC LSP Reports. It is also extended to report the 262 set of Central Controller's Instructions (CCI) (label forwarding 263 instructions in the context of this document) received from the 264 PCE. See Section 5.4.6 for more details. 266 (PCInitiate): a PCEP message described in [RFC8281]. PCInitiate 267 message is used to setup PCE-Initiated LSP based on PCECC 268 mechanism. It is also extended for Central Controller's 269 Instructions (CCI) (download or cleanup the Label forwarding 270 instructions in the context of this document) on all nodes along 271 the path. 273 (PCUpd): a PCEP message described in [RFC8231]. PCUpd message is 274 used to send PCECC LSP Update. 276 The new LSP functions defined in this document are mapped onto the 277 messages as shown in the following table. 279 +----------------------------------------+--------------------------+ 280 | Function | Message | 281 +----------------------------------------+--------------------------+ 282 | PCECC Capability advertisement | Open | 283 | Label entry Add | PCInitiate | 284 | Label entry Cleanup | 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 | PCRpt | 290 +----------------------------------------+--------------------------+ 292 This document specify a new object CCI (see Section 7.3) for the 293 encoding of central controller's instructions. In the scope of this 294 document this is limited to Label forwarding instructions. The CC-ID 295 is the unique identifier for the central controller's instructions in 296 PCEP. The PCEP messages are extended in this document to handle the 297 PCECC operations. 299 5.3. PCECC Capability Advertisement 301 During PCEP Initialization Phase, PCEP Speakers (PCE or PCC) 302 advertise their support of PCECC extensions. 304 This document defines a new Path Setup Type (PST) [RFC8408] for 305 PCECC, as follows: 307 o PST = TBD: Path is setup via PCECC mode. 309 A PCEP speaker MUST indicate its support of the function described in 310 this document by sending a PATH-SETUP-TYPE-CAPABILITY TLV in the OPEN 311 object with this new PST included in the PST list. 313 This document also defines the PCECC Capability sub-TLV 314 Section 7.1.1. PCEP speakers use this sub-TLV to exchange 315 information about their PCECC capability. If a PCEP speaker includes 316 PST=TBD in the PST List of the PATH-SETUP-TYPE-CAPABILITY TLV then it 317 MUST also include the PCECC Capability sub-TLV inside the PATH-SETUP- 318 TYPE-CAPABILITY TLV. 320 The presence of the PST and PCECC Capability sub-TLV in PCC's OPEN 321 Object indicates that the PCC is willing to function as a PCECC 322 client. 324 The presence of the PST and PCECC Capability sub-TLV in PCE's OPEN 325 message indicates that the PCE is interested in function as a PCECC 326 server. 328 The PCEP protocol extensions for PCECC MUST NOT be used if one or 329 both PCEP Speakers have not included the PST or the PCECC Capability 330 sub-TLV in their respective OPEN message. If the PCEP Speakers 331 support the extensions of this draft but did not advertise this 332 capability then a PCErr message with Error-Type=19(Invalid Operation) 333 and Error-Value=TBD (Attempted PCECC operations when PCECC capability 334 was not advertised) will be generated and the PCEP session will be 335 terminated. 337 A PCC or a PCE MUST include both PCECC-CAPABILITY sub-TLV and 338 STATEFUL-PCE-CAPABILITY TLV ([RFC8231]) (with I flag set [RFC8281]) 339 in OPEN Object to support the extensions defined in this document. 340 If PCECC-CAPABILITY sub-TLV is advertised and STATEFUL-PCE-CAPABILITY 341 TLV is not advertised in OPEN Object, it SHOULD send a PCErr message 342 with Error-Type=19 (Invalid Operation) and Error-value=TBD (stateful 343 PCE capability was not advertised) and terminate the session. 345 5.4. LSP Operations 347 The PCEP messages pertaining to PCECC MUST include PATH-SETUP-TYPE 348 TLV [RFC8408] in the SRP object to clearly identify the PCECC LSP is 349 intended. 351 5.4.1. Basic PCECC LSP Setup 353 In order to setup a LSP based on PCECC mechanism, a PCC MUST delegate 354 the LSP by sending a PCRpt message with PST set for PCECC (see 355 Section 7.2) and D (Delegate) flag (see [RFC8231]) set in the LSP 356 object. 358 LSP-IDENTIFIER TLV MUST be included for PCECC LSP, the tuple uniquely 359 identifies the LSP in the network. The LSP object is included in 360 central controller's instructions (label download) to identify the 361 PCECC LSP for this instruction. The PLSP-ID is the original 362 identifier used by the ingress PCC, so the transit LSR could have 363 multiple central controller instructions that have the same PLSP-ID. 364 The PLSP-ID in combination with the source (in LSP-IDENTIFIER TLV) 365 MUST be unique. The PLSP-ID is included for maintainability reasons. 366 As per [RFC8281], the LSP object could include SPEAKER-ENTITY-ID TLV 367 to identify the PCE that initiated these instructions. Also the CC- 368 ID is unique on the PCEP session as described in Section 7.3. 370 When a PCE receives PCRpt message with D flags and PST Type set, it 371 calculates the path and assigns labels along the path; and set up the 372 path by sending PCInitiate message to each node along the path of the 373 LSP. The PCC generates a Path Computation State Report (PCRpt) and 374 include the central controller's instruction (CCI) and the identified 375 LSP. The CC-ID is uniquely identify the central controller's 376 instruction within PCEP. The PCC further responds with the PCRpt 377 messages including the CCI and LSP objects. 379 The Ingress node would receive one CCI object with O bit (out-label) 380 set. The transit node(s) would receive two CCI object with the in- 381 label CCI without O bit set and the out-label CCI with O bit set. 382 The egress node would receive one CCI object without O bit set. A 383 node can determine its role based on the setting of the O bit in the 384 CCI object(s). 386 Once the central controller's instructions (label operations) are 387 completed, the PCE SHOULD send the PCUpd message to the Ingress PCC. 388 The PCUpd message is as per [RFC8231] SHOULD include the path 389 information as calculated by the PCE. 391 Note that the PCECC LSPs MUST be delegated to a PCE at all times. 393 LSP deletion operation for PCECC LSP is same as defined in [RFC8231]. 394 If the PCE receives PCRpt message for LSP deletion then it does Label 395 cleanup operation as described in Section 5.4.2.2 for the 396 corresponding LSP. 398 The Basic PCECC LSP setup sequence is as shown below. 400 +-------+ +-------+ 401 |PCC | | PCE | 402 |Ingress| +-------+ 403 +------| | | 404 | PCC +-------+ | 405 | Transit| | | 406 +------| | |-- PCRpt,PLSP-ID=1, PST=TBD, D=1---->| PCECC LSP 407 |PCC +--------+ | | 408 |Egress | | | | 409 +--------+ | | | 410 | | | | 411 |<------ PCInitiate,CC-ID=X,PLSP-ID=1 ------------ | Label 412 | | | L1,O=0 | download 413 |------- PCRpt,CC-ID=X,PLSP-ID=1 ----------------->| 414 | | | | 415 | |<----- PCInitiate,PLSP-ID=1, ------------- | Labels 416 | | | CC-ID=Y1,O=0,L2 | download 417 | | | CC-ID=Y2,O=1,L1 | 418 | |----- PCRpt,CC-ID=Y1,Y2,PLSP-ID=1 ------>| 419 | | | | 420 | | |<--- PCInitiate,CC-ID=Z,PLSP-ID=1 - | Label 421 | | | L2,O=1 | download 422 | | |---- PCRpt,CC-ID=Z,PLSP-ID=1 ------>| 423 | | | | 424 | | |<-- PCUpd,PLSP-ID=1,PST=TBD, D=1-----| PCECC LSP 425 | | | | Update 426 | | | | 428 Figure 2: Basic PCECC LSP setup 430 The PCECC LSP are considered to be 'up' by default (on receipt of 431 PCUpd message from PCE). The Ingress MAY further choose to deploy a 432 data plane check mechanism and report the status back to the PCE via 433 PCRpt message. 435 In case where the label allocation are made by the PCC itself (see 436 Section 5.4.8), the PCE could still request an allocation to be made 437 by the PCC, and where the PCC would send a PCRpt with the allocated 438 label encoded in the CC-ID object as shown below - 439 +-------+ +-------+ 440 |PCC | | PCE | 441 |Ingress| +-------+ 442 +------| | | 443 | PCC +-------+ | 444 | Transit| | | 445 +------| | |-- PCRpt,PLSP-ID=1, PST=TBD, D=1---->| PCECC LSP 446 |PCC +--------+ | | 447 |Egress | | | | 448 +--------+ | | | 449 | | | | 450 |<------ PCInitiate,CC-ID=X,PLSP-ID=1 ------------ | Label 451 | | | C=1 | download 452 |------- PCRpt,CC-ID=X,PLSP-ID=1 ----------------->| 453 | | | Label=L1 | 454 | |<----- PCInitiate,PLSP-ID=1, ------------- | Labels 455 | | | CC-ID=Y1,C=1 | download 456 | | | CC-ID=Y2,C=0,L1 | 457 | |----- PCRpt,PLSP-ID=1 ------------------>| 458 | | | CC-ID=Y1, Label=L2 | 459 | | | CC-ID=Y2 | 460 | | |<--- PCInitiate,CC-ID=Z,PLSP-ID=1 - | Label 461 | | | C=0,L2 | download 462 | | |---- PCRpt,CC-ID=Z,PLSP-ID=1 ------>| 463 | | | | 464 | | |<-- PCUpd,PLSP-ID=1,PST=TBD, D=1-----| PCECC LSP 465 | | | | Update 466 | | | | 468 - The O bit is set as before (and thus not included) 470 Figure 3: Basic PCECC LSP setup (PCC allocation) 472 It should be noted that in this example, the request is made to the 473 egress node with C bit set in the CCI object to indicate that the 474 label allocation needs to be done by the egress and it responds with 475 the allocated label to the PCE. The PCE would further inform the 476 transit PCC without setting the C bit in the CCI object for out-label 477 but the C-bit is unset for in-label so the transit node make the 478 label allocation (for the in-label) and report to the PCE. Similarly 479 C bit is unset towards the ingress to complete all the label 480 allocation for the PCECC LSP. 482 5.4.2. Central Control Instructions 484 The new central controller's instructions (CCI) for the label 485 operations in PCEP is done via the PCInitiate message, by defining a 486 new PCEP Objects for CCI operations. Local label range of each PCC 487 is assumed to be known at both the PCC and the PCE. 489 5.4.2.1. Label Download 491 In order to setup an LSP based on PCECC, the PCE sends a PCInitiate 492 message to each node along the path to download the Label instruction 493 as described in Section 5.4.1. 495 The CCI object MUST be included, along with the LSP object in the 496 PCInitiate message. The LSP-IDENTIFIER TLV MUST be included in LSP 497 object. The SPEAKER-ENTITY-ID TLV SHOULD be included in LSP object. 499 If a node (PCC) receives a PCInitiate message which includes a Label 500 to download as part of CCI, that is out of the range set aside for 501 the PCE, it MUST send a PCErr message with Error-type=TBD (PCECC 502 failure) and Error-value=TBD (Label out of range) and MUST include 503 the SRP object to specify the error is for the corresponding label 504 update via PCInitiate message. If a PCC receives a PCInitiate 505 message but failed to download the Label entry, it MUST send a PCErr 506 message with Error-type=TBD (PCECC failure) and Error-value=TBD 507 (instruction failed) and MUST include the SRP object to specify the 508 error is for the corresponding label update via PCInitiate message. 510 New PCEP object for central control instructions (CCI) is defined in 511 Section 7.3. 513 5.4.2.2. Label Cleanup 515 In order to delete an LSP based on PCECC, the PCE sends a central 516 controller instructions via a PCInitiate message to each node along 517 the path of the LSP to cleanup the Label forwarding instruction. 519 If the PCC receives a PCInitiate message but does not recognize the 520 label in the CCI, the PCC MUST generate a PCErr message with Error- 521 Type 19(Invalid operation) and Error-Value=TBD, "Unknown Label" and 522 MUST include the SRP object to specify the error is for the 523 corresponding label cleanup (via PCInitiate message). 525 The R flag in the SRP object defined in [RFC8281] specifies the 526 deletion of Label Entry in the PCInitiate message. 528 +-------+ +-------+ 529 |PCC | | PCE | 530 |Ingress| +-------+ 531 +------| | | 532 | PCC +-------+ | 533 | Transit| | | 534 +------| | |-- PCRpt,PLSP-ID=1,PST=TBD,D=1,R=1--->| PCECC LSP 535 |PCC +--------+ | | remove 536 |Egress | | | | 537 +--------+ | | | 538 | | | | 539 |<------ PCInitiate,CC-ID=X,PLSP-ID=1 ------------ | Label 540 | | | R=1 | cleanup 541 |------- PCRpt,CC-ID=X,PLSP-ID=1 ------------------>| 542 | | | | 543 | |<----- PCInitiate,CC-ID=Y1,Y2,PLSP-ID=1 -- | Label 544 | | | R=1 | cleanup 545 | |----- PCRpt,CC-ID=Y1,Y2,PLSP-ID=1 ------->| 546 | | | | 547 | | |<--- PCInitiate,CC-ID=Z,PLSP-ID=1 -- | Label 548 | | | R=1 | cleanup 549 | | |---- PCRpt,CC-ID=Z,PLSP-ID=1 ------->| 550 | | | | 552 As per [RFC8281], following the removal of the Label forwarding 553 instruction, the PCC MUST send a PCRpt message. The SRP object in 554 the PCRpt MUST include the SRP-ID-number from the PCInitiate message 555 that triggered the removal. The R flag in the SRP object MUST be 556 set. 558 In case where the label allocation are made by the PCC itself (see 559 Section 5.4.8), the removal procedure remains the same. 561 5.4.3. PCE Initiated PCECC LSP 563 The LSP Instantiation operation is same as defined in [RFC8281]. 565 In order to setup a PCE Initiated LSP based on the PCECC mechanism, a 566 PCE sends PCInitiate message with Path Setup Type set for PCECC (see 567 Section 7.2) to the Ingress PCC. 569 The Ingress PCC MUST also set D (Delegate) flag (see [RFC8231]) and C 570 (Create) flag (see [RFC8281]) in LSP object of PCRpt message. The 571 PCC responds with first PCRpt message with the status as "GOING-UP" 572 and assigned PLSP-ID. 574 Note that the label forwarding instructions from PCECC are send after 575 the initial PCInitiate and PCRpt exchange. This is done so that the 576 PLSP-ID and other LSP identifiers can be obtained from the ingress 577 and can be included in the label forwarding instruction in the next 578 PCInitiate message. The rest of the PCECC LSP setup operations are 579 same as those described in Section 5.4.1. 581 The LSP deletion operation for PCE Initiated PCECC LSP is same as 582 defined in [RFC8281]. The PCE should further perform Label entry 583 cleanup operation as described in Section 5.4.2.2 for the 584 corresponding LSP. 586 The PCE Initiated PCECC LSP setup sequence is shown below - 588 +-------+ +-------+ 589 |PCC | | PCE | 590 |Ingress| +-------+ 591 +------| | | 592 | PCC +-------+ | 593 | Transit| | | 594 +------| | |<--PCInitiate,PLSP-ID=0,PST=TBD,D=1---| PCECC LSP 595 |PCC +--------+ | | Initiate 596 |Egress | | |--- PCRpt,PLSP-ID=2,P=1,D=1,C=1---> | PCECC LSP 597 +--------+ | | (GOING-UP) | 598 | | | | 599 |<------ PCInitiate,CC-ID=X,PLSP-ID=2 -------------- | Label 600 | | | | download 601 |------- PCRpt,CC-ID=X,PLSP-ID=2 ------------------>| 602 | | | | 603 | |<----- PCInitiate,CC-ID=Y1,Y2,PLSP-ID=2 --- | Label 604 | | | | download 605 | |----- PCRpt,CC-ID=Y1,Y2,PLSP-ID=2 ------->| 606 | | | | 607 | | |<--- PCInitiate,CC-ID=Z,PLSP-ID=2 --- | Label 608 | | | | download 609 | | |---- PCRpt,CC-ID=Z,PLSP-ID=2 ------->| 610 | | | | 611 | | |<-- PCUpd, PLSP-ID=2, PST=TBD, D=1--- | PCECC LSP 612 | | | (UP) | Update 613 | | |--- PCRpt,PLSP-ID=2,P=1,D=1,C=1---> | 614 | | | (UP) | 616 Once the label operations are completed, the PCE SHOULD send the 617 PCUpd message to the Ingress PCC. The PCUpd message is as per 618 [RFC8231]. 620 In case where the label allocation are made by the PCC itself (see 621 Section 5.4.8), the procedure remains similar. 623 5.4.4. PCECC LSP Update 625 In case of a modification of PCECC LSP with a new path, a PCE sends a 626 PCUpd message to the Ingress PCC. But to follow the make-before- 627 break procedures, the PCECC first update new instructions based on 628 the updated LSP and then update to ingress to switch traffic, before 629 cleaning up the old instructions. A new CC-ID is used to identify 630 the updated instruction, the existing identifiers in the LSP object 631 identify the existing LSP. Once new instructions are downloaded, the 632 PCE further updates the new path at the ingress which triggers the 633 traffic switch on the updated path. The Ingress PCC acknowledges 634 with a PCRpt message, on receipt of PCRpt message, the PCE does 635 cleanup operation for the old LSP as described in Section 5.4.2.2. 637 The PCECC LSP Update sequence is shown below - 638 +-------+ +-------+ 639 |PCC | | PCE | 640 |Ingress| +-------+ 641 +------| | | 642 | PCC +-------+ | 643 | Transit| | | 644 +------| | | | 645 |PCC +--------+ | | 646 |Egress | | | | 647 +--------+ | | | 648 | | | | New Path 649 |<------ PCInitiate,CC-ID=XX,PLSP-ID=1 ----------- | for LSP 650 | | | | trigger 651 |------- PCRpt,CC-ID=XX,PLSP-ID=1 ---------------->| new CCI 652 | | | | 653 | |<----- PCInitiate,CC-ID=YY1,YY2,PLSP-ID=1--| Label 654 | | | | download 655 | |----- PCRpt,CC-ID=YY1,YY2,PLSP-ID=1 ---->| 656 | | | | 657 | | |<--- PCInitiate,CC-ID=ZZ,PLSP-ID=1 - | Label 658 | | | | download 659 | | |---- PCRpt,CC-ID=ZZ,PLSP-ID=1 ----->| 660 | | | | 661 | | |<-- PCUpd, PLSP-ID=1, PST=TBD, D=1-- | PCECC 662 | | | SRP=S | LSP Update 663 | | | | 664 | | |-- PCRpt,PLSP-ID=1,PST=TBD,D=1 -->| Trigger 665 | | | (SRP=S) | Delete old 666 | | | | CCI 667 | | | | 668 |<------ PCInitiate,CC-ID=X, PLSP-ID=1 ----------- | Label 669 | | | R=1 | cleanup 670 |------- PCRpt,CC-ID=X, PLSP-ID=1 ---------------->| 671 | | | | 672 | |<----- PCInitiate,CC-ID=Y1,Y2, PLSP-ID=1 - | Label 673 | | | R=1 | cleanup 674 | |----- PCRpt,CC-ID=Y1,Y2, PLSP-ID=1 ----->| 675 | | | | 676 | | |<--- PCInitiate,CC-ID=Z, PLSP-ID=1 - | Label 677 | | | R=1 | cleanup 678 | | |---- PCRpt,CC-ID=Z, PLSP-ID=1 ----->| 679 | | | | 681 The modified PCECC LSP are considered to be 'up' by default. The 682 Ingress MAY further choose to deploy a data plane check mechanism and 683 report the status back to the PCE via PCRpt message. 685 In case where the label allocation are made by the PCC itself (see 686 Section 5.4.8), the procedure remains similar. 688 5.4.5. Re Delegation and Cleanup 690 As described in [RFC8281], a new PCE can gain control over the 691 orphaned LSP. In case of PCECC LSP, the new PCE MUST also gain 692 control over the central controllers instructions in the same way by 693 sending a PCInitiate message that includes the SRP, LSP and CCI 694 objects and carries the CC-ID and PLSP-ID identifying the 695 instruction, it wants to take control of. 697 Further, as described in [RFC8281], the State Timeout Interval timer 698 ensures that a PCE crash does not result in automatic and immediate 699 disruption for the services using PCE-initiated LSPs. Similarly the 700 central controller instructions are not removed immediately upon PCE 701 failure. Instead, they are cleaned up on the expiration of this 702 timer. This allows for network cleanup without manual intervention. 703 The PCC MUST support removal of CCI as one of the behaviors applied 704 on expiration of the State Timeout Interval timer. 706 5.4.6. Synchronization of Central Controllers Instructions 708 The purpose of Central Controllers Instructions synchronization 709 (labels in the context of this document) is to make sure that the 710 PCE's view of CCI (Labels) matches with the PCC's Label allocation. 711 This synchronization is performed as part of the LSP state 712 synchronization as described in [RFC8231] and [RFC8233]. 714 As per LSP State Synchronization [RFC8231], a PCC reports the state 715 of its LSPs to the PCE using PCRpt messages and as per [RFC8281], PCE 716 would initiate any missing LSPs and/or remove any LSPs that are not 717 wanted. The same PCEP messages and procedure is also used for the 718 Central Controllers Instructions synchronization. The PCRpt message 719 includes the CCI and the LSP object to report the label forwarding 720 instructions. The PCE would further remove any unwanted instructions 721 or initiate any missing instructions. 723 5.4.7. PCECC LSP State Report 725 As mentioned before, an Ingress PCC MAY choose to apply any OAM 726 mechanism to check the status of LSP in the Data plane and MAY 727 further send its status in PCRpt message to the PCE. 729 5.4.8. PCC Based Allocations 731 The PCE can request the PCC to allocate the label using the 732 PCInitiate message. The C flag in the CCI object is set to 1 to 733 indicate that the allocation needs to be done by the PCC. The PCC 734 would allocate the Label and would report to the PCE using the PCRpt 735 message. 737 If the value of the Label is 0 and the C flag is set, it indicates 738 that the PCE is requesting the allocation to be done by the PCC. If 739 the Label is 'n' and the C flag is set in the CCI object, it 740 indicates that the PCE requests a specific value 'n' for the Label. 741 If the allocation is successful, the PCC should report via PCRpt 742 message with the CCI object. Else, it MUST send a PCErr message with 743 Error-Type = TBD ("PCECC failure") and Error Value = TBD ("Invalid 744 CCI"). If the value of the the Label in the CCI object is valid, but 745 the PCC is unable to allocate it, it MUST send a PCErr message with 746 Error-Type = TBD ("PCECC failure") and Error Value = TBD ("Unable to 747 allocate the specified CCI"). 749 If the PCC wishes to withdrawn or modify the previously assigned 750 label, it MUST send a PCRpt message without any Label or with the 751 Label containing the new value respectively in the CCI object. The 752 PCE would further trigger the removal of the central controller 753 instruction as per this document. 755 5.4.9. Binding Label 757 As per [I-D.sivabalan-pce-binding-label-sid], when a stateful PCE is 758 deployed for setting up TE paths, it may be desirable to report the 759 binding label to the stateful PCE for the purpose of enforcing end- 760 to-end TE. In case of PCECC, the binding label may be allocated by 761 the PCE itself as described in this section. This procedure is thus 762 applicable for all path setup types including PCECC. 764 A P flag in LSP object is introduced in [I-D.li-pce-sr-path-segment] 765 to indicate the allocation needs to be made by the PCE. The same 766 flag can also be used to indicate that the allocation needs to be 767 made by the PCE. A PCC would set this bit to 1 (and carry the TE- 768 PATH-BINDING TLV [I-D.sivabalan-pce-binding-label-sid] in LSP object) 769 to request for allocation of the binding label by the PCE in the 770 PCReq or PCRpt message. A PCE would also set this bit to 1 to 771 indicate that the binding label is allocated by PCE and encoded in 772 the PCRep, PCUpd or PCInitiate message (the TE-PATH-BINDING TLV is 773 present in LSP object). Further, a PCE would set this bit to 0 to 774 indicate that the allocation is done by the PCC instead. 776 The ingress PCC could request the binding label to be allocated by 777 the PCE via PCRpt message as per [RFC8231]. The delegate flag 778 (D-flag) MUST also be set for this LSP. The TE-PATH-BINDING TLV MUST 779 be included with no Binding Value. The PCECC would allocated the 780 binding label and further respond to Ingress PCC with PCUpd message 781 as per [RFC8231] and MUST include the TE-PATH-BINDING TLV in a LSP 782 object. The P flag in the LSP object would be set to 1 to indicate 783 that the allocation is made by the PCE. 785 The PCE could allocate the binding label on its own accord for a PCE- 786 Initiated (or delegated LSP). The allocated binding label needs to 787 be informed to the PCC. The PCE would use the PCInitiate message 788 [RFC8281] or PCUpd message [RFC8231] towards the PCC and MUST include 789 the TE-PATH-BINDING TLV in the LSP object. The P flag in the LSP 790 object would be set to 1 to indicate that the allocation is made by 791 the PCE. 793 The PCECC capability MUST be exchanged on the PCEP session, before 794 PCE could allocate binding label. Note that the CCI object is not 795 used for binding allocation; this is done to maintain consistency 796 with the rest of the binding label/SID procedures as per 797 [I-D.sivabalan-pce-binding-label-sid]. 799 6. PCEP messages 801 As defined in [RFC5440], a PCEP message consists of a common header 802 followed by a variable-length body made of a set of objects that can 803 be either mandatory or optional. An object is said to be mandatory 804 in a PCEP message when the object must be included for the message to 805 be considered valid. For each PCEP message type, a set of rules is 806 defined that specify the set of objects that the message can carry. 807 An implementation MUST form the PCEP messages using the object 808 ordering specified in this document. 810 LSP-IDENTIFIERS TLV MUST be included in the LSP object for PCECC LSP. 812 6.1. The PCInitiate message 814 The PCInitiate message [RFC8281] can be used to download or remove 815 the labels, the message has been extended as shown below - 816 ::= 817 818 Where: 819 is defined in [RFC5440] 821 ::= 822 [] 824 ::= 825 (| 826 | 827 ) 829 ::= 830 831 833 ::= 834 [] 836 Where: 837 and 838 are as per 839 [RFC8281]. 841 The LSP and SRP object is defined in [RFC8231]. 843 When PCInitiate message is used for central controller's instructions 844 (labels), the SRP, LSP and CCI objects MUST be present. The SRP 845 object is defined in [RFC8231] and if the SRP object is missing, the 846 receiving PCC MUST send a PCErr message with Error-type=6 (Mandatory 847 Object missing) and Error-value=10 (SRP object missing). The LSP 848 object is defined in [RFC8231] and if the LSP object is missing, the 849 receiving PCC MUST send a PCErr message with Error-type=6 (Mandatory 850 Object missing) and Error-value=8 (LSP object missing). The CCI 851 object is defined in Section 7.3 and if the CCI object is missing, 852 the receiving PCC MUST send a PCErr message with Error-type=6 853 (Mandatory Object missing) and Error-value=TBD (CCI object missing). 854 More than one CCI object MAY be included in the PCInitiate message 855 for the transit LSR. 857 To cleanup the SRP object must set the R (remove) bit. 859 At max two instances of CCI object would be included in case of 860 transit LSR to encode both in-coming and out-going label forwarding 861 instructions. Other instances MUST be ignored. 863 6.2. The PCRpt message 865 The PCRpt message can be used to report the labels that were 866 allocated by the PCE, to be used during the state synchronization 867 phase. 869 ::= 870 871 Where: 873 ::= [] 875 ::= (| 876 ) 878 ::= [] 879 880 882 ::= [] 883 884 886 ::= 887 [] 889 Where: 890 is as per [RFC8231] and the LSP and SRP object are 891 also defined in [RFC8231]. 893 When PCRpt message is used to report the central controller's 894 instructions (labels), the LSP and CCI objects MUST be present. The 895 LSP object is defined in [RFC8231] and if the LSP object is missing, 896 the receiving PCE MUST send a PCErr message with Error-type=6 897 (Mandatory Object missing) and Error-value=8 (LSP object missing). 898 The CCI object is defined in Section 7.3 and if the CCI object is 899 missing, the receiving PCC MUST send a PCErr message with Error- 900 type=6 (Mandatory Object missing) and Error-value=TBD (CCI object 901 missing). Two CCI object can be included in the PCRpt message for 902 the transit LSR. 904 7. PCEP Objects 906 The PCEP objects defined in this document are compliant with the PCEP 907 object format defined in [RFC5440]. 909 7.1. OPEN Object 911 This document defines a new optional TLVs for use in the OPEN Object. 913 7.1.1. PCECC Capability sub-TLV 915 The PCECC-CAPABILITY sub-TLV is an optional TLV for use in the OPEN 916 Object for PCECC capability advertisement in PATH-SETUP-TYPE- 917 CAPABILITY TLV. Advertisement of the PCECC capability implies 918 support of LSPs that are setup through PCECC as per PCEP extensions 919 defined in this document. 921 Its format is shown in the following figure: 923 0 1 2 3 924 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 925 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 926 | Type=TBD | Length=4 | 927 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 928 | Flags | 929 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 931 The type of the TLV is TBD and it has a fixed length of 4 octets. 933 The value comprises a single field - Flags (32 bits). 935 No flags are assigned right now. 937 Unassigned bits are considered reserved. They MUST be set to 0 on 938 transmission and MUST be ignored on receipt. 940 7.2. PATH-SETUP-TYPE TLV 942 The PATH-SETUP-TYPE TLV is defined in [RFC8408]; this document 943 defines a new PST value: 945 o PST = TBD: Path is setup via PCECC mode. 947 On a PCRpt/PCUpd/PCInitiate message, the PST=TBD in PATH-SETUP-TYPE 948 TLV in SRP object indicates that this LSP was setup via a PCECC based 949 mechanism. 951 7.3. CCI Object 953 The Central Control Instructions (CCI) Object is used by the PCE to 954 specify the forwarding instructions (Label information in the context 955 of this document) to the PCC, and MAY be carried within PCInitiate or 956 PCRpt message for label download. 958 CCI Object-Class is TBD. 960 CCI Object-Type is 1 for the MPLS Label. 962 0 1 2 3 963 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 964 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 965 | CC-ID | 966 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 967 | Reserved | Flags |C|O| 968 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 969 | Label | Reserved | 970 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 971 | | 972 // Optional TLV // 973 | | 974 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 976 The fields in the CCI object are as follows: 978 CC-ID: A PCEP-specific identifier for the CCI information. A PCE 979 creates an CC-ID for each instruction, the value is unique within 980 the scope of the PCE and is constant for the lifetime of a PCEP 981 session. The values 0 and 0xFFFFFFFF are reserved and MUST NOT be 982 used. 984 Flags: is used to carry any additional information pertaining to the 985 CCI. Currently, the following flag bit is defined: 987 * O bit(Out-label) : If the bit is set, it specifies the label is 988 the OUT label and it is mandatory to encode the next-hop 989 information (via IPV4-ADDRESS TLV or IPV6-ADDRESS TLV or 990 UNNUMBERED-IPV4-ID-ADDRESS TLV in the CCI object). If the bit 991 is not set, it specifies the label is the IN label and it is 992 optional to encode the local interface information (via 993 IPV4-ADDRESS TLV or IPV6-ADDRESS TLV or UNNUMBERED-IPV4-ID- 994 ADDRESS TLV in the CCI object). 996 * C-Bit (PCC Allocation): If the bit is set to 1, it indicates 997 that the allocation needs to be done by the PCC for this 998 central controller instruction. A PCE set this bit to request 999 the PCC to make an allocation from its label space. A PCC 1000 would set this bit to indicate that it has allocated the CC-ID 1001 and report it to the PCE. 1003 Label (20-bit): The Label information. 1005 Reserved (12 bit): Set to zero while sending, ignored on receive. 1007 7.3.1. Address TLVs 1009 This document defines the following TLVs for the CCI object to 1010 associate the next-hop information in case of an outgoing label and 1011 local interface information in case of an incoming label. 1013 IPV4-ADDRESS TLV: 1015 0 1 2 3 1016 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 1017 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1018 | Type=TBD | Length = 4 | 1019 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1020 | IPv4 address | 1021 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1023 IPV6-ADDRESS TLV: 1025 0 1 2 3 1026 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 1027 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1028 | Type=TBD | Length = 16 | 1029 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1030 | | 1031 // IPv6 address (16 bytes) // 1032 | | 1033 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1035 UNNUMBERED-IPV4-ID-ADDRESS TLV: 1037 0 1 2 3 1038 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 1039 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1040 | Type=TBD | Length = 8 | 1041 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1042 | Node-ID | 1043 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1044 | Interface ID | 1045 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1047 The address TLVs are as follows: 1049 IPV4-ADDRESS TLV: an IPv4 address. 1051 IPV6-ADDRESS TLV: an IPv6 address. 1053 UNNUMBERED-IPV4-ID-ADDRESS TLV: a pair of Node ID / Interface ID 1054 tuples. 1056 8. Security Considerations 1058 The security considerations described in [RFC8231] and [RFC8281] 1059 apply to the extensions described in this document. Additional 1060 considerations related to a malicious PCE are introduced. 1062 8.1. Malicious PCE 1064 PCE has complete control over PCC to update the labels and can cause 1065 the LSP's to behave inappropriate and cause cause major impact to the 1066 network. As a general precaution, it is RECOMMENDED that these PCEP 1067 extensions only be activated on authenticated and encrypted sessions 1068 across PCEs and PCCs belonging to the same administrative authority, 1069 using Transport Layer Security (TLS) [RFC8253], as per the 1070 recommendations and best current practices in [RFC7525]. 1072 9. Manageability Considerations 1074 9.1. Control of Function and Policy 1076 A PCE or PCC implementation SHOULD allow to configure to enable/ 1077 disable PCECC capability as a global configuration. 1079 9.2. Information and Data Models 1081 [RFC7420] describes the PCEP MIB, this MIB can be extended to get the 1082 PCECC capability status. 1084 The PCEP YANG module [I-D.ietf-pce-pcep-yang] could be extended to 1085 enable/disable PCECC capability. 1087 9.3. Liveness Detection and Monitoring 1089 Mechanisms defined in this document do not imply any new liveness 1090 detection and monitoring requirements in addition to those already 1091 listed in [RFC5440]. 1093 9.4. Verify Correct Operations 1095 Mechanisms defined in this document do not imply any new operation 1096 verification requirements in addition to those already listed in 1097 [RFC5440] and [RFC8231]. 1099 9.5. Requirements On Other Protocols 1101 PCEP extensions defined in this document do not put new requirements 1102 on other protocols. 1104 9.6. Impact On Network Operations 1106 PCEP extensions defined in this document do not put new requirements 1107 on network operations. 1109 10. IANA Considerations 1111 10.1. PCEP TLV Type Indicators 1113 IANA is requested to confirm the early allocation of the following 1114 TLV Type Indicator values within the "PCEP TLV Type Indicators" sub- 1115 registry of the PCEP Numbers registry, and to update the reference in 1116 the registry to point to this document, when it is an RFC: 1118 Value Meaning Reference 1119 TBD PCECC-CAPABILITY This document 1120 TBD IPV4-ADDRESS TLV This document 1121 TBD IPV6-ADDRESS TLV This document 1122 TBD UNNUMBERED-IPV4-ID-ADDRESS TLV This document 1124 10.2. New Path Setup Type Registry 1126 IANA is requested to allocate new PST Field in PATH- SETUP-TYPE TLV. 1127 The allocation policy for this new registry should be by IETF 1128 Consensus. The new registry should contain the following value: 1130 Value Description Reference 1131 TBD Traffic engineering path is This document 1132 setup using PCECC mode 1134 10.3. PCEP Object 1136 IANA is requested to allocate new registry for CCI PCEP object. 1138 Object-Class Value Name Reference 1139 TBD CCI Object-Type This document 1140 1 MPLS Label 1142 10.4. CCI Object Flag Field 1144 IANA is requested to create a registry to manage the Flag field of 1145 the CCI object. 1147 One bit to be defined for the CCI Object flag field in this document: 1149 Codespace of the Flag field (CCI Object) 1150 Bit Description Reference 1151 7 Specifies label This document 1152 is out label 1154 10.5. PCEP-Error Object 1156 IANA is requested to allocate new error types and error values within 1157 the "PCEP-ERROR Object Error Types and Values" sub-registry of the 1158 PCEP Numbers registry for the following errors: 1160 Error-Type Meaning 1161 ---------- ------- 1162 19 Invalid operation. 1164 Error-value = TBD : Attempted PCECC 1165 operations when 1166 PCECC capability 1167 was not advertised 1168 Error-value = TBD : Stateful PCE 1169 capability was not 1170 advertised 1171 Error-value = TBD : Unknown Label 1172 6 Mandatory Object missing. 1174 Error-value = TBD : CCI object missing 1175 TBD PCECC failure. 1177 Error-value = TBD : Label out of range. 1178 Error-value = TBD : Instruction failed. 1179 Error-value = TBD : Invalid CCI. 1180 Error-value = TBD : Unable to allocate 1181 the specified CCI. 1183 11. Acknowledgments 1185 We would like to thank Robert Tao, Changjing Yan, Tieying Huang and 1186 Avantika for their useful comments and suggestions. 1188 12. References 1190 12.1. Normative References 1192 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1193 Requirement Levels", BCP 14, RFC 2119, 1194 DOI 10.17487/RFC2119, March 1997, 1195 . 1197 [RFC5440] Vasseur, JP., Ed. and JL. Le Roux, Ed., "Path Computation 1198 Element (PCE) Communication Protocol (PCEP)", RFC 5440, 1199 DOI 10.17487/RFC5440, March 2009, 1200 . 1202 [RFC7420] Koushik, A., Stephan, E., Zhao, Q., King, D., and J. 1203 Hardwick, "Path Computation Element Communication Protocol 1204 (PCEP) Management Information Base (MIB) Module", 1205 RFC 7420, DOI 10.17487/RFC7420, December 2014, 1206 . 1208 [RFC7525] Sheffer, Y., Holz, R., and P. Saint-Andre, 1209 "Recommendations for Secure Use of Transport Layer 1210 Security (TLS) and Datagram Transport Layer Security 1211 (DTLS)", BCP 195, RFC 7525, DOI 10.17487/RFC7525, May 1212 2015, . 1214 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 1215 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 1216 May 2017, . 1218 [RFC8231] Crabbe, E., Minei, I., Medved, J., and R. Varga, "Path 1219 Computation Element Communication Protocol (PCEP) 1220 Extensions for Stateful PCE", RFC 8231, 1221 DOI 10.17487/RFC8231, September 2017, 1222 . 1224 [RFC8233] Dhody, D., Wu, Q., Manral, V., Ali, Z., and K. Kumaki, 1225 "Extensions to the Path Computation Element Communication 1226 Protocol (PCEP) to Compute Service-Aware Label Switched 1227 Paths (LSPs)", RFC 8233, DOI 10.17487/RFC8233, September 1228 2017, . 1230 [RFC8281] Crabbe, E., Minei, I., Sivabalan, S., and R. Varga, "Path 1231 Computation Element Communication Protocol (PCEP) 1232 Extensions for PCE-Initiated LSP Setup in a Stateful PCE 1233 Model", RFC 8281, DOI 10.17487/RFC8281, December 2017, 1234 . 1236 [RFC8408] Sivabalan, S., Tantsura, J., Minei, I., Varga, R., and J. 1237 Hardwick, "Conveying Path Setup Type in PCE Communication 1238 Protocol (PCEP) Messages", RFC 8408, DOI 10.17487/RFC8408, 1239 July 2018, . 1241 12.2. Informative References 1243 [RFC4655] Farrel, A., Vasseur, J., and J. Ash, "A Path Computation 1244 Element (PCE)-Based Architecture", RFC 4655, 1245 DOI 10.17487/RFC4655, August 2006, 1246 . 1248 [RFC7025] Otani, T., Ogaki, K., Caviglia, D., Zhang, F., and C. 1249 Margaria, "Requirements for GMPLS Applications of PCE", 1250 RFC 7025, DOI 10.17487/RFC7025, September 2013, 1251 . 1253 [RFC7399] Farrel, A. and D. King, "Unanswered Questions in the Path 1254 Computation Element Architecture", RFC 7399, 1255 DOI 10.17487/RFC7399, October 2014, 1256 . 1258 [RFC7491] King, D. and A. Farrel, "A PCE-Based Architecture for 1259 Application-Based Network Operations", RFC 7491, 1260 DOI 10.17487/RFC7491, March 2015, 1261 . 1263 [RFC8253] Lopez, D., Gonzalez de Dios, O., Wu, Q., and D. Dhody, 1264 "PCEPS: Usage of TLS to Provide a Secure Transport for the 1265 Path Computation Element Communication Protocol (PCEP)", 1266 RFC 8253, DOI 10.17487/RFC8253, October 2017, 1267 . 1269 [RFC8283] Farrel, A., Ed., Zhao, Q., Ed., Li, Z., and C. Zhou, "An 1270 Architecture for Use of PCE and the PCE Communication 1271 Protocol (PCEP) in a Network with Central Control", 1272 RFC 8283, DOI 10.17487/RFC8283, December 2017, 1273 . 1275 [I-D.ietf-teas-pcecc-use-cases] 1276 Zhao, Q., Li, Z., Khasanov, B., Dhody, D., Ke, Z., Fang, 1277 L., Zhou, C., Communications, T., Rachitskiy, A., and A. 1278 Gulida, "The Use Cases for Path Computation Element (PCE) 1279 as a Central Controller (PCECC).", draft-ietf-teas-pcecc- 1280 use-cases-02 (work in progress), October 2018. 1282 [I-D.ietf-pce-pcep-yang] 1283 Dhody, D., Hardwick, J., Beeram, V., and J. Tantsura, "A 1284 YANG Data Model for Path Computation Element 1285 Communications Protocol (PCEP)", draft-ietf-pce-pcep- 1286 yang-09 (work in progress), October 2018. 1288 [I-D.zhao-pce-pcep-extension-pce-controller-sr] 1289 Zhao, Q., Li, Z., Dhody, D., Karunanithi, S., Farrel, A., 1290 and C. Zhou, "PCEP Procedures and Protocol Extensions for 1291 Using PCE as a Central Controller (PCECC) of SR-LSPs", 1292 draft-zhao-pce-pcep-extension-pce-controller-sr-03 (work 1293 in progress), June 2018. 1295 [I-D.li-pce-controlled-id-space] 1296 Li, C., Chen, M., Dong, J., Li, Z., and A. Wang, "PCE 1297 Controlled ID Space", draft-li-pce-controlled-id-space-01 1298 (work in progress), December 2018. 1300 [I-D.sivabalan-pce-binding-label-sid] 1301 Sivabalan, S., Filsfils, C., Tantsura, J., Hardwick, J., 1302 Previdi, S., and D. Dhody, "Carrying Binding Label/ 1303 Segment-ID in PCE-based Networks.", draft-sivabalan-pce- 1304 binding-label-sid-05 (work in progress), October 2018. 1306 [I-D.li-pce-sr-path-segment] 1307 Li, C., Chen, M., Dhody, D., Cheng, W., Dong, J., Li, Z., 1308 and R. Gandhi, "Path Computation Element Communication 1309 Protocol (PCEP) Extension for Path Segment in Segment 1310 Routing (SR)", draft-li-pce-sr-path-segment-03 (work in 1311 progress), October 2018. 1313 Appendix A. Contributor Addresses 1315 Dhruv Dhody 1316 Huawei Technologies 1317 Divyashree Techno Park, Whitefield 1318 Bangalore, Karnataka 560066 1319 India 1321 EMail: dhruv.ietf@gmail.com 1323 Satish Karunanithi 1324 Huawei Technologies 1325 Divyashree Techno Park, Whitefield 1326 Bangalore, Karnataka 560066 1327 India 1329 EMail: satishk@huawei.com 1331 Adrian Farrel 1332 Juniper Networks, Inc 1333 UK 1335 EMail: adrian@olddog.co.uk 1337 Xuesong Geng 1338 Huawei Technologies 1339 China 1341 Email: gengxuesong@huawei.com 1343 Udayasree Palle 1344 Huawei Technologies 1345 Divyashree Techno Park, Whitefield 1346 Bangalore, Karnataka 560066 1347 India 1349 EMail: udayasreereddy@gmail.com 1351 Katherine Zhao 1352 Huawei Technologies 1353 2330 Central Expressway 1354 Santa Clara, CA 95050 1355 USA 1357 EMail: katherine.zhao@huawei.com 1359 Boris Zhang 1360 Telus Ltd. 1362 Toronto 1363 Canada 1365 EMail: boris.zhang@telus.com 1367 Alex Tokar 1368 Cisco Systems 1369 Slovak Republic 1371 EMail: atokar@cisco.com 1373 Authors' Addresses 1375 Quintin Zhao 1376 Huawei Technologies 1377 125 Nagog Technology Park 1378 Acton, MA 01719 1379 USA 1381 EMail: quintin.zhao@huawei.com 1383 Zhenbin Li 1384 Huawei Technologies 1385 Huawei Bld., No.156 Beiqing Rd. 1386 Beijing 100095 1387 China 1389 EMail: lizhenbin@huawei.com 1391 Mahendra Singh Negi 1392 Huawei Technologies 1393 Divyashree Techno Park, Whitefield 1394 Bangalore, Karnataka 560066 1395 India 1397 EMail: mahendrasingh@huawei.com 1399 Chao Zhou 1400 Cisco Systems 1402 EMail: chao.zhou@cisco.com