idnits 2.17.1 draft-zhao-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 : ---------------------------------------------------------------------------- ** The abstract seems to contain references ([RFC5440], [I-D.zhao-pce-central-controller-user-cases]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. == There are 2 instances of lines with non-RFC6890-compliant IPv4 addresses in the document. If these are example addresses, they should be changed. == There are 2 instances of lines with private range IPv4 addresses in the document. If these are generic example addresses, they should be changed to use any of the ranges defined in RFC 6890 (or successor): 192.0.2.x, 198.51.100.x or 203.0.113.x. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == Line 1519 has weird spacing: '... label base ...' -- The document date (March 16, 2016) is 2957 days in the past. Is this intentional? Checking references for intended status: Experimental ---------------------------------------------------------------------------- == Missing Reference: 'TBD' is mentioned on line 1466, but not defined == Outdated reference: A later version (-21) exists of draft-ietf-pce-stateful-pce-13 == Outdated reference: A later version (-11) exists of draft-ietf-pce-pce-initiated-lsp-05 == Outdated reference: A later version (-27) exists of draft-dhodylee-pce-pcep-ls-03 == Outdated reference: A later version (-06) exists of draft-ietf-pce-remote-initiated-gmpls-lsp-01 == Outdated reference: A later version (-15) exists of draft-ietf-spring-segment-routing-07 == Outdated reference: A later version (-25) exists of draft-ietf-isis-segment-routing-extensions-06 == Outdated reference: A later version (-27) exists of draft-ietf-ospf-segment-routing-extensions-06 == Outdated reference: A later version (-16) exists of draft-ietf-pce-segment-routing-06 == Outdated reference: A later version (-10) exists of draft-ietf-pce-lsp-setup-type-03 Summary: 1 error (**), 0 flaws (~~), 14 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: Experimental D. Dhody 5 Expires: September 17, 2016 Huawei Technologies 6 C. Zhou 7 Cisco Systems 8 March 16, 2016 10 PCEP Procedures and Protocol Extensions for Using PCE as a Central 11 Controller (PCECC) of LSPs 12 draft-zhao-pce-pcep-extension-for-pce-controller-03 14 Abstract 16 In certain networks deployment scenarios, service providers would 17 like to keep all the existing MPLS functionalities in both MPLS and 18 GMPLS while removing the complexity of existing signalling protocols 19 such as LDP and RSVP-TE. In 20 [I-D.zhao-pce-central-controller-user-cases], we propose to use the 21 PCE [RFC5440] as a central controller (PCECC) so that LSP can be 22 calculated/ signalled/initiated and label forwarding entries are 23 downloaded through a centralized PCE server to each network devices 24 along the LSP path while leveraging the existing PCE technologies as 25 much as possible. 27 This draft specify the procedures and PCEP protocol extensions for 28 using the PCE as the central controller and user cases where LSPs are 29 calculated/setup/initiated and label forwarding entries are 30 downloaded through extending the existing PCE architectures and PCEP. 32 This document also discuss the role of PCECC in Segment Routing (SR). 34 Status of This Memo 36 This Internet-Draft is submitted in full conformance with the 37 provisions of BCP 78 and BCP 79. 39 Internet-Drafts are working documents of the Internet Engineering 40 Task Force (IETF). Note that other groups may also distribute 41 working documents as Internet-Drafts. The list of current Internet- 42 Drafts is at http://datatracker.ietf.org/drafts/current/. 44 Internet-Drafts are draft documents valid for a maximum of six months 45 and may be updated, replaced, or obsoleted by other documents at any 46 time. It is inappropriate to use Internet-Drafts as reference 47 material or to cite them other than as "work in progress." 48 This Internet-Draft will expire on September 17, 2016. 50 Copyright Notice 52 Copyright (c) 2016 IETF Trust and the persons identified as the 53 document authors. All rights reserved. 55 This document is subject to BCP 78 and the IETF Trust's Legal 56 Provisions Relating to IETF Documents 57 (http://trustee.ietf.org/license-info) in effect on the date of 58 publication of this document. Please review these documents 59 carefully, as they describe your rights and restrictions with respect 60 to this document. Code Components extracted from this document must 61 include Simplified BSD License text as described in Section 4.e of 62 the Trust Legal Provisions and are provided without warranty as 63 described in the Simplified BSD License. 65 Table of Contents 67 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 68 1.1. Requirements Language . . . . . . . . . . . . . . . . . . 5 69 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5 70 3. PCECC Modes . . . . . . . . . . . . . . . . . . . . . . . . . 5 71 4. PCEP Requirements . . . . . . . . . . . . . . . . . . . . . . 6 72 5. Procedures for Using the PCE as the Central Controller 73 (PCECC) . . . . . . . . . . . . . . . . . . . . . . . . . . . 7 74 5.1. Stateful PCE Model . . . . . . . . . . . . . . . . . . . 7 75 5.2. New LSP Functions . . . . . . . . . . . . . . . . . . . . 7 76 5.3. PCECC Capability Advertisement . . . . . . . . . . . . . 8 77 5.4. PCEP session IP address and TEDB Router ID . . . . . . . 9 78 5.5. LSP Operations . . . . . . . . . . . . . . . . . . . . . 9 79 5.5.1. Basic PCECC Mode . . . . . . . . . . . . . . . . . . 9 80 5.5.1.1. PCECC LSP Setup . . . . . . . . . . . . . . . . . 9 81 5.5.1.2. Label Operations . . . . . . . . . . . . . . . . 11 82 5.5.2. PCE Initiated PCECC LSP . . . . . . . . . . . . . . . 14 83 5.5.3. PCECC LSP Update . . . . . . . . . . . . . . . . . . 16 84 5.5.4. PCECC LSP State Report . . . . . . . . . . . . . . . 19 85 5.5.5. PCECC Segment Routing (SR) . . . . . . . . . . . . . 19 86 5.5.5.1. PCECC SR-BE . . . . . . . . . . . . . . . . . . . 19 87 5.5.5.2. PCECC SR-TE . . . . . . . . . . . . . . . . . . . 20 88 6. PCEP messages . . . . . . . . . . . . . . . . . . . . . . . . 21 89 6.1. Label Operations . . . . . . . . . . . . . . . . . . . . 22 90 6.1.1. The PCLabelUpd message . . . . . . . . . . . . . . . 22 91 6.1.2. The PCInitiate message . . . . . . . . . . . . . . . 23 92 7. PCEP Objects . . . . . . . . . . . . . . . . . . . . . . . . 23 93 7.1. OPEN Object . . . . . . . . . . . . . . . . . . . . . . . 23 94 7.1.1. PCECC Capability TLV . . . . . . . . . . . . . . . . 23 95 7.2. PATH-SETUP-TYPE TLV . . . . . . . . . . . . . . . . . . . 24 96 7.3. Label Object . . . . . . . . . . . . . . . . . . . . . . 24 97 7.3.1. Address TLVs . . . . . . . . . . . . . . . . . . . . 25 98 7.4. FEC Object . . . . . . . . . . . . . . . . . . . . . . . 27 99 8. Security Considerations . . . . . . . . . . . . . . . . . . . 28 100 9. Manageability Considerations . . . . . . . . . . . . . . . . 29 101 9.1. Control of Function and Policy . . . . . . . . . . . . . 29 102 9.2. Information and Data Models . . . . . . . . . . . . . . . 29 103 9.3. Liveness Detection and Monitoring . . . . . . . . . . . . 29 104 9.4. Verify Correct Operations . . . . . . . . . . . . . . . . 29 105 9.5. Requirements On Other Protocols . . . . . . . . . . . . . 29 106 9.6. Impact On Network Operations . . . . . . . . . . . . . . 29 107 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 29 108 11. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 29 109 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 29 110 12.1. Normative References . . . . . . . . . . . . . . . . . . 29 111 12.2. Informative References . . . . . . . . . . . . . . . . . 30 112 Appendix A. Contributor Addresses . . . . . . . . . . . . . . . 32 113 Appendix B. Label Range Handling . . . . . . . . . . . . . . . . 32 114 B.1. Label Range Reservation . . . . . . . . . . . . . . . . . 33 115 B.2. The PCLRResv message . . . . . . . . . . . . . . . . . . 34 116 B.3. LABEL-RANGE Object . . . . . . . . . . . . . . . . . . . 35 117 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 36 119 1. Introduction 121 In certain network deployment scenarios, service providers would like 122 to have the ability to dynamically adapt to a wide range of 123 customer's requests for the sake of flexible network service 124 delivery, Software Defined Networks(SDN) has provides additional 125 flexibility in how the network is operated compared to the 126 traditional network. 128 The existing networking ecosystem has become awfully complex and 129 highly demanding in terms of robustness, performance, scalability, 130 flexibility, agility, etc. By migrating to the SDN enabled network 131 from the existing network, service providers and network operators 132 must have a solution which they can evolve easily from the existing 133 network into the SDN enabled network while keeping the network 134 services remain scalable, guarantee robustness and availability etc. 136 Taking the smooth transition between traditional network and the new 137 SDN enabled network into account, especially from a cost impact 138 assessment perspective, using the existing PCE components from the 139 current network to function as the central controller of the SDN 140 network is one choice, which not only achieves the goal of having a 141 centralized controller, but also leverage the existing PCE network 142 components. 144 The Path Computation Element communication Protocol (PCEP) provides 145 mechanisms for Path Computation Elements (PCEs) to perform route 146 computations in response to Path Computation Clients (PCCs) requests. 147 PCEP Extensions for PCE-initiated LSP Setup in a Stateful PCE Model 148 [I-D.ietf-pce-stateful-pce] describes a set of extensions to PCEP to 149 enable active control of MPLS-TE and GMPLS tunnels. 151 [I-D.ietf-pce-pce-initiated-lsp] describes the setup and tear down of 152 PCE-initiated LSPs under the active stateful PCE model, without the 153 need for local configuration on the PCC, thus allowing for a dynamic 154 MPLS network that is centrally controlled and deployed. 156 [I-D.ietf-pce-remote-initiated-gmpls-lsp] complements 157 [I-D.ietf-pce-pce-initiated-lsp] by addressing the requirements for 158 remote-initiated GMPLS LSPs. 160 Segment Routing (SR) technology leverage the source routing and 161 tunnelling paradigms. A source node can choose a path without 162 relying on hop-by-hop signalling protocols such as LDP or RSVP-TE. 163 Each path is specified as a set of "segments" advertised by link- 164 state routing protocols (IS-IS or OSPF). 165 [I-D.ietf-spring-segment-routing] provides an introduction to SR 166 technology. The corresponding IS-IS and OSPF extensions are 167 specified in [I-D.ietf-isis-segment-routing-extensions] and 168 [I-D.ietf-ospf-segment-routing-extensions], respectively. 170 A Segment Routed path (SR path) can be derived from an IGP Shortest 171 Path Tree (SPT). Segment Routed Traffic Engineering paths (SR-TE 172 paths) may not follow IGP SPT. Such paths may be chosen by a 173 suitable network planning tool and provisioned on the source node of 174 the SR-TE path. 176 It is possible to use a stateful PCE for computing one or more SR-TE 177 paths taking into account various constraints and objective 178 functions. Once a path is chosen, the stateful PCE can instantiate 179 an SR-TE path on a PCC using PCEP extensions specified in 180 [I-D.ietf-pce-pce-initiated-lsp] using the SR specific PCEP 181 extensions described in [I-D.ietf-pce-segment-routing]. 183 PCECC may further use PCEP protocol for SR label distribution instead 184 of IGP extensions with some benefits. 186 Current MPLS label has local meaning. That is, MPLS label is always 187 allocated by the downstream node to the upstream node. Then the MPLS 188 label is only identified by the neighbouring upstream node and 189 downstream node. The label allocation is done locally and signalled 190 through the LDP/RSVP-TE/BGP protocol. To ease the label allocation 191 and signalling mechanism, PCE can be conveniently used as a central 192 controller with Label download capability. Further PCE can also be 193 used to manage the label range and Segment Routing Global Block 194 (SRGB) etc. 196 The PCECC solution introduced in 197 [I-D.zhao-pce-central-controller-user-cases] allow for a dynamic MPLS 198 network that is eventually controlled and deployed without the 199 deployment of RSVP-TE protocol or extended IGP protocol with node/ 200 adjacency segment identifiers signalling capability while providing 201 all the key MPLS functionalities needed by the service providers. 203 This draft specify the procedures and PCEP protocol extensions for 204 using the PCE as the central controller and user cases where LSPs are 205 calculated/setup/initiated/downloaded through extending the existing 206 PCE architectures and PCEP. 208 1.1. Requirements Language 210 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 211 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 212 document are to be interpreted as described in [RFC2119]. 214 2. Terminology 216 The following terminology is used in this document. 218 IGP: Interior Gateway Protocol. Either of the two routing 219 protocols, Open Shortest Path First (OSPF) or Intermediate System 220 to Intermediate System (IS-IS). 222 PCC: Path Computation Client: any client application requesting a 223 path computation to be performed by a Path Computation Element. 225 PCE: Path Computation Element. An entity (component, application, 226 or network node) that is capable of computing a network path or 227 route based on a network graph and applying computational 228 constraints. 230 TE: Traffic Engineering. 232 3. PCECC Modes 234 The following PCECC modes are supported - 236 o Basic PCECC. 238 o PCECC SR. 240 * PCECC SR-BE (Best Effort). 242 * PCECC SR-TE (Traffic Engineered). 244 In basic PCECC mode, the forwarding is similar to RSVP-TE signalled 245 LSP without the RSVP-TE signalling. The PCECC allocates and download 246 the label entries along the LSP. The rest of processing is similar 247 to the existing stateful PCE mechanism. 249 In case of SR, there are two modes for SR-BE and SR-TE. For SR-BE, 250 the forwarding is similar to LDP LSP without LDP signalling or IGP-SR 251 extension. The SR Node label are allocated and distributed in the 252 domain centrally by the PCE via PCEP. Each node (PCC) relies on 253 local IGP for the nexthop calculation. For SR-TE, the forwarding 254 uses label stack similar to IGP based SR-TE without IGP-SR extension. 255 The SR node and adjacency labels are allocated and distributed in the 256 domain centrally by the PCE via PCEP by PCECC. Rest of the 257 processing is similar to existing stateful PCE with SR mechanism. 259 4. PCEP Requirements 261 Following key requirements associated PCECC should be considered when 262 designing the PCECC based solution: 264 1. PCEP speaker supporting this draft MUST have the capability to 265 advertise its PCECC capability to its peers. 267 2. PCEP speaker not supporting this draft MUST be able to reject 268 PCECC related message with a reason code that indicates no 269 support for PCECC. 271 3. PCEP SHOULD provide a means to identify PCECC based LSP in the 272 PCEP messages. 274 4. PCEP SHOULD provide a means to update (or cleanup) the label- 275 download or label-map entry to the PCC. 277 5. Path Computation Client (PCC) supporting this draft MAY support a 278 capability to communicate local label range or global label range 279 or both to PCE. (see xref target="sec_lr"/>) 281 6. Path Computation Element (PCE) supporting this draft MAY have the 282 capability to negotiate a global label range for a group of 283 clients and communicate the final global label range to PCC. (see 284 xref target="sec_lr"/>) 286 5. Procedures for Using the PCE as the Central Controller (PCECC) 288 5.1. Stateful PCE Model 290 Active stateful PCE is described in [I-D.ietf-pce-stateful-pce]. PCE 291 as a central controller (PCECC) reuses existing Active stateful PCE 292 mechanism as much as possible to control the LSP. 294 5.2. New LSP Functions 296 This document defines the following new PCEP messages and extends the 297 existing messages to support PCECC: 299 (PCRpt): a PCEP message described in [I-D.ietf-pce-stateful-pce]. 300 PCRpt message MAYBE used to send PCECC LSP Reports. 302 (PCInitiate): a PCEP message described in 303 [I-D.ietf-pce-pce-initiated-lsp]. PCInitiate message is used to 304 setup PCE-Initiated LSP based on PCECC mechanism. 306 (PCUpd): a PCEP message described in [I-D.ietf-pce-stateful-pce]. 307 PCUpd message is used to send PCECC LSP Update. 309 Per Node Label Operations: a PCEP mechanism to instruct label 310 operations on each node. An approach to this could be - 312 (PCLabelUpd): a new PCEP message sent by a PCE to a PCC to 313 download or cleanup the Label entry. The PCLabelUpd message 314 described in Section 6.1.1. 316 (PCInitiate): reuse an existing PCEP message described in 317 [I-D.ietf-pce-pce-initiated-lsp]. PCInitiate message. 319 The new LSP functions defined in this document are mapped onto the 320 messages as shown in the following table. 322 +----------------------------------------+--------------------------+ 323 | Function | Message | 324 +----------------------------------------+--------------------------+ 325 | PCECC Capability advertisement | Open | 326 | Label entry Update | PCLabelUpd/PCInitiate | 327 | Label entry Cleanup | PCLabelUpd/PCInitiate | 328 | PCECC Initiated LSP | PCInitiate | 329 | PCECC LSP Update | PCUpd | 330 | PCECC LSP State Report | PCRpt | 331 | PCECC LSP Delegation | PCRpt | 332 +----------------------------------------+--------------------------+ 334 5.3. PCECC Capability Advertisement 336 During PCEP Initialization Phase, PCEP Speakers (PCE or PCC) 337 advertise their support of PCECC extensions. A PCEP Speaker includes 338 the "PCECC Capability" TLV, described in Section 7.1.1 of this 339 document, in the OPEN Object to advertise its support for PCECC 340 extensions. 342 The presence of the PCECC Capability TLV in PCC's OPEN Object 343 indicates that the PCC is willing to function as a PCECC client. 345 The presence of the PCECC Capability TLV in PCE's OPEN message 346 indicates that the PCE is interested in function as a PCECC server. 348 The PCEP protocol extensions for PCECC MUST NOT be used if one or 349 both PCEP Speakers have not included the PCECC Capability TLV in 350 their respective OPEN message. If the PCEP Speakers support the 351 extensions of this draft but did not advertise this capability then a 352 PCErr message with Error-Type=19(Invalid Operation) and Error- 353 Value=[TBD] (Attempted LSP setup/download/label-range reservation if 354 PCECC capability was not advertised) will be generated and the PCEP 355 session will be terminated. 357 A PCC or a PCE MUST include both PCECC-CAPABILITY TLV and STATEFUL- 358 PCE-CAPABILITY TLV ([I-D.ietf-pce-stateful-pce]) in OPEN Object to 359 support the extensions defined in this document. If PCECC-CAPABILITY 360 TLV is advertised and STATEFUL-PCE-CAPABILITY TLV is not advertised 361 in OPEN Object, it SHOULD send a PCErr message with Error-Type=19 362 (Invalid Operation) and Error-value=[TBD](stateful PCE capability was 363 not advertised) and terminate the session. 365 PCECC-CAPABILITY TLV includes a S-bit to indicate support for PCECC- 366 SR. A PCEP speaker MUST set S-bit in PCECC-CAPABILITY TLV and 367 include SR-PCE-CAPABILITY TLV ([I-D.ietf-pce-segment-routing]) in 368 OPEN Object to support the PCECC SR-TE extensions defined in this 369 document. If S-bit is set in PCECC-CAPABILITY TLV and SR-PCE- 370 CAPABILITY TLV is not advertised in OPEN Object, PCEP speaker SHOULD 371 send a PCErr message with Error-Type=19 (Invalid Operation) and 372 Error-value=[TBD](SR capability was not advertised) and terminate the 373 session. 375 5.4. PCEP session IP address and TEDB Router ID 377 PCE may construct its TEDB by participating in the IGP ([RFC3630] 378 and [RFC5305] for MPLS-TE; [RFC4203] and [RFC5307] for GMPLS). An 379 alternative is offered by BGP-LS [I-D.ietf-idr-ls-distribution] and 380 [I-D.dhodylee-pce-pcep-ls]. 382 PCEP [RFC5440] speaker MAY use any IP address while creating a TCP 383 session. It is important to link the session IP address with the 384 Router ID in TEDB for successful PCECC operations. 386 During PCEP Initialization Phase, PCC SHOULD advertise the TE mapping 387 information. Thus a PCC includes the "Node Attributes TLV" 388 [I-D.dhodylee-pce-pcep-ls] with "IPv4/IPv6 Router-ID of Local Node", 389 in the OPEN Object for this purpose. [I-D.ietf-idr-ls-distribution] 390 describes the usage as auxiliary Router-IDs that the IGP might be 391 using, e.g., for TE purposes. If there are more than one auxiliary 392 Router-ID of a given type, then multiple TLVs are used to encode 393 them. 395 If "IPv4/IPv6 Router-ID" TLV is not present, the TCP session IP 396 address is directly used for the mapping purpose. 398 5.5. LSP Operations 400 The PCEP messages pertaining to PCECC MUST include PATH-SETUP-TYPE 401 TLV [I-D.ietf-pce-lsp-setup-type] in the SRP object to clearly 402 identify the PCECC LSP is intended. 404 5.5.1. Basic PCECC Mode 406 5.5.1.1. PCECC LSP Setup 408 In order to setup a LSP based on PCECC mechanism, a PCC MUST delegate 409 the LSP by sending a PCRpt message with Path Setup Type set for basic 410 PCECC (see Section 7.2) and D (Delegate) flag (see 411 [I-D.ietf-pce-stateful-pce]) set in the LSP object. 413 LSP-IDENTIFIER TLV MAY be included for PCECC LSP, the LSP-ID SHOULD 414 be generated by the PCE for PCECC LSP. In the first PCRpt message of 415 PCECC LSP, LSP ID of LSP-IDENTIFIER TLV is set to zero. 417 When a PCE receives PCRpt message with P and D flags set, it MAY 418 generates LSP ID; calculates the path and assigns labels along the 419 path; and setups the path by sending PCLabelUpd or PCInitiate message 420 to each node along the path of the LSP. 422 In response to the delegate PCRpt message, the PCE SHOULD send the 423 PCUpd message with the same PLSP-ID to the Ingress PCC. 425 The PCECC LSPs MUST be delegated to a PCE at all times. 427 LSP deletion operation for PCECC LSP is same as defined in 428 [I-D.ietf-pce-stateful-pce]. If the PCE receives PCRpt message for 429 LSP deletion then it does Label cleanup operation as described in 430 Section 5.5.1.2.1.2 for the corresponding LSP. 432 The Basic PCECC LSP setup sequence is as shown below using a new 433 message PCLabelUpd. 435 +-------+ +-------+ 436 |PCC | | PCE | 437 |Ingress| +-------+ 438 +------| | | 439 | PCC +-------+ | 440 | Transit| | | 441 +------| | |--- PCRpt,PLSP-ID=1, P=1, D=1 --->| PCECC LSP 442 |PCC +--------+ | (LSP ID=0) |(LSPID=1) 443 |Egress | | | | 444 +--------+ | | | 445 | | | | 446 |<------ PCLabelUpd,PLSP-ID=1 ------------------ | Label 447 | | | (LSP ID=1) | download 448 | | | | 449 | |<----- PCLabelUpd,PLSP-ID=1 ----------- | Label 450 | | | (LSP ID=1) | download 451 | | | | 452 | | |<--- PCLabelUpd,PLSP-ID=1 ------- | Label 453 | | | (LSP ID=1) | download 454 | | | | 455 | | |<-- PCUpd,PLSP-ID=1, P=1, D=1 ---- | PCECC LSP 456 | | | (LSP ID=1) | Update 457 | | | | 459 Figure 2: Using PCLabelUpd For Label Operations 460 +-------+ +-------+ 461 |PCC | | PCE | 462 |Ingress| +-------+ 463 +------| | | 464 | PCC +-------+ | 465 | Transit| | | 466 +------| | |--- PCRpt,PLSP-ID=1, P=1, D=1 --->| PCECC LSP 467 |PCC +--------+ | (LSP ID=0) |(LSPID=1) 468 |Egress | | | | 469 +--------+ | | | 470 | | | | 471 |<------ PCInitiate,PLSP-ID=1 ------------------ | Label 472 | | | (LSP ID=1) | download 473 |------- PCRpt ---------------------------------->| 474 | | | | 475 | |<----- PCInitiate,PLSP-ID=1 ----------- | Label 476 | | | (LSP ID=1) | download 477 | |----- -PCRpt---------------------------->| 478 | | | | 479 | | |<--- PCInitiate,PLSP-ID=1 ------- | Label 480 | | | (LSP ID=1) | download 481 | | |-----PCRpt------------------------>| 482 | | | | 483 | | |<-- PCUpd,PLSP-ID=1, P=1, D=1 ---- | PCECC LSP 484 | | | (LSP ID=1) | Update 485 | | | | 487 Some open issue - 489 * PCC send PCRpt messages for each PCInitiate message? 490 * Should one use PCInitiate at Ingress too? How to link this 491 with existing tunnel at the PCC? 493 Figure 3: Using PCInitiate For Label Operations 495 The PCECC LSP are considered to be 'up' by default. The Ingress MAY 496 further choose to deploy a data plane check mechanism and report the 497 status back to the PCE via PCRpt message. 499 5.5.1.2. Label Operations 501 5.5.1.2.1. Via a new PCLabelUpd Message 503 The new label operations in PCEP can be done via a new message and by 504 defining new PCEP Objects for Label operations and FEC. 506 5.5.1.2.1.1. Label Download 508 In order to setup an LSP based on PCECC, the PCE sends a PCLabelUpd 509 message to each node of the LSP to download the Label entry as 510 described in Section 5.5.1.1. 512 The LSP object in PCLabelUpd MUST include the LSP-IDENTIFIER TLV. 514 If a node (PCC) receives a PCLabelUpd message but failed to download 515 the Label entry, it MUST send a PCErr message with Error-type=[TBD] 516 (label download failed) and Error-value=[TBD]. 518 Two new PCEP objects for LABEL and FEC are defined in Section 7.3 and 519 Section 7.4 to encode the Label operations and its associated FEC. 521 5.5.1.2.1.2. Label Cleanup 523 In order to delete an LSP based on PCECC, the PCE sends a PCLabelUpd 524 message to each node along the path of the LSP to cleanup the Label 525 entry. 527 If the PCC receives a PCLabelUpd message but does not recognize the 528 label, the PCC MUST generate a PCErr message with Error-Type 529 19(Invalid operation) and Error-Value=3, "Unknown Label". 531 The R flag in SRP object defined in [I-D.ietf-pce-pce-initiated-lsp] 532 specifies the deletion of Label Entry in the new PCLabelUpd message. 534 +-------+ +-------+ 535 |PCC | | PCE | 536 |Ingress| +-------+ 537 +------| | | 538 | PCC +-------+ | 539 | Transit| | | 540 +------| | |--- PCRpt,PLSP-ID=1,P=1,D=1,R=1--->| PCECC LSP 541 |PCC +--------+ | (LSP ID=1) | remove 542 |Egress | | | | 543 +--------+ | | | 544 | | | | 545 |<------ PCLabelUpd, PLSP-ID=1 ------------------ | Label 546 | | | (LSP ID=1, R=1) | cleanup 547 | | | | 548 | |<----- PCLabelUpd, PLSP-ID=1 ----------- | Label 549 | | | (LSP ID=1, R=1) | cleanup 550 | | | | 551 | | |<--- PCLabelUpd, PLSP-ID=1 ------- | Label 552 | | | (LSP ID=1, R=1) | cleanup 553 | | | | 555 5.5.1.2.2. Via an existing PCInitiate Message 557 The new label operations in PCEP can be done via existing PCInitiate 558 message and by reusing PCEP Objects (and subobjects) to encode Label 559 operations and FEC. A TE LSP can be envisioned as a series of 560 "cross-connects" and ERO in the PCInitiate message can be used to 561 indicate each such cross-connect along the path. The use of 562 PCInitiate message would also require each node to send the PCRpt 563 message. The handling of PLSP-ID, LSP Identifiers, Symbolic path 564 name would need to be taken into consideration. 566 The PATH-SETUP-TYPE TLV [I-D.ietf-pce-lsp-setup-type] in the SRP 567 object can identify the PCECC LSP. 569 5.5.1.2.2.1. Label Download 571 In order to setup an LSP based on PCECC, the PCE sends a PCInitiate 572 message to each node of the LSP to download the Label entry as 573 described in Section 5.5.1.1 represented as a "cross-connect". 575 If a node (PCC) receives a PCInitiate message with setup type 576 indicated as PCECC, it should not try to initiate a complete tunnel. 577 The error-handling and other processing would remain unchanged. 579 The ERO in the PCInitiate message would indicate the cross-connect as 580 {input interface, input label, output interface, output label}. For 581 Egress only input interface/label would be present and for Ingress 582 only output interface/label. For Ingress either PCInitiate is used 583 or the same information can be put in PCUpd message as well. 585 5.5.1.2.2.2. Label Cleanup 587 In order to delete an LSP based on PCECC, one can use existing 588 PCInitiate message (with R flag) to each node along the path of the 589 LSP to cleanup the Label entry. The R flag in SRP object defined in 590 [I-D.ietf-pce-pce-initiated-lsp] is used during cleanup. 592 The error-handling and other processing would remain unchanged. 594 5.5.2. PCE Initiated PCECC LSP 596 The LSP Instantiation operation is same as defined in 597 [I-D.ietf-pce-pce-initiated-lsp]. 599 In order to setup a PCE Initiated LSP based on PCECC mechanism, a PCE 600 sends PCInitiate message with Path Setup Type set for basic PCECC 601 (see Section 7.2) to the Ingress PCC. 603 The Ingress PCC MUST also set D (Delegate) flag (see 604 [I-D.ietf-pce-stateful-pce]) and C (Create) flag (see 605 [I-D.ietf-pce-pce-initiated-lsp]) in LSP object of PCRpt message. 606 The PCC responds with first PCRpt message with the status as "GOING- 607 UP" and assigned PLSP-ID. 609 The rest of the PCECC LSP setup operations are same as those 610 described in Section 5.5.1.1. 612 The LSP deletion operation for PCE Initiated PCECC LSP is same as 613 defined in [I-D.ietf-pce-pce-initiated-lsp]. The PCE should further 614 perform Label entry cleanup operation as described in 615 Section 5.5.1.2.1.2 for the corresponding LSP. 617 The PCE Initiated PCECC LSP setup sequence is shown below using a new 618 PCLabelUpd message. 620 +-------+ +-------+ 621 |PCC | | PCE | 622 |Ingress| +-------+ 623 +------| | | 624 | PCC +-------+ | 625 | Transit| | | 626 +------| | |<---PCInitiate,PLSP-ID=0,P=1,D=1---| PCECC LSP 627 |PCC +--------+ | | Initiate 628 |Egress | | |--- PCRpt,PLSP-ID=2,P=1,D=1,C=1--->| PCECC LSP 629 +--------+ | | (LSP ID=0,GOING-UP) |(LSPID=2 630 | | | | assigned) 631 |<------ PCLabelUpd, PLSP-ID=2 ------------------ | Label 632 | | | (LSP ID=2) | download 633 | | | | 634 | |<----- PCLabelUpd, PLSP-ID=2 ----------- | Label 635 | | | (LSP ID=2) | download 636 | | | | 637 | | |<--- PCLabelUpd, PLSP-ID=2 ------- | Label 638 | | | (LSP ID=2) | download 639 | | | | 640 | | |<-- PCUpd, PLSP-ID=2, P=1, D=1---- | PCECC LSP 641 | | | (LSP ID=2) | Update 642 | | | | 644 The PCE Initiated PCECC LSP setup sequence is shown below using 645 existing PCInitiate message. 647 +-------+ +-------+ 648 |PCC | | PCE | 649 |Ingress| +-------+ 650 +------| | | 651 | PCC +-------+ | 652 | Transit| | | 653 +------| | |<---PCInitiate,PLSP-ID=0,P=1,D=1---| PCECC LSP 654 |PCC +--------+ | | Initiate 655 |Egress | | |--- PCRpt,PLSP-ID=2,P=1,D=1,C=1--->| PCECC LSP 656 +--------+ | | (LSP ID=0,GOING-UP) |(LSPID=2 657 | | | | assigned) 658 |<------ PCInitiate, PLSP-ID=2 ------------------ | Label 659 | | | (LSP ID=2) | download 660 |------- PCRpt ---------------------------------->| 661 | | | | 662 | |<----- PCInitiate, PLSP-ID=2 ----------- | Label 663 | | | (LSP ID=2) | download 664 | |----- -PCRpt---------------------------->| 665 | | | | 666 | | |<--- PCInitiate, PLSP-ID=2 ------- | Label 667 | | | (LSP ID=2) | download 668 | | |-----PCRpt------------------------>| 669 | | | | 670 | | |<-- PCUpd, PLSP-ID=2, P=1, D=1---- | PCECC LSP 671 | | | (LSP ID=2) | Update 672 | | | | 674 Some open issue - 676 * PCC send PCRpt messages for each PCInitiate message? 677 * How to link 2 PCInitiate message at Ingress one to initiate the 678 full tunnel, and one to download the cross-connect (label)? 680 5.5.3. PCECC LSP Update 682 Incase of a modification of PCECC LSP with a new path, a PCE sends a 683 PCUpd message to the Ingress PCC. 685 When a PCC receives a PCUpd message for an existing LSP, a PCC MAY 686 follow the make-before-break procedure i.e. first download labels for 687 the updated LSP and then switch traffic, before cleaning up the old 688 labels. On successful traffic switch over to the new LSP, PCC sends 689 a PCRpt message to the PCE for the deletion of old LSP. Further the 690 PCE does cleanup operation for the old LSP as described in 691 Section 5.5.1.2.1.2. 693 The PCECC LSP Update and make-before-break sequence is shown below 694 using a new PCLabelUpd message. 696 +-------+ +-------+ 697 |PCC | | PCE | 698 |Ingress| +-------+ 699 +------| | | 700 | PCC +-------+ | 701 | Transit| | | 702 +------| | | | 703 |PCC +--------+ | | 704 |Egress | | | | 705 +--------+ | | | 706 | | | | Modify LSP 707 |<------ PCLabelUpd, PLSP-ID=1 ------------------ | (LSPID=3 708 | | | (LSP ID=3) | assigned) 709 | | | | 710 | |<----- PCLabelUpd, PLSP-ID=1 ----------- | Label 711 | | | (LSP ID=3) | download 712 | | | | 713 | | |<--- PCLabelUpd, PLSP-ID=1 ------- | Label 714 | | | (LSP ID=3) | download 715 | | | | 716 | | |<-- PCUpd, PLSP-ID=1, P=1, D=1---- | PCECC 717 | | | (LSP ID=3) | LSP Update 718 | | | | 719 | | |--- PCRpt,PLSP-ID=1,P=1,D=1,R=1--->| Delete 720 | | | (LSP ID=1) | old LSP 721 | | | | 722 |<------ PCLabelUpd, PLSP-ID=1 ------------------ | Label 723 | | | (LSP ID=1, R=1) | cleanup 724 | | | | 725 | |<----- PCLabelUpd, PLSP-ID=1 ----------- | Label 726 | | | (LSP ID=1, R=1) | cleanup 727 | | | | 728 | | |<--- PCLabelUpd, PLSP-ID=1 ------- | Label 729 | | | (LSP ID=1, R=1) | cleanup 731 The PCECC LSP Update and make-before-break sequence is shown below 732 using existing PCInitiate message. 734 +-------+ +-------+ 735 |PCC | | PCE | 736 |Ingress| +-------+ 737 +------| | | 738 | PCC +-------+ | 739 | Transit| | | 740 +------| | | | 741 |PCC +--------+ | | 742 |Egress | | | | 743 +--------+ | | | 744 | | | | Modify LSP 745 |<------ PCInitiate, PLSP-ID=1 ------------------ | (LSPID=3 746 | | | (LSP ID=3) | assigned) 747 |------- PCRpt ---------------------------------->| 748 | | | | 749 | |<----- PCInitiate, PLSP-ID=1 ----------- | Label 750 | | | (LSP ID=3) | download 751 | |----- -PCRpt---------------------------->| 752 | | | | 753 | | |<--- PCInitiate, PLSP-ID=1 ------- | Label 754 | | | (LSP ID=3) | download 755 | | |-----PCRpt------------------------>| 756 | | | | 757 | | |<-- PCUpd, PLSP-ID=1, P=1, D=1---- | PCECC 758 | | | (LSP ID=3) | LSP Update 759 | | | | 760 | | |--- PCRpt,PLSP-ID=1,P=1,D=1,R=1--->| Delete 761 | | | (LSP ID=1) | old LSP 762 | | | | 763 |<------ PCInitiate, PLSP-ID=1 ------------------ | Label 764 | | | (LSP ID=1, R=1) | cleanup 765 |------- PCRpt ---------------------------------->| 766 | | | | 767 | |<----- PCInitiate, PLSP-ID=1 ----------- | Label 768 | | | (LSP ID=1, R=1) | cleanup 769 | |----- -PCRpt---------------------------->| 770 | | | | 771 | | |<--- PCInitiate, PLSP-ID=1 ------- | Label 772 | | | (LSP ID=1, R=1) | cleanup 773 | | |-----PCRpt------------------------>| 775 The modified PCECC LSP are considered to be 'up' by default. The 776 Ingress MAY further choose to deploy a data plane check mechanism and 777 report the status back to the PCE via PCRpt message. 779 5.5.4. PCECC LSP State Report 781 As mentioned before, an Ingress PCC MAY choose to apply any OAM 782 mechanism to check the status of LSP in the Data plane and MAY 783 further send its status in PCRpt message to the PCE. 785 5.5.5. PCECC Segment Routing (SR) 787 Segment Routing (SR) as described in 788 [I-D.ietf-spring-segment-routing] depends on "segments" that are 789 advertised by Interior Gateway Protocols (IGPs). The SR-node 790 allocates and advertises the SID (node, adj etc) and flood via the 791 IGP. This document proposes a new mechanism where PCE allocates the 792 SID (label) centrally and uses PCEP to advertise the SID. In some 793 deployments PCE (and PCEP) are better suited than IGP because of 794 centralized nature of PCE and direct TCP based PCEP session to the 795 node. 797 PCECC SR capability (S-bit) MUST be advertised in Open message. 799 [EDITOR NOTE: Currently only the use of a new message PCLabelUpd is 800 discussed in this section, the editors feel that use of existing 801 PCInitiate message for SR node and adjacency label would be 802 problematic.] 804 5.5.5.1. PCECC SR-BE 806 Each node (PCC) is allocated a node-SID (label) by the PCECC. The 807 PCECC sends PCLabelUpd to update the label map of each node to all 808 the nodes in the domain. The TE router ID is determined from the 809 TEDB or from "IPv4/IPv6 Router-ID" Sub-TLV 810 [I-D.dhodylee-pce-pcep-ls], in the OPEN Object Section 5.4. 812 It is RECOMMENDED that PCEP session with PCECC SR capability to use a 813 different session IP address during TCP session establishment than 814 the node Router ID in TEDB, to make sure that the PCEP session does 815 not get impacted by the SR-BE node label maps (Section 5.4). 817 On receiving the label map, each node (PCC) uses the local 818 information to determine the next-hop and download the label 819 forwarding instructions accordingly. The PCLabelUpd message in this 820 case MUST NOT have LSP object but use the new FEC object. 822 +-------+ +-------+ 823 |PCC | | PCE | 824 |3.3.3.3| +-------+ 825 +------| | | 826 | PCC +-------+ | 827 | 2.2.2.2| | | 828 +------| | | | 829 |PCC +--------+ | | 830 |1.1.1.1 | | | | 831 +--------+ | | | 832 | | | | 833 |<------ PCLabelUpd, FEC=1.1.1.1----------------- | Label Map 834 | | | Label=X | update 835 |Find | | | 836 |Nexthop|<----- PCLabelUpd, FEC=1.1.1.1---------- | Label Map 837 |locally| | Label=X | update 838 | | | | 839 | | |<--- PCLabelUpd, FEC=1.1.1.1------ | Label Map 840 | | | Label=X | update 841 | | | | 843 The forwarding behaviour and the end result is similar to IGP based 844 "Node-SID" in SR. Thus, from anywhere in the domain, it enforces the 845 ECMP-aware shortest-path forwarding of the packet towards the related 846 node. 848 PCE relies on the Node label cleanup using the same PCLabelUpd 849 message. 851 5.5.5.2. PCECC SR-TE 853 A Segment Routed Best Effort path (SR-BE path) can be derived from an 854 IGP Shortest Path Tree (SPT) as explained above. On the other hand, 855 SR-TE paths may not follow IGP SPT. Such paths may be chosen by a 856 PCE and provisioned on the source node of the SR-TE path. 858 [I-D.ietf-pce-segment-routing] extends PCEP to allow a stateful PCE 859 to compute and initiate SR-TE paths, as well as a PCC to request a 860 path subject to certain constraint(s) and optimization criteria in SR 861 networks. 863 For SR-TE, apart from node-SID, Adj-SID is used where each adjacency 864 is allocated an Adj-SID (label) by the PCECC. The PCECC sends 865 PCLabelUpd to update the label map of each Adj to the corresponding 866 nodes in the domain. Each node (PCC) download the label forwarding 867 instructions accordingly. Similar to SR-BE, the PCLabelUpd message 868 in this case MUST NOT have LSP object but use the new FEC object. 870 +-------+ +-------+ 871 |PCC | | PCE | 872 |3.3.3.3| +-------+ 873 +------| | | 874 | PCC +-------+ | 875 | 2.2.2.2| | | 876 +------| | | | 877 |PCC +--------+ | | 878 |1.1.1.1 | | | | 879 +--------+ | | | 880 | | | | 881 |<------ PCLabelUpd, FEC=10.1.1.1 / ------------- | Label Map 882 | | | 10.1.1.2 | update 883 | | | Label=A | 884 | | | | 885 | |<----- PCLabelUpd, FEC=10.1.1.2--------- | Label Map 886 | | | 10.1.1.1 | update 887 | | | Label=B | 888 | | | | 890 The forwarding behavior and the end result is similar to IGP based 891 "Adj-SID" in SR. 893 The Path Setup Type for segment routing MUST be set for PCECC SR-TE 894 (see Section 7.2). All PCEP procedures and mechanism are similar to 895 [I-D.ietf-pce-segment-routing]. 897 PCE relies on the Adj label cleanup using the same PCLabelUpd 898 message. 900 6. PCEP messages 902 As defined in [RFC5440], a PCEP message consists of a common header 903 followed by a variable-length body made of a set of objects that can 904 be either mandatory or optional. An object is said to be mandatory 905 in a PCEP message when the object must be included for the message to 906 be considered valid. For each PCEP message type, a set of rules is 907 defined that specify the set of objects that the message can carry. 908 An implementation MUST form the PCEP messages using the object 909 ordering specified in this document. 911 LSP-IDENTIFIERS TLV MAY be included in the LSP object for PCECC LSP. 913 6.1. Label Operations 915 6.1.1. The PCLabelUpd message 917 A new Label Update Message (also referred to as PCLabelUpd) is a PCEP 918 message sent by a PCE to a PCC to download label or update the label 919 map. The same message is also used to cleanup the Label entry. The 920 Message-Type field of the PCEP common header for the PCLabelUpd 921 message is set to [TBD]. 923 The format of the PCLabelUpd message is as follows: 925 ::= 926 927 Where: 928 ::= 929 [] 931 ::= (|) 933 Where: 934 ::= 935 936 938 ::= 939