idnits 2.17.1 draft-ali-pce-remote-initiated-gmpls-lsp-03.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == The page length should not exceed 58 lines per page, but there was 7 longer pages, the longest (page 2) being 61 lines 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 == The document seems to contain a disclaimer for pre-RFC5378 work, but was first submitted on or after 10 November 2008. The disclaimer is usually necessary only for documents that revise or obsolete older RFCs, and that take significant amounts of text from those RFCs. If you can contact all authors of the source material and they are willing to grant the BCP78 rights to the IETF Trust, you can and should remove the disclaimer. Otherwise, the disclaimer is needed and you can ignore this comment. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (February 14, 2014) is 3714 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: 'RFC6387' is mentioned on line 219, but not defined == Unused Reference: 'RFC5440' is defined on line 353, but no explicit reference was found in the text == Unused Reference: 'RFC5623' is defined on line 357, but no explicit reference was found in the text == Unused Reference: 'RFC 6107' is defined on line 363, but no explicit reference was found in the text ** Downref: Normative reference to an Informational RFC: RFC 5623 Summary: 1 error (**), 0 flaws (~~), 7 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 PCE Working Group Zafar Ali 3 Internet Draft Siva Sivabalan 4 Intended status: Standard Track Clarence Filsfils 5 Expires: August 13, 2014 Cisco Systems 6 Robert Varga 7 Pantheon Technologies 8 Victor Lopez 9 Oscar Gonzalez de Dios 10 Telefonica I+D 11 Xian Zhang 12 Huawei 13 February 14, 2014 15 Path Computation Element Communication Protocol (PCEP) 16 Extensions for remote-initiated GMPLS LSP Setup 17 draft-ali-pce-remote-initiated-gmpls-lsp-03.txt 19 Status of this Memo 21 This Internet-Draft is submitted in full conformance with the 22 provisions of BCP 78 and BCP 79. 24 Internet-Drafts are working documents of the Internet Engineering 25 Task Force (IETF). Note that other groups may also distribute 26 working documents as Internet-Drafts. The list of current Internet- 27 Drafts is at http://datatracker.ietf.org/drafts/current/. 29 Internet-Drafts are draft documents valid for a maximum of six 30 months and may be updated, replaced, or obsoleted by other 31 documents at any time. It is inappropriate to use Internet-Drafts 32 as reference material or to cite them other than as "work in 33 progress." 35 This Internet-Draft will expire on August 13, 2014. 37 Copyright Notice 39 Copyright (c) 2014 IETF Trust and the persons identified as the 40 document authors. All rights reserved. 42 This document is subject to BCP 78 and the IETF Trust's Legal 43 Provisions Relating to IETF Documents 44 (http://trustee.ietf.org/license-info) in effect on the date of 45 publication of this document. Please review these documents 46 carefully, as they describe your rights and restrictions with 47 respect to this document. Code Components extracted from this 48 document must include Simplified BSD License text as described in 49 Internet-Draft draft-ali-pce-remote-initiated-gmpls-lsp-02.txt 51 Section 4.e of the Trust Legal Provisions and are provided without 52 warranty as described in the Simplified BSD License. 54 This document may contain material from IETF Documents or IETF 55 Contributions published or made publicly available before November 56 10, 2008. The person(s) controlling the copyright in some of this 57 material may not have granted the IETF Trust the right to allow 58 modifications of such material outside the IETF Standards Process. 59 Without obtaining an adequate license from the person(s) 60 controlling the copyright in such materials, this document may not 61 be modified outside the IETF Standards Process, and derivative 62 works of it may not be created outside the IETF Standards Process, 63 except to format it for publication as an RFC or to translate it 64 into languages other than English. 66 Abstract 68 Draft [I-D. draft-crabbe-pce-pce-initiated-lsp] specifies 69 procedures that can be used for creation and deletion of PCE- 70 initiated LSPs in the active stateful PCE model. However, this 71 specification focuses on MPLS networks, and does not cover remote 72 instantiation of paths in GMPLS-controlled networks. This document 73 complements [I-D. draft-crabbe-pce-pce-initiated-lsp] by addressing 74 the requirements for remote-initiated GMPLS LSPs. 76 Conventions used in this document 78 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 79 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in 80 this document are to be interpreted as described in RFC 2119 81 [RFC2119]. 83 Table of Contents 85 1. Introduction .............................................3 86 2. Requirements for Remote-Initiated GMPLS LSPs .............3 87 3. PCEP Extensions for Remote-Initiated GMPLS LSPs ..........4 88 3.1. Generalized Endpoint in LSP Initiate Message .........4 89 3.2. GENERALIZED-BANDWIDTH object in LSP Initiate Message .5 90 3.3. Protection Attributes in LSP Initiate Message ........5 91 3.4. ERO in LSP Initiate Object ...........................5 92 3.4.1. ERO with explicit label control ................5 93 3.4.2. ERO with Path Keys .............................6 94 3.4.3. Switch Layer Object ............................6 95 3.5. LSP delegation and cleanup ...........................7 96 4. Security Considerations ..................................7 97 5. IANA Considerations ......................................7 98 5.1. PCEP-Error Object ....................................7 99 6. Acknowledgments ..........................................7 100 7. References ...............................................7 101 7.1. Normative References .................................7 102 Internet-Draft draft-ali-pce-remote-initiated-gmpls-lsp-02.txt 104 7.2. Informative References ...............................8 106 1. Introduction 108 The Path Computation Element communication Protocol (PCEP) 109 provides mechanisms for Path Computation Elements (PCEs) to 110 perform route computations in response to Path Computation 111 Clients (PCCs) requests. PCEP Extensions for PCE-initiated LSP 112 Setup in a Stateful PCE Model draft [I-D. draft-ietf-pce- 113 stateful-pce] describes a set of extensions to PCEP to enable 114 active control of MPLS-TE and GMPLS network. 116 [I-D. draft-crabbe-pce-pce-initiated-lsp] describes the setup 117 and teardown of PCE-initiated LSPs under the active stateful PCE 118 model, without the need for local configuration on the PCC. This 119 enables realization of a dynamic network that is centrally 120 controlled and deployed. However, this specification is focused 121 on MPLS networks, and does not cover the GMPLS networks (e.g., 122 WSON, OTN, SONET/ SDH, etc. technologies). This document 123 complements [I-D. draft-crabbe-pce-pce-initiated-lsp] by 124 addressing the requirements for remote-initiated GMPLS LSPs. 125 These requirements are covered in Section 2 of this draft. The 126 PCEP extensions for remote initiated GMPLS LSPs are specified in 127 Section 3. 129 2. Requirements for Remote-Initiated GMPLS LSPs 131 [I-D. draft-crabbe-pce-pce-initiated-lsp] specifies procedures 132 that can be used for creation and deletion of PCE-initiated LSPs 133 under the active stateful PCE model. However, this specification 134 does not address GMPLS requirements outlined in the following: 136 - GMPLS support multiple switching capabilities on per TE link 137 basis. GMPLS LSP creation requires knowledge of LSP switching 138 capability (e.g., TDM, L2SC, OTN-TDM, LSC, etc.) to be used 139 [RFC3471], [RFC3473]. 141 - GMPLS LSP creation requires knowledge of the encoding type 142 (e.g., lambda photonic, Ethernet, SONET/ SDH, G709 OTN, etc.) 143 to be used by the LSP [RFC3471], [RFC3473]. 145 - GMPLS LSP creation requires information of the generalized 146 payload (G-PID) to be carried by the LSP [RFC3471], [RFC3473]. 148 - GMPLS LSP creation requires specification of data flow 149 specific traffic parameters (also known as Tspec), which are 150 technology specific. 152 Internet-Draft draft-ali-pce-remote-initiated-gmpls-lsp-02.txt 154 - GMPLS also specifics support for asymmetric bandwidth 155 requests [RFC6387]. 157 - GMPLS extends the addressing to include unnumbered interface 158 identifiers, as defined in [RFC3477]. 160 - In some technologies path calculation is tightly coupled with 161 label selection along the route. For example, path calculation 162 in a WDM network may include lambda continuity and/ or lambda 163 feasibility constraints and hence a path computed by the PCE 164 is associated with a specific lambda (label). Hence, in such 165 networks, the label information needs to be provided to a PCC 166 in order for a PCE to initiate GMPLS LSPs under the active 167 stateful PCE model. I.e., explicit label control may be 168 required. 170 - GMPLS specifics protection context for the LSP, as defined in 171 [RFC4872] and [RFC4873]. 173 3. PCEP Extensions for Remote-Initiated GMPLS LSPs 175 LSP initiate (PCInitiate) message defined in [I-D. draft-crabbe- 176 pce-pce-initiated-lsp] needs to be extended to include GMPLS 177 specific PCEP objects as follows: 179 3.1. Generalized Endpoint in LSP Initiate Message 181 This document does not modify the usage of END-POINTS object for 182 PCE initiated LSPs as specified in [I-D. draft-crabbe-pce-pce- 183 initiated-lsp]. It augments the usage as specified below. 185 END-POINTS object has been extended by [I-D. draft-ietf-pcep- 186 gmpls-ext] to include a new object type called "Generalized 187 Endpoint". PCInitiate message sent by a PCE to a PCC to trigger 188 a GMPLS LSP instantiation SHOULD include the END-POINTS with 189 Generalized Endpoint object type. Furthermore, the END-POINTS 190 object MUST contain "label request" TLV. The label request TLV 191 is used to specify the switching type, encoding type and GPID of 192 the LSP being instantiated by the PCE. 194 The unnumbered endpoint TLV can be used to specify unnumbered 195 endpoint addresses for the LSP being instantiated by the PCE. 196 The END-POINTS MAY contain other TLVs defined in [I-D. draft- 197 ietf-pcep-gmpls-ext]. 199 If the END-POINTS Object of type Generalized Endpoint is missing 200 the label request TLV, the PCC MUST send a PCErr message with 201 Error-type=6 (Mandatory Object missing) and Error-value= TBA 202 (LSP request TLV missing). 204 If the PCC does not support the END-POINTS Object of type 205 Generalized Endpoint, the PCC MUST send a PCErr message with 206 Internet-Draft draft-ali-pce-remote-initiated-gmpls-lsp-02.txt 208 Error-type = 3 (Unknown Object), Error-value = 2(unknown object 209 type). 211 3.2. GENERALIZED-BANDWIDTH object in LSP Initiate Message 213 LSP initiate message defined in [I-D. draft-crabbe-pce-pce- 214 initiated-lsp] can optionally include the BANDWIDTH object. 215 However, the following possibilities cannot be represented in 216 the BANDWIDTH object: 218 - Asymmetric bandwidth (different bandwidth in forward and 219 reverse direction), as described in [RFC6387]. 221 - Technology specific GMPLS parameters (e.g., Tspec for 222 SDH/SONET, G.709, ATM, MEF, etc.) are not supported. 224 GENERALIZED-BANDWIDTH object has been defined in [I-D. draft- 225 ietf-pcep-gmpls-ext] to address the above-mentioned limitation 226 of the BANDWIDTH object. 228 This document specifies the use of GENERALIZED-BANDWIDTH object 229 in PCInitiate message. Specifically, GENERALIZED-BANDWIDTH 230 object MAY be included in the PCInitiate message. The 231 GENERALIZED-BANDWIDTH object in PCInitiate message is used to 232 specify technology specific Tspec and asymmetrical bandwidth 233 values for the LSP being instantiated by the PCE. 235 3.3. Protection Attributes in LSP Initiate Message 237 This document does not modify the usage of LSPA object for PCE 238 initiated LSPs as specified in [I-D. draft-crabbe-pce-pce- 239 initiated-lsp]. It augments the usage of LSPA object in LSP 240 Initiate Message to carry the end-to-end protection context this 241 also includes the protection state information. 243 The LSP Protection Information TLV of LSPA in the PCInitiate 244 message can be used to specify protection attributes of the LSP 245 being instantiated by the PCE. 247 3.4. ERO in LSP Initiate Object 249 This document does not modify the usage of ERO object for PCE 250 initiated LSPs as specified in [I-D. draft-crabbe-pce-pce- 251 initiated-lsp]. It augments the usage as specified in the 252 following sections. 254 3.4.1. ERO with explicit label control 256 As mentioned earlier, there are technologies and scenarios where 257 active stateful PCE requires explicit label control in order to 258 instantiate an LSP. 260 Internet-Draft draft-ali-pce-remote-initiated-gmpls-lsp-02.txt 262 Explicit label control (ELC) is a procedure supported by RSVP- 263 TE, where the outgoing label(s) is (are) encoded in the ERO. [I- 264 D. draft-ietf-pcep-gmpls-ext] extends the object of PCEP 265 to include explicit label control. The ELC procedure enables the 266 PCE to provide such label(s) directly in the path ERO. 268 The extended ERO object in PCInitiate message can be used to 269 specify label along with ERO to PCC for the LSP being 270 instantiated by the active stateful PCE. 272 3.4.2. ERO with Path Keys 274 There are many scenarios in packet and optical networks where 275 the route information of an LSP may not be provided to the PCC 276 for confidentiality reasons. A multi-domain or multi-layer 277 network is an example of such networks. Similarly, a GMPLS User- 278 Network Interface (UNI) [RFC4208] is also an example of such 279 networks. 281 In such scenarios, ERO containing the entire route cannot be 282 provided to PCC (by PCE). Instead, PCE provides an ERO with Path 283 Keys to the PCC. For example, in the case UNI interface between 284 the router and the optical nodes, the ERO in the LSP Initiate 285 Message may be constructed as follows: 287 - The first hop is a strict hop that provides the egress 288 interface information at PCC. This interface information is 289 used to get to a network node that can extend the rest of the 290 ERO. (Please note that in the cases where the network node is 291 not directly connected with the PCC, this part of ERO may 292 consist of multiple hops and may be loose). 293 - The following(s) hop in the ERO may provide the network node 294 with the path key [RFC5520] that can be resolved to get the 295 contents of the route towards the destination. 296 - There may be further hops but these hops may also be encoded 297 with the path keys (if needed). 299 This document does not change encoding or processing roles for 300 the path keys, which are defined in [RFC5520]. 302 3.4.3. Switch Layer Object 304 [draft-ietf-pce-inter-layer-ext-07] specifies the SWITCH-LAYER 305 object which defines and specifies the switching layer (or 306 layers) in which a path MUST or MUST NOT be established. A 307 switching layer is expressed as a switching type and encoding 308 type. [I-D. draft-ietf-pcep-gmpls-ext], which defines the GMPLS 309 Internet-Draft draft-ali-pce-remote-initiated-gmpls-lsp-02.txt 311 extensions for PCEP, suggests using the SWITCH-LAYER object. 312 Thus, SWITCH-LAYER object can be used in the PCInitiate message 313 to specify the switching layer (or layers) of the LSP being 314 remotely initiated. 316 3.5. LSP delegation and cleanup 318 LSP delegation and cleanup procedure specified in [I-D. draft- 319 ietf-pcep-gmpls-ext] are equally applicable to GMPLS LSPs and 320 this document does not modify the associated usage. 322 4. Security Considerations 324 To be added in future revision of this document. 326 5. IANA Considerations 328 5.1. PCEP-Error Object 330 This document defines the following new Error-Value: 332 Error-Type Error Value 334 6 Error-value=TBA: LSP Request TLV missing 336 6. Acknowledgments 338 The authors would like to thank George Swallow and Jan Medved 339 for their comments. 341 7. References 343 7.1. Normative References 345 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 346 Requirement Levels", BCP 14, RFC 2119, March 1997. 348 [I-D. draft-crabbe-pce-pce-initiated-lsp] Crabbe, E., Minei, 349 I., Sivabalan, S., Varga, R., "PCEP Extensions for 350 PCE-initiated LSP Setup in a Stateful PCE Model", 351 draft-crabbe-pce-pce-initiated-lsp, work in progress. 353 [RFC5440] Vasseur, JP., Ed., and JL. Le Roux, Ed., "Path 354 Computation Element (PCE) Communication Protocol 355 (PCEP)", RFC 5440, March 2009. 357 [RFC5623] Oki, E., Takeda, T., Le Roux, JL., and A. Farrel, 358 "Framework for PCE-Based Inter-Layer MPLS and GMPLS 359 Traffic Engineering", RFC 5623, September 2009. 361 Internet-Draft draft-ali-pce-remote-initiated-gmpls-lsp-02.txt 363 [RFC 6107] Shiomoto, K., Ed., and A. Farrel, Ed., "Procedures 364 for Dynamically Signaled Hierarchical Label Switched 365 Paths", RFC 6107, February 2011. 367 7.2. Informative References 369 [RFC3471] Berger, L., Ed., "Generalized Multi-Protocol Label 370 Switching (GMPLS) Signaling Functional Description", 371 RFC 3471, January 2003. 373 [RFC3473] Berger, L., Ed., "Generalized Multi-Protocol Label 374 Switching (GMPLS) Signaling Resource ReserVation 375 Protocol-Traffic Engineering (RSVP-TE) Extensions", 376 RFC 3473, January 2003. 378 [RFC3477] Kompella, K. and Y. Rekhter, "Signalling Unnumbered 379 Links in Resource ReSerVation Protocol - Traffic 380 Engineering (RSVP-TE)", RFC 3477, January 2003. 382 [RFC4872] Lang, J., Ed., Rekhter, Y., Ed., and D. Papadimitriou, 383 Ed., "RSVP-TE Extensions in Support of End-to-End 384 Generalized Multi-Protocol Label Switching (GMPLS) 385 Recovery", RFC 4872, May 2007. 387 [RFC4873] Berger, L., Bryskin, I., Papadimitriou, D., and A. 388 Farrel, "GMPLS Segment Recovery", RFC 4873, May 2007. 390 [RFC4208] Swallow, G., Drake, J., Ishimatsu, H., and Y. Rekhter, 391 "Generalized Multiprotocol Label Switching (GMPLS) 392 User-Network Interface (UNI): Resource ReserVation 393 Protocol-Traffic Engineering (RSVP-TE) Support for the 394 Overlay Model", RFC 4208, October 2005. 396 [RFC5520] Bradford, R., Ed., Vasseur, JP., and A. Farrel, 397 "Preserving Topology Confidentiality in Inter-Domain 398 Path Computation Using a Path-Key-Based Mechanism", 399 RFC 5520, April 2009. 401 Author's Addresses 403 Zafar Ali 404 Cisco Systems 405 Email: zali@cisco.com 407 Siva Sivabalan 408 Cisco Systems 409 Email: msiva@cisco.com 411 Clarence Filsfils 412 Internet-Draft draft-ali-pce-remote-initiated-gmpls-lsp-02.txt 414 Cisco Systems 415 Email: cfilsfil@cisco.com 417 Robert Varga 418 Pantheon Technologies 420 Victor Lopez 421 Telefonica I+D 422 Email: vlopez@tid.es 424 Oscar Gonzalez de Dios 425 Telefonica I+D 426 Email: ogondio@tid.es 428 Xian Zhang 429 Huawei Technologies 430 Email: zhang.xian@huawei.com