Requirements for Very Fast Setup of GMPLS LSPs
draft-malis-ccamp-fast-lsps-03

Abstract

Establishment and control of Label Switch Paths (LSPs) have become mainstream tools of commercial and government network providers. One of the elements of further evolving such networks is scaling their performance in terms of LSP bandwidth and traffic loads, LSP intensity (e.g., rate of LSP creation, deletion, and modification), LSP set up delay, quality of service differentiation, and different levels of resilience.

The goal of this document is to present target scaling objectives and the related protocol requirements for Generalized Multi-Protocol Label Switching (GMPLS). The document also summarizes key factors affecting current GMPLS signaling procedures in meeting these application scaling requirements.

Status of This Memo

This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.

Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet-Drafts is at http://datatracker.ietf.org/drafts/current/.

Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress."

This Internet-Draft will expire on April 13, 2015.

Copyright Notice

Copyright (c) 2014 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) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.

Table of Contents

• 1. Introduction
• 2. Background
• 3. Motivation
• 4. Driving Applications and Their Requirements
• 4.1. Key Application Requirements
• 5. Potential GMPLS Limitations
• 6. Requirements for Very Fast Setup of GMPLS LSPs
• 6.1. Protocol and Procedure Requirements
• 7. IANA Considerations
• 8. Security Considerations
• 9. Acknowledgements
• 10. References
• 10.1. Normative References
• 10.2. Informative References
• Authors' Addresses

1. Introduction

Generalized Multi-Protocol Label Switching (GMPLS) [RFC3945] includes an architecture and a set of control plane protocols that can be used to operate data networks ranging from packet-switch-capable networks, through those networks that use Time Division Multiplexing, to WDM networks. The Path Computation Element (PCE) architecture [RFC4655] defines functional components that can be used to compute and suggest appropriate paths in connection-oriented traffic-engineered networks. Additional wavelength switched optical networks (WSON) considerations were defined in [RFC6163].

This document refers to the same general framework and technologies, but adds requirements related to expediting LSP setup, under heavy connection churn scenarios, while achieving low blocking, under an overall distributed control plane. This document focuses on a specific problem space – high capacity and highly dynamic connection request scenarios - that may require clarification and or extensions to current GMPLS protocols and procedures. In particular, the purpose of this document is to address the potential need for protocols and procedures that enable expediting the set up of LSPs in high churn scenarios. Both single-domain and multi-domain network scenarios are considered.

This document focuses on the following two topics: 1) the driving applications and main characteristics and requirements of this problem space, and 2) the key requirements which may be novel with respect to current GMPLS protocols.

This document intends to present the objectives and related requirements for GMPLS to provide the control for networks operating with such performance requirements. While specific deployment scenarios are considered as part of the presentation of objectives, the stated requirements are aimed at ensuring the control protocols are not the limiting factor in achieving a particular network’s performance. Implementation dependencies are out of scope of this document.

It is envisioned that other documents may be needed to define how GMPLS protocols meet the requirements laid out in this document. Such future documents may define extensions, or simply clarify how existing mechanisms may be used to address 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 that includes IP and optical commercial and government networks, with a focus 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 (up to tens of requests per second network-wide and holding times as short as one second) on-demand wavelength, sub-wavelength and packet services for a variety of applications (e.g., grid computing, cloud computing, data visualization, fast data transfer, etc.). This must be done while meeting stringent call blocking requirements, and while minimizing the use of resources such as time slots, switch ports, wavelength conversion, etc.

3. Motivation

The motivation for this document, and envisioned related future documents, is two-fold:

1. The anticipated need for rapid setup, while maintaining low blocking, of large bandwidth and highly churned on-demand connections (in the form of sub-wavelengths, e.g., OTN ODUx, and wavelengths, e.g., OTN OCh) for a variety of applications including grid computing, cloud computing, data visualization, and intra- and inter-datacenter communications.
2. The ability to setup circuit-like LSPs for large bandwidth flows with low setup delays provides an alternative to packet-based solutions implemented over static circuits that may require tying up more expensive and power-consuming resources (e.g., router ports). Reducing the LSP setup delay will reduce the minimum bandwidth threshold at which a GMPLS circuit approach is preferred over a layer 3 (e.g., IP) approach. Dynamic circuit and virtual circuit switching intrinsically provide guaranteed bandwidth, guaranteed low-latency and jitter, and faster restoration, all of which are very hard to provide in a packet-only networks. Again, a key element in achieving these benefits is enabling the fastest possible circuit setup times.

Future applications are expected to require setup times as fast as 100 ms in highly dynamic, national-scale network environments while meeting stringent blocking requirements and minimizing the use of resources such as switch ports, wavelength converters/regenerators, wavelength-km, and other network design parameters. Of course, the benefits of low setup delay diminish for connections with long holding times. The need for rapid setup for specific applications may override and thus get traded off, for these specific applications, against some other features currently provided in GMPLS, e.g., robustness against setup errors.

With the advent of data centers, cloud computing, video, gaming, mobile and other broadband applications, it is anticipated that connection request rates may increase, even for connections with longer holding times, either during limited time periods (such as during the restoration from a data center failure) or over the longer term, to the point where the current GMPLS procedures of path computation/selection and resource allocation may not be timely, thus leading to increased blocking or increased resource cost. Thus, extensions of GMPLS signaling and routing protocols (e.g. OSPF-TE) may also be needed to address heavy churn of connection requests (i.e., high connection request arrival rate) 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 that fall under the problem space addressed here in several service areas such as provided by telecommunication carriers, government networks, enterprise networks, content providers, and cloud providers. Such applications include research and education networks/grid computing, and cloud computing. Detailing and standardizing protocols to address these applications will expedite the transition to commercial deployment.

In the target environment there are multiple Bandwidth-on-Demand service requests per second, such as might arise as cloud services proliferate. It includes dynamic services with connection setup requirements that range from seconds to milliseconds. The aggregate traffic demand, which is composed of both packet (IP) and circuit (wavelength and sub-wavelength) services, represents a five to twenty-fold increase over today's traffic levels for the largest of any individual carrier. Thus, the aggressive requirements must be met with solutions that are scalable, cost effective, and power efficient, while providing the desired quality of service (QoS).

4.1. Key Application Requirements

There are two key performance scaling requirements in the target environment that are the main drivers behind this draft:

1. Connection request rate ranging from a few request per second for high capacity (e.g., 40 Gb/s , 100 Gb/s) wavelength-based LSPs to around 100 request 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 meet this target, and assuming pipelined cross-connection, and worst case propagation delay and hop count, it is estimated that the maximum processing delay per hop is around 700 microseconds [Lehmen]. Optimal path selection and resource allocation may require 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 that of the continental US with up to 100 nodes and LSPs 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. Potential GMPLS Limitations

GMPLS protocols and procedures have been developed to enable automated control of Label Switched Paths (LSPs), including setup, teardown, modification, and restoration, for switching technologies extending from layer 2 and layer 3 packets, to time division multiplexing, to wavelength, and to fiber. Thus GMPLS enables substantial improvement in connection setup delays relative to manual procedures.

However, while the GMPLS protocols are geared for a wide scope of applications and robust performance, they have not specifically addressed the more aggressive characteristics envisioned here, e.g., applications requiring very fast connection setup while maintaining a high success ratio (i.e., low blocking) in a high-churn environment. Preliminary simulations and analyses of national and global scale networks, both WSON and sub-wavelength OTN [Skoog], have shown that using current GMPLS protocols and procedures does not meet the stated performance targets with respect to blocking, setup delays, and resource utilization. These simulations have also indicated limited scalability of current protocols to increasing loads and churn beyond the baseline design.

Some possible issues with existing components of GMPLS include:

1. Path selection and resource allocation in GMPLS networks is based on TE information collected via OSPF-TE LSA updates. Thus, scenarios with highly dynamic connection request activity, where the connection request arrival rate is higher than the TE update rate allowed by OSPF-TE, could lead to unacceptable blocking ratios or low resource utilization. Recall that the minimum LSA update interval is 5 seconds within which time several connections are requested in the scenarios addressed here. Stale TE information leads also, indirectly, to longer setup delays if connection attempts are re-tried. One approach to address this issue is to increase the frequency of LSA updates. Another approach is where TE information collection is incorporated into the signaling protocol which would provide a much more timely view and thus reduced blocking. Furthermore, simultaneously probing multiple paths can be another element to reduce blocking in scenarios with highly dynamic connection requests. It should be noted that GMPLS supports distributed wavelengths allocation during the signaling phase (i.e., not just based on LSA updates) using the Label Set object and associated procedures of RSVP-TE [RFC3471]. However, in highly dynamic scenarios even the choice of route may be better made in real time rather than based on perhaps stale information. Another recent approach that can reduce the dependence of LSA updates is the use of a stateful PCE that updates an LSP data base as LSPs are set up.
2. In current GMPLS procedures, path computation, and PCC-PCE and PCC-PCC communications occur following the connection request, thus increasing overall setup delays. Although pre-computed paths are not specifically ruled out and thus can be implemented by GMPLS and stored in the PCEs or source nodes, detailed procedures need to be specified. A potential enhancement of periodical off-line downloading of multiple pre-computed paths to individual LSR nodes could, for example, significantly cut down the setup delay.
3. Current GMPLS cross-connection procedures require, as a default, a serial cross-connection processing - the cross-connection in each node must be completed before the signaling message is transmitted to the next node. This serial procedure results in cross-connection delays being accumulated in each node along the path. A procedure allowing simultaneous or pipelined cross-connections could cut this delay contribution by a factor proportional to the path hop count. Pipelined processing can be used with the RSVP-TE Path objects Suggested Label (for the forward direction) and Upstream Label (for the reverse direction). However, their successful use requires accurate resource availability information and wavelength conversion capabilities at all the nodes along the path. In heavy churned connection scenarios, the use of SL and UL objects will either mostly amount to the default serial process or require a lot of wavelength conversions. Note that this delay contribution is significant in WSON - given current optical switching delays of ~ 10-20 ms or more; it is less significant with TDM or L2 electronic switching.

Note that GMPLS allows for signaling crankbacks when a connection setup fails. Such crankbacks increase the maximum and average setup delays. Thus, reduction of blocking rates, for example, via multiple path probing as in point 1 above, will also improve the worst case and average setup delays.

Note again that these potential GMPLS extensions should be optional as they may entail increased cost or reduced functionality and thus should only be used when needed.

6. Requirements for Very Fast Setup of GMPLS LSPs

This section lists the protocol requirements for very fast setup of GMPLS LSPs in order to adequately support the service characteristics described in the previous sections. These requirements may be the basis for future documents, some of which may be simply informational, while others may describe specific GMPLS protocol extensions. While some of these requirements may be have implications on implementations, the intent is for the requirements to apply to GMPLS protocols and their standardized mechanisms.

6.1. Protocol and Procedure Requirements

R1

Protocol extensions must be backward compatible with existing GMPLS control plane protocols. The purpose of this obvious requirement is to indicate that applications that do not need the performance addressed here and thus do not need the required protocol extensions should be able to use currently existing GMPLS protocols.

R2

Use of optional GMPLS protocol extensions for this application must be selectable by provisioning or configuration.

R3

LSP Establishment time should scale linearly based on number of traversed nodes.

R4

LSP Establishment time should be bounded by a single (worst case) per-node data path (cross-connect) establishment time and not scale linearly based on number of traversed nodes, i.e., support parallel or pipelined cross-connection establishment.

R5

LSP Establishment time shall depend on number of nodes supporting an LSP and link propagation delays and not 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.

R6

Must support LSP holding times as short as one second to one minute.

R7

The protocol aspects of LSP signaling must not preclude LSP request rates of tens per second.

R8

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.

R9

These requirements are applicable even when an LSP crosses one or more administrative domains / boundaries.

R10

The above are additional requirements and do not replace existing requirements, e.g. alarm free setup and teardown, Recovery, or inter-domain confidentiality.

7. IANA Considerations

This memo includes no requests to IANA.

8. Security Considerations

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.

9. Acknowledgements

The authors would like to thank Ann Von Lehmen, Joe Gannett, and Brian Wilson of Applied Communication Sciences for their comments and assistance on this document. Lou Berger provided editorial comments on this document.

10. References

10.1. Normative References

10.2. Informative References

Authors' Addresses