    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

       Label Switched Path (LSP) Dynamic Provisioning Performance Metrics
                          in Generalized MPLS Networks

    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 Section 2 of RFC 5741.

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

    Sun & Zhang                  Standards Track                    [Page 1]

    RFC 5814            LSP Dynamic PPM in GMPLS Networks         March 2010

    Copyright Notice

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

       This document is subject to BCP 78 and the IETF Trust's Legal
       Provisions Relating to IETF Documents
       (http://trustee.ietf.org/license-info) in effect on the date of
       publication of this document.  Please review these documents
       carefully, as they describe your rights and restrictions with respect
       to this document.  Code Components extracted from this document must
       include Simplified BSD License text as described in Section 4.e of
       the Trust Legal Provisions and are provided without warranty as
       described in the Simplified BSD License.

       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.

    Sun & Zhang                  Standards Track                    [Page 2]

    RFC 5814            LSP Dynamic PPM in GMPLS Networks         March 2010

    Table of Contents

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

    Sun & Zhang                  Standards Track                    [Page 3]

    RFC 5814            LSP Dynamic PPM in GMPLS Networks         March 2010

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

    Sun & Zhang                  Standards Track                    [Page 4]

    RFC 5814            LSP Dynamic PPM in GMPLS Networks         March 2010

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

    Sun & Zhang                  Standards Track                    [Page 5]

    RFC 5814            LSP Dynamic PPM in GMPLS Networks         March 2010

    1.  Introduction

       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.

    2.  Conventions Used in This Document

       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 [RFC2119].

    3.  Overview of Performance Metrics

       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, [RFC2330] [RFC2679] [RFC2681].  The reader is
       assumed to be familiar with the notions in those documents.

    Sun & Zhang                  Standards Track                    [Page 6]

    RFC 5814            LSP Dynamic PPM in GMPLS Networks         March 2010

       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 [CCAMP-DPM].  It is desirable that both measurements are
       performed to complement each other.

    4.  A Singleton Definition for Single Unidirectional LSP Setup Delay

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

    4.1.  Motivation

       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.

    4.2.  Metric Name

       Single unidirectional LSP setup delay

    Sun & Zhang                  Standards Track                    [Page 7]

    RFC 5814            LSP Dynamic PPM in GMPLS Networks         March 2010

    4.3.  Metric Parameters

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

       o  ID1, the egress LSR ID

       o  T, a time when the setup is attempted

    4.4.  Metric Units

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

    4.5.  Definition

       The single unidirectional LSP setup delay from ingress node ID0 to
       egress node ID1 [RFC3945] 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
       Section 14.5 for definitions of LSP setup/release failures.

    4.6.  Discussion

       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

    Sun & Zhang                  Standards Track                    [Page 8]

    RFC 5814            LSP Dynamic PPM in GMPLS Networks         March 2010

          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.

    4.7.  Methodologies

       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.

    4.8.  Metric Reporting

       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

    Sun & Zhang                  Standards Track                    [Page 9]

    RFC 5814            LSP Dynamic PPM in GMPLS Networks         March 2010

       use of the record route object, see [RFC3209], or via the management
       plane.  The collection of routes via the management plane is out of
       scope of this document.

    5.  A Singleton Definition for Multiple Unidirectional LSPs Setup Delay

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

    5.1.  Motivation

       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.

    5.2.  Metric Name

       Multiple unidirectional LSPs setup delay

    5.3.  Metric Parameters

       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

    5.4.  Metric Units

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

    Sun & Zhang                  Standards Track                   [Page 10]

    RFC 5814            LSP Dynamic PPM in GMPLS Networks         March 2010

    5.5.  Definition

       Given Lambda_m and X, the multiple unidirectional LSPs setup delay
       from the ingress node to the egress node [RFC3945] 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
       Section 14.5 for definitions of LSP setup/release failures.

    5.6.  Discussion

       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

    Sun & Zhang                  Standards Track                   [Page 11]

    RFC 5814            LSP Dynamic PPM in GMPLS Networks         March 2010

          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.

    5.7.  Methodologies

       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.

    Sun & Zhang                  Standards Track                   [Page 12]

    RFC 5814            LSP Dynamic PPM in GMPLS Networks         March 2010

       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.

    5.8.  Metric Reporting

       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 [RFC3209], or via the management
       plane.  The collection of routes via the management plane is out of
       scope of this document.

    6.  A Singleton Definition for Single Bidirectional LSP Setup Delay

       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.

    6.1.  Motivation

       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

    Sun & Zhang                  Standards Track                   [Page 13]

    RFC 5814            LSP Dynamic PPM in GMPLS Networks         March 2010

          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.

    6.2.  Metric Name

       Single bidirectional LSP setup delay

    6.3.  Metric Parameters

       o  ID0, the ingress LSR ID

       o  ID1, the egress LSR ID

       o  T, a time when the setup is attempted

    6.4.  Metric Units

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

    6.5.  Definition

       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 [RFC3473] 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.

    Sun & Zhang                  Standards Track                   [Page 14]

    RFC 5814            LSP Dynamic PPM in GMPLS Networks         March 2010

       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
       Section 14.5 for definitions of LSP setup/release failures.

    6.6.  Discussion

       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.

    6.7.  Methodologies

       Generally, the methodology would proceed as follows:

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

    Sun & Zhang                  Standards Track                   [Page 15]

    RFC 5814            LSP Dynamic PPM in GMPLS Networks         March 2010

       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.

    6.8.  Metric Reporting

       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 [RFC3209], or via the management
       plane.  The collection of routes via the management plane is out of
       scope of this document.

    7.  A Singleton Definition for Multiple Bidirectional LSPs Setup Delay

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

    7.1.  Motivation

       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.

    7.2.  Metric Name

       Multiple bidirectional LSPs setup delay

    Sun & Zhang                  Standards Track                   [Page 16]

    RFC 5814            LSP Dynamic PPM in GMPLS Networks         March 2010

    7.3.  Metric Parameters

       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

    7.4.  Metric Units

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

    7.5.  Definition

       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
       Section 14.5 for definitions of LSP setup/release failures.

    Sun & Zhang                  Standards Track                   [Page 17]

    RFC 5814            LSP Dynamic PPM in GMPLS Networks         March 2010

    7.6.  Discussion

       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.

    Sun & Zhang                  Standards Track                   [Page 18]

    RFC 5814            LSP Dynamic PPM in GMPLS Networks         March 2010

    7.7.  Methodologies

       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.

    7.8.  Metric Reporting

       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 [RFC3209], or via the management
       plane.  The collection of routes via the management plane is out of
       scope of this document.

    Sun & Zhang                  Standards Track                   [Page 19]

    RFC 5814            LSP Dynamic PPM in GMPLS Networks         March 2010

    8.  A Singleton Definition for LSP Graceful Release Delay

       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.

    8.1.  Motivation

       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 [RFC4208].

    8.2.  Metric Name

       LSP graceful release delay

    8.3.  Metric Parameters

       o  ID0, the ingress LSR ID

       o  ID1, the egress LSR ID

       o  T, a time when the release is attempted

    8.4.  Metric Units

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

    8.5.  Definition

       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 [RFC3473].  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

    Sun & Zhang                  Standards Track                   [Page 20]

    RFC 5814            LSP Dynamic PPM in GMPLS Networks         March 2010

       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 Section 14.5 for definitions
       of LSP setup/release failures.

    Sun & Zhang                  Standards Track                   [Page 21]

    RFC 5814            LSP Dynamic PPM in GMPLS Networks         March 2010

    8.6.  Discussion

       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.

    8.7.  Methodologies

       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.

    Sun & Zhang                  Standards Track                   [Page 22]

    RFC 5814            LSP Dynamic PPM in GMPLS Networks         March 2010

       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.

    8.8.  Metric Reporting

       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 Section 8.5 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
       [RFC3209], or via the management plane.  The collection of routes via
       the management plane is out of scope of this document.

    Sun & Zhang                  Standards Track                   [Page 23]

    RFC 5814            LSP Dynamic PPM in GMPLS Networks         March 2010

    9.  A Definition for Samples of Single Unidirectional LSP Setup Delay

       In Section 4, 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 [RFC2330], we use Poisson
       sampling as an example.

    9.1.  Metric Name

       Single unidirectional LSP setup delay sample

    9.2.  Metric Parameters

       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

    9.3.  Metric Units

       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

    9.4.  Definition

       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 <time, LSP setup delay> pairs.  If there are no such pairs,
       the sequence is of length zero and the sample is said to be empty.

    Sun & Zhang                  Standards Track                   [Page 24]

    RFC 5814            LSP Dynamic PPM in GMPLS Networks         March 2010

    9.5.  Discussion

       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.

    9.6.  Methodologies

       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.

    Sun & Zhang                  Standards Track                   [Page 25]

    RFC 5814            LSP Dynamic PPM in GMPLS Networks         March 2010

    9.7.  Typical Testing Cases

    9.7.1.  With No LSP in the Network

    9.7.1.1.  Motivation

       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.

    9.7.1.2.  Methodologies

       Make sure that there is no LSP in the network and proceed with the
       methodologies described in Section 9.6

    9.7.2.  With a Number of LSPs in the Network

    9.7.2.1.  Motivation

       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.

    9.7.2.2.  Methodologies

       Set up the required number of LSPs, and wait until the network
       reaches a stable state; then, proceed with the methodologies
       described in Section 9.6.

    9.8.  Metric Reporting

       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.

    10.  A Definition for Samples of Multiple Unidirectional LSPs Setup
         Delay

       In Section 5, 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.

    Sun & Zhang                  Standards Track                   [Page 26]

    RFC 5814            LSP Dynamic PPM in GMPLS Networks         March 2010

       Sampling means to take a number of distinct instances of a skeleton
       metric under a given set of parameters.  As in [RFC2330], we use
       Poisson sampling as an example.

    10.1.  Metric Name

       Multiple unidirectional LSPs setup delay sample

    10.2.  Metric Parameters

       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

    10.3.  Metric Units

       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

    10.4.  Definition

       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 <time, setup delay> pairs.  If there are no such
       pairs, the sequence is of length zero and the sample is said to be
       empty.

    Sun & Zhang                  Standards Track                   [Page 27]

    RFC 5814            LSP Dynamic PPM in GMPLS Networks         March 2010

    10.5.  Discussion

       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 Section 5

       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.

    10.6.  Methodologies

       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.

    Sun & Zhang                  Standards Track                   [Page 28]

    RFC 5814            LSP Dynamic PPM in GMPLS Networks         March 2010

    10.7.  Typical Testing Cases

    10.7.1.  With No LSP in the Network

    10.7.1.1.  Motivation

       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.

    10.7.1.2.  Methodologies

       Make sure that there is no LSP in the network and proceed with the
       methodologies described in Section 10.6.

    10.7.2.  With a Number of LSPs in the Network

    10.7.2.1.  Motivation

       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.

    10.7.2.2.  Methodologies

       Set up the required number of LSPs, and wait until the network
       reaches a stable state; then, proceed with the methodologies
       described in Section 10.6.

    10.8.  Metric Reporting

       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.

    Sun & Zhang                  Standards Track                   [Page 29]

    RFC 5814            LSP Dynamic PPM in GMPLS Networks         March 2010

    11.  A Definition for Samples of Single Bidirectional LSP Setup Delay

       In Section 6, 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 [RFC2330], we use Poisson sampling as an
       example.

    11.1.  Metric Name

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

    11.2.  Metric Parameters

       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

    11.3.  Metric Units

       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

    11.4.  Definition

       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 <time, LSP setup delay> pairs.  If there are no such pairs,
       the sequence is of length zero and the sample is said to be empty.

    Sun & Zhang                  Standards Track                   [Page 30]

    RFC 5814            LSP Dynamic PPM in GMPLS Networks         March 2010

    11.5.  Discussion

       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.

    11.6.  Methodologies

       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.

    Sun & Zhang                  Standards Track                   [Page 31]

    RFC 5814            LSP Dynamic PPM in GMPLS Networks         March 2010

    11.7.  Typical Testing Cases

    11.7.1.  With No LSP in the Network

    11.7.1.1.  Motivation

       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.

    11.7.1.2.  Methodologies

       Make sure that there is no LSP in the network and proceed with the
       methodologies described in Section 11.6.

    11.7.2.  With a Number of LSPs in the Network

    11.7.2.1.  Motivation

       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.

    11.7.2.2.  Methodologies

       Set up the required number of LSPs and wait until the network reaches
       a stable state; then, proceed with the methodologies described in
       Section 11.6.

    11.8.  Metric Reporting

       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.

    12.  A Definition for Samples of Multiple Bidirectional LSPs Setup Delay

       In Section 7, 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.

    Sun & Zhang                  Standards Track                   [Page 32]

    RFC 5814            LSP Dynamic PPM in GMPLS Networks         March 2010

       Sampling means to take a number of distinct instances of a skeleton
       metric under a given set of parameters.  As in [RFC2330], we use
       Poisson sampling as an example.

    12.1.  Metric Name

       Multiple bidirectional LSPs setup delay sample

    12.2.  Metric Parameters

       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

    12.3.  Metric Units

       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

    12.4.  Definition

       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 <time, setup delay> pairs.  If there are no such
       pairs, the sequence is of length zero and the sample is said to be
       empty.

    Sun & Zhang                  Standards Track                   [Page 33]

    RFC 5814            LSP Dynamic PPM in GMPLS Networks         March 2010

    12.5.  Discussion

       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 Section 7.

       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.

    12.6.  Methodologies

       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.

    Sun & Zhang                  Standards Track                   [Page 34]

    RFC 5814            LSP Dynamic PPM in GMPLS Networks         March 2010

    12.7.  Typical Testing Cases

    12.7.1.  With No LSP in the Network

    12.7.1.1.  Motivation

       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.

    12.7.1.2.  Methodologies

       Make sure that there is no LSP in the network and proceed with the
       methodologies described in Section 10.6.

    12.7.2.  With a Number of LSPs in the Network

    12.7.2.1.  Motivation

       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.

    12.7.2.2.  Methodologies

       Set up the required number of LSPs, and wait until the network
       reaches a stable state; then, proceed with the methodologies
       described in Section 12.6.

    12.8.  Metric Reporting

       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.

    13.  A Definition for Samples of LSP Graceful Release Delay

       In Section 8, 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.

    Sun & Zhang                  Standards Track                   [Page 35]

    RFC 5814            LSP Dynamic PPM in GMPLS Networks         March 2010

    13.1.  Metric Name

       LSP graceful release delay sample

    13.2.  Metric Parameters

       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

    13.3.  Metric Units

       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

    13.4.  Definition

       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 <time, LSP graceful delay> pairs.  If there are no such
       pairs, the sequence is of length zero and the sample is said to be
       empty.

    13.5.  Discussion

       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.

    Sun & Zhang                  Standards Track                   [Page 36]

    RFC 5814            LSP Dynamic PPM in GMPLS Networks         March 2010

       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.

    13.6.  Methodologies

       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.

    13.7.  Metric Reporting

       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.

    14.  Some Statistics Definitions for Metrics to Report

       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.

    14.1.  The Minimum of Metric

       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.

    14.2.  The Median of Metric

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

    Sun & Zhang                  Standards Track                   [Page 37]

    RFC 5814            LSP Dynamic PPM in GMPLS Networks         March 2010

    14.3.  The Maximum of Metric

       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.

    14.4.  The Percentile of Metric

       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 <= x.

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

       See [RFC2330] for further details.

    14.5.  Failure Statistics of Metric

       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.

    Sun & Zhang                  Standards Track                   [Page 38]

    RFC 5814            LSP Dynamic PPM in GMPLS Networks         March 2010

    14.5.1.  Failure Count

       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.

    14.5.2.  Failure Ratio

       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%.

    15.  Discussion

       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 [RFC3209], [RFC3471],
          and [RFC3473].  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 [CCAMP-SWITCH] 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 [CCAMP-DPM], 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 [CCAMP-DPM] are performed to
          complement each other.

    Sun & Zhang                  Standards Track                   [Page 39]

    RFC 5814            LSP Dynamic PPM in GMPLS Networks         March 2010

       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.

    16.  Security Considerations

       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

    Sun & Zhang                  Standards Track                   [Page 40]

    RFC 5814            LSP Dynamic PPM in GMPLS Networks         March 2010

       security features as provided by the SNMPv3 framework (see [RFC3410],
       section 8), including full support for the SNMPv3 cryptographic
       mechanisms (for authentication and privacy).

       Additionally, the security considerations pertaining to the original
       RSVP protocol [RFC2205] and its TE extensions [RFC3209] also remain
       relevant.

    17.  Acknowledgments

       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.

    18.  References

    18.1.  Normative References

       [RFC2119]       Bradner, S., "Key words for use in RFCs to Indicate
                       Requirement Levels", BCP 14, RFC 2119, March 1997.

       [RFC2205]       Braden, B., Zhang, L., Berson, S., Herzog, S., and S.
                       Jamin, "Resource ReSerVation Protocol (RSVP) --
                       Version 1 Functional Specification", RFC 2205,
                       September 1997.

       [RFC2679]       Almes, G., Kalidindi, S., and M. Zekauskas, "A One-
                       way Delay Metric for IPPM", RFC 2679, September 1999.

       [RFC2681]       Almes, G., Kalidindi, S., and M. Zekauskas, "A Round-
                       trip Delay Metric for IPPM", RFC 2681,
                       September 1999.

    Sun & Zhang                  Standards Track                   [Page 41]

    RFC 5814            LSP Dynamic PPM in GMPLS Networks         March 2010

       [RFC3209]       Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan,
                       V., and G. Swallow, "RSVP-TE: Extensions to RSVP for
                       LSP Tunnels", RFC 3209, December 2001.

       [RFC3471]       Berger, L., "Generalized Multi-Protocol Label
                       Switching (GMPLS) Signaling Functional Description",
                       RFC 3471, January 2003.

       [RFC3473]       Berger, L., "Generalized Multi-Protocol Label
                       Switching (GMPLS) Signaling Resource ReserVation
                       Protocol-Traffic Engineering (RSVP-TE) Extensions",
                       RFC 3473, January 2003.

       [RFC3945]       Mannie, E., "Generalized Multi-Protocol Label
                       Switching (GMPLS) Architecture", RFC 3945,
                       October 2004.

       [RFC4208]       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", RFC 4208,
                       October 2005.

    18.2.  Informative References

       [CCAMP-DPM]     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.

       [CCAMP-SWITCH]  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.

       [RFC2330]       Paxson, V., Almes, G., Mahdavi, J., and M. Mathis,
                       "Framework for IP Performance Metrics", RFC 2330,
                       May 1998.

       [RFC3410]       Case, J., Mundy, R., Partain, D., and B. Stewart,
                       "Introduction and Applicability Statements for
                       Internet-Standard Management Framework", RFC 3410,
                       December 2002.

    Sun & Zhang                  Standards Track                   [Page 42]

    RFC 5814            LSP Dynamic PPM in GMPLS Networks         March 2010

    Appendix A.  Authors' Addresses

       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

    Sun & Zhang                  Standards Track                   [Page 43]

    RFC 5814            LSP Dynamic PPM in GMPLS Networks         March 2010

       Tomohiro Otani
       KDDI R&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 & Zhang                  Standards Track                   [Page 44]