< draft-malis-ccamp-fast-lsps-03.txt   draft-malis-ccamp-fast-lsps-04.txt >
Internet Engineering Task Force (IETF) A. Malis, Ed. Internet Engineering Task Force (IETF) A. Malis, Ed.
Internet-Draft Huawei Technologies Internet-Draft Huawei Technologies
Intended status: Informational R. Skoog Intended status: Informational R. Skoog
Expires: April 13, 2015 H. Kobrinski Expires: May 24, 2015 H. Kobrinski
Applied Communication Sciences Applied Communication Sciences
G. Clapp G. Clapp
AT&T Labs Research AT&T Labs Research
V. Shukla V. Shukla
Verizon Communications Verizon Communications
October 10, 2014 November 20, 2014
Requirements for Very Fast Setup of GMPLS LSPs Requirements for Very Fast Setup of GMPLS LSPs
draft-malis-ccamp-fast-lsps-03 draft-malis-ccamp-fast-lsps-04
Abstract Abstract
Establishment and control of Label Switch Paths (LSPs) have become Establishment and control of Label Switch Paths (LSPs) have become
mainstream tools of commercial and government network providers. One mainstream tools of commercial and government network providers. One
of the elements of further evolving such networks is scaling their of the elements of further evolving such networks is scaling their
performance in terms of LSP bandwidth and traffic loads, LSP performance in terms of LSP bandwidth and traffic loads, LSP
intensity (e.g., rate of LSP creation, deletion, and modification), intensity (e.g., rate of LSP creation, deletion, and modification),
LSP set up delay, quality of service differentiation, and different LSP set up delay, quality of service differentiation, and different
levels of resilience. levels of resilience.
The goal of this document is to present target scaling objectives and The goal of this document is to present target scaling objectives and
the related protocol requirements for Generalized Multi-Protocol the related protocol requirements for Generalized Multi-Protocol
Label Switching (GMPLS). The document also summarizes key factors Label Switching (GMPLS).
affecting current GMPLS signaling procedures in meeting these
application scaling requirements.
Status of This Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on April 13, 2015. This Internet-Draft will expire on May 24, 2015.
Copyright Notice Copyright Notice
Copyright (c) 2014 IETF Trust and the persons identified as the Copyright (c) 2014 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
skipping to change at page 2, line 27 skipping to change at page 2, line 27
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Background . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Background . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Motivation . . . . . . . . . . . . . . . . . . . . . . . . . 4 3. Motivation . . . . . . . . . . . . . . . . . . . . . . . . . 4
4. Driving Applications and Their Requirements . . . . . . . . . 5 4. Driving Applications and Their Requirements . . . . . . . . . 5
4.1. Key Application Requirements . . . . . . . . . . . . . . 5 4.1. Key Application Requirements . . . . . . . . . . . . . . 5
5. Potential GMPLS Limitations . . . . . . . . . . . . . . . . . 6 5. Requirements for Very Fast Setup of GMPLS LSPs . . . . . . . 6
6. Requirements for Very Fast Setup of GMPLS LSPs . . . . . . . 8 5.1. Protocol and Procedure Requirements . . . . . . . . . . . 6
6.1. Protocol and Procedure Requirements . . . . . . . . . . . 8 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 7. Security Considerations . . . . . . . . . . . . . . . . . . . 7
8. Security Considerations . . . . . . . . . . . . . . . . . . . 9 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 7
9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 9 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 7
10. References . . . . . . . . . . . . . . . . . . . . . . . . . 9 9.1. Normative References . . . . . . . . . . . . . . . . . . 7
10.1. Normative References . . . . . . . . . . . . . . . . . . 9 9.2. Informative References . . . . . . . . . . . . . . . . . 8
10.2. Informative References . . . . . . . . . . . . . . . . . 10 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 8
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 10
1. Introduction 1. Introduction
Generalized Multi-Protocol Label Switching (GMPLS) [RFC3945] includes Generalized Multi-Protocol Label Switching (GMPLS) [RFC3471]
an architecture and a set of control plane protocols that can be used [RFC3945] includes an architecture and a set of control plane
to operate data networks ranging from packet-switch-capable networks, protocols that can be used to operate data networks ranging from
through those networks that use Time Division Multiplexing, to WDM packet-switch-capable networks, through those networks that use Time
networks. The Path Computation Element (PCE) architecture [RFC4655] Division Multiplexing, to WDM networks. The Path Computation Element
defines functional components that can be used to compute and suggest (PCE) architecture [RFC4655] defines functional components that can
appropriate paths in connection-oriented traffic-engineered networks. be used to compute and suggest appropriate paths in connection-
Additional wavelength switched optical networks (WSON) considerations oriented traffic-engineered networks. Additional wavelength switched
were defined in [RFC6163]. optical networks (WSON) considerations were defined in [RFC6163].
This document refers to the same general framework and technologies, This document refers to the same general framework and technologies,
but adds requirements related to expediting LSP setup, under heavy but adds requirements related to expediting LSP setup, under heavy
connection churn scenarios, while achieving low blocking, under an connection churn scenarios, while achieving low blocking, under an
overall distributed control plane. This document focuses on a overall distributed control plane. This document focuses on a
specific problem space - high capacity and highly dynamic connection specific problem space - high capacity and highly dynamic connection
request scenarios - that may require clarification and or extensions request scenarios - that may require clarification and or extensions
to current GMPLS protocols and procedures. In particular, the to current GMPLS protocols and procedures. In particular, the
purpose of this document is to address the potential need for purpose of this document is to address the potential need for
protocols and procedures that enable expediting the set up of LSPs in protocols and procedures that enable expediting the set up of LSPs in
skipping to change at page 4, line 34 skipping to change at page 4, line 34
and virtual circuit switching intrinsically provide guaranteed and virtual circuit switching intrinsically provide guaranteed
bandwidth, guaranteed low-latency and jitter, and faster bandwidth, guaranteed low-latency and jitter, and faster
restoration, all of which are very hard to provide in a packet- restoration, all of which are very hard to provide in a packet-
only networks. Again, a key element in achieving these benefits only networks. Again, a key element in achieving these benefits
is enabling the fastest possible circuit setup times. is enabling the fastest possible circuit setup times.
Future applications are expected to require setup times as fast as Future applications are expected to require setup times as fast as
100 ms in highly dynamic, national-scale network environments while 100 ms in highly dynamic, national-scale network environments while
meeting stringent blocking requirements and minimizing the use of meeting stringent blocking requirements and minimizing the use of
resources such as switch ports, wavelength converters/regenerators, resources such as switch ports, wavelength converters/regenerators,
wavelength-km, and other network design parameters. Of course, the and other network design parameters. Of course, the benefits of low
benefits of low setup delay diminish for connections with long setup delay diminish for connections with long holding times. The
holding times. The need for rapid setup for specific applications need for rapid setup for specific applications may override and thus
may override and thus get traded off, for these specific get traded off, for these specific applications, against some other
applications, against some other features currently provided in features currently provided in GMPLS, e.g., robustness against setup
GMPLS, e.g., robustness against setup errors. errors.
With the advent of data centers, cloud computing, video, gaming, With the advent of data centers, cloud computing, video, gaming,
mobile and other broadband applications, it is anticipated that mobile and other broadband applications, it is anticipated that
connection request rates may increase, even for connections with connection request rates may increase, even for connections with
longer holding times, either during limited time periods (such as longer holding times, either during limited time periods (such as
during the restoration from a data center failure) or over the longer during the restoration from a data center failure) or over the longer
term, to the point where the current GMPLS procedures of path term, to the point where the current GMPLS procedures of path
computation/selection and resource allocation may not be timely, thus computation/selection and resource allocation may not be timely, thus
leading to increased blocking or increased resource cost. Thus, leading to increased blocking or increased resource cost. Thus,
extensions of GMPLS signaling and routing protocols (e.g. OSPF-TE) extensions of GMPLS signaling and routing protocols (e.g. OSPF-TE)
skipping to change at page 6, line 13 skipping to change at page 6, line 13
up to 100 nodes and LSPs distances up to ~3000 km and up to 15 hops. 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 A connection setup delay is defined here as the time between the
arrival of a connection request at an ingress edge switch - or more arrival of a connection request at an ingress edge switch - or more
generally a Label Switch Router (LSR) - and the time at which generally a Label Switch Router (LSR) - and the time at which
information can start flowing from that ingress switch over that information can start flowing from that ingress switch over that
connection. Note that this definition is more inclusive than the LSP connection. Note that this definition is more inclusive than the LSP
setup time defined in [RFC5814] and [RFC6777], which do not include setup time defined in [RFC5814] and [RFC6777], which do not include
PCE path computation delays. PCE path computation delays.
5. Potential GMPLS Limitations 5. Requirements for Very Fast Setup of GMPLS LSPs
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 This section lists the protocol requirements for very fast setup of
GMPLS LSPs in order to adequately support the service characteristics GMPLS LSPs in order to adequately support the service characteristics
described in the previous sections. These requirements may be the described in the previous sections. These requirements may be the
basis for future documents, some of which may be simply basis for future documents, some of which may be simply
informational, while others may describe specific GMPLS protocol informational, while others may describe specific GMPLS protocol
extensions. While some of these requirements may be have extensions. While some of these requirements may be have
implications on implementations, the intent is for the requirements implications on implementations, the intent is for the requirements
to apply to GMPLS protocols and their standardized mechanisms. to apply to GMPLS protocols and their standardized mechanisms.
6.1. Protocol and Procedure Requirements 5.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 R1 The protocol processing related portion of the LSP establishment
traversed nodes. time should scale linearly based on number of traversed nodes.
R4 LSP Establishment time should be bounded by a single (worst R2 End-to-end LSP data path availability should be bounded by the
case) per-node data path (cross-connect) establishment time and worst case single node data path establishment time. In other
not scale linearly based on number of traversed nodes, i.e., words, pipelined cross-connect processing as discussed in
support parallel or pipelined cross-connection establishment. [RFC6383] should be enabled.
R5 LSP Establishment time shall depend on number of nodes R3 LSP Establishment time shall depend on number of nodes supporting
supporting an LSP and link propagation delays and not any off an LSP and link propagation delays and not any off (control) path
(control) path transactions, e.g., PCC-PCE and PCC-PCC transactions, e.g., PCC-PCE and PCC-PCC communications at the
communications at the time of connection setup, even when PCE- time of connection setup, even when PCE-based approaches are
based approaches are used. used.
R6 Must support LSP holding times as short as one second to one R4 Must support LSP holding times as short as one second.
minute.
R7 The protocol aspects of LSP signaling must not preclude LSP R5 The protocol aspects of LSP signaling must not preclude LSP
request rates of tens per second. request rates of tens per second.
R8 The above requirements should be met even when there are R6 The above requirements should be met even when there are failures
failures in connection establishment, i.e., LSPs should be in connection establishment, i.e., LSPs should be established
established faster than when crank-back is used. faster than when crank-back is used.
R9 These requirements are applicable even when an LSP crosses one R7 These requirements are applicable even when an LSP crosses one or
or more administrative domains / boundaries. more administrative domains/boundaries.
R10 The above are additional requirements and do not replace R8 The above are additional requirements and do not replace existing
existing requirements, e.g. alarm free setup and teardown, requirements, e.g. alarm free setup and teardown, Recovery, or
Recovery, or inter-domain confidentiality. inter-domain confidentiality.
7. IANA Considerations 6. IANA Considerations
This memo includes no requests to IANA. This memo includes no requests to IANA.
8. Security Considerations 7. Security Considerations
Being able to support very fast setup and a high churn rate of GMPLS Being able to support very fast setup and a high churn rate of GMPLS
LSPs is not expected to adversely affect the underlying security LSPs is not expected to adversely affect the underlying security
issues associated with existing GMPLS signaling. issues associated with existing GMPLS signaling.
9. Acknowledgements 8. Acknowledgements
The authors would like to thank Ann Von Lehmen, Joe Gannett, and The authors would like to thank Ann Von Lehmen, Joe Gannett, and
Brian Wilson of Applied Communication Sciences for their comments and Brian Wilson of Applied Communication Sciences for their comments and
assistance on this document. Lou Berger provided editorial comments assistance on this document. Lou Berger provided editorial comments
on this document. on this document.
10. References 9. References
10.1. Normative References 9.1. Normative References
[RFC3471] Berger, L., "Generalized Multi-Protocol Label Switching [RFC3471] Berger, L., "Generalized Multi-Protocol Label Switching
(GMPLS) Signaling Functional Description", RFC 3471, (GMPLS) Signaling Functional Description", RFC 3471,
January 2003. January 2003.
[RFC3945] Mannie, E., "Generalized Multi-Protocol Label Switching [RFC3945] Mannie, E., "Generalized Multi-Protocol Label Switching
(GMPLS) Architecture", RFC 3945, October 2004. (GMPLS) Architecture", RFC 3945, October 2004.
[RFC4655] Farrel, A., Vasseur, J., and J. Ash, "A Path Computation [RFC4655] Farrel, A., Vasseur, J., and J. Ash, "A Path Computation
Element (PCE)-Based Architecture", RFC 4655, August 2006. Element (PCE)-Based Architecture", RFC 4655, August 2006.
[RFC5814] Sun, W. and G. Zhang, "Label Switched Path (LSP) Dynamic [RFC5814] Sun, W. and G. Zhang, "Label Switched Path (LSP) Dynamic
Provisioning Performance Metrics in Generalized MPLS Provisioning Performance Metrics in Generalized MPLS
Networks", RFC 5814, March 2010. Networks", RFC 5814, March 2010.
[RFC6163] Lee, Y., Bernstein, G., and W. Imajuku, "Framework for [RFC6163] Lee, Y., Bernstein, G., and W. Imajuku, "Framework for
GMPLS and Path Computation Element (PCE) Control of GMPLS and Path Computation Element (PCE) Control of
Wavelength Switched Optical Networks (WSONs)", RFC 6163, Wavelength Switched Optical Networks (WSONs)", RFC 6163,
April 2011. April 2011.
[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, September 2011.
[RFC6777] Sun, W., Zhang, G., Gao, J., Xie, G., and R. Papneja, [RFC6777] Sun, W., Zhang, G., Gao, J., Xie, G., and R. Papneja,
"Label Switched Path (LSP) Data Path Delay Metrics in "Label Switched Path (LSP) Data Path Delay Metrics in
Generalized MPLS and MPLS Traffic Engineering (MPLS-TE) Generalized MPLS and MPLS Traffic Engineering (MPLS-TE)
Networks", RFC 6777, November 2012. Networks", RFC 6777, November 2012.
10.2. Informative References 9.2. Informative References
[Chiu] A. Chiu, et al, "Architectures and Protocols for Capacity [Chiu] A. Chiu, et al, "Architectures and Protocols for Capacity
Efficient, Highly Dynamic and Highly Resilient Core Efficient, Highly Dynamic and Highly Resilient Core
Networks", Journal of Optical Communications and Networks", Journal of Optical Communications and
Networking vol. 4, No. 1, pp. 1-14, January 2012, Networking vol. 4, No. 1, pp. 1-14, January 2012,
<http://dx.doi.org/10.1364/JOCN.4.000001>. <http://dx.doi.org/10.1364/JOCN.4.000001>.
[Lehmen] A. Von Lehmen, et al, "CORONET: Testbeds, Demonstration [Lehmen] A. Von Lehmen, et al, "CORONET: Testbeds, Demonstration
and Lessons Learned", Journal of Optical Communications and Lessons Learned", Journal of Optical Communications
and Networking vol. 7, No. 1, January 2015 (expected). 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 Authors' Addresses
Andrew G. Malis (editor) Andrew G. Malis (editor)
Huawei Technologies Huawei Technologies
Email: agmalis@gmail.com Email: agmalis@gmail.com
Ronald A. Skoog Ronald A. Skoog
Applied Communication Sciences Applied Communication Sciences
 End of changes. 26 change blocks. 
168 lines changed or deleted 63 lines changed or added

This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/