idnits 2.17.1 draft-ietf-pce-pcep-extension-for-pce-controller-03.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 (November 3, 2019) is 1635 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-04 == 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-05 == Outdated reference: A later version (-16) exists of draft-li-pce-controlled-id-space-03 Summary: 1 error (**), 0 flaws (~~), 5 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: May 6, 2020 Huawei Technologies 6 C. Zhou 7 Cisco Systems 8 November 3, 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-03 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 May 6, 2020. 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 CCI . . . . . . . . . . . . . . . 12 89 5.4.2.2. Label Cleanup CCI . . . . . . . . . . . . . . . . 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. Implementation Status . . . . . . . . . . . . . . . . . . . . 25 107 8.1. Huawei's Proof of Concept based on ONOS . . . . . . . . . 26 108 9. Security Considerations . . . . . . . . . . . . . . . . . . . 26 109 9.1. Malicious PCE . . . . . . . . . . . . . . . . . . . . . . 26 110 10. Manageability Considerations . . . . . . . . . . . . . . . . 27 111 10.1. Control of Function and Policy . . . . . . . . . . . . . 27 112 10.2. Information and Data Models . . . . . . . . . . . . . . 27 113 10.3. Liveness Detection and Monitoring . . . . . . . . . . . 27 114 10.4. Verify Correct Operations . . . . . . . . . . . . . . . 27 115 10.5. Requirements On Other Protocols . . . . . . . . . . . . 27 116 10.6. Impact On Network Operations . . . . . . . . . . . . . . 27 117 11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 27 118 11.1. PCEP TLV Type Indicators . . . . . . . . . . . . . . . . 27 119 11.2. PATH-SETUP-TYPE-CAPABILITY Sub-TLV Type Indicators . . . 28 120 11.3. New Path Setup Type Registry . . . . . . . . . . . . . . 28 121 11.4. PCEP Object . . . . . . . . . . . . . . . . . . . . . . 28 122 11.5. CCI Object Flag Field . . . . . . . . . . . . . . . . . 28 123 11.6. PCEP-Error Object . . . . . . . . . . . . . . . . . . . 29 124 12. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 29 125 13. References . . . . . . . . . . . . . . . . . . . . . . . . . 30 126 13.1. Normative References . . . . . . . . . . . . . . . . . . 30 127 13.2. Informative References . . . . . . . . . . . . . . . . . 31 128 Appendix A. Contributor Addresses . . . . . . . . . . . . . . . 34 129 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 35 131 1. Introduction 133 The Path Computation Element (PCE) [RFC4655] was developed to offload 134 path computation function from routers in an MPLS traffic-engineered 135 network. Since then, the role and function of the PCE has grown to 136 cover a number of other uses (such as GMPLS [RFC7025]) and to allow 137 delegated control [RFC8231] and PCE-initiated use of network 138 resources [RFC8281]. 140 According to [RFC7399], Software-Defined Networking (SDN) refers to a 141 separation between the control elements and the forwarding components 142 so that software running in a centralized system, called a 143 controller, can act to program the devices in the network to behave 144 in specific ways. A required element in an SDN architecture is a 145 component that plans how the network resources will be used and how 146 the devices will be programmed. It is possible to view this 147 component as performing specific computations to place traffic flows 148 within the network given knowledge of the availability of network 149 resources, how other forwarding devices are programmed, and the way 150 that other flows are routed. This is the function and purpose of a 151 PCE, and the way that a PCE integrates into a wider network control 152 system (including an SDN system) is presented in [RFC7491]. 154 In early PCE implementations, where the PCE was used to derive paths 155 for MPLS Label Switched Paths (LSPs), paths were requested by network 156 elements (known as Path Computation Clients (PCCs)), and the results 157 of the path computations were supplied to network elements using the 158 Path Computation Element Communication Protocol (PCEP) [RFC5440]. 159 This protocol was later extended to allow a PCE to send unsolicited 160 requests to the network for LSP establishment [RFC8281]. 162 [RFC8283] introduces the architecture for PCE as a central controller 163 as an extension of the architecture described in [RFC4655] and 164 assumes the continued use of PCEP as the protocol used between PCE 165 and PCC. [RFC8283] further examines the motivations and 166 applicability for PCEP as a Southbound Interface (SBI), and 167 introduces the implications for the protocol. 168 [I-D.ietf-teas-pcecc-use-cases] describes the use cases for the PCECC 169 architecture. 171 A PCE-based central controller (PCECC) can simplify the processing of 172 a distributed control plane by blending it with elements of SDN and 173 without necessarily completely replacing it. Thus, the LSP can be 174 calculated/setup/initiated and the label forwarding entries can also 175 be downloaded through a centralized PCE server to each network 176 devices along the path while leveraging the existing PCE technologies 177 as much as possible. 179 This draft specify the procedures and PCEP protocol extensions for 180 using the PCE as the central controller for static LSPs, where LSPs 181 can be provisioned as explicit label instructions at each hop on the 182 end-to-end path. Each router along the path must be told what label- 183 forwarding instructions to program and what resources to reserve. 184 The PCE-based controller keeps a view of the network and determines 185 the paths of the end-to-end LSPs, and the controller uses PCEP to 186 communicate with each router along the path of the end-to-end LSP. 188 The extension for PCECC in Segment Routing (SR) is specified in a 189 separate draft [I-D.zhao-pce-pcep-extension-pce-controller-sr]. 191 1.1. Requirements Language 193 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 194 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 195 "OPTIONAL" in this document are to be interpreted as described in BCP 196 14 [RFC2119] [RFC8174] when, and only when, they appear in all 197 capitals, as shown here. 199 2. Terminology 201 Terminologies used in this document is same as described in the draft 202 [RFC8283]. 204 3. Basic PCECC Mode 206 In this mode LSPs are provisioned as explicit label instructions at 207 each hop on the end-to-end path. Each router along the path must be 208 told what label forwarding instructions to program and what resources 209 to reserve. The controller uses PCEP to communicate with each router 210 along the path of the end-to-end LSP. 212 Note that the PCE-based controller will take responsibility for 213 managing some part of the MPLS label space for each of the routers 214 that it controls, and may taker wider responsibility for partitioning 215 the label space for each router and allocating different parts for 216 different uses. This is also described in section 3.1.2. of 217 [RFC8283]. For the purpose of this document, it is assumed that 218 label range to be used by a PCE is known and set on both PCEP peers. 219 A future extension could add this capability to advertise the range 220 via possible PCEP extensions as well (see 221 [I-D.li-pce-controlled-id-space]). The rest of processing is similar 222 to the existing stateful PCE mechanism. 224 This document also allow a case where the label space is maintained 225 by PCC itself, and the labels are allocated by the PCC, in this case, 226 the PCE should request the allocation from PCC as described in 227 Section 5.4.8. 229 4. PCEP Requirements 231 Following key requirements associated PCECC should be considered when 232 designing the PCECC based solution: 234 1. PCEP speaker supporting this draft needs to have the capability 235 to advertise its PCECC capability to its peers. 237 2. PCEP speaker needs a means to identify PCECC based LSP in the 238 PCEP messages. 240 3. PCEP procedures needs to allow for PCC based label allocations. 242 4. PCEP procedures needs to provide a means to update (or cleanup) 243 the label- download entry to the PCC. 245 5. PCEP procedures needs to provide a means to synchronize the 246 labels between PCE to PCC in PCEP messages. 248 5. Procedures for Using the PCE as the Central Controller (PCECC) 250 5.1. Stateful PCE Model 252 Active stateful PCE is described in [RFC8231]. PCE as a central 253 controller (PCECC) reuses existing Active stateful PCE mechanism as 254 much as possible to control the LSP. 256 5.2. New LSP Functions 258 This document defines the following new PCEP messages and extends the 259 existing messages to support PCECC: 261 (PCInitiate): a PCEP message described in [RFC8281]. PCInitiate 262 message is used to setup PCE-Initiated LSP based on PCECC 263 mechanism. It is also extended for Central Controller's 264 Instructions (CCI) (download or cleanup the Label forwarding 265 instructions in the context of this document) on all nodes along 266 the path. 268 (PCRpt): a PCEP message described in [RFC8231]. PCRpt message is 269 used to send PCECC LSP Reports. It is also extended to report the 270 set of Central Controller's Instructions (CCI) (label forwarding 271 instructions in the context of this document) received from the 272 PCE. See Section 5.4.6 for more details. 274 (PCUpd): a PCEP message described in [RFC8231]. PCUpd message is 275 used to send PCECC LSP Update. 277 The new LSP functions defined in this document are mapped onto the 278 messages as shown in the following table. 280 +----------------------------------------+--------------------------+ 281 | Function | Message | 282 +----------------------------------------+--------------------------+ 283 | PCECC Capability advertisement | Open | 284 | Label entry Add | PCInitiate | 285 | Label entry Cleanup | PCInitiate | 286 | PCECC Initiated LSP | PCInitiate | 287 | PCECC LSP Update | PCUpd | 288 | PCECC LSP State Report | PCRpt | 289 | PCECC LSP Delegation | PCRpt | 290 | PCECC Label Report | PCRpt | 291 +----------------------------------------+--------------------------+ 293 This document specify a new PCEP object called CCI (see Section 7.3) 294 for the encoding of central controller's instructions. In the scope 295 of this document this is limited to Label forwarding instructions. 296 Future documents can create new CCI object-type for other types of 297 central control instructions. The CC-ID is the unique identifier for 298 the central controller's instructions in PCEP. The PCEP messages are 299 extended in this document to handle the PCECC operations. 301 5.3. PCECC Capability Advertisement 303 During PCEP Initialization Phase, PCEP Speakers (PCE or PCC) 304 advertise their support of PCECC extensions. 306 This document defines a new Path Setup Type (PST) [RFC8408] for 307 PCECC, as follows: 309 o PST = TBD1: Path is setup via PCECC mode. 311 A PCEP speaker MUST indicate its support of the function described in 312 this document by sending a PATH-SETUP-TYPE-CAPABILITY TLV in the OPEN 313 object with this new PST included in the PST list. 315 This document also defines the PCECC Capability sub-TLV 316 Section 7.1.1. PCEP speakers use this sub-TLV to exchange 317 information about their PCECC capability. If a PCEP speaker includes 318 PST=TBD1 in the PST List of the PATH-SETUP-TYPE-CAPABILITY TLV then 319 it MUST also include the PCECC Capability sub-TLV inside the PATH- 320 SETUP-TYPE-CAPABILITY TLV. If the sub-TLV is absent, then the PCEP 321 speaker MUST send a PCErr message with Error-Type 10 (Reception of an 322 invalid object) and Error-Value TBD2 (Missing PCECC Capability sub- 323 TLV) and MUST then close the PCEP session. If a PCEP speaker 324 receives a PATH-SETUP-TYPE-CAPABILITY TLV with a SR-PCE-CAPABILITY 325 sub-TLV, but the PST list does not contain PST=1, then the PCEP 326 speaker MUST ignore the SR-PCE-CAPABILITY sub- TLV. 328 The presence of the PST and PCECC Capability sub-TLV in PCC's OPEN 329 Object indicates that the PCC is willing to function as a PCECC 330 client. The presence of the PST and PCECC Capability sub-TLV in 331 PCE's OPEN message indicates that the PCE is interested in function 332 as a PCECC server. 334 The PCEP protocol extensions for PCECC MUST NOT be used if one or 335 both PCEP Speakers have not included the PST or the PCECC Capability 336 sub-TLV in their respective OPEN message. If the PCEP Speakers 337 support the extensions of this draft but did not advertise this 338 capability then a PCErr message with Error-Type=19(Invalid Operation) 339 and Error-Value=TBD3 (Attempted PCECC operations when PCECC 340 capability was not advertised) will be generated and the PCEP session 341 will be terminated. 343 A PCC or a PCE MUST include both PCECC-CAPABILITY sub-TLV and 344 STATEFUL-PCE-CAPABILITY TLV ([RFC8231]) (with I flag set [RFC8281]) 345 in OPEN Object to support the extensions defined in this document. 346 If PCECC-CAPABILITY sub-TLV is advertised and STATEFUL-PCE-CAPABILITY 347 TLV is not advertised in OPEN Object, it MUST send a PCErr message 348 with Error-Type=19 (Invalid Operation) and Error-value=TBD4 (stateful 349 PCE capability was not advertised) and terminate the session. This 350 error is also triggered if PCECC-CAPABILITY sub-TLV is advertised and 351 I flag is not set. 353 5.4. LSP Operations 355 The PCEP messages pertaining to PCECC MUST include PATH-SETUP-TYPE 356 TLV [RFC8408] in the SRP object to clearly identify the PCECC LSP is 357 intended. 359 5.4.1. Basic PCECC LSP Setup 361 In order to setup a LSP based on PCECC mechanism, a PCC MUST delegate 362 the LSP by sending a PCRpt message with PST set for PCECC (see 363 Section 7.2) and D (Delegate) flag (see [RFC8231]) set in the LSP 364 object. 366 LSP-IDENTIFIER TLV MUST be included for PCECC LSP, the tuple uniquely 367 identifies the LSP in the network. The LSP object is included in 368 central controller's instructions (label download) to identify the 369 PCECC LSP for this instruction. The PLSP-ID is the original 370 identifier used by the ingress PCC, so the transit LSR could have 371 multiple central controller instructions that have the same PLSP-ID. 372 The PLSP-ID in combination with the source (in LSP-IDENTIFIER TLV) 373 MUST be unique. The PLSP-ID is included for maintainability reasons 374 to ease debugging. As per [RFC8281], the LSP object could include 375 SPEAKER-ENTITY-ID TLV to identify the PCE that initiated these 376 instructions. Also the CC-ID is unique on the PCEP session as 377 described in Section 7.3. 379 When a PCE receives PCRpt message with D flags and PST Type set, it 380 calculates the path and assigns labels along the path; and set up the 381 path by sending PCInitiate message to each node along the path of the 382 LSP. The PCC generates a Path Computation State Report (PCRpt) and 383 include the central controller's instruction (CCI) and the identified 384 LSP. The CC-ID is uniquely identify the central controller's 385 instruction within a PCEP session. The PCC further responds with the 386 PCRpt messages including the CCI and LSP objects. 388 The Ingress node would receive one CCI object with O bit (out-label) 389 set. The transit node(s) would receive two CCI object with the in- 390 label CCI without O bit set and the out-label CCI with O bit set. 391 The egress node would receive one CCI object without O bit set. A 392 node can determine its role based on the setting of the O bit in the 393 CCI object(s). 395 Once the central controller's instructions (label operations) are 396 completed, the PCE MUST send the PCUpd message to the Ingress PCC. 397 This PCUpd message is as per [RFC8231] SHOULD include the path 398 information as calculated by the PCE. 400 Note that the PCECC LSPs MUST be delegated to a PCE at all times. 402 LSP deletion operation for PCECC LSP is same as defined in [RFC8231]. 403 If the PCE receives PCRpt message for LSP deletion then it does Label 404 cleanup operation as described in Section 5.4.2.2 for the 405 corresponding LSP. 407 The Basic PCECC LSP setup sequence is as shown below. 409 +-------+ +-------+ 410 |PCC | | PCE | 411 |Ingress| +-------+ 412 +------| | | 413 | PCC +-------+ | 414 | Transit| | | 415 +------| | |-- PCRpt,PLSP-ID=1, PST=TBD1, D=1--->| PCECC LSP 416 |PCC +--------+ | | 417 |Egress | | | | 418 +--------+ | | | 419 | | | | 420 |<------ PCInitiate,CC-ID=X,PLSP-ID=1 ------------ | Label 421 | | | L1,O=0 | download 422 |------- PCRpt,CC-ID=X,PLSP-ID=1 ----------------->| CCI 423 | | | | 424 | |<----- PCInitiate,PLSP-ID=1, ------------- | Labels 425 | | | CC-ID=Y1,O=0,L2 | download 426 | | | CC-ID=Y2,O=1,L1 | CCI 427 | |----- PCRpt,CC-ID=Y1,Y2,PLSP-ID=1 ------>| 428 | | | | 429 | | |<--- PCInitiate,CC-ID=Z,PLSP-ID=1 - | Label 430 | | | L2,O=1 | download 431 | | |---- PCRpt,CC-ID=Z,PLSP-ID=1 ------>| CCI 432 | | | | 433 | | |<-- PCUpd,PLSP-ID=1,PST=TBD1, D=1----| PCECC LSP 434 | | | | Update 435 | | | | 437 Figure 2: Basic PCECC LSP setup 439 The PCECC LSP are considered to be 'up' by default (on receipt of 440 PCUpd message from PCE). The Ingress MAY further choose to deploy a 441 data plane check mechanism and report the status back to the PCE via 442 PCRpt message. 444 In case where the label allocation are made by the PCC itself (see 445 Section 5.4.8), the PCE could request an allocation to be made by the 446 PCC, and where the PCC would send a PCRpt with the allocated label 447 encoded in the CC-ID object as shown below - 448 +-------+ +-------+ 449 |PCC | | PCE | 450 |Ingress| +-------+ 451 +------| | | 452 | PCC +-------+ | 453 | Transit| | | 454 +------| | |-- PCRpt,PLSP-ID=1, PST=TBD1, D=1--->| PCECC LSP 455 |PCC +--------+ | | 456 |Egress | | | | 457 +--------+ | | | 458 | | | | 459 |<------ PCInitiate,CC-ID=X,PLSP-ID=1 ------------ | Label 460 | | | C=1 | download 461 |------- PCRpt,CC-ID=X,PLSP-ID=1 ----------------->| CCI 462 | | | Label=L1 | 463 | |<----- PCInitiate,PLSP-ID=1, ------------- | Labels 464 | | | CC-ID=Y1,C=1 | download 465 | | | CC-ID=Y2,C=0,L1 | CCI 466 | |----- PCRpt,PLSP-ID=1 ------------------>| 467 | | | CC-ID=Y1, Label=L2 | 468 | | | CC-ID=Y2 | 469 | | |<--- PCInitiate,CC-ID=Z,PLSP-ID=1 - | Label 470 | | | C=0,L2 | download 471 | | |---- PCRpt,CC-ID=Z,PLSP-ID=1 ------>| CCI 472 | | | | 473 | | |<-- PCUpd,PLSP-ID=1,PST=TBD1, D=1----| PCECC LSP 474 | | | | Update 475 | | | | 477 - The O bit is set as before (and thus not included) 479 Figure 3: Basic PCECC LSP setup (PCC allocation) 481 It should be noted that in this example, the request is made to the 482 egress node with C bit set in the CCI object to indicate that the 483 label allocation needs to be done by the egress and it responds with 484 the allocated label to the PCE. The PCE would further inform the 485 transit PCC without setting the C bit in the CCI object for out-label 486 but the C-bit is unset for in-label so the transit node make the 487 label allocation (for the in-label) and report to the PCE. Similarly 488 C bit is unset towards the ingress to complete all the label 489 allocation for the PCECC LSP. 491 5.4.2. Central Control Instructions 493 The new central controller's instructions (CCI) for the label 494 operations in PCEP is done via the PCInitiate message, by defining a 495 new PCEP Objects for CCI operations. Local label range of each PCC 496 is assumed to be known at both the PCC and the PCE. 498 5.4.2.1. Label Download CCI 500 In order to setup an LSP based on PCECC, the PCE sends a PCInitiate 501 message to each node along the path to download the Label instruction 502 as described in Section 5.4.1. 504 The CCI object MUST be included, along with the LSP object in the 505 PCInitiate message. The LSP-IDENTIFIER TLV MUST be included in LSP 506 object. The SPEAKER-ENTITY-ID TLV SHOULD be included in LSP object. 508 If a node (PCC) receives a PCInitiate message which includes a Label 509 to download as part of CCI, that is out of the range set aside for 510 the PCE, it MUST send a PCErr message with Error-type=TBD5 (PCECC 511 failure) and Error-value=TBD6 (Label out of range) and MUST include 512 the SRP object to specify the error is for the corresponding label 513 update via PCInitiate message. If a PCC receives a PCInitiate 514 message but failed to download the Label entry, it MUST send a PCErr 515 message with Error-type=TBD5 (PCECC failure) and Error-value=TBD7 516 (instruction failed) and MUST include the SRP object to specify the 517 error is for the corresponding label update via PCInitiate message. 519 New PCEP object for central control instructions (CCI) is defined in 520 Section 7.3. 522 5.4.2.2. Label Cleanup CCI 524 In order to delete an LSP based on PCECC, the PCE sends a central 525 controller instructions via a PCInitiate message to each node along 526 the path of the LSP to cleanup the Label forwarding instruction. 528 If the PCC receives a PCInitiate message but does not recognize the 529 label in the CCI, the PCC MUST generate a PCErr message with Error- 530 Type 19(Invalid operation) and Error-Value=TBD8, "Unknown Label" and 531 MUST include the SRP object to specify the error is for the 532 corresponding label cleanup (via PCInitiate message). 534 The R flag in the SRP object defined in [RFC8281] specifies the 535 deletion of Label Entry in the PCInitiate message. 537 +-------+ +-------+ 538 |PCC | | PCE | 539 |Ingress| +-------+ 540 +------| | | 541 | PCC +-------+ | 542 | Transit| | | 543 +------| | |-- PCRpt,PLSP-ID=1,PST=TBD1,D=1,R=1-->| PCECC LSP 544 |PCC +--------+ | | remove 545 |Egress | | | | 546 +--------+ | | | 547 | | | | 548 |<------ PCInitiate,CC-ID=X,PLSP-ID=1 ------------ | Label 549 | | | R=1 | cleanup 550 |------- PCRpt,CC-ID=X,PLSP-ID=1 ------------------>| CCI 551 | | | | 552 | |<----- PCInitiate,CC-ID=Y1,Y2,PLSP-ID=1 -- | Label 553 | | | R=1 | cleanup 554 | |----- PCRpt,CC-ID=Y1,Y2,PLSP-ID=1 ------->| CCI 555 | | | | 556 | | |<--- PCInitiate,CC-ID=Z,PLSP-ID=1 -- | Label 557 | | | R=1 | cleanup 558 | | |---- PCRpt,CC-ID=Z,PLSP-ID=1 ------->| CCI 559 | | | | 561 As per [RFC8281], following the removal of the Label forwarding 562 instruction, the PCC MUST send a PCRpt message. The SRP object in 563 the PCRpt MUST include the SRP-ID-number from the PCInitiate message 564 that triggered the removal. The R flag in the SRP object MUST be 565 set. 567 In case where the label allocation are made by the PCC itself (see 568 Section 5.4.8), the removal procedure remains the same. 570 5.4.3. PCE Initiated PCECC LSP 572 The LSP Instantiation operation is same as defined in [RFC8281]. 574 In order to setup a PCE Initiated LSP based on the PCECC mechanism, a 575 PCE sends PCInitiate message with Path Setup Type set for PCECC (see 576 Section 7.2) to the Ingress PCC. 578 The Ingress PCC MUST also set D (Delegate) flag (see [RFC8231]) and C 579 (Create) flag (see [RFC8281]) in LSP object of PCRpt message. The 580 PCC responds with first PCRpt message with the status as "GOING-UP" 581 and assigned PLSP-ID. 583 Note that the label forwarding instructions from PCECC are send after 584 the initial PCInitiate and PCRpt exchange. This is done so that the 585 PLSP-ID and other LSP identifiers can be obtained from the ingress 586 and can be included in the label forwarding instruction in the next 587 PCInitiate message. The rest of the PCECC LSP setup operations are 588 same as those described in Section 5.4.1. 590 The LSP deletion operation for PCE Initiated PCECC LSP is same as 591 defined in [RFC8281]. The PCE should further perform Label entry 592 cleanup operation as described in Section 5.4.2.2 for the 593 corresponding LSP. 595 The PCE Initiated PCECC LSP setup sequence is shown below - 597 +-------+ +-------+ 598 |PCC | | PCE | 599 |Ingress| +-------+ 600 +------| | | 601 | PCC +-------+ | 602 | Transit| | | 603 +------| | |<--PCInitiate,PLSP-ID=0,PST=TBD1,D=1--| PCECC LSP 604 |PCC +--------+ | | Initiate 605 |Egress | | |--- PCRpt,PLSP-ID=2,P=1,D=1,C=1---> | PCECC LSP 606 +--------+ | | (GOING-UP) | 607 | | | | 608 |<------ PCInitiate,CC-ID=X,PLSP-ID=2 -------------- | Label 609 | | | | download 610 |------- PCRpt,CC-ID=X,PLSP-ID=2 ------------------>| CCI 611 | | | | 612 | |<----- PCInitiate,CC-ID=Y1,Y2,PLSP-ID=2 --- | Label 613 | | | | download 614 | |----- PCRpt,CC-ID=Y1,Y2,PLSP-ID=2 ------->| CCI 615 | | | | 616 | | |<--- PCInitiate,CC-ID=Z,PLSP-ID=2 --- | Label 617 | | | | download 618 | | |---- PCRpt,CC-ID=Z,PLSP-ID=2 ------->| CCI 619 | | | | 620 | | |<-- PCUpd, PLSP-ID=2, PST=TBD1, D=1-- | PCECC LSP 621 | | | (UP) | Update 622 | | |--- PCRpt,PLSP-ID=2,P=1,D=1,C=1---> | 623 | | | (UP) | 625 Once the label operations are completed, the PCE SHOULD send the 626 PCUpd message to the Ingress PCC. The PCUpd message is as per 627 [RFC8231]. 629 In case where the label allocation are made by the PCC itself (see 630 Section 5.4.8), the procedure remains similar. 632 5.4.4. PCECC LSP Update 634 In case of a modification of PCECC LSP with a new path, a PCE sends a 635 PCUpd message to the Ingress PCC. But to follow the make-before- 636 break procedures, the PCECC first update new instructions based on 637 the updated LSP and then update to ingress to switch traffic, before 638 cleaning up the old instructions. A new CC-ID is used to identify 639 the updated instruction, the existing identifiers in the LSP object 640 identify the existing LSP. Once new instructions are downloaded, the 641 PCE further updates the new path at the ingress which triggers the 642 traffic switch on the updated path. The Ingress PCC acknowledges 643 with a PCRpt message, on receipt of PCRpt message, the PCE does 644 cleanup operation for the old LSP as described in Section 5.4.2.2. 646 The PCECC LSP Update sequence is shown below - 647 +-------+ +-------+ 648 |PCC | | PCE | 649 |Ingress| +-------+ 650 +------| | | 651 | PCC +-------+ | 652 | Transit| | | 653 +------| | | | 654 |PCC +--------+ | | 655 |Egress | | | | 656 +--------+ | | | 657 | | | | New Path 658 |<------ PCInitiate,CC-ID=XX,PLSP-ID=1 ----------- | for LSP 659 | | | | trigger 660 |------- PCRpt,CC-ID=XX,PLSP-ID=1 ---------------->| new CCI 661 | | | | 662 | |<----- PCInitiate,CC-ID=YY1,YY2,PLSP-ID=1--| Label 663 | | | | download 664 | |----- PCRpt,CC-ID=YY1,YY2,PLSP-ID=1 ---->| CCI 665 | | | | 666 | | |<--- PCInitiate,CC-ID=ZZ,PLSP-ID=1 - | Label 667 | | | | download 668 | | |---- PCRpt,CC-ID=ZZ,PLSP-ID=1 ----->| CCI 669 | | | | 670 | | |<-- PCUpd, PLSP-ID=1, PST=TBD1, D=1- | PCECC 671 | | | SRP=S | LSP Update 672 | | | | 673 | | |-- PCRpt,PLSP-ID=1,PST=TBD1,D=1 -->| Trigger 674 | | | (SRP=S) | Delete old 675 | | | | CCI 676 | | | | 677 |<------ PCInitiate,CC-ID=X, PLSP-ID=1 ----------- | Label 678 | | | R=1 | cleanup 679 |------- PCRpt,CC-ID=X, PLSP-ID=1 ---------------->| CCI 680 | | | | 681 | |<----- PCInitiate,CC-ID=Y1,Y2, PLSP-ID=1 - | Label 682 | | | R=1 | cleanup 683 | |----- PCRpt,CC-ID=Y1,Y2, PLSP-ID=1 ----->| CCI 684 | | | | 685 | | |<--- PCInitiate,CC-ID=Z, PLSP-ID=1 - | Label 686 | | | R=1 | cleanup 687 | | |---- PCRpt,CC-ID=Z, PLSP-ID=1 ----->| CCI 688 | | | | 690 The modified PCECC LSP are considered to be 'up' by default. The 691 Ingress MAY further choose to deploy a data plane check mechanism and 692 report the status back to the PCE via PCRpt message. 694 In case where the label allocation are made by the PCC itself (see 695 Section 5.4.8), the procedure remains similar. 697 5.4.5. Re Delegation and Cleanup 699 As described in [RFC8281], a new PCE can gain control over the 700 orphaned LSP. In case of PCECC LSP, the new PCE MUST also gain 701 control over the central controllers instructions in the same way by 702 sending a PCInitiate message that includes the SRP, LSP and CCI 703 objects and carries the CC-ID and PLSP-ID identifying the 704 instruction, it wants to take control of. 706 Further, as described in [RFC8281], the State Timeout Interval timer 707 ensures that a PCE crash does not result in automatic and immediate 708 disruption for the services using PCE-initiated LSPs. Similarly the 709 central controller instructions are not removed immediately upon PCE 710 failure. Instead, they are cleaned up on the expiration of this 711 timer. This allows for network cleanup without manual intervention. 712 The PCC MUST support removal of CCI as one of the behaviors applied 713 on expiration of the State Timeout Interval timer. 715 5.4.6. Synchronization of Central Controllers Instructions 717 The purpose of Central Controllers Instructions synchronization 718 (labels in the context of this document) is to make sure that the 719 PCE's view of CCI (Labels) matches with the PCC's Label allocation. 720 This synchronization is performed as part of the LSP state 721 synchronization as described in [RFC8231] and [RFC8233]. 723 As per LSP State Synchronization [RFC8231], a PCC reports the state 724 of its LSPs to the PCE using PCRpt messages and as per [RFC8281], PCE 725 would initiate any missing LSPs and/or remove any LSPs that are not 726 wanted. The same PCEP messages and procedure is also used for the 727 Central Controllers Instructions synchronization. The PCRpt message 728 includes the CCI and the LSP object to report the label forwarding 729 instructions. The PCE would further remove any unwanted instructions 730 or initiate any missing instructions. 732 5.4.7. PCECC LSP State Report 734 As mentioned before, an Ingress PCC MAY choose to apply any OAM 735 mechanism to check the status of LSP in the Data plane and MAY 736 further send its status in PCRpt message to the PCE. 738 5.4.8. PCC Based Allocations 740 The PCE can request the PCC to allocate the label using the 741 PCInitiate message. The C flag in the CCI object is set to 1 to 742 indicate that the allocation needs to be done by the PCC. The PCC 743 would allocate the Label and would report to the PCE using the PCRpt 744 message. 746 If the value of the Label is 0 and the C flag is set, it indicates 747 that the PCE is requesting the allocation to be done by the PCC. If 748 the Label is 'n' and the C flag is set in the CCI object, it 749 indicates that the PCE requests a specific value 'n' for the Label. 750 If the allocation is successful, the PCC should report via PCRpt 751 message with the CCI object. Else, it MUST send a PCErr message with 752 Error-Type = TBD5 ("PCECC failure") and Error Value = TBD9 ("Invalid 753 CCI"). If the value of the the Label in the CCI object is valid, but 754 the PCC is unable to allocate it, it MUST send a PCErr message with 755 Error-Type = TBD5 ("PCECC failure") and Error Value = TBD10 ("Unable 756 to allocate the specified CCI"). 758 If the PCC wishes to withdrawn or modify the previously assigned 759 label, it MUST send a PCRpt message without any Label or with the 760 Label containing the new value respectively in the CCI object. The 761 PCE would further trigger the removal of the central controller 762 instruction as per this document. 764 5.4.9. Binding Label 766 As per [I-D.sivabalan-pce-binding-label-sid], when a stateful PCE is 767 deployed for setting up TE paths, it may be desirable to report the 768 binding label to the stateful PCE for the purpose of enforcing end- 769 to-end TE. In case of PCECC, the binding label may be allocated by 770 the PCE itself as described in this section. This procedure is thus 771 applicable for all path setup types including PCECC. 773 A P flag in LSP object is introduced in [I-D.li-pce-sr-path-segment] 774 to indicate the allocation needs to be made by the PCE. This flag is 775 used to indicate that the allocation needs to be made by the PCE. A 776 PCC would set this bit to 1 (and carry the TE-PATH-BINDING TLV 777 [I-D.sivabalan-pce-binding-label-sid] in LSP object) to request for 778 allocation of the binding label by the PCE in the PCReq or PCRpt 779 message. A PCE would also set this bit to 1 to indicate that the 780 binding label is allocated by PCE and encoded in the PCRep, PCUpd or 781 PCInitiate message (the TE-PATH-BINDING TLV is present in LSP 782 object). Further, a PCE would set this bit to 0 to indicate that the 783 allocation is done by the PCC instead. 785 The ingress PCC could request the binding label to be allocated by 786 the PCE via PCRpt message as per [RFC8231]. The delegate flag 787 (D-flag) MUST also be set for this LSP. The TE-PATH-BINDING TLV MUST 788 be included with no Binding Value. The PCECC would allocated the 789 binding label and further respond to Ingress PCC with PCUpd message 790 as per [RFC8231] and MUST include the TE-PATH-BINDING TLV in a LSP 791 object. The P flag in the LSP object would be set to 1 to indicate 792 that the allocation is made by the PCE. 794 The PCE could allocate the binding label on its own accord for a PCE- 795 Initiated (or delegated LSP). The allocated binding label needs to 796 be informed to the PCC. The PCE would use the PCInitiate message 797 [RFC8281] or PCUpd message [RFC8231] towards the PCC and MUST include 798 the TE-PATH-BINDING TLV in the LSP object. The P flag in the LSP 799 object would be set to 1 to indicate that the allocation is made by 800 the PCE. 802 The PCECC capability MUST be exchanged on the PCEP session, before 803 PCE could allocate binding label. Note that the CCI object is not 804 used for binding allocation; this is done to maintain consistency 805 with the rest of the binding label/SID procedures as per 806 [I-D.sivabalan-pce-binding-label-sid]. 808 6. PCEP messages 810 As defined in [RFC5440], a PCEP message consists of a common header 811 followed by a variable-length body made of a set of objects that can 812 be either mandatory or optional. An object is said to be mandatory 813 in a PCEP message when the object must be included for the message to 814 be considered valid. For each PCEP message type, a set of rules is 815 defined that specify the set of objects that the message can carry. 816 An implementation MUST form the PCEP messages using the object 817 ordering specified in this document. 819 LSP-IDENTIFIERS TLV MUST be included in the LSP object for PCECC LSP. 821 6.1. The PCInitiate message 823 The PCInitiate message [RFC8281] can be used to download or remove 824 the labels, the message has been extended as shown below - 825 ::= 826 827 Where: 828 is defined in [RFC5440] 830 ::= 831 [] 833 ::= 834 (| 835 | 836 ) 838 ::= 839 840 842 ::= 843 [] 845 Where: 846 and 847 are as per 848 [RFC8281]. 850 The LSP and SRP object is defined in [RFC8231]. 852 When PCInitiate message is used for central controller's instructions 853 (labels), the SRP, LSP and CCI objects MUST be present. The SRP 854 object is defined in [RFC8231] and if the SRP object is missing, the 855 receiving PCC MUST send a PCErr message with Error-type=6 (Mandatory 856 Object missing) and Error-value=10 (SRP object missing). The LSP 857 object is defined in [RFC8231] and if the LSP object is missing, the 858 receiving PCC MUST send a PCErr message with Error-type=6 (Mandatory 859 Object missing) and Error-value=8 (LSP object missing). The CCI 860 object is defined in Section 7.3 and if the CCI object is missing, 861 the receiving PCC MUST send a PCErr message with Error-type=6 862 (Mandatory Object missing) and Error-value=TBD11 (CCI object 863 missing). More than one CCI object MAY be included in the PCInitiate 864 message for the transit LSR. 866 To cleanup the SRP object must set the R (remove) bit. 868 At max two instances of CCI object would be included in case of 869 transit LSR to encode both in-coming and out-going label forwarding 870 instructions. Other instances MUST be ignored. 872 6.2. The PCRpt message 874 The PCRpt message can be used to report the labels that were 875 allocated by the PCE, to be used during the state synchronization 876 phase. 878 ::= 879 880 Where: 882 ::= [] 884 ::= (| 885 ) 887 ::= [] 888 889 891 ::= [] 892 893 895 ::= 896 [] 898 Where: 899 is as per [RFC8231] and the LSP and SRP object are 900 also defined in [RFC8231]. 902 When PCRpt message is used to report the central controller's 903 instructions (labels), the LSP and CCI objects MUST be present. The 904 LSP object is defined in [RFC8231] and if the LSP object is missing, 905 the receiving PCE MUST send a PCErr message with Error-type=6 906 (Mandatory Object missing) and Error-value=8 (LSP object missing). 907 The CCI object is defined in Section 7.3 and if the CCI object is 908 missing, the receiving PCC MUST send a PCErr message with Error- 909 type=6 (Mandatory Object missing) and Error-value=TBD11 (CCI object 910 missing). Two CCI object can be included in the PCRpt message for 911 the transit LSR. 913 7. PCEP Objects 915 The PCEP objects defined in this document are compliant with the PCEP 916 object format defined in [RFC5440]. 918 7.1. OPEN Object 920 This document defines a new optional TLVs for use in the OPEN Object. 922 7.1.1. PCECC Capability sub-TLV 924 The PCECC-CAPABILITY sub-TLV is an optional TLV for use in the OPEN 925 Object for PCECC capability advertisement in PATH-SETUP-TYPE- 926 CAPABILITY TLV. Advertisement of the PCECC capability implies 927 support of LSPs that are setup through PCECC as per PCEP extensions 928 defined in this document. 930 Its format is shown in the following figure: 932 0 1 2 3 933 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 934 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 935 | Type=TBD12 | Length=4 | 936 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 937 | Flags | 938 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 940 The type of the TLV is TBD12 and it has a fixed length of 4 octets. 942 The value comprises a single field - Flags (32 bits). 944 No flags are assigned right now. 946 Unassigned bits are considered reserved. They MUST be set to 0 on 947 transmission and MUST be ignored on receipt. 949 7.2. PATH-SETUP-TYPE TLV 951 The PATH-SETUP-TYPE TLV is defined in [RFC8408]; this document 952 defines a new PST value: 954 o PST = TBD1: Path is setup via PCECC mode. 956 On a PCRpt/PCUpd/PCInitiate message, the PST=TBD1 in PATH-SETUP-TYPE 957 TLV in SRP object indicates that this LSP was setup via a PCECC based 958 mechanism. 960 7.3. CCI Object 962 The Central Control Instructions (CCI) Object is used by the PCE to 963 specify the forwarding instructions (Label information in the context 964 of this document) to the PCC, and MAY be carried within PCInitiate or 965 PCRpt message for label download. 967 CCI Object-Class is TBD13. 969 CCI Object-Type is 1 for the MPLS Label. 971 0 1 2 3 972 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 973 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 974 | CC-ID | 975 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 976 | Reserved | Flags |C|O| 977 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 978 | Label | Reserved | 979 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 980 | | 981 // Optional TLV // 982 | | 983 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 985 The fields in the CCI object are as follows: 987 CC-ID: A PCEP-specific identifier for the CCI information. A PCE 988 creates an CC-ID for each instruction, the value is unique within 989 the scope of the PCE and is constant for the lifetime of a PCEP 990 session. The values 0 and 0xFFFFFFFF are reserved and MUST NOT be 991 used. 993 Flags: is used to carry any additional information pertaining to the 994 CCI. Currently, the following flag bit is defined: 996 * O bit(Out-label) : If the bit is set, it specifies the label is 997 the OUT label and it is mandatory to encode the next-hop 998 information (via IPV4-ADDRESS TLV or IPV6-ADDRESS TLV or 999 UNNUMBERED-IPV4-ID-ADDRESS TLV in the CCI object). If the bit 1000 is not set, it specifies the label is the IN label and it is 1001 optional to encode the local interface information (via 1002 IPV4-ADDRESS TLV or IPV6-ADDRESS TLV or UNNUMBERED-IPV4-ID- 1003 ADDRESS TLV in the CCI object). 1005 * C-Bit (PCC Allocation): If the bit is set to 1, it indicates 1006 that the allocation needs to be done by the PCC for this 1007 central controller instruction. A PCE set this bit to request 1008 the PCC to make an allocation from its label space. A PCC 1009 would set this bit to indicate that it has allocated the CC-ID 1010 and report it to the PCE. 1012 Label (20-bit): The Label information. 1014 Reserved (12 bit): Set to zero while sending, ignored on receive. 1016 7.3.1. Address TLVs 1018 This document defines the following TLVs for the CCI object to 1019 associate the next-hop information in case of an outgoing label and 1020 local interface information in case of an incoming label. 1022 IPV4-ADDRESS TLV: 1024 0 1 2 3 1025 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 1026 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1027 | Type=TBD14 | Length = 4 | 1028 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1029 | IPv4 address | 1030 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1032 IPV6-ADDRESS TLV: 1034 0 1 2 3 1035 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 1036 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1037 | Type=TBD15 | Length = 16 | 1038 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1039 | | 1040 // IPv6 address (16 bytes) // 1041 | | 1042 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1044 UNNUMBERED-IPV4-ID-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=TBD16 | Length = 8 | 1050 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1051 | Node-ID | 1052 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1053 | Interface ID | 1054 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1056 LINKLOCAL-IPV6-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=TBD17 | Length = 40 | 1062 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1063 // Local IPv6 address (16 octets) // 1064 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1065 | Local Interface ID | 1066 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1067 // Remote IPv6 address (16 octets) // 1068 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1069 | Remote Interface ID | 1070 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1072 The address TLVs are as follows: 1074 IPV4-ADDRESS TLV: an IPv4 address. 1076 IPV6-ADDRESS TLV: an IPv6 address. 1078 UNNUMBERED-IPV4-ID-ADDRESS TLV: a Node ID / Interface ID tuple. 1080 LINKLOCAL-IPV6-ID-ADDRESS TLV: a pair of (global IPv6 address, 1081 interface ID) tuples. 1083 8. Implementation Status 1085 [Note to the RFC Editor - remove this section before publication, as 1086 well as remove the reference to RFC 7942.] 1088 This section records the status of known implementations of the 1089 protocol defined by this specification at the time of posting of this 1090 Internet-Draft, and is based on a proposal described in [RFC7942]. 1091 The description of implementations in this section is intended to 1092 assist the IETF in its decision processes in progressing drafts to 1093 RFCs. Please note that the listing of any individual implementation 1094 here does not imply endorsement by the IETF. Furthermore, no effort 1095 has been spent to verify the information presented here that was 1096 supplied by IETF contributors. This is not intended as, and must not 1097 be construed to be, a catalog of available implementations or their 1098 features. Readers are advised to note that other implementations may 1099 exist. 1101 According to [RFC7942], "this will allow reviewers and working groups 1102 to assign due consideration to documents that have the benefit of 1103 running code, which may serve as evidence of valuable experimentation 1104 and feedback that have made the implemented protocols more mature. 1105 It is up to the individual working groups to use this information as 1106 they see fit". 1108 8.1. Huawei's Proof of Concept based on ONOS 1110 The PCE function was developed in the ONOS open source platform. 1111 This extension was implemented on a private version as a proof of 1112 concept for PCECC. 1114 o Organization: Huawei 1116 o Implementation: Huawei's PoC based on ONOS 1118 o Description: PCEP as a southbound plugin was added to ONOS. To 1119 support PCECC, an earlier version of this I-D was implemented. 1120 Refer https://wiki.onosproject.org/display/ONOS/PCEP+Protocol 1122 o Maturity Level: Prototype 1124 o Coverage: Partial 1126 o Contact: satishk@huawei.com 1128 9. Security Considerations 1130 The security considerations described in [RFC8231] and [RFC8281] 1131 apply to the extensions described in this document. Additional 1132 considerations related to a malicious PCE are introduced. 1134 9.1. Malicious PCE 1136 PCE has complete control over PCC to update the labels and can cause 1137 the LSP's to behave inappropriate and cause cause major impact to the 1138 network. As a general precaution, it is RECOMMENDED that these PCEP 1139 extensions only be activated on authenticated and encrypted sessions 1140 across PCEs and PCCs belonging to the same administrative authority, 1141 using Transport Layer Security (TLS) [RFC8253], as per the 1142 recommendations and best current practices in [RFC7525]. 1144 10. Manageability Considerations 1146 10.1. Control of Function and Policy 1148 A PCE or PCC implementation SHOULD allow to configure to enable/ 1149 disable PCECC capability as a global configuration. 1151 10.2. Information and Data Models 1153 [RFC7420] describes the PCEP MIB, this MIB can be extended to get the 1154 PCECC capability status. 1156 The PCEP YANG module [I-D.ietf-pce-pcep-yang] could be extended to 1157 enable/disable PCECC capability. 1159 10.3. Liveness Detection and Monitoring 1161 Mechanisms defined in this document do not imply any new liveness 1162 detection and monitoring requirements in addition to those already 1163 listed in [RFC5440]. 1165 10.4. Verify Correct Operations 1167 Mechanisms defined in this document do not imply any new operation 1168 verification requirements in addition to those already listed in 1169 [RFC5440] and [RFC8231]. 1171 10.5. Requirements On Other Protocols 1173 PCEP extensions defined in this document do not put new requirements 1174 on other protocols. 1176 10.6. Impact On Network Operations 1178 PCEP extensions defined in this document do not put new requirements 1179 on network operations. 1181 11. IANA Considerations 1183 11.1. PCEP TLV Type Indicators 1185 IANA is requested to allocate the following TLV Type Indicator values 1186 within the "PCEP TLV Type Indicators" sub- registry of the PCEP 1187 Numbers registry: 1189 Value Meaning Reference 1190 TBD14 IPV4-ADDRESS TLV This document 1191 TBD15 IPV6-ADDRESS TLV This document 1192 TBD16 UNNUMBERED-IPV4-ID-ADDRESS TLV This document 1193 TBD17 LINKLOCAL-IPV6-ID-ADDRESS TLV This document 1195 11.2. PATH-SETUP-TYPE-CAPABILITY Sub-TLV Type Indicators 1197 [I-D.ietf-pce-segment-routing] requested creation of "PATH-SETUP- 1198 TYPE-CAPABILITY Sub-TLV Type Indicators" sub-registry. Further IANA 1199 is requested to allocate the following code-point: 1201 Value Meaning Reference 1202 TBD12 PCECC-CAPABILITY This document 1204 11.3. New Path Setup Type Registry 1206 [RFC8408] created a sub-registry within the "Path Computation Element 1207 Protocol (PCEP) Numbers" registry called "PCEP Path Setup Types". 1208 IANA is requested to allocate a new code point within this registry, 1209 as follows: 1211 Value Description Reference 1212 TBD1 Traffic engineering path is This document 1213 setup using PCECC mode 1215 11.4. PCEP Object 1217 IANA is requested to allocate new code-point in the "PCEP Objects" 1218 sub-registry for the CCI object as follows: 1220 Object-Class Value Name Reference 1221 TBD13 CCI Object-Type This document 1222 0 Reserved 1223 1 MPLS Label 1225 11.5. CCI Object Flag Field 1227 IANA is requested to create a new sub-registry to manage the Flag 1228 field of the CCI object called "CCI Object Flag Field". New values 1229 are to be assigned by Standards Action [RFC8126]. Each bit should be 1230 tracked with the following qualities: 1232 o Bit number (counting from bit 0 as the most significant bit) 1234 o Capability description 1236 o Defining RFC 1237 Two bits to be defined for the CCI Object flag field in this document 1238 as follows: 1240 Bit Description Reference 1241 0-13 Unassigned This document 1242 14 C Bit - PCC allocation This document 1243 15 O Bit - Specifies label This document 1244 is out label 1246 11.6. PCEP-Error Object 1248 IANA is requested to allocate new error types and error values within 1249 the "PCEP-ERROR Object Error Types and Values" sub-registry of the 1250 PCEP Numbers registry for the following errors: 1252 Error-Type Meaning 1253 ---------- ------- 1254 10 Reception of an invalid object. 1256 Error-value = TBD2 : Missing PCECC 1257 Capability sub-TLV 1258 19 Invalid operation. 1260 Error-value = TBD3 : Attempted PCECC 1261 operations when 1262 PCECC capability 1263 was not advertised 1264 Error-value = TBD4 : Stateful PCE 1265 capability was not 1266 advertised 1267 Error-value = TBD8 : Unknown Label 1268 6 Mandatory Object missing. 1270 Error-value = TBD11 : CCI object missing 1271 TBD5 PCECC failure. 1273 Error-value = TBD6 : Label out of range. 1274 Error-value = TBD7 : Instruction failed. 1275 Error-value = TBD9 : Invalid CCI. 1276 Error-value = TBD10 : Unable to allocate 1277 the specified CCI. 1279 12. Acknowledgments 1281 We would like to thank Robert Tao, Changjing Yan, Tieying Huang and 1282 Avantika for their useful comments and suggestions. 1284 13. References 1286 13.1. Normative References 1288 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1289 Requirement Levels", BCP 14, RFC 2119, 1290 DOI 10.17487/RFC2119, March 1997, 1291 . 1293 [RFC5440] Vasseur, JP., Ed. and JL. Le Roux, Ed., "Path Computation 1294 Element (PCE) Communication Protocol (PCEP)", RFC 5440, 1295 DOI 10.17487/RFC5440, March 2009, 1296 . 1298 [RFC7420] Koushik, A., Stephan, E., Zhao, Q., King, D., and J. 1299 Hardwick, "Path Computation Element Communication Protocol 1300 (PCEP) Management Information Base (MIB) Module", 1301 RFC 7420, DOI 10.17487/RFC7420, December 2014, 1302 . 1304 [RFC7525] Sheffer, Y., Holz, R., and P. Saint-Andre, 1305 "Recommendations for Secure Use of Transport Layer 1306 Security (TLS) and Datagram Transport Layer Security 1307 (DTLS)", BCP 195, RFC 7525, DOI 10.17487/RFC7525, May 1308 2015, . 1310 [RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for 1311 Writing an IANA Considerations Section in RFCs", BCP 26, 1312 RFC 8126, DOI 10.17487/RFC8126, June 2017, 1313 . 1315 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 1316 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 1317 May 2017, . 1319 [RFC8231] Crabbe, E., Minei, I., Medved, J., and R. Varga, "Path 1320 Computation Element Communication Protocol (PCEP) 1321 Extensions for Stateful PCE", RFC 8231, 1322 DOI 10.17487/RFC8231, September 2017, 1323 . 1325 [RFC8233] Dhody, D., Wu, Q., Manral, V., Ali, Z., and K. Kumaki, 1326 "Extensions to the Path Computation Element Communication 1327 Protocol (PCEP) to Compute Service-Aware Label Switched 1328 Paths (LSPs)", RFC 8233, DOI 10.17487/RFC8233, September 1329 2017, . 1331 [RFC8281] Crabbe, E., Minei, I., Sivabalan, S., and R. Varga, "Path 1332 Computation Element Communication Protocol (PCEP) 1333 Extensions for PCE-Initiated LSP Setup in a Stateful PCE 1334 Model", RFC 8281, DOI 10.17487/RFC8281, December 2017, 1335 . 1337 [RFC8408] Sivabalan, S., Tantsura, J., Minei, I., Varga, R., and J. 1338 Hardwick, "Conveying Path Setup Type in PCE Communication 1339 Protocol (PCEP) Messages", RFC 8408, DOI 10.17487/RFC8408, 1340 July 2018, . 1342 13.2. Informative References 1344 [RFC4655] Farrel, A., Vasseur, J., and J. Ash, "A Path Computation 1345 Element (PCE)-Based Architecture", RFC 4655, 1346 DOI 10.17487/RFC4655, August 2006, 1347 . 1349 [RFC7025] Otani, T., Ogaki, K., Caviglia, D., Zhang, F., and C. 1350 Margaria, "Requirements for GMPLS Applications of PCE", 1351 RFC 7025, DOI 10.17487/RFC7025, September 2013, 1352 . 1354 [RFC7399] Farrel, A. and D. King, "Unanswered Questions in the Path 1355 Computation Element Architecture", RFC 7399, 1356 DOI 10.17487/RFC7399, October 2014, 1357 . 1359 [RFC7491] King, D. and A. Farrel, "A PCE-Based Architecture for 1360 Application-Based Network Operations", RFC 7491, 1361 DOI 10.17487/RFC7491, March 2015, 1362 . 1364 [RFC7942] Sheffer, Y. and A. Farrel, "Improving Awareness of Running 1365 Code: The Implementation Status Section", BCP 205, 1366 RFC 7942, DOI 10.17487/RFC7942, July 2016, 1367 . 1369 [RFC8253] Lopez, D., Gonzalez de Dios, O., Wu, Q., and D. Dhody, 1370 "PCEPS: Usage of TLS to Provide a Secure Transport for the 1371 Path Computation Element Communication Protocol (PCEP)", 1372 RFC 8253, DOI 10.17487/RFC8253, October 2017, 1373 . 1375 [RFC8283] Farrel, A., Ed., Zhao, Q., Ed., Li, Z., and C. Zhou, "An 1376 Architecture for Use of PCE and the PCE Communication 1377 Protocol (PCEP) in a Network with Central Control", 1378 RFC 8283, DOI 10.17487/RFC8283, December 2017, 1379 . 1381 [I-D.ietf-pce-segment-routing] 1382 Sivabalan, S., Filsfils, C., Tantsura, J., Henderickx, W., 1383 and J. Hardwick, "PCEP Extensions for Segment Routing", 1384 draft-ietf-pce-segment-routing-16 (work in progress), 1385 March 2019. 1387 [I-D.ietf-teas-pcecc-use-cases] 1388 Zhao, Q., Li, Z., Khasanov, B., Dhody, D., Ke, Z., Fang, 1389 L., Zhou, C., Communications, T., Rachitskiy, A., and A. 1390 Gulida, "The Use Cases for Path Computation Element (PCE) 1391 as a Central Controller (PCECC).", draft-ietf-teas-pcecc- 1392 use-cases-04 (work in progress), July 2019. 1394 [I-D.ietf-pce-pcep-yang] 1395 Dhody, D., Hardwick, J., Beeram, V., and J. Tantsura, "A 1396 YANG Data Model for Path Computation Element 1397 Communications Protocol (PCEP)", draft-ietf-pce-pcep- 1398 yang-13 (work in progress), October 2019. 1400 [I-D.zhao-pce-pcep-extension-pce-controller-sr] 1401 Zhao, Q., Li, Z., Negi, M., and C. Zhou, "PCEP Procedures 1402 and Protocol Extensions for Using PCE as a Central 1403 Controller (PCECC) of SR-LSPs", draft-zhao-pce-pcep- 1404 extension-pce-controller-sr-05 (work in progress), July 1405 2019. 1407 [I-D.li-pce-controlled-id-space] 1408 Li, C., Chen, M., Dong, J., Li, Z., Wang, A., Cheng, W., 1409 and C. Zhou, "PCE Controlled ID Space", draft-li-pce- 1410 controlled-id-space-03 (work in progress), June 2019. 1412 [I-D.sivabalan-pce-binding-label-sid] 1413 Sivabalan, S., Filsfils, C., Tantsura, J., Hardwick, J., 1414 Previdi, S., and C. Li, "Carrying Binding Label/Segment-ID 1415 in PCE-based Networks.", draft-sivabalan-pce-binding- 1416 label-sid-07 (work in progress), July 2019. 1418 [I-D.li-pce-sr-path-segment] 1419 Li, C., Chen, M., Cheng, W., Dong, J., Li, Z., Gandhi, R., 1420 and Q. Xiong, "Path Computation Element Communication 1421 Protocol (PCEP) Extension for Path Segment in Segment 1422 Routing (SR)", draft-li-pce-sr-path-segment-08 (work in 1423 progress), August 2019. 1425 Appendix A. Contributor Addresses 1427 Dhruv Dhody 1428 Huawei Technologies 1429 Divyashree Techno Park, Whitefield 1430 Bangalore, Karnataka 560066 1431 India 1433 EMail: dhruv.ietf@gmail.com 1435 Satish Karunanithi 1436 Huawei Technologies 1437 Divyashree Techno Park, Whitefield 1438 Bangalore, Karnataka 560066 1439 India 1441 EMail: satishk@huawei.com 1443 Adrian Farrel 1444 Juniper Networks, Inc 1445 UK 1447 EMail: adrian@olddog.co.uk 1449 Xuesong Geng 1450 Huawei Technologies 1451 China 1453 Email: gengxuesong@huawei.com 1455 Udayasree Palle 1457 EMail: udayasreereddy@gmail.com 1459 Katherine Zhao 1460 Futurewei Technologies 1462 EMail: katherine.zhao@futurewei.com 1464 Boris Zhang 1465 Telus Ltd. 1466 Toronto 1467 Canada 1469 EMail: boris.zhang@telus.com 1471 Alex Tokar 1472 Cisco Systems 1473 Slovak Republic 1475 EMail: atokar@cisco.com 1477 Authors' Addresses 1479 Quintin Zhao 1480 Huawei Technologies 1481 125 Nagog Technology Park 1482 Acton, MA 01719 1483 USA 1485 EMail: quintin.zhao@huawei.com 1487 Zhenbin Li 1488 Huawei Technologies 1489 Huawei Bld., No.156 Beiqing Rd. 1490 Beijing 100095 1491 China 1493 EMail: lizhenbin@huawei.com 1495 Mahendra Singh Negi 1496 Huawei Technologies 1497 Divyashree Techno Park, Whitefield 1498 Bangalore, Karnataka 560066 1499 India 1501 EMail: mahend.ietf@gmail.com 1503 Chao Zhou 1504 Cisco Systems 1506 EMail: chao.zhou@cisco.com