idnits 2.17.1 draft-ietf-pce-pcep-extension-for-pce-controller-02.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 8, 2019) is 1754 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-12 == Outdated reference: A later version (-09) exists of draft-zhao-pce-pcep-extension-pce-controller-sr-04 == Outdated reference: A later version (-16) exists of draft-li-pce-controlled-id-space-03 == Outdated reference: A later version (-08) exists of draft-li-pce-sr-path-segment-05 Summary: 1 error (**), 0 flaws (~~), 6 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 PCE Working Group Q. Zhao 3 Internet-Draft Z. Li 4 Intended status: Standards Track M. Negi 5 Expires: January 9, 2020 Huawei Technologies 6 C. Zhou 7 Cisco Systems 8 July 8, 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-02 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 January 9, 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 MUST have the capability to 235 advertise its PCECC capability to its peers. 237 2. PCEP speaker not supporting this draft MUST be able to reject 238 PCECC related extensions with a error reason code that indicates 239 that this feature is not supported. 241 3. PCEP speaker MUST provide a means to identify PCECC based LSP in 242 the PCEP messages. 244 4. PCEP procedures SHOULD provide a means to update (or cleanup) the 245 label- download entry to the PCC. 247 5. PCEP procedures SHOULD provide a means to synchronize the labels 248 between PCE to PCC in PCEP messages. 250 6. PCEP procedures MAY allow for PCC based label allocations. 252 5. Procedures for Using the PCE as the Central Controller (PCECC) 254 5.1. Stateful PCE Model 256 Active stateful PCE is described in [RFC8231]. PCE as a central 257 controller (PCECC) reuses existing Active stateful PCE mechanism as 258 much as possible to control the LSP. 260 5.2. New LSP Functions 262 This document defines the following new PCEP messages and extends the 263 existing messages to support PCECC: 265 (PCInitiate): a PCEP message described in [RFC8281]. PCInitiate 266 message is used to setup PCE-Initiated LSP based on PCECC 267 mechanism. It is also extended for Central Controller's 268 Instructions (CCI) (download or cleanup the Label forwarding 269 instructions in the context of this document) on all nodes along 270 the path. 272 (PCRpt): a PCEP message described in [RFC8231]. PCRpt message is 273 used to send PCECC LSP Reports. It is also extended to report the 274 set of Central Controller's Instructions (CCI) (label forwarding 275 instructions in the context of this document) received from the 276 PCE. See Section 5.4.6 for more details. 278 (PCUpd): a PCEP message described in [RFC8231]. PCUpd message is 279 used to send PCECC LSP Update. 281 The new LSP functions defined in this document are mapped onto the 282 messages as shown in the following table. 284 +----------------------------------------+--------------------------+ 285 | Function | Message | 286 +----------------------------------------+--------------------------+ 287 | PCECC Capability advertisement | Open | 288 | Label entry Add | PCInitiate | 289 | Label entry Cleanup | PCInitiate | 290 | PCECC Initiated LSP | PCInitiate | 291 | PCECC LSP Update | PCUpd | 292 | PCECC LSP State Report | PCRpt | 293 | PCECC LSP Delegation | PCRpt | 294 | PCECC Label Report | PCRpt | 295 +----------------------------------------+--------------------------+ 297 This document specify a new PCEP object called CCI (see Section 7.3) 298 for the encoding of central controller's instructions. In the scope 299 of this document this is limited to Label forwarding instructions. 300 Future documents can create new CCI object-type for other types of 301 central control instructions. The CC-ID is the unique identifier for 302 the central controller's instructions in PCEP. The PCEP messages are 303 extended in this document to handle the PCECC operations. 305 5.3. PCECC Capability Advertisement 307 During PCEP Initialization Phase, PCEP Speakers (PCE or PCC) 308 advertise their support of PCECC extensions. 310 This document defines a new Path Setup Type (PST) [RFC8408] for 311 PCECC, as follows: 313 o PST = TBD: Path is setup via PCECC mode. 315 A PCEP speaker MUST indicate its support of the function described in 316 this document by sending a PATH-SETUP-TYPE-CAPABILITY TLV in the OPEN 317 object with this new PST included in the PST list. 319 This document also defines the PCECC Capability sub-TLV 320 Section 7.1.1. PCEP speakers use this sub-TLV to exchange 321 information about their PCECC capability. If a PCEP speaker includes 322 PST=TBD in the PST List of the PATH-SETUP-TYPE-CAPABILITY TLV then it 323 MUST also include the PCECC Capability sub-TLV inside the PATH-SETUP- 324 TYPE-CAPABILITY TLV. If the sub-TLV is absent, then the PCEP speaker 325 MUST send a PCErr message with Error-Type 10 (Reception of an invalid 326 object) and Error-Value TBD (Missing PCECC Capability sub-TLV) and 327 MUST then close the PCEP session. If a PCEP speaker receives a PATH- 328 SETUP-TYPE-CAPABILITY TLV with a SR-PCE-CAPABILITY sub-TLV, but the 329 PST list does not contain PST=1, then the PCEP speaker MUST ignore 330 the SR-PCE-CAPABILITY sub- TLV. 332 The presence of the PST and PCECC Capability sub-TLV in PCC's OPEN 333 Object indicates that the PCC is willing to function as a PCECC 334 client. The presence of the PST and PCECC Capability sub-TLV in 335 PCE's OPEN message indicates that the PCE is interested in function 336 as a PCECC server. 338 The PCEP protocol extensions for PCECC MUST NOT be used if one or 339 both PCEP Speakers have not included the PST or the PCECC Capability 340 sub-TLV in their respective OPEN message. If the PCEP Speakers 341 support the extensions of this draft but did not advertise this 342 capability then a PCErr message with Error-Type=19(Invalid Operation) 343 and Error-Value=TBD (Attempted PCECC operations when PCECC capability 344 was not advertised) will be generated and the PCEP session will be 345 terminated. 347 A PCC or a PCE MUST include both PCECC-CAPABILITY sub-TLV and 348 STATEFUL-PCE-CAPABILITY TLV ([RFC8231]) (with I flag set [RFC8281]) 349 in OPEN Object to support the extensions defined in this document. 350 If PCECC-CAPABILITY sub-TLV is advertised and STATEFUL-PCE-CAPABILITY 351 TLV is not advertised in OPEN Object, it MUST send a PCErr message 352 with Error-Type=19 (Invalid Operation) and Error-value=TBD (stateful 353 PCE capability was not advertised) and terminate the session. This 354 error is also triggered if PCECC-CAPABILITY sub-TLV is advertised and 355 I flag is not set. 357 5.4. LSP Operations 359 The PCEP messages pertaining to PCECC MUST include PATH-SETUP-TYPE 360 TLV [RFC8408] in the SRP object to clearly identify the PCECC LSP is 361 intended. 363 5.4.1. Basic PCECC LSP Setup 365 In order to setup a LSP based on PCECC mechanism, a PCC MUST delegate 366 the LSP by sending a PCRpt message with PST set for PCECC (see 367 Section 7.2) and D (Delegate) flag (see [RFC8231]) set in the LSP 368 object. 370 LSP-IDENTIFIER TLV MUST be included for PCECC LSP, the tuple uniquely 371 identifies the LSP in the network. The LSP object is included in 372 central controller's instructions (label download) to identify the 373 PCECC LSP for this instruction. The PLSP-ID is the original 374 identifier used by the ingress PCC, so the transit LSR could have 375 multiple central controller instructions that have the same PLSP-ID. 376 The PLSP-ID in combination with the source (in LSP-IDENTIFIER TLV) 377 MUST be unique. The PLSP-ID is included for maintainability reasons 378 to ease debugging. As per [RFC8281], the LSP object could include 379 SPEAKER-ENTITY-ID TLV to identify the PCE that initiated these 380 instructions. Also the CC-ID is unique on the PCEP session as 381 described in Section 7.3. 383 When a PCE receives PCRpt message with D flags and PST Type set, it 384 calculates the path and assigns labels along the path; and set up the 385 path by sending PCInitiate message to each node along the path of the 386 LSP. The PCC generates a Path Computation State Report (PCRpt) and 387 include the central controller's instruction (CCI) and the identified 388 LSP. The CC-ID is uniquely identify the central controller's 389 instruction within a PCEP session. The PCC further responds with the 390 PCRpt messages including the CCI and LSP objects. 392 The Ingress node would receive one CCI object with O bit (out-label) 393 set. The transit node(s) would receive two CCI object with the in- 394 label CCI without O bit set and the out-label CCI with O bit set. 395 The egress node would receive one CCI object without O bit set. A 396 node can determine its role based on the setting of the O bit in the 397 CCI object(s). 399 Once the central controller's instructions (label operations) are 400 completed, the PCE MUST send the PCUpd message to the Ingress PCC. 401 This PCUpd message is as per [RFC8231] SHOULD include the path 402 information as calculated by the PCE. 404 Note that the PCECC LSPs MUST be delegated to a PCE at all times. 406 LSP deletion operation for PCECC LSP is same as defined in [RFC8231]. 407 If the PCE receives PCRpt message for LSP deletion then it does Label 408 cleanup operation as described in Section 5.4.2.2 for the 409 corresponding LSP. 411 The Basic PCECC LSP setup sequence is as shown below. 413 +-------+ +-------+ 414 |PCC | | PCE | 415 |Ingress| +-------+ 416 +------| | | 417 | PCC +-------+ | 418 | Transit| | | 419 +------| | |-- PCRpt,PLSP-ID=1, PST=TBD, D=1---->| PCECC LSP 420 |PCC +--------+ | | 421 |Egress | | | | 422 +--------+ | | | 423 | | | | 424 |<------ PCInitiate,CC-ID=X,PLSP-ID=1 ------------ | Label 425 | | | L1,O=0 | download 426 |------- PCRpt,CC-ID=X,PLSP-ID=1 ----------------->| CCI 427 | | | | 428 | |<----- PCInitiate,PLSP-ID=1, ------------- | Labels 429 | | | CC-ID=Y1,O=0,L2 | download 430 | | | CC-ID=Y2,O=1,L1 | CCI 431 | |----- PCRpt,CC-ID=Y1,Y2,PLSP-ID=1 ------>| 432 | | | | 433 | | |<--- PCInitiate,CC-ID=Z,PLSP-ID=1 - | Label 434 | | | L2,O=1 | download 435 | | |---- PCRpt,CC-ID=Z,PLSP-ID=1 ------>| CCI 436 | | | | 437 | | |<-- PCUpd,PLSP-ID=1,PST=TBD, D=1-----| PCECC LSP 438 | | | | Update 439 | | | | 441 Figure 2: Basic PCECC LSP setup 443 The PCECC LSP are considered to be 'up' by default (on receipt of 444 PCUpd message from PCE). The Ingress MAY further choose to deploy a 445 data plane check mechanism and report the status back to the PCE via 446 PCRpt message. 448 In case where the label allocation are made by the PCC itself (see 449 Section 5.4.8), the PCE could request an allocation to be made by the 450 PCC, and where the PCC would send a PCRpt with the allocated label 451 encoded in the CC-ID object as shown below - 452 +-------+ +-------+ 453 |PCC | | PCE | 454 |Ingress| +-------+ 455 +------| | | 456 | PCC +-------+ | 457 | Transit| | | 458 +------| | |-- PCRpt,PLSP-ID=1, PST=TBD, D=1---->| PCECC LSP 459 |PCC +--------+ | | 460 |Egress | | | | 461 +--------+ | | | 462 | | | | 463 |<------ PCInitiate,CC-ID=X,PLSP-ID=1 ------------ | Label 464 | | | C=1 | download 465 |------- PCRpt,CC-ID=X,PLSP-ID=1 ----------------->| CCI 466 | | | Label=L1 | 467 | |<----- PCInitiate,PLSP-ID=1, ------------- | Labels 468 | | | CC-ID=Y1,C=1 | download 469 | | | CC-ID=Y2,C=0,L1 | CCI 470 | |----- PCRpt,PLSP-ID=1 ------------------>| 471 | | | CC-ID=Y1, Label=L2 | 472 | | | CC-ID=Y2 | 473 | | |<--- PCInitiate,CC-ID=Z,PLSP-ID=1 - | Label 474 | | | C=0,L2 | download 475 | | |---- PCRpt,CC-ID=Z,PLSP-ID=1 ------>| CCI 476 | | | | 477 | | |<-- PCUpd,PLSP-ID=1,PST=TBD, D=1-----| PCECC LSP 478 | | | | Update 479 | | | | 481 - The O bit is set as before (and thus not included) 483 Figure 3: Basic PCECC LSP setup (PCC allocation) 485 It should be noted that in this example, the request is made to the 486 egress node with C bit set in the CCI object to indicate that the 487 label allocation needs to be done by the egress and it responds with 488 the allocated label to the PCE. The PCE would further inform the 489 transit PCC without setting the C bit in the CCI object for out-label 490 but the C-bit is unset for in-label so the transit node make the 491 label allocation (for the in-label) and report to the PCE. Similarly 492 C bit is unset towards the ingress to complete all the label 493 allocation for the PCECC LSP. 495 5.4.2. Central Control Instructions 497 The new central controller's instructions (CCI) for the label 498 operations in PCEP is done via the PCInitiate message, by defining a 499 new PCEP Objects for CCI operations. Local label range of each PCC 500 is assumed to be known at both the PCC and the PCE. 502 5.4.2.1. Label Download CCI 504 In order to setup an LSP based on PCECC, the PCE sends a PCInitiate 505 message to each node along the path to download the Label instruction 506 as described in Section 5.4.1. 508 The CCI object MUST be included, along with the LSP object in the 509 PCInitiate message. The LSP-IDENTIFIER TLV MUST be included in LSP 510 object. The SPEAKER-ENTITY-ID TLV SHOULD be included in LSP object. 512 If a node (PCC) receives a PCInitiate message which includes a Label 513 to download as part of CCI, that is out of the range set aside for 514 the PCE, it MUST send a PCErr message with Error-type=TBD (PCECC 515 failure) and Error-value=TBD (Label out of range) and MUST include 516 the SRP object to specify the error is for the corresponding label 517 update via PCInitiate message. If a PCC receives a PCInitiate 518 message but failed to download the Label entry, it MUST send a PCErr 519 message with Error-type=TBD (PCECC failure) and Error-value=TBD 520 (instruction failed) and MUST include the SRP object to specify the 521 error is for the corresponding label update via PCInitiate message. 523 New PCEP object for central control instructions (CCI) is defined in 524 Section 7.3. 526 5.4.2.2. Label Cleanup CCI 528 In order to delete an LSP based on PCECC, the PCE sends a central 529 controller instructions via a PCInitiate message to each node along 530 the path of the LSP to cleanup the Label forwarding instruction. 532 If the PCC receives a PCInitiate message but does not recognize the 533 label in the CCI, the PCC MUST generate a PCErr message with Error- 534 Type 19(Invalid operation) and Error-Value=TBD, "Unknown Label" and 535 MUST include the SRP object to specify the error is for the 536 corresponding label cleanup (via PCInitiate message). 538 The R flag in the SRP object defined in [RFC8281] specifies the 539 deletion of Label Entry in the PCInitiate message. 541 +-------+ +-------+ 542 |PCC | | PCE | 543 |Ingress| +-------+ 544 +------| | | 545 | PCC +-------+ | 546 | Transit| | | 547 +------| | |-- PCRpt,PLSP-ID=1,PST=TBD,D=1,R=1--->| PCECC LSP 548 |PCC +--------+ | | remove 549 |Egress | | | | 550 +--------+ | | | 551 | | | | 552 |<------ PCInitiate,CC-ID=X,PLSP-ID=1 ------------ | Label 553 | | | R=1 | cleanup 554 |------- PCRpt,CC-ID=X,PLSP-ID=1 ------------------>| CCI 555 | | | | 556 | |<----- PCInitiate,CC-ID=Y1,Y2,PLSP-ID=1 -- | Label 557 | | | R=1 | cleanup 558 | |----- PCRpt,CC-ID=Y1,Y2,PLSP-ID=1 ------->| CCI 559 | | | | 560 | | |<--- PCInitiate,CC-ID=Z,PLSP-ID=1 -- | Label 561 | | | R=1 | cleanup 562 | | |---- PCRpt,CC-ID=Z,PLSP-ID=1 ------->| CCI 563 | | | | 565 As per [RFC8281], following the removal of the Label forwarding 566 instruction, the PCC MUST send a PCRpt message. The SRP object in 567 the PCRpt MUST include the SRP-ID-number from the PCInitiate message 568 that triggered the removal. The R flag in the SRP object MUST be 569 set. 571 In case where the label allocation are made by the PCC itself (see 572 Section 5.4.8), the removal procedure remains the same. 574 5.4.3. PCE Initiated PCECC LSP 576 The LSP Instantiation operation is same as defined in [RFC8281]. 578 In order to setup a PCE Initiated LSP based on the PCECC mechanism, a 579 PCE sends PCInitiate message with Path Setup Type set for PCECC (see 580 Section 7.2) to the Ingress PCC. 582 The Ingress PCC MUST also set D (Delegate) flag (see [RFC8231]) and C 583 (Create) flag (see [RFC8281]) in LSP object of PCRpt message. The 584 PCC responds with first PCRpt message with the status as "GOING-UP" 585 and assigned PLSP-ID. 587 Note that the label forwarding instructions from PCECC are send after 588 the initial PCInitiate and PCRpt exchange. This is done so that the 589 PLSP-ID and other LSP identifiers can be obtained from the ingress 590 and can be included in the label forwarding instruction in the next 591 PCInitiate message. The rest of the PCECC LSP setup operations are 592 same as those described in Section 5.4.1. 594 The LSP deletion operation for PCE Initiated PCECC LSP is same as 595 defined in [RFC8281]. The PCE should further perform Label entry 596 cleanup operation as described in Section 5.4.2.2 for the 597 corresponding LSP. 599 The PCE Initiated PCECC LSP setup sequence is shown below - 601 +-------+ +-------+ 602 |PCC | | PCE | 603 |Ingress| +-------+ 604 +------| | | 605 | PCC +-------+ | 606 | Transit| | | 607 +------| | |<--PCInitiate,PLSP-ID=0,PST=TBD,D=1---| PCECC LSP 608 |PCC +--------+ | | Initiate 609 |Egress | | |--- PCRpt,PLSP-ID=2,P=1,D=1,C=1---> | PCECC LSP 610 +--------+ | | (GOING-UP) | 611 | | | | 612 |<------ PCInitiate,CC-ID=X,PLSP-ID=2 -------------- | Label 613 | | | | download 614 |------- PCRpt,CC-ID=X,PLSP-ID=2 ------------------>| CCI 615 | | | | 616 | |<----- PCInitiate,CC-ID=Y1,Y2,PLSP-ID=2 --- | Label 617 | | | | download 618 | |----- PCRpt,CC-ID=Y1,Y2,PLSP-ID=2 ------->| CCI 619 | | | | 620 | | |<--- PCInitiate,CC-ID=Z,PLSP-ID=2 --- | Label 621 | | | | download 622 | | |---- PCRpt,CC-ID=Z,PLSP-ID=2 ------->| CCI 623 | | | | 624 | | |<-- PCUpd, PLSP-ID=2, PST=TBD, D=1--- | PCECC LSP 625 | | | (UP) | Update 626 | | |--- PCRpt,PLSP-ID=2,P=1,D=1,C=1---> | 627 | | | (UP) | 629 Once the label operations are completed, the PCE SHOULD send the 630 PCUpd message to the Ingress PCC. The PCUpd message is as per 631 [RFC8231]. 633 In case where the label allocation are made by the PCC itself (see 634 Section 5.4.8), the procedure remains similar. 636 5.4.4. PCECC LSP Update 638 In case of a modification of PCECC LSP with a new path, a PCE sends a 639 PCUpd message to the Ingress PCC. But to follow the make-before- 640 break procedures, the PCECC first update new instructions based on 641 the updated LSP and then update to ingress to switch traffic, before 642 cleaning up the old instructions. A new CC-ID is used to identify 643 the updated instruction, the existing identifiers in the LSP object 644 identify the existing LSP. Once new instructions are downloaded, the 645 PCE further updates the new path at the ingress which triggers the 646 traffic switch on the updated path. The Ingress PCC acknowledges 647 with a PCRpt message, on receipt of PCRpt message, the PCE does 648 cleanup operation for the old LSP as described in Section 5.4.2.2. 650 The PCECC LSP Update sequence is shown below - 651 +-------+ +-------+ 652 |PCC | | PCE | 653 |Ingress| +-------+ 654 +------| | | 655 | PCC +-------+ | 656 | Transit| | | 657 +------| | | | 658 |PCC +--------+ | | 659 |Egress | | | | 660 +--------+ | | | 661 | | | | New Path 662 |<------ PCInitiate,CC-ID=XX,PLSP-ID=1 ----------- | for LSP 663 | | | | trigger 664 |------- PCRpt,CC-ID=XX,PLSP-ID=1 ---------------->| new CCI 665 | | | | 666 | |<----- PCInitiate,CC-ID=YY1,YY2,PLSP-ID=1--| Label 667 | | | | download 668 | |----- PCRpt,CC-ID=YY1,YY2,PLSP-ID=1 ---->| CCI 669 | | | | 670 | | |<--- PCInitiate,CC-ID=ZZ,PLSP-ID=1 - | Label 671 | | | | download 672 | | |---- PCRpt,CC-ID=ZZ,PLSP-ID=1 ----->| CCI 673 | | | | 674 | | |<-- PCUpd, PLSP-ID=1, PST=TBD, D=1-- | PCECC 675 | | | SRP=S | LSP Update 676 | | | | 677 | | |-- PCRpt,PLSP-ID=1,PST=TBD,D=1 -->| Trigger 678 | | | (SRP=S) | Delete old 679 | | | | CCI 680 | | | | 681 |<------ PCInitiate,CC-ID=X, PLSP-ID=1 ----------- | Label 682 | | | R=1 | cleanup 683 |------- PCRpt,CC-ID=X, PLSP-ID=1 ---------------->| CCI 684 | | | | 685 | |<----- PCInitiate,CC-ID=Y1,Y2, PLSP-ID=1 - | Label 686 | | | R=1 | cleanup 687 | |----- PCRpt,CC-ID=Y1,Y2, PLSP-ID=1 ----->| CCI 688 | | | | 689 | | |<--- PCInitiate,CC-ID=Z, PLSP-ID=1 - | Label 690 | | | R=1 | cleanup 691 | | |---- PCRpt,CC-ID=Z, PLSP-ID=1 ----->| CCI 692 | | | | 694 The modified PCECC LSP are considered to be 'up' by default. The 695 Ingress MAY further choose to deploy a data plane check mechanism and 696 report the status back to the PCE via PCRpt message. 698 In case where the label allocation are made by the PCC itself (see 699 Section 5.4.8), the procedure remains similar. 701 5.4.5. Re Delegation and Cleanup 703 As described in [RFC8281], a new PCE can gain control over the 704 orphaned LSP. In case of PCECC LSP, the new PCE MUST also gain 705 control over the central controllers instructions in the same way by 706 sending a PCInitiate message that includes the SRP, LSP and CCI 707 objects and carries the CC-ID and PLSP-ID identifying the 708 instruction, it wants to take control of. 710 Further, as described in [RFC8281], the State Timeout Interval timer 711 ensures that a PCE crash does not result in automatic and immediate 712 disruption for the services using PCE-initiated LSPs. Similarly the 713 central controller instructions are not removed immediately upon PCE 714 failure. Instead, they are cleaned up on the expiration of this 715 timer. This allows for network cleanup without manual intervention. 716 The PCC MUST support removal of CCI as one of the behaviors applied 717 on expiration of the State Timeout Interval timer. 719 5.4.6. Synchronization of Central Controllers Instructions 721 The purpose of Central Controllers Instructions synchronization 722 (labels in the context of this document) is to make sure that the 723 PCE's view of CCI (Labels) matches with the PCC's Label allocation. 724 This synchronization is performed as part of the LSP state 725 synchronization as described in [RFC8231] and [RFC8233]. 727 As per LSP State Synchronization [RFC8231], a PCC reports the state 728 of its LSPs to the PCE using PCRpt messages and as per [RFC8281], PCE 729 would initiate any missing LSPs and/or remove any LSPs that are not 730 wanted. The same PCEP messages and procedure is also used for the 731 Central Controllers Instructions synchronization. The PCRpt message 732 includes the CCI and the LSP object to report the label forwarding 733 instructions. The PCE would further remove any unwanted instructions 734 or initiate any missing instructions. 736 5.4.7. PCECC LSP State Report 738 As mentioned before, an Ingress PCC MAY choose to apply any OAM 739 mechanism to check the status of LSP in the Data plane and MAY 740 further send its status in PCRpt message to the PCE. 742 5.4.8. PCC Based Allocations 744 The PCE can request the PCC to allocate the label using the 745 PCInitiate message. The C flag in the CCI object is set to 1 to 746 indicate that the allocation needs to be done by the PCC. The PCC 747 would allocate the Label and would report to the PCE using the PCRpt 748 message. 750 If the value of the Label is 0 and the C flag is set, it indicates 751 that the PCE is requesting the allocation to be done by the PCC. If 752 the Label is 'n' and the C flag is set in the CCI object, it 753 indicates that the PCE requests a specific value 'n' for the Label. 754 If the allocation is successful, the PCC should report via PCRpt 755 message with the CCI object. Else, it MUST send a PCErr message with 756 Error-Type = TBD ("PCECC failure") and Error Value = TBD ("Invalid 757 CCI"). If the value of the the Label in the CCI object is valid, but 758 the PCC is unable to allocate it, it MUST send a PCErr message with 759 Error-Type = TBD ("PCECC failure") and Error Value = TBD ("Unable to 760 allocate the specified CCI"). 762 If the PCC wishes to withdrawn or modify the previously assigned 763 label, it MUST send a PCRpt message without any Label or with the 764 Label containing the new value respectively in the CCI object. The 765 PCE would further trigger the removal of the central controller 766 instruction as per this document. 768 5.4.9. Binding Label 770 As per [I-D.sivabalan-pce-binding-label-sid], when a stateful PCE is 771 deployed for setting up TE paths, it may be desirable to report the 772 binding label to the stateful PCE for the purpose of enforcing end- 773 to-end TE. In case of PCECC, the binding label may be allocated by 774 the PCE itself as described in this section. This procedure is thus 775 applicable for all path setup types including PCECC. 777 A P flag in LSP object is introduced in [I-D.li-pce-sr-path-segment] 778 to indicate the allocation needs to be made by the PCE. This flag is 779 used to indicate that the allocation needs to be made by the PCE. A 780 PCC would set this bit to 1 (and carry the TE-PATH-BINDING TLV 781 [I-D.sivabalan-pce-binding-label-sid] in LSP object) to request for 782 allocation of the binding label by the PCE in the PCReq or PCRpt 783 message. A PCE would also set this bit to 1 to indicate that the 784 binding label is allocated by PCE and encoded in the PCRep, PCUpd or 785 PCInitiate message (the TE-PATH-BINDING TLV is present in LSP 786 object). Further, a PCE would set this bit to 0 to indicate that the 787 allocation is done by the PCC instead. 789 The ingress PCC could request the binding label to be allocated by 790 the PCE via PCRpt message as per [RFC8231]. The delegate flag 791 (D-flag) MUST also be set for this LSP. The TE-PATH-BINDING TLV MUST 792 be included with no Binding Value. The PCECC would allocated the 793 binding label and further respond to Ingress PCC with PCUpd message 794 as per [RFC8231] and MUST include the TE-PATH-BINDING TLV in a LSP 795 object. The P flag in the LSP object would be set to 1 to indicate 796 that the allocation is made by the PCE. 798 The PCE could allocate the binding label on its own accord for a PCE- 799 Initiated (or delegated LSP). The allocated binding label needs to 800 be informed to the PCC. The PCE would use the PCInitiate message 801 [RFC8281] or PCUpd message [RFC8231] towards the PCC and MUST include 802 the TE-PATH-BINDING TLV in the LSP object. The P flag in the LSP 803 object would be set to 1 to indicate that the allocation is made by 804 the PCE. 806 The PCECC capability MUST be exchanged on the PCEP session, before 807 PCE could allocate binding label. Note that the CCI object is not 808 used for binding allocation; this is done to maintain consistency 809 with the rest of the binding label/SID procedures as per 810 [I-D.sivabalan-pce-binding-label-sid]. 812 6. PCEP messages 814 As defined in [RFC5440], a PCEP message consists of a common header 815 followed by a variable-length body made of a set of objects that can 816 be either mandatory or optional. An object is said to be mandatory 817 in a PCEP message when the object must be included for the message to 818 be considered valid. For each PCEP message type, a set of rules is 819 defined that specify the set of objects that the message can carry. 820 An implementation MUST form the PCEP messages using the object 821 ordering specified in this document. 823 LSP-IDENTIFIERS TLV MUST be included in the LSP object for PCECC LSP. 825 6.1. The PCInitiate message 827 The PCInitiate message [RFC8281] can be used to download or remove 828 the labels, the message has been extended as shown below - 829 ::= 830 831 Where: 832 is defined in [RFC5440] 834 ::= 835 [] 837 ::= 838 (| 839 | 840 ) 842 ::= 843 844 846 ::= 847 [] 849 Where: 850 and 851 are as per 852 [RFC8281]. 854 The LSP and SRP object is defined in [RFC8231]. 856 When PCInitiate message is used for central controller's instructions 857 (labels), the SRP, LSP and CCI objects MUST be present. The SRP 858 object is defined in [RFC8231] and if the SRP object is missing, the 859 receiving PCC MUST send a PCErr message with Error-type=6 (Mandatory 860 Object missing) and Error-value=10 (SRP object missing). The LSP 861 object is defined in [RFC8231] and if the LSP object is missing, the 862 receiving PCC MUST send a PCErr message with Error-type=6 (Mandatory 863 Object missing) and Error-value=8 (LSP object missing). The CCI 864 object is defined in Section 7.3 and if the CCI object is missing, 865 the receiving PCC MUST send a PCErr message with Error-type=6 866 (Mandatory Object missing) and Error-value=TBD (CCI object missing). 867 More than one CCI object MAY be included in the PCInitiate message 868 for the transit LSR. 870 To cleanup the SRP object must set the R (remove) bit. 872 At max two instances of CCI object would be included in case of 873 transit LSR to encode both in-coming and out-going label forwarding 874 instructions. Other instances MUST be ignored. 876 6.2. The PCRpt message 878 The PCRpt message can be used to report the labels that were 879 allocated by the PCE, to be used during the state synchronization 880 phase. 882 ::= 883 884 Where: 886 ::= [] 888 ::= (| 889 ) 891 ::= [] 892 893 895 ::= [] 896 897 899 ::= 900 [] 902 Where: 903 is as per [RFC8231] and the LSP and SRP object are 904 also defined in [RFC8231]. 906 When PCRpt message is used to report the central controller's 907 instructions (labels), the LSP and CCI objects MUST be present. The 908 LSP object is defined in [RFC8231] and if the LSP object is missing, 909 the receiving PCE MUST send a PCErr message with Error-type=6 910 (Mandatory Object missing) and Error-value=8 (LSP object missing). 911 The CCI object is defined in Section 7.3 and if the CCI object is 912 missing, the receiving PCC MUST send a PCErr message with Error- 913 type=6 (Mandatory Object missing) and Error-value=TBD (CCI object 914 missing). Two CCI object can be included in the PCRpt message for 915 the transit LSR. 917 7. PCEP Objects 919 The PCEP objects defined in this document are compliant with the PCEP 920 object format defined in [RFC5440]. 922 7.1. OPEN Object 924 This document defines a new optional TLVs for use in the OPEN Object. 926 7.1.1. PCECC Capability sub-TLV 928 The PCECC-CAPABILITY sub-TLV is an optional TLV for use in the OPEN 929 Object for PCECC capability advertisement in PATH-SETUP-TYPE- 930 CAPABILITY TLV. Advertisement of the PCECC capability implies 931 support of LSPs that are setup through PCECC as per PCEP extensions 932 defined in this document. 934 Its format is shown in the following figure: 936 0 1 2 3 937 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 938 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 939 | Type=TBD | Length=4 | 940 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 941 | Flags | 942 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 944 The type of the TLV is TBD and it has a fixed length of 4 octets. 946 The value comprises a single field - Flags (32 bits). 948 No flags are assigned right now. 950 Unassigned bits are considered reserved. They MUST be set to 0 on 951 transmission and MUST be ignored on receipt. 953 7.2. PATH-SETUP-TYPE TLV 955 The PATH-SETUP-TYPE TLV is defined in [RFC8408]; this document 956 defines a new PST value: 958 o PST = TBD: Path is setup via PCECC mode. 960 On a PCRpt/PCUpd/PCInitiate message, the PST=TBD in PATH-SETUP-TYPE 961 TLV in SRP object indicates that this LSP was setup via a PCECC based 962 mechanism. 964 7.3. CCI Object 966 The Central Control Instructions (CCI) Object is used by the PCE to 967 specify the forwarding instructions (Label information in the context 968 of this document) to the PCC, and MAY be carried within PCInitiate or 969 PCRpt message for label download. 971 CCI Object-Class is TBD. 973 CCI Object-Type is 1 for the MPLS Label. 975 0 1 2 3 976 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 977 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 978 | CC-ID | 979 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 980 | Reserved | Flags |C|O| 981 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 982 | Label | Reserved | 983 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 984 | | 985 // Optional TLV // 986 | | 987 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 989 The fields in the CCI object are as follows: 991 CC-ID: A PCEP-specific identifier for the CCI information. A PCE 992 creates an CC-ID for each instruction, the value is unique within 993 the scope of the PCE and is constant for the lifetime of a PCEP 994 session. The values 0 and 0xFFFFFFFF are reserved and MUST NOT be 995 used. 997 Flags: is used to carry any additional information pertaining to the 998 CCI. Currently, the following flag bit is defined: 1000 * O bit(Out-label) : If the bit is set, it specifies the label is 1001 the OUT label and it is mandatory to encode the next-hop 1002 information (via IPV4-ADDRESS TLV or IPV6-ADDRESS TLV or 1003 UNNUMBERED-IPV4-ID-ADDRESS TLV in the CCI object). If the bit 1004 is not set, it specifies the label is the IN label and it is 1005 optional to encode the local interface information (via 1006 IPV4-ADDRESS TLV or IPV6-ADDRESS TLV or UNNUMBERED-IPV4-ID- 1007 ADDRESS TLV in the CCI object). 1009 * C-Bit (PCC Allocation): If the bit is set to 1, it indicates 1010 that the allocation needs to be done by the PCC for this 1011 central controller instruction. A PCE set this bit to request 1012 the PCC to make an allocation from its label space. A PCC 1013 would set this bit to indicate that it has allocated the CC-ID 1014 and report it to the PCE. 1016 Label (20-bit): The Label information. 1018 Reserved (12 bit): Set to zero while sending, ignored on receive. 1020 7.3.1. Address TLVs 1022 This document defines the following TLVs for the CCI object to 1023 associate the next-hop information in case of an outgoing label and 1024 local interface information in case of an incoming label. 1026 IPV4-ADDRESS TLV: 1028 0 1 2 3 1029 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 1030 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1031 | Type=TBD | Length = 4 | 1032 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1033 | IPv4 address | 1034 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1036 IPV6-ADDRESS TLV: 1038 0 1 2 3 1039 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 1040 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1041 | Type=TBD | Length = 16 | 1042 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1043 | | 1044 // IPv6 address (16 bytes) // 1045 | | 1046 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1048 UNNUMBERED-IPV4-ID-ADDRESS TLV: 1050 0 1 2 3 1051 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 1052 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1053 | Type=TBD | Length = 8 | 1054 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1055 | Node-ID | 1056 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1057 | Interface ID | 1058 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1060 LINKLOCAL-IPV6-ID-ADDRESS TLV: 1062 0 1 2 3 1063 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 1064 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1065 | Type=TBD | Length = 40 | 1066 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1067 // Local IPv6 address (16 octets) // 1068 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1069 | Local Interface ID | 1070 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1071 // Remote IPv6 address (16 octets) // 1072 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1073 | Remote Interface ID | 1074 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1076 The address TLVs are as follows: 1078 IPV4-ADDRESS TLV: an IPv4 address. 1080 IPV6-ADDRESS TLV: an IPv6 address. 1082 UNNUMBERED-IPV4-ID-ADDRESS TLV: a Node ID / Interface ID tuple. 1084 LINKLOCAL-IPV6-ID-ADDRESS TLV: a pair of (global IPv6 address, 1085 interface ID) tuples. 1087 8. Implementation Status 1089 [Note to the RFC Editor - remove this section before publication, as 1090 well as remove the reference to RFC 7942.] 1092 This section records the status of known implementations of the 1093 protocol defined by this specification at the time of posting of this 1094 Internet-Draft, and is based on a proposal described in [RFC7942]. 1095 The description of implementations in this section is intended to 1096 assist the IETF in its decision processes in progressing drafts to 1097 RFCs. Please note that the listing of any individual implementation 1098 here does not imply endorsement by the IETF. Furthermore, no effort 1099 has been spent to verify the information presented here that was 1100 supplied by IETF contributors. This is not intended as, and must not 1101 be construed to be, a catalog of available implementations or their 1102 features. Readers are advised to note that other implementations may 1103 exist. 1105 According to [RFC7942], "this will allow reviewers and working groups 1106 to assign due consideration to documents that have the benefit of 1107 running code, which may serve as evidence of valuable experimentation 1108 and feedback that have made the implemented protocols more mature. 1109 It is up to the individual working groups to use this information as 1110 they see fit". 1112 8.1. Huawei's Proof of Concept based on ONOS 1114 The PCE function was developed in the ONOS open source platform. 1115 This extension was implemented on a private version as a proof of 1116 concept for PCECC. 1118 o Organization: Huawei 1120 o Implementation: Huawei's PoC based on ONOS 1122 o Description: PCEP as a southbound plugin was added to ONOS. To 1123 support PCECC, an earlier version of this I-D was implemented. 1124 Refer https://wiki.onosproject.org/display/ONOS/PCEP+Protocol 1126 o Maturity Level: Prototype 1128 o Coverage: Partial 1130 o Contact: satishk@huawei.com 1132 9. Security Considerations 1134 The security considerations described in [RFC8231] and [RFC8281] 1135 apply to the extensions described in this document. Additional 1136 considerations related to a malicious PCE are introduced. 1138 9.1. Malicious PCE 1140 PCE has complete control over PCC to update the labels and can cause 1141 the LSP's to behave inappropriate and cause cause major impact to the 1142 network. As a general precaution, it is RECOMMENDED that these PCEP 1143 extensions only be activated on authenticated and encrypted sessions 1144 across PCEs and PCCs belonging to the same administrative authority, 1145 using Transport Layer Security (TLS) [RFC8253], as per the 1146 recommendations and best current practices in [RFC7525]. 1148 10. Manageability Considerations 1150 10.1. Control of Function and Policy 1152 A PCE or PCC implementation SHOULD allow to configure to enable/ 1153 disable PCECC capability as a global configuration. 1155 10.2. Information and Data Models 1157 [RFC7420] describes the PCEP MIB, this MIB can be extended to get the 1158 PCECC capability status. 1160 The PCEP YANG module [I-D.ietf-pce-pcep-yang] could be extended to 1161 enable/disable PCECC capability. 1163 10.3. Liveness Detection and Monitoring 1165 Mechanisms defined in this document do not imply any new liveness 1166 detection and monitoring requirements in addition to those already 1167 listed in [RFC5440]. 1169 10.4. Verify Correct Operations 1171 Mechanisms defined in this document do not imply any new operation 1172 verification requirements in addition to those already listed in 1173 [RFC5440] and [RFC8231]. 1175 10.5. Requirements On Other Protocols 1177 PCEP extensions defined in this document do not put new requirements 1178 on other protocols. 1180 10.6. Impact On Network Operations 1182 PCEP extensions defined in this document do not put new requirements 1183 on network operations. 1185 11. IANA Considerations 1187 11.1. PCEP TLV Type Indicators 1189 IANA is requested to allocate the following TLV Type Indicator values 1190 within the "PCEP TLV Type Indicators" sub- registry of the PCEP 1191 Numbers registry: 1193 Value Meaning Reference 1194 TBD IPV4-ADDRESS TLV This document 1195 TBD IPV6-ADDRESS TLV This document 1196 TBD UNNUMBERED-IPV4-ID-ADDRESS TLV This document 1197 TBD LINKLOCAL-IPV6-ID-ADDRESS TLV This document 1199 11.2. PATH-SETUP-TYPE-CAPABILITY Sub-TLV Type Indicators 1201 [I-D.ietf-pce-segment-routing] requested creation of "PATH-SETUP- 1202 TYPE-CAPABILITY Sub-TLV Type Indicators" sub-registry. Further IANA 1203 is requested to allocate the following code-point: 1205 Value Meaning Reference 1206 TBD PCECC-CAPABILITY This document 1208 11.3. New Path Setup Type Registry 1210 [RFC8408] created a sub-registry within the "Path Computation Element 1211 Protocol (PCEP) Numbers" registry called "PCEP Path Setup Types". 1212 IANA is requested to allocate a new code point within this registry, 1213 as follows: 1215 Value Description Reference 1216 TBD Traffic engineering path is This document 1217 setup using PCECC mode 1219 11.4. PCEP Object 1221 IANA is requested to allocate new code-point in the "PCEP Objects" 1222 sub-registry for the CCI object as follows: 1224 Object-Class Value Name Reference 1225 TBD CCI Object-Type This document 1226 0 Reserved 1227 1 MPLS Label 1229 11.5. CCI Object Flag Field 1231 IANA is requested to create a new sub-registry to manage the Flag 1232 field of the CCI object called "CCI Object Flag Field". New values 1233 are to be assigned by Standards Action [RFC8126]. Each bit should be 1234 tracked with the following qualities: 1236 o Bit number (counting from bit 0 as the most significant bit) 1238 o Capability description 1240 o Defining RFC 1241 Two bits to be defined for the CCI Object flag field in this document 1242 as follows: 1244 Bit Description Reference 1245 0-13 Unassigned This document 1246 14 C Bit - PCC allocation This document 1247 15 O Bit - Specifies label This document 1248 is out label 1250 11.6. PCEP-Error Object 1252 IANA is requested to allocate new error types and error values within 1253 the "PCEP-ERROR Object Error Types and Values" sub-registry of the 1254 PCEP Numbers registry for the following errors: 1256 Error-Type Meaning 1257 ---------- ------- 1258 10 Reception of an invalid object. 1260 Error-value = TBD : Missing PCECC 1261 Capability sub-TLV 1262 19 Invalid operation. 1264 Error-value = TBD : Attempted PCECC 1265 operations when 1266 PCECC capability 1267 was not advertised 1268 Error-value = TBD : Stateful PCE 1269 capability was not 1270 advertised 1271 Error-value = TBD : Unknown Label 1272 6 Mandatory Object missing. 1274 Error-value = TBD : CCI object missing 1275 TBD PCECC failure. 1277 Error-value = TBD : Label out of range. 1278 Error-value = TBD : Instruction failed. 1279 Error-value = TBD : Invalid CCI. 1280 Error-value = TBD : Unable to allocate 1281 the specified CCI. 1283 12. Acknowledgments 1285 We would like to thank Robert Tao, Changjing Yan, Tieying Huang and 1286 Avantika for their useful comments and suggestions. 1288 13. References 1290 13.1. Normative References 1292 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1293 Requirement Levels", BCP 14, RFC 2119, 1294 DOI 10.17487/RFC2119, March 1997, 1295 . 1297 [RFC5440] Vasseur, JP., Ed. and JL. Le Roux, Ed., "Path Computation 1298 Element (PCE) Communication Protocol (PCEP)", RFC 5440, 1299 DOI 10.17487/RFC5440, March 2009, 1300 . 1302 [RFC7420] Koushik, A., Stephan, E., Zhao, Q., King, D., and J. 1303 Hardwick, "Path Computation Element Communication Protocol 1304 (PCEP) Management Information Base (MIB) Module", 1305 RFC 7420, DOI 10.17487/RFC7420, December 2014, 1306 . 1308 [RFC7525] Sheffer, Y., Holz, R., and P. Saint-Andre, 1309 "Recommendations for Secure Use of Transport Layer 1310 Security (TLS) and Datagram Transport Layer Security 1311 (DTLS)", BCP 195, RFC 7525, DOI 10.17487/RFC7525, May 1312 2015, . 1314 [RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for 1315 Writing an IANA Considerations Section in RFCs", BCP 26, 1316 RFC 8126, DOI 10.17487/RFC8126, June 2017, 1317 . 1319 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 1320 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 1321 May 2017, . 1323 [RFC8231] Crabbe, E., Minei, I., Medved, J., and R. Varga, "Path 1324 Computation Element Communication Protocol (PCEP) 1325 Extensions for Stateful PCE", RFC 8231, 1326 DOI 10.17487/RFC8231, September 2017, 1327 . 1329 [RFC8233] Dhody, D., Wu, Q., Manral, V., Ali, Z., and K. Kumaki, 1330 "Extensions to the Path Computation Element Communication 1331 Protocol (PCEP) to Compute Service-Aware Label Switched 1332 Paths (LSPs)", RFC 8233, DOI 10.17487/RFC8233, September 1333 2017, . 1335 [RFC8281] Crabbe, E., Minei, I., Sivabalan, S., and R. Varga, "Path 1336 Computation Element Communication Protocol (PCEP) 1337 Extensions for PCE-Initiated LSP Setup in a Stateful PCE 1338 Model", RFC 8281, DOI 10.17487/RFC8281, December 2017, 1339 . 1341 [RFC8408] Sivabalan, S., Tantsura, J., Minei, I., Varga, R., and J. 1342 Hardwick, "Conveying Path Setup Type in PCE Communication 1343 Protocol (PCEP) Messages", RFC 8408, DOI 10.17487/RFC8408, 1344 July 2018, . 1346 13.2. Informative References 1348 [RFC4655] Farrel, A., Vasseur, J., and J. Ash, "A Path Computation 1349 Element (PCE)-Based Architecture", RFC 4655, 1350 DOI 10.17487/RFC4655, August 2006, 1351 . 1353 [RFC7025] Otani, T., Ogaki, K., Caviglia, D., Zhang, F., and C. 1354 Margaria, "Requirements for GMPLS Applications of PCE", 1355 RFC 7025, DOI 10.17487/RFC7025, September 2013, 1356 . 1358 [RFC7399] Farrel, A. and D. King, "Unanswered Questions in the Path 1359 Computation Element Architecture", RFC 7399, 1360 DOI 10.17487/RFC7399, October 2014, 1361 . 1363 [RFC7491] King, D. and A. Farrel, "A PCE-Based Architecture for 1364 Application-Based Network Operations", RFC 7491, 1365 DOI 10.17487/RFC7491, March 2015, 1366 . 1368 [RFC7942] Sheffer, Y. and A. Farrel, "Improving Awareness of Running 1369 Code: The Implementation Status Section", BCP 205, 1370 RFC 7942, DOI 10.17487/RFC7942, July 2016, 1371 . 1373 [RFC8253] Lopez, D., Gonzalez de Dios, O., Wu, Q., and D. Dhody, 1374 "PCEPS: Usage of TLS to Provide a Secure Transport for the 1375 Path Computation Element Communication Protocol (PCEP)", 1376 RFC 8253, DOI 10.17487/RFC8253, October 2017, 1377 . 1379 [RFC8283] Farrel, A., Ed., Zhao, Q., Ed., Li, Z., and C. Zhou, "An 1380 Architecture for Use of PCE and the PCE Communication 1381 Protocol (PCEP) in a Network with Central Control", 1382 RFC 8283, DOI 10.17487/RFC8283, December 2017, 1383 . 1385 [I-D.ietf-pce-segment-routing] 1386 Sivabalan, S., Filsfils, C., Tantsura, J., Henderickx, W., 1387 and J. Hardwick, "PCEP Extensions for Segment Routing", 1388 draft-ietf-pce-segment-routing-16 (work in progress), 1389 March 2019. 1391 [I-D.ietf-teas-pcecc-use-cases] 1392 Zhao, Q., Li, Z., Khasanov, B., Dhody, D., Ke, Z., Fang, 1393 L., Zhou, C., Communications, T., Rachitskiy, A., and A. 1394 Gulida, "The Use Cases for Path Computation Element (PCE) 1395 as a Central Controller (PCECC).", draft-ietf-teas-pcecc- 1396 use-cases-04 (work in progress), July 2019. 1398 [I-D.ietf-pce-pcep-yang] 1399 Dhody, D., Hardwick, J., Beeram, V., and J. Tantsura, "A 1400 YANG Data Model for Path Computation Element 1401 Communications Protocol (PCEP)", draft-ietf-pce-pcep- 1402 yang-12 (work in progress), July 2019. 1404 [I-D.zhao-pce-pcep-extension-pce-controller-sr] 1405 Zhao, Q., Li, Z., Negi, M., and C. Zhou, "PCEP Procedures 1406 and Protocol Extensions for Using PCE as a Central 1407 Controller (PCECC) of SR-LSPs", draft-zhao-pce-pcep- 1408 extension-pce-controller-sr-04 (work in progress), 1409 February 2019. 1411 [I-D.li-pce-controlled-id-space] 1412 Li, C., Chen, M., Dong, J., Li, Z., Wang, A., Cheng, W., 1413 and C. Zhou, "PCE Controlled ID Space", draft-li-pce- 1414 controlled-id-space-03 (work in progress), June 2019. 1416 [I-D.sivabalan-pce-binding-label-sid] 1417 Sivabalan, S., Filsfils, C., Tantsura, J., Hardwick, J., 1418 Previdi, S., and C. Li, "Carrying Binding Label/Segment-ID 1419 in PCE-based Networks.", draft-sivabalan-pce-binding- 1420 label-sid-07 (work in progress), July 2019. 1422 [I-D.li-pce-sr-path-segment] 1423 Li, C., Chen, M., Cheng, W., Dong, J., Li, Z., Gandhi, R., 1424 and Q. Xiong, "Path Computation Element Communication 1425 Protocol (PCEP) Extension for Path Segment in Segment 1426 Routing (SR)", draft-li-pce-sr-path-segment-05 (work in 1427 progress), March 2019. 1429 Appendix A. Contributor Addresses 1431 Dhruv Dhody 1432 Huawei Technologies 1433 Divyashree Techno Park, Whitefield 1434 Bangalore, Karnataka 560066 1435 India 1437 EMail: dhruv.ietf@gmail.com 1439 Satish Karunanithi 1440 Huawei Technologies 1441 Divyashree Techno Park, Whitefield 1442 Bangalore, Karnataka 560066 1443 India 1445 EMail: satishk@huawei.com 1447 Adrian Farrel 1448 Juniper Networks, Inc 1449 UK 1451 EMail: adrian@olddog.co.uk 1453 Xuesong Geng 1454 Huawei Technologies 1455 China 1457 Email: gengxuesong@huawei.com 1459 Udayasree Palle 1461 EMail: udayasreereddy@gmail.com 1463 Katherine Zhao 1464 Futurewei Technologies 1466 EMail: katherine.zhao@futurewei.com 1468 Boris Zhang 1469 Telus Ltd. 1470 Toronto 1471 Canada 1473 EMail: boris.zhang@telus.com 1475 Alex Tokar 1476 Cisco Systems 1477 Slovak Republic 1479 EMail: atokar@cisco.com 1481 Authors' Addresses 1483 Quintin Zhao 1484 Huawei Technologies 1485 125 Nagog Technology Park 1486 Acton, MA 01719 1487 USA 1489 EMail: quintin.zhao@huawei.com 1491 Zhenbin Li 1492 Huawei Technologies 1493 Huawei Bld., No.156 Beiqing Rd. 1494 Beijing 100095 1495 China 1497 EMail: lizhenbin@huawei.com 1499 Mahendra Singh Negi 1500 Huawei Technologies 1501 Divyashree Techno Park, Whitefield 1502 Bangalore, Karnataka 560066 1503 India 1505 EMail: mahendrasingh@huawei.com 1507 Chao Zhou 1508 Cisco Systems 1510 EMail: chao.zhou@cisco.com