<pre>Internet Engineering Task Force (IETF)                       W. Sun, Ed.
Request for Comments: 5814                                          SJTU
Category: Standards Track                                  G. Zhang, Ed.
ISSN: 2070-1721                                                     CATR
                                                              March 2010


   <span class="h1">Label Switched Path (LSP) Dynamic Provisioning Performance Metrics</span>
                      <span class="h1">in Generalized MPLS Networks</span>

Abstract

   Generalized Multi-Protocol Label Switching (GMPLS) is one of the most
   promising candidate technologies for a future data transmission
   network.  GMPLS has been developed to control and operate different
   kinds of network elements, such as conventional routers, switches,
   Dense Wavelength Division Multiplexing (DWDM) systems, Add-Drop
   Multiplexers (ADMs), photonic cross-connects (PXCs), optical cross-
   connects (OXCs), etc.  These physically diverse devices differ
   drastically from one another in dynamic provisioning ability.  At the
   same time, the need for dynamically provisioned connections is
   increasing because optical networks are being deployed in metro
   areas.  As different applications have varied requirements in the
   provisioning performance of optical networks, it is imperative to
   define standardized metrics and procedures such that the performance
   of networks and application needs can be mapped to each other.

   This document provides a series of performance metrics to evaluate
   the dynamic Label Switched Path (LSP) provisioning performance in
   GMPLS networks, specifically the dynamic LSP setup/release
   performance.  These metrics can be used to characterize the features
   of GMPLS networks in LSP dynamic provisioning.

Status of This Memo

   This is an Internet Standards Track document.

   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).  Further information on
   Internet Standards is available in <a href="./rfc5741#section-2">Section&nbsp;2 of RFC 5741</a>.

   Information about the current status of this document, any errata,
   and how to provide feedback on it may be obtained at
   <a href="http://www.rfc-editor.org/info/rfc5814">http://www.rfc-editor.org/info/rfc5814</a>.





<span class="grey">Sun &amp; Zhang                  Standards Track                    [Page 1]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-2" ></span>
<span class="grey"><a href="./rfc5814">RFC 5814</a>            LSP Dynamic PPM in GMPLS Networks         March 2010</span>


Copyright Notice

   Copyright (c) 2010 IETF Trust and the persons identified as the
   document authors.  All rights reserved.

   This document is subject to <a href="https://www.rfc-editor.org/bcp/bcp78">BCP 78</a> and the IETF Trust's Legal
   Provisions Relating to IETF Documents
   (<a href="http://trustee.ietf.org/license-info">http://trustee.ietf.org/license-info</a>) 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.

   This document may contain material from IETF Documents or IETF
   Contributions published or made publicly available before November
   10, 2008.  The person(s) controlling the copyright in some of this
   material may not have granted the IETF Trust the right to allow
   modifications of such material outside the IETF Standards Process.
   Without obtaining an adequate license from the person(s) controlling
   the copyright in such materials, this document may not be modified
   outside the IETF Standards Process, and derivative works of it may
   not be created outside the IETF Standards Process, except to format
   it for publication as an RFC or to translate it into languages other
   than English.

























<span class="grey">Sun &amp; Zhang                  Standards Track                    [Page 2]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-3" ></span>
<span class="grey"><a href="./rfc5814">RFC 5814</a>            LSP Dynamic PPM in GMPLS Networks         March 2010</span>


Table of Contents

   <a href="#section-1">1</a>. Introduction ....................................................<a href="#page-6">6</a>
   <a href="#section-2">2</a>. Conventions Used in This Document ...............................<a href="#page-6">6</a>
   <a href="#section-3">3</a>. Overview of Performance Metrics .................................<a href="#page-6">6</a>
   4. A Singleton Definition for Single Unidirectional LSP
      Setup Delay .....................................................<a href="#page-7">7</a>
      <a href="#section-4.1">4.1</a>. Motivation .................................................<a href="#page-7">7</a>
      <a href="#section-4.2">4.2</a>. Metric Name ................................................<a href="#page-7">7</a>
      <a href="#section-4.3">4.3</a>. Metric Parameters ..........................................<a href="#page-8">8</a>
      <a href="#section-4.4">4.4</a>. Metric Units ...............................................<a href="#page-8">8</a>
      <a href="#section-4.5">4.5</a>. Definition .................................................<a href="#page-8">8</a>
      <a href="#section-4.6">4.6</a>. Discussion .................................................<a href="#page-8">8</a>
      <a href="#section-4.7">4.7</a>. Methodologies ..............................................<a href="#page-9">9</a>
      <a href="#section-4.8">4.8</a>. Metric Reporting ...........................................<a href="#page-9">9</a>
   5. A Singleton Definition for Multiple Unidirectional LSPs
      Setup Delay ....................................................<a href="#page-10">10</a>
      <a href="#section-5.1">5.1</a>. Motivation ................................................<a href="#page-10">10</a>
      <a href="#section-5.2">5.2</a>. Metric Name ...............................................<a href="#page-10">10</a>
      <a href="#section-5.3">5.3</a>. Metric Parameters .........................................<a href="#page-10">10</a>
      <a href="#section-5.4">5.4</a>. Metric Units ..............................................<a href="#page-10">10</a>
      <a href="#section-5.5">5.5</a>. Definition ................................................<a href="#page-11">11</a>
      <a href="#section-5.6">5.6</a>. Discussion ................................................<a href="#page-11">11</a>
      <a href="#section-5.7">5.7</a>. Methodologies .............................................<a href="#page-12">12</a>
      <a href="#section-5.8">5.8</a>. Metric Reporting ..........................................<a href="#page-13">13</a>
   6. A Singleton Definition for Single Bidirectional LSP
      Setup Delay ....................................................<a href="#page-13">13</a>
      <a href="#section-6.1">6.1</a>. Motivation ................................................<a href="#page-13">13</a>
      <a href="#section-6.2">6.2</a>. Metric Name ...............................................<a href="#page-14">14</a>
      <a href="#section-6.3">6.3</a>. Metric Parameters .........................................<a href="#page-14">14</a>
      <a href="#section-6.4">6.4</a>. Metric Units ..............................................<a href="#page-14">14</a>
      <a href="#section-6.5">6.5</a>. Definition ................................................<a href="#page-14">14</a>
      <a href="#section-6.6">6.6</a>. Discussion ................................................<a href="#page-15">15</a>
      <a href="#section-6.7">6.7</a>. Methodologies .............................................<a href="#page-15">15</a>
      <a href="#section-6.8">6.8</a>. Metric Reporting ..........................................<a href="#page-16">16</a>
   7. A Singleton Definition for Multiple Bidirectional LSPs
      Setup Delay ....................................................<a href="#page-16">16</a>
      <a href="#section-7.1">7.1</a>. Motivation ................................................<a href="#page-16">16</a>
      <a href="#section-7.2">7.2</a>. Metric Name ...............................................<a href="#page-16">16</a>
      <a href="#section-7.3">7.3</a>. Metric Parameters .........................................<a href="#page-17">17</a>
      <a href="#section-7.4">7.4</a>. Metric Units ..............................................<a href="#page-17">17</a>
      <a href="#section-7.5">7.5</a>. Definition ................................................<a href="#page-17">17</a>
      <a href="#section-7.6">7.6</a>. Discussion ................................................<a href="#page-18">18</a>
      <a href="#section-7.7">7.7</a>. Methodologies .............................................<a href="#page-19">19</a>
      <a href="#section-7.8">7.8</a>. Metric Reporting ..........................................<a href="#page-19">19</a>
   <a href="#section-8">8</a>. A Singleton Definition for LSP Graceful Release Delay ..........<a href="#page-20">20</a>
      <a href="#section-8.1">8.1</a>. Motivation ................................................<a href="#page-20">20</a>
      <a href="#section-8.2">8.2</a>. Metric Name ...............................................<a href="#page-20">20</a>



<span class="grey">Sun &amp; Zhang                  Standards Track                    [Page 3]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-4" ></span>
<span class="grey"><a href="./rfc5814">RFC 5814</a>            LSP Dynamic PPM in GMPLS Networks         March 2010</span>


      <a href="#section-8.3">8.3</a>. Metric Parameters .........................................<a href="#page-20">20</a>
      <a href="#section-8.4">8.4</a>. Metric Units ..............................................<a href="#page-20">20</a>
      <a href="#section-8.5">8.5</a>. Definition ................................................<a href="#page-20">20</a>
      <a href="#section-8.6">8.6</a>. Discussion ................................................<a href="#page-22">22</a>
      <a href="#section-8.7">8.7</a>. Methodologies .............................................<a href="#page-22">22</a>
      <a href="#section-8.8">8.8</a>. Metric Reporting ..........................................<a href="#page-23">23</a>
   9. A Definition for Samples of Single Unidirectional LSP
      Setup Delay ....................................................<a href="#page-24">24</a>
      <a href="#section-9.1">9.1</a>. Metric Name ...............................................<a href="#page-24">24</a>
      <a href="#section-9.2">9.2</a>. Metric Parameters .........................................<a href="#page-24">24</a>
      <a href="#section-9.3">9.3</a>. Metric Units ..............................................<a href="#page-24">24</a>
      <a href="#section-9.4">9.4</a>. Definition ................................................<a href="#page-24">24</a>
      <a href="#section-9.5">9.5</a>. Discussion ................................................<a href="#page-25">25</a>
      <a href="#section-9.6">9.6</a>. Methodologies .............................................<a href="#page-25">25</a>
      <a href="#section-9.7">9.7</a>. Typical Testing Cases .....................................<a href="#page-26">26</a>
           <a href="#section-9.7.1">9.7.1</a>. With No LSP in the Network .........................<a href="#page-26">26</a>
           <a href="#section-9.7.2">9.7.2</a>. With a Number of LSPs in the Network ...............<a href="#page-26">26</a>
      <a href="#section-9.8">9.8</a>. Metric Reporting ..........................................<a href="#page-26">26</a>
   10. A Definition for Samples of Multiple Unidirectional
       LSPs Setup Delay ..............................................<a href="#page-26">26</a>
      <a href="#section-10.1">10.1</a>. Metric Name ..............................................<a href="#page-27">27</a>
      <a href="#section-10.2">10.2</a>. Metric Parameters ........................................<a href="#page-27">27</a>
      <a href="#section-10.3">10.3</a>. Metric Units .............................................<a href="#page-27">27</a>
      <a href="#section-10.4">10.4</a>. Definition ...............................................<a href="#page-27">27</a>
      <a href="#section-10.5">10.5</a>. Discussion ...............................................<a href="#page-28">28</a>
      <a href="#section-10.6">10.6</a>. Methodologies ............................................<a href="#page-28">28</a>
      <a href="#section-10.7">10.7</a>. Typical Testing Cases ....................................<a href="#page-29">29</a>
           <a href="#section-10.7.1">10.7.1</a>. With No LSP in the Network ........................<a href="#page-29">29</a>
           <a href="#section-10.7.2">10.7.2</a>. With a Number of LSPs in the Network ..............<a href="#page-29">29</a>
      <a href="#section-10.8">10.8</a>. Metric Reporting .........................................<a href="#page-29">29</a>
   11. A Definition for Samples of Single Bidirectional LSP
       Setup Delay ...................................................<a href="#page-30">30</a>
      <a href="#section-11.1">11.1</a>. Metric Name ..............................................<a href="#page-30">30</a>
      <a href="#section-11.2">11.2</a>. Metric Parameters ........................................<a href="#page-30">30</a>
      <a href="#section-11.3">11.3</a>. Metric Units .............................................<a href="#page-30">30</a>
      <a href="#section-11.4">11.4</a>. Definition ...............................................<a href="#page-30">30</a>
      <a href="#section-11.5">11.5</a>. Discussion ...............................................<a href="#page-31">31</a>
      <a href="#section-11.6">11.6</a>. Methodologies ............................................<a href="#page-31">31</a>
      <a href="#section-11.7">11.7</a>. Typical Testing Cases ....................................<a href="#page-32">32</a>
           <a href="#section-11.7.1">11.7.1</a>. With No LSP in the Network ........................<a href="#page-32">32</a>
           <a href="#section-11.7.2">11.7.2</a>. With a Number of LSPs in the Network ..............<a href="#page-32">32</a>
      <a href="#section-11.8">11.8</a>. Metric Reporting .........................................<a href="#page-32">32</a>
   12. A Definition for Samples of Multiple Bidirectional
       LSPs Setup Delay ..............................................<a href="#page-32">32</a>
      <a href="#section-12.1">12.1</a>. Metric Name ..............................................<a href="#page-33">33</a>
      <a href="#section-12.2">12.2</a>. Metric Parameters ........................................<a href="#page-33">33</a>
      <a href="#section-12.3">12.3</a>. Metric Units .............................................<a href="#page-33">33</a>
      <a href="#section-12.4">12.4</a>. Definition ...............................................<a href="#page-33">33</a>



<span class="grey">Sun &amp; Zhang                  Standards Track                    [Page 4]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-5" ></span>
<span class="grey"><a href="./rfc5814">RFC 5814</a>            LSP Dynamic PPM in GMPLS Networks         March 2010</span>


      <a href="#section-12.5">12.5</a>. Discussion ...............................................<a href="#page-34">34</a>
      <a href="#section-12.6">12.6</a>. Methodologies ............................................<a href="#page-34">34</a>
      <a href="#section-12.7">12.7</a>. Typical Testing Cases ....................................<a href="#page-35">35</a>
           <a href="#section-12.7.1">12.7.1</a>. With No LSP in the Network ........................<a href="#page-35">35</a>
           <a href="#section-12.7.2">12.7.2</a>. With a Number of LSPs in the Network ..............<a href="#page-35">35</a>
      <a href="#section-12.8">12.8</a>. Metric Reporting .........................................<a href="#page-35">35</a>
   <a href="#section-13">13</a>. A Definition for Samples of LSP Graceful Release Delay ........<a href="#page-35">35</a>
      <a href="#section-13.1">13.1</a>. Metric Name ..............................................<a href="#page-36">36</a>
      <a href="#section-13.2">13.2</a>. Metric Parameters ........................................<a href="#page-36">36</a>
      <a href="#section-13.3">13.3</a>. Metric Units .............................................<a href="#page-36">36</a>
      <a href="#section-13.4">13.4</a>. Definition ...............................................<a href="#page-36">36</a>
      <a href="#section-13.5">13.5</a>. Discussion ...............................................<a href="#page-36">36</a>
      <a href="#section-13.6">13.6</a>. Methodologies ............................................<a href="#page-37">37</a>
      <a href="#section-13.7">13.7</a>. Metric Reporting .........................................<a href="#page-37">37</a>
   <a href="#section-14">14</a>. Some Statistics Definitions for Metrics to Report .............<a href="#page-37">37</a>
      <a href="#section-14.1">14.1</a>. The Minimum of Metric ....................................<a href="#page-37">37</a>
      <a href="#section-14.2">14.2</a>. The Median of Metric .....................................<a href="#page-37">37</a>
      <a href="#section-14.3">14.3</a>. The Maximum of Metric ....................................<a href="#page-38">38</a>
      <a href="#section-14.4">14.4</a>. The Percentile of Metric .................................<a href="#page-38">38</a>
      <a href="#section-14.5">14.5</a>. Failure Statistics of Metric .............................<a href="#page-38">38</a>
           <a href="#section-14.5.1">14.5.1</a>. Failure Count .....................................<a href="#page-39">39</a>
           <a href="#section-14.5.2">14.5.2</a>. Failure Ratio .....................................<a href="#page-39">39</a>
   <a href="#section-15">15</a>. Discussion ....................................................<a href="#page-39">39</a>
   <a href="#section-16">16</a>. Security Considerations .......................................<a href="#page-40">40</a>
   <a href="#section-17">17</a>. Acknowledgments ...............................................<a href="#page-41">41</a>
   <a href="#section-18">18</a>. References ....................................................<a href="#page-41">41</a>
      <a href="#section-18.1">18.1</a>. Normative References .....................................<a href="#page-41">41</a>
      <a href="#section-18.2">18.2</a>. Informative References ...................................<a href="#page-42">42</a>
   <a href="#appendix-A">Appendix A</a>.  Authors' Addresses ...................................<a href="#page-43">43</a>






















<span class="grey">Sun &amp; Zhang                  Standards Track                    [Page 5]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-6" ></span>
<span class="grey"><a href="./rfc5814">RFC 5814</a>            LSP Dynamic PPM in GMPLS Networks         March 2010</span>


<span class="h2"><a class="selflink" id="section-1" href="#section-1">1</a>.  Introduction</span>

   Generalized Multi-Protocol Label Switching (GMPLS) is one of the most
   promising control plane solutions for future transport and service
   network.  GMPLS has been developed to control and operate different
   kinds of network elements, such as conventional routers, switches,
   Dense Wavelength Division Multiplexing (DWDM) systems, Add-Drop
   Multiplexors (ADMs), photonic cross-connects (PXCs), optical cross-
   connects (OXCs), etc.  These physically diverse devices differ
   drastically from one another in dynamic provisioning ability.

   The introduction of a control plane into optical circuit switching
   networks provides the basis for automating the provisioning of
   connections and drastically reduces connection provision delay.  As
   more and more services and applications are seeking to use GMPLS-
   controlled networks as their underlying transport network, and
   increasingly in a dynamic way, the need is growing for measuring and
   characterizing the performance of LSP provisioning in GMPLS networks,
   such that requirement from applications and the provisioning
   capability of the network can be mapped to each other.

   This document defines performance metrics and methodologies that can
   be used to characterize the dynamic LSP provisioning performance of
   GMPLS networks, more specifically, performance of the signaling
   protocol.  The metrics defined in this document can be used to
   characterize the average performance of GMPLS implementations.

<span class="h2"><a class="selflink" id="section-2" href="#section-2">2</a>.  Conventions Used in This Document</span>

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
   document are to be interpreted as described in [<a href="./rfc2119" title="&quot;Key words for use in RFCs to Indicate Requirement Levels&quot;">RFC2119</a>].

<span class="h2"><a class="selflink" id="section-3" href="#section-3">3</a>.  Overview of Performance Metrics</span>

   In this memo, to characterize the dynamic LSP provisioning
   performance of a GMPLS network, we define three performance metrics:
   unidirectional LSP setup delay, bidirectional LSP setup delay, and
   LSP graceful release delay.  The latency of the LSP setup/release
   signal is conceptually similar to the Round-trip Delay in IP
   networks.  This enables us to refer to the structures and notions
   introduced and discussed in the IP Performance Metrics (IPPM)
   Framework documents, [<a href="./rfc2330" title="&quot;Framework for IP Performance Metrics&quot;">RFC2330</a>] [<a href="./rfc2679" title="&quot;A One- way Delay Metric for IPPM&quot;">RFC2679</a>] [<a href="./rfc2681" title="&quot;A Round- trip Delay Metric for IPPM&quot;">RFC2681</a>].  The reader is
   assumed to be familiar with the notions in those documents.







<span class="grey">Sun &amp; Zhang                  Standards Track                    [Page 6]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-7" ></span>
<span class="grey"><a href="./rfc5814">RFC 5814</a>            LSP Dynamic PPM in GMPLS Networks         March 2010</span>


   Note that data-path-related metrics, for example, the time between
   the reception of a Resv message by the ingress node and when the
   forward data path becomes operational, are defined in another
   document [<a href="#ref-CCAMP-DPM" title="&quot;Label Switched Path (LSP) Data Path Delay Metric in Generalized MPLS/ MPLS-TE Networks&quot;">CCAMP-DPM</a>].  It is desirable that both measurements are
   performed to complement each other.

<span class="h2"><a class="selflink" id="section-4" href="#section-4">4</a>.  A Singleton Definition for Single Unidirectional LSP Setup Delay</span>

   This section defines a metric for single unidirectional Label
   Switched Path setup delay across a GMPLS network.

<span class="h3"><a class="selflink" id="section-4.1" href="#section-4.1">4.1</a>.  Motivation</span>

   Single unidirectional Label Switched Path setup delay is useful for
   several reasons:

   o  Single LSP setup delay is an important metric that characterizes
      the provisioning performance of a GMPLS network.  Longer LSP setup
      delay will most likely incur higher overhead for the requesting
      application, especially when the LSP duration itself is comparable
      to the LSP setup delay.

   o  The minimum value of this metric provides an indication of the
      delay that will likely be experienced when the LSP traverses the
      shortest route at the lightest load in the control plane.  As the
      delay itself consists of several components, such as link
      propagation delay and nodal processing delay, this metric also
      reflects the status of the control plane.  For example, for LSPs
      traversing the same route, longer setup delays may suggest
      congestion in the control channel or high control element load.
      For this reason, this metric is useful for testing and diagnostic
      purposes.

   o  The observed variance in a sample of LSP setup delay metric values
      variance may serve as an early indicator on the feasibility of
      support of applications that have stringent setup delay
      requirements.

   The measurement of single unidirectional LSP setup delay instead of
   bidirectional LSP setup delay is motivated by the following factors:

   o  Some applications may use only unidirectional LSPs rather than
      bidirectional ones.  For example, content delivery services with
      multicasting may use only unidirectional LSPs.

<span class="h3"><a class="selflink" id="section-4.2" href="#section-4.2">4.2</a>.  Metric Name</span>

   Single unidirectional LSP setup delay



<span class="grey">Sun &amp; Zhang                  Standards Track                    [Page 7]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-8" ></span>
<span class="grey"><a href="./rfc5814">RFC 5814</a>            LSP Dynamic PPM in GMPLS Networks         March 2010</span>


<span class="h3"><a class="selflink" id="section-4.3" href="#section-4.3">4.3</a>.  Metric Parameters</span>

   o  ID0, the ingress Label Switching Router (LSR) ID

   o  ID1, the egress LSR ID

   o  T, a time when the setup is attempted

<span class="h3"><a class="selflink" id="section-4.4" href="#section-4.4">4.4</a>.  Metric Units</span>

   The value of single unidirectional LSP setup delay is either a real
   number of milliseconds or undefined.

<span class="h3"><a class="selflink" id="section-4.5" href="#section-4.5">4.5</a>.  Definition</span>

   The single unidirectional LSP setup delay from ingress node ID0 to
   egress node ID1 [<a href="./rfc3945" title="&quot;Generalized Multi-Protocol Label Switching (GMPLS) Architecture&quot;">RFC3945</a>] at T is dT means that ingress node ID0
   sends the first bit of a Path message packet to egress node ID1 at
   wire-time T, and that ingress node ID0 received the last bit of
   responding Resv message packet from egress node ID1 at wire-time
   T+dT.

   The single unidirectional LSP setup delay from ingress node ID0 to
   egress node ID1 at T is undefined means that ingress node ID0 sends
   the first bit of Path message packet to egress node ID1 at wire-time
   T and that ingress node ID0 does not receive the corresponding Resv
   message within a reasonable period of time.

   The undefined value of this metric indicates an event of Single
   Unidirectional LSP Setup Failure and would be used to report a count
   or a percentage of Single Unidirectional LSP Setup failures.  See
   <a href="#section-14.5">Section 14.5</a> for definitions of LSP setup/release failures.

<span class="h3"><a class="selflink" id="section-4.6" href="#section-4.6">4.6</a>.  Discussion</span>

   The following issues are likely to come up in practice:

   o  The accuracy of unidirectional LSP setup delay at time T depends
      on the clock resolution in the ingress node; but synchronization
      between the ingress node and egress node is not required since
      unidirectional LSP setup uses two-way signaling.

   o  A given methodology will have to include a way to determine
      whether a latency value is infinite or whether it is merely very
      large.  Simple upper bounds MAY be used, but GMPLS networks may
      accommodate many kinds of devices.  For example, some photonic
      cross-connects (PXCs) have to move micro mirrors.  This physical
      motion may take several milliseconds, but the common electronic



<span class="grey">Sun &amp; Zhang                  Standards Track                    [Page 8]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-9" ></span>
<span class="grey"><a href="./rfc5814">RFC 5814</a>            LSP Dynamic PPM in GMPLS Networks         March 2010</span>


      switches can finish the nodal processing within several
      microseconds.  So the unidirectional LSP setup delay varies
      drastically from one network to another.  In practice, the upper
      bound SHOULD be chosen carefully.

   o  If the ingress node sends out the Path message to set up an LSP,
      but never receives the corresponding Resv message, the
      unidirectional LSP setup delay MUST be set to undefined.

   o  If the ingress node sends out the Path message to set up an LSP
      but receives a PathErr message, the unidirectional LSP setup delay
      MUST be set to undefined.  There are many possible reasons for
      this case; for example, the Path message has invalid parameters or
      the network does not have enough resources to set up the requested
      LSP, etc.

<span class="h3"><a class="selflink" id="section-4.7" href="#section-4.7">4.7</a>.  Methodologies</span>

   Generally, the methodology would proceed as follows:

   o  Make sure that the network has enough resources to set up the
      requested LSP.

   o  At the ingress node, form the Path message according to the LSP
      requirements.  A timestamp (T1) may be stored locally on the
      ingress node when the Path message packet is sent towards the
      egress node.

   o  If the corresponding Resv message arrives within a reasonable
      period of time, take the timestamp (T2) as soon as possible upon
      receipt of the message.  By subtracting the two timestamps, an
      estimate of unidirectional LSP setup delay (T2-T1) can be
      computed.

   o  If the corresponding Resv message fails to arrive within a
      reasonable period of time, the unidirectional LSP setup delay is
      deemed to be undefined.  Note that the "reasonable" threshold is a
      parameter of the methodology.

   o  If the corresponding response is a PathErr message, the
      unidirectional LSP setup delay is deemed to be undefined.

<span class="h3"><a class="selflink" id="section-4.8" href="#section-4.8">4.8</a>.  Metric Reporting</span>

   The metric result (either a real number or undefined) MUST be
   reported together with the selected upper bound.  The route that the
   LSP traverses MUST also be reported.  The route MAY be collected via




<span class="grey">Sun &amp; Zhang                  Standards Track                    [Page 9]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-10" ></span>
<span class="grey"><a href="./rfc5814">RFC 5814</a>            LSP Dynamic PPM in GMPLS Networks         March 2010</span>


   use of the record route object, see [<a href="./rfc3209" title="&quot;RSVP-TE: Extensions to RSVP for LSP Tunnels&quot;">RFC3209</a>], or via the management
   plane.  The collection of routes via the management plane is out of
   scope of this document.

<span class="h2"><a class="selflink" id="section-5" href="#section-5">5</a>.  A Singleton Definition for Multiple Unidirectional LSPs Setup Delay</span>

   This section defines a metric for multiple unidirectional Label
   Switched Paths setup delay across a GMPLS network.

<span class="h3"><a class="selflink" id="section-5.1" href="#section-5.1">5.1</a>.  Motivation</span>

   Multiple unidirectional Label Switched Paths setup delay is useful
   for several reasons:

   o  Carriers may require that a large number of LSPs be set up during
      a short time period.  This request may arise, e.g., as a
      consequence to interruptions on established LSPs or other network
      failures.

   o  The time needed to set up a large number of LSPs during a short
      time period cannot be deduced from single LSP setup delay.

<span class="h3"><a class="selflink" id="section-5.2" href="#section-5.2">5.2</a>.  Metric Name</span>

   Multiple unidirectional LSPs setup delay

<span class="h3"><a class="selflink" id="section-5.3" href="#section-5.3">5.3</a>.  Metric Parameters</span>

   o  ID0, the ingress LSR ID

   o  ID1, the egress LSR ID

   o  Lambda_m, a rate in reciprocal milliseconds

   o  X, the number of LSPs to set up

   o  T, a time when the first setup is attempted

<span class="h3"><a class="selflink" id="section-5.4" href="#section-5.4">5.4</a>.  Metric Units</span>

   The value of multiple unidirectional LSPs setup delay is either a
   real number of milliseconds or undefined









<span class="grey">Sun &amp; Zhang                  Standards Track                   [Page 10]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-11" ></span>
<span class="grey"><a href="./rfc5814">RFC 5814</a>            LSP Dynamic PPM in GMPLS Networks         March 2010</span>


<span class="h3"><a class="selflink" id="section-5.5" href="#section-5.5">5.5</a>.  Definition</span>

   Given Lambda_m and X, the multiple unidirectional LSPs setup delay
   from the ingress node to the egress node [<a href="./rfc3945" title="&quot;Generalized Multi-Protocol Label Switching (GMPLS) Architecture&quot;">RFC3945</a>] at T is dT means:

   o  ingress node ID0 sends the first bit of the first Path message
      packet to egress node ID1 at wire-time T;

   o  all subsequent (X-1) Path messages are sent according to the
      specified Poisson process with arrival rate Lambda_m;

   o  ingress node ID0 receives all corresponding Resv message packets
      from egress node ID1; and

   o  ingress node ID0 receives the last Resv message packet at wire-
      time T+dT.

   If the multiple unidirectional LSPs setup delay at T is "undefined",
   this means that:

   o  ingress node ID0 sends all the Path messages toward egress node
      ID1,

   o  the first bit of the first Path message packet is sent at wire-
      time T, and

   o  ingress node ID0 does not receive one or more of the corresponding
      Resv messages within a reasonable period of time.

   The undefined value of this metric indicates an event of Multiple
   Unidirectional LSP Setup Failure and would be used to report a count
   or a percentage of Multiple Unidirectional LSP Setup failures.  See
   <a href="#section-14.5">Section 14.5</a> for definitions of LSP setup/release failures.

<span class="h3"><a class="selflink" id="section-5.6" href="#section-5.6">5.6</a>.  Discussion</span>

   The following issues are likely to come up in practice:

   o  The accuracy of multiple unidirectional LSPs setup delay at time T
      depends on the clock resolution in the ingress node; but
      synchronization between the ingress node and egress node is not
      required since unidirectional LSP setup uses two-way signaling.

   o  A given methodology will have to include a way to determine
      whether a latency value is infinite or whether it is merely very
      large.  Simple upper bounds MAY be used, but GMPLS networks may
      accommodate many kinds of devices.  For example, some photonic
      cross-connects (PXCs) have to move micro mirrors.  This physical



<span class="grey">Sun &amp; Zhang                  Standards Track                   [Page 11]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-12" ></span>
<span class="grey"><a href="./rfc5814">RFC 5814</a>            LSP Dynamic PPM in GMPLS Networks         March 2010</span>


      motion may take several milliseconds, but electronic switches can
      finish the nodal processing within several microseconds.  So the
      multiple unidirectional LSP setup delay varies drastically from
      one network to another.  In practice, the upper bound SHOULD be
      chosen carefully.

   o  If the ingress node sends out the multiple Path messages to set up
      the LSPs, but never receives one or more of the corresponding Resv
      messages, multiple unidirectional LSP setup delay MUST be set to
      undefined.

   o  If the ingress node sends out the Path messages to set up the LSPs
      but receives one or more PathErr messages, multiple unidirectional
      LSPs setup delay MUST be set to undefined.  There are many
      possible reasons for this case.  For example, one of the Path
      messages has invalid parameters or the network does not have
      enough resources to set up the requested LSPs, etc.

   o  The arrival rate of the Poisson process Lambda_m SHOULD be chosen
      carefully such that on the one hand, the control plane is not
      overburdened.  On the other hand, the arrival rate is large enough
      to meet the requirements of applications or services.

   o  It is important that all the LSPs MUST traverse the same route.
      If there are multiple routes between the ingress node ID0 and
      egress node ID1, Explicit Route Objects (EROs), or an alternate
      method, e.g., static configuration, MUST be used to ensure that
      all LSPs traverse the same route.

<span class="h3"><a class="selflink" id="section-5.7" href="#section-5.7">5.7</a>.  Methodologies</span>

   Generally, the methodology would proceed as follows:

   o  Make sure that the network has enough resources to set up the
      requested LSPs.

   o  At the ingress node, form the Path messages according to the LSPs'
      requirements.

   o  At the ingress node, select the time for each of the Path messages
      according to the specified Poisson process.

   o  At the ingress node, send out the Path messages according to the
      selected time.

   o  Store a timestamp (T1) locally on the ingress node when the first
      Path message packet is sent towards the egress node.




<span class="grey">Sun &amp; Zhang                  Standards Track                   [Page 12]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-13" ></span>
<span class="grey"><a href="./rfc5814">RFC 5814</a>            LSP Dynamic PPM in GMPLS Networks         March 2010</span>


   o  If all of the corresponding Resv messages arrive within a
      reasonable period of time, take the final timestamp (T2) as soon
      as possible upon the receipt of all the messages.  By subtracting
      the two timestamps, an estimate of multiple unidirectional LSPs
      setup delay (T2-T1) can be computed.

   o  If one or more of the corresponding Resv messages fail to arrive
      within a reasonable period of time, the multiple unidirectional
      LSPs setup delay is deemed to be undefined.  Note that the
      "reasonable" threshold is a parameter of the methodology.

   o  If one or more of the corresponding responses are PathErr
      messages, the multiple unidirectional LSPs setup delay is deemed
      to be undefined.

<span class="h3"><a class="selflink" id="section-5.8" href="#section-5.8">5.8</a>.  Metric Reporting</span>

   The metric result (either a real number or undefined) MUST be
   reported together with the selected upper bound.  The route that the
   LSPs traverse MUST also be reported.  The route MAY be collected via
   use of the record route object, see [<a href="./rfc3209" title="&quot;RSVP-TE: Extensions to RSVP for LSP Tunnels&quot;">RFC3209</a>], or via the management
   plane.  The collection of routes via the management plane is out of
   scope of this document.

<span class="h2"><a class="selflink" id="section-6" href="#section-6">6</a>.  A Singleton Definition for Single Bidirectional LSP Setup Delay</span>

   GMPLS allows establishment of bidirectional symmetric LSPs (not of
   asymmetric LSPs).  This section defines a metric for single
   bidirectional LSP setup delay across a GMPLS network.

<span class="h3"><a class="selflink" id="section-6.1" href="#section-6.1">6.1</a>.  Motivation</span>

   Single bidirectional Label Switched Path setup delay is useful for
   several reasons:

   o  LSP setup delay is an important metric that characterizes the
      provisioning performance of a GMPLS network.  Longer LSP setup
      delay will incur higher overhead for the requesting application,
      especially when the LSP duration is comparable to the LSP setup
      delay.  Thus, measuring the setup delay is important for
      application scheduling.

   o  The minimum value of this metric provides an indication of the
      delay that will likely be experienced when the LSP traverses the
      shortest route at the lightest load in the control plane.  As the
      delay itself consists of several components, such as link
      propagation delay and nodal processing delay, this metric also
      reflects the status of the control plane.  For example, for LSPs



<span class="grey">Sun &amp; Zhang                  Standards Track                   [Page 13]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-14" ></span>
<span class="grey"><a href="./rfc5814">RFC 5814</a>            LSP Dynamic PPM in GMPLS Networks         March 2010</span>


      traversing the same route, longer setup delays may suggest
      congestion in the control channel or high control element load.
      For this reason, this metric is useful for testing and diagnostic
      purposes.

   o  LSP setup delay variance has a different impact on applications.
      Erratic variation in LSP setup delay makes it difficult to support
      applications that have stringent setup delay requirement.

   The measurement of single bidirectional LSP setup delay instead of
   unidirectional LSP setup delay is motivated by the following factors:

   o  Bidirectional LSPs are seen as a requirement for many GMPLS
      networks.  Its provisioning performance is important to
      applications that generate bidirectional traffic.

<span class="h3"><a class="selflink" id="section-6.2" href="#section-6.2">6.2</a>.  Metric Name</span>

   Single bidirectional LSP setup delay

<span class="h3"><a class="selflink" id="section-6.3" href="#section-6.3">6.3</a>.  Metric Parameters</span>

   o  ID0, the ingress LSR ID

   o  ID1, the egress LSR ID

   o  T, a time when the setup is attempted

<span class="h3"><a class="selflink" id="section-6.4" href="#section-6.4">6.4</a>.  Metric Units</span>

   The value of single bidirectional LSP setup delay is either a real
   number of milliseconds or undefined

<span class="h3"><a class="selflink" id="section-6.5" href="#section-6.5">6.5</a>.  Definition</span>

   For a real number dT, the single bidirectional LSP setup delay from
   ingress node ID0 to egress node ID1 at T is dT means that ingress
   node ID0 sends out the first bit of a Path message including an
   Upstream Label [<a href="./rfc3473" title="&quot;Generalized Multi-Protocol Label Switching (GMPLS) Signaling Resource ReserVation Protocol-Traffic Engineering (RSVP-TE) Extensions&quot;">RFC3473</a>] heading for egress node ID1 at wire-time T,
   egress node ID1 receives that packet, then immediately sends a Resv
   message packet back to ingress node ID0, and that ingress node ID0
   receives the last bit of the Resv message packet at wire-time T+dT.

   If the single bidirectional LSP setup delay from ingress node ID0 to
   egress node ID1 at T is "undefined", this means that ingress node ID0
   sends the first bit of a Path message to egress node ID1 at wire-time
   T and that ingress node ID0 does not receive that response packet
   within a reasonable period of time.



<span class="grey">Sun &amp; Zhang                  Standards Track                   [Page 14]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-15" ></span>
<span class="grey"><a href="./rfc5814">RFC 5814</a>            LSP Dynamic PPM in GMPLS Networks         March 2010</span>


   The undefined value of this metric indicates an event of Single
   Bidirectional LSP Setup Failure and would be used to report a count
   or a percentage of Single Bidirectional LSP Setup failures.  See
   <a href="#section-14.5">Section 14.5</a> for definitions of LSP setup/release failures.

<span class="h3"><a class="selflink" id="section-6.6" href="#section-6.6">6.6</a>.  Discussion</span>

   The following issues are likely to come up in practice:

   o  The accuracy of single bidirectional LSP setup delay depends on
      the clock resolution in the ingress node; but synchronization
      between the ingress node and egress node is not required since
      single bidirectional LSP setup uses two-way signaling.

   o  A given methodology will have to include a way to determine
      whether a latency value is infinite or whether it is merely very
      large.  Simple upper bounds MAY be used, but GMPLS networks may
      accommodate many kinds of devices.  For example, some photonic
      cross-connects (PXCs) have to move micro mirrors.  This physical
      motion may take several milliseconds, but electronic switches can
      finish the nodal processing within several microseconds.  So the
      bidirectional LSP setup delay varies drastically from one network
      to another.  In the process of bidirectional LSP setup, if the
      downstream node overrides the label suggested by the upstream
      node, the setup delay may also increase.  Thus, in practice, the
      upper bound SHOULD be chosen carefully.

   o  If the ingress node sends out the Path message to set up the LSP,
      but never receives the corresponding Resv message, single
      bidirectional LSP setup delay MUST be set to undefined.

   o  If the ingress node sends out the Path message to set up the LSP,
      but receives a PathErr message, single bidirectional LSP setup
      delay MUST be set to undefined.  There are many possible reasons
      for this case.  For example, the Path message has invalid
      parameters or the network does not have enough resources to set up
      the requested LSP.

<span class="h3"><a class="selflink" id="section-6.7" href="#section-6.7">6.7</a>.  Methodologies</span>

   Generally, the methodology would proceed as follows:

   o  Make sure that the network has enough resources to set up the
      requested LSP.







<span class="grey">Sun &amp; Zhang                  Standards Track                   [Page 15]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-16" ></span>
<span class="grey"><a href="./rfc5814">RFC 5814</a>            LSP Dynamic PPM in GMPLS Networks         March 2010</span>


   o  At the ingress node, form the Path message (including the Upstream
      Label or suggested label) according to the LSP requirements.  A
      timestamp (T1) may be stored locally on the ingress node when the
      Path message packet is sent towards the egress node.

   o  If the corresponding Resv message arrives within a reasonable
      period of time, take the final timestamp (T2) as soon as possible
      upon the receipt of the message.  By subtracting the two
      timestamps, an estimate of bidirectional LSP setup delay (T2-T1)
      can be computed.

   o  If the corresponding Resv message fails to arrive within a
      reasonable period of time, the single bidirectional LSP setup
      delay is deemed to be undefined.  Note that the "reasonable"
      threshold is a parameter of the methodology.

   o  If the corresponding response is a PathErr message, the single
      bidirectional LSP setup delay is deemed to be undefined.

<span class="h3"><a class="selflink" id="section-6.8" href="#section-6.8">6.8</a>.  Metric Reporting</span>

   The metric result (either a real number or undefined) MUST be
   reported together with the selected upper bound.  The route that the
   LSP traverses MUST also be reported.  The route MAY be collected via
   use of the record route object, see [<a href="./rfc3209" title="&quot;RSVP-TE: Extensions to RSVP for LSP Tunnels&quot;">RFC3209</a>], or via the management
   plane.  The collection of routes via the management plane is out of
   scope of this document.

<span class="h2"><a class="selflink" id="section-7" href="#section-7">7</a>.  A Singleton Definition for Multiple Bidirectional LSPs Setup Delay</span>

   This section defines a metric for multiple bidirectional LSPs setup
   delay across a GMPLS network.

<span class="h3"><a class="selflink" id="section-7.1" href="#section-7.1">7.1</a>.  Motivation</span>

   Multiple bidirectional LSPs setup delay is useful for several
   reasons:

   o  Upon traffic interruption caused by network failure or network
      upgrade, carriers may require a large number of LSPs be set up
      during a short time period.

   o  The time needed to set up a large number of LSPs during a short
      time period cannot be deduced by single LSP setup delay.

<span class="h3"><a class="selflink" id="section-7.2" href="#section-7.2">7.2</a>.  Metric Name</span>

   Multiple bidirectional LSPs setup delay



<span class="grey">Sun &amp; Zhang                  Standards Track                   [Page 16]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-17" ></span>
<span class="grey"><a href="./rfc5814">RFC 5814</a>            LSP Dynamic PPM in GMPLS Networks         March 2010</span>


<span class="h3"><a class="selflink" id="section-7.3" href="#section-7.3">7.3</a>.  Metric Parameters</span>

   o  ID0, the ingress LSR ID

   o  ID1, the egress LSR ID

   o  Lambda_m, a rate in reciprocal milliseconds

   o  X, the number of LSPs to set up

   o  T, a time when the first setup is attempted

<span class="h3"><a class="selflink" id="section-7.4" href="#section-7.4">7.4</a>.  Metric Units</span>

   The value of multiple bidirectional LSPs setup delay is either a real
   number of milliseconds or undefined

<span class="h3"><a class="selflink" id="section-7.5" href="#section-7.5">7.5</a>.  Definition</span>

   Given Lambda_m and X, for a real number dT, the multiple
   bidirectional LSPs setup delay from ingress node to egress node at T
   is dT, means that:

   o  Ingress node ID0 sends the first bit of the first Path message
      heading for egress node ID1 at wire-time T;

   o  All subsequent (X-1) Path messages are sent according to the
      specified Poisson process with arrival rate Lambda_m;

   o  Ingress node ID1 receives all corresponding Resv message packets
      from egress node ID1; and

   o  Ingress node ID0 receives the last Resv message packet at wire-
      time T+dT.

   If the multiple bidirectional LSPs setup delay from ingress node to
   egress node at T is "undefined", this means that the ingress node
   sends all the Path messages to the egress node and that the ingress
   node fails to receive one or more of the response Resv messages
   within a reasonable period of time.

   The undefined value of this metric indicates an event of Multiple
   Bidirectional LSP Setup Failure and would be used to report a count
   or a percentage of Multiple Bidirectional LSP Setup failures.  See
   <a href="#section-14.5">Section 14.5</a> for definitions of LSP setup/release failures.






<span class="grey">Sun &amp; Zhang                  Standards Track                   [Page 17]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-18" ></span>
<span class="grey"><a href="./rfc5814">RFC 5814</a>            LSP Dynamic PPM in GMPLS Networks         March 2010</span>


<span class="h3"><a class="selflink" id="section-7.6" href="#section-7.6">7.6</a>.  Discussion</span>

   The following issues are likely to come up in practice:

   o  The accuracy of multiple bidirectional LSPs setup delay depends on
      the clock resolution in the ingress node; but synchronization
      between the ingress node and egress node is not required since
      bidirectional LSP setup uses two-way signaling.

   o  A given methodology will have to include a way to determine
      whether a latency value is infinite or whether it is merely very
      large.  Simple upper bounds MAY be used, but GMPLS networks may
      accommodate many kinds of devices.  For example, some photonic
      cross-connects (PXCs) have to move micro mirrors.  This physical
      motion may take several milliseconds, but electronic switches can
      finish the nodal process within several microseconds.  So the
      multiple bidirectional LSPs setup delay varies drastically from a
      network to another.  In the process of multiple bidirectional LSPs
      setup, if the downstream node overrides the label suggested by the
      upstream node, the setup delay may also increase.  Thus, in
      practice, the upper bound SHOULD be chosen carefully.

   o  If the ingress node sends out the Path messages to set up the
      LSPs, but never receives all the corresponding Resv messages, the
      multiple bidirectional LSPs setup delay MUST be set to undefined.

   o  If the ingress node sends out the Path messages to set up the
      LSPs, but receives one or more responding PathErr messages, the
      multiple bidirectional LSPs setup delay MUST be set to undefined.
      There are many possible reasons for this case.  For example, one
      or more of the Path messages have invalid parameters or the
      network does not have enough resources to set up the requested
      LSPs.

   o  The arrival rate of the Poisson process Lambda_m SHOULD be
      carefully chosen such that on the one hand, the control plane is
      not overburdened.  On the other hand, the arrival rate is large
      enough to meet the requirements of applications or services.

   o  It is important that all the LSPs MUST traverse the same route.
      If there are multiple routes between the ingress node ID0 and
      egress node ID1, EROs, or an alternate method, e.g., static
      configuration, MUST be used to ensure that all LSPs traverse the
      same route.







<span class="grey">Sun &amp; Zhang                  Standards Track                   [Page 18]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-19" ></span>
<span class="grey"><a href="./rfc5814">RFC 5814</a>            LSP Dynamic PPM in GMPLS Networks         March 2010</span>


<span class="h3"><a class="selflink" id="section-7.7" href="#section-7.7">7.7</a>.  Methodologies</span>

   Generally, the methodology would proceed as follows:

   o  Make sure that the network has enough resources to set up the
      requested LSPs.

   o  At the ingress node, form the Path messages (including the
      Upstream Label or suggested label) according to the LSPs'
      requirements.

   o  At the ingress node, select the time for each of the Path messages
      according to the specified Poisson process.

   o  At the ingress node, send out the Path messages according to the
      selected time.

   o  Store a timestamp (T1) locally in the ingress node when the first
      Path message packet is sent towards the egress node.

   o  If all of the corresponding Resv messages arrive within a
      reasonable period of time, take the final timestamp (T2) as soon
      as possible upon the receipt of all the messages.  By subtracting
      the two timestamps, an estimate of multiple bidirectional LSPs
      setup delay (T2-T1) can be computed.

   o  If one or more of the corresponding Resv messages fail to arrive
      within a reasonable period of time, the multiple bidirectional
      LSPs setup delay is deemed to be undefined.  Note that the
      "reasonable" threshold is a parameter of the methodology.

   o  If one or more of the corresponding responses are PathErr
      messages, the multiple bidirectional LSPs setup delay is deemed to
      be undefined.

<span class="h3"><a class="selflink" id="section-7.8" href="#section-7.8">7.8</a>.  Metric Reporting</span>

   The metric result (either a real number or undefined) MUST be
   reported together with the selected upper bound.  The route that the
   LSPs traverse MUST also be reported.  The route MAY be collected via
   use of the record route object, see [<a href="./rfc3209" title="&quot;RSVP-TE: Extensions to RSVP for LSP Tunnels&quot;">RFC3209</a>], or via the management
   plane.  The collection of routes via the management plane is out of
   scope of this document.








<span class="grey">Sun &amp; Zhang                  Standards Track                   [Page 19]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-20" ></span>
<span class="grey"><a href="./rfc5814">RFC 5814</a>            LSP Dynamic PPM in GMPLS Networks         March 2010</span>


<span class="h2"><a class="selflink" id="section-8" href="#section-8">8</a>.  A Singleton Definition for LSP Graceful Release Delay</span>

   There are two different kinds of LSP release mechanisms in GMPLS
   networks: graceful release and forceful release.  This document does
   not take forceful LSP release procedure into account.

<span class="h3"><a class="selflink" id="section-8.1" href="#section-8.1">8.1</a>.  Motivation</span>

   LSP graceful release delay is useful for several reasons:

   o  The LSP graceful release delay is part of the total cost of
      dynamic LSP provisioning.  For some short duration applications,
      the LSP release time cannot be ignored.

   o  The LSP graceful release procedure is more preferred in a GMPLS
      controlled network, particularly the optical networks.  Since it
      doesn't trigger restoration/protection, it is "alarm-free
      connection deletion" in [<a href="./rfc4208" title="&quot;Generalized Multiprotocol Label Switching (GMPLS) User-Network Interface (UNI): Resource ReserVation Protocol-Traffic Engineering (RSVP-TE) Support for the Overlay Model&quot;">RFC4208</a>].

<span class="h3"><a class="selflink" id="section-8.2" href="#section-8.2">8.2</a>.  Metric Name</span>

   LSP graceful release delay

<span class="h3"><a class="selflink" id="section-8.3" href="#section-8.3">8.3</a>.  Metric Parameters</span>

   o  ID0, the ingress LSR ID

   o  ID1, the egress LSR ID

   o  T, a time when the release is attempted

<span class="h3"><a class="selflink" id="section-8.4" href="#section-8.4">8.4</a>.  Metric Units</span>

   The value of LSP graceful release delay is either a real number of
   milliseconds or undefined

<span class="h3"><a class="selflink" id="section-8.5" href="#section-8.5">8.5</a>.  Definition</span>

   There are two different LSP graceful release procedures: one is
   initiated by the ingress node, and another is initiated by the egress
   node.  The two procedures are depicted in [<a href="./rfc3473" title="&quot;Generalized Multi-Protocol Label Switching (GMPLS) Signaling Resource ReserVation Protocol-Traffic Engineering (RSVP-TE) Extensions&quot;">RFC3473</a>].  We define the
   graceful LSP release delay for these two procedures separately.

   For a real number dT, if the LSP graceful release delay from ingress
   node ID0 to egress node ID1 at T is dT, this means that ingress node
   ID0 sends the first bit of a Path message including an Admin Status
   Object with the Reflect (R) and Delete (D) bits set to the egress
   node at wire-time T, that egress node ID1 receives that packet, then



<span class="grey">Sun &amp; Zhang                  Standards Track                   [Page 20]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-21" ></span>
<span class="grey"><a href="./rfc5814">RFC 5814</a>            LSP Dynamic PPM in GMPLS Networks         March 2010</span>


   immediately sends a Resv message including an Admin Status Object
   with the Delete (D) bit set back to the ingress node.  Ingress node
   ID0 sends the PathTear message downstream to remove the LSP, and
   egress node ID1 receives the last bit of PathTear packet at wire-time
   T+dT.

   Also, as an option, upon receipt of the Path message including an
   Admin Status Object with the Reflect (R) and Delete (D) bits set,
   egress node ID1 may respond with a PathErr message with the
   Path_State_Removed flag set.

   The LSP graceful release delay from ingress node ID0 to egress node
   ID1 at T is undefined means that ingress node ID0 sends the first bit
   of Path message to egress node ID1 at wire-time T and that (either
   the egress node does not receive the Path packet, the egress node
   does not send a corresponding Resv message packet in response, or the
   ingress node does not receive that Resv packet, and) egress node ID1
   does not receive the PathTear message within a reasonable period of
   time.

   If the LSP graceful release delay from egress node ID1 to ingress
   node ID0 at T is dT, this means that egress node ID1 sends the first
   bit of a Resv message including an Admin Status Object with the
   Reflect (R) and Delete (D) bits set to the ingress node at wire-time
   T.  Ingress node ID0 sends a PathTear message downstream to remove
   the LSP, and egress node ID1 receives the last bit of PathTear packet
   at wire-time T+dT.

   If the LSP graceful release delay from egress node ID1 to ingress
   node ID0 at T is "undefined", this means that egress node ID1 sends
   the first bit of Resv message including an Admin Status Object with
   the Reflect (R) and Delete (D) bits set to the ingress node ID0 at
   wire-time T and that (either the ingress node does not receive the
   Resv packet or the ingress node does not send PathTear message packet
   in response, and) egress node ID1 does not receive the PathTear
   message within a reasonable period of time.

   The undefined value of this metric indicates an event of LSP Graceful
   Release Failure and would be used to report a count or a percentage
   of LSP Graceful Release failures.  See <a href="#section-14.5">Section 14.5</a> for definitions
   of LSP setup/release failures.










<span class="grey">Sun &amp; Zhang                  Standards Track                   [Page 21]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-22" ></span>
<span class="grey"><a href="./rfc5814">RFC 5814</a>            LSP Dynamic PPM in GMPLS Networks         March 2010</span>


<span class="h3"><a class="selflink" id="section-8.6" href="#section-8.6">8.6</a>.  Discussion</span>

   The following issues are likely to come up in practice:

   o  In the first (second) circumstance, the accuracy of LSP graceful
      release delay at time T depends on the clock resolution in the
      ingress (egress) node.  In the first circumstance, synchronization
      between the ingress node and egress node is required, but it is
      not in the second circumstance.

   o  A given methodology has to include a way to determine whether a
      latency value is infinite or whether it is merely very large.
      Simple upper bounds MAY be used, but the upper bound SHOULD be
      chosen carefully in practice.

   o  In the first circumstance, if the ingress node sends out Path
      message including an Admin Status Object with the Reflect (R) and
      Delete (D) bits set to initiate LSP graceful release, but the
      egress node never receives the corresponding PathTear message, LSP
      graceful release delay MUST be set to undefined.

   o  In the second circumstance, if the egress node sends out the Resv
      message including an Admin Status Object with the Reflect (R) and
      Delete (D) bits set to initiate LSP graceful release, but never
      receives the corresponding PathTear message, LSP graceful release
      delay MUST be set to undefined.

<span class="h3"><a class="selflink" id="section-8.7" href="#section-8.7">8.7</a>.  Methodologies</span>

   In the first circumstance, the methodology may proceed as follows:

   o  Make sure the LSP to be deleted is set up;

   o  At the ingress node, form the Path message including an Admin
      Status Object with the Reflect (R) and Delete (D) bits set.  A
      timestamp (T1) may be stored locally on the ingress node when the
      Path message packet is sent towards the egress node.

   o  Upon receiving the Path message including an Admin Status Object
      with the Reflect (R) and Delete (D) bits set, the egress node
      sends a Resv message including an Admin Status Object with the
      Delete (D) and Reflect (R) bits set.  Alternatively, the egress
      node sends a PathErr message with the Path_State_Removed flag set
      upstream.

   o  When the ingress node receives the Resv message or the PathErr
      message, it sends a PathTear message to remove the LSP.




<span class="grey">Sun &amp; Zhang                  Standards Track                   [Page 22]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-23" ></span>
<span class="grey"><a href="./rfc5814">RFC 5814</a>            LSP Dynamic PPM in GMPLS Networks         March 2010</span>


   o  The egress node takes a timestamp (T2) once it receives the last
      bit of the PathTear message.  The LSP graceful release delay is
      then (T2-T1).

   o  If the ingress node sends the Path message downstream, but the
      egress node fails to receive the PathTear message within a
      reasonable period of time, the LSP graceful release delay is
      deemed to be undefined.  Note that the "reasonable" threshold is a
      parameter of the methodology.

   In the second circumstance, the methodology would proceed as follows:

   o  Make sure the LSP to be deleted is set up;

   o  On the egress node, form the Resv message including an Admin
      Status Object with the Reflect (R) and Delete (D) bits set.  A
      timestamp may be stored locally on the egress node when the Resv
      message packet is sent towards the ingress node.

   o  Upon receiving the Admin Status Object with the Reflect (R) and
      Delete (D) bits set in the Resv message, the ingress node sends a
      PathTear message downstream to remove the LSP.

   o  The egress node takes a timestamp (T2) once it receives the last
      bit of the PathTear message.  The LSP graceful release delay is
      then (T2-T1).

   o  If the egress node sends the Resv message upstream, but it fails
      to receive the PathTear message within a reasonable period of
      time, the LSP graceful release delay is deemed to be undefined.
      Note that the "reasonable" threshold is a parameter of the
      methodology.

<span class="h3"><a class="selflink" id="section-8.8" href="#section-8.8">8.8</a>.  Metric Reporting</span>

   The metric result (either a real number or undefined) MUST be
   reported together with the selected upper bound and the procedure
   used (e.g., either from the ingress node to the egress node or from
   the egress node to the ingress node; see <a href="#section-8.5">Section 8.5</a> for more
   details).  The route that the LSP traverses MUST also be reported.
   The route MAY be collected via use of the record route object, see
   [<a href="./rfc3209" title="&quot;RSVP-TE: Extensions to RSVP for LSP Tunnels&quot;">RFC3209</a>], or via the management plane.  The collection of routes via
   the management plane is out of scope of this document.








<span class="grey">Sun &amp; Zhang                  Standards Track                   [Page 23]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-24" ></span>
<span class="grey"><a href="./rfc5814">RFC 5814</a>            LSP Dynamic PPM in GMPLS Networks         March 2010</span>


<span class="h2"><a class="selflink" id="section-9" href="#section-9">9</a>.  A Definition for Samples of Single Unidirectional LSP Setup Delay</span>

   In <a href="#section-4">Section 4</a>, we defined the singleton metric of single
   unidirectional LSP setup delay.  Now we define how to get one
   particular sample of single unidirectional LSP setup delay.  Sampling
   means to take a number of distinct instances of a skeleton metric
   under a given set of parameters.  As in [<a href="./rfc2330" title="&quot;Framework for IP Performance Metrics&quot;">RFC2330</a>], we use Poisson
   sampling as an example.

<span class="h3"><a class="selflink" id="section-9.1" href="#section-9.1">9.1</a>.  Metric Name</span>

   Single unidirectional LSP setup delay sample

<span class="h3"><a class="selflink" id="section-9.2" href="#section-9.2">9.2</a>.  Metric Parameters</span>

   o  ID0, the ingress LSR ID

   o  ID1, the egress LSR ID

   o  T0, a time

   o  Tf, a time

   o  Lambda, a rate in the reciprocal milliseconds

   o  Th, LSP holding time

   o  Td, the maximum waiting time for successful setup

<span class="h3"><a class="selflink" id="section-9.3" href="#section-9.3">9.3</a>.  Metric Units</span>

   A sequence of pairs; the elements of each pair are:

   o  T, a time when setup is attempted

   o  dT, either a real number of milliseconds or undefined

<span class="h3"><a class="selflink" id="section-9.4" href="#section-9.4">9.4</a>.  Definition</span>

   Given T0, Tf, and Lambda, compute a pseudo-random Poisson process
   beginning at or before T0, with average arrival rate Lambda, and
   ending at or after Tf.  Those time values greater than or equal to T0
   and less than or equal to Tf are then selected.  At each of the times
   in this process, we obtain the value of unidirectional LSP setup
   delay sample.  The value of the sample is the sequence made up of the
   resulting &lt;time, LSP setup delay&gt; pairs.  If there are no such pairs,
   the sequence is of length zero and the sample is said to be empty.




<span class="grey">Sun &amp; Zhang                  Standards Track                   [Page 24]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-25" ></span>
<span class="grey"><a href="./rfc5814">RFC 5814</a>            LSP Dynamic PPM in GMPLS Networks         March 2010</span>


<span class="h3"><a class="selflink" id="section-9.5" href="#section-9.5">9.5</a>.  Discussion</span>

   The parameter Lambda should be carefully chosen.  If the rate is too
   high, too frequent LSP setup/release procedure will result in high
   overhead in the control plane.  In turn, the high overhead will
   increase unidirectional LSP setup delay.  On the other hand, if the
   rate is too low, the sample might not completely reflect the dynamic
   provisioning performance of the GMPLS network.  The appropriate
   Lambda value depends on the given network.

   The parameters Td should be carefully chosen.  Different switching
   technologies may vary significantly in performing a cross-connect
   operation.  At the same time, the time needed in setting up an LSP
   under different traffic may also vary significantly.

   In the case of active measurement, the parameters Th should be
   carefully chosen.  The combination of Lambda and Th reflects the load
   of the network.  The selection of Th should take into account that
   the network has sufficient resources to perform subsequent tests.
   The value of Th MAY be constant during one sampling process for
   simplicity considerations.

   Note that for online or passive measurements, the arrival rate and
   LSP holding time are determined by actual traffic; hence, in this
   case, Lambda and Th are not input parameters.

   It is important that, in obtaining a sample, all the LSPs MUST
   traverse the same route.  If there are multiple routes between the
   ingress node ID0 and egress node ID1, EROs, or an alternate method,
   e.g., static configuration, MUST be used to ensure that all LSPs
   traverse the same route.

<span class="h3"><a class="selflink" id="section-9.6" href="#section-9.6">9.6</a>.  Methodologies</span>

   o  Select the times using the specified Poisson arrival process,

   o  Set up the LSP as the methodology for the singleton unidirectional
      LSP setup delay, and obtain the value of unidirectional LSP setup
      delay, and

   o  Release the LSP after Th, and wait for the next Poisson arrival
      event.

   Note: it is possible that before the previous LSP release procedure
   completes, the next Poisson arrival event arrives and the LSP setup
   procedure is initiated.  If there is resource contention between the
   two LSPs, the LSP setup may fail.  Ways to avoid such contention are
   outside the scope of this document.



<span class="grey">Sun &amp; Zhang                  Standards Track                   [Page 25]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-26" ></span>
<span class="grey"><a href="./rfc5814">RFC 5814</a>            LSP Dynamic PPM in GMPLS Networks         March 2010</span>


<span class="h3"><a class="selflink" id="section-9.7" href="#section-9.7">9.7</a>.  Typical Testing Cases</span>

<span class="h4"><a class="selflink" id="section-9.7.1" href="#section-9.7.1">9.7.1</a>.  With No LSP in the Network</span>

<span class="h5"><a class="selflink" id="section-9.7.1.1" href="#section-9.7.1.1">9.7.1.1</a>.  Motivation</span>

   Single unidirectional LSP setup delay with no LSP in the network is
   important because this reflects the inherent delay of a Resource
   Reservation Protocol - Traffic Engineering (RSVP-TE) implementation.
   The minimum value provides an indication of the delay that will
   likely be experienced when an LSP traverses the shortest route with
   the lightest load in the control plane.

<span class="h5"><a class="selflink" id="section-9.7.1.2" href="#section-9.7.1.2">9.7.1.2</a>.  Methodologies</span>

   Make sure that there is no LSP in the network and proceed with the
   methodologies described in <a href="#section-9.6">Section 9.6</a>

<span class="h4"><a class="selflink" id="section-9.7.2" href="#section-9.7.2">9.7.2</a>.  With a Number of LSPs in the Network</span>

<span class="h5"><a class="selflink" id="section-9.7.2.1" href="#section-9.7.2.1">9.7.2.1</a>.  Motivation</span>

   Single unidirectional LSP setup delay with a number of LSPs in the
   network is important because it reflects the performance of an
   operational network with considerable load.  This delay may vary
   significantly as the number of existing LSPs vary.  It can be used as
   a scalability metric of an RSVP-TE implementation.

<span class="h5"><a class="selflink" id="section-9.7.2.2" href="#section-9.7.2.2">9.7.2.2</a>.  Methodologies</span>

   Set up the required number of LSPs, and wait until the network
   reaches a stable state; then, proceed with the methodologies
   described in <a href="#section-9.6">Section 9.6</a>.

<span class="h3"><a class="selflink" id="section-9.8" href="#section-9.8">9.8</a>.  Metric Reporting</span>

   The metric results including both real and undefined values MUST be
   reported together with the total number of values.  The context under
   which the sample is obtained, including the selected parameters, the
   route traversed by the LSPs, and the testing case used, MUST also be
   reported.

<span class="h2"><a class="selflink" id="section-10" href="#section-10">10</a>.  A Definition for Samples of Multiple Unidirectional LSPs Setup</span>
<span class="h2">     Delay</span>

   In <a href="#section-5">Section 5</a>, we defined the singleton metric of multiple
   unidirectional LSPs setup delay.  Now we define how to get one
   particular sample of multiple unidirectional LSPs setup delay.



<span class="grey">Sun &amp; Zhang                  Standards Track                   [Page 26]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-27" ></span>
<span class="grey"><a href="./rfc5814">RFC 5814</a>            LSP Dynamic PPM in GMPLS Networks         March 2010</span>


   Sampling means to take a number of distinct instances of a skeleton
   metric under a given set of parameters.  As in [<a href="./rfc2330" title="&quot;Framework for IP Performance Metrics&quot;">RFC2330</a>], we use
   Poisson sampling as an example.

<span class="h3"><a class="selflink" id="section-10.1" href="#section-10.1">10.1</a>.  Metric Name</span>

   Multiple unidirectional LSPs setup delay sample

<span class="h3"><a class="selflink" id="section-10.2" href="#section-10.2">10.2</a>.  Metric Parameters</span>

   o  ID0, the ingress LSR ID

   o  ID1, the egress LSR ID

   o  T0, a time

   o  Tf, a time

   o  Lambda_m, a rate in the reciprocal milliseconds

   o  Lambda, a rate in the reciprocal milliseconds

   o  X, the number of LSPs to set up

   o  Th, LSP holding time

   o  Td, the maximum waiting time for successful multiple
      unidirectional LSPs setup

<span class="h3"><a class="selflink" id="section-10.3" href="#section-10.3">10.3</a>.  Metric Units</span>

   A sequence of pairs; the elements of each pair are:

   o  T, a time when the first setup is attempted

   o  dT, either a real number of milliseconds or undefined

<span class="h3"><a class="selflink" id="section-10.4" href="#section-10.4">10.4</a>.  Definition</span>

   Given T0, Tf, and Lambda, compute a pseudo-random Poisson process
   beginning at or before T0, with an average arrival rate Lambda and
   ending at or after Tf.  Those time values greater than or equal to T0
   and less than or equal to Tf are then selected.  At each of the times
   in this process, we obtain the value of multiple unidirectional LSP
   setup delay sample.  The value of the sample is the sequence made up
   of the resulting &lt;time, setup delay&gt; pairs.  If there are no such
   pairs, the sequence is of length zero and the sample is said to be
   empty.



<span class="grey">Sun &amp; Zhang                  Standards Track                   [Page 27]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-28" ></span>
<span class="grey"><a href="./rfc5814">RFC 5814</a>            LSP Dynamic PPM in GMPLS Networks         March 2010</span>


<span class="h3"><a class="selflink" id="section-10.5" href="#section-10.5">10.5</a>.  Discussion</span>

   The parameter Lambda is used as an arrival rate of "batch
   unidirectional LSPs setup" operation.  It regulates the interval in
   between each batch operation.  The parameter Lambda_m is used within
   each batch operation, as described in <a href="#section-5">Section 5</a>

   The parameters Lambda and Lambda_m should be carefully chosen.  If
   the rate is too high, overly frequent LSP setup/release procedure
   will result in high overhead in the control plane.  In turn, the high
   overhead will increase unidirectional LSP setup delay.  On the other
   hand, if the rate is too low, the sample might not completely reflect
   the dynamic provisioning performance of the GMPLS network.  The
   appropriate Lambda and Lambda_m value depends on the given network.

   The parameters Td should be carefully chosen.  Different switching
   technologies may vary significantly in performing a cross-connect
   operation.  At the same time, the time needed in setting up an LSP
   under different traffic may also vary significantly.

   It is important that, in obtaining a sample, all the LSPs MUST
   traverse the same route.  If there are multiple routes between the
   ingress node ID0 and egress node ID1, EROs, or an alternate method,
   e.g., static configuration, MUST be used to ensure that all LSPs
   traverse the same route.

<span class="h3"><a class="selflink" id="section-10.6" href="#section-10.6">10.6</a>.  Methodologies</span>

   o  Select the times using the specified Poisson arrival process,

   o  Set up the LSP as the methodology for the singleton multiple
      unidirectional LSPs setup delay, and obtain the value of multiple
      unidirectional LSPs setup delay, and

   o  Release the LSP after Th, and wait for the next Poisson arrival
      event.

   Note: it is possible that before the previous LSP release procedure
   completes, the next Poisson arrival event arrives and the LSP setup
   procedure is initiated.  If there is resource contention between the
   two LSPs, the LSP setup may fail.  Ways to avoid such contention are
   outside the scope of this document.









<span class="grey">Sun &amp; Zhang                  Standards Track                   [Page 28]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-29" ></span>
<span class="grey"><a href="./rfc5814">RFC 5814</a>            LSP Dynamic PPM in GMPLS Networks         March 2010</span>


<span class="h3"><a class="selflink" id="section-10.7" href="#section-10.7">10.7</a>.  Typical Testing Cases</span>

<span class="h4"><a class="selflink" id="section-10.7.1" href="#section-10.7.1">10.7.1</a>.  With No LSP in the Network</span>

<span class="h5"><a class="selflink" id="section-10.7.1.1" href="#section-10.7.1.1">10.7.1.1</a>.  Motivation</span>

   Multiple unidirectional LSPs setup delay with no LSP in the network
   is important because this reflects the inherent delay of an RSVP-TE
   implementation.  The minimum value provides an indication of the
   delay that will likely be experienced when LSPs traverse the shortest
   route with the lightest load in the control plane.

<span class="h5"><a class="selflink" id="section-10.7.1.2" href="#section-10.7.1.2">10.7.1.2</a>.  Methodologies</span>

   Make sure that there is no LSP in the network and proceed with the
   methodologies described in <a href="#section-10.6">Section 10.6</a>.

<span class="h4"><a class="selflink" id="section-10.7.2" href="#section-10.7.2">10.7.2</a>.  With a Number of LSPs in the Network</span>

<span class="h5"><a class="selflink" id="section-10.7.2.1" href="#section-10.7.2.1">10.7.2.1</a>.  Motivation</span>

   Multiple unidirectional LSPs setup delay with a number of LSPs in the
   network is important because it reflects the performance of an
   operational network with considerable load.  This delay can vary
   significantly as the number of existing LSPs vary.  It can be used as
   a scalability metric of an RSVP-TE implementation.

<span class="h5"><a class="selflink" id="section-10.7.2.2" href="#section-10.7.2.2">10.7.2.2</a>.  Methodologies</span>

   Set up the required number of LSPs, and wait until the network
   reaches a stable state; then, proceed with the methodologies
   described in <a href="#section-10.6">Section 10.6</a>.

<span class="h3"><a class="selflink" id="section-10.8" href="#section-10.8">10.8</a>.  Metric Reporting</span>

   The metric results including both real and undefined values MUST be
   reported together with the total number of values.  The context under
   which the sample is obtained, including the selected parameters, the
   route traversed by the LSPs, and the testing case used, MUST also be
   reported.











<span class="grey">Sun &amp; Zhang                  Standards Track                   [Page 29]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-30" ></span>
<span class="grey"><a href="./rfc5814">RFC 5814</a>            LSP Dynamic PPM in GMPLS Networks         March 2010</span>


<span class="h2"><a class="selflink" id="section-11" href="#section-11">11</a>.  A Definition for Samples of Single Bidirectional LSP Setup Delay</span>

   In <a href="#section-6">Section 6</a>, we defined the singleton metric of single bidirectional
   LSP setup delay.  Now we define how to get one particular sample of
   single bidirectional LSP setup delay.  Sampling means to take a
   number of distinct instances of a skeleton metric under a given set
   of parameters.  As in [<a href="./rfc2330" title="&quot;Framework for IP Performance Metrics&quot;">RFC2330</a>], we use Poisson sampling as an
   example.

<span class="h3"><a class="selflink" id="section-11.1" href="#section-11.1">11.1</a>.  Metric Name</span>

   Single bidirectional LSP setup delay sample with no LSP in the
   network

<span class="h3"><a class="selflink" id="section-11.2" href="#section-11.2">11.2</a>.  Metric Parameters</span>

   o  ID0, the ingress LSR ID

   o  ID1, the egress LSR ID

   o  T0, a time

   o  Tf, a time

   o  Lambda, a rate in the reciprocal milliseconds

   o  Th, LSP holding time

   o  Td, the maximum waiting time for successful setup

<span class="h3"><a class="selflink" id="section-11.3" href="#section-11.3">11.3</a>.  Metric Units</span>

   A sequence of pairs; the elements of each pair are:

   o  T, a time when setup is attempted

   o  dT, either a real number of milliseconds or undefined

<span class="h3"><a class="selflink" id="section-11.4" href="#section-11.4">11.4</a>.  Definition</span>

   Given T0, Tf, and Lambda, compute a pseudo-random Poisson process
   beginning at or before T0, with an average arrival rate Lambda, and
   ending at or after Tf.  Those time values greater than or equal to T0
   and less than or equal to Tf are then selected.  At each of the times
   in this process, we obtain the value of bidirectional LSP setup delay
   sample.  The value of the sample is the sequence made up of the
   resulting &lt;time, LSP setup delay&gt; pairs.  If there are no such pairs,
   the sequence is of length zero and the sample is said to be empty.



<span class="grey">Sun &amp; Zhang                  Standards Track                   [Page 30]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-31" ></span>
<span class="grey"><a href="./rfc5814">RFC 5814</a>            LSP Dynamic PPM in GMPLS Networks         March 2010</span>


<span class="h3"><a class="selflink" id="section-11.5" href="#section-11.5">11.5</a>.  Discussion</span>

   The parameters Lambda should be carefully chosen.  If the rate is too
   high, overly frequent LSP setup/release procedure will result in high
   overhead in the control plane.  In turn, the high overhead will
   increase bidirectional LSP setup delay.  On the other hand, if the
   rate is too low, the sample might not completely reflect the dynamic
   provisioning performance of the GMPLS network.  The appropriate
   Lambda value depends on the given network.

   The parameters Td should be carefully chosen.  Different switching
   technologies may vary significantly in performing a cross-connect
   operation.  At the same time, the time needed to set up an LSP under
   different traffic may also vary significantly.

   In the case of active measurement, the parameters Th should be
   carefully chosen.  The combination of Lambda and Th reflects the load
   of the network.  The selection of Th SHOULD take into account that
   the network has sufficient resources to perform subsequent tests.
   The value of Th MAY be constant during one sampling process for
   simplicity considerations.

   Note that for online or passive measurements, the arrival rate and
   the LSP holding time are determined by actual traffic; hence, in this
   case, Lambda and Th are not input parameters.

   It is important that, in obtaining a sample, all the LSPs MUST
   traverse the same route.  If there are multiple routes between the
   ingress node ID0 and egress node ID1, EROs, or an alternate method,
   e.g., static configuration, MUST be used to ensure that all LSPs
   traverse the same route.

<span class="h3"><a class="selflink" id="section-11.6" href="#section-11.6">11.6</a>.  Methodologies</span>

   o  Select the times using the specified Poisson arrival process,

   o  Set up the LSP as the methodology for the singleton bidirectional
      LSP setup delay, and obtain the value of bidirectional LSP setup
      delay, and

   o  Release the LSP after Th, and wait for the next Poisson arrival
      event.

   Note: it is possible that before the previous LSP release procedure
   completes, the next Poisson arrival event arrives and the LSP setup
   procedure is initiated.  If there is resource contention between the
   two LSPs, the LSP setup may fail.  Ways to avoid such contention are
   outside the scope of this document.



<span class="grey">Sun &amp; Zhang                  Standards Track                   [Page 31]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-32" ></span>
<span class="grey"><a href="./rfc5814">RFC 5814</a>            LSP Dynamic PPM in GMPLS Networks         March 2010</span>


<span class="h3"><a class="selflink" id="section-11.7" href="#section-11.7">11.7</a>.  Typical Testing Cases</span>

<span class="h4"><a class="selflink" id="section-11.7.1" href="#section-11.7.1">11.7.1</a>.  With No LSP in the Network</span>

<span class="h5"><a class="selflink" id="section-11.7.1.1" href="#section-11.7.1.1">11.7.1.1</a>.  Motivation</span>

   Single bidirectional LSP setup delay with no LSP in the network is
   important because this reflects the inherent delay of an RSVP-TE
   implementation.  The minimum value provides an indication of the
   delay that will likely be experienced when an LSP traverses the
   shortest route with the lightest load in the control plane.

<span class="h5"><a class="selflink" id="section-11.7.1.2" href="#section-11.7.1.2">11.7.1.2</a>.  Methodologies</span>

   Make sure that there is no LSP in the network and proceed with the
   methodologies described in <a href="#section-11.6">Section 11.6</a>.

<span class="h4"><a class="selflink" id="section-11.7.2" href="#section-11.7.2">11.7.2</a>.  With a Number of LSPs in the Network</span>

<span class="h5"><a class="selflink" id="section-11.7.2.1" href="#section-11.7.2.1">11.7.2.1</a>.  Motivation</span>

   Single bidirectional LSP setup delay with a number of LSPs in the
   network is important because it reflects the performance of an
   operational network with considerable load.  This delay can vary
   significantly as the number of existing LSPs varies.  It can be used
   as a scalability metric of an RSVP-TE implementation.

<span class="h5"><a class="selflink" id="section-11.7.2.2" href="#section-11.7.2.2">11.7.2.2</a>.  Methodologies</span>

   Set up the required number of LSPs and wait until the network reaches
   a stable state; then, proceed with the methodologies described in
   <a href="#section-11.6">Section 11.6</a>.

<span class="h3"><a class="selflink" id="section-11.8" href="#section-11.8">11.8</a>.  Metric Reporting</span>

   The metric results including both real and undefined values MUST be
   reported together with the total number of values.  The context under
   which the sample is obtained, including the selected parameters, the
   route traversed by the LSPs, and the testing case used, MUST also be
   reported.

<span class="h2"><a class="selflink" id="section-12" href="#section-12">12</a>.  A Definition for Samples of Multiple Bidirectional LSPs Setup Delay</span>

   In <a href="#section-7">Section 7</a>, we defined the singleton metric of multiple
   bidirectional LSPs setup delay.  Now we define how to get one
   particular sample of multiple bidirectional LSP setup delay.





<span class="grey">Sun &amp; Zhang                  Standards Track                   [Page 32]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-33" ></span>
<span class="grey"><a href="./rfc5814">RFC 5814</a>            LSP Dynamic PPM in GMPLS Networks         March 2010</span>


   Sampling means to take a number of distinct instances of a skeleton
   metric under a given set of parameters.  As in [<a href="./rfc2330" title="&quot;Framework for IP Performance Metrics&quot;">RFC2330</a>], we use
   Poisson sampling as an example.

<span class="h3"><a class="selflink" id="section-12.1" href="#section-12.1">12.1</a>.  Metric Name</span>

   Multiple bidirectional LSPs setup delay sample

<span class="h3"><a class="selflink" id="section-12.2" href="#section-12.2">12.2</a>.  Metric Parameters</span>

   o  ID0, the ingress LSR ID

   o  ID1, the egress LSR ID

   o  T0, a time

   o  Tf, a time

   o  Lambda_m, a rate in the reciprocal milliseconds

   o  Lambda, a rate in the reciprocal milliseconds

   o  X, the number of LSPs to set up

   o  Th, LSP holding time

   o  Td, the maximum waiting time for successful multiple
      unidirectional LSPs setup

<span class="h3"><a class="selflink" id="section-12.3" href="#section-12.3">12.3</a>.  Metric Units</span>

   A sequence of pairs; the elements of each pair are:

   o  T, a time when the first setup is attempted

   o  dT, either a real number of milliseconds or undefined

<span class="h3"><a class="selflink" id="section-12.4" href="#section-12.4">12.4</a>.  Definition</span>

   Given T0, Tf, and Lambda, compute a pseudo-random Poisson process
   beginning at or before T0, with an average arrival rate Lambda and
   ending at or after Tf.  Those time values greater than or equal to T0
   and less than or equal to Tf are then selected.  At each of the times
   in this process, we obtain the value of multiple unidirectional LSP
   setup delay sample.  The value of the sample is the sequence made up
   of the resulting &lt;time, setup delay&gt; pairs.  If there are no such
   pairs, the sequence is of length zero and the sample is said to be
   empty.



<span class="grey">Sun &amp; Zhang                  Standards Track                   [Page 33]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-34" ></span>
<span class="grey"><a href="./rfc5814">RFC 5814</a>            LSP Dynamic PPM in GMPLS Networks         March 2010</span>


<span class="h3"><a class="selflink" id="section-12.5" href="#section-12.5">12.5</a>.  Discussion</span>

   The parameter Lambda is used as an arrival rate of "batch
   bidirectional LSPs setup" operation.  It regulates the interval in
   between each batch operation.  The parameter Lambda_m is used within
   each batch operation, as described in <a href="#section-7">Section 7</a>.

   The parameters Lambda and Lambda_m should be carefully chosen.  If
   the rate is too high, overly frequent LSP setup/release procedure
   will result in high overhead in the control plane.  In turn, the high
   overhead will increase unidirectional LSP setup delay.  On the other
   hand, if the rate is too low, the sample might not completely reflect
   the dynamic provisioning performance of the GMPLS network.  The
   appropriate Lambda and Lambda_m values depend on the given network.

   The parameters Td should be carefully chosen.  Different switching
   technologies may vary significantly in performing a cross-connect
   operation.  At the same time, the time needed to set up an LSP under
   different traffic may also vary significantly.

   It is important that, in obtaining a sample, all the LSPs MUST
   traverse the same route.  If there are multiple routes between the
   ingress node ID0 and egress node ID1, EROs, or an alternate method,
   e.g., static configuration, MUST be used to ensure that all LSPs
   traverse the same route.

<span class="h3"><a class="selflink" id="section-12.6" href="#section-12.6">12.6</a>.  Methodologies</span>

   o  Select the times using the specified Poisson arrival process,

   o  Set up the LSP as the methodology for the singleton multiple
      bidirectional LSPs setup delay, and obtain the value of multiple
      unidirectional LSPs setup delay, and

   o  Release the LSP after Th, and wait for the next Poisson arrival
      event.

   Note: it is possible that before the previous LSP release procedure
   completes, the next Poisson arrival event arrives and the LSP setup
   procedure is initiated.  If there is resource contention between the
   two LSPs, the LSP setup may fail.  Ways to avoid such contention are
   outside the scope of this document.









<span class="grey">Sun &amp; Zhang                  Standards Track                   [Page 34]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-35" ></span>
<span class="grey"><a href="./rfc5814">RFC 5814</a>            LSP Dynamic PPM in GMPLS Networks         March 2010</span>


<span class="h3"><a class="selflink" id="section-12.7" href="#section-12.7">12.7</a>.  Typical Testing Cases</span>

<span class="h4"><a class="selflink" id="section-12.7.1" href="#section-12.7.1">12.7.1</a>.  With No LSP in the Network</span>

<span class="h5"><a class="selflink" id="section-12.7.1.1" href="#section-12.7.1.1">12.7.1.1</a>.  Motivation</span>

   Multiple bidirectional LSPs setup delay with no LSP in the network is
   important because this reflects the inherent delay of an RSVP-TE
   implementation.  The minimum value provides an indication of the
   delay that will likely be experienced when an LSPs traverse the
   shortest route with the lightest load in the control plane.

<span class="h5"><a class="selflink" id="section-12.7.1.2" href="#section-12.7.1.2">12.7.1.2</a>.  Methodologies</span>

   Make sure that there is no LSP in the network and proceed with the
   methodologies described in <a href="#section-10.6">Section 10.6</a>.

<span class="h4"><a class="selflink" id="section-12.7.2" href="#section-12.7.2">12.7.2</a>.  With a Number of LSPs in the Network</span>

<span class="h5"><a class="selflink" id="section-12.7.2.1" href="#section-12.7.2.1">12.7.2.1</a>.  Motivation</span>

   Multiple bidirectional LSPs setup delay with a number of LSPs in the
   network is important because it reflects the performance of an
   operational network with considerable load.  This delay may vary
   significantly as the number of existing LSPs vary.  It may be used as
   a scalability metric of an RSVP-TE implementation.

<span class="h5"><a class="selflink" id="section-12.7.2.2" href="#section-12.7.2.2">12.7.2.2</a>.  Methodologies</span>

   Set up the required number of LSPs, and wait until the network
   reaches a stable state; then, proceed with the methodologies
   described in <a href="#section-12.6">Section 12.6</a>.

<span class="h3"><a class="selflink" id="section-12.8" href="#section-12.8">12.8</a>.  Metric Reporting</span>

   The metric results including both real and undefined values MUST be
   reported together with the total number of values.  The context under
   which the sample is obtained, including the selected parameters, the
   route traversed by the LSPs, and the testing case used, MUST also be
   reported.

<span class="h2"><a class="selflink" id="section-13" href="#section-13">13</a>.  A Definition for Samples of LSP Graceful Release Delay</span>

   In <a href="#section-8">Section 8</a>, we defined the singleton metric of LSP graceful release
   delay.  Now we define how to get one particular sample of LSP
   graceful release delay.  We also use Poisson sampling as an example.





<span class="grey">Sun &amp; Zhang                  Standards Track                   [Page 35]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-36" ></span>
<span class="grey"><a href="./rfc5814">RFC 5814</a>            LSP Dynamic PPM in GMPLS Networks         March 2010</span>


<span class="h3"><a class="selflink" id="section-13.1" href="#section-13.1">13.1</a>.  Metric Name</span>

   LSP graceful release delay sample

<span class="h3"><a class="selflink" id="section-13.2" href="#section-13.2">13.2</a>.  Metric Parameters</span>

   o  ID0, the ingress LSR ID

   o  ID1, the egress LSR ID

   o  T0, a time

   o  Tf, a time

   o  Lambda, a rate in reciprocal milliseconds

   o  Td, the maximum waiting time for successful LSP release

<span class="h3"><a class="selflink" id="section-13.3" href="#section-13.3">13.3</a>.  Metric Units</span>

   A sequence of pairs; the elements of each pair are:

   o  T, a time, and

   o  dT, either a real number of milliseconds or undefined

<span class="h3"><a class="selflink" id="section-13.4" href="#section-13.4">13.4</a>.  Definition</span>

   Given T0, Tf, and Lambda, we compute a pseudo-random Poisson process
   beginning at or before T0, with an average arrival rate Lambda and
   ending at or after Tf.  Those time values greater than or equal to T0
   and less than or equal to Tf are then selected.  At each of the times
   in this process, we obtain the value of LSP graceful release delay
   sample.  The value of the sample is the sequence made up of the
   resulting &lt;time, LSP graceful delay&gt; pairs.  If there are no such
   pairs, the sequence is of length zero and the sample is said to be
   empty.

<span class="h3"><a class="selflink" id="section-13.5" href="#section-13.5">13.5</a>.  Discussion</span>

   The parameter Lambda should be carefully chosen.  If the rate is too
   large, overly frequent LSP setup/release procedure will result in
   high overhead in the control plane.  In turn, the high overhead will
   increase unidirectional LSP setup delay.  On the other hand, if the
   rate is too small, the sample might not completely reflect the
   dynamic provisioning performance of the GMPLS network.  The
   appropriate Lambda value depends on the given network.




<span class="grey">Sun &amp; Zhang                  Standards Track                   [Page 36]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-37" ></span>
<span class="grey"><a href="./rfc5814">RFC 5814</a>            LSP Dynamic PPM in GMPLS Networks         March 2010</span>


   It is important that, in obtaining a sample, all the LSPs MUST
   traverse the same route.  If there are multiple routes between the
   ingress node ID0 and egress node ID1, EROs, or an alternate method,
   e.g., static configuration, MUST be used to ensure that all LSPs
   traverse the same route.

<span class="h3"><a class="selflink" id="section-13.6" href="#section-13.6">13.6</a>.  Methodologies</span>

   Generally, the methodology would proceed as follows:

   o  Set up the LSP to be deleted

   o  Select the times using the specified Poisson arrival process,

   o  Release the LSP as the methodology for the singleton LSP graceful
      release delay, and obtain the value of LSP graceful release delay,
      and

   o  Set up the LSP, and restart the Poisson arrival process, wait for
      the next Poisson arrival event.

<span class="h3"><a class="selflink" id="section-13.7" href="#section-13.7">13.7</a>.  Metric Reporting</span>

   The metric results including both real and undefined values MUST be
   reported together with the total number of values.  The context under
   which the sample is obtained, including the selected parameters, and
   the route traversed by the LSPs MUST also be reported.

<span class="h2"><a class="selflink" id="section-14" href="#section-14">14</a>.  Some Statistics Definitions for Metrics to Report</span>

   Given the samples of the performance metric, we now offer several
   statistics of these samples to report.  From these statistics, we can
   draw some useful conclusions of a GMPLS network.  The value of these
   metrics is either a real number of milliseconds or undefined.  In the
   following discussion, we only consider the finite values.

<span class="h3"><a class="selflink" id="section-14.1" href="#section-14.1">14.1</a>.  The Minimum of Metric</span>

   The minimum of the metric is the minimum of all the dT values in the
   sample.  In computing this, undefined values SHOULD be treated as
   infinitely large.  Note that this means that the minimum could thus
   be undefined if all the dT values are undefined.  In addition, the
   metric minimum SHOULD be set to undefined if the sample is empty.

<span class="h3"><a class="selflink" id="section-14.2" href="#section-14.2">14.2</a>.  The Median of Metric</span>

   Metric median is the median of the dT values in the given sample.  In
   computing the median, the undefined values MUST NOT be included.



<span class="grey">Sun &amp; Zhang                  Standards Track                   [Page 37]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-38" ></span>
<span class="grey"><a href="./rfc5814">RFC 5814</a>            LSP Dynamic PPM in GMPLS Networks         March 2010</span>


<span class="h3"><a class="selflink" id="section-14.3" href="#section-14.3">14.3</a>.  The Maximum of Metric</span>

   The maximum of the metric is the maximum of all the dT values in the
   sample.  In computing this, undefined values MUST NOT be included.
   Note that this means that measurements that exceed the upper bound
   are not reported in this statistic.  This is an important
   consideration when evaluating the maximum when the number of
   undefined measurements is non-zero.

<span class="h3"><a class="selflink" id="section-14.4" href="#section-14.4">14.4</a>.  The Percentile of Metric</span>

   The "empirical distribution function" (EDF) of a set of scalar
   measurements is a function F(x), which, for any x, gives the
   fractional proportion of the total measurements that were &lt;= x.

   Given a percentage X, the X-th percentile of the metric means the
   smallest value of x for which F(x) &gt;= X.  In computing the
   percentile, undefined values MUST NOT be included.

   See [<a href="./rfc2330" title="&quot;Framework for IP Performance Metrics&quot;">RFC2330</a>] for further details.

<span class="h3"><a class="selflink" id="section-14.5" href="#section-14.5">14.5</a>.  Failure Statistics of Metric</span>

   In the process of LSP setup/release, it may fail due to various
   reasons.  For example, setup/release may fail when the control plane
   is overburdened or when there is resource shortage in one of the
   intermediate nodes.  Since the setup/release failure may have
   significant impact on network operation, it is worthwhile to report
   each failure cases, so that appropriate operations can be performed
   to check the possible implementation, configuration or other
   deficiencies.

   Five types of failure events are defined in previous sections:

   o  Single Unidirectional LSP Setup Failure

   o  Multiple Unidirectional LSP Setup Failure

   o  Single Bidirectional LSP Setup Failure

   o  Multiple Bidirectional LSP Setup Failure

   o  LSP Graceful Release Failure

   Given the samples of the performance metric, we now offer two
   statistics of failure events of these samples to report.





<span class="grey">Sun &amp; Zhang                  Standards Track                   [Page 38]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-39" ></span>
<span class="grey"><a href="./rfc5814">RFC 5814</a>            LSP Dynamic PPM in GMPLS Networks         March 2010</span>


<span class="h4"><a class="selflink" id="section-14.5.1" href="#section-14.5.1">14.5.1</a>.  Failure Count</span>

   Failure Count is defined as the number of the undefined value of the
   corresponding performance metric (failure events) in a sample.  The
   value of Failure Count is an integer.

<span class="h4"><a class="selflink" id="section-14.5.2" href="#section-14.5.2">14.5.2</a>.  Failure Ratio</span>

   Failure Ratio is the percentage of the number of failure events to
   the total number of requests in a sample.  The calculation for
   Failure Ratio is defined as follows:

   X type failure ratio = Number of X type failure events/(Number of
   valid X type metric values + Number of X type failure events) * 100%.

<span class="h2"><a class="selflink" id="section-15" href="#section-15">15</a>.  Discussion</span>

   It is worthwhile to point out that:

   o  The unidirectional/bidirectional LSP setup delay is one ingress-
      egress round-trip time plus processing time.  But in this
      document, unidirectional/bidirectional LSP setup delay has not
      taken the processing time in the end nodes (ingress and/or egress)
      into account.  The timestamp T2 is taken after the endpoint node
      receives it.  Actually, the last node has to take some time to
      process local procedures.  Similarly, in the LSP graceful release
      delay, the memo has not considered the processing time in the end
      node.

   o  This document assumes that the correct procedures for installing
      the data plane are followed as described in [<a href="./rfc3209" title="&quot;RSVP-TE: Extensions to RSVP for LSP Tunnels&quot;">RFC3209</a>], [<a href="./rfc3471" title="&quot;Generalized Multi-Protocol Label Switching (GMPLS) Signaling Functional Description&quot;">RFC3471</a>],
      and [<a href="./rfc3473" title="&quot;Generalized Multi-Protocol Label Switching (GMPLS) Signaling Resource ReserVation Protocol-Traffic Engineering (RSVP-TE) Extensions&quot;">RFC3473</a>].  That is, by the time the egress receives and
      processes a Path message, it is safe for the egress to transmit
      data on the reverse path, and by the time the ingress receives and
      processes a Resv message it is safe for the ingress to transmit
      data on the forward path.  See [<a href="#ref-CCAMP-SWITCH" title="&quot;Advice on When It is Safe to Start Sending Data on Label Switched Paths Established Using RSVP-TE&quot;">CCAMP-SWITCH</a>] for detailed
      explanations.  This document does not include any verification
      that the implementations of the control plane software are
      conformant, although such tests MAY be constructed with the use of
      suitable signal generation test equipment.  In [<a href="#ref-CCAMP-DPM" title="&quot;Label Switched Path (LSP) Data Path Delay Metric in Generalized MPLS/ MPLS-TE Networks&quot;">CCAMP-DPM</a>], we
      defined a series of metrics to do such verifications.  However, it
      is RECOMMENDED that both the measurements defined in this document
      and the measurements defined in [<a href="#ref-CCAMP-DPM" title="&quot;Label Switched Path (LSP) Data Path Delay Metric in Generalized MPLS/ MPLS-TE Networks&quot;">CCAMP-DPM</a>] are performed to
      complement each other.







<span class="grey">Sun &amp; Zhang                  Standards Track                   [Page 39]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-40" ></span>
<span class="grey"><a href="./rfc5814">RFC 5814</a>            LSP Dynamic PPM in GMPLS Networks         March 2010</span>


   o  Note that, in implementing the tests described in this document, a
      tester should be sure to measure the time taken for the control
      plane messages including the processing of those messages by the
      nodes under test.

   o  Bidirectional LSPs may be set up using three-way signaling, where
      the initiating node will send a ResvConf message downstream upon
      receiving the Resv message.  The ResvConf message is used to
      notify the terminate node that it can transfer data upstream.
      Actually, both directions should be ready to transfer data when
      the Resv message is received by the initiating node.  Therefore,
      the bidirectional LSP setup delay defined in this document does
      not take the confirmation procedure into account.

<span class="h2"><a class="selflink" id="section-16" href="#section-16">16</a>.  Security Considerations</span>

   Samples of the metrics can be obtained in either active or passive
   manners.

   In active measurement, ingress nodes inject probing messages into the
   control plane.  Since the measurement endpoints must be conformant to
   signaling specifications and behave as normal signaling endpoints, it
   will not incur other security issues than normal LSP provisioning.
   However, the measurement parameters must be carefully selected so
   that the measurements inject trivial amounts of additional traffic
   into the networks they measure.  If they inject "too much" traffic,
   they can skew the results of the measurement, and, in extreme cases,
   cause congestion and denial of service.

   When samples of the metrics are collected in a passive manner, e.g.,
   by monitoring the operations on real-life LSPs, the implementation of
   the monitoring and reporting mechanism must be careful so that they
   will not be used to attack the control plane.  A typical
   implementation may use the Management Information Base (MIB) to
   collect/store the metrics and access to the MIB is limited to the
   Network Management Systems (NMSs).  In this case, passive monitoring
   will not incur other security issues than implementing the MIBs and
   NMSs.  If an implementation chooses to expose the performance data to
   other applications, then it must take into account the possible
   security issues it may face.  For example, when exposing the
   performance data through Simple Network Management Protocol (SNMP),
   certain authentication methods should be used to ensure that the
   entity maintaining the performance data are not subject to
   unauthorized readings and modifications.  Rate limiting on the
   performance query may also be desirable to reduce the risk that the
   entity maintaining the performance data are overwhelmed by too many
   query requests.  It is RECOMMENDED that implementers consider the




<span class="grey">Sun &amp; Zhang                  Standards Track                   [Page 40]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-41" ></span>
<span class="grey"><a href="./rfc5814">RFC 5814</a>            LSP Dynamic PPM in GMPLS Networks         March 2010</span>


   security features as provided by the SNMPv3 framework (see <a href="./rfc3410#section-8">[RFC3410],
   section&nbsp;8</a>), including full support for the SNMPv3 cryptographic
   mechanisms (for authentication and privacy).

   Additionally, the security considerations pertaining to the original
   RSVP protocol [<a href="./rfc2205" title="&quot;Resource ReSerVation Protocol (RSVP) -- Version 1 Functional Specification&quot;">RFC2205</a>] and its TE extensions [<a href="./rfc3209" title="&quot;RSVP-TE: Extensions to RSVP for LSP Tunnels&quot;">RFC3209</a>] also remain
   relevant.

<span class="h2"><a class="selflink" id="section-17" href="#section-17">17</a>.  Acknowledgments</span>

   We wish to thank Dan Li, Fang Liu (Christine), Zafar Ali, Monique
   Morrow, Adrian Farrel, Deborah Brungard, Lou Berger, Thomas D. Nadeau
   for their comments and help.  Lou Berger and Adrian Farrel have made
   text contributions to this document.

   We wish to thank experts from IPPM and BMWG -- Reinhard Schrage, Al
   Morton, and Henk Uijterwaal -- for reviewing this document.  Reinhard
   Schrage has made text contributions to this document.

   This document contains ideas as well as text that have appeared in
   existing IETF documents.  The authors wish to thank G. Almes, S.
   Kalidindi, and M. Zekauskas.

   We also wish to thank Weisheng Hu, Yaohui Jin, and Wei Guo in the
   state key laboratory of advanced optical communication systems and
   networks for the valuable comments.  We also wish to thank the
   support from National Natural Science Foundation of China (NSFC) and
   863 program of China.

<span class="h2"><a class="selflink" id="section-18" href="#section-18">18</a>.  References</span>

<span class="h3"><a class="selflink" id="section-18.1" href="#section-18.1">18.1</a>.  Normative References</span>

   [<a id="ref-RFC2119">RFC2119</a>]       Bradner, S., "Key words for use in RFCs to Indicate
                   Requirement Levels", <a href="https://www.rfc-editor.org/bcp/bcp14">BCP 14</a>, <a href="./rfc2119">RFC 2119</a>, March 1997.

   [<a id="ref-RFC2205">RFC2205</a>]       Braden, B., Zhang, L., Berson, S., Herzog, S., and S.
                   Jamin, "Resource ReSerVation Protocol (RSVP) --
                   Version 1 Functional Specification", <a href="./rfc2205">RFC 2205</a>,
                   September 1997.

   [<a id="ref-RFC2679">RFC2679</a>]       Almes, G., Kalidindi, S., and M. Zekauskas, "A One-
                   way Delay Metric for IPPM", <a href="./rfc2679">RFC 2679</a>, September 1999.

   [<a id="ref-RFC2681">RFC2681</a>]       Almes, G., Kalidindi, S., and M. Zekauskas, "A Round-
                   trip Delay Metric for IPPM", <a href="./rfc2681">RFC 2681</a>,
                   September 1999.




<span class="grey">Sun &amp; Zhang                  Standards Track                   [Page 41]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-42" ></span>
<span class="grey"><a href="./rfc5814">RFC 5814</a>            LSP Dynamic PPM in GMPLS Networks         March 2010</span>


   [<a id="ref-RFC3209">RFC3209</a>]       Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan,
                   V., and G. Swallow, "RSVP-TE: Extensions to RSVP for
                   LSP Tunnels", <a href="./rfc3209">RFC 3209</a>, December 2001.

   [<a id="ref-RFC3471">RFC3471</a>]       Berger, L., "Generalized Multi-Protocol Label
                   Switching (GMPLS) Signaling Functional Description",
                   <a href="./rfc3471">RFC 3471</a>, January 2003.

   [<a id="ref-RFC3473">RFC3473</a>]       Berger, L., "Generalized Multi-Protocol Label
                   Switching (GMPLS) Signaling Resource ReserVation
                   Protocol-Traffic Engineering (RSVP-TE) Extensions",
                   <a href="./rfc3473">RFC 3473</a>, January 2003.

   [<a id="ref-RFC3945">RFC3945</a>]       Mannie, E., "Generalized Multi-Protocol Label
                   Switching (GMPLS) Architecture", <a href="./rfc3945">RFC 3945</a>,
                   October 2004.

   [<a id="ref-RFC4208">RFC4208</a>]       Swallow, G., Drake, J., Ishimatsu, H., and Y.
                   Rekhter, "Generalized Multiprotocol Label Switching
                   (GMPLS) User-Network Interface (UNI): Resource
                   ReserVation Protocol-Traffic Engineering (RSVP-TE)
                   Support for the Overlay Model", <a href="./rfc4208">RFC 4208</a>,
                   October 2005.

<span class="h3"><a class="selflink" id="section-18.2" href="#section-18.2">18.2</a>.  Informative References</span>

   [<a id="ref-CCAMP-DPM">CCAMP-DPM</a>]     Sun, W., Zhang, G., Gao, J., Xie, G., Papneja, R.,
                   Gu, B., Wei, X., Otani, T., and R. Jing, "Label
                   Switched Path (LSP) Data Path Delay Metric in
                   Generalized MPLS/ MPLS-TE Networks", Work
                   in Progress, December 2009.

   [<a id="ref-CCAMP-SWITCH">CCAMP-SWITCH</a>]  Shiomoto, K. and A. Farrel, "Advice on When It is
                   Safe to Start Sending Data on Label Switched Paths
                   Established Using RSVP-TE", Work in Progress,
                   October 2009.

   [<a id="ref-RFC2330">RFC2330</a>]       Paxson, V., Almes, G., Mahdavi, J., and M. Mathis,
                   "Framework for IP Performance Metrics", <a href="./rfc2330">RFC 2330</a>,
                   May 1998.

   [<a id="ref-RFC3410">RFC3410</a>]       Case, J., Mundy, R., Partain, D., and B. Stewart,
                   "Introduction and Applicability Statements for
                   Internet-Standard Management Framework", <a href="./rfc3410">RFC 3410</a>,
                   December 2002.






<span class="grey">Sun &amp; Zhang                  Standards Track                   [Page 42]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-43" ></span>
<span class="grey"><a href="./rfc5814">RFC 5814</a>            LSP Dynamic PPM in GMPLS Networks         March 2010</span>


<span class="h2"><a class="selflink" id="appendix-A" href="#appendix-A">Appendix A</a>.  Authors' Addresses</span>

   Jianhua Gao
   Huawei Technologies Co., LTD.
   China

   Phone: +86 755 28973237
   EMail: gjhhit@huawei.com


   Guowu Xie
   University of California, Riverside
   900 University Ave.
   Riverside, CA 92521
   USA

   Phone: +1 951 237 8825
   EMail: xieg@cs.ucr.edu


   Rajiv Papneja
   Isocore
   12359 Sunrise Valley Drive, STE 100
   Reston, VA  20190
   USA

   Phone: +1 703 860 9273
   EMail: rpapneja@isocore.com

   Bin Gu
   IXIA
   Oriental Kenzo Plaza 8M, 48 Dongzhimen Wai Street, Dongcheng District
   Beijing  200240
   China

   Phone: +86 13611590766
   EMail: BGu@ixiacom.com


   Xueqin Wei
   Fiberhome Telecommunication Technology Co., Ltd.
   Wuhan
   China

   Phone: +86 13871127882
   EMail: xqwei@fiberhome.com.cn





<span class="grey">Sun &amp; Zhang                  Standards Track                   [Page 43]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-44" ></span>
<span class="grey"><a href="./rfc5814">RFC 5814</a>            LSP Dynamic PPM in GMPLS Networks         March 2010</span>


   Tomohiro Otani
   KDDI R&amp;D Laboratories, Inc.
   2-1-15 Ohara Kamifukuoka Saitama
   356-8502
   Japan

   Phone: +81-49-278-7357
   EMail: otani@kddilabs.jp


   Ruiquan Jing
   China Telecom Beijing Research Institute
   118 Xizhimenwai Avenue
   Beijing  100035
   China

   Phone: +86-10-58552000
   EMail: jingrq@ctbri.com.cn

Editors' Addresses

   Weiqiang Sun (editor)
   Shanghai Jiao Tong University
   800 Dongchuan Road
   Shanghai  200240
   China

   Phone: +86 21 3420 5359
   EMail: sunwq@mit.edu


   Guoying Zhang (editor)
   China Academy of Telecommunication Research, MIIT, China.
   No.52 Hua Yuan Bei Lu,Haidian District
   Beijing  100083
   China

   Phone: +86 1062300103
   EMail: zhangguoying@mail.ritt.com.cn












Sun &amp; Zhang                  Standards Track                   [Page 44]
</pre>