One document matched: draft-ietf-teas-fast-lsps-requirements-02.xml

<?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 RFC3471 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.3471.xml">
<!ENTITY RFC3945 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.3945.xml">
<!ENTITY RFC4655 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.4655.xml">
<!-- <!ENTITY RFC5441 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.5441.xml"> -->
<!ENTITY RFC5814 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.5814.xml">
<!ENTITY RFC6163 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.6163.xml">
<!ENTITY RFC6383 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.6383.xml">
<!ENTITY RFC6777 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.6777.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-ietf-teas-fast-lsps-requirements-02" 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="Brian J. Wilson" initials="B.J."
            surname="Wilson">
      <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>bwilson@appcomsci.com</email>

        <!-- uri and facsimile elements may also be added -->
      </address>
    </author>

    <author fullname="George Clapp" initials="G."
            surname="Clapp">
      <organization>AT&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="October" year="2015" />

    <!-- 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>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. </t>

<t>The goal of this document is to present target scaling objectives and the related protocol requirements for Generalized Multi-Protocol Label Switching (GMPLS).</t>
    </abstract>
  </front>

  <middle>
    <section title="Introduction">
<t>Generalized Multi-Protocol Label Switching (GMPLS) <xref target="RFC3471"/> <xref target="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 <xref target="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 <xref target="RFC6163"/>.</t>

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

<t>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.</t>

<t>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 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.   </t>

<t>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.</t>
</section>

    <section title="Background">
<t>The Defense Advanced Research Projects Agency (DARPA) Core Optical Networks (CORONET) program <xref target="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.
</t>

</section>

    <section title="Motivation">

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

<list style="numbers">
<t>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.</t>
<t>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.</t>
</list>
</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, 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.
</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 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.</t>
     </section>
    <section title="Driving Applications and Their Requirements">
<t>
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.
</t>
<t>
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).
</t>
<section title="Key Application Requirements">
<t>
There are two key performance-scaling requirements in the target environment that are the main drivers behind this draft:
<list style="numbers">
<t>
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).
</t>
<t>
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 <xref target="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.
</t>
</list> </t>
<t>
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.
</t>
<t>
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>
     </section>
     </section>

    <section anchor="Requirements" title="Requirements for Very Fast Setup of GMPLS LSPs">
<t>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.
</t>


<section anchor="ControlPlaneRequirements" title="Protocol and Procedure Requirements">
<t><list counter="reqs" hangIndent="4" style="format R%d">
<t>
The protocol processing related portion of the LSP establishment time should scale linearly based on number of traversed nodes.
</t>
<t>
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 <xref target="RFC6383"/> should be enabled.
</t>
<t>
LSP Establishment time shall depend on the 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.
</t>
<t>
Must support LSP holding times as short as one second.
</t>
<t>
The protocol aspects of LSP signaling must not preclude LSP request rates of tens per second.
</t>
<t>
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.
</t>
<t>
These requirements are applicable even when an LSP crosses one or more administrative domains/boundaries.
</t>
<t>
The above are additional requirements and do not replace existing requirements, e.g., alarm free setup and teardown, Recovery, or inter-domain confidentiality.
</t>
</list>
</t>

    </section>
    </section>

    <section anchor="IANA" title="IANA Considerations">
      <t>This memo includes no requests 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. 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.
</t>
    </section>
    <section anchor="Acknowledgements" title="Acknowledgements">
      <t>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.
</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">

      &RFC3471;

      &RFC3945;

      &RFC4655;

<!--      &RFC5441; -->

      &RFC5814;

      &RFC6163;

      &RFC6383;

      &RFC6777;

    </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>

<!--  Note: this reference is no longer used in the text.
<reference anchor="Skoog" target="http://www.opticsinfobase.org/abstract.cfm?URI=OFC-2014-W1K.1">

        <front>
          <title>Analysis and Implementation of a 3-Way Handshake Signaling Protocol for Highly Dynamic Transport Networks</title>

          <author>
            <organization>R. Skoog, et al</organization>
          </author>

          <date />
        </front>
<seriesInfo name="" value="OFC 2014"/>
</reference> -->

      <reference anchor="Lehmen" target="http://www.osapublishing.org/jocn/abstract.cfm?uri=jocn-7-3-A447">
        <!-- the following is the minimum to make xml2rfc happy -->

        <front>
          <title>CORONET: Testbeds, Demonstration and Lessons Learned</title>

          <author>
            <organization>A. Von Lehmen, et al</organization>
          </author>

          <date month="March" year="2015" />
        </front>
<seriesInfo name="Journal of Optical Communications and Networking" value="Vol. 7, Issue 3, pp. A447-A458"/>
      </reference>
    </references>

  </back>
</rfc>