doc: Add RFC documents

1 files changed, 507 insertions, 0 deletions

diff --git a/doc/rfc/rfc7709.txt b/doc/rfc/rfc7709.txt
new file mode 100644
index 0000000..cfe3f69
--- /dev/null
+++ b/doc/rfc/rfc7709.txt
@@ -0,0 +1,507 @@
+
+
+
+
+
+
+Internet Engineering Task Force (IETF)                     A. Malis, Ed.
+Request for Comments: 7709                           Huawei Technologies
+Category: Informational                                        B. Wilson
+ISSN: 2070-1721                           Applied Communication Sciences
+                                                                G. Clapp
+                                                      AT&T Labs Research
+                                                               V. Shukla
+                                                  Verizon Communications
+                                                           November 2015
+
+
+ Requirements for Very Fast Setup of GMPLS Label Switched Paths (LSPs)
+
+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).
+
+Status of This Memo
+
+   This document is not an Internet Standards Track specification; it is
+   published for informational purposes.
+
+   This document is a product of the Internet Engineering Task Force
+   (IETF).  It represents the consensus of the IETF community.  It has
+   received public review and has been approved for publication by the
+   Internet Engineering Steering Group (IESG).  Not all documents
+   approved by the IESG are a candidate for any level of Internet
+   Standard; see Section 2 of RFC 5741.
+
+   Information about the current status of this document, any errata,
+   and how to provide feedback on it may be obtained at
+   http://www.rfc-editor.org/info/rfc7709.
+
+
+
+
+
+
+
+
+
+Malis, et al.                 Informational                     [Page 1]
+
+RFC 7709              Very Fast Setup of GMPLS LSPs        November 2015
+
+
+Copyright Notice
+
+   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) 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  . . . . . . . . . . . . . . . . . . . . . . . .   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
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Malis, et al.                 Informational                     [Page 2]
+
+RFC 7709              Very Fast Setup of GMPLS LSPs        November 2015
+
+
+1.  Introduction
+
+   Generalized Multi-Protocol Label Switching (GMPLS) [RFC3471]
+   [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 it 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 setup 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 that may be novel with
+   respect to current GMPLS protocols.
+
+   This document presents the objectives and related requirements for
+   GMPLS to provide the control for networks operating with such
+   performance requirements.  While specific deployment scenarios are
+   considered 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.
+
+   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.
+
+
+
+Malis, et al.                 Informational                     [Page 3]
+
+RFC 7709              Very Fast Setup of GMPLS LSPs        November 2015
+
+
+   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 set up 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 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 that are 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, and other network design parameters.  Of course, the
+   benefits of low setup delay diminish for connections with long
+   holding times.  For some specific applications, a trade-off may be
+   required, as the need for rapid setup may be more important than
+   their requirements for other features currently provided in GMPLS
+   (e.g., robustness against setup errors).
+
+
+
+
+
+
+Malis, et al.                 Informational                     [Page 4]
+
+RFC 7709              Very Fast Setup of GMPLS LSPs        November 2015
+
+
+   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 document:
+
+   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 meet this target, assuming pipelined cross-
+       connection and worst-case propagation delay and hop count, it is
+
+
+
+Malis, et al.                 Informational                     [Page 5]
+
+RFC 7709              Very Fast Setup of GMPLS LSPs        November 2015
+
+
+       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 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 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 have implications
+   on implementations, 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.
+
+
+
+Malis, et al.                 Informational                     [Page 6]
+
+RFC 7709              Very Fast Setup of GMPLS LSPs        November 2015
+
+
+   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
+
+   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, as 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.
+
+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>.
+
+
+
+Malis, et al.                 Informational                     [Page 7]
+
+RFC 7709              Very Fast Setup of GMPLS LSPs        November 2015
+
+
+   [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>.
+
+
+
+
+
+
+
+
+
+
+Malis, et al.                 Informational                     [Page 8]
+
+RFC 7709              Very Fast Setup of GMPLS LSPs        November 2015
+
+
+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
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Malis, et al.                 Informational                     [Page 9]
+