idnits 2.17.1 draft-ietf-pce-pcep-stateful-pce-gmpls-12.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 54 characters in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == Line 39 has weird spacing: '... months and ...' == Line 40 has weird spacing: '... at any time...' == Line 41 has weird spacing: '...ference mate...' -- The document date (October 29, 2019) is 1634 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) == Missing Reference: 'RFC 5440' is mentioned on line 118, but not defined == Missing Reference: 'RFC7399' is mentioned on line 125, but not defined == Missing Reference: 'PCE-GMPLS' is mentioned on line 203, but not defined == Missing Reference: 'RFC5521' is mentioned on line 430, but not defined == Missing Reference: 'RFC7025' is mentioned on line 670, but not defined ** Downref: Normative reference to an Informational RFC: RFC 4655 Summary: 2 errors (**), 0 flaws (~~), 9 warnings (==), 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 SKKU 3 Intended status: Standards Track H. Zheng (Editor) 4 Expires: April 30, 2020. Huawei 5 O. G. de Dios 6 V. Lopez 7 Telefonica 8 Zafar Ali 9 Cisco Systems 10 October 29, 2019 12 Path Computation Element (PCE) Protocol Extensions for Stateful PCE 13 Usage in GMPLS-controlled Networks 15 draft-ietf-pce-pcep-stateful-pce-gmpls-12 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. 38 Internet-Drafts are draft documents valid for a maximum of six 39 months and may be updated, replaced, or obsoleted by other 40 documents at any time. It is inappropriate to use Internet-Drafts 41 as reference material or to cite them other than as "work in 42 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 April 30, 2020. 51 Copyright Notice 53 Copyright (c) 2019 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 .............. 8 78 5.4.1. LSP Update in GMPLS-controlled Networks ........... 8 79 5.4.2. LSP Initiation in GMPLS-controlled Networks ....... 9 80 6. Modification of Existing PCEP Messages and Procedures ....... 9 81 6.1. Modification for LSP Re-optimization ................... 9 82 6.2. Modification for Route Exclusion ...................... 10 83 6.2.1. Modification for SRP Object ...................... 11 84 7. PCEP Object Extensions ..................................... 11 85 7.1. Generalized Endpoint .................................. 11 86 7.2. GENERALIZED-BANDWIDTH object .......................... 12 87 7.3. The LSP Protection Information ........................ 12 88 7.4. ERO Extension ......................................... 12 89 7.4.1. ERO with explicit label control .................. 13 90 7.4.2. ERO with Path Keys ............................... 13 91 7.5. Switch Layer Object ................................... 14 92 8. IANA Considerations ........................................ 14 93 8.1. New PCEP Error Codes .................................. 14 94 8.2. New Subobject for the Exclude Route Object ............ 14 95 8.3. New "B" Flag in the SRP Object ........................ 15 96 9. Manageability Considerations ............................... 15 97 9.1. Requirements on Other Protocols and Functional Components15 98 10. Security Considerations ................................... 15 99 11. Acknowledgement ........................................... 16 100 12. References ................................................ 16 101 12.1. Normative References ................................. 16 102 12.2. Informative References ............................... 16 103 13. Contributors' Address ..................................... 18 104 Authors' Addresses ............................................ 19 106 1. Introduction 108 [RFC4655] presents the architecture of a Path Computation Element 109 (PCE)-based model for computing Multiprotocol Label Switching (MPLS) 110 and Generalized MPLS (GMPLS) Traffic Engineering Label Switched 111 Paths (TE LSPs). To perform such a constrained computation, a PCE 112 stores the network topology (i.e., TE links and nodes) and resource 113 information (i.e., TE attributes) in its TE Database (TED). Such a 114 PCE is usually referred as a stateless PCE. To request path 115 computation services to a PCE, [RFC5440] defines the PCE 116 communication Protocol (PCEP) for interaction between a Path 117 Computation Client (PCC) and a PCE, or between two PCEs. PCEP as 118 specified in [RFC 5440] mainly focuses on MPLS networks and the PCEP 119 extensions needed for GMPLS-controlled networks are provided in 120 [PCEP-GMPLS]. 122 Stateful PCEs are shown to be helpful in many application scenarios, 123 in both MPLS and GMPLS networks, as illustrated in [RFC8051]. 124 Further discussion of concept of a stateful PCE can be found in 125 [RFC7399]. In order for these applications to able to exploit the 126 capability of stateful PCEs, extensions to PCEP are required. 128 [RFC8051] describes how a stateful PCE can be applicable to solve 129 various problems for MPLS-TE and GMPLS networks and the benefits it 130 brings to such deployments. 132 [RFC8231] provides the fundamental extensions needed for stateful 133 PCE to support general functionality. Furthermore, [RFC8281] 134 describes the setup and teardown of PCE-initiated LSPs under the 135 active stateful PCE model, without the need for local configuration 136 on the PCC. However, both the documents left out the specification 137 for technology-specific objects/TLVs, and does not cover the GMPLS 138 networks (e.g., WSON, OTN, SONET/ SDH, etc. technologies). This 139 document focuses on the extensions that are necessary in order for 140 the deployment of stateful PCEs and the requirements for remote- 141 initiated LSPs in GMPLS-controlled networks. Section 3 provides 142 General context of Stateful PCE and PCEP for GMPLS are provided in 143 Section 3, and PCE initiation requirement for GMPLS is provided in 144 section 4. Protocol extensions is included in section 5, as a 145 solution to address such requirements. 147 2. Conventions used in this document 149 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 150 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 151 "OPTIONAL" in this document are to be interpreted as described in 152 BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all 153 capitals, as shown here. 155 3. General Context of Stateful PCE and PCEP for GMPLS 157 This section is built on the basis of Stateful PCE in [RFC8231] and 158 PCEP for GMPLS in [PCEP-GMPLS]. 160 The operation for Stateful PCE on LSPs can be divided into two types, 161 active stateful PCE and passive stateful PCE. 163 For active stateful PCE, PCUpd message is sent from PCE to PCC to 164 update the LSP state for the LSP delegated to PCE. Any changes to 165 the delegated LSPs generate a PCRpt message by the PCC to PCE to 166 convey the changes of the LSP. Any modifications to the Objects/TLVs 167 that are identified in this document to support GMPLS technology- 168 specific attributes will be carried in the PCRpt and PCUpd messages. 170 For passive stateful PCEs, PCReq/PCRep messages are used to convey 171 path computation instructions. GMPLS-technology specific Objects 172 and TLVs are defined in [PCEP-GMPLS], so this document just points 173 at that work and only adds the stateful PCE aspects where applicable. 174 Passive Stateful PCE makes use of PCRpt messages when reporting LSP 175 State changes sent by PCC to PCEs. Any modifications to the 176 Objects/TLVs that are identified in this document to support GMPLS 177 technology-specific attributes will be carried in the PCRpt message. 179 [PCEP-GMPLS] defines GMPLS-technology specific Objects/TLVs and this 180 document makes use of these Objects/TLVs without modifications where 181 applicable. Some of these Objects/TLVs may require modifications to 182 incorporate stateful PCE where applicable. The remote-initiated LSP 183 would follow the principle specified in [RFC8281], and GMPLS- 184 specific extensions are also included in this document. 186 4. Main Requirements 188 This section notes the main functional requirements for PCEP 189 extensions to support stateful PCE for use in GMPLS-controlled 190 networks, based on the description in [RFC8051]. Many 191 requirements are common across a variety of network types (e.g., 192 MPLS-TE networks and GMPLS networks) and the protocol extensions to 193 meet the requirements are already described in [RFC8231]. This 194 document does not repeat the description of those protocol 195 extensions. This document presents protocol extensions for a set of 196 requirements which are specific to the use of a stateful PCE in a 197 GMPLS-controlled network. 199 The requirements for GMPLS-specific stateful PCE are as follows: 201 o Advertisement of the stateful PCE capability. This generic 202 requirement is covered in Section 5.4 of [RFC8231], and the 203 GMPLS capability TLV as per [PCE-GMPLS] MUST be advertised as 204 well. This document assumes that STATEFUL-PCE-CAPABILITY TLV 205 specified in [RFC8231] can be used for GMPLS Stateful PCE 206 capability advertisement and there is no further extensions. 208 o Active LSP update is covered in Section 6.2 of [RFC8231]. 209 Section 5.1 of this document provides extension for its 210 application in GMPLS-controlled networks. 212 o LSP state synchronization and LSP state report. This is a 213 generic requirement already covered in Section 5.6. of 214 [RFC8231]. However, there are further extensions required 215 specifically for GMPLS-controlled networks and discussed in 216 Section 5.2. 218 o LSP delegation is already covered in Section 5.7 of [RFC8231]. 219 The delegation procedure is reused in this document without any 220 further extensions. Statement can be found in section 5.3 in 221 this document. 223 o All the PCEP messages need to be capable to indicate GMPLS- 224 specific switching capabilities per TE link basis. GMPLS LSP 225 creation requires knowledge of LSP switching capability (e.g., 226 TDM, L2SC, OTN-TDM, LSC, etc.) to be used according to [RFC3471], 227 [RFC3473]. 229 o In order to create/modify/delete GMPLS LSPs, the PCEP messages 230 also need to indicate knowledge of the encoding type (e.g., 231 lambda photonic, Ethernet, SONET/ SDH, G709 OTN, etc.) to be 232 used by the LSP according to [RFC3471], [RFC3473]. 234 o GMPLS LSP creation/modification/deletion requires information of 235 the generalized payload (G-PID) to be carried by the LSP per 236 [RFC3471], [RFC3473]. It also requires the specification of data 237 flow specific traffic parameters (also known as Tspec), which 238 are technology specific. Such information would be needed for 239 PCEP message. 241 o GMPLS extends the addressing to include unnumbered interface 242 identifiers, as defined in [RFC3477]. 244 o In some technologies path calculation is tightly coupled with 245 label selection along the route. For example, path calculation 246 in a WDM network may include lambda continuity and/or lambda 247 feasibility constraints and hence a path computed by the PCE is 248 associated with a specific lambda (label). Hence, in such 249 networks, the label information needs to be provided to a PCC in 250 order for a PCE to initiate GMPLS LSPs under the active stateful 251 PCE model, i.e., explicit label control may be required. 253 o Stateful PCEP message also need to indicate the protection 254 context information for the LSP specified by GMPLS, as defined 255 in [RFC4872], [RFC4873]. 257 5. Stateful PCEP Extensions for GMPLS Networks 259 5.1. Capability Advertisement for Stateful PCEP in GMPLS 261 Capability Advertisement has been specified in [RFC8231], and can be 262 achieved by using the "STATEFUL-PCE-CAPABILITY TLV". GMPLS- 263 CAPABILITY TLV has been defined in [PCEP-GMPLS], and would be useful 264 for stateful PCEP in GMPLS network as well. 266 Besides the above, this document does not have additional extension 267 regarding the capability advertisement. 269 5.2. LSP Synchronization in GMPLS-controlled Networks 271 PCCs need to report the attributes of LSPs to the PCE to enable 272 stateful operation of a GMPLS network. This process is known as 273 LSP state synchronization. The LSP attributes include bandwidth, 274 associated route, and protection information etc., are stored by the 275 PCE in the LSP database (LSP-DB). Note that, as described in 276 [RFC8231], the LSP state synchronization covers both the bulk 277 reporting of LSPs at initialization as well the reporting of new or 278 modified LSP during normal operation. Incremental LSP-DB 279 synchronization may be desired in a GMPLS-controlled network and it 280 is specified in [RFC8232]. 282 [RFC8231] describes mechanisms for LSP synchronization using the 283 Path Computation State Report (PCRpt) message, but does not cover 284 reporting of technology-specific attributes. As stated in [RFC8231], 285 the construct is further composed of a compulsory Explicit 286 Route Object (ERO) and a compulsory attribute-list and an optional 287 Record Route Object (RRO). In order to report LSP states in GMPLS 288 networks, this specification allows the use within a PCRpt message 289 both of technology- and GMPLS-specific attribute objects and TLVs 290 defined in [PCEP-GMPLS] as follows: 292 o Include Route Object (IRO)/ Exclude Route Object (XRO) 293 Extensions to support the inclusion/exclusion of labels and 294 label sub-objects for GMPLS. (See Section 2.6 and 2.7 in [PCEP- 295 GMPLS]) 297 o END-POINTS (Generalized END-POINTS Object Type. See Section 2.5 298 in [PCEP-GMPLS]) 300 o BANDWIDTH (Generalized BANDWIDTH Object Type. See Section 2.3 301 in [PCEP-GMPLS]) 303 o LSPA (PROTECTION ATTRIBUTE TLV, See Section 2.8 in [PCEP-GMPLS]. 305 The END-POINTS object SHOULD be carried within the attribute-list to 306 specify the endpoints pertaining to the reported LSP. The XRO object 307 MAY be carried to specify the network resources that the reported 308 LSP avoids and a PCE SHOULD consider avoid these network resources 309 during the process of re-optimizing after this LSP is delegated to 310 the PCE. To be more specific, the is updated as 311 follows using the notations of [RFC5511]: 313 ::= [] 314 [] 315 [] 317 [] 318 [] 319 [] 321 ::= [] 323 If the LSP being reported protects another LSP, the PROTECTION- 324 ATTRIBUTE TLV [PCEP-GMPLS] MUST be included in the LSPA object to 325 describe its attributes and restrictions. Moreover, if the status of 326 the protecting LSP changes from non-operational to operational, the 327 PCC SHOULD synchronize the state change of the LSPs to the stateful 328 PCE using a PCRpt message. This use case arises, for example, when 329 the protecting LSP becomes operational due to the failure of the 330 primary LSP. 332 5.3. LSP Delegation and Cleanup 334 LSP delegation and cleanup procedure specified in [RFC8231] are 335 equally applicable to GMPLS LSPs and this document does not modify 336 the associated usage. 338 5.4. LSP Operations in Stateful PCEP for GMPLS 340 Both passive and active stateful PCE mechanism in [RFC8231] are 341 applicable in GMPLS-controlled networks. 343 5.4.1. LSP Update in GMPLS-controlled Networks 345 [RFC8231] defines the Path Computation LSP Update Request (PCUpd) 346 message to enable to update the attributes of an LSP. However, 347 [RFC8231] does not define technology-specific parameters. 349 A key element of the PCUpd message is the attribute-list construct 350 defined in [RFC5440] and extended by many other PCEP specifications. 352 For GMPLS purposes we note that the BANDWIDTH object used in the 353 attribute-list is defined in [PCEP-GMPLS]. Furthermore, additional 354 TLVs are defined for the LSPA object in [PCEP-GMPLS] and MAY be 355 included to indicate technology-specific attributes. There are other 356 technology-specific attributes that need to be conveyed in the 357 of the construct in the PCUpd 358 message. Note that these path details in the PCUpd message are the 359 same as the of the PCRep message. See Section 5.3 360 for the details. 362 5.4.2. LSP Initiation in GMPLS-controlled Networks 364 PCInitiate message defined in [RFC8281] needs to be extended in 365 GMPLS network to support the LSP initiation. The extension includes 366 the following objects: 368 6. Modification of Existing PCEP Messages and Procedures 370 [Editor Notes]: the whole section would need re-working, the 371 objective is to indicate the RBNF model for the PCEP extension, 372 especially where new objects and TLVs are specified. 374 One of the advantages mentioned in [RFC8051] is that the stateful 375 nature of a PCE simplifies the information conveyed in PCEP messages, 376 notably between PCC and PCE, since it is possible to refer to PCE 377 managed state for active LSPs. To be more specific, with a stateful 378 PCE, it is possible to refer to an LSP with a unique identifier in 379 the scope of the PCC-PCE session and thus use such identifier to 380 refer to that LSP. Note this is also applicable to packet networks. 382 6.1. Modification for LSP Re-optimization 384 The Request Parameters (RP) object on a Path Computation Request 385 (PCReq) message carries the R bit. When set, this indicates that 386 the PCC is requesting re-optimization of an existing LSP. Upon 387 receiving such a PCReq, a stateful PCE SHOULD perform the re- 388 optimization in the following cases: 390 o The existing bandwidth and route information of the LSP to be 391 re-optimized is provided in the PCReq message using the 392 BANDWIDTH object and the ERO. 394 o The existing bandwidth and route information is not supplied 395 in the PCReq message, but can be found in the PCE's LSP-DB. 396 In this case, the LSP MUST be identified using an LSP 397 identifier carried in the PCReq message, and that fact 398 requires that the LSP identifier was previously supplied 399 either by the PCC in a PCRpt message or by the PCE in a PCRep 400 message. [RFC8231] defines how this is achieved using a 401 combination of the per-node LSP identifier (PLSP-ID) and the 402 PCC's address. 404 If no LSP state information is available to carry out re- 405 optimization, the stateful PCE should report the error "LSP state 406 information unavailable for the LSP re-optimization" (Error Type = 407 TBD1, Error value= TBD2). 409 6.2. Modification for Route Exclusion 411 [RFC5521] defines a mechanism for a PCC to request or demand that 412 specific nodes, links, or other network resources are excluded from 413 paths computed by a PCE. A PCC may wish to request the computation 414 of a path that avoids all link and nodes traversed by some other LSP. 416 To this end this document defines a new sub-object for use with 417 route exclusion defined in [RFC5521]. The LSP exclusion sub-object 418 is as follows: 420 0 1 2 3 421 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 422 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 423 |X|Type (TBD3) | Length | Attributes | Flag | 424 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 425 | | 426 // Symbolic Path Name // 427 | | 428 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 430 X bit and Attribute fields are defined in [RFC5521]. 432 Type: Subobject Type for an LSP exclusion sub-object. Value of 433 TBD3. To be assigned by IANA. 435 Length: The Length contains the total length of the subobject in 436 bytes, including the Type and Length fields. 438 Flags: This field may be used to further specify the exclusion 439 constraint with regard to the LSP. Currently, no values are 440 defined. 442 Symbolic Path Name: This is the identifier given to an LSP and is 443 unique in the context of the PCC address as defined in [RFC8231]. 445 Reserved: MUST be transmitted as zero and SHOULD be ignored on 446 receipt. 448 This sub-object is OPTIONAL in the exclude route object (XRO) and 449 can be present multiple times. When a stateful PCE receives a PCReq 450 message carrying this sub-object, it SHOULD search for the 451 identified LSP in its LSP-DB and then exclude from the new path 452 computation all resources used by the identified LSP. If the 453 stateful PCE cannot recognize one or more of the received LSP 454 identifiers, it should send an error message PCErr reporting "The 455 LSP state information for route exclusion purpose cannot be found" 456 (Error-type = TBD1, Error-value = TBD4). Optionally, it may provide 457 with the unrecognized identifier information to the requesting PCC 458 using the error reporting techniques described in [RFC5440]. 460 6.2.1. Modification for SRP Object 462 The format of the SRP object is defined in [RFC8231]. The object is 463 used in PCUpd and PCInitiate messages for GMPLS. 465 This document defines a new flag to be carried in the Flags field of 466 the SRP object. This flag indicates a bidirectional co-routed LSP 467 setup operation initiated by the PCE as follows: 469 o B (Bidirectional LSP -- 1 bit): If set to 0, it indicates a 470 request to create a uni-directional LSP. If set to 1, it 471 indicates a request to create a bidirectional co-routed LSP. 473 The bit position is TBD5 as assigned by IANA (see Section 5.3) 475 7. PCEP Object Extensions 477 7.1. Generalized Endpoint 479 This document does not modify the usage of END-POINTS object for PCE 480 initiated LSPs as specified in [RFC8281] . It augments the usage as 481 specified below. 483 END-POINTS object has been extended by [PCEP-GMPLS] to include a new 484 object type called "Generalized Endpoint". PCInitiate message sent 485 by a PCE to a PCC to trigger a GMPLS LSP instantiation SHOULD 486 include the END-POINTS with Generalized Endpoint object type. 487 Furthermore, the END-POINTS object MUST contain "label request" TLV. 488 The label request TLV is used to specify the switching type, 489 encoding type and G-PID of the LSP being instantiated by the PCE. 491 If the END-POINTS Object of type Generalized Endpoint is missing the 492 label request TLV, the PCC MUST send a PCErr message with Error- 493 type=6 (Mandatory Object missing) and Error-value= TBA (label 494 request TLV missing). 496 If the PCC does not support the END-POINTS Object of type 497 Generalized Endpoint, the PCC MUST send a PCErr message with Error- 498 type = 3(Unknown Object), Error-value = 2(unknown object type). 500 The unnumbered endpoint TLV can be used to specify unnumbered 501 endpoint addresses for the LSP being instantiated by the PCE. The 502 END-POINTS MAY contain other TLVs defined in [PCEP-GMPLS]. 504 7.2. GENERALIZED-BANDWIDTH object 506 LSP initiate message defined in [RFC8281] can optionally include the 507 BANDWIDTH object. However, the following possibilities cannot be 508 represented in the BANDWIDTH object: 510 o Asymmetric bandwidth (different bandwidth in forward and 511 reverse direction), as described in [RFC6387]. 513 o Technology specific GMPLS parameters (e.g., Tspec for 514 SDH/SONET, G.709, ATM, MEF, etc.) are not supported. 516 GENERALIZED-BANDWIDTH object has been defined in [PCEP-GMPLS] to 517 address the above-mentioned limitation of the BANDWIDTH object. 519 This document specifies the use of GENERALIZED-BANDWIDTH object in 520 PCInitiate message. Specifically, GENERALIZED-BANDWIDTH object MAY 521 be included in the PCInitiate message. The GENERALIZED-BANDWIDTH 522 object in PCInitiate message is used to specify technology specific 523 Tspec and asymmetrical bandwidth values for the LSP being 524 instantiated by the PCE. 525 7.3. The LSP Protection Information 527 LSPA in the PCEP message can be used to specify protection 528 attributes of the LSP being instantiated by the stateful PCE. 530 7.4. ERO Extension 532 GMPLS network does not have special requirement on modifying the 533 usage of ERO object for stateful PCEP in [RFC8231] and PCE initiated 534 LSPs as specified in [RFC8281]. It augments the usage as specified 535 in the following sections. 537 7.4.1. ERO with explicit label control 539 As mentioned earlier, there are technologies and scenarios where 540 active stateful PCE requires explicit label control in order to 541 instantiate an LSP. 543 Explicit label control (ELC) is a procedure supported by RSVP-TE, 544 where the outgoing label(s) is (are) encoded in the ERO. [PCEP-GMPLS] 545 extends the ERO object of PCEP to include explicit label control. 546 The ELC procedure enables the PCE to provide such label(s) directly 547 in the path ERO. 549 The extended ERO object in PCInitiate message can be used to specify 550 label along with ERO to PCC for the LSP being instantiated by the 551 active stateful PCE. 553 7.4.2. ERO with Path Keys 555 There are many scenarios in packet and optical networks where the 556 route information of an LSP may not be provided to the PCC for 557 confidentiality reasons. A multi-domain or multi-layer network is 558 an example of such networks. Similarly, a GMPLS User- Network 559 Interface (UNI) [RFC4208] is also an example of such networks. 561 In such scenarios, ERO containing the entire route cannot be 562 provided to PCC (by PCE). Instead, PCE provides an ERO with Path 563 Keys to the PCC. For example, in the case UNI interface between the 564 router and the optical nodes, the ERO in the LSP Initiate Message 565 may be constructed as follows: 567 o The first hop is a strict hop that provides the egress 568 interface information at PCC. This interface information is 569 used to get to a network node that can extend the rest of the 570 ERO. (Please note that in the cases where the network node is 571 not directly connected with the PCC, this part of ERO may 572 consist of multiple hops and may be loose). 574 o The following(s) hop in the ERO may provide the network node 575 with the path key [RFC5520] that can be resolved to get the 576 contents of the route towards the destination. 578 o There may be further hops but these hops may also be encoded 579 with the path keys (if needed). 581 This document does not change encoding or processing roles for the 582 path keys, which are defined in [RFC5520]. 584 7.5. Switch Layer Object 586 [I-D.ietf-pce-inter-layer-ext] specifies the SWITCH-LAYER object 587 which defines and specifies the switching layer (or layers) in which 588 a path MUST or MUST NOT be established. A switching layer is 589 expressed as a switching type and encoding type. [PCEP-GMPLS], which 590 defines the GMPLS extensions for PCEP, suggests using the SWITCH- 591 LAYER object. Thus, SWITCH-LAYER object can be used in the 592 PCInitiate message to specify the switching layer (or layers) of the 593 LSP being remotely initiated. 595 8. IANA Considerations 597 8.1. New PCEP Error Codes 599 IANA is requested to make the following allocation in the "PCEP- 600 ERROR Object Error Types and Values" registry. 602 Error Type Meaning Reference 604 TBD1 LSP state information missing [This.I-D] 606 Error-value TBD2: LSP state information unavailable [This.I-D] 607 for the LSP re-optimization 609 Error-value TBD4: LSP state information for route 610 exclusion purpose cannot be found [This.I-D] 612 This document defines the following new Error-Value: 614 Error-Type Error-Value Reference 616 6 Error-value TBD5: Label Request TLV 617 missing [This.I-D] 619 8.2. New Subobject for the Exclude Route Object 621 IANA maintains the "PCEP Parameters" registry containing a 622 subregistry called "PCEP Objects". This registry has a subregistry 623 for the XRO (Exclude Route Object) listing the sub-objects that can 624 be carried in the XRO. IANA is requested to assign a further sub- 625 object that can be carried in the XRO as follows: 627 Value Description Reference 629 ----------+------------------------------+------------- 631 TBD3 LSP identifier sub-object [This.I-D] 633 8.3. New "B" Flag in the SRP Object 635 IANA maintains a subregistry, named the "SRP Object Flag Field", 636 within the "Path Computation Element Protocol (PCEP) Numbers" 637 registry, to manage the Flag field of the SRP object. 639 IANA is requested to make an assignment from this registry as 640 follows: 642 Bit Description Reference 643 --- ---------------------------- ---------- 645 TDB5 Bi-directional co-routed LSP [This.I-D] 647 9. Manageability Considerations 649 The description and functionality specifications presented related 650 to stateful PCEs should also comply with the manageability 651 specifications covered in Section 8 of [RFC4655]. Furthermore, a 652 further list of manageability issues presented in [RFC8231] should 653 also be considered. 655 Additional considerations are presented in the next Update. 657 9.1. Requirements on Other Protocols and Functional Components 659 When the detailed route information is included for LSP state 660 synchronization (either at the initial stage or during LSP state 661 report process), this requires the ingress node of an LSP carry the 662 RRO object in order to enable the collection of such information. 664 10. Security Considerations 666 This draft provides additional extensions to PCEP so as to 667 facilitate stateful PCE usage in GMPLS-controlled networks, on top 668 of [RFC8231]. The PCEP extensions to support GMPLS-controlled 669 networks should be considered under the same security as for MPLS 670 networks, as noted in [RFC7025]. Therefore, the security 671 considerations elaborated in [RFC5440] still apply to this draft. 672 Furthermore, [RFC8231] provides a detailed analysis of the 673 additional security issues incurred due to the new extensions and 674 possible solutions needed to support for the new stateful PCE 675 capabilities and they apply to this document as well. 677 11. Acknowledgement 679 We would like to thank Adrian Farrel, Cyril Margaria, George Swallow 680 and Jan Medved for the useful comments and discussions. 682 12. References 684 12.1. Normative References 686 [RFC2119] Bradner, S., "Key words for use in RFCs to indicate 687 requirements levels", RFC 2119, March 1997. 689 [RFC4655] Farrel, A., Vasseur, J.-P., and Ash, J., "A Path 690 Computation Element (PCE)-Based Architecture", RFC 4655, 691 August 2006. 693 [RFC5440] Vasseur, J.-P., and Le Roux, JL., "Path Computation 694 Element (PCE) Communication Protocol (PCEP)", RFC 5440, 695 March 2009. 697 [RFC8174] B. Leiba, "Ambiguity of Uppercase vs Lowercase in RFC 2119 698 Key Words", RFC 8174, May 2017. 700 [RFC8231] Crabbe, E., Medved, J., Varga, R., Minei, I., "Path 701 Computation Element Communication Protocol (PCEP) 702 Extensions for Stateful PCE", RFC 8231, September 2017. 704 [RFC8281] Crabbe, E., Minei, I., Sivabalan, S., and R. Varga, "Path 705 Computation Element Communication Protocol (PCEP) 706 Extensions for PCE-Initiated LSP Setup in a Stateful PCE 707 Model", RFC 8281, December 2017. 709 [PCEP-GMPLS] Margaria, C., Gonzalez de Dios, O., Zhang, F., "PCEP 710 extensions for GMPLS", draft-ietf-pce-gmpls-pcep- 711 extensions, work in progress. 713 12.2. Informative References 715 [RFC5511] A. Farrel, "Routing Backus-Naur Form (RBNF): A Syntax Used 716 to Form Encoding Rules in Various Routing Protocol 717 Specifications", RFC 5511, April 2009. 719 [RFC8051] Zhang, X., Minei, I., et al, "Applicability of Stateful 720 Path Computation Element (PCE) ", RFC 8051, January 2017. 722 [RFC8232] Crabbe, E., Minei, I., Medved, J., Varga, R., Zhang, X., 723 and D. Dhody, "Optimizations of Label Switched Path State 724 Synchronization Procedures for a Stateful PCE", RFC 8232, 725 September 2017. 727 [I-D.ietf-pce-inter-layer-ext] Oki, E., Takeda, T., Farrel, A., and 728 F. Zhang, "Extensions to the Path Computation Element 729 communication Protocol (PCEP) for Inter-Layer MPLS and 730 GMPLS Traffic Engineering", draft-ietf-pce-inter-layer-ext. 731 work in progress. 733 [RFC3471] Berger, L., Ed., "Generalized Multi-Protocol Label 734 Switching (GMPLS) Signaling Functional Description", RFC 735 3471, January 2003. 737 [RFC3473] Berger, L., Ed., "Generalized Multi-Protocol Label 738 Switching (GMPLS) Signaling Resource ReserVation Protocol 739 Traffic Engineering (RSVP-TE) Extensions", RFC 3473, 740 January 2003. 742 [RFC3477] Kompella, K. and Y. Rekhter, "Signalling Unnumbered Links 743 in Resource ReSerVation Protocol - Traffic Engineering 744 (RSVP-TE)", RFC 3477, January 2003. 746 [RFC4208] Swallow, G., Drake, J., Ishimatsu, H., and Y. Rekhter, 747 "Generalized Multiprotocol Label Switching (GMPLS) User 748 Network Interface (UNI): Resource ReserVation Protocol- 749 Traffic Engineering (RSVP-TE) Support for the Overlay 750 Model", RFC 4208, October 2005. 752 [RFC4872] Lang, J., Ed., Rekhter, Y., Ed., and D. Papadimitriou, 753 Ed., "RSVP-TE Extensions in Support of End-to-End 754 Generalized Multi-Protocol Label Switching (GMPLS) 755 Recovery", RFC 4872, May 2007. 757 [RFC4873] Berger, L., Bryskin, I., Papadimitriou, D., and A. Farrel, 758 "GMPLS Segment Recovery", RFC 4873, May 2007. 760 [RFC5520] Bradford, R., Ed., Vasseur, JP., and A. Farrel, 761 "Preserving Topology Confidentiality in Inter-Domain Path 762 Computation Using a Path-Key-Based Mechanism", RFC 5520, 763 April 2009. 765 [RFC6387] Takacs, A., Berger, L., Caviglia, D., Fedyk, D., and J. 766 Meuric, "GMPLS Asymmetric Bandwidth Bidirectional Label 767 Switched Paths (LSPs)", RFC 6387, September 2011. 769 13. Contributors' Address 771 Xian Zhang 772 Huawei Technologies 773 F1 R&D Center, Huawei Base 774 Bantian, Longgang District 775 Shenzhen 518129 P.R.China 777 Phone: +86-755-28972645 778 Email: zhang.xian@huawei.com 780 Dhruv Dhody 781 Huawei Technology 782 India 783 Email: dhruv.ietf@gmail.com 785 Yi Lin 786 Huawei Technologies 787 Email: yi.lin@huawei.com 789 Fatai Zhang 790 Huawei Technologies 791 Email: zhangfatai@huawei.com 793 Ramon Casellas 794 CTTC 795 Av. Carl Friedrich Gauss n7 796 Castelldefels, Barcelona 08860 797 Spain 798 Email: ramon.casellas@cttc.es 800 Siva Sivabalan 801 Cisco Systems 802 Email: msiva@cisco.com 804 Clarence Filsfils 805 Cisco Systems 806 Email: cfilsfil@cisco.com 807 Robert Varga 808 Pantheon Technologies 809 Email: nite@hq.sk 811 Authors' Addresses 813 Young Lee (Editor) 814 Sung Kyun Kwan University (SKKU) 815 Email: younglee.tx@gmail.com 817 Haomian Zheng (Editor) 818 Huawei Technologies 819 H1-1-A043S Huawei Industrial Base, Songshanhu 820 Dongguan, Guangdong 523808 821 P.R.China 823 Email: zhenghaomian@huawei.com 825 Oscar Gonzalez de Dios 826 Telefonica Investigacion y Desarrollo 827 Phone: +34 913374013 828 Email: oscar.gonzalezdedios@telefonica.com 830 Victor Lopez 831 Telefonica 832 Email: victor.lopezalvarez@telefonica.com 834 Zafar Ali 835 Cisco Systems 836 Email: zali@cisco.com