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