idnits 2.17.1 draft-ietf-pce-pcep-stateful-pce-gmpls-07.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == Line 41 has weird spacing: '... months and ...' == Line 42 has weird spacing: '... at any time...' == Line 43 has weird spacing: '...ference mate...' == Line 295 has weird spacing: '...orm the re-...' == Line 376 has weird spacing: '... P flag and...' -- The document date (February 13, 2018) is 2263 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 114, but not defined == Missing Reference: 'RFC7399' is mentioned on line 121, but not defined == Missing Reference: 'RFC5521' is mentioned on line 349, but not defined == Missing Reference: 'RFC7025' is mentioned on line 441, but not defined ** Downref: Normative reference to an Informational RFC: RFC 4655 Summary: 1 error (**), 0 flaws (~~), 10 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 PCE Working Group Xian Zhang 2 Internet-Draft Young Lee (Editor) 3 Intended status: Standards Track Fatai Zhang 4 Huawei 5 Ramon Casellas 6 CTTC 7 Oscar Gonzalez de Dios 8 Telefonica I+D 9 Zafar Ali 10 Cisco Systems 12 Expires: August 13, 2018 February 13, 2018 14 Path Computation Element (PCE) Protocol Extensions for Stateful PCE 15 Usage in GMPLS-controlled Networks 17 draft-ietf-pce-pcep-stateful-pce-gmpls-07.txt 19 Abstract 21 The Path Computation Element (PCE) facilitates Traffic Engineering 22 (TE) based path calculation in large, multi-domain, multi-region, or 23 multi-layer networks. The PCE communication Protocol (PCEP) has been 24 extended to support stateful PCE functions where the PCE retains 25 information about the paths already present in the network, but 26 those extensions are technology-agnostic. This memo provides 27 extensions required for PCEP so as to enable the usage of a stateful 28 PCE capability in GMPLS-controlled networks. 30 Status of this Memo 32 This Internet-Draft is submitted to IETF in full conformance with 33 the provisions of BCP 78 and BCP 79. 35 Internet-Drafts are working documents of the Internet Engineering 36 Task Force (IETF), its areas, and its working groups. Note that 37 other groups may also distribute working documents as Internet- 38 Drafts. 40 Internet-Drafts are draft documents valid for a maximum of six 41 months and may be updated, replaced, or obsoleted by other 42 documents at any time. It is inappropriate to use Internet-Drafts 43 as reference material or to cite them other than as "work in 44 progress." 46 The list of current Internet-Drafts can be accessed at 47 http://www.ietf.org/ietf/1id-abstracts.txt. 49 The list of Internet-Draft Shadow Directories can be accessed at 50 http://www.ietf.org/shadow.html. 52 This Internet-Draft will expire on August 13, 2018. 54 Copyright Notice 56 Copyright (c) 2018 IETF Trust and the persons identified as the 57 document authors. All rights reserved. 59 This document is subject to BCP 78 and the IETF Trust's Legal 60 Provisions Relating to IETF Documents 61 (http://trustee.ietf.org/license-info) in effect on the date of 62 publication of this document. Please review these documents 63 carefully, as they describe your rights and restrictions with 64 respect to this document. Code Components extracted from this 65 document must include Simplified BSD License text as described in 66 Section 4.e of the Trust Legal Provisions and are provided without 67 warranty as described in the Simplified BSD License. 69 Conventions used in this document 71 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 72 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 73 document are to be interpreted as described in RFC-2119 [RFC2119]. 75 Table of Contents 77 Table of Contents.................................................2 78 1. Introduction...................................................3 79 2. Context of Stateful PCE and PCE for GMPLS......................3 80 3. Main Requirements..............................................4 81 4. PCEP Extensions................................................5 82 4.1. LSP Update in GMPLS-controlled Networks...................5 83 4.2. LSP Synchronization in GMPLS-controlled Networks..........5 84 4.3. Modification of Existing PCEP Messages and Procedures.....7 85 4.3.1. Modification for LSP Re-optimization.................7 86 4.3.2. Modification for Route Exclusion.....................7 87 4.4. Object Encoding...........................................9 89 5. IANA Considerations............................................9 90 5.1. New PCEP Error Codes......................................9 91 5.2. New Subobject for the Exclude Route Object................9 92 6. Manageability Considerations..................................10 93 6.1. Requirements on Other Protocols and Functional Components10 94 7. Security Considerations.......................................10 95 8. Acknowledgement...............................................10 96 9. References....................................................10 97 9.1. Normative References.....................................10 98 9.2. Informative References...................................11 99 10. Contributors' Address........................................11 100 Authors' Addresses...............................................12 102 1. Introduction 104 [RFC4655] presents the architecture of a Path Computation Element 105 (PCE)-based model for computing Multiprotocol Label Switching (MPLS) 106 and Generalized MPLS (GMPLS) Traffic Engineering Label Switched 107 Paths (TE LSPs). To perform such a constrained computation, a PCE 108 stores the network topology (i.e., TE links and nodes) and resource 109 information (i.e., TE attributes) in its TE Database (TED). Such a 110 PCE is usually referred as a stateless PCE. To request path 111 computation services to a PCE, [RFC5440] defines the PCE 112 communication Protocol (PCEP) for interaction between a Path 113 Computation Client (PCC) and a PCE, or between two PCEs. PCEP as 114 specified in [RFC 5440] mainly focuses on MPLS networks and the PCEP 115 extensions needed for GMPLS-controlled networks are provided in 116 [PCEP-GMPLS]. 118 Stateful PCEs are shown to be helpful in many application scenarios, 119 in both MPLS and GMPLS networks, as illustrated in [RFC8051]. 120 Further discussion of concept of a stateful PCE can be found in 121 [RFC7399]. In order for these applications to able to exploit the 122 capability of stateful PCEs, extensions to PCEP are required. 124 [RFC8231] provides the fundamental extensions needed for stateful 125 PCE to support general functionality, but leaves out the 126 specification for technology-specific objects/TLVs. This document 127 focuses on the extensions that are necessary in order for the 128 deployment of stateful PCEs in GMPLS-controlled networks. 130 2. Context of Stateful PCE and PCEP for GMPLS 132 This document is built on the basis of Stateful PCE [RFC8231] and 133 PCEP for GMPLS [PCEP-GMPLS]. 135 There are two types of LSP operation for Stateful PCE. 137 For Active Stateful PCE, PCUpd message is sent from PCE to PCC to 138 update the LSP state for the LSP delegated to PCE. Any changes to 139 the delegated LSPs generate a PCRpt message by the PCC to PCE to 140 convey the changes of the LSP. Any modifications to the Objects/TLVs 141 that are identified in this document to support GMPLS technology- 142 specific attributes will be carried in the PCRpt and PCUpd messages. 144 For Passive Stateful PCE where PCReq/PCRep messages are used to 145 convey path computation instruction. As GMPLS-technology specific 146 Objects/TLVs are defined in [PCEP-GMPLS], this document just points 147 to the work in [PCEP-GMPLS] and add only the stateful PCE aspect 148 only if applicable. Passive Stateful PCE makes use of PCRep messages 149 when reporting LSP State changes sent by PCC to PCEs. Any 150 modifications to the Objects/TLVs that are identified in this 151 document to support GMPLS technology-specific attributes will be 152 carried in the PCRpt message. 154 [PCEP-GMPLS] defines GMPLS-technology specific Objects/TLVs and this 155 document makes use of these Objects/TLVs without modifications where 156 applicable. Some of these Objects/TLVs may require modifications to 157 incorporate stateful PCE element where applicable. 159 3. Main Requirements 161 This section notes the main functional requirements for PCEP 162 extensions to support stateful PCE for use in GMPLS-controlled 163 networks, based on the description in [RFC8051]. Many 164 requirements are common across a variety of network types (e.g., 165 MPLS-TE networks and GMPLS networks) and the protocol extensions to 166 meet the requirements are already described in [RFC8231]. This 167 document does not repeat the description of those protocol 168 extensions. This document presents protocol extensions for a set of 169 requirements which are specific to the use of a stateful PCE in a 170 GMPLS-controlled network. 172 The basic requirements are as follows: 174 o Advertisement of the stateful PCE capability. This generic 175 requirement is covered in Section 5.7. of [RFC8231]. This 176 document does not provide any further extensions. 178 o LSP delegation is already covered in Section 5.7. of [RFC8231]. 179 Section 2.2. of this document does not provide any further 180 extensions. 182 o Active LSP update is covered in Section 6.2 of [RFC8231]. Section 183 4.1. of this document provides extension for its application in 184 GMPLS-controlled networks. 186 o LSP state synchronization and LSP state report. This is a generic 187 requirement already covered in Section 5.6. of [RFC8231]. However, 188 there are further extensions required specifically for GMPLS- 189 controlled networks and discussed in Section 4.2. 191 4. PCEP Extensions 193 4.1. LSP Update in GMPLS-controlled Networks 195 [RFC8231] defines the Path Computation LSP Update Request (PCUpd) 196 message to enable to update the attributes of an LSP. However, that 197 document does not define technology-specific parameters. 199 A key element of the PCUpd message is the attribute-list construct 200 defined in [RFC5440] and extended by many other PCEP specifications. 202 For GMPLS purposes we note that the BANDWIDTH object used in the 203 attribute-list is defined in [PCEP-GMPLS]. Furthermore, additional 204 TLVs are defined for the LSPA object in [PCEP-GMPLS] and MAY be 205 included to indicate technology-specific attributes. There are other 206 technology-specific attributes that need to be conveyed in the 207 of the object of the PCUpd message. 208 Note that these path details in the PCUpd message are the same as 209 the of the PCRep message. See Section 4.2 for the 210 details. 212 LSP parameter update controlled by a stateful PCE in a multi-domain 213 network is complex and requires well-defined operational procedures 214 as well as protocol design and is out of scope of this document and 215 left for further study. 217 4.2. LSP Synchronization in GMPLS-controlled Networks 219 PCCs need to report the attributes of LSPs to the PCE to enable 220 stateful operation of a GMPLS network. This process is known as 221 LSP state synchronization. The LSP attributes include bandwidth, 222 associated route, and protection information etc., are stored by the 223 PCE in the LSP database (LSP-DB). Note that, as described in 224 [RFC8231], the LSP state synchronization covers both the bulk 225 reporting of LSPs at initialization as well the reporting of new or 226 modified LSP during normal operation. Incremental LSP-DB 227 synchronization may be desired in a GMPLS-controlled network and it 228 is specified in [RFC8232]. 230 [RFC8231] describes mechanisms for LSP synchronization using the 231 Path Computation State Report (PCRpt) message, but does not cover 232 reporting of technology-specific attributes. As stated in [RFC8231], 233 the construct is further composed of a compulsory ERO object 234 and a compulsory attribute-list and an optional RRO object. In order 235 to report LSP states in GMPLS networks, this specification allows 236 the use within a PCRpt message both of technology- and GMPLS- 237 specific attribute objects and TLVs defined in [PCEP-GMPLS] as 238 follows: 240 o IRO/XRO Extensions to support the inclusion/exclusion of labels 241 and label sub-objects for GMPLS. (See Section 2.6 and 2.7 in 242 [PCEP-GMPLS]) 244 o END-POINTS (Generalized END-POINTS Object Type. See Section 2.5 245 in [PCEP-GMPLS]) 247 o BANDWIDTH (Generalized BANDWIDTH Object Type. See Section 2.3 248 in [PCEP-GMPLS]) 250 o LSPA (PROTECTION ATTRIBUTE TLV, See Section 2.8 in [PCEP-GMPLS]. 252 o IF_ID_ERROR_SPEC (extending [RFC8231] section 7.3.4 that only 253 considers the use of RSVP ERROR_SPEC) 255 The END-POINTS object SHOULD be carried within the attribute-list to 256 specify the endpoints pertaining to the reported LSP. The XRO object 257 MAY be carried to specify the network resources that the reported 258 LSP avoids and a PCE SHOULD consider avoid these network resources 259 during the process of re-optimizing after this LSP is delegated to 260 the PCE. To be more specific, the is updated as 261 follows: 263 ::= [] 264 [] 265 [] 266 [] 267 [] 268 [] 270 ::= [] 272 If the LSP being reported protects another LSP, the PROTECTION- 273 ATTRIBUTE TLV [PCEP-GMPLS] MUST be included in the LSPA object to 274 describe its attributes and restrictions. Moreover, if the status 275 of the protecting LSP changes from non-operational to operational, 276 this SHOULD to be synchronized to the stateful PCE using a PCRpt 277 message. 279 4.3. Modification of Existing PCEP Messages and Procedures 281 One of the advantages mentioned in [RFC8051] is that the stateful 282 nature of a PCE simplifies the information conveyed in PCEP messages, 283 notably between PCC and PCE, since it is possible to refer to PCE 284 managed state for active LSPs. To be more specific, with a stateful 285 PCE, it is possible to refer to an LSP with a unique identifier in 286 the scope of the PCC-PCE session and thus use such identifier to 287 refer to that LSP. Note this MAY also be applicable to packet 288 networks. 290 4.3.1. Modification for LSP Re-optimization 292 The Request Parameters (RP) object on a Path Computation Request 293 (PCReq) message carries the R bit. When set, this indicates that 294 the PCC is requesting re-optimization of an existing LSP. Upon 295 receiving such a PCReq, a stateful PCE SHOULD perform the re- 296 optimization in the following cases: 298 o The existing bandwidth and route information of the LSP to be 299 re-optimized is provided in the PCReq message using the 300 BANDWIDTH object and the ERO. 302 o The existing bandwidth and route information is not supplied 303 in the PCReq message, but can be found in the PCE's LSP-DB. 304 In this case, the LSP MUST be identified using an LSP 305 identifier carried in the PCReq message, and that fact 306 requires that the LSP identifier was previously supplied 307 either by the PCC in a PCRpt message or by the PCE in a PCRep 308 message. [RFC8231] defines how this is achieved using a 309 combination of the per-node LSP identifier (PLSP-ID) and the 310 PCC's address. 312 If no LSP state information is available to carry out re- 313 optimization, the stateful PCE should report the error "LSP state 314 information unavailable for the LSP re-optimization" (Error Type = 315 TBD1, Error value= TBD2). 317 4.3.2. Modification for Route Exclusion 319 [RFC5521] defines a mechanism for a PCC to request or demand that 320 specific nodes, links, or other network resources are excluded from 321 paths computed by a PCE. A PCC may wish to request the computation 322 of a path that avoids all link and nodes traversed by some other LSP. 324 To this end this document defines a new sub-object for use with 325 route exclusion defined in [RFC5521]. The LSP exclusion sub-object 326 is as follows: 328 0 1 2 3 329 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 330 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 331 |X|Type (TBD3) | Length | Attributes | Flag | 332 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 333 | PLSP-ID | Reserved | 334 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 336 X bit and Attribute fields are defined in [RFC5521]. 338 X bit: indicates whether the exclusion is mandatory (X=1) and MUST 339 be accommodated, or desired (X=0) and SHOULD be accommodated. 341 Type: Subobject Type for an LSP exclusion sub-object. Value of 342 TBD3. To be assigned by IANA. 344 Length: The Length contains the total length of the subobject in 345 bytes, including the Type and Length fields. 347 Attributes: indicates how the exclusion object is to be 348 interpreted. Currently, Interface (Attributes = 0), Node 349 (Attributes =1) and SRLG (Attributes =2) are defined in [RFC5521] 350 and this document does not define new values. 352 Flags: This field may be used to further specify the exclusion 353 constraint with regard to the LSP. Currently, no values are 354 defined. 356 PLSP-ID: This is the identifier given to a LSP and is unique in 357 the context of the PCC address as defined in [RFC8231]. 359 Reserved: MUST be transmitted as zero and SHOULD be ignored on 360 receipt. 362 This sub-object is OPTIONAL in the exclude route object (XRO) and 363 can be present multiple times. When a stateful PCE receives a PCReq 364 message carrying this sub-object, it SHOULD search for the 365 identified LSP in its LSP-DB and then exclude it from the new path 366 computation all resources used by the identified LSP. If the 367 stateful PCE cannot recognize one or more of the received LSP 368 identifiers, it should send an error message PCErr reporting "The 369 LSP state information for route exclusion purpose cannot be found" 370 (Error-type = TBD1, Error-value = TBD4). Optionally, it may provide 371 with the unrecognized identifier information to the requesting PCC 372 using the error reporting techniques described in [RFC5440]. 374 4.4. Object Encoding 376 Note that, as is stated in Section 7 of [RFC8231], the P flag and 377 the I flag of the PCEP objects used on PCUpd and PCRpt messages 378 SHOULD be set to 0 on transmission and SHOULD be ignored on receipt 379 since these flags are exclusively related to path computation 380 requests. 382 5. IANA Considerations 384 IANA is requested to allocate new Types for the TLV/Object defined 385 in this document. 387 5.1. New PCEP Error Codes 389 IANA is requested to make the following allocation in the "PCEP- 390 ERROR Object Error Types and Values" registry. 392 Error Type Meaning Reference 394 TBD1 LSP state information missing [This.I-D] 396 Error-value TBD2: LSP state information unavailable [This.I-D] 398 for the LSP re-optimization 400 Error-value TBD4: LSP state information for route 402 exclusion purpose cannot be found [This.I-D] 404 5.2. New Subobject for the Exclude Route Object 406 IANA maintains the "PCEP Parameters" registry containing a 407 subregistry called "PCEP Objects". This registry has a subregistry 408 for the XRO (Exclude Route Object) listing the sub-objects that can 409 be carried in the XRO. IANA is requested to assign a further sub- 410 object that can be carried in the XRO as follows: 412 Value Description Reference 414 ----------+------------------------------+------------- 416 TBD3 LSP identifier sub-object [This.I-D] 418 6. Manageability Considerations 420 The description and functionality specifications presented related 421 to stateful PCEs should also comply with the manageability 422 specifications covered in Section 8 of [RFC4655]. Furthermore, a 423 further list of manageability issues presented in [RFC8231] should 424 also be considered. 426 Additional considerations are presented in the next sections. 428 6.1. Requirements on Other Protocols and Functional Components 430 When the detailed route information is included for LSP state 431 synchronization (either at the initial stage or during LSP state 432 report process), this requires the ingress node of an LSP carry the 433 RRO object in order to enable the collection of such information. 435 7. Security Considerations 437 This draft provides additional extensions to PCEP so as to 438 facilitate stateful PCE usage in GMPLS-controlled networks, on top 439 of [RFC8231]. The PCEP extensions to support GMPLS-controlled 440 networks should be considered under the same security as for MPLS 441 networks, as noted in [RFC7025]. Therefore, the security 442 considerations elaborated in [RFC5440] still apply to this draft. 443 Furthermore, [RFC8231] provides a detailed analysis of the 444 additional security issues incurred due to the new extensions and 445 possible solutions needed to support for the new stateful PCE 446 capabilities and they apply to this document as well. 448 8. Acknowledgement 450 We would like to thank Adrian Farrel and Cyril Margaria for the 451 useful comments and discussions. 453 9. References 455 9.1. Normative References 457 [RFC2119] Bradner, S., "Key words for use in RFCs to indicate 458 requirements levels", RFC 2119, March 1997. 460 [RFC4655] Farrel, A., Vasseur, J.-P., and Ash, J., "A Path 461 Computation Element (PCE)-Based Architecture", RFC 4655, 462 August 2006. 464 [RFC5440] Vasseur, J.-P., and Le Roux, JL., "Path Computation 465 Element (PCE) Communication Protocol (PCEP)", RFC 5440, 466 March 2009. 468 [RFC8231] Crabbe, E., Medved, J., Varga, R., Minei, I., "Path 469 Computation Element Communication Protocol (PCEP) 470 Extensions for Stateful PCE", RFC 8231, September 2017. 472 [PCEP-GMPLS] Margaria, C., Gonzalez de Dios, O., Zhang, F., "PCEP 473 extensions for GMPLS", draft-ietf-pce-gmpls-pcep- 474 extensions, work in progress. 476 9.2. Informative References 478 [RFC8051] Zhang, X., Minei, I., et al, "Applicability of Stateful 479 Path Computation Element (PCE) ", RFC 8051, January 2017. 481 [RFC8232] Crabbe, E., Minei, I., Medved, J., Varga, R., Zhang, X., 482 and D. Dhody, "Optimizations of Label Switched Path State 483 Synchronization Procedures for a Stateful PCE", RFC 8232, 484 September 2017. 486 10. Contributors' Address 488 Dhruv Dhody 489 Huawei Technology 490 Leela Palace 491 Bangalore, Karnataka 560008 492 INDIA 494 EMail: dhruvd@huawei.com 496 Yi Lin 497 Huawei Technologies 498 F3-5-B R&D Center, Huawei Base 499 Bantian, Longgang District 500 Shenzhen 518129 P.R.China 502 Phone: +86-755-28972914 503 Email: yi.lin@huawei.com 505 Authors' Addresses 507 Xian Zhang 508 Huawei Technologies 509 F3-5-B R&D Center, Huawei Base 510 Bantian, Longgang District 511 Shenzhen 518129 P.R.China 513 Phone: +86-755-28972645 514 Email: zhang.xian@huawei.com 516 Young Lee (Editor) 517 Huawei 518 5340 Legacy Drive, Suite 170 519 Plano, TX 75023 520 US 522 Phone: +1 469 278 5838 523 EMail: leeyoung@huawei.com 525 Fatai Zhang 526 Huawei 527 F3-5-B R&D Center, Huawei Base 528 Bantian, Longgang District 529 P.R. China 531 Phone: +86-755-28972912 532 Email: zhangfatai@huawei.com 534 Ramon Casellas 535 CTTC 536 Av. Carl Friedrich Gauss n7 537 Castelldefels, Barcelona 08860 538 Spain 540 Phone: 541 Email: ramon.casellas@cttc.es 543 Oscar Gonzalez de Dios 544 Telefonica Investigacion y Desarrollo 545 Emilio Vargas 6 546 Madrid, 28045 547 Spain 549 Phone: +34 913374013 550 Email: ogondio@tid.es 552 Zafar Ali 553 Cisco Systems 554 Email: zali@cisco.com