idnits 2.17.1 draft-ietf-pce-pcep-stateful-pce-gmpls-13.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 : ---------------------------------------------------------------------------- ** There are 2 instances of too long lines in the document, the longest one being 1 character in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (April 24, 2020) is 1461 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) No issues found here. Summary: 1 error (**), 0 flaws (~~), 1 warning (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 PCE Working Group Y. Lee (Editor) 2 Internet-Draft Samsung 3 Intended status: Standards Track H. Zheng (Editor) 4 Expires: October 24, 2020 Huawei 5 O. G. de Dios 6 V. Lopez 7 Telefonica 8 Z. Ali 9 Cisco Systems 10 April 24, 2020 12 Path Computation Element (PCE) Protocol Extensions for Stateful PCE 13 Usage in GMPLS-controlled Networks 15 draft-ietf-pce-pcep-stateful-pce-gmpls-13 17 Abstract 19 The Path Computation Element (PCE) facilitates Traffic Engineering 20 (TE) based path calculation in large, multi-domain, multi-region, or 21 multi-layer networks. The PCE communication Protocol (PCEP) has been 22 extended to support stateful PCE functions where the PCE retains 23 information about the paths already present in the network, but 24 those extensions are technology-agnostic. This memo provides 25 extensions required for PCEP so as to enable the usage of a stateful 26 PCE capability in GMPLS-controlled networks. 28 Status of this Memo 30 This Internet-Draft is submitted to IETF in full conformance with 31 the provisions of BCP 78 and BCP 79. 33 Internet-Drafts are working documents of the Internet Engineering 34 Task Force (IETF), its areas, and its working groups. Note that 35 other groups may also distribute working documents as Internet- 36 Drafts. The list of current Internet-Drafts is at 37 https://datatracker.ietf.org/drafts/current/. 39 Internet-Drafts are draft documents valid for a maximum of six 40 months and may be updated, replaced, or obsoleted by other documents 41 at any time. It is inappropriate to use Internet-Drafts as 42 reference material or to cite them other than as "work in progress." 43 The list of current Internet-Drafts can be accessed at 44 http://www.ietf.org/ietf/1id-abstracts.txt. 46 The list of Internet-Draft Shadow Directories can be accessed at 47 http://www.ietf.org/shadow.html. 49 This Internet-Draft will expire on October 24, 2020. 51 Copyright Notice 53 Copyright (c) 2020 IETF Trust and the persons identified as the 54 document authors. All rights reserved. 56 This document is subject to BCP 78 and the IETF Trust's Legal 57 Provisions Relating to IETF Documents 58 (http://trustee.ietf.org/license-info) in effect on the date of 59 publication of this document. Please review these documents 60 carefully, as they describe your rights and restrictions with 61 respect to this document. Code Components extracted from this 62 document must include Simplified BSD License text as described in 63 Section 4.e of the Trust Legal Provisions and are provided without 64 warranty as described in the Simplified BSD License. 66 Table of Contents 68 Table of Contents .............................................. 2 69 1. Introduction ................................................ 3 70 2. Conventions used in this document............................ 4 71 3. General Context of Stateful PCE and PCEP for GMPLS .......... 4 72 4. Main Requirements ........................................... 5 73 5. Stateful PCEP Extensions for GMPLS Networks ................. 6 74 5.1. Capability Advertisement for Stateful PCEP in GMPLS .... 6 75 5.2. LSP Synchronization in GMPLS-controlled Networks ....... 7 76 5.3. LSP Delegation and Cleanup ............................. 8 77 5.4. LSP Operations in Stateful PCEP for GMPLS-controlled 78 Networks .................................................... 8 79 5.4.1. LSP Update in GMPLS-controlled Networks ........... 8 80 5.4.2. LSP Initiation in GMPLS-controlled Networks ....... 9 81 6. Modification of Existing PCEP Messages and Procedures ....... 9 82 6.1. Modification for LSP Re-optimization ................... 9 83 6.2. Modification for Route Exclusion ...................... 10 84 6.2.1. Modification for SRP Object to indicate Bi-directional 85 LSP ..................................................... 11 86 7. PCEP Object Extensions ..................................... 11 87 7.1. Generalized Endpoint .................................. 11 88 7.2. GENERALIZED-BANDWIDTH object .......................... 12 89 7.3. The LSP Protection Information ........................ 12 90 7.4. ERO Extension ......................................... 12 91 7.4.1. ERO with explicit label control .................. 13 92 7.4.2. ERO with Path Keys ............................... 13 93 7.5. Switch Layer Object ................................... 14 94 8. IANA Considerations ........................................ 14 95 8.1. New PCEP Error Codes .................................. 14 96 8.2. New Subobject for the Exclude Route Object ............ 14 97 8.3. New "B" Flag in the SRP Object ........................ 15 98 9. Manageability Considerations ............................... 15 99 9.1. Requirements on Other Protocols and Functional Components15 100 10. Security Considerations ................................... 15 101 11. Acknowledgement ........................................... 16 102 12. References ................................................ 16 103 12.1. Normative References ................................. 16 104 12.2. Informative References ............................... 16 105 13. Contributors' Address ..................................... 18 106 Authors' Addresses ............................................ 19 108 1. Introduction 110 [RFC4655] presents the architecture of a Path Computation Element 111 (PCE)-based model for computing Multiprotocol Label Switching (MPLS) 112 and Generalized MPLS (GMPLS) Traffic Engineering Label Switched 113 Paths (TE LSPs). To perform such a constrained computation, a PCE 114 stores the network topology (i.e., TE links and nodes) and resource 115 information (i.e., TE attributes) in its TE Database (TED). Such a 116 PCE is usually referred as a stateless PCE. To request path 117 computation services to a PCE, [RFC5440] defines the PCE 118 communication Protocol (PCEP) for interaction between a Path 119 Computation Client (PCC) and a PCE, or between two PCEs. PCEP as 120 specified in [RFC5440] mainly focuses on MPLS networks and the PCEP 121 extensions needed for GMPLS-controlled networks are provided in 122 [PCEP-GMPLS]. 124 Stateful PCEs are shown to be helpful in many application scenarios, 125 in both MPLS and GMPLS networks, as illustrated in [RFC8051]. 126 Further discussion of concept of a stateful PCE can be found in 127 [RFC7399]. In order for these applications to able to exploit the 128 capability of stateful PCEs, extensions to PCEP are required. 130 [RFC8051] describes how a stateful PCE can be applicable to solve 131 various problems for MPLS-TE and GMPLS networks and the benefits it 132 brings to such deployments. 134 [RFC8231] provides the fundamental extensions needed for stateful 135 PCE to support general functionality. Furthermore, [RFC8281] 136 describes the setup and teardown of PCE-initiated LSPs under the 137 active stateful PCE model, without the need for local configuration 138 on the PCC. However, both the documents left out the specification 139 for technology-specific objects/TLVs, and does not cover the GMPLS 140 networks (e.g., WSON, OTN, SONET/ SDH, etc. technologies). This 141 document focuses on the extensions that are necessary in order for 142 the deployment of stateful PCEs and the requirements for remote- 143 initiated LSPs in GMPLS-controlled networks. Section 3 provides 144 General context of Stateful PCE and PCEP for GMPLS are provided in 145 Section 3, and PCE initiation requirement for GMPLS is provided in 146 section 4. Protocol extensions is included in section 5, as a 147 solution to address such requirements. 149 2. Conventions used in this document 151 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 152 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 153 "OPTIONAL" in this document are to be interpreted as described in 154 BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all 155 capitals, as shown here. 157 3. General Context of Stateful PCE and PCEP for GMPLS 159 This section is built on the basis of Stateful PCE in [RFC8231] and 160 PCEP for GMPLS in [PCEP-GMPLS]. 162 The operation for Stateful PCE on LSPs can be divided into two types, 163 active stateful PCE and passive stateful PCE. 165 For active stateful PCE, PCUpd message is sent from PCE to PCC to 166 update the LSP state for the LSP delegated to PCE. Any changes to 167 the delegated LSPs generate a PCRpt message by the PCC to PCE to 168 convey the changes of the LSP. Any modifications to the Objects/TLVs 169 that are identified in this document to support GMPLS technology- 170 specific attributes will be carried in the PCRpt and PCUpd messages. 172 For passive stateful PCEs, PCReq/PCRep messages are used to convey 173 path computation instructions. GMPLS-technology specific Objects 174 and TLVs are defined in [PCEP-GMPLS], so this document just points 175 at that work and only adds the stateful PCE aspects where applicable. 176 Passive Stateful PCE makes use of PCRpt messages when reporting LSP 177 State changes sent by PCC to PCEs. Any modifications to the 178 Objects/TLVs that are identified in this document to support GMPLS 179 technology-specific attributes will be carried in the PCRpt message. 181 [PCEP-GMPLS] defines GMPLS-technology specific Objects/TLVs and this 182 document makes use of these Objects/TLVs without modifications where 183 applicable. Some of these Objects/TLVs may require modifications to 184 incorporate stateful PCE where applicable. The remote-initiated LSP 185 would follow the principle specified in [RFC8281], and GMPLS- 186 specific extensions are also included in this document. 188 4. Main Requirements 190 This section notes the main functional requirements for PCEP 191 extensions to support stateful PCE for use in GMPLS-controlled 192 networks, based on the description in [RFC8051]. Many 193 requirements are common across a variety of network types (e.g., 194 MPLS-TE networks and GMPLS networks) and the protocol extensions to 195 meet the requirements are already described in [RFC8231]. This 196 document does not repeat the description of those protocol 197 extensions. This document presents protocol extensions for a set of 198 requirements which are specific to the use of a stateful PCE in a 199 GMPLS-controlled network. 201 The requirements for GMPLS-specific stateful PCE are as follows: 203 o Advertisement of the stateful PCE capability. This generic 204 requirement is covered in Section 5.4 of [RFC8231], and the 205 GMPLS capability TLV as per [PCEP-GMPLS] MUST be advertised as 206 well. This document assumes that STATEFUL-PCE-CAPABILITY TLV 207 specified in [RFC8231] can be used for GMPLS Stateful PCE 208 capability advertisement and there is no further extensions. 210 o Active LSP update is covered in Section 6.2 of [RFC8231]. 211 Section 5.1 of this document provides extension for its 212 application in GMPLS-controlled networks. 214 o LSP state synchronization and LSP state report. This is a 215 generic requirement already covered in Section 5.6. of 216 [RFC8231]. However, there are further extensions required 217 specifically for GMPLS-controlled networks and discussed in 218 Section 5.2. 220 o LSP delegation is already covered in Section 5.7 of [RFC8231]. 221 The delegation procedure is reused in this document without any 222 further extensions. Statement can be found in section 5.3 in 223 this document. 225 o All the PCEP messages need to be capable to indicate GMPLS- 226 specific switching capabilities per TE link basis. GMPLS LSP 227 creation requires knowledge of LSP switching capability (e.g., 228 TDM, L2SC, OTN-TDM, LSC, etc.) to be used according to [RFC3471], 229 [RFC3473]. 231 o In order to create/modify/delete GMPLS LSPs, the PCEP messages 232 also need to indicate knowledge of the encoding type (e.g., WSON, 233 Ethernet, SONET/ SDH, OTN, etc.) to be used by the LSP according 234 to [RFC3471], [RFC3473]. 236 o GMPLS LSP creation/modification/deletion requires information of 237 the generalized payload (G-PID) to be carried by the LSP per 238 [RFC3471], [RFC3473]. It also requires the specification of data 239 flow specific traffic parameters (also known as Tspec), which 240 are technology specific. Such information would be needed for 241 PCEP message. 243 o GMPLS extends the addressing to include unnumbered interface 244 identifiers, as defined in [RFC3477]. 246 o In some technologies path calculation is tightly coupled with 247 label selection along the route. For example, path calculation 248 in a WDM network may include lambda continuity and/or lambda 249 feasibility constraints and hence a path computed by the PCE is 250 associated with a specific lambda (label). Hence, in such 251 networks, the label information needs to be provided to a PCC in 252 order for a PCE to initiate GMPLS LSPs under the active stateful 253 PCE model, i.e., explicit label control may be required. 255 o Stateful PCEP message also need to indicate the protection 256 context information for the LSP specified by GMPLS, as defined 257 in [RFC4872], [RFC4873]. 259 5. Stateful PCEP Extensions for GMPLS Networks 261 5.1. Capability Advertisement for Stateful PCEP in GMPLS 263 Capability Advertisement has been specified in [RFC8231], and can be 264 achieved by using the "STATEFUL-PCE-CAPABILITY TLV". GMPLS- 265 CAPABILITY TLV has been defined in [PCEP-GMPLS], and would be useful 266 for stateful PCEP in GMPLS network as well. 268 Besides the above, this document does not have additional extension 269 regarding the capability advertisement. 271 5.2. LSP Synchronization in GMPLS-controlled Networks 273 PCCs need to report the attributes of LSPs to the PCE to enable 274 stateful operation of a GMPLS network. This process is known as 275 LSP state synchronization. The LSP attributes include bandwidth, 276 associated route, and protection information etc., are stored by the 277 PCE in the LSP database (LSP-DB). Note that, as described in 278 [RFC8231], the LSP state synchronization covers both the bulk 279 reporting of LSPs at initialization as well the reporting of new or 280 modified LSP during normal operation. Incremental LSP-DB 281 synchronization may be desired in a GMPLS-controlled network and it 282 is specified in [RFC8232]. 284 [RFC8231] describes mechanisms for LSP synchronization using the 285 Path Computation State Report (PCRpt) message, but does not cover 286 reporting of technology-specific attributes. As stated in [RFC8231], 287 the construct is further composed of a compulsory Explicit 288 Route Object (ERO) and a compulsory attribute-list and an optional 289 Record Route Object (RRO). In order to report LSP states in GMPLS 290 networks, this specification allows the use within a PCRpt message 291 both of technology- and GMPLS-specific attribute objects and TLVs 292 defined in [PCEP-GMPLS] as follows: 294 o Include Route Object (IRO)/ Exclude Route Object (XRO) 295 Extensions to support the inclusion/exclusion of labels and 296 label sub-objects for GMPLS. (See Section 2.6 and 2.7 in [PCEP- 297 GMPLS]) 299 o END-POINTS (Generalized END-POINTS Object Type. See Section 2.5 300 in [PCEP-GMPLS]) 302 o BANDWIDTH (Generalized BANDWIDTH Object Type. See Section 2.3 303 in [PCEP-GMPLS]) 305 o LSPA (PROTECTION ATTRIBUTE TLV, See Section 2.8 in [PCEP-GMPLS]. 307 The END-POINTS object SHOULD be carried within the attribute-list to 308 specify the endpoints pertaining to the reported LSP. The XRO object 309 MAY be carried to specify the network resources that the reported 310 LSP avoids and a PCE SHOULD consider avoid these network resources 311 during the process of re-optimizing after this LSP is delegated to 312 the PCE. To be more specific, the is updated as 313 follows using the notations of [RFC5511]: 315 ::= [] 316 [] 317 [] 319 [] 320 [] 321 [] 323 ::= [] 325 If the LSP being reported protects another LSP, the PROTECTION- 326 ATTRIBUTE TLV [PCEP-GMPLS] MUST be included in the LSPA object to 327 describe its attributes and restrictions. Moreover, if the status of 328 the protecting LSP changes from non-operational to operational, the 329 PCC SHOULD synchronize the state change of the LSPs to the stateful 330 PCE using a PCRpt message. This use case arises, for example, when 331 the protecting LSP becomes operational due to the failure of the 332 primary LSP. 334 5.3. LSP Delegation and Cleanup 336 LSP delegation and cleanup procedure specified in [RFC8231] are 337 equally applicable to GMPLS LSPs and this document does not modify 338 the associated usage. 340 5.4. LSP Operations in Stateful PCEP for GMPLS-controlled Networks 342 Both passive and active stateful PCE mechanism in [RFC8231] are 343 applicable in GMPLS-controlled networks. 345 5.4.1. LSP Update in GMPLS-controlled Networks 347 [RFC8231] defines the Path Computation LSP Update Request (PCUpd) 348 message to enable to update the attributes of an LSP. However, 349 [RFC8231] does not define technology-specific parameters. 351 A key element of the PCUpd message is the attribute-list construct 352 defined in [RFC5440] and extended by many other PCEP specifications. 354 For GMPLS purposes we note that the BANDWIDTH object used in the 355 attribute-list is defined in [PCEP-GMPLS]. Furthermore, additional 356 TLVs are defined for the LSPA object in [PCEP-GMPLS] and MAY be 357 included to indicate technology-specific attributes. There are other 358 technology-specific attributes that need to be conveyed in the 359 of the construct in the PCUpd 360 message. Note that these path details in the PCUpd message are the 361 same as the of the PCRep message. See Section 5.3 362 for the details. 364 5.4.2. LSP Initiation in GMPLS-controlled Networks 366 PCInitiate message defined in [RFC8281] needs to be extended in 367 GMPLS network to support the LSP initiation. The extension includes 368 the following objects: 370 6. Modification of Existing PCEP Messages and Procedures 372 [Editor Notes]: the whole section would need re-working, the 373 objective is to indicate the RBNF model for the PCEP extension, 374 especially where new objects and TLVs are specified. 376 One of the advantages mentioned in [RFC8051] is that the stateful 377 nature of a PCE simplifies the information conveyed in PCEP messages, 378 notably between PCC and PCE, since it is possible to refer to PCE 379 managed state for active LSPs. To be more specific, with a stateful 380 PCE, it is possible to refer to an LSP with a unique identifier in 381 the scope of the PCC-PCE session and thus use such identifier to 382 refer to that LSP. Note this is also applicable to packet networks. 384 6.1. Modification for LSP Re-optimization 386 The Request Parameters (RP) object on a Path Computation Request 387 (PCReq) message carries the R bit. When set, this indicates that 388 the PCC is requesting re-optimization of an existing LSP. Upon 389 receiving such a PCReq, a stateful PCE SHOULD perform the re- 390 optimization in the following cases: 392 o The existing bandwidth and route information of the LSP to be 393 re-optimized is provided in the PCReq message using the 394 BANDWIDTH object and the ERO. 396 o The existing bandwidth and route information is not supplied 397 in the PCReq message, but can be found in the PCE's LSP-DB. 398 In this case, the LSP MUST be identified using an LSP 399 identifier carried in the PCReq message, and that fact 400 requires that the LSP identifier was previously supplied 401 either by the PCC in a PCRpt message or by the PCE in a PCRep 402 message. [RFC8231] defines how this is achieved using a 403 combination of the per-node LSP identifier (PLSP-ID) and the 404 PCC's address. 406 If no LSP state information is available to carry out re- 407 optimization, the stateful PCE should report the error "LSP state 408 information unavailable for the LSP re-optimization" (Error Type = 409 TBD1, Error value= TBD2). 411 6.2. Modification for Route Exclusion 413 [RFC5521] defines a mechanism for a PCC to request or demand that 414 specific nodes, links, or other network resources are excluded from 415 paths computed by a PCE. A PCC may wish to request the computation 416 of a path that avoids all link and nodes traversed by some other LSP. 418 To this end this document defines a new sub-object for use with 419 route exclusion defined in [RFC5521]. The LSP exclusion sub-object 420 is as follows: 422 0 1 2 3 423 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 424 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 425 |X|Type (TBD3) | Length | Attributes | Flag | 426 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 427 | | 428 // Symbolic Path Name // 429 | | 430 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 432 X bit and Attribute fields are defined in [RFC5521]. 434 Type: Subobject Type for an LSP exclusion sub-object. Value of 435 TBD3. To be assigned by IANA. 437 Length: The Length contains the total length of the subobject in 438 bytes, including the Type and Length fields. 440 Flags: This field may be used to further specify the exclusion 441 constraint with regard to the LSP. Currently, no values are 442 defined. 444 Symbolic Path Name: This is the identifier given to an LSP and is 445 unique in the context of the PCC address as defined in [RFC8231]. 447 Reserved: MUST be transmitted as zero and SHOULD be ignored on 448 receipt. 450 This sub-object is OPTIONAL in the exclude route object (XRO) and 451 can be present multiple times. When a stateful PCE receives a PCReq 452 message carrying this sub-object, it SHOULD search for the 453 identified LSP in its LSP-DB and then exclude from the new path 454 computation all resources used by the identified LSP. If the 455 stateful PCE cannot recognize one or more of the received LSP 456 identifiers, it should send an error message PCErr reporting "The 457 LSP state information for route exclusion purpose cannot be found" 458 (Error-type = TBD1, Error-value = TBD4). Optionally, it may provide 459 with the unrecognized identifier information to the requesting PCC 460 using the error reporting techniques described in [RFC5440]. 462 6.2.1. Modification for SRP Object to indicate Bi-directional LSP 464 The format of the SRP object is defined in [RFC8231]. The object is 465 used in PCUpd and PCInitiate messages for GMPLS. 467 This document defines a new flag to be carried in the Flags field of 468 the SRP object. This flag indicates a bidirectional co-routed LSP 469 setup operation initiated by the PCE as follows: 471 o B (Bidirectional LSP -- 1 bit): If set to 0, it indicates a 472 request to create a uni-directional LSP. If set to 1, it 473 indicates a request to create a bidirectional co-routed LSP. 475 The bit position is TBD5 as assigned by IANA (see Section 5.3) 477 7. PCEP Object Extensions 479 7.1. Generalized Endpoint 481 This document does not modify the usage of END-POINTS object for PCE 482 initiated LSPs as specified in [RFC8281] . It augments the usage as 483 specified below. 485 END-POINTS object has been extended by [PCEP-GMPLS] to include a new 486 object type called "Generalized Endpoint". PCInitiate message sent 487 by a PCE to a PCC to trigger a GMPLS LSP instantiation MUST include 488 the END-POINTS with Generalized Endpoint object type. Furthermore, 489 the END-POINTS object MUST contain "label request" TLV. The label 490 request TLV is used to specify the switching type, encoding type and 491 G-PID of the LSP being instantiated by the PCE. 493 If the END-POINTS Object of type Generalized Endpoint is missing the 494 label request TLV, the PCC MUST send a PCErr message with Error- 495 type=6 (Mandatory Object missing) and Error-value= TBA (label 496 request TLV missing). 498 If the PCC does not support the END-POINTS Object of type 499 Generalized Endpoint, the PCC MUST send a PCErr message with Error- 500 type = 3(Unknown Object), Error-value = 2(unknown object type). 502 The unnumbered endpoint TLV can be used to specify unnumbered 503 endpoint addresses for the LSP being instantiated by the PCE. The 504 END-POINTS MAY contain other TLVs defined in [PCEP-GMPLS]. 506 7.2. GENERALIZED-BANDWIDTH object 508 LSP initiate message defined in [RFC8281] can optionally include the 509 BANDWIDTH object. However, the following possibilities cannot be 510 represented in the BANDWIDTH object: 512 o Asymmetric bandwidth (different bandwidth in forward and 513 reverse direction), as described in [RFC6387]. 515 o Technology specific GMPLS parameters (e.g., Tspec for 516 SDH/SONET, G.709, ATM, MEF, etc.) are not supported. 518 GENERALIZED-BANDWIDTH object has been defined in [PCEP-GMPLS] to 519 address the above-mentioned limitation of the BANDWIDTH object. 521 This document specifies the use of GENERALIZED-BANDWIDTH object in 522 PCInitiate message. Specifically, GENERALIZED-BANDWIDTH object MAY 523 be included in the PCInitiate message. The GENERALIZED-BANDWIDTH 524 object in PCInitiate message is used to specify technology specific 525 Tspec and asymmetrical bandwidth values for the LSP being 526 instantiated by the PCE. 527 7.3. The LSP Protection Information 529 LSPA in the PCEP message can be used to specify protection 530 attributes of the LSP being instantiated by the stateful PCE. 532 7.4. ERO Extension 534 GMPLS network does not have special requirement on modifying the 535 usage of ERO object for stateful PCEP in [RFC8231] and PCE initiated 536 LSPs as specified in [RFC8281]. It augments the usage as specified 537 in the following sections. 539 7.4.1. ERO with explicit label control 541 As mentioned earlier, there are technologies and scenarios where 542 active stateful PCE requires explicit label control in order to 543 instantiate an LSP. 545 Explicit label control (ELC) is a procedure supported by RSVP-TE, 546 where the outgoing label(s) is (are) encoded in the ERO. [PCEP-GMPLS] 547 extends the ERO object of PCEP to include explicit label control. 548 The ELC procedure enables the PCE to provide such label(s) directly 549 in the path ERO. 551 The extended ERO object in PCInitiate message can be used to specify 552 label along with ERO to PCC for the LSP being instantiated by the 553 active stateful PCE. 555 7.4.2. ERO with Path Keys 557 There are many scenarios in packet and optical networks where the 558 route information of an LSP may not be provided to the PCC for 559 confidentiality reasons. A multi-domain or multi-layer network is 560 an example of such networks. Similarly, a GMPLS User- Network 561 Interface (UNI) [RFC4208] is also an example of such networks. 563 In such scenarios, ERO containing the entire route cannot be 564 provided to PCC (by PCE). Instead, PCE provides an ERO with Path 565 Keys to the PCC. For example, in the case UNI interface between the 566 router and the optical nodes, the ERO in the LSP Initiate Message 567 may be constructed as follows: 569 o The first hop is a strict hop that provides the egress 570 interface information at PCC. This interface information is 571 used to get to a network node that can extend the rest of the 572 ERO. (Please note that in the cases where the network node is 573 not directly connected with the PCC, this part of ERO may 574 consist of multiple hops and may be loose). 576 o The following(s) hop in the ERO may provide the network node 577 with the path key [RFC5520] that can be resolved to get the 578 contents of the route towards the destination. 580 o There may be further hops but these hops may also be encoded 581 with the path keys (if needed). 583 This document does not change encoding or processing roles for the 584 path keys, which are defined in [RFC5520]. 586 7.5. Switch Layer Object 588 [RFC8282] specifies the SWITCH-LAYER object which defines and 589 specifies the switching layer (or layers) in which a path MUST or 590 MUST NOT be established. A switching layer is expressed as a 591 switching type and encoding type. [PCEP-GMPLS], which defines the 592 GMPLS extensions for PCEP, suggests using the SWITCH-LAYER object. 593 Thus, SWITCH-LAYER object can be used in the PCInitiate message to 594 specify the switching layer (or layers) of the LSP being remotely 595 initiated. 597 8. IANA Considerations 599 8.1. New PCEP Error Codes 601 IANA is requested to make the following allocation in the "PCEP- 602 ERROR Object Error Types and Values" registry. 604 Error Type Meaning Reference 606 TBD1 LSP state information missing [This.I-D] 608 Error-value TBD2: LSP state information unavailable [This.I-D] 609 for the LSP re-optimization 611 Error-value TBD4: LSP state information for route 612 exclusion purpose cannot be found [This.I-D] 614 This document defines the following new Error-Value: 616 Error-Type Error-Value Reference 618 6 Error-value TBD5: Label Request TLV 619 missing [This.I-D] 621 8.2. New Subobject for the Exclude Route Object 623 IANA maintains the "PCEP Parameters" registry containing a 624 subregistry called "PCEP Objects". This registry has a subregistry 625 for the XRO (Exclude Route Object) listing the sub-objects that can 626 be carried in the XRO. IANA is requested to assign a further sub- 627 object that can be carried in the XRO as follows: 629 Value Description Reference 631 ----------+------------------------------+------------- 633 TBD3 LSP identifier sub-object [This.I-D] 635 8.3. New "B" Flag in the SRP Object 637 IANA maintains a subregistry, named the "SRP Object Flag Field", 638 within the "Path Computation Element Protocol (PCEP) Numbers" 639 registry, to manage the Flag field of the SRP object. 641 IANA is requested to make an assignment from this registry as 642 follows: 644 Bit Description Reference 645 --- ---------------------------- ---------- 647 TDB5 Bi-directional co-routed LSP [This.I-D] 649 9. Manageability Considerations 651 The description and functionality specifications presented related 652 to stateful PCEs should also comply with the manageability 653 specifications covered in Section 8 of [RFC4655]. Furthermore, a 654 further list of manageability issues presented in [RFC8231] should 655 also be considered. 657 Additional considerations are presented in the next section. 659 9.1. Requirements on Other Protocols and Functional Components 661 When the detailed route information is included for LSP state 662 synchronization (either at the initial stage or during LSP state 663 report process), this requires the ingress node of an LSP carry the 664 RRO object in order to enable the collection of such information. 666 10. Security Considerations 668 This draft provides additional extensions to PCEP so as to 669 facilitate stateful PCE usage in GMPLS-controlled networks, on top 670 of [RFC8231]. The PCEP extensions to support GMPLS-controlled 671 networks should be considered under the same security as for MPLS 672 networks, as noted in [RFC7025]. Therefore, the security 673 considerations elaborated in [RFC5440] still apply to this draft. 674 Furthermore, [RFC8231] provides a detailed analysis of the 675 additional security issues incurred due to the new extensions and 676 possible solutions needed to support for the new stateful PCE 677 capabilities and they apply to this document as well. 679 11. Acknowledgement 681 We would like to thank Adrian Farrel, Cyril Margaria, George Swallow 682 and Jan Medved for the useful comments and discussions. 684 12. References 686 12.1. Normative References 688 [RFC2119] Bradner, S., "Key words for use in RFCs to indicate 689 requirements levels", RFC 2119, March 1997. 691 [RFC5440] Vasseur, J.-P., and Le Roux, JL., "Path Computation 692 Element (PCE) Communication Protocol (PCEP)", RFC 5440, 693 March 2009. 695 [RFC5521] Oki, E., Takeda, T., and A. Farrel, "Extensions to the 696 Path Computation Element Communication Protocol (PCEP) for 697 Route Exclusions", RFC 5521, April 2009. 699 [RFC8174] B. Leiba, "Ambiguity of Uppercase vs Lowercase in RFC 2119 700 Key Words", RFC 8174, May 2017. 702 [RFC8231] Crabbe, E., Medved, J., Varga, R., Minei, I., "Path 703 Computation Element Communication Protocol (PCEP) 704 Extensions for Stateful PCE", RFC 8231, September 2017. 706 [RFC8281] Crabbe, E., Minei, I., Sivabalan, S., and R. Varga, "Path 707 Computation Element Communication Protocol (PCEP) 708 Extensions for PCE-Initiated LSP Setup in a Stateful PCE 709 Model", RFC 8281, December 2017. 711 [PCEP-GMPLS] Margaria, C., Gonzalez de Dios, O., Zhang, F., "PCEP 712 extensions for GMPLS", draft-ietf-pce-gmpls-pcep- 713 extensions, work in progress. 715 12.2. Informative References 717 [RFC5511] A. Farrel, "Routing Backus-Naur Form (RBNF): A Syntax Used 718 to Form Encoding Rules in Various Routing Protocol 719 Specifications", RFC 5511, April 2009. 721 [RFC8051] Zhang, X., Minei, I., et al, "Applicability of Stateful 722 Path Computation Element (PCE) ", RFC 8051, January 2017. 724 [RFC8232] Crabbe, E., Minei, I., Medved, J., Varga, R., Zhang, X., 725 and D. Dhody, "Optimizations of Label Switched Path State 726 Synchronization Procedures for a Stateful PCE", RFC 8232, 727 September 2017. 729 [RFC8282] Oki, E., Takeda, T., Farrel, A., and F. Zhang, "Extensions 730 to the Path Computation Element communication Protocol 731 (PCEP) for Inter-Layer MPLS and GMPLS Traffic Engineering", 732 RFC 8282, December 2017. 734 [RFC3471] Berger, L., Ed., "Generalized Multi-Protocol Label 735 Switching (GMPLS) Signaling Functional Description", RFC 736 3471, January 2003. 738 [RFC3473] Berger, L., Ed., "Generalized Multi-Protocol Label 739 Switching (GMPLS) Signaling Resource ReserVation Protocol 740 Traffic Engineering (RSVP-TE) Extensions", RFC 3473, 741 January 2003. 743 [RFC3477] Kompella, K. and Y. Rekhter, "Signalling Unnumbered Links 744 in Resource ReSerVation Protocol - Traffic Engineering 745 (RSVP-TE)", RFC 3477, January 2003. 747 [RFC4208] Swallow, G., Drake, J., Ishimatsu, H., and Y. Rekhter, 748 "Generalized Multiprotocol Label Switching (GMPLS) User 749 Network Interface (UNI): Resource ReserVation Protocol- 750 Traffic Engineering (RSVP-TE) Support for the Overlay 751 Model", RFC 4208, October 2005. 753 [RFC4655] Farrel, A., Vasseur, J.-P., and Ash, J., "A Path 754 Computation Element (PCE)-Based Architecture", RFC 4655, 755 August 2006. 757 [RFC4872] Lang, J., Ed., Rekhter, Y., Ed., and D. Papadimitriou, 758 Ed., "RSVP-TE Extensions in Support of End-to-End 759 Generalized Multi-Protocol Label Switching (GMPLS) 760 Recovery", RFC 4872, May 2007. 762 [RFC4873] Berger, L., Bryskin, I., Papadimitriou, D., and A. Farrel, 763 "GMPLS Segment Recovery", RFC 4873, May 2007. 765 [RFC5520] Bradford, R., Ed., Vasseur, JP., and A. Farrel, 766 "Preserving Topology Confidentiality in Inter-Domain Path 767 Computation Using a Path-Key-Based Mechanism", RFC 5520, 768 April 2009. 770 [RFC6387] Takacs, A., Berger, L., Caviglia, D., Fedyk, D., and J. 771 Meuric, "GMPLS Asymmetric Bandwidth Bidirectional Label 772 Switched Paths (LSPs)", RFC 6387, September 2011. 774 [RFC7025] Otani, T., Ogaki, K., Caviglia, D., Zhang, F., and C. 775 Margaria, "Requirements for GMPLS Applications of PCE", 776 RFC 7025, September 2013, 778 [RFC7399] Farrel, A., King, D., "Unanswered Questions in the Path 779 Computation Element Architecture", RFC 7399, October 2014. 781 13. Contributors' Address 783 Xian Zhang 784 Huawei Technologies 785 Email: zhang.xian@huawei.com 787 Dhruv Dhody 788 Huawei Technology 789 India 790 Email: dhruv.ietf@gmail.com 792 Yi Lin 793 Huawei Technologies 794 Email: yi.lin@huawei.com 796 Fatai Zhang 797 Huawei Technologies 798 Email: zhangfatai@huawei.com 800 Ramon Casellas 801 CTTC 802 Av. Carl Friedrich Gauss n7 803 Castelldefels, Barcelona 08860 804 Spain 805 Email: ramon.casellas@cttc.es 807 Siva Sivabalan 808 Cisco Systems 809 Email: msiva@cisco.com 811 Clarence Filsfils 812 Cisco Systems 813 Email: cfilsfil@cisco.com 815 Robert Varga 816 Pantheon Technologies 817 Email: nite@hq.sk 819 Authors' Addresses 821 Young Lee (Editor) 822 Samsung 823 Email: younglee.tx@gmail.com 825 Haomian Zheng (Editor) 826 Huawei Technologies 827 H1, Huawei Xiliu Beipo Village, Songshan Lake 828 Dongguan, Guangdong 523808 829 P.R.China 831 Email: zhenghaomian@huawei.com 833 Oscar Gonzalez de Dios 834 Telefonica 835 Phone: +34 913374013 836 Email: oscar.gonzalezdedios@telefonica.com 838 Victor Lopez 839 Telefonica 841 Email: victor.lopezalvarez@telefonica.com 843 Zafar Ali 844 Cisco Systems 845 Email: zali@cisco.com