idnits 2.17.1 draft-ietf-pce-remote-initiated-gmpls-lsp-06.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 2 characters in excess of 72. ** The abstract seems to contain references ([RFC8281]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (February 23, 2019) is 1889 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) == Unused Reference: 'RFC5440' is defined on line 328, but no explicit reference was found in the text == Unused Reference: 'RFC5623' is defined on line 333, but no explicit reference was found in the text == Unused Reference: 'RFC6107' is defined on line 338, but no explicit reference was found in the text == Outdated reference: A later version (-16) exists of draft-ietf-pce-gmpls-pcep-extensions-13 ** Downref: Normative reference to an Informational RFC: RFC 5623 Summary: 3 errors (**), 0 flaws (~~), 5 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 PCE Working Group Z. Ali 3 Internet-Draft S. Sivabalan 4 Intended status: Standards Track C. Filsfils 5 Expires: August 27, 2019 Cisco Systems 6 R. Varga 7 Pantheon Technologies 8 V. Lopez 9 O. Gonzalez de Dios 10 Telefonica 11 H. Zheng 12 X. Zhang 13 Huawei Technologies 14 February 23, 2019 16 Path Computation Element Communication Protocol (PCEP) Extensions for 17 remote-initiated GMPLS LSP Setup 18 draft-ietf-pce-remote-initiated-gmpls-lsp-06.txt 20 Abstract 22 [RFC8281] specifies procedures that can be used for creation and 23 deletion of PCE-initiated LSPs in the active stateful PCE model. 24 However, this specification focuses on MPLS networks, and does not 25 cover remote instantiation of paths in GMPLS-controlled networks. 26 This document complements [RFC8281] by addressing the requirements 27 for remote-initiated GMPLS LSPs. 29 Requirements Language 31 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 32 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 33 document are to be interpreted as described in [RFC2119]. 35 Status of This Memo 37 This Internet-Draft is submitted in full conformance with the 38 provisions of BCP 78 and BCP 79. 40 Internet-Drafts are working documents of the Internet Engineering 41 Task Force (IETF). Note that other groups may also distribute 42 working documents as Internet-Drafts. The list of current Internet- 43 Drafts is at https://datatracker.ietf.org/drafts/current/. 45 Internet-Drafts are draft documents valid for a maximum of six months 46 and may be updated, replaced, or obsoleted by other documents at any 47 time. It is inappropriate to use Internet-Drafts as reference 48 material or to cite them other than as "work in progress." 49 This Internet-Draft will expire on August 27, 2019. 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 (https://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 respect 61 to this document. Code Components extracted from this document must 62 include Simplified BSD License text as described in Section 4.e of 63 the Trust Legal Provisions and are provided without warranty as 64 described in the Simplified BSD License. 66 Table of Contents 68 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 69 2. Requirements for Remote-Initiated GMPLS LSPs . . . . . . . . 3 70 3. PCEP Extensions for Remote-Initiated GMPLS LSPs . . . . . . . 4 71 3.1. Generalized Endpoint in LSP Initiate Message . . . . . . . 4 72 3.2. GENERALIZED-BANDWIDTH object in LSP Initiate Message . . . 4 73 3.3. Protection Attributes in LSP Initiate Message . . . . . . . 5 74 3.4. ERO in LSP Initiate Object . . . . . . . . . . . . . . . . 5 75 3.4.1. ERO with explicit label control . . . . . . . . . . . . . 5 76 3.4.2. ERO with Path Keys . . . . . . . . . . . . . . . . . . . 6 77 3.4.3. Switch Layer Object . . . . . . . . . . . . . . . . . . . 6 78 3.5. LSP delegation and cleanup . . . . . . . . . . . . . . . . 6 79 4. Security Considerations . . . . . . . . . . . . . . . . . . . 7 80 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7 81 5.1. PCEP-Error Object . . . . . . . . . . . . . . . . . . . . . 7 82 6. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 7 83 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 7 84 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 7 85 8.1. Normative References . . . . . . . . . . . . . . . . . . . 7 86 8.2. Informational References . . . . . . . . . . . . . . . . . 8 87 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 9 89 1. Introduction 91 The Path Computation Element communication Protocol (PCEP) provides 92 mechanisms for Path Computation Elements (PCEs) to perform route 93 computations in response to Path Computation Clients (PCCs) requests. 94 PCEP Extensions for PCE-initiated LSP Setup in a Stateful PCE Model 95 draft [RFC8231] describes a set of extensions to PCEP to enable 96 active control of MPLS-TE and GMPLS network. 98 [RFC8281] describes the setup and teardown of PCE-initiated LSPs 99 under the active stateful PCE model, without the need for local 100 configuration on the PCC. This enables realization of a dynamic 101 network that is centrally controlled and deployed. However, this 102 specification is focused on MPLS networks, and does not cover the 103 GMPLS networks (e.g., WSON, OTN, SONET/ SDH, etc. technologies). 104 This document complements [RFC8281] by addressing the requirements 105 for remote-initiated GMPLS LSPs. These requirements are covered in 106 Section 2 of this draft. The PCEP extensions for remote initiated 107 GMPLS LSPs are specified in Section 3. 109 2. Requirements for Remote-Initiated GMPLS LSPs 111 [RFC8281] specifies procedures that can be used for creation and 112 deletion of PCE-initiated LSPs under the active stateful PCE model. 113 However, this specification does not address GMPLS requirements 114 outlined in the following: 116 o GMPLS support multiple switching capabilities on per TE link 117 basis. GMPLS LSP creation requires knowledge of LSP switching 118 capability (e.g., TDM, L2SC, OTN-TDM, LSC, etc.) to be used 119 [RFC3471] , [RFC3473] . 121 o GMPLS LSP creation requires knowledge of the encoding type (e.g., 122 lambda photonic, Ethernet, SONET/ SDH, G709 OTN, etc.) to be used 123 by the LSP [RFC3471] , [RFC3473]. 125 o GMPLS LSP creation requires information of the generalized payload 126 (G-PID) to be carried by the LSP [RFC3471] , [RFC3473]. 128 o GMPLS LSP creation requires specification of data flow specific 129 traffic parameters (also known as Tspec), which are technology 130 specific. 132 o GMPLS also specifics support for asymmetric bandwidth requests 133 [RFC6387] . 135 o GMPLS extends the addressing to include unnumbered interface 136 identifiers, as defined in [RFC3477] . 138 o In some technologies path calculation is tightly coupled with 139 label selection along the route. For example, path calculation in 140 a WDM network may include lambda continuity and/ or lambda 141 feasibility constraints and hence a path computed by the PCE is 142 associated with a specific lambda (label). Hence, in such 143 networks, the label information needs to be provided to a PCC in 144 order for a PCE to initiate GMPLS LSPs under the active stateful 145 PCE model. I.e., explicit label control may be required. 147 o GMPLS specifics protection context for the LSP, as defined in 148 [RFC4872] , [RFC4873]. 150 3. PCEP Extensions for Remote-Initiated GMPLS LSPs 152 LSP initiate (PCInitiate) message defined in [RFC8281] needs to be 153 extended to include GMPLS specific PCEP objects as follows: 155 3.1. Generalized Endpoint in LSP Initiate Message 157 This document does not modify the usage of END-POINTS object for PCE 158 initiated LSPs as specified in [RFC8281] . It augments the usage as 159 specified below. 161 END-POINTS object has been extended by 162 [I-D.ietf-pce-gmpls-pcep-extensions] to include a new object type 163 called "Generalized Endpoint". PCInitiate message sent by a PCE to a 164 PCC to trigger a GMPLS LSP instantiation SHOULD include the END- 165 POINTS with Generalized Endpoint object type. Furthermore, the END- 166 POINTS object MUST contain "label request" TLV. The label request 167 TLV is used to specify the switching type, encoding type and GPID of 168 the LSP being instantiated by the PCE. 170 If the END-POINTS Object of type Generalized Endpoint is missing the 171 label request TLV, the PCC MUST send a PCErr message with Error- 172 type=6 (Mandatory Object missing) and Error-value= TBA (label request 173 TLV missing). 175 If the PCC does not support the END-POINTS Object of type Generalized 176 Endpoint, the PCC MUST send a PCErr message with Error-type = 3 177 (Unknown Object), Error-value = 2(unknown object type). 179 The unnumbered endpoint TLV can be used to specify unnumbered 180 endpoint addresses for the LSP being instantiated by the PCE. The 181 END-POINTS MAY contain other TLVs defined in 182 [I-D.ietf-pce-gmpls-pcep-extensions]. 184 3.2. GENERALIZED-BANDWIDTH object in LSP Initiate Message 186 LSP initiate message defined in [RFC8281] can optionally include the 187 BANDWIDTH object. However, the following possibilities cannot be 188 represented in the BANDWIDTH object: 190 o Asymmetric bandwidth (different bandwidth in forward and reverse 191 direction), as described in [RFC6387] . 193 o Technology specific GMPLS parameters (e.g., Tspec for SDH/SONET, 194 G.709, ATM, MEF, etc.) are not supported. 196 GENERALIZED-BANDWIDTH object has been defined in 197 [I-D.ietf-pce-gmpls-pcep-extensions] to address the above-mentioned 198 limitation of the BANDWIDTH object. 200 This document specifies the use of GENERALIZED-BANDWIDTH object in 201 PCInitiate message. Specifically, GENERALIZED-BANDWIDTHobject MAY be 202 included in the PCInitiate message. The GENERALIZED-BANDWIDTH object 203 in PCInitiate message is used to specify technology specific Tspec 204 and asymmetrical bandwidth values for the LSP being instantiated by 205 the PCE. 207 3.3. Protection Attributes in LSP Initiate Message 209 This document does not modify the usage of LSPA object for PCE 210 initiated LSPs as specified in [RFC8281] . It augments the usage of 211 LSPA object in LSP Initiate Message to carry the end-to-end 212 protection context this also includes the protection state 213 information. 215 The LSP Protection Information TLV of LSPA in the PCInitiate message 216 can be used to specify protection attributes of the LSP being 217 instantiated by the PCE. 219 3.4. ERO in LSP Initiate Object 221 This document does not modify the usage of ERO object for PCE 222 initiated LSPs as specified in [RFC8281]. It augments the usage as 223 specified in the following sections. 225 3.4.1. ERO with explicit label control 227 As mentioned earlier, there are technologies and scenarios where 228 active stateful PCE requires explicit label control in order to 229 instantiate an LSP. 231 Explicit label control (ELC) is a procedure supported by RSVP-TE, 232 where the outgoing label(s) is (are) encoded in the ERO. 233 [I-D.ietf-pce-gmpls-pcep-extensions] extends the ERO object of PCEP 234 to include explicit label control. The ELC procedure enables the PCE 235 to provide such label(s) directly in the path ERO. 237 The extended ERO object in PCInitiate message can be used to specify 238 label along with ERO to PCC for the LSP being instantiated by the 239 active stateful PCE. 241 3.4.2. ERO with Path Keys 243 There are many scenarios in packet and optical networks where the 244 route information of an LSP may not be provided to the PCC for 245 confidentiality reasons. A multi-domain or multi-layer network is an 246 example of such networks. Similarly, a GMPLS User- Network Interface 247 (UNI) [RFC4208] is also an example of such networks. 249 In such scenarios, ERO containing the entire route cannot be provided 250 to PCC (by PCE). Instead, PCE provides an ERO with Path Keys to the 251 PCC. For example, in the case UNI interface between the router and 252 the optical nodes, the ERO in the LSP Initiate Message may be 253 constructed as follows: 255 o The first hop is a strict hop that provides the egress interface 256 information at PCC. This interface information is used to get to 257 a network node that can extend the rest of the ERO. (Please note 258 that in the cases where the network node is not directly connected 259 with the PCC, this part of ERO may consist of multiple hops and 260 may be loose). 262 o The following(s) hop in the ERO may provide the network node with 263 the path key [RFC5520] that can be resolved to get the contents of 264 the route towards the destination. 266 o There may be further hops but these hops may also be encoded with 267 the path keys (if needed). 269 This document does not change encoding or processing roles for the 270 path keys, which are defined in [RFC5520]. 272 3.4.3. Switch Layer Object 274 [I-D.ietf-pce-inter-layer-ext] specifies the SWITCH-LAYER object 275 which defines and specifies the switching layer (or layers) in which 276 a path MUST or MUST NOT be established. A switching layer is 277 expressed as a switching type and encoding type. 278 [I-D.ietf-pce-gmpls-pcep-extensions], which defines the GMPLS 279 extensions for PCEP, suggests using the SWITCH-LAYER object. Thus, 280 SWITCH-LAYER object can be used in the PCInitiate message to specify 281 the switching layer (or layers) of the LSP being remotely initiated. 283 3.5. LSP delegation and cleanup 285 LSP delegation and cleanup procedure specified in 286 [I-D.ietf-pce-gmpls-pcep-extensions] are equally applicable to GMPLS 287 LSPs and this document does not modify the associated usage. 289 4. Security Considerations 291 The security considerations described in [RFC8281] apply to the 292 extensions described in this document. 294 5. IANA Considerations 296 5.1. PCEP-Error Object 298 This document defines the following new Error-Value: 300 Error-type Error Value Reference 301 6 Error-value = TBA: Label Request TLV Missing this document 303 6. Contributors 305 Sajal Agarwal 306 Cisco Systems 307 Email: sajaagar@cisco.com 309 7. Acknowledgements 311 The authors would like to thank George Swallow and Jan Medved for 312 their comments. 314 8. References 316 8.1. Normative References 318 [I-D.ietf-pce-gmpls-pcep-extensions] 319 Margaria, C., Dios, O., and F. Zhang, "PCEP extensions for 320 GMPLS", draft-ietf-pce-gmpls-pcep-extensions-13 (work in 321 progress), January 2019. 323 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 324 Requirement Levels", BCP 14, RFC 2119, 325 DOI 10.17487/RFC2119, March 1997, 326 . 328 [RFC5440] Vasseur, JP., Ed. and JL. Le Roux, Ed., "Path Computation 329 Element (PCE) Communication Protocol (PCEP)", RFC 5440, 330 DOI 10.17487/RFC5440, March 2009, 331 . 333 [RFC5623] Oki, E., Takeda, T., Le Roux, JL., and A. Farrel, 334 "Framework for PCE-Based Inter-Layer MPLS and GMPLS 335 Traffic Engineering", RFC 5623, DOI 10.17487/RFC5623, 336 September 2009, . 338 [RFC6107] Shiomoto, K., Ed. and A. Farrel, Ed., "Procedures for 339 Dynamically Signaled Hierarchical Label Switched Paths", 340 RFC 6107, DOI 10.17487/RFC6107, February 2011, 341 . 343 [RFC8231] Crabbe, E., Minei, I., Medved, J., and R. Varga, "Path 344 Computation Element Communication Protocol (PCEP) 345 Extensions for Stateful PCE", RFC 8231, 346 DOI 10.17487/RFC8231, September 2017, 347 . 349 [RFC8281] Crabbe, E., Minei, I., Sivabalan, S., and R. Varga, "Path 350 Computation Element Communication Protocol (PCEP) 351 Extensions for PCE-Initiated LSP Setup in a Stateful PCE 352 Model", RFC 8281, DOI 10.17487/RFC8281, December 2017, 353 . 355 8.2. Informational References 357 [I-D.ietf-pce-inter-layer-ext] 358 Oki, E., Takeda, T., Farrel, A., and F. Zhang, "Extensions 359 to the Path Computation Element communication Protocol 360 (PCEP) for Inter-Layer MPLS and GMPLS Traffic 361 Engineering", draft-ietf-pce-inter-layer-ext-12 (work in 362 progress), January 2017. 364 [RFC3471] Berger, L., Ed., "Generalized Multi-Protocol Label 365 Switching (GMPLS) Signaling Functional Description", 366 RFC 3471, DOI 10.17487/RFC3471, January 2003, 367 . 369 [RFC3473] Berger, L., Ed., "Generalized Multi-Protocol Label 370 Switching (GMPLS) Signaling Resource ReserVation Protocol- 371 Traffic Engineering (RSVP-TE) Extensions", RFC 3473, 372 DOI 10.17487/RFC3473, January 2003, 373 . 375 [RFC3477] Kompella, K. and Y. Rekhter, "Signalling Unnumbered Links 376 in Resource ReSerVation Protocol - Traffic Engineering 377 (RSVP-TE)", RFC 3477, DOI 10.17487/RFC3477, January 2003, 378 . 380 [RFC4208] Swallow, G., Drake, J., Ishimatsu, H., and Y. Rekhter, 381 "Generalized Multiprotocol Label Switching (GMPLS) User- 382 Network Interface (UNI): Resource ReserVation Protocol- 383 Traffic Engineering (RSVP-TE) Support for the Overlay 384 Model", RFC 4208, DOI 10.17487/RFC4208, October 2005, 385 . 387 [RFC4872] Lang, J., Ed., Rekhter, Y., Ed., and D. Papadimitriou, 388 Ed., "RSVP-TE Extensions in Support of End-to-End 389 Generalized Multi-Protocol Label Switching (GMPLS) 390 Recovery", RFC 4872, DOI 10.17487/RFC4872, May 2007, 391 . 393 [RFC4873] Berger, L., Bryskin, I., Papadimitriou, D., and A. Farrel, 394 "GMPLS Segment Recovery", RFC 4873, DOI 10.17487/RFC4873, 395 May 2007, . 397 [RFC5520] Bradford, R., Ed., Vasseur, JP., and A. Farrel, 398 "Preserving Topology Confidentiality in Inter-Domain Path 399 Computation Using a Path-Key-Based Mechanism", RFC 5520, 400 DOI 10.17487/RFC5520, April 2009, 401 . 403 [RFC6387] Takacs, A., Berger, L., Caviglia, D., Fedyk, D., and J. 404 Meuric, "GMPLS Asymmetric Bandwidth Bidirectional Label 405 Switched Paths (LSPs)", RFC 6387, DOI 10.17487/RFC6387, 406 September 2011, . 408 Authors' Addresses 410 Zafar Ali 411 Cisco Systems 413 Email: zali@cisco.com 415 Siva Sivabalan 416 Cisco Systems 418 Email: msiva@cisco.com 420 Clarence Filsfils 421 Cisco Systems 423 Email: cfilsfil@cisco.com 424 Robert Varga 425 Pantheon Technologies 427 Email: nite@hq.sk 429 Victor Lopez 430 Telefonica 432 Email: victor.lopezalvarez@telefonica.com 434 Oscar Gonzalez de Dios 435 Telefonica 437 Email: oscar.gonzalezdedios@telefonica.com 439 Haomian Zheng (Editor) 440 Huawei Technologies 441 H1-1-A043S Huawei Industrial Base, Songshanhu 442 Dongguan, Guangdong 523808 443 P.R.China 445 Email: zhenghaomian@huawei.com 447 Xian Zhang 448 Huawei Technologies 449 G1-2, Huawei Industrial Base, Bantian, Longgang District 450 Shenzhen, Guangdong 518129 451 P.R.China 453 Email: zhang.xian@huawei.com