idnits 2.17.00 (12 Aug 2021) /tmp/idnits34829/draft-ietf-teas-fast-lsps-requirements-01.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 -- The document date (June 11, 2015) is 2536 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- No issues found here. Summary: 0 errors (**), 0 flaws (~~), 1 warning (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Internet Engineering Task Force (IETF) A. Malis, Ed. 3 Internet-Draft Huawei Technologies 4 Intended status: Informational B. Wilson 5 Expires: December 13, 2015 Applied Communication Sciences 6 G. Clapp 7 AT&T Labs Research 8 V. Shukla 9 Verizon Communications 10 June 11, 2015 12 Requirements for Very Fast Setup of GMPLS LSPs 13 draft-ietf-teas-fast-lsps-requirements-01 15 Abstract 17 Establishment and control of Label Switch Paths (LSPs) have become 18 mainstream tools of commercial and government network providers. One 19 of the elements of further evolving such networks is scaling their 20 performance in terms of LSP bandwidth and traffic loads, LSP 21 intensity (e.g., rate of LSP creation, deletion, and modification), 22 LSP set up delay, quality of service differentiation, and different 23 levels of resilience. 25 The goal of this document is to present target scaling objectives and 26 the related protocol requirements for Generalized Multi-Protocol 27 Label Switching (GMPLS). 29 Status of This Memo 31 This Internet-Draft is submitted in full conformance with the 32 provisions of BCP 78 and BCP 79. 34 Internet-Drafts are working documents of the Internet Engineering 35 Task Force (IETF). Note that other groups may also distribute 36 working documents as Internet-Drafts. The list of current Internet- 37 Drafts is at http://datatracker.ietf.org/drafts/current/. 39 Internet-Drafts are draft documents valid for a maximum of six months 40 and may be updated, replaced, or obsoleted by other documents at any 41 time. It is inappropriate to use Internet-Drafts as reference 42 material or to cite them other than as "work in progress." 44 This Internet-Draft will expire on December 13, 2015. 46 Copyright Notice 48 Copyright (c) 2015 IETF Trust and the persons identified as the 49 document authors. All rights reserved. 51 This document is subject to BCP 78 and the IETF Trust's Legal 52 Provisions Relating to IETF Documents 53 (http://trustee.ietf.org/license-info) in effect on the date of 54 publication of this document. Please review these documents 55 carefully, as they describe your rights and restrictions with respect 56 to this document. Code Components extracted from this document must 57 include Simplified BSD License text as described in Section 4.e of 58 the Trust Legal Provisions and are provided without warranty as 59 described in the Simplified BSD License. 61 Table of Contents 63 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 64 2. Background . . . . . . . . . . . . . . . . . . . . . . . . . 3 65 3. Motivation . . . . . . . . . . . . . . . . . . . . . . . . . 4 66 4. Driving Applications and Their Requirements . . . . . . . . . 5 67 4.1. Key Application Requirements . . . . . . . . . . . . . . 5 68 5. Requirements for Very Fast Setup of GMPLS LSPs . . . . . . . 6 69 5.1. Protocol and Procedure Requirements . . . . . . . . . . . 6 70 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7 71 7. Security Considerations . . . . . . . . . . . . . . . . . . . 7 72 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 7 73 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 7 74 9.1. Normative References . . . . . . . . . . . . . . . . . . 7 75 9.2. Informative References . . . . . . . . . . . . . . . . . 8 76 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 8 78 1. Introduction 80 Generalized Multi-Protocol Label Switching (GMPLS) [RFC3471] 81 [RFC3945] includes an architecture and a set of control plane 82 protocols that can be used to operate data networks ranging from 83 packet-switch-capable networks, through those networks that use Time 84 Division Multiplexing, to WDM networks. The Path Computation Element 85 (PCE) architecture [RFC4655] defines functional components that can 86 be used to compute and suggest appropriate paths in connection- 87 oriented traffic-engineered networks. Additional wavelength switched 88 optical networks (WSON) considerations were defined in [RFC6163]. 90 This document refers to the same general framework and technologies, 91 but adds requirements related to expediting LSP setup, under heavy 92 connection churn scenarios, while achieving low blocking, under an 93 overall distributed control plane. This document focuses on a 94 specific problem space - high capacity and highly dynamic connection 95 request scenarios - that may require clarification and or extensions 96 to current GMPLS protocols and procedures. In particular, the 97 purpose of this document is to address the potential need for 98 protocols and procedures that enable expediting the set up of LSPs in 99 high churn scenarios. Both single-domain and multi-domain network 100 scenarios are considered. 102 This document focuses on the following two topics: 1) the driving 103 applications and main characteristics and requirements of this 104 problem space, and 2) the key requirements which may be novel with 105 respect to current GMPLS protocols. 107 This document intends to present the objectives and related 108 requirements for GMPLS to provide the control for networks operating 109 with such performance requirements. While specific deployment 110 scenarios are considered as part of the presentation of objectives, 111 the stated requirements are aimed at ensuring the control protocols 112 are not the limiting factor in achieving a particular network's 113 performance. Implementation dependencies are out of scope of this 114 document. 116 It is envisioned that other documents may be needed to define how 117 GMPLS protocols meet the requirements laid out in this document. 118 Such future documents may define extensions, or simply clarify how 119 existing mechanisms may be used to address the key requirements of 120 highly dynamic networks. 122 2. Background 124 The Defense Advanced Research Projects Agency (DARPA) Core Optical 125 Networks (CORONET) program [Chiu], is an example target environment 126 that includes IP and optical commercial and government networks, with 127 a focus on highly dynamic and resilient multi-terabit core networks. 128 It anticipates the need for rapid (sub-second) setup and SONET/SDH- 129 like restoration times for high-churn (up to tens of requests per 130 second network-wide and holding times as short as one second) on- 131 demand wavelength, sub-wavelength and packet services for a variety 132 of applications (e.g., grid computing, cloud computing, data 133 visualization, fast data transfer, etc.). This must be done while 134 meeting stringent call blocking requirements, and while minimizing 135 the use of resources such as time slots, switch ports, wavelength 136 conversion, etc. 138 3. Motivation 140 The motivation for this document, and envisioned related future 141 documents, is two-fold: 143 1. The anticipated need for rapid setup, while maintaining low 144 blocking, of large bandwidth and highly churned on-demand 145 connections (in the form of sub-wavelengths, e.g., OTN ODUx, and 146 wavelengths, e.g., OTN OCh) for a variety of applications 147 including grid computing, cloud computing, data visualization, 148 and intra- and inter-datacenter communications. 150 2. The ability to setup circuit-like LSPs for large bandwidth flows 151 with low setup delays provides an alternative to packet-based 152 solutions implemented over static circuits that may require tying 153 up more expensive and power-consuming resources (e.g., router 154 ports). Reducing the LSP setup delay will reduce the minimum 155 bandwidth threshold at which a GMPLS circuit approach is 156 preferred over a layer 3 (e.g., IP) approach. Dynamic circuit 157 and virtual circuit switching intrinsically provide guaranteed 158 bandwidth, guaranteed low-latency and jitter, and faster 159 restoration, all of which are very hard to provide in a packet- 160 only networks. Again, a key element in achieving these benefits 161 is enabling the fastest possible circuit setup times. 163 Future applications are expected to require setup times as fast as 164 100 ms in highly dynamic, national-scale network environments while 165 meeting stringent blocking requirements and minimizing the use of 166 resources such as switch ports, wavelength converters/regenerators, 167 and other network design parameters. Of course, the benefits of low 168 setup delay diminish for connections with long holding times. The 169 need for rapid setup for specific applications may override and thus 170 get traded off, for these specific applications, against some other 171 features currently provided in GMPLS, e.g., robustness against setup 172 errors. 174 With the advent of data centers, cloud computing, video, gaming, 175 mobile and other broadband applications, it is anticipated that 176 connection request rates may increase, even for connections with 177 longer holding times, either during limited time periods (such as 178 during the restoration from a data center failure) or over the longer 179 term, to the point where the current GMPLS procedures of path 180 computation/selection and resource allocation may not be timely, thus 181 leading to increased blocking or increased resource cost. Thus, 182 extensions of GMPLS signaling and routing protocols (e.g. OSPF-TE) 183 may also be needed to address heavy churn of connection requests 184 (i.e., high connection request arrival rate) in networks with high 185 traffic loads, even for connections with relatively longer holding 186 times. 188 4. Driving Applications and Their Requirements 190 There are several emerging applications that fall under the problem 191 space addressed here in several service areas such as provided by 192 telecommunication carriers, government networks, enterprise networks, 193 content providers, and cloud providers. Such applications include 194 research and education networks/grid computing, and cloud computing. 195 Detailing and standardizing protocols to address these applications 196 will expedite the transition to commercial deployment. 198 In the target environment there are multiple Bandwidth-on-Demand 199 service requests per second, such as might arise as cloud services 200 proliferate. It includes dynamic services with connection setup 201 requirements that range from seconds to milliseconds. The aggregate 202 traffic demand, which is composed of both packet (IP) and circuit 203 (wavelength and sub-wavelength) services, represents a five to 204 twenty-fold increase over today's traffic levels for the largest of 205 any individual carrier. Thus, the aggressive requirements must be 206 met with solutions that are scalable, cost effective, and power 207 efficient, while providing the desired quality of service (QoS). 209 4.1. Key Application Requirements 211 There are two key performance scaling requirements in the target 212 environment that are the main drivers behind this draft: 214 1. Connection request rate ranging from a few request per second for 215 high capacity (e.g., 40 Gb/s , 100 Gb/s) wavelength-based LSPs to 216 around 100 request per second for sub-wavelength LSPs (e.g., OTN 217 ODU0, ODU1, and ODU2). 219 2. Connection setup delay of around 100 ms across a national or 220 regional network. To meet this target, and assuming pipelined 221 cross-connection, and worst case propagation delay and hop count, 222 it is estimated that the maximum processing delay per hop is 223 around 700 microseconds [Lehmen]. Optimal path selection and 224 resource allocation may require somewhat longer processing (up to 225 5 milliseconds) in either the destination or source nodes and 226 possibly tighter processing delays (around 500 microseconds) in 227 intermediate nodes. 229 The model for a national network is that of the continental US with 230 up to 100 nodes and LSPs distances up to ~3000 km and up to 15 hops. 232 A connection setup delay is defined here as the time between the 233 arrival of a connection request at an ingress edge switch - or more 234 generally a Label Switch Router (LSR) - and the time at which 235 information can start flowing from that ingress switch over that 236 connection. Note that this definition is more inclusive than the LSP 237 setup time defined in [RFC5814] and [RFC6777], which do not include 238 PCE path computation delays. 240 5. Requirements for Very Fast Setup of GMPLS LSPs 242 This section lists the protocol requirements for very fast setup of 243 GMPLS LSPs in order to adequately support the service characteristics 244 described in the previous sections. These requirements may be the 245 basis for future documents, some of which may be simply 246 informational, while others may describe specific GMPLS protocol 247 extensions. While some of these requirements may be have 248 implications on implementations, the intent is for the requirements 249 to apply to GMPLS protocols and their standardized mechanisms. 251 5.1. Protocol and Procedure Requirements 253 R1 The protocol processing related portion of the LSP establishment 254 time should scale linearly based on number of traversed nodes. 256 R2 End-to-end LSP data path availability should be bounded by the 257 worst case single node data path establishment time. In other 258 words, pipelined cross-connect processing as discussed in 259 [RFC6383] should be enabled. 261 R3 LSP Establishment time shall depend on number of nodes supporting 262 an LSP and link propagation delays and not any off (control) path 263 transactions, e.g., PCC-PCE and PCC-PCC communications at the 264 time of connection setup, even when PCE-based approaches are 265 used. 267 R4 Must support LSP holding times as short as one second. 269 R5 The protocol aspects of LSP signaling must not preclude LSP 270 request rates of tens per second. 272 R6 The above requirements should be met even when there are failures 273 in connection establishment, i.e., LSPs should be established 274 faster than when crank-back is used. 276 R7 These requirements are applicable even when an LSP crosses one or 277 more administrative domains/boundaries. 279 R8 The above are additional requirements and do not replace existing 280 requirements, e.g. alarm free setup and teardown, Recovery, or 281 inter-domain confidentiality. 283 6. IANA Considerations 285 This memo includes no requests to IANA. 287 7. Security Considerations 289 Being able to support very fast setup and a high churn rate of GMPLS 290 LSPs is not expected to adversely affect the underlying security 291 issues associated with existing GMPLS signaling. 293 8. Acknowledgements 295 The authors would like to thank Ann Von Lehmen, Joe Gannett, Ron 296 Skoog, and Haim Kobrinski of Applied Communication Sciences for their 297 comments and assistance on this document. Lou Berger provided 298 editorial comments on this document. 300 9. References 302 9.1. Normative References 304 [RFC3471] Berger, L., "Generalized Multi-Protocol Label Switching 305 (GMPLS) Signaling Functional Description", RFC 3471, 306 January 2003. 308 [RFC3945] Mannie, E., "Generalized Multi-Protocol Label Switching 309 (GMPLS) Architecture", RFC 3945, October 2004. 311 [RFC4655] Farrel, A., Vasseur, J., and J. Ash, "A Path Computation 312 Element (PCE)-Based Architecture", RFC 4655, August 2006. 314 [RFC5814] Sun, W. and G. Zhang, "Label Switched Path (LSP) Dynamic 315 Provisioning Performance Metrics in Generalized MPLS 316 Networks", RFC 5814, March 2010. 318 [RFC6163] Lee, Y., Bernstein, G., and W. Imajuku, "Framework for 319 GMPLS and Path Computation Element (PCE) Control of 320 Wavelength Switched Optical Networks (WSONs)", RFC 6163, 321 April 2011. 323 [RFC6383] Shiomoto, K. and A. Farrel, "Advice on When It Is Safe to 324 Start Sending Data on Label Switched Paths Established 325 Using RSVP-TE", RFC 6383, September 2011. 327 [RFC6777] Sun, W., Zhang, G., Gao, J., Xie, G., and R. Papneja, 328 "Label Switched Path (LSP) Data Path Delay Metrics in 329 Generalized MPLS and MPLS Traffic Engineering (MPLS-TE) 330 Networks", RFC 6777, November 2012. 332 9.2. Informative References 334 [Chiu] A. Chiu, et al, "Architectures and Protocols for Capacity 335 Efficient, Highly Dynamic and Highly Resilient Core 336 Networks", Journal of Optical Communications and 337 Networking vol. 4, No. 1, pp. 1-14, January 2012, 338 . 340 [Lehmen] A. Von Lehmen, et al, "CORONET: Testbeds, Demonstration 341 and Lessons Learned", Journal of Optical Communications 342 and Networking Vol. 7, Issue 3, pp. A447-A458, March 2015, 343 . 346 Authors' Addresses 348 Andrew G. Malis (editor) 349 Huawei Technologies 351 Email: agmalis@gmail.com 353 Brian J. Wilson 354 Applied Communication Sciences 356 Email: bwilson@appcomsci.com 358 George Clapp 359 AT&T Labs Research 361 Email: clapp@research.att.com 363 Vishnu Shukla 364 Verizon Communications 366 Email: vishnu.shukla@verizon.com