idnits 2.17.1 draft-ietf-teas-fast-lsps-requirements-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: ---------------------------------------------------------------------------- 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 (October 5, 2015) is 3125 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: April 7, 2016 Applied Communication Sciences 6 G. Clapp 7 AT&T Labs Research 8 V. Shukla 9 Verizon Communications 10 October 5, 2015 12 Requirements for Very Fast Setup of GMPLS LSPs 13 draft-ietf-teas-fast-lsps-requirements-02 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 April 7, 2016. 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 . . . . . . . . . . . . . . . . . . . . . . . . . 3 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 setup 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 presents the objectives and related requirements for 108 GMPLS to provide the control for networks operating with such 109 performance requirements. While specific deployment scenarios are 110 considered as part of the presentation of objectives, the stated 111 requirements are aimed at ensuring the control protocols are not the 112 limiting factor in achieving a particular network's performance. 113 Implementation dependencies are out of scope of this document. 115 It is envisioned that other documents may be needed to define how 116 GMPLS protocols meet the requirements laid out in this document. 117 Such future documents may define extensions, or simply clarify how 118 existing mechanisms may be used to address the key requirements of 119 highly dynamic networks. 121 2. Background 123 The Defense Advanced Research Projects Agency (DARPA) Core Optical 124 Networks (CORONET) program [Chiu], is an example target environment 125 that includes IP and optical commercial and government networks, with 126 a focus on highly dynamic and resilient multi-terabit core networks. 127 It anticipates the need for rapid (sub-second) setup and SONET/SDH- 128 like restoration times for high-churn (up to tens of requests per 129 second network-wide and holding times as short as one second) on- 130 demand wavelength, sub-wavelength, and packet services for a variety 131 of applications (e.g., grid computing, cloud computing, data 132 visualization, fast data transfer, etc.). This must be done while 133 meeting stringent call blocking requirements and while minimizing the 134 use of resources such as time slots, switch ports, wavelength 135 conversion, etc. 137 3. Motivation 139 The motivation for this document, and envisioned related future 140 documents, is two-fold: 142 1. The anticipated need for rapid setup, while maintaining low 143 blocking, of large bandwidth and highly churned on-demand 144 connections (in the form of sub-wavelengths, e.g., OTN ODUx, and 145 wavelengths, e.g., OTN OCh) for a variety of applications 146 including grid computing, cloud computing, data visualization, 147 and intra- and inter-datacenter communications. 149 2. The ability to set up circuit-like LSPs for large bandwidth flows 150 with low setup delays provides an alternative to packet-based 151 solutions implemented over static circuits that may require tying 152 up more expensive and power-consuming resources (e.g., router 153 ports). Reducing the LSP setup delay will reduce the minimum 154 bandwidth threshold at which a GMPLS circuit approach is 155 preferred over a layer 3 (e.g., IP) approach. Dynamic circuit 156 and virtual circuit switching intrinsically provide guaranteed 157 bandwidth, guaranteed low-latency and jitter, and faster 158 restoration, all of which are very hard to provide in packet-only 159 networks. Again, a key element in achieving these benefits is 160 enabling the fastest possible circuit setup times. 162 Future applications are expected to require setup times as fast as 163 100 ms in highly dynamic, national-scale network environments while 164 meeting stringent blocking requirements and minimizing the use of 165 resources such as switch ports, wavelength converters/regenerators, 166 and other network design parameters. Of course, the benefits of low 167 setup delay diminish for connections with long holding times. The 168 need for rapid setup for specific applications may override and thus 169 get traded off, for these specific applications, against some other 170 features currently provided in GMPLS, e.g., robustness against setup 171 errors. 173 With the advent of data centers, cloud computing, video, gaming, 174 mobile and other broadband applications, it is anticipated that 175 connection request rates may increase, even for connections with 176 longer holding times, either during limited time periods (such as 177 during the restoration from a data center failure) or over the longer 178 term, to the point where the current GMPLS procedures of path 179 computation/selection and resource allocation may not be timely, thus 180 leading to increased blocking or increased resource cost. Thus, 181 extensions of GMPLS signaling and routing protocols (e.g., OSPF-TE) 182 may also be needed to address heavy churn of connection requests 183 (i.e., high connection request arrival rate) in networks with high 184 traffic loads, even for connections with relatively longer holding 185 times. 187 4. Driving Applications and Their Requirements 189 There are several emerging applications that fall under the problem 190 space addressed here in several service areas such as provided by 191 telecommunication carriers, government networks, enterprise networks, 192 content providers, and cloud providers. Such applications include 193 research and education networks/grid computing, and cloud computing. 194 Detailing and standardizing protocols to address these applications 195 will expedite the transition to commercial deployment. 197 In the target environment there are multiple Bandwidth-on-Demand 198 service requests per second, such as might arise as cloud services 199 proliferate. It includes dynamic services with connection setup 200 requirements that range from seconds to milliseconds. The aggregate 201 traffic demand, which is composed of both packet (IP) and circuit 202 (wavelength and sub-wavelength) services, represents a five to 203 twenty-fold increase over today's traffic levels for the largest of 204 any individual carrier. Thus, the aggressive requirements must be 205 met with solutions that are scalable, cost effective, and power 206 efficient, while providing the desired quality of service (QoS). 208 4.1. Key Application Requirements 210 There are two key performance-scaling requirements in the target 211 environment that are the main drivers behind this draft: 213 1. Connection request rates ranging from a few requests per second 214 for high capacity (e.g., 40 Gb/s , 100 Gb/s) wavelength-based 215 LSPs to around 100 requests per second for sub-wavelength LSPs 216 (e.g., OTN ODU0, ODU1, and ODU2). 218 2. Connection setup delay of around 100 ms across a national or 219 regional network. To meet this target, and assuming pipelined 220 cross-connection, and worst case propagation delay and hop count, 221 it is estimated that the maximum processing delay per hop is 222 around 700 microseconds [Lehmen]. Optimal path selection and 223 resource allocation may require somewhat longer processing (up to 224 5 milliseconds) in either the destination or source nodes and 225 possibly tighter processing delays (around 500 microseconds) in 226 intermediate nodes. 228 The model for a national network is that of the continental US with 229 up to 100 nodes and LSPs distances up to ~3000 km and up to 15 hops. 231 A connection setup delay is defined here as the time between the 232 arrival of a connection request at an ingress edge switch - or more 233 generally a Label Switch Router (LSR) - and the time at which 234 information can start flowing from that ingress switch over that 235 connection. Note that this definition is more inclusive than the LSP 236 setup time defined in [RFC5814] and [RFC6777], which do not include 237 PCE path computation delays. 239 5. Requirements for Very Fast Setup of GMPLS LSPs 241 This section lists the protocol requirements for very fast setup of 242 GMPLS LSPs in order to adequately support the service characteristics 243 described in the previous sections. These requirements may be the 244 basis for future documents, some of which may be simply 245 informational, while others may describe specific GMPLS protocol 246 extensions. While some of these requirements may have implications 247 on implementations, the intent is for the requirements to apply to 248 GMPLS protocols and their standardized mechanisms. 250 5.1. Protocol and Procedure Requirements 252 R1 The protocol processing related portion of the LSP establishment 253 time should scale linearly based on number of traversed nodes. 255 R2 End-to-end LSP data path availability should be bounded by the 256 worst case single node data path establishment time. In other 257 words, pipelined cross-connect processing as discussed in 258 [RFC6383] should be enabled. 260 R3 LSP Establishment time shall depend on the number of nodes 261 supporting an LSP and link propagation delays and not any off 262 (control) path transactions, e.g., PCC-PCE and PCC-PCC 263 communications at the time of connection setup, even when PCE- 264 based approaches are used. 266 R4 Must support LSP holding times as short as one second. 268 R5 The protocol aspects of LSP signaling must not preclude LSP 269 request rates of tens per second. 271 R6 The above requirements should be met even when there are failures 272 in connection establishment, i.e., LSPs should be established 273 faster than when crank-back is used. 275 R7 These requirements are applicable even when an LSP crosses one or 276 more administrative domains/boundaries. 278 R8 The above are additional requirements and do not replace existing 279 requirements, e.g., alarm free setup and teardown, Recovery, or 280 inter-domain confidentiality. 282 6. IANA Considerations 284 This memo includes no requests to IANA. 286 7. Security Considerations 288 Being able to support very fast setup and a high churn rate of GMPLS 289 LSPs is not expected to adversely affect the underlying security 290 issues associated with existing GMPLS signaling. If encryption that 291 requires key exchange is intended to be used on the signaled LSPs, 292 then this requirement needs to be included as a part of the protocol 293 design process, as the usual extra round trip time (RTT) for key 294 exchange will have an effect on the setup and churn rate of the GMPLS 295 LSPs. It is possible to amortize the costs of key exchange over 296 multiple exchanges (if those occur between the same peers) so that 297 some exchanges need not cost a full RTT and operate in so-called 298 zero-RTT mode. 300 8. Acknowledgements 302 The authors would like to thank Ann Von Lehmen, Joe Gannett, Ron 303 Skoog, and Haim Kobrinski of Applied Communication Sciences for their 304 comments and assistance on this document. Lou Berger provided 305 editorial comments on this document. 307 9. References 309 9.1. Normative References 311 [RFC3471] Berger, L., Ed., "Generalized Multi-Protocol Label 312 Switching (GMPLS) Signaling Functional Description", 313 RFC 3471, DOI 10.17487/RFC3471, January 2003, 314 . 316 [RFC3945] Mannie, E., Ed., "Generalized Multi-Protocol Label 317 Switching (GMPLS) Architecture", RFC 3945, 318 DOI 10.17487/RFC3945, October 2004, 319 . 321 [RFC4655] Farrel, A., Vasseur, J., and J. Ash, "A Path Computation 322 Element (PCE)-Based Architecture", RFC 4655, 323 DOI 10.17487/RFC4655, August 2006, 324 . 326 [RFC5814] Sun, W., Ed. and G. Zhang, Ed., "Label Switched Path (LSP) 327 Dynamic Provisioning Performance Metrics in Generalized 328 MPLS Networks", RFC 5814, DOI 10.17487/RFC5814, March 329 2010, . 331 [RFC6163] Lee, Y., Ed., Bernstein, G., Ed., and W. Imajuku, 332 "Framework for GMPLS and Path Computation Element (PCE) 333 Control of Wavelength Switched Optical Networks (WSONs)", 334 RFC 6163, DOI 10.17487/RFC6163, April 2011, 335 . 337 [RFC6383] Shiomoto, K. and A. Farrel, "Advice on When It Is Safe to 338 Start Sending Data on Label Switched Paths Established 339 Using RSVP-TE", RFC 6383, DOI 10.17487/RFC6383, September 340 2011, . 342 [RFC6777] Sun, W., Ed., Zhang, G., Ed., Gao, J., Xie, G., and R. 343 Papneja, "Label Switched Path (LSP) Data Path Delay 344 Metrics in Generalized MPLS and MPLS Traffic Engineering 345 (MPLS-TE) Networks", RFC 6777, DOI 10.17487/RFC6777, 346 November 2012, . 348 9.2. Informative References 350 [Chiu] A. Chiu, et al, "Architectures and Protocols for Capacity 351 Efficient, Highly Dynamic and Highly Resilient Core 352 Networks", Journal of Optical Communications and 353 Networking vol. 4, No. 1, pp. 1-14, January 2012, 354 . 356 [Lehmen] A. Von Lehmen, et al, "CORONET: Testbeds, Demonstration 357 and Lessons Learned", Journal of Optical Communications 358 and Networking Vol. 7, Issue 3, pp. A447-A458, March 2015, 359 . 362 Authors' Addresses 364 Andrew G. Malis (editor) 365 Huawei Technologies 367 Email: agmalis@gmail.com 369 Brian J. Wilson 370 Applied Communication Sciences 372 Email: bwilson@appcomsci.com 373 George Clapp 374 AT&T Labs Research 376 Email: clapp@research.att.com 378 Vishnu Shukla 379 Verizon Communications 381 Email: vishnu.shukla@verizon.com