RFC 7709

Requirements for Very Fast Setup of GMPLS Label Switched Paths (LSPs)

📅 published November 2015, from ietf

RFC 7709 🦋 Requirements for Very Fast Setup of GMPLS Label Switched Paths (LSPs)

okay bestie, this one is a requirements doc about making GMPLS set up LSPs super fast when a ton of connections are coming and going 💅✨

  • RFC number: 7709
  • Authors: A. Malis, Ed. (Huawei Technologies), B. Wilson (Applied Communication Sciences), G. Clapp (AT&T Labs Research), V. Shukla (Verizon Communications)
  • Category: Informational (so it's published for info, not as a Standards Track spec, no pressure 🫶)
  • ISSN: 2070-1721
  • Date: November 2015
  • Obsoletes / Updates: the header doesn't list any RFCs it obsoletes or updates 🌸

Abstract 💜

LSPs (Label Switched Paths) are now a mainstream thing for commercial and government network providers, which is honestly iconic 👑. The next step in making these networks even better is scaling how they perform: LSP bandwidth and traffic loads, LSP intensity (how often LSPs get created, deleted, and modified), LSP setup delay, quality-of-service differentiation, and different levels of resilience 🌈.

The goal of this doc is to lay out target scaling objectives and the protocol requirements that go with them for Generalized Multi-Protocol Label Switching (GMPLS) ✨.

Status of This Memo 📝

This document is not an Internet Standards Track specification. It's published for informational purposes, so chill 🍓

It's a product of the Internet Engineering Task Force (IETF) and represents the consensus of the IETF community. It got public review and was approved for publication by the Internet Engineering Steering Group (IESG). Not every IESG-approved doc is a candidate for any level of Internet Standard, though. See Section 2 of RFC 5741 for that 🧚

For the current status, any errata, and how to give feedback, check http://www.rfc-editor.org/info/rfc7709 🔍

Copyright (c) 2015 IETF Trust and the persons identified as the document authors. All rights reserved.

This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) as they're in effect on the date of publication. Please actually read these, because they spell out your rights and restrictions for this doc 🙈

If you pull Code Components out of this document, they must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions. They're provided without warranty, as described in the Simplified BSD License 💖

Table of Contents 🗺️

1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   3
2.  Background  . . . . . . . . . . . . . . . . . . . . . . . . .   3
3.  Motivation  . . . . . . . . . . . . . . . . . . . . . . . . .   4
4.  Driving Applications and Their Requirements . . . . . . . . .   5
  4.1.  Key Application Requirements  . . . . . . . . . . . . . .   5
5.  Requirements for Very Fast Setup of GMPLS LSPs  . . . . . . .   6
  5.1.  Protocol and Procedure Requirements . . . . . . . . . . .   6
6.  Security Considerations . . . . . . . . . . . . . . . . . . .   7
7.  Acknowledgements  . . . . . . . . . . . . . . . . . . . . . .   7
8.  References  . . . . . . . . . . . . . . . . . . . . . . . . .   7
  8.1.  Normative References  . . . . . . . . . . . . . . . . . .   7
  8.2.  Informative References  . . . . . . . . . . . . . . . . .   8
Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .   9

1. Introduction 🎀

okay so GMPLS [RFC3471] [RFC3945] is this whole architecture plus a set of control-plane protocols for running data networks. It covers everything from packet-switch-capable networks, through networks using Time Division Multiplexing, all the way to WDM networks 🌈

The Path Computation Element (PCE) architecture [RFC4655] defines functional components that can compute and suggest good paths in connection-oriented traffic-engineered networks 🧠. And wavelength switched optical networks (WSON) got their own considerations in [RFC6163] ✨

This doc uses the same general framework and technologies, but it adds requirements for speeding up LSP setup when there's heavy connection churn, while still keeping blocking low under an overall distributed control plane 🦋. It zooms in on high-capacity, highly dynamic connection request scenarios, which might need some clarification or extensions to current GMPLS protocols and procedures 💅. So the real point is to address the potential need for protocols and procedures that expedite LSP setup in high-churn scenarios. Both single-domain and multi-domain network scenarios are covered 🫶

This doc focuses on two big things: 1) the driving applications, plus the main characteristics and requirements of this problem space, and 2) the key requirements that might be new compared to current GMPLS protocols 🔥

It presents the objectives and related requirements for GMPLS to provide control for networks that have these performance needs. Specific deployment scenarios are part of the objectives, but the big idea is making sure the control protocols are not the thing holding back a network's performance. Implementation dependencies are out of scope here 🙈

Other documents may be needed to show how GMPLS protocols meet the requirements in this doc. Those future docs might define extensions, or they might just clarify how existing mechanisms can be used for the key requirements of highly dynamic networks 🧚

2. Background 🌷

The Defense Advanced Research Projects Agency (DARPA) Core Optical Networks (CORONET) program [Chiu] is an example target environment. It includes IP and optical commercial and government networks, focused on highly dynamic and resilient multi-terabit core networks 🌐

It anticipates the need for rapid (sub-second) setup and SONET/SDH-like restoration times for high-churn situations. We're talking up to tens of requests per second network-wide, with holding times as short as one second 😭. That's for on-demand wavelength, sub-wavelength, and packet services for all kinds of apps, like grid computing, cloud computing, data visualization, fast data transfer, and more 💖

Meanwhile it has to hit stringent call-blocking requirements and keep resource use low, things like time slots, switch ports, and wavelength conversion 👑

3. Motivation 💜

The motivation for this doc, and the related future docs it envisions, has two parts:

  1. The anticipated need for rapid setup, while keeping blocking low, for large-bandwidth and highly churned on-demand connections. These come as sub-wavelengths (e.g., OTN ODUx) and wavelengths (e.g., OTN OCh) for apps like grid computing, cloud computing, data visualization, and intra- and inter-datacenter communications 🍓
  2. The ability to set up circuit-like LSPs for large-bandwidth flows with low setup delays gives you an alternative to packet-based solutions built over static circuits. Those static setups can tie up pricier, more power-hungry resources like router ports 🔋. Cutting LSP setup delay lowers the minimum bandwidth threshold where a GMPLS circuit approach beats a layer 3 (e.g., IP) approach. Dynamic circuit and virtual circuit switching naturally give you guaranteed bandwidth, guaranteed low latency and jitter, and faster restoration. All of that is super hard to get in packet-only networks ✨. And again, the key to unlocking these benefits is getting the fastest possible circuit setup times 🏃‍♀️

Future apps are expected to need setup times as fast as 100 ms in highly dynamic, national-scale network environments. They still have to meet stringent blocking requirements and minimize use of resources like switch ports, wavelength converters/regenerators, and other network design parameters 🦋. Of course, the perks of low setup delay shrink for connections with long holding times 🙃. For some specific apps, a trade-off might be needed, because rapid setup could matter more to them than other features GMPLS already provides (e.g., robustness against setup errors) 🫠

With data centers, cloud computing, video, gaming, mobile, and other broadband apps everywhere, connection request rates may go up. That's true even for connections with longer holding times 📈. It could happen for limited periods (like during restoration from a data center failure) or over the long term. At some point the current GMPLS procedures for path computation/selection and resource allocation might not be timely enough, which leads to more blocking or higher resource cost 😵. So extensions to GMPLS signaling and routing protocols (e.g., OSPF-TE) may also be needed to handle heavy churn of connection requests, meaning high connection-request arrival rates in networks with high traffic loads, even for connections with relatively longer holding times 🌈

4. Driving Applications and Their Requirements 🚀

There are several emerging applications in this problem space, across service areas like telecommunication carriers, government networks, enterprise networks, content providers, and cloud providers 🌍. They include research and education networks / grid computing, and cloud computing. Detailing and standardizing protocols for these apps will speed up the move to commercial deployment 💅

In the target environment there are multiple Bandwidth-on-Demand service requests per second. That's the kind of thing that pops up as cloud services take off 📱. It includes dynamic services with connection setup requirements that range from seconds all the way down to milliseconds ⚡. The aggregate traffic demand, made of both packet (IP) and circuit (wavelength and sub-wavelength) services, is a five-to-twenty-fold increase over today's traffic levels for the largest individual carrier. Wild, right? 😭 So the aggressive requirements have to be met with solutions that are scalable, cost-effective, and power-efficient, while still delivering the quality of service (QoS) people want 👑💖

4.1. Key Application Requirements

okay so there are two key performance-scaling requirements in the target environment, and they're the main reason this document exists 💅✨

  1. Connection request rates ranging from a few requests per second for high-capacity (e.g., 40 Gb/s, 100 Gb/s) wavelength-based LSPs to around 100 requests per second for sub-wavelength LSPs (e.g., OTN ODU0, ODU1, and ODU2) 🌈
  2. Connection setup delay of around 100 ms across a national or regional network 🦋 To hit this target, assuming pipelined cross-connection and worst-case propagation delay and hop count, it's estimated that the maximum processing delay per hop is around 700 microseconds [Lehmen]. Optimal path selection and resource allocation may need somewhat longer processing (up to 5 milliseconds) in either the destination or source nodes, and possibly tighter processing delays (around 500 microseconds) in intermediate nodes 😭

The model for a national network is the continental US, with up to 100 nodes and LSPs with distances up to ~3000 km and up to 15 hops 🍓

A connection setup delay is defined here as the time between the arrival of a connection request at an ingress edge switch -- or more generally a Label Switch Router (LSR) -- and the time at which information can start flowing from that ingress switch over that connection. Note that this definition is more inclusive than the LSP setup time defined in [RFC5814] and [RFC6777], which do not include PCE path computation delays 🙈

5. Requirements for Very Fast Setup of GMPLS LSPs ✨

this section lists the protocol requirements for very fast setup of GMPLS LSPs, so they can properly support the service characteristics from the previous sections 🧚 These requirements may be the basis for future documents, some of which may be purely informational, while others may describe specific GMPLS protocol extensions. Some of these requirements may have implications on implementations, but the intent is for the requirements to apply to GMPLS protocols and their standardized mechanisms 💜

5.1. Protocol and Procedure Requirements

  • R1 The portion of the LSP establishment time related to protocol processing should scale linearly based on the number of traversed nodes.
  • R2 End-to-end LSP data path availability should be bounded by the worst-case single-node data path establishment time. In other words, pipelined cross-connect processing as discussed in [RFC6383] should be enabled. 🔥
  • R3 LSP establishment time shall depend on the number of nodes supporting an LSP and link propagation delays, and not on any off (control) path transactions, e.g., PCC-PCE and PCC-PCC communications at the time of connection setup, even when PCE-based approaches are used. 👑
  • R4 LSP holding times as short as one second must be supported. ⭐
  • R5 The protocol aspects of LSP signaling must not preclude LSP request rates of tens per second. 🎀
  • R6 The above requirements should be met even when there are failures in connection establishment, i.e., LSPs should be established faster than when crank-back is used. 💀
  • R7 These requirements are applicable even when an LSP crosses one or more administrative domains/boundaries. 🌸
  • R8 The above are additional requirements and do not replace existing requirements, e.g., alarm-free setup and teardown, recovery, or inter-domain confidentiality. 🫶

6. Security Considerations

Okay bestie, this part is SERIOUS 🚨 Being able to support very fast setup and a high-churn rate of GMPLS LSPs is not expected to adversely affect the underlying security issues associated with existing GMPLS signaling. If encryption that requires key exchange is intended to be used on the signaled LSPs, then this requirement needs to be included as a part of the protocol design process, because the usual extra round-trip time (RTT) for key exchange will have an effect on the setup and churn rate of the GMPLS LSPs. It is possible to amortize the costs of key exchange over multiple exchanges (if those occur between the same peers), so that some exchanges need not cost a full RTT and operate in so-called zero-RTT mode 🔐💅

7. Acknowledgements

The authors would like to thank Ann Von Lehmen, Joe Gannett, Ron Skoog, and Haim Kobrinski of Applied Communication Sciences for their comments and assistance on this document 🫶 Lou Berger provided editorial comments on this document too 🌷

8. References

8.1. Normative References

[RFC3471]  Berger, L., Ed., "Generalized Multi-Protocol Label
           Switching (GMPLS) Signaling Functional Description",
           RFC 3471, DOI 10.17487/RFC3471, January 2003,
           <http://www.rfc-editor.org/info/rfc3471>.

[RFC3945]  Mannie, E., Ed., "Generalized Multi-Protocol Label
           Switching (GMPLS) Architecture", RFC 3945,
           DOI 10.17487/RFC3945, October 2004,
           <http://www.rfc-editor.org/info/rfc3945>.

[RFC4655]  Farrel, A., Vasseur, J., and J. Ash, "A Path Computation
           Element (PCE)-Based Architecture", RFC 4655,
           DOI 10.17487/RFC4655, August 2006,
           <http://www.rfc-editor.org/info/rfc4655>.

[RFC5814]  Sun, W., Ed. and G. Zhang, Ed., "Label Switched Path (LSP)
           Dynamic Provisioning Performance Metrics in Generalized
           MPLS Networks", RFC 5814, DOI 10.17487/RFC5814, March
           2010, <http://www.rfc-editor.org/info/rfc5814>.

[RFC6163]  Lee, Y., Ed., Bernstein, G., Ed., and W. Imajuku,
           "Framework for GMPLS and Path Computation Element (PCE)
           Control of Wavelength Switched Optical Networks (WSONs)",
           RFC 6163, DOI 10.17487/RFC6163, April 2011,
           <http://www.rfc-editor.org/info/rfc6163>.

[RFC6383]  Shiomoto, K. and A. Farrel, "Advice on When It Is Safe to
           Start Sending Data on Label Switched Paths Established
           Using RSVP-TE", RFC 6383, DOI 10.17487/RFC6383, September
           2011, <http://www.rfc-editor.org/info/rfc6383>.

[RFC6777]  Sun, W., Ed., Zhang, G., Ed., Gao, J., Xie, G., and R.
           Papneja, "Label Switched Path (LSP) Data Path Delay
           Metrics in Generalized MPLS and MPLS Traffic Engineering
           (MPLS-TE) Networks", RFC 6777, DOI 10.17487/RFC6777,
           November 2012, <http://www.rfc-editor.org/info/rfc6777>.

8.2. Informative References

[Chiu]     Chiu, A., et al., "Architectures and Protocols for
           Capacity Efficient, Highly Dynamic and Highly Resilient
           Core Networks", Journal of Optical Communications and
           Networking vol. 4, No. 1, pp. 1-14, 2012,
           DOI 10.1364/JOCN.4.000001,
           <http://dx.doi.org/10.1364/JOCN.4.000001>.

[Lehmen]   Von Lehmen, A., et al., "CORONET: Testbeds, Demonstration,
           and Lessons Learned", Journal of Optical Communications
           and Networking Vol. 7, Issue 3, pp. A447-A458, 2015,
           DOI 10.1364/JOCN.7.00A447,
           <http://dx.doi.org/10.1364/JOCN.7.00A447>.

Authors' Addresses

Andrew G. Malis (editor)
Huawei Technologies

Email: agmalis@gmail.com


Brian J. Wilson
Applied Communication Sciences

Email: bwilson@appcomsci.com


George Clapp
AT&T Labs Research

Email: clapp@research.att.com


Vishnu Shukla
Verizon Communications

Email: vishnu.shukla@verizon.com

That's the whole spec, bestie 🌈💖 You made it through!

📦 where this page comes from