<?xml version="1.0" ?>
<!-- This template is for creating an Internet Draft using xml2rfc,
     which is available here: http://xml.resource.org. -->
<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [
<!-- One method to get references from the online citation libraries.
     There has to be one entity for each item to be referenced.
     An alternate method (rfc include) is described in the references. -->

<!ENTITY RFC6163 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.6163.xml">
<!ENTITY RFC5814 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.5814.xml">
<!ENTITY RFC6777 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.6777.xml">
<!ENTITY RFC5441 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.5441.xml">
<!ENTITY I-D.narten-iana-considerations-rfc2434bis SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.narten-iana-considerations-rfc2434bis.xml">
]>
<?xml-stylesheet type='text/xsl' href='rfc2629.xslt' ?>
<!-- used by XSLT processors -->
<!-- For a complete list and description of processing instructions (PIs),
     please see http://xml.resource.org/authoring/README.html. -->
<!-- Below are generally applicable Processing Instructions (PIs) that most I-Ds might want to use.
     (Here they are set differently than their defaults in xml2rfc v1.32) -->
<?rfc strict="yes" ?>
<!-- give errors regarding ID-nits and DTD validation -->
<!-- control the table of contents (ToC) -->
<?rfc toc="yes"?>
<!-- generate a ToC -->
<?rfc tocdepth="4"?>
<!-- the number of levels of subsections in ToC. default: 3 -->
<!-- control references -->
<?rfc symrefs="yes"?>
<!-- use symbolic references tags, i.e, [RFC2119] instead of [1] -->
<?rfc sortrefs="yes" ?>
<!-- sort the reference entries alphabetically -->
<!-- control vertical white space
     (using these PIs as follows is recommended by the RFC Editor) -->
<?rfc compact="yes" ?>
<!-- do not start each main section on a new page -->
<?rfc subcompact="no" ?>
<!-- keep one blank line between list items -->
<!-- end of list of popular I-D processing instructions -->
<rfc category="info" docName="draft-malis-ccamp-fast-lsps-00" ipr="trust200902">
  <!-- category values: std, bcp, info, exp, and historic
     ipr values: full3667, noModification3667, noDerivatives3667
     you can add the attributes updates="NNNN" and obsoletes="NNNN"
     they will automatically be output with "(if approved)" -->

  <!-- ***** FRONT MATTER ***** -->

  <front>
    <!-- The abbreviated title is used in the page header - it is only necessary if the
         full title is longer than 39 characters -->

    <title abbrev="Very Fast Setup of GMPLS LSPs">Requirements for Very Fast Setup of GMPLS LSPs</title>

    <!-- add 'role="editor"' below for the editors if appropriate -->

    <!-- Another author who claims to be an editor -->

    <author fullname="Andrew G. Malis" initials="A.G." role="editor"
            surname="Malis">
      <organization>Huawei Technologies</organization>

      <address>
        <postal>
          <street></street>

          <!-- Reorder these if your country does things differently -->

          <city></city>

          <region></region>

          <code></code>

          <country></country>
        </postal>

        <phone></phone>

        <email>agmalis@gmail.com</email>

        <!-- uri and facsimile elements may also be added -->
      </address>
    </author>

    <author fullname="Ronald A. Skoog" initials="R.A."
            surname="Skoog">
      <organization>Applied Communication Sciences</organization>

      <address>
        <postal>
          <street></street>

          <!-- Reorder these if your country does things differently -->

          <city></city>

          <region></region>

          <code></code>

          <country></country>
        </postal>

        <phone></phone>

        <email>rskoog@appcomsci.com</email>

        <!-- uri and facsimile elements may also be added -->
      </address>
    </author>

    <author fullname="Haim Kobrinski" initials="H."
            surname="Kobrinski">
      <organization>Applied Communication Sciences</organization>

      <address>
        <postal>
          <street></street>

          <!-- Reorder these if your country does things differently -->

          <city></city>

          <region></region>

          <code></code>

          <country></country>
        </postal>

        <phone></phone>

        <email>hkobrinski@appcomsci.com</email>

        <!-- uri and facsimile elements may also be added -->
      </address>
    </author>

    <author fullname="George Clapp" initials="G."
            surname="Clapp">
      <organization>AT&amp;T Labs Research</organization>

      <address>
        <postal>
          <street></street>

          <!-- Reorder these if your country does things differently -->

          <city></city>

          <region></region>

          <code></code>

          <country></country>
        </postal>

        <phone></phone>

        <email>clapp@research.att.com</email>

        <!-- uri and facsimile elements may also be added -->
      </address>
    </author>

    <author fullname="Vishnu Shukla" initials="V."
            surname="Shukla">
      <organization>Verizon Communications</organization>

      <address>
        <postal>
          <street></street>

          <!-- Reorder these if your country does things differently -->

          <city></city>

          <region></region>

          <code></code>

          <country></country>
        </postal>

        <phone></phone>

        <email>vishnu.shukla@verizon.com</email>

        <!-- uri and facsimile elements may also be added -->
      </address>
    </author>

    <date month="January" year="2014" />

    <!-- If the month and year are both specified and are the current ones, xml2rfc will fill
         in the current day for you. If only the current year is specified, xml2rfc will fill
	 in the current day and month for you. If the year is not the current one, it is
	 necessary to specify at least a month (xml2rfc assumes day="1" if not specified for the
	 purpose of calculating the expiry date).  With drafts it is normally sufficient to
	 specify just the year. -->

    <!-- Meta-data Declarations -->

    <area>General</area>

    <workgroup>Internet Engineering Task Force (IETF)</workgroup>

    <!-- WG name at the upperleft corner of the doc,
         IETF is fine for individual submissions.
	 If this element is not present, the default is "Network Working Group",
         which is used by the RFC Editor as a nod to the history of the IETF. -->

    <keyword>template</keyword>

    <!-- Keywords will be incorporated into HTML output
         files in a meta tag but they have no effect on text or nroff
         output. If you submit your draft to the RFC Editor, the
         keywords will be used for the search engine. -->

    <abstract>
<t>The Defense Advanced Research Projects Agency (DARPA) Core Optical Networks (CORONET) program has laid out a vision for the next evolution of 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 one second to one minute holding times) 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 and wavelength-km.</t>

<t>This document discusses the requirements for extensions to Generalized Multi-Protocol Label Switching (GMPLS) signaling for expediting the control of Label Switched Paths (LSPs), including sub-wavelengths (e.g., OTN ODUs) and full wavelengths, in order to satisfy application requirements laid out in this program.</t>
    </abstract>
  </front>

  <middle>
    <section title="Introduction">
<t>The Defense Advanced Research Projects Agency (DARPA) Core Optical Networks (CORONET) program <xref target="Chiu" /> has laid out a vision for the next evolution of IP and optical commercial and government networks, with a focus on highly dynamic and resilient multi-terabit core networks. The program anticipates an environment where 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 are two to three orders of magnitude faster than possible with current connection setup protocols. 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. It is the desired goal of the program to achieve transition of these advances to commercial and government networks in the next few years.  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).</t>

<t> Thus, CORONET anticipates the need for rapid (sub-second) setup and restoration times for high-churn (up to tens of requests per second network-wide and one second to one minute holding times) 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 and wavelength-km.</t>

<t>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.</t>

<t>However, while the current GMPLS constituent 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 low connection setup times while maintaining a high success ratio (i.e., low blocking) in a high-churn environment. For  example, in Internet2, a network which provides CORONET-like high bandwidth circuit services for the Research &amp; Education community, a circuit is currently established, on average, roughly at a rate of one per hour. In contrast, the CORONET vision is a churn rate of up to tens of circuits per second, over four orders of magnitude greater.</t>

<t>Furthermore, 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. The purpose of this draft is to determine the requirements to augment the GMPLS framework to allow specific applications, or users, to rapidly set up connections over GMPLS networks with minimal delays and a high probability of success. </t>
    </section>

    <section title="Scope and Motivation">
<t><xref target="RFC6163" /> provides the framework, basic elements, and terminology of wavelength switched optical networks (WSON) and wavelength-based LSPs. These basic elements generally apply to other GMPLS technologies as well, e.g., spectral switching (SSON), sub-wavelength TDM, and L2 LSPs. This draft refers to the same general framework and technologies, but addresses an extension of the general problem space addressed in <xref target="RFC6163" />. Specifically, this draft addresses the requirements of expediting LSP setup, under heavy connection churn scenarios, while achieving low blocking, under an overall distributed control plane. Once there is agreement on the requirements, further drafts will describe the procedures and signaling contents required to meet the requirements (potentially more than one if separate standard track drafts are found necessary for wavelength and sub-wavelength LSPs). Both single-domain and multi-domain network scenarios are addressed. 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 <xref target="RFC5814" /> and <xref target="RFC6777" />, which do not include PCE path computation delays.</t>

<t>The motivation for GMPLS extensions as described here is the anticipated need for rapid setup while maintaining low blocking, on-demand, of large bandwidth 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. The ability to setup circuit-like LSPs for large bandwidth flows and 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 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.</t>

<t>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. </t>

<t>The need for rapid setup for specific applications may override and thus get traded off against some other features currently provided in GMPLS, e.g., robustness against setup errors.</t>

<t>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 maximum frequency of TE information updates is not sufficient to provide adequate path computation and resource allocation, as network conditions and resource attributes may be changing faster than can be reflected in OSPF-TE updates.</t>

<t>Thus, GMPLS and routing protocol traffic engineering (e.g. OSPF-TE) extensions are also 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.</t>
     </section>

    <section anchor="Requirements" title="Requirements for Very Fast Setup of GMPLS LSPs">
<t>This section lists the requirements for very fast setup of GMPLS LSPs in order to provide the services described in the previous sections. They will be the basis for future standards-track drafts to satisfy these requirements. Some of these requirements may be implementation-dependent to some extent, but they may also have LSP signaling protocol dependencies as well.</t>

<t><list counter="reqs" hangIndent="4" style="format R%d">
<t>Protocol extensions must be backward compatible with existing GMPLS control plane protocols.</t>

<t>Use of GMPLS protocol extensions for this application must be selectable by provisioning or configuration.</t>

<t>Must support the use of PCE for path computation, and in particular the PCE-based approach for multi-domain LSPs in <xref target="RFC5441" />.</t>

<t>Must have an LSP setup time less than or equal to 100 ms for intra-continental LSPs, and less than or equal to 250 ms for transcontinental LSPs, including PCE path computation delays.</t>

<t>Must support LSP holding times of one second to one minute.</t>

<t>While there are implementation-dependent aspects of supporting high LSP setup rates, the protocol aspects of LSP signaling must not preclude LSP request rates of tens per second. A possible example of a protocol aspect is the ability to update the IGP TE database to accurately reflect resource availability at all times. Note that LSP request rates may be dependent on LSP bandwidth, where very high bandwidth LSPs (such as for an entire wavelength) could be less frequent than lower-rate LSPs (such as an ODUx connection).</t>

<t>Must support restoration for all cases of single node or link failures.</t>

<t>At most one blocked LSP setup request per 1000 requests.</t>
</list></t>
    </section>

    <section anchor="IANA" title="IANA Considerations">
      <t>This memo includes no request to IANA.</t>
    </section>

    <section anchor="Security" title="Security Considerations">
      <t>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, and potentially could improve GMPLS' resistance against denial of service attacks that attempt to deny service through the use of a high frequency of GMPLS LSP setup requests.</t>
    </section>
    <section anchor="Acknowledgements" title="Acknowledgements">
      <t>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.</t>
    </section>
  </middle>

  <!--  *****BACK MATTER ***** -->

  <back>
    <!-- References split into informative and normative -->

    <!-- There are 2 ways to insert reference entries from the citation libraries:
     1. define an ENTITY at the top, and use "ampersand character"RFC2629; here (as shown)
     2. simply use a PI "less than character"?rfc include="reference.RFC.2119.xml"?> here
        (for I-Ds: include="reference.I-D.narten-iana-considerations-rfc2434bis.xml")

     Both are cited textually in the same manner: by using xref elements.
     If you use the PI option, xml2rfc will, by default, try to find included files in the same
     directory as the including file. You can also define the XML_LIBRARY environment variable
     with a value containing a set of directories to search.  These can be either in the local
     filing system or remote ones accessed by http (http://domain/dir/... ).-->

    <references title="Normative References">

      &RFC6163;

      &RFC5814;

      &RFC6777;

      &RFC5441;

    </references>

    <references title="Informative References">
      <!-- Here we use entities that we defined at the beginning. -->

      <reference anchor="Chiu" target="http://dx.doi.org/10.1364/JOCN.4.000001">
        <!-- the following is the minimum to make xml2rfc happy -->

        <front>
          <title>Architectures and Protocols for Capacity Efficient, Highly Dynamic and Highly Resilient Core Networks</title>

          <author>
            <organization>A. Chiu, et al</organization>
          </author>

          <date month="January" year="2012" />
        </front>
<seriesInfo name="Journal of Optical Communications and Networking" value="vol. 4, No. 1, pp. 1-14"/>
      </reference>

    </references>

  </back>
</rfc>
