idnits 2.17.1 draft-ietf-pce-pcep-stateful-pce-gmpls-04.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 is 1 instance 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 == Line 41 has weird spacing: '... months and ...' == Line 42 has weird spacing: '... at any time...' == Line 43 has weird spacing: '...ference mate...' -- The document date (October 16, 2015) is 3114 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 112, but not defined == Missing Reference: 'RFC7399' is mentioned on line 119, but not defined == Missing Reference: 'RFC5521' is mentioned on line 312, but not defined == Missing Reference: 'RFC7025' is mentioned on line 403, but not defined ** Downref: Normative reference to an Informational RFC: RFC 4655 Summary: 2 errors (**), 0 flaws (~~), 8 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 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: April 13, 2016 October 16, 2015 14 Path Computation Element (PCE) Protocol Extensions for Stateful PCE 15 Usage in GMPLS-controlled Networks 17 draft-ietf-pce-pcep-stateful-pce-gmpls-04.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 April 13, 2016. 54 Copyright Notice 56 Copyright (c) 2015 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. PCEP Extensions ............................................. 3 80 2.1. Overview of Requirements................................ 3 81 2.2. LSP Delegation in GMPLS-controlled Networks .............4 82 2.3. LSP Synchronization in GMPLS-controlled Networks.........5 83 2.4. Modification of Existing PCEP Messages and Procedures....6 84 2.4.1. Modification for LSP Re-optimization ...............6 85 2.4.2. Modification for Route Exclusion ...................7 86 2.5. Object Encoding......................................... 8 87 3. IANA Considerations ......................................... 8 88 3.1. New PCEP Error Codes.................................... 8 89 3.2. New Subobject for the Exclude Route Object ..............9 90 4. Manageability Considerations................................. 9 91 4.1. Requirements on Other Protocols and Functional Components 9 92 5. Security Considerations...................................... 9 93 6. Acknowledgement ............................................ 10 94 7. References ................................................. 10 95 7.1. Normative References................................... 10 96 7.2. Informative References................................. 10 97 8. Contributors' Address....................................... 11 98 Authors' Addresses ............................................ 12 100 1. Introduction 102 [RFC4655] presents the architecture of a Path Computation Element 103 (PCE)-based model for computing Multiprotocol Label Switching (MPLS) 104 and Generalized MPLS (GMPLS) Traffic Engineering Label Switched 105 Paths (TE LSPs). To perform such a constrained computation, a PCE 106 stores the network topology (i.e., TE links and nodes) and resource 107 information (i.e., TE attributes) in its TE Database (TED). Such a 108 PCE is usually referred as a stateless PCE. To request path 109 computation services to a PCE, [RFC5440] defines the PCE 110 communication Protocol (PCEP) for interaction between a Path 111 Computation Client (PCC) and a PCE, or between two PCEs. PCEP as 112 specified in [RFC 5440] mainly focuses on MPLS networks and the PCEP 113 extensions needed for GMPLS-controlled networks are provided in 114 [PCEP-GMPLS]. 116 Stateful PCEs are shown to be helpful in many application scenarios, 117 in both MPLS and GMPLS networks, as illustrated in [Stateful-APP]. 118 Further discussion of concept of a stateful PCE can be found in 119 [RFC7399]. In order for these applications to able to exploit the 120 capability of stateful PCEs, extensions to PCEP are required. 122 [Stateful-PCE] provides the fundamental extensions needed for 123 stateful PCE to support general functionality, but leaves out the 124 specification for technology-specific objects/TLVs. This document 125 focuses on the extensions that are necessary in order for the 126 deployment of stateful PCEs in GMPLS-controlled networks. 128 2. PCEP Extensions 130 2.1. Overview of Requirements 131 This section notes the main functional requirements for PCEP 132 extensions to support stateful PCE for use in GMPLS-controlled 133 networks, based on the description in [Stateful-APP]. Many 134 requirements are common across a variety of network types (e.g., 135 MPLS-TE networks and GMPLS networks) and the protocol extensions to 136 meet the requirements are already described in [Stateful-PCE]. This 137 document does not repeat the description of those protocol 138 extensions. This document presents protocol extensions for a set of 139 requirements which are specific to the use of a stateful PCE in a 140 GMPLS-controlled network. 142 The basic requirements are as follows: 144 o Advertisement of the stateful PCE capability. This generic 145 requirement is covered in Section 7.1.1. of [Stateful-PCE]. This 146 document does not provide any further extensions. 148 o LSP delegation is already covered in Section 5.5. of [Stateful- 149 PCE]. Section 2.3. of this document provides extension for its 150 application in GMPLS-controlled networks. Moreover, further 151 discussion of some generic details that need additional 152 consideration is provided. 154 o LSP state synchronization and LSP state report. This is a generic 155 requirement already covered in Section 5.4. of [Stateful-PCE]. 156 However, there are further extensions required specifically for 157 GMPLS-controlled networks and discussed in Section 2.4. Reference 158 to LSPs by identifiers is discussed in Section 7.3. of [Stateful- 159 PCE]. This feature can be applied to reduce the data carried in 160 PCEP messages. Use cases and additional Error Codes are necessary, 161 as described in Section 2.5. of this document. 163 2.2. LSP Delegation in GMPLS-controlled Networks 165 [Stateful-PCE] defines the Path Computation LSP Update Request 166 (PCUpd) message to enable to update the attributes of an LSP. 167 However, that document does not define technology-specific 168 parameters. 170 A key element of the PCUpd message is the attribute-list construct 171 defined in [RFC5440] and extended by many other PCEP specifications. 173 For GMPLS purposes we note that the BANDWIDTH object used in the 174 attribute-list is defined in [PCEP-GMPLS]. Furthermore, additional 175 TLVs are defined for the LSPA object in [PCEP-GMPLS] and MAY be 176 included to indicate technology-specific attributes. 178 LSP parameter update controlled by a stateful PCE in a multi-domain 179 network is complex and requires well-defined operational procedures 180 as well as protocol design and is out of scope of this document and 181 left for further study. 183 2.3. LSP Synchronization in GMPLS-controlled Networks 185 PCCs need to report the attributes of LSPs to the PCE to enable 186 stateful operation of a GMPLS network. This process is known as 187 LSP state synchronization. The LSP attributes include bandwidth, 188 associated route, and protection information etc., are stored by the 189 PCE in the LSP database (LSP-DB). Note that, as described in 190 [Stateful-PCE], the LSP state synchronization covers both the bulk 191 reporting of LSPs at initialization as well the reporting of new or 192 modified LSP during normal operation. Incremental LSP-DB 193 synchronization may be desired in a GMPLS-controlled network and it 194 is specified in [Sync-OPT]. 196 [Stateful-PCE] describes mechanisms for LSP synchronization using 197 the Path Computation State Report (PCRpt) message, but does not 198 cover reporting of technology-specific attributes. As stated in 199 [Stateful-PCE], the construct is further composed of a 200 compulsory ERO object and a compulsory attribute-list and a optional 201 RRO object. In order to report LSP states in GMPLS networks, this 202 specification allows the use within a PCRpt message of technology- 203 and GMPLS-specific attribute objects and TLVs defined in [PCEP-GMPLS] 204 as follows: 206 o Extensions to the ERO, RRO, IRO, and XRO to carry label sub- 207 objects for SDH/SONET, OTN, and DWDM networks. 209 o Extended objects to support the inclusion of the label and 210 unnumbered links. 212 o END-POINTS (Generalized END-POINTS Object Type) 214 o BANDWIDTH (Generalized BANDWIDTH Object Type) 216 o PROTECTION ATTRIBUTE TLV 218 o IF_ID_ERROR_SPEC (extending [Stateful-PCE] section 7.3.4 that 219 only considers the use of RSVP ERROR_SPEC) 221 The END-POINTS object SHOULD be carried within the attribute-list to 222 specify the endpoints pertaining to the reported LSP. The XRO object 223 MAY be carried to specify the network resources that the reported 224 LSP avoids and a PCE SHOULD consider avoid these network resources 225 during the process of re-optimizing after this LSP is delegated to 226 the PCE. To be more specific, the is updated as: 228 ::= [] 229 [] 230 [] 231 [] 232 [] 233 [] 235 ::= [] 237 If the LSP being reported protects another LSP, the PROTECTION- 238 ATTRIBUTE TLV [PCEP-GMPLS] MUST be included in the LSPA object to 239 describe its attributes and restrictions. Moreover, if the status 240 of the protecting LSP changes from non-operational to operational, 241 this SHOULD to be synchronized to the stateful PCE using a PCRpt 242 message. 244 2.4. Modification of Existing PCEP Messages and Procedures 246 One of the advantages mentioned in [Stateful-APP] is that the 247 stateful nature of a PCE simplifies the information conveyed in PCEP 248 messages, notably between PCC and PCE, since it is possible to refer 249 to PCE managed state for active LSPs. To be more specific, with a 250 stateful PCE, it is possible to refer to a LSP with a unique 251 identifier in the scope of the PCC-PCEP session and thus use such 252 identifier to refer to that LSP. Note this MAY also be applicable to 253 packet networks. 255 2.4.1. Modification for LSP Re-optimization 257 The Request Parameters (RP) object on a Path Computation Request 258 (PCReq) message carries the R bit. When set, this indicates that 259 the PCC is requesting reoptimization of an existing LSP. Upon 260 receiving such a PCReq, a stateful PCE SHOULD perform the 261 reoptimization in the following cases: 263 - The existing bandwidth and route information of the LSP to be 264 reoptimized is provided in the PCReq message using the BANDWIDTH 265 object and the ERO. 267 - The existing bandwidth and route information is not supplied in 268 the PCReq message, but can be found in the PCE's LSP-DB. In this 269 case, the LSP MUST be identified using an LSP identifier carried in 270 the PCReq message, and that fact requires that the LSP identifier 271 was previously supplied either by the PCC in a PCRpt message or by 272 the PCE in a PCRep. [Stateful-PCE] defines how this is achieved 273 using a combination of the per-node LSP identifier (PLSP-ID) and the 274 PCC's address. 276 If no LSP state information is available to carry out 277 reoptimization, the stateful PCE should report the error "LSP state 278 information unavailable for the LSP reoptimization" (Error Type = 279 TBD1, Error value= TBD2). 281 2.4.2. Modification for Route Exclusion 283 [RFC5521] defines a mechanism for a PCC to request or demand that 284 specific nodes, links, or other network resources are excluded from 285 paths computed by a PCE. A PCC may wish to request the computation 286 of a path that avoids all link and nodes traversed by some other LSP. 288 To this end this document defines a new sub-object for use with 289 route exclusion defined in [RFC5521]. The LSP exclusion sub-object 290 is as follows: 292 0 1 2 3 293 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 294 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 295 |X|Type (TBD3) | Length | Attributes | Flag | 296 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 297 | PLSP-ID | Reserved | 298 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 300 X bit and Attribute fields are defined in [RFC5521]. 301 X bit: indicates whether the exclusion is mandatory (X=1) and 302 MUST be accommodated, or desired (X=0) and SHOULD be accommodated. 304 Type: Subobject Type for an LSP exclusion sub-object. Value of 305 TBD3. To be assigned by IANA. 307 Length: The Length contains the total length of the subobject in 308 bytes, including the Type and Length fields. 310 Attributes: indicates how the exclusion object is to be 311 interpreted. Currently, Interface (Attributes = 0), Node (Attributes 312 =1) and SRLG (Attributes =2) are defined in [RFC5521] and this 313 document does not define new values. 315 Flags: This field may be used to further specify the exclusion 316 constraint with regard to the LSP. Currently, no values are defined. 318 PLSP-ID: This is the identifier given to a LSP and is unique in 319 the context of the PCC address as defined in [Stateful-PCE]. 321 Reserved: MUST be transmitted as zero and SHOULD be ignored on 322 receipt. 324 This sub-object is OPTIONAL in the exclude route object (XRO) and 325 can be present multiple times. When a stateful PCE receives a PCReq 326 message carrying this sub-object, it SHOULD search for the 327 identified LSP in its LSP-DB and then exclude it from the new path 328 computation all resources used by the identified LSP. If the 329 stateful PCE cannot recognize one or more of the received LSP 330 identifiers, it should send an error message PCErr reporting "The 331 LSP state information for route exclusion purpose cannot be found" 332 (Error-type = TBD1, Error-value = TBD4). Optionally, it may provide 333 with the unrecognized identifier information to the requesting PCC 334 using the error reporting techniques described in [RFC5440]. 336 2.5. Object Encoding 338 Note that, as is stated in Section 7 of [Stateful-PCE], the P flag 339 and the I flag of the PCEP objects used on PCUpd and PCRpt messages 340 SHOULD be set to 0 on transmission and SHOULD be ignored on receipt 341 since these flags are exclusively related to path computation 342 requests. 344 3. IANA Considerations 346 IANA is requested to allocate new Types for the TLV/Object defined 347 in this document. 349 3.1. New PCEP Error Codes 351 IANA is requested to make the following allocation in the "PCEP- 352 ERROR Object Error Types and Values" registry. 354 Error Type Meaning Reference 356 TBD1 LSP state information missing [This.I-D] 358 Error-value TBD2: LSP state information unavailable [This.I-D] 360 for the LSP re-optimization 362 Error-value TBD4: LSP state information for route 364 exclusion purpose cannot be found [This.I-D] 366 3.2. New Subobject for the Exclude Route Object 368 IANA maintains the "PCEP Parameters" registry containing a 369 subregistry called "PCEP Objects". This registry has a subregistry 370 for the XRO (Exclude Route Object) listing the sub-objects that can 371 be carried in the XRO. IANA is requested to assign a further sub- 372 object that can be carried in the XRO as follows: 374 Value Description Reference 376 ----------+------------------------------+------------- 378 TBD3 LSP identifier sub-object [This.I-D] 380 4. Manageability Considerations 382 The description and functionality specifications presented related 383 to stateful PCEs should also comply with the manageability 384 specifications covered in Section 8 of [RFC4655]. Furthermore, a 385 further list of manageability issues presented in [Stateful-PCE] 386 should also be considered. 388 Additional considerations are presented in the next sections. 390 4.1. Requirements on Other Protocols and Functional Components 392 When the detailed route information is included for LSP state 393 synchronization (either at the initial stage or during LSP state 394 report process), this require the ingress node of an LSP carry the 395 RRO object in order to enable the collection of such information. 397 5. Security Considerations 399 This draft provides additional extensions to PCEP so as to 400 facilitate stateful PCE usage in GMPLS-controlled networks, on top 401 of [Stateful-PCE]. The PCEP extensions to support GMPLS-controlled 402 networks should be considered under the same security as for MPLS 403 networks, as noted in [RFC7025]. Therefore, the security 404 considerations elaborated in [RFC5440] still apply to this draft. 405 Furthermore, [Stateful-PCE] provides a detailed analysis of the 406 additional security issues incurred due to the new extensions and 407 possible solutions needed to support for the new stateful PCE 408 capabilities and they apply to this document as well. 410 6. Acknowledgement 412 We would like to thank Adrian Farrel and Cyril Margaria for the 413 useful comments and discussions. 415 7. References 417 7.1. Normative References 419 [RFC2119] Bradner, S., "Key words for use in RFCs to indicate 420 requirements levels", RFC 2119, March 1997. 422 [RFC4655] Farrel, A., Vasseur, J.-P., and Ash, J., "A Path 423 Computation Element (PCE)-Based Architecture", RFC 4655, 424 August 2006. 426 [RFC5440] Vasseur, J.-P., and Le Roux, JL., "Path Computation 427 Element (PCE) Communication Protocol (PCEP)", RFC 5440, 428 March 2009. 430 [Stateful-PCE] Crabbe, E., Medved, J., Varga, R., Minei, I., "PCEP 431 Extensions for Stateful PCE", draft-ietf-pce-stateful-pce, 432 work in progress. 434 [PCEP-GMPLS] Margaria, C., Gonzalez de Dios, O., Zhang, F., "PCEP 435 extensions for GMPLS", draft-ietf-pce-gmpls-pcep- 436 extensions, work in progress. 438 7.2. Informative References 440 [Stateful-APP] Zhang, X., Minei, I., et al, "Applicability of 441 Stateful Path Computation Element (PCE) ", draft-ietf-pce- 442 stateful-pce-app, work in progress. 444 [Sync-OPT] Crabbe, E., Minei, I., Medved, J., Varga, R., Zhang, X., 445 and D. Dhody, "Optimizations of Label Switched Path State 446 Synchronization Procedures for a Stateful PCE", draft- 447 ietf-pce-stateful-sync-optimizations, work in progress. 449 8. Contributors' Address 451 Dhruv Dhody 452 Huawei Technology 453 Leela Palace 454 Bangalore, Karnataka 560008 455 INDIA 457 EMail: dhruvd@huawei.com 459 Yi Lin 460 Huawei Technologies 461 F3-5-B R&D Center, Huawei Base 462 Bantian, Longgang District 463 Shenzhen 518129 P.R.China 465 Phone: +86-755-28972914 466 Email: yi.lin@huawei.com 468 Authors' Addresses 470 Xian Zhang 471 Huawei Technologies 472 F3-5-B R&D Center, Huawei Base 473 Bantian, Longgang District 474 Shenzhen 518129 P.R.China 476 Phone: +86-755-28972645 477 Email: zhang.xian@huawei.com 479 Young Lee 480 Huawei 481 1700 Alma Drive, Suite 100 482 Plano, TX 75075 483 US 485 Phone: +1 972 509 5599 x2240 486 Fax: +1 469 229 5397 487 EMail: ylee@huawei.com 489 Fatai Zhang 490 Huawei 491 F3-5-B R&D Center, Huawei Base 492 Bantian, Longgang District 493 P.R. China 495 Phone: +86-755-28972912 496 Email: zhangfatai@huawei.com 498 Ramon Casellas 499 CTTC 500 Av. Carl Friedrich Gauss n7 501 Castelldefels, Barcelona 08860 502 Spain 504 Phone: 505 Email: ramon.casellas@cttc.es 507 Oscar Gonzalez de Dios 508 Telefonica Investigacion y Desarrollo 509 Emilio Vargas 6 510 Madrid, 28045 511 Spain 512 Phone: +34 913374013 513 Email: ogondio@tid.es 515 Zafar Ali 516 Cisco Systems 517 Email: zali@cisco.com