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