Skip to main content

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

The information below is for an old version of the document.
Document Type
This is an older version of an Internet-Draft whose latest revision state is "Replaced".
Authors Andrew G. Malis , Ronald A. Skoog , Haim Kobrinski , George Clapp , Vishnu Shukla
Last updated 2014-10-10
Replaced by draft-ietf-teas-fast-lsps-requirements, RFC 7709
RFC stream (None)
Formats
Additional resources
Stream Stream state (No stream defined)
Consensus boilerplate Unknown
RFC Editor Note (None)
IESG IESG state I-D Exists
Telechat date (None)
Responsible AD (None)
Send notices to (None)
draft-malis-ccamp-fast-lsps-03
Internet Engineering Task Force (IETF)                     A. Malis, Ed.
Internet-Draft                                       Huawei Technologies
Intended status: Informational                                  R. Skoog
Expires: April 13, 2015                                     H. Kobrinski
                                          Applied Communication Sciences
                                                                G. Clapp
                                                      AT&T Labs Research
                                                               V. Shukla
                                                  Verizon Communications
                                                        October 10, 2014

             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.

Malis, et al.            Expires April 13, 2015                 [Page 1]
Internet-Draft        Very Fast Setup of GMPLS LSPs         October 2014

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

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

Malis, et al.            Expires April 13, 2015                 [Page 2]
Internet-Draft        Very Fast Setup of GMPLS LSPs         October 2014

   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.

Malis, et al.            Expires April 13, 2015                 [Page 3]
Internet-Draft        Very Fast Setup of GMPLS LSPs         October 2014

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

Malis, et al.            Expires April 13, 2015                 [Page 4]
Internet-Draft        Very Fast Setup of GMPLS LSPs         October 2014

   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.

Malis, et al.            Expires April 13, 2015                 [Page 5]
Internet-Draft        Very Fast Setup of GMPLS LSPs         October 2014

   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

Malis, et al.            Expires April 13, 2015                 [Page 6]
Internet-Draft        Very Fast Setup of GMPLS LSPs         October 2014

       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.

Malis, et al.            Expires April 13, 2015                 [Page 7]
Internet-Draft        Very Fast Setup of GMPLS LSPs         October 2014

   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.

Malis, et al.            Expires April 13, 2015                 [Page 8]
Internet-Draft        Very Fast Setup of GMPLS LSPs         October 2014

   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

   [RFC3471]  Berger, L., "Generalized Multi-Protocol Label Switching
              (GMPLS) Signaling Functional Description", RFC 3471,
              January 2003.

   [RFC3945]  Mannie, E., "Generalized Multi-Protocol Label Switching
              (GMPLS) Architecture", RFC 3945, October 2004.

   [RFC4655]  Farrel, A., Vasseur, J., and J. Ash, "A Path Computation
              Element (PCE)-Based Architecture", RFC 4655, August 2006.

   [RFC5814]  Sun, W. and G. Zhang, "Label Switched Path (LSP) Dynamic
              Provisioning Performance Metrics in Generalized MPLS
              Networks", RFC 5814, March 2010.

Malis, et al.            Expires April 13, 2015                 [Page 9]
Internet-Draft        Very Fast Setup of GMPLS LSPs         October 2014

   [RFC6163]  Lee, Y., Bernstein, G., and W. Imajuku, "Framework for
              GMPLS and Path Computation Element (PCE) Control of
              Wavelength Switched Optical Networks (WSONs)", RFC 6163,
              April 2011.

   [RFC6777]  Sun, W., Zhang, G., 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, November 2012.

10.2.  Informative References

   [Chiu]     A. Chiu, 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, January 2012,
              <http://dx.doi.org/10.1364/JOCN.4.000001>.

   [Lehmen]   A. Von Lehmen, et al, "CORONET: Testbeds, Demonstration
              and Lessons Learned", Journal of Optical Communications
              and Networking vol. 7, No. 1, January 2015 (expected).

   [Skoog]    R. Skoog, et al, "Analysis and Implementation of a 3-Way
              Handshake Signaling Protocol for Highly Dynamic Transport
              Networks", OFC 2014, <http://www.opticsinfobase.org/
              abstract.cfm?URI=OFC-2014-W1K.1>.

Authors' Addresses

   Andrew G. Malis (editor)
   Huawei Technologies

   Email: agmalis@gmail.com

   Ronald A. Skoog
   Applied Communication Sciences

   Email: rskoog@appcomsci.com

   Haim Kobrinski
   Applied Communication Sciences

   Email: hkobrinski@appcomsci.com

Malis, et al.            Expires April 13, 2015                [Page 10]
Internet-Draft        Very Fast Setup of GMPLS LSPs         October 2014

   George Clapp
   AT&T Labs Research

   Email: clapp@research.att.com

   Vishnu Shukla
   Verizon Communications

   Email: vishnu.shukla@verizon.com

Malis, et al.            Expires April 13, 2015                [Page 11]