idnits 2.17.1 draft-ietf-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 (July 13, 2020) is 1384 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-05 == Outdated reference: A later version (-23) exists of draft-ietf-pce-pcep-yang-13 == Outdated reference: A later version (-09) exists of draft-zhao-pce-pcep-extension-pce-controller-sr-06 == Outdated reference: A later version (-16) exists of draft-li-pce-controlled-id-space-06 == Outdated reference: A later version (-16) exists of draft-ietf-pce-binding-label-sid-03 == Outdated reference: A later version (-09) exists of draft-ietf-pce-sr-path-segment-01 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 Z. Li 3 Internet-Draft S. Peng 4 Intended status: Standards Track Huawei Technologies 5 Expires: January 14, 2021 M. Negi 6 RtBrick India 7 Q. Zhao 8 Etheric Networks 9 C. Zhou 10 Cisco Systems 11 July 13, 2020 13 PCEP Procedures and Protocol Extensions for Using PCE as a Central 14 Controller (PCECC) of LSPs 15 draft-ietf-pce-pcep-extension-for-pce-controller-06 17 Abstract 19 The Path Computation Element (PCE) is a core component of Software- 20 Defined Networking (SDN) systems. It can compute optimal paths for 21 traffic across a network and can also update the paths to reflect 22 changes in the network or traffic demands. 24 PCE was developed to derive paths for MPLS Label Switched Paths 25 (LSPs), which are supplied to the head end of the LSP using the Path 26 Computation Element Communication Protocol (PCEP). But SDN has a 27 broader applicability than signaled (G)MPLS traffic-engineered (TE) 28 networks, and the PCE may be used to determine paths in a range of 29 use cases. PCEP has been proposed as a control protocol for use in 30 these environments to allow the PCE to be fully enabled as a central 31 controller. 33 A PCE-based central controller (PCECC) can simplify the processing of 34 a distributed control plane by blending it with elements of SDN and 35 without necessarily completely replacing it. Thus, the LSP can be 36 calculated/setup/initiated and the label forwarding entries can also 37 be downloaded through a centralized PCE server to each network 38 devices along the path while leveraging the existing PCE technologies 39 as much as possible. 41 This document specifies the procedures and PCEP protocol extensions 42 for using the PCE as the central controller. 44 Status of This Memo 46 This Internet-Draft is submitted in full conformance with the 47 provisions of BCP 78 and BCP 79. 49 Internet-Drafts are working documents of the Internet Engineering 50 Task Force (IETF). Note that other groups may also distribute 51 working documents as Internet-Drafts. The list of current Internet- 52 Drafts is at https://datatracker.ietf.org/drafts/current/. 54 Internet-Drafts are draft documents valid for a maximum of six months 55 and may be updated, replaced, or obsoleted by other documents at any 56 time. It is inappropriate to use Internet-Drafts as reference 57 material or to cite them other than as "work in progress." 59 This Internet-Draft will expire on January 14, 2021. 61 Copyright Notice 63 Copyright (c) 2020 IETF Trust and the persons identified as the 64 document authors. All rights reserved. 66 This document is subject to BCP 78 and the IETF Trust's Legal 67 Provisions Relating to IETF Documents 68 (https://trustee.ietf.org/license-info) in effect on the date of 69 publication of this document. Please review these documents 70 carefully, as they describe your rights and restrictions with respect 71 to this document. Code Components extracted from this document must 72 include Simplified BSD License text as described in Section 4.e of 73 the Trust Legal Provisions and are provided without warranty as 74 described in the Simplified BSD License. 76 Table of Contents 78 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 79 1.1. Requirements Language . . . . . . . . . . . . . . . . . . 5 80 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5 81 3. Basic PCECC Mode . . . . . . . . . . . . . . . . . . . . . . 5 82 4. PCEP Requirements . . . . . . . . . . . . . . . . . . . . . . 5 83 5. Procedures for Using the PCE as the Central Controller 84 (PCECC) . . . . . . . . . . . . . . . . . . . . . . . . . . . 6 85 5.1. Stateful PCE Model . . . . . . . . . . . . . . . . . . . 6 86 5.2. New LSP Functions . . . . . . . . . . . . . . . . . . . . 6 87 5.3. New PCEP Object . . . . . . . . . . . . . . . . . . . . . 7 88 5.4. PCECC Capability Advertisement . . . . . . . . . . . . . 7 89 5.5. LSP Operations . . . . . . . . . . . . . . . . . . . . . 8 90 5.5.1. Basic PCECC LSP Setup . . . . . . . . . . . . . . . . 8 91 5.5.2. Central Control Instructions . . . . . . . . . . . . 12 92 5.5.2.1. Label Download CCI . . . . . . . . . . . . . . . 12 93 5.5.2.2. Label Cleanup CCI . . . . . . . . . . . . . . . . 12 94 5.5.3. PCE Initiated PCECC LSP . . . . . . . . . . . . . . . 13 95 5.5.4. PCECC LSP Update . . . . . . . . . . . . . . . . . . 15 96 5.5.5. Re-Delegation and Cleanup . . . . . . . . . . . . . . 17 97 5.5.6. Synchronization of Central Controllers Instructions . 17 98 5.5.7. PCECC LSP State Report . . . . . . . . . . . . . . . 17 99 5.5.8. PCC Based Allocations . . . . . . . . . . . . . . . . 18 100 5.5.9. Binding Label . . . . . . . . . . . . . . . . . . . . 18 101 6. PCEP messages . . . . . . . . . . . . . . . . . . . . . . . . 19 102 6.1. The PCInitiate message . . . . . . . . . . . . . . . . . 19 103 6.2. The PCRpt message . . . . . . . . . . . . . . . . . . . . 21 104 7. PCEP Objects . . . . . . . . . . . . . . . . . . . . . . . . 21 105 7.1. OPEN Object . . . . . . . . . . . . . . . . . . . . . . . 22 106 7.1.1. PCECC Capability sub-TLV . . . . . . . . . . . . . . 22 107 7.2. PATH-SETUP-TYPE TLV . . . . . . . . . . . . . . . . . . . 22 108 7.3. CCI Object . . . . . . . . . . . . . . . . . . . . . . . 23 109 7.3.1. Address TLVs . . . . . . . . . . . . . . . . . . . . 24 110 8. Implementation Status . . . . . . . . . . . . . . . . . . . . 25 111 8.1. Huawei's Proof of Concept based on ONOS . . . . . . . . . 26 112 9. Security Considerations . . . . . . . . . . . . . . . . . . . 26 113 9.1. Malicious PCE . . . . . . . . . . . . . . . . . . . . . . 26 114 10. Manageability Considerations . . . . . . . . . . . . . . . . 27 115 10.1. Control of Function and Policy . . . . . . . . . . . . . 27 116 10.2. Information and Data Models . . . . . . . . . . . . . . 27 117 10.3. Liveness Detection and Monitoring . . . . . . . . . . . 27 118 10.4. Verify Correct Operations . . . . . . . . . . . . . . . 27 119 10.5. Requirements On Other Protocols . . . . . . . . . . . . 27 120 10.6. Impact On Network Operations . . . . . . . . . . . . . . 27 121 11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 27 122 11.1. PCEP TLV Type Indicators . . . . . . . . . . . . . . . . 27 123 11.2. PATH-SETUP-TYPE-CAPABILITY Sub-TLV Type Indicators . . . 28 124 11.3. PCECC-CAPABILITY sub-TLV's Flag field . . . . . . . . . 28 125 11.4. New Path Setup Type Registry . . . . . . . . . . . . . . 28 126 11.5. PCEP Object . . . . . . . . . . . . . . . . . . . . . . 28 127 11.6. CCI Object Flag Field . . . . . . . . . . . . . . . . . 29 128 11.7. PCEP-Error Object . . . . . . . . . . . . . . . . . . . 29 129 12. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 30 130 13. References . . . . . . . . . . . . . . . . . . . . . . . . . 30 131 13.1. Normative References . . . . . . . . . . . . . . . . . . 30 132 13.2. Informative References . . . . . . . . . . . . . . . . . 31 133 Appendix A. Contributor Addresses . . . . . . . . . . . . . . . 34 134 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 35 136 1. Introduction 138 The Path Computation Element (PCE) [RFC4655] was developed to offload 139 path computation function from routers in an MPLS traffic-engineered 140 network. Since then, the role and function of the PCE has grown to 141 cover a number of other uses (such as GMPLS [RFC7025]) and to allow 142 delegated control [RFC8231] and PCE-initiated use of network 143 resources [RFC8281]. 145 According to [RFC7399], Software-Defined Networking (SDN) refers to a 146 separation between the control elements and the forwarding components 147 so that software running in a centralized system, called a 148 controller, can act to program the devices in the network to behave 149 in specific ways. A required element in an SDN architecture is a 150 component that plans how the network resources will be used and how 151 the devices will be programmed. It is possible to view this 152 component as performing specific computations to place traffic flows 153 within the network given knowledge of the availability of network 154 resources, how other forwarding devices are programmed, and the way 155 that other flows are routed. This is the function and purpose of a 156 PCE, and the way that a PCE integrates into a wider network control 157 system (including an SDN system) is presented in [RFC7491]. 159 In early PCE implementations, where the PCE was used to derive paths 160 for MPLS Label Switched Paths (LSPs), paths were requested by network 161 elements (known as Path Computation Clients (PCCs)), and the results 162 of the path computations were supplied to network elements using the 163 Path Computation Element Communication Protocol (PCEP) [RFC5440]. 164 This protocol was later extended to allow a PCE to send unsolicited 165 requests to the network for LSP establishment [RFC8281]. 167 [RFC8283] introduces the architecture for PCE as a central controller 168 as an extension of the architecture described in [RFC4655] and 169 assumes the continued use of PCEP as the protocol used between PCE 170 and PCC. [RFC8283] further examines the motivations and 171 applicability for PCEP as a Southbound Interface (SBI), and 172 introduces the implications for the protocol. 173 [I-D.ietf-teas-pcecc-use-cases] describes the use cases for the PCECC 174 architecture. 176 A PCE-based central controller (PCECC) can simplify the processing of 177 a distributed control plane by blending it with elements of SDN and 178 without necessarily completely replacing it. Thus, the LSP can be 179 calculated/setup/initiated and the label forwarding entries can also 180 be downloaded through a centralized PCE server to each network 181 devices along the path while leveraging the existing PCE technologies 182 as much as possible. 184 This draft specify the procedures and PCEP protocol extensions for 185 using the PCE as the central controller for static LSPs, where LSPs 186 can be provisioned as explicit label instructions at each hop on the 187 end-to-end path. Each router along the path must be told what label- 188 forwarding instructions to program and what resources to reserve. 189 The PCE-based controller keeps a view of the network and determines 190 the paths of the end-to-end LSPs, and the controller uses PCEP to 191 communicate with each router along the path of the end-to-end LSP. 193 The extension for PCECC in Segment Routing (SR) is specified in a 194 separate draft [I-D.zhao-pce-pcep-extension-pce-controller-sr]. 196 1.1. Requirements Language 198 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 199 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 200 "OPTIONAL" in this document are to be interpreted as described in BCP 201 14 [RFC2119] [RFC8174] when, and only when, they appear in all 202 capitals, as shown here. 204 2. Terminology 206 Terminologies used in this document is same as described in the draft 207 [RFC8283]. 209 3. Basic PCECC Mode 211 In this mode LSPs are provisioned as explicit label instructions at 212 each hop on the end-to-end path. Each router along the path must be 213 told what label forwarding instructions to program and what resources 214 to reserve. The controller uses PCEP to communicate with each router 215 along the path of the end-to-end LSP. 217 Note that the PCE-based controller will take responsibility for 218 managing some part of the MPLS label space for each of the routers 219 that it controls, and may take wider responsibility for partitioning 220 the label space for each router and allocating different parts for 221 different uses. This is also described in section 3.1.2. of 222 [RFC8283]. For the purpose of this document, it is assumed that 223 label range to be used by a PCE is known and set on both PCEP peers. 224 A future extension could add this capability to advertise the range 225 via possible PCEP extensions as well (see 226 [I-D.li-pce-controlled-id-space]). The rest of processing is similar 227 to the existing stateful PCE mechanism. 229 This document also allow a case where the label space is maintained 230 by PCC itself, and the labels are allocated by the PCC, in this case, 231 the PCE should request the allocation from PCC as described in 232 Section 5.5.8. 234 4. PCEP Requirements 236 Following key requirements associated PCECC should be considered when 237 designing the PCECC based solution: 239 1. PCEP speaker supporting this draft needs to have the capability 240 to advertise its PCECC capability to its peers. 242 2. PCEP speaker needs a means to identify PCECC based LSP in the 243 PCEP messages. 245 3. PCEP procedures needs to allow for PCC based label allocations. 247 4. PCEP procedures needs to provide a means to update (or cleanup) 248 the label-download entry to the PCC. 250 5. PCEP procedures needs to provide a means to synchronize the 251 labels between PCE to PCC in PCEP messages. 253 5. Procedures for Using the PCE as the Central Controller (PCECC) 255 5.1. Stateful PCE Model 257 Active stateful PCE is described in [RFC8231]. PCE as a central 258 controller (PCECC) reuses existing Active stateful PCE mechanism as 259 much as possible to control the LSP. 261 5.2. New LSP Functions 263 Several new functions are required in PCEP to support PCECC. This 264 document extends the existing messages to support the new functions 265 required by PCECC: 267 (PCInitiate): a PCEP message described in [RFC8281]. PCInitiate 268 message is used to setup PCE-Initiated LSP based on PCECC 269 mechanism. It is also extended for Central Controller's 270 Instructions (CCI) (download or cleanup the Label forwarding 271 instructions in the context of this document) on all nodes along 272 the path. 274 (PCRpt): a PCEP message described in [RFC8231]. PCRpt message is 275 used to send PCECC LSP Reports. It is also extended to report the 276 set of Central Controller's Instructions (CCI) (label forwarding 277 instructions in the context of this document) received from the 278 PCE. See Section 5.5.6 for more details. 280 (PCUpd): a PCEP message described in [RFC8231]. PCUpd message is 281 used to send PCECC LSP Update. 283 The new functions defined in this document are mapped onto the PCEP 284 messages as shown in the following table. 286 +----------------------------------------+--------------------------+ 287 | Function | Message | 288 +----------------------------------------+--------------------------+ 289 | PCECC Capability advertisement | Open | 290 | Label entry Add | PCInitiate | 291 | Label entry Cleanup | PCInitiate | 292 | PCECC Initiated LSP | PCInitiate | 293 | PCECC LSP Update | PCUpd | 294 | PCECC LSP State Report | PCRpt | 295 | PCECC LSP Delegation | PCRpt | 296 | PCECC Label Report | PCRpt | 297 +----------------------------------------+--------------------------+ 299 5.3. New PCEP Object 301 This document specify a new PCEP object called CCI (see Section 7.3) 302 for the encoding of central controller's instructions. In the scope 303 of this document this is limited to Label forwarding instructions. 304 Future documents can create new CCI object-type for other types of 305 central control instructions. The CC-ID is the unique identifier for 306 the central controller's instructions in PCEP. The PCEP messages are 307 extended in this document to handle the PCECC operations. 309 5.4. PCECC Capability Advertisement 311 During PCEP Initialization Phase, PCEP Speakers (PCE or PCC) 312 advertise their support of PCECC extensions. 314 This document defines a new Path Setup Type (PST) [RFC8408] for 315 PCECC, as follows: 317 o PST = TBD1: Path is setup via PCECC mode. 319 A PCEP speaker MUST indicate its support of the function described in 320 this document by sending a PATH-SETUP-TYPE-CAPABILITY TLV in the OPEN 321 object with this new PST included in the PST list. 323 This document also defines the PCECC Capability sub-TLV 324 Section 7.1.1. PCEP speakers use this sub-TLV to exchange 325 information about their PCECC capability. If a PCEP speaker includes 326 PST=TBD1 in the PST List of the PATH-SETUP-TYPE-CAPABILITY TLV then 327 it MUST also include the PCECC Capability sub-TLV inside the PATH- 328 SETUP-TYPE-CAPABILITY TLV. If the sub-TLV is absent, then the PCEP 329 speaker MUST send a PCErr message with Error-Type 10 (Reception of an 330 invalid object) and Error-Value TBD2 (Missing PCECC Capability sub- 331 TLV) and MUST then close the PCEP session. If a PCEP speaker 332 receives a PATH-SETUP-TYPE-CAPABILITY TLV with a PCECC-CAPABILITY 333 sub-TLV, but the PST list does not contain PST=TBD1, then the PCEP 334 speaker MUST ignore the PCECC-CAPABILITY sub-TLV. 336 The presence of the PST=TBD1 and PCECC Capability sub-TLV in PCC's 337 OPEN Object indicates that the PCC is willing to function as a PCECC 338 client. The presence of the PST=TBD1 and PCECC Capability sub-TLV in 339 PCE's OPEN message indicates that the PCE is interested in function 340 as a PCECC server. 342 The PCEP protocol extensions for PCECC MUST NOT be used if one or 343 both PCEP Speakers have not included the PST=TBD1 or the PCECC 344 Capability sub-TLV in their respective OPEN message. If the PCEP 345 Speakers support the extensions of this draft but did not advertise 346 this capability attempts a PCECC operation then a PCErr message with 347 Error-Type=19(Invalid Operation) and Error-Value=TBD3 (Attempted 348 PCECC operations when PCECC capability was not advertised) will be 349 generated and the PCEP session will be terminated. 351 A PCC or a PCE MUST include both PCECC-CAPABILITY sub-TLV and 352 STATEFUL-PCE-CAPABILITY TLV ([RFC8231]) (with I flag set [RFC8281]) 353 in OPEN Object to support the extensions defined in this document. 354 If PCECC-CAPABILITY sub-TLV is advertised and STATEFUL-PCE-CAPABILITY 355 TLV is not advertised in OPEN Object, it MUST send a PCErr message 356 with Error-Type=19 (Invalid Operation) and Error-value=TBD4 (stateful 357 PCE capability was not advertised) and terminate the session. This 358 error is also triggered if PCECC-CAPABILITY sub-TLV is advertised and 359 I flag in the STATEFUL-PCE-CAPABILITY TLV is not set. 361 5.5. LSP Operations 363 The PCEP messages pertaining to PCECC MUST include PATH-SETUP-TYPE 364 TLV [RFC8408] in the SRP object to clearly identify the PCECC LSP is 365 intended. 367 5.5.1. Basic PCECC LSP Setup 369 In order to setup a LSP based on PCECC mechanism, a PCC MUST delegate 370 the LSP by sending a PCRpt message with PST set for PCECC (see 371 Section 7.2) and D (Delegate) flag (see [RFC8231]) set in the LSP 372 object. 374 LSP-IDENTIFIER TLV MUST be included for PCECC LSP, the tuple uniquely 375 identifies the LSP in the network. The LSP object is included in 376 central controller's instructions (label download) to identify the 377 PCECC LSP for this instruction. The PLSP-ID is the original 378 identifier used by the ingress PCC, so the transit LSR could have 379 multiple central controller instructions that have the same PLSP-ID. 380 The PLSP-ID in combination with the source (in LSP-IDENTIFIER TLV) 381 MUST be unique. The PLSP-ID is included for maintainability reasons 382 to ease debugging. As per [RFC8281], the LSP object could include 383 SPEAKER-ENTITY-ID TLV to identify the PCE that initiated these 384 instructions. Also the CC-ID is unique on the PCEP session as 385 described in Section 7.3. 387 When a PCE receives PCRpt message with D flags and PST Type set, it 388 calculates the path and assigns labels along the path; and set up the 389 path by sending PCInitiate message to each node along the path of the 390 LSP. The PCC generates a Path Computation State Report (PCRpt) and 391 include the central controller's instruction (CCI) and the identified 392 LSP. The CC-ID is uniquely identify the central controller's 393 instruction within a PCEP session. The PCC further responds with the 394 PCRpt messages including the CCI and LSP objects. 396 The Ingress node would receive one CCI object with O bit (out-label) 397 set. The transit node(s) would receive two CCI object with the in- 398 label CCI without O bit set and the out-label CCI with O bit set. 399 The egress node would receive one CCI object without O bit set. A 400 node can determine its role based on the setting of the O bit in the 401 CCI object(s). 403 Once the central controller's instructions (label operations) are 404 completed, the PCE MUST send the PCUpd message to the Ingress PCC. 405 This PCUpd message is as per [RFC8231] SHOULD include the path 406 information as calculated by the PCE. 408 Note that the PCECC LSPs MUST be delegated to a PCE at all times. 410 LSP deletion operation for PCECC LSP is same as defined in [RFC8231]. 411 If the PCE receives PCRpt message for LSP deletion then it does Label 412 cleanup operation as described in Section 5.5.2.2 for the 413 corresponding LSP. 415 The Basic PCECC LSP setup sequence is as shown below. 417 +-------+ +-------+ 418 |PCC | | PCE | 419 |Ingress| +-------+ 420 +------| | | 421 | PCC +-------+ | 422 | Transit| | | 423 +------| | |-- PCRpt,PLSP-ID=1, PST=TBD1, D=1--->| PCECC LSP 424 |PCC +--------+ | | 425 |Egress | | | | 426 +--------+ | | | 427 | | | | 428 |<------ PCInitiate,CC-ID=X,PLSP-ID=1 ------------ | Label 429 | | | L1,O=0 | download 430 |------- PCRpt,CC-ID=X,PLSP-ID=1 ----------------->| CCI 431 | | | | 432 | |<----- PCInitiate,PLSP-ID=1, ------------- | Labels 433 | | | CC-ID=Y1,O=0,L2 | download 434 | | | CC-ID=Y2,O=1,L1 | CCI 435 | |----- PCRpt,CC-ID=Y1,Y2,PLSP-ID=1 ------>| 436 | | | | 437 | | |<--- PCInitiate,CC-ID=Z,PLSP-ID=1 - | Label 438 | | | L2,O=1 | download 439 | | |---- PCRpt,CC-ID=Z,PLSP-ID=1 ------>| CCI 440 | | | | 441 | | |<-- PCUpd,PLSP-ID=1,PST=TBD1, D=1----| PCECC LSP 442 | | | | Update 443 | | | | 445 Figure 2: Basic PCECC LSP setup 447 The PCECC LSP are considered to be 'up' by default (on receipt of 448 PCUpd message from PCE). The Ingress MAY further choose to deploy a 449 data plane check mechanism and report the status back to the PCE via 450 PCRpt message. 452 In case where the label allocation are made by the PCC itself (see 453 Section 5.5.8), the PCE could request an allocation to be made by the 454 PCC, and where the PCC would send a PCRpt with the allocated label 455 encoded in the CC-ID object as shown below - 456 +-------+ +-------+ 457 |PCC | | PCE | 458 |Ingress| +-------+ 459 +------| | | 460 | PCC +-------+ | 461 | Transit| | | 462 +------| | |-- PCRpt,PLSP-ID=1, PST=TBD1, D=1--->| PCECC LSP 463 |PCC +--------+ | | 464 |Egress | | | | 465 +--------+ | | | 466 | | | | 467 |<------ PCInitiate,CC-ID=X,PLSP-ID=1 ------------ | Label 468 | | | C=1 | download 469 |------- PCRpt,CC-ID=X,PLSP-ID=1 ----------------->| CCI 470 | | | Label=L1 | 471 | |<----- PCInitiate,PLSP-ID=1, ------------- | Labels 472 | | | CC-ID=Y1,C=1 | download 473 | | | CC-ID=Y2,C=0,L1 | CCI 474 | |----- PCRpt,PLSP-ID=1 ------------------>| 475 | | | CC-ID=Y1, Label=L2 | 476 | | | CC-ID=Y2 | 477 | | |<--- PCInitiate,CC-ID=Z,PLSP-ID=1 - | Label 478 | | | C=0,L2 | download 479 | | |---- PCRpt,CC-ID=Z,PLSP-ID=1 ------>| CCI 480 | | | | 481 | | |<-- PCUpd,PLSP-ID=1,PST=TBD1, D=1----| PCECC LSP 482 | | | | Update 483 | | | | 485 - The O bit is set as before (and thus not included) 487 Figure 3: Basic PCECC LSP setup (PCC allocation) 489 It should be noted that in this example, the request is made to the 490 egress node with C bit set in the CCI object to indicate that the 491 label allocation needs to be done by the egress and it responds with 492 the allocated label to the PCE. The PCE would further inform the 493 transit PCC without setting the C bit in the CCI object for out-label 494 but the C-bit is set for in-label so the transit node make the label 495 allocation (for the in-label) and report to the PCE. Similarly C bit 496 is unset towards the ingress to complete all the label allocation for 497 the PCECC LSP. 499 5.5.2. Central Control Instructions 501 The new central controller's instructions (CCI) for the label 502 operations in PCEP is done via the PCInitiate message, by defining a 503 new PCEP Objects for CCI operations. Local label range of each PCC 504 is assumed to be known at both the PCC and the PCE. 506 5.5.2.1. Label Download CCI 508 In order to setup an LSP based on PCECC, the PCE sends a PCInitiate 509 message to each node along the path to download the Label instruction 510 as described in Section 5.5.1. 512 The CCI object MUST be included, along with the LSP object in the 513 PCInitiate message. The LSP-IDENTIFIER TLV MUST be included in LSP 514 object. The SPEAKER-ENTITY-ID TLV SHOULD be included in LSP object. 516 If a node (PCC) receives a PCInitiate message which includes a Label 517 to download as part of CCI, that is out of the range set aside for 518 the PCE, it MUST send a PCErr message with Error-type=TBD5 (PCECC 519 failure) and Error-value=TBD6 (Label out of range) and MUST include 520 the SRP object to specify the error is for the corresponding label 521 update via PCInitiate message. If a PCC receives a PCInitiate 522 message but failed to download the Label entry, it MUST send a PCErr 523 message with Error-type=TBD5 (PCECC failure) and Error-value=TBD7 524 (instruction failed) and MUST include the SRP object to specify the 525 error is for the corresponding label update via PCInitiate message. 527 New PCEP object for central control instructions (CCI) is defined in 528 Section 7.3. 530 5.5.2.2. Label Cleanup CCI 532 In order to delete an LSP based on PCECC, the PCE sends a central 533 controller instructions via a PCInitiate message to each node along 534 the path of the LSP to cleanup the Label forwarding instruction. 536 If the PCC receives a PCInitiate message but does not recognize the 537 label in the CCI, the PCC MUST generate a PCErr message with Error- 538 Type 19(Invalid operation) and Error-Value=TBD8, "Unknown Label" and 539 MUST include the SRP object to specify the error is for the 540 corresponding label cleanup (via PCInitiate message). 542 The R flag in the SRP object defined in [RFC8281] specifies the 543 deletion of Label Entry in the PCInitiate message. 545 +-------+ +-------+ 546 |PCC | | PCE | 547 |Ingress| +-------+ 548 +------| | | 549 | PCC +-------+ | 550 | Transit| | | 551 +------| | |-- PCRpt,PLSP-ID=1,PST=TBD1,D=1,R=1-->| PCECC LSP 552 |PCC +--------+ | | remove 553 |Egress | | | | 554 +--------+ | | | 555 | | | | 556 |<------ PCInitiate,CC-ID=X,PLSP-ID=1 ------------ | Label 557 | | | R=1 | cleanup 558 |------- PCRpt,CC-ID=X,PLSP-ID=1 ------------------>| CCI 559 | | | | 560 | |<----- PCInitiate,CC-ID=Y1,Y2,PLSP-ID=1 -- | Label 561 | | | R=1 | cleanup 562 | |----- PCRpt,CC-ID=Y1,Y2,PLSP-ID=1 ------->| CCI 563 | | | | 564 | | |<--- PCInitiate,CC-ID=Z,PLSP-ID=1 -- | Label 565 | | | R=1 | cleanup 566 | | |---- PCRpt,CC-ID=Z,PLSP-ID=1 ------->| CCI 567 | | | | 569 As per [RFC8281], following the removal of the Label forwarding 570 instruction, the PCC MUST send a PCRpt message. The SRP object in 571 the PCRpt MUST include the SRP-ID-number from the PCInitiate message 572 that triggered the removal. The R flag in the SRP object MUST be 573 set. 575 In case where the label allocation are made by the PCC itself (see 576 Section 5.5.8), the removal procedure remains the same. 578 5.5.3. PCE Initiated PCECC LSP 580 The LSP Instantiation operation is same as defined in [RFC8281]. 582 In order to setup a PCE Initiated LSP based on the PCECC mechanism, a 583 PCE sends PCInitiate message with Path Setup Type set for PCECC (see 584 Section 7.2) to the Ingress PCC. 586 The Ingress PCC MUST also set D (Delegate) flag (see [RFC8231]) and C 587 (Create) flag (see [RFC8281]) in LSP object of PCRpt message. The 588 PCC responds with first PCRpt message with the status as "GOING-UP" 589 and assigned PLSP-ID. 591 Note that the label forwarding instructions from PCECC are send after 592 the initial PCInitiate and PCRpt exchange. This is done so that the 593 PLSP-ID and other LSP identifiers can be obtained from the ingress 594 and can be included in the label forwarding instruction in the next 595 PCInitiate message. The rest of the PCECC LSP setup operations are 596 same as those described in Section 5.5.1. 598 The LSP deletion operation for PCE Initiated PCECC LSP is same as 599 defined in [RFC8281]. The PCE should further perform Label entry 600 cleanup operation as described in Section 5.5.2.2 for the 601 corresponding LSP. 603 The PCE Initiated PCECC LSP setup sequence is shown below - 605 +-------+ +-------+ 606 |PCC | | PCE | 607 |Ingress| +-------+ 608 +------| | | 609 | PCC +-------+ | 610 | Transit| | | 611 +------| | |<--PCInitiate,PLSP-ID=0,PST=TBD1,D=1--| PCECC LSP 612 |PCC +--------+ | | Initiate 613 |Egress | | |--- PCRpt,PLSP-ID=2,P=1,D=1,C=1---> | PCECC LSP 614 +--------+ | | (GOING-UP) | 615 | | | | 616 |<------ PCInitiate,CC-ID=X,PLSP-ID=2 -------------- | Label 617 | | | | download 618 |------- PCRpt,CC-ID=X,PLSP-ID=2 ------------------>| CCI 619 | | | | 620 | |<----- PCInitiate,CC-ID=Y1,Y2,PLSP-ID=2 --- | Label 621 | | | | download 622 | |----- PCRpt,CC-ID=Y1,Y2,PLSP-ID=2 ------->| CCI 623 | | | | 624 | | |<--- PCInitiate,CC-ID=Z,PLSP-ID=2 --- | Label 625 | | | | download 626 | | |---- PCRpt,CC-ID=Z,PLSP-ID=2 ------->| CCI 627 | | | | 628 | | |<-- PCUpd, PLSP-ID=2, PST=TBD1, D=1-- | PCECC LSP 629 | | | (UP) | Update 630 | | |--- PCRpt,PLSP-ID=2,P=1,D=1,C=1---> | 631 | | | (UP) | 633 Once the label operations are completed, the PCE SHOULD send the 634 PCUpd message to the Ingress PCC. The PCUpd message is as per 635 [RFC8231]. 637 In case where the label allocation are made by the PCC itself (see 638 Section 5.5.8), the procedure remains similar. 640 5.5.4. PCECC LSP Update 642 In case of a modification of PCECC LSP with a new path, a PCE sends a 643 PCUpd message to the Ingress PCC. But to follow the make-before- 644 break procedures, the PCECC first update new instructions based on 645 the updated LSP and then update to ingress to switch traffic, before 646 cleaning up the old instructions. A new CC-ID is used to identify 647 the updated instruction, the existing identifiers in the LSP object 648 identify the existing LSP. Once new instructions are downloaded, the 649 PCE further updates the new path at the ingress which triggers the 650 traffic switch on the updated path. The Ingress PCC acknowledges 651 with a PCRpt message, on receipt of PCRpt message, the PCE does 652 cleanup operation for the old LSP as described in Section 5.5.2.2. 654 The PCECC LSP Update sequence is shown below - 655 +-------+ +-------+ 656 |PCC | | PCE | 657 |Ingress| +-------+ 658 +------| | | 659 | PCC +-------+ | 660 | Transit| | | 661 +------| | | | 662 |PCC +--------+ | | 663 |Egress | | | | 664 +--------+ | | | 665 | | | | New Path 666 |<------ PCInitiate,CC-ID=XX,PLSP-ID=1 ----------- | for LSP 667 | | | | trigger 668 |------- PCRpt,CC-ID=XX,PLSP-ID=1 ---------------->| new CCI 669 | | | | 670 | |<----- PCInitiate,CC-ID=YY1,YY2,PLSP-ID=1--| Label 671 | | | | download 672 | |----- PCRpt,CC-ID=YY1,YY2,PLSP-ID=1 ---->| CCI 673 | | | | 674 | | |<--- PCInitiate,CC-ID=ZZ,PLSP-ID=1 - | Label 675 | | | | download 676 | | |---- PCRpt,CC-ID=ZZ,PLSP-ID=1 ----->| CCI 677 | | | | 678 | | |<-- PCUpd, PLSP-ID=1, PST=TBD1, D=1- | PCECC 679 | | | SRP=S | LSP Update 680 | | | | 681 | | |-- PCRpt,PLSP-ID=1,PST=TBD1,D=1 -->| Trigger 682 | | | (SRP=S) | Delete old 683 | | | | CCI 684 | | | | 685 |<------ PCInitiate,CC-ID=X, PLSP-ID=1 ----------- | Label 686 | | | R=1 | cleanup 687 |------- PCRpt,CC-ID=X, PLSP-ID=1 ---------------->| CCI 688 | | | | 689 | |<----- PCInitiate,CC-ID=Y1,Y2, PLSP-ID=1 - | Label 690 | | | R=1 | cleanup 691 | |----- PCRpt,CC-ID=Y1,Y2, PLSP-ID=1 ----->| CCI 692 | | | | 693 | | |<--- PCInitiate,CC-ID=Z, PLSP-ID=1 - | Label 694 | | | R=1 | cleanup 695 | | |---- PCRpt,CC-ID=Z, PLSP-ID=1 ----->| CCI 696 | | | | 698 The modified PCECC LSP are considered to be 'up' by default. The 699 Ingress MAY further choose to deploy a data plane check mechanism and 700 report the status back to the PCE via PCRpt message. 702 In case where the label allocation are made by the PCC itself (see 703 Section 5.5.8), the procedure remains similar. 705 5.5.5. Re-Delegation and Cleanup 707 As described in [RFC8281], a new PCE can gain control over the 708 orphaned LSP. In case of PCECC LSP, the new PCE MUST also gain 709 control over the central controllers instructions in the same way by 710 sending a PCInitiate message that includes the SRP, LSP and CCI 711 objects and carries the CC-ID and PLSP-ID identifying the 712 instruction, it wants to take control of. 714 Further, as described in [RFC8281], the State Timeout Interval timer 715 ensures that a PCE crash does not result in automatic and immediate 716 disruption for the services using PCE-initiated LSPs. Similarly the 717 central controller instructions are not removed immediately upon PCE 718 failure. Instead, they are cleaned up on the expiration of this 719 timer. This allows for network cleanup without manual intervention. 720 The PCC MUST support removal of CCI as one of the behaviors applied 721 on expiration of the State Timeout Interval timer. 723 5.5.6. Synchronization of Central Controllers Instructions 725 The purpose of Central Controllers Instructions synchronization 726 (labels in the context of this document) is to make sure that the 727 PCE's view of CCI (Labels) matches with the PCC's Label allocation. 728 This synchronization is performed as part of the LSP state 729 synchronization as described in [RFC8231] and [RFC8233]. 731 As per LSP State Synchronization [RFC8231], a PCC reports the state 732 of its LSPs to the PCE using PCRpt messages and as per [RFC8281], PCE 733 would initiate any missing LSPs and/or remove any LSPs that are not 734 wanted. The same PCEP messages and procedure is also used for the 735 Central Controllers Instructions synchronization. The PCRpt message 736 includes the CCI and the LSP object to report the label forwarding 737 instructions. The PCE would further remove any unwanted instructions 738 or initiate any missing instructions. 740 5.5.7. PCECC LSP State Report 742 As mentioned before, an Ingress PCC MAY choose to apply any OAM 743 mechanism to check the status of LSP in the Data plane and MAY 744 further send its status in PCRpt message to the PCE. 746 5.5.8. PCC Based Allocations 748 The PCE can request the PCC to allocate the label using the 749 PCInitiate message. The C flag in the CCI object is set to 1 to 750 indicate that the allocation needs to be done by the PCC. The PCC 751 would allocate the Label and would report to the PCE using the PCRpt 752 message. 754 If the value of the Label is 0 and the C flag is set, it indicates 755 that the PCE is requesting the allocation to be done by the PCC. If 756 the Label is 'n' and the C flag is set in the CCI object, it 757 indicates that the PCE requests a specific value 'n' for the Label. 758 If the allocation is successful, the PCC should report via PCRpt 759 message with the CCI object. Else, it MUST send a PCErr message with 760 Error-Type = TBD5 ("PCECC failure") and Error Value = TBD9 ("Invalid 761 CCI"). If the value of the the Label in the CCI object is valid, but 762 the PCC is unable to allocate it, it MUST send a PCErr message with 763 Error-Type = TBD5 ("PCECC failure") and Error Value = TBD10 ("Unable 764 to allocate the specified CCI"). 766 If the PCC wishes to withdraw or modify the previously assigned 767 label, it MUST send a PCRpt message without any Label or with the 768 Label containing the new value respectively in the CCI object. The 769 PCE would further trigger the removal of the central controller 770 instruction as per this document. 772 5.5.9. Binding Label 774 As per [I-D.ietf-pce-binding-label-sid], when a stateful PCE is 775 deployed for setting up TE paths, it may be desirable to report the 776 binding label to the stateful PCE for the purpose of enforcing end- 777 to-end TE. In case of PCECC, the binding label may be allocated by 778 the PCE itself as described in this section. This procedure is thus 779 applicable for all path setup types including PCECC. 781 A P flag in LSP object is introduced in 782 [I-D.ietf-pce-sr-path-segment] to indicate the allocation needs to be 783 made by the PCE. This flag is used to indicate that the allocation 784 needs to be made by the PCE. A PCC would set this bit to 1 (and 785 carry the TE-PATH-BINDING TLV [I-D.ietf-pce-binding-label-sid] in LSP 786 object) to request for allocation of the binding label by the PCE in 787 the PCReq or PCRpt message. A PCE would also set this bit to 1 to 788 indicate that the binding label is allocated by PCE and encoded in 789 the PCRep, PCUpd or PCInitiate message (the TE-PATH-BINDING TLV is 790 present in LSP object). Further, a PCE would set this bit to 0 to 791 indicate that the allocation is done by the PCC instead. 793 The ingress PCC could request the binding label to be allocated by 794 the PCE via PCRpt message as per [RFC8231]. The delegate flag 795 (D-flag) MUST also be set for this LSP. The TE-PATH-BINDING TLV MUST 796 be included with no Binding Value. The PCECC would allocate the 797 binding label and further respond to Ingress PCC with PCUpd message 798 as per [RFC8231] and MUST include the TE-PATH-BINDING TLV in a LSP 799 object. The P flag in the LSP object would be set to 1 to indicate 800 that the allocation is made by the PCE. 802 The PCE could allocate the binding label on its own accord for a PCE- 803 Initiated (or delegated LSP). The allocated binding label needs to 804 be informed to the PCC. The PCE would use the PCInitiate message 805 [RFC8281] or PCUpd message [RFC8231] towards the PCC and MUST include 806 the TE-PATH-BINDING TLV in the LSP object. The P flag in the LSP 807 object would be set to 1 to indicate that the allocation is made by 808 the PCE. 810 The PCECC capability MUST be exchanged on the PCEP session, before 811 PCE could allocate binding label. Note that the CCI object is not 812 used for binding allocation; this is done to maintain consistency 813 with the rest of the binding label/SID procedures as per 814 [I-D.ietf-pce-binding-label-sid]. 816 6. PCEP messages 818 As defined in [RFC5440], a PCEP message consists of a common header 819 followed by a variable-length body made of a set of objects that can 820 be either mandatory or optional. An object is said to be mandatory 821 in a PCEP message when the object must be included for the message to 822 be considered valid. For each PCEP message type, a set of rules is 823 defined that specify the set of objects that the message can carry. 824 An implementation MUST form the PCEP messages using the object 825 ordering specified in this document. 827 LSP-IDENTIFIERS TLV MUST be included in the LSP object for PCECC LSP. 829 6.1. The PCInitiate message 831 The PCInitiate message [RFC8281] can be used to download or remove 832 the labels, the message has been extended as shown below - 833 ::= 834 835 Where: 836 is defined in [RFC5440] 838 ::= 839 [] 841 ::= 842 (| 843 | 844 ) 846 ::= 847 848 850 ::= 851 [] 853 Where: 854 and 855 are as per 856 [RFC8281]. 858 The LSP and SRP object is defined in [RFC8231]. 860 When PCInitiate message is used for central controller's instructions 861 (labels), the SRP, LSP and CCI objects MUST be present. The SRP 862 object is defined in [RFC8231] and if the SRP object is missing, the 863 receiving PCC MUST send a PCErr message with Error-type=6 (Mandatory 864 Object missing) and Error-value=10 (SRP object missing). The LSP 865 object is defined in [RFC8231] and if the LSP object is missing, the 866 receiving PCC MUST send a PCErr message with Error-type=6 (Mandatory 867 Object missing) and Error-value=8 (LSP object missing). The CCI 868 object is defined in Section 7.3 and if the CCI object is missing, 869 the receiving PCC MUST send a PCErr message with Error-type=6 870 (Mandatory Object missing) and Error-value=TBD11 (CCI object 871 missing). More than one CCI object MAY be included in the PCInitiate 872 message for the transit LSR. 874 To cleanup the SRP object must set the R (remove) bit and include the 875 LSP and the CCI object. 877 At max two instances of CCI object would be included in case of 878 transit LSR to encode both in-coming and out-going label forwarding 879 instructions. Other instances MUST be ignored. 881 6.2. The PCRpt message 883 The PCRpt message can be used to report the labels that were 884 allocated by the PCE, to be used during the state synchronization 885 phase. 887 ::= 888 889 Where: 891 ::= [] 893 ::= (| 894 ) 896 ::= [] 897 898 900 ::= [] 901 902 904 ::= 905 [] 907 Where: 908 is as per [RFC8231] and the LSP and SRP object are 909 also defined in [RFC8231]. 911 When PCRpt message is used to report the central controller's 912 instructions (labels), the LSP and CCI objects MUST be present. The 913 LSP object is defined in [RFC8231] and if the LSP object is missing, 914 the receiving PCE MUST send a PCErr message with Error-type=6 915 (Mandatory Object missing) and Error-value=8 (LSP object missing). 916 The CCI object is defined in Section 7.3 and if the CCI object is 917 missing, the receiving PCC MUST send a PCErr message with Error- 918 type=6 (Mandatory Object missing) and Error-value=TBD11 (CCI object 919 missing). Two CCI object can be included in the PCRpt message for 920 the transit LSR. 922 7. PCEP Objects 924 The PCEP objects defined in this document are compliant with the PCEP 925 object format defined in [RFC5440]. 927 7.1. OPEN Object 929 This document defines a new optional TLVs for use in the OPEN Object. 931 7.1.1. PCECC Capability sub-TLV 933 The PCECC-CAPABILITY sub-TLV is an optional TLV for use in the OPEN 934 Object for PCECC capability advertisement in PATH-SETUP-TYPE- 935 CAPABILITY TLV. Advertisement of the PCECC capability implies 936 support of LSPs that are setup through PCECC as per PCEP extensions 937 defined in this document. 939 Its format is shown in the following figure: 941 0 1 2 3 942 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 943 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 944 | Type=TBD12 | Length=4 | 945 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 946 | Flags | 947 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 949 The type of the TLV is TBD12 and it has a fixed length of 4 octets. 951 The value comprises a single field - Flags (32 bits). 953 No flags are assigned right now. 955 Unassigned bits MUST be set to 0 on transmission and MUST be ignored 956 on receipt. 958 7.2. PATH-SETUP-TYPE TLV 960 The PATH-SETUP-TYPE TLV is defined in [RFC8408]; this document 961 defines a new PST value: 963 o PST = TBD1: Path is setup via PCECC mode. 965 On a PCRpt/PCUpd/PCInitiate message, the PST=TBD1 in PATH-SETUP-TYPE 966 TLV in SRP object indicates that this LSP was setup via a PCECC based 967 mechanism. 969 7.3. CCI Object 971 The Central Control Instructions (CCI) Object is used by the PCE to 972 specify the forwarding instructions (Label information in the context 973 of this document) to the PCC, and MAY be carried within PCInitiate or 974 PCRpt message for label download. 976 CCI Object-Class is TBD13. 978 CCI Object-Type is 1 for the MPLS Label. 980 0 1 2 3 981 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 982 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 983 | CC-ID | 984 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 985 | Reserved | Flags |C|O| 986 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 987 | Label | Reserved | 988 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 989 | | 990 // Optional TLV // 991 | | 992 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 994 The fields in the CCI object are as follows: 996 CC-ID: A PCEP-specific identifier for the CCI information. A PCE 997 creates an CC-ID for each instruction, the value is unique within 998 the scope of the PCE and is constant for the lifetime of a PCEP 999 session. The values 0 and 0xFFFFFFFF are reserved and MUST NOT be 1000 used. 1002 Flags: is used to carry any additional information pertaining to the 1003 CCI. Currently, the following flag bit is defined: 1005 * O bit(Out-label) : If the bit is set, it specifies the label is 1006 the OUT label and it is mandatory to encode the next-hop 1007 information (via IPV4-ADDRESS TLV or IPV6-ADDRESS TLV or 1008 UNNUMBERED-IPV4-ID-ADDRESS TLV in the CCI object). If the bit 1009 is not set, it specifies the label is the IN label and it is 1010 optional to encode the local interface information (via 1011 IPV4-ADDRESS TLV or IPV6-ADDRESS TLV or UNNUMBERED-IPV4-ID- 1012 ADDRESS TLV in the CCI object). 1014 * C-Bit (PCC Allocation): If the bit is set to 1, it indicates 1015 that the allocation needs to be done by the PCC for this 1016 central controller instruction. A PCE set this bit to request 1017 the PCC to make an allocation from its label space. A PCC 1018 would set this bit to indicate that it has allocated the CC-ID 1019 and report it to the PCE. 1021 * All unassigned bits MUST be set to zero at transmission and 1022 ignored at receipt. 1024 Label (20-bit): The Label information. 1026 Reserved (12 bit): Set to zero while sending, ignored on receive. 1028 7.3.1. Address TLVs 1030 This document defines the following TLVs for the CCI object to 1031 associate the next-hop information in case of an outgoing label and 1032 local interface information in case of an incoming label. 1034 IPV4-ADDRESS TLV: 1036 0 1 2 3 1037 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 1038 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1039 | Type=TBD14 | Length = 4 | 1040 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1041 | IPv4 address | 1042 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1044 IPV6-ADDRESS TLV: 1046 0 1 2 3 1047 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 1048 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1049 | Type=TBD15 | Length = 16 | 1050 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1051 | | 1052 // IPv6 address (16 bytes) // 1053 | | 1054 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1056 UNNUMBERED-IPV4-ID-ADDRESS TLV: 1058 0 1 2 3 1059 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 1060 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1061 | Type=TBD16 | Length = 8 | 1062 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1063 | Node-ID | 1064 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1065 | Interface ID | 1066 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1068 LINKLOCAL-IPV6-ID-ADDRESS TLV: 1070 0 1 2 3 1071 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 1072 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1073 | Type=TBD17 | Length = 40 | 1074 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1075 // Local IPv6 address (16 octets) // 1076 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1077 | Local Interface ID | 1078 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1079 // Remote IPv6 address (16 octets) // 1080 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1081 | Remote Interface ID | 1082 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1084 The address TLVs are as follows: 1086 IPV4-ADDRESS TLV: an IPv4 address. 1088 IPV6-ADDRESS TLV: an IPv6 address. 1090 UNNUMBERED-IPV4-ID-ADDRESS TLV: a Node ID / Interface ID tuple. 1092 LINKLOCAL-IPV6-ID-ADDRESS TLV: a pair of (global IPv6 address, 1093 interface ID) tuples. 1095 8. Implementation Status 1097 [Note to the RFC Editor - remove this section before publication, as 1098 well as remove the reference to RFC 7942.] 1100 This section records the status of known implementations of the 1101 protocol defined by this specification at the time of posting of this 1102 Internet-Draft, and is based on a proposal described in [RFC7942]. 1103 The description of implementations in this section is intended to 1104 assist the IETF in its decision processes in progressing drafts to 1105 RFCs. Please note that the listing of any individual implementation 1106 here does not imply endorsement by the IETF. Furthermore, no effort 1107 has been spent to verify the information presented here that was 1108 supplied by IETF contributors. This is not intended as, and must not 1109 be construed to be, a catalog of available implementations or their 1110 features. Readers are advised to note that other implementations may 1111 exist. 1113 According to [RFC7942], "this will allow reviewers and working groups 1114 to assign due consideration to documents that have the benefit of 1115 running code, which may serve as evidence of valuable experimentation 1116 and feedback that have made the implemented protocols more mature. 1117 It is up to the individual working groups to use this information as 1118 they see fit". 1120 8.1. Huawei's Proof of Concept based on ONOS 1122 The PCE function was developed in the ONOS open source platform. 1123 This extension was implemented on a private version as a proof of 1124 concept for PCECC. 1126 o Organization: Huawei 1128 o Implementation: Huawei's PoC based on ONOS 1130 o Description: PCEP as a southbound plugin was added to ONOS. To 1131 support PCECC, an earlier version of this I-D was implemented. 1132 Refer https://wiki.onosproject.org/display/ONOS/PCEP+Protocol 1134 o Maturity Level: Prototype 1136 o Coverage: Partial 1138 o Contact: satishk@huawei.com 1140 9. Security Considerations 1142 The security considerations described in [RFC8231] and [RFC8281] 1143 apply to the extensions described in this document. Additional 1144 considerations related to a malicious PCE are introduced. 1146 9.1. Malicious PCE 1148 PCE has complete control over PCC to update the labels and can cause 1149 the LSP's to behave inappropriate and cause major impact to the 1150 network. As a general precaution, it is RECOMMENDED that these PCEP 1151 extensions only be activated on authenticated and encrypted sessions 1152 across PCEs and PCCs belonging to the same administrative authority, 1153 using Transport Layer Security (TLS) [RFC8253], as per the 1154 recommendations and best current practices in [RFC7525]. 1156 10. Manageability Considerations 1158 10.1. Control of Function and Policy 1160 A PCE or PCC implementation SHOULD allow to configure to enable/ 1161 disable PCECC capability as a global configuration. 1163 10.2. Information and Data Models 1165 [RFC7420] describes the PCEP MIB, this MIB can be extended to get the 1166 PCECC capability status. 1168 The PCEP YANG module [I-D.ietf-pce-pcep-yang] could be extended to 1169 enable/disable PCECC capability. 1171 10.3. Liveness Detection and Monitoring 1173 Mechanisms defined in this document do not imply any new liveness 1174 detection and monitoring requirements in addition to those already 1175 listed in [RFC5440]. 1177 10.4. Verify Correct Operations 1179 Mechanisms defined in this document do not imply any new operation 1180 verification requirements in addition to those already listed in 1181 [RFC5440] and [RFC8231]. 1183 10.5. Requirements On Other Protocols 1185 PCEP extensions defined in this document do not put new requirements 1186 on other protocols. 1188 10.6. Impact On Network Operations 1190 PCEP extensions defined in this document do not put new requirements 1191 on network operations. 1193 11. IANA Considerations 1195 11.1. PCEP TLV Type Indicators 1197 IANA is requested to allocate the following TLV Type Indicator values 1198 within the "PCEP TLV Type Indicators" sub- registry of the PCEP 1199 Numbers registry: 1201 Value Meaning Reference 1202 TBD14 IPV4-ADDRESS TLV This document 1203 TBD15 IPV6-ADDRESS TLV This document 1204 TBD16 UNNUMBERED-IPV4-ID-ADDRESS TLV This document 1205 TBD17 LINKLOCAL-IPV6-ID-ADDRESS TLV This document 1207 11.2. PATH-SETUP-TYPE-CAPABILITY Sub-TLV Type Indicators 1209 [RFC8408] requested creation of "PATH-SETUP- TYPE-CAPABILITY Sub-TLV 1210 Type Indicators" sub-registry. Further IANA is requested to allocate 1211 the following code-point: 1213 Value Meaning Reference 1214 TBD12 PCECC-CAPABILITY This document 1216 11.3. PCECC-CAPABILITY sub-TLV's Flag field 1218 This documents defines the PCECC-CAPABILITY sub-TLV and requests that 1219 IANA to creates a new sub-registry to manage the value of the PCECC- 1220 CAPABILITY sub-TLV's Flag field. New values are to be assigned by 1221 Standards Action [RFC8126]. Each bit should be tracked with the 1222 following qualities: 1224 o Bit number (counting from bit 0 as the most significant bit) 1226 o Capability description 1228 o Defining RFC 1230 Currently there are no allocations in this registry. 1232 11.4. New Path Setup Type Registry 1234 [RFC8408] created a sub-registry within the "Path Computation Element 1235 Protocol (PCEP) Numbers" registry called "PCEP Path Setup Types". 1236 IANA is requested to allocate a new code point within this registry, 1237 as follows: 1239 Value Description Reference 1240 TBD1 Traffic engineering path is This document 1241 setup using PCECC mode 1243 11.5. PCEP Object 1245 IANA is requested to allocate new code-point in the "PCEP Objects" 1246 sub-registry for the CCI object as follows: 1248 Object-Class Value Name Reference 1249 TBD13 CCI Object-Type This document 1250 0 Reserved 1251 1 MPlS Label 1253 11.6. CCI Object Flag Field 1255 IANA is requested to create a new sub-registry to manage the Flag 1256 field of the CCI object called "CCI Object Flag Field". New values 1257 are to be assigned by Standards Action [RFC8126]. Each bit should be 1258 tracked with the following qualities: 1260 o Bit number (counting from bit 0 as the most significant bit) 1262 o Capability description 1264 o Defining RFC 1266 Two bits to be defined for the CCI Object flag field in this document 1267 as follows: 1269 Bit Description Reference 1270 0-13 Unassigned This document 1271 14 C Bit - PCC allocation This document 1272 15 O Bit - Specifies label This document 1273 is out-label 1275 11.7. PCEP-Error Object 1277 IANA is requested to allocate new error types and error values within 1278 the "PCEP-ERROR Object Error Types and Values" sub-registry of the 1279 PCEP Numbers registry for the following errors: 1281 Error-Type Meaning 1282 ---------- ------- 1283 10 Reception of an invalid object. 1285 Error-value = TBD2 : Missing PCECC 1286 Capability sub-TLV 1287 19 Invalid operation. 1289 Error-value = TBD3 : Attempted PCECC 1290 operations when 1291 PCECC capability 1292 was not advertised 1294 Error-value = TBD4 : Stateful PCE 1295 capability was not 1296 advertised 1297 Error-value = TBD8 : Unknown Label 1298 6 Mandatory Object missing. 1300 Error-value = TBD11 : CCI object missing 1301 TBD5 PCECC failure. 1303 Error-value = TBD6 : Label out of range. 1304 Error-value = TBD7 : Instruction failed. 1305 Error-value = TBD9 : Invalid CCI. 1306 Error-value = TBD10 : Unable to allocate 1307 the specified CCI. 1309 12. Acknowledgments 1311 We would like to thank Robert Tao, Changjing Yan, Tieying Huang and 1312 Avantika for their useful comments and suggestions. 1314 13. References 1316 13.1. Normative References 1318 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1319 Requirement Levels", BCP 14, RFC 2119, 1320 DOI 10.17487/RFC2119, March 1997, 1321 . 1323 [RFC5440] Vasseur, JP., Ed. and JL. Le Roux, Ed., "Path Computation 1324 Element (PCE) Communication Protocol (PCEP)", RFC 5440, 1325 DOI 10.17487/RFC5440, March 2009, 1326 . 1328 [RFC7420] Koushik, A., Stephan, E., Zhao, Q., King, D., and J. 1329 Hardwick, "Path Computation Element Communication Protocol 1330 (PCEP) Management Information Base (MIB) Module", 1331 RFC 7420, DOI 10.17487/RFC7420, December 2014, 1332 . 1334 [RFC7525] Sheffer, Y., Holz, R., and P. Saint-Andre, 1335 "Recommendations for Secure Use of Transport Layer 1336 Security (TLS) and Datagram Transport Layer Security 1337 (DTLS)", BCP 195, RFC 7525, DOI 10.17487/RFC7525, May 1338 2015, . 1340 [RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for 1341 Writing an IANA Considerations Section in RFCs", BCP 26, 1342 RFC 8126, DOI 10.17487/RFC8126, June 2017, 1343 . 1345 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 1346 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 1347 May 2017, . 1349 [RFC8231] Crabbe, E., Minei, I., Medved, J., and R. Varga, "Path 1350 Computation Element Communication Protocol (PCEP) 1351 Extensions for Stateful PCE", RFC 8231, 1352 DOI 10.17487/RFC8231, September 2017, 1353 . 1355 [RFC8233] Dhody, D., Wu, Q., Manral, V., Ali, Z., and K. Kumaki, 1356 "Extensions to the Path Computation Element Communication 1357 Protocol (PCEP) to Compute Service-Aware Label Switched 1358 Paths (LSPs)", RFC 8233, DOI 10.17487/RFC8233, September 1359 2017, . 1361 [RFC8281] Crabbe, E., Minei, I., Sivabalan, S., and R. Varga, "Path 1362 Computation Element Communication Protocol (PCEP) 1363 Extensions for PCE-Initiated LSP Setup in a Stateful PCE 1364 Model", RFC 8281, DOI 10.17487/RFC8281, December 2017, 1365 . 1367 [RFC8408] Sivabalan, S., Tantsura, J., Minei, I., Varga, R., and J. 1368 Hardwick, "Conveying Path Setup Type in PCE Communication 1369 Protocol (PCEP) Messages", RFC 8408, DOI 10.17487/RFC8408, 1370 July 2018, . 1372 13.2. Informative References 1374 [RFC4655] Farrel, A., Vasseur, J., and J. Ash, "A Path Computation 1375 Element (PCE)-Based Architecture", RFC 4655, 1376 DOI 10.17487/RFC4655, August 2006, 1377 . 1379 [RFC7025] Otani, T., Ogaki, K., Caviglia, D., Zhang, F., and C. 1380 Margaria, "Requirements for GMPLS Applications of PCE", 1381 RFC 7025, DOI 10.17487/RFC7025, September 2013, 1382 . 1384 [RFC7399] Farrel, A. and D. King, "Unanswered Questions in the Path 1385 Computation Element Architecture", RFC 7399, 1386 DOI 10.17487/RFC7399, October 2014, 1387 . 1389 [RFC7491] King, D. and A. Farrel, "A PCE-Based Architecture for 1390 Application-Based Network Operations", RFC 7491, 1391 DOI 10.17487/RFC7491, March 2015, 1392 . 1394 [RFC7942] Sheffer, Y. and A. Farrel, "Improving Awareness of Running 1395 Code: The Implementation Status Section", BCP 205, 1396 RFC 7942, DOI 10.17487/RFC7942, July 2016, 1397 . 1399 [RFC8253] Lopez, D., Gonzalez de Dios, O., Wu, Q., and D. Dhody, 1400 "PCEPS: Usage of TLS to Provide a Secure Transport for the 1401 Path Computation Element Communication Protocol (PCEP)", 1402 RFC 8253, DOI 10.17487/RFC8253, October 2017, 1403 . 1405 [RFC8283] Farrel, A., Ed., Zhao, Q., Ed., Li, Z., and C. Zhou, "An 1406 Architecture for Use of PCE and the PCE Communication 1407 Protocol (PCEP) in a Network with Central Control", 1408 RFC 8283, DOI 10.17487/RFC8283, December 2017, 1409 . 1411 [I-D.ietf-teas-pcecc-use-cases] 1412 Zhao, Q., Li, Z., Khasanov, B., Dhody, D., Ke, Z., Fang, 1413 L., Zhou, C., Communications, T., Rachitskiy, A., and A. 1414 Gulida, "The Use Cases for Path Computation Element (PCE) 1415 as a Central Controller (PCECC).", draft-ietf-teas-pcecc- 1416 use-cases-05 (work in progress), March 2020. 1418 [I-D.ietf-pce-pcep-yang] 1419 Dhody, D., Hardwick, J., Beeram, V., and J. Tantsura, "A 1420 YANG Data Model for Path Computation Element 1421 Communications Protocol (PCEP)", draft-ietf-pce-pcep- 1422 yang-13 (work in progress), October 2019. 1424 [I-D.zhao-pce-pcep-extension-pce-controller-sr] 1425 Zhao, Q., Li, Z., Negi, M., Peng, S., and C. Zhou, "PCEP 1426 Procedures and Protocol Extensions for Using PCE as a 1427 Central Controller (PCECC) of SR-LSPs", draft-zhao-pce- 1428 pcep-extension-pce-controller-sr-06 (work in progress), 1429 March 2020. 1431 [I-D.li-pce-controlled-id-space] 1432 Li, C., Chen, M., Wang, A., Cheng, W., and C. Zhou, "PCE 1433 Controlled ID Space", draft-li-pce-controlled-id-space-06 1434 (work in progress), July 2020. 1436 [I-D.ietf-pce-binding-label-sid] 1437 Filsfils, C., Sivabalan, S., Tantsura, J., Hardwick, J., 1438 Previdi, S., and C. Li, "Carrying Binding Label/Segment-ID 1439 in PCE-based Networks.", draft-ietf-pce-binding-label- 1440 sid-03 (work in progress), June 2020. 1442 [I-D.ietf-pce-sr-path-segment] 1443 Li, C., Chen, M., Cheng, W., Gandhi, R., and Q. Xiong, 1444 "Path Computation Element Communication Protocol (PCEP) 1445 Extension for Path Segment in Segment Routing (SR)", 1446 draft-ietf-pce-sr-path-segment-01 (work in progress), May 1447 2020. 1449 Appendix A. Contributor Addresses 1451 Dhruv Dhody 1452 Huawei Technologies 1453 Divyashree Techno Park, Whitefield 1454 Bangalore, Karnataka 560066 1455 India 1457 EMail: dhruv.ietf@gmail.com 1459 Satish Karunanithi 1460 Huawei Technologies 1461 Divyashree Techno Park, Whitefield 1462 Bangalore, Karnataka 560066 1463 India 1465 EMail: satishk@huawei.com 1467 Adrian Farrel 1468 Juniper Networks, Inc 1469 UK 1471 EMail: adrian@olddog.co.uk 1473 Xuesong Geng 1474 Huawei Technologies 1475 China 1477 Email: gengxuesong@huawei.com 1479 Udayasree Palle 1481 EMail: udayasreereddy@gmail.com 1483 Katherine Zhao 1484 Futurewei Technologies 1486 EMail: katherine.zhao@futurewei.com 1488 Boris Zhang 1489 Telus Ltd. 1490 Toronto 1491 Canada 1493 EMail: boris.zhang@telus.com 1495 Alex Tokar 1496 Cisco Systems 1497 Slovak Republic 1499 EMail: atokar@cisco.com 1501 Authors' Addresses 1503 Zhenbin Li 1504 Huawei Technologies 1505 Huawei Bld., No.156 Beiqing Rd. 1506 Beijing 100095 1507 China 1509 EMail: lizhenbin@huawei.com 1511 Shuping Peng 1512 Huawei Technologies 1513 Huawei Bld., No.156 Beiqing Rd. 1514 Beijing 100095 1515 China 1517 EMail: pengshuping@huawei.com 1519 Mahendra Singh Negi 1520 RtBrick India 1521 N-17L, Floor-1, 18th Cross Rd, HSR Layout Sector-3 1522 Bangalore, Karnataka 560102 1523 India 1525 EMail: mahend.ietf@gmail.com 1527 Quintin Zhao 1528 Etheric Networks 1529 1009 S CLAREMONT ST 1530 SAN MATEO, CA 94402 1531 USA 1533 EMail: qzhao@ethericnetworks.com 1535 Chao Zhou 1536 Cisco Systems 1538 EMail: chao.zhou@cisco.com