Network Working Group                                             W. Sun
Internet-Draft                                                      SJTU
Intended status: Standards Track                                G. Zhang
Expires: October 12, December 26, 2008                                          CATR
                                                                  J. Gao
                                                                  Huawei
                                                                  G. Xie
                                                                    SJTU

                                                          April 10,

                                                           June 24, 2008

 Label Switched Path (LSP) Dynamic Provisioning Performance Metrics in
                       Generalized MPLS Networks
                    draft-ietf-ccamp-lsp-dppm-01.txt
                    draft-ietf-ccamp-lsp-dppm-02.txt

Status of this Memo

   By submitting this Internet-Draft, each author represents that any
   applicable patent or other IPR claims of which he or she is aware
   have been or will be disclosed, and any of which he or she becomes
   aware will be disclosed, in accordance with Section 6 of BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF), its areas, and its working groups.  Note that
   other groups may also distribute working documents as Internet-
   Drafts.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   The list of current Internet-Drafts can be accessed at
   http://www.ietf.org/ietf/1id-abstracts.txt.

   The list of Internet-Draft Shadow Directories can be accessed at
   http://www.ietf.org/shadow.html.

   This Internet-Draft will expire on October 12, December 16, 2008.

Abstract

   Generalized Multi-Protocol Label Switching (GMPLS) is one of the most
   promising candidate technologies for 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
   Multiplexors (ADMs), photonic cross-connects (PXCs), optical cross-
   connects (OXCs), etc.  Dynamic provisioning ability of these
   physically diverse devices differs from each other drastically.  At
   the same time, the need for Dynamicly 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 LSP provisioning performance in GMPLS networks,
   specifically the Dynamic LSP setup/release performance.  These
   metrics can depict the features of GMPLS networks in LSP dynamic
   provisioning.  They can also be used in operational networks for
   carriers to monitor the control plane performance in realtime.

Table of Contents

   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  5  7
   2.  Overview of Performance Metrics  . . . . . . . . . . . . . . .  6  8
   3.  A Singleton Definition for Single Unidirectional LSP Setup
       Delay  . . . . . . . . . . . . . . . . . . . . . . . . . . . .  7  9
     3.1.  Motivation . . . . . . . . . . . . . . . . . . . . . . . .  7  9
     3.2.  Metric Name  . . . . . . . . . . . . . . . . . . . . . . .  7  9
     3.3.  Metric Parameters  . . . . . . . . . . . . . . . . . . . .  7  9
     3.4.  Metric Units . . . . . . . . . . . . . . . . . . . . . . .  8 10
     3.5.  Definition . . . . . . . . . . . . . . . . . . . . . . . .  8 10
     3.6.  Discussion . . . . . . . . . . . . . . . . . . . . . . . .  8 10
     3.7.  Methodologies  . . . . . . . . . . . . . . . . . . . . . .  9 11
   4.  A Singleton Definition for multiple Unidirectional LSP
       Setup Delay  . . . . . . . . . . . . . . . . . . . . . . . . . 10 12
     4.1.  Motivation . . . . . . . . . . . . . . . . . . . . . . . . 10 12
     4.2.  Metric Name  . . . . . . . . . . . . . . . . . . . . . . . 10 12
     4.3.  Metric Parameters  . . . . . . . . . . . . . . . . . . . . 10 12
     4.4.  Metric Units . . . . . . . . . . . . . . . . . . . . . . . 10 12
     4.5.  Definition . . . . . . . . . . . . . . . . . . . . . . . . 10 12
     4.6.  Discussion . . . . . . . . . . . . . . . . . . . . . . . . 11 13
     4.7.  Methodologies  . . . . . . . . . . . . . . . . . . . . . . 12 14
   5.  A Singleton Definition for Single Bidirectional LSP Setup
       Delay  . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13 15
     5.1.  Motivation . . . . . . . . . . . . . . . . . . . . . . . . 13 15
     5.2.  Metric Name  . . . . . . . . . . . . . . . . . . . . . . . 13 15
     5.3.  Metric Parameters  . . . . . . . . . . . . . . . . . . . . 13 15
     5.4.  Metric Units . . . . . . . . . . . . . . . . . . . . . . . 14 16
     5.5.  Definition . . . . . . . . . . . . . . . . . . . . . . . . 14 16
     5.6.  Discussion . . . . . . . . . . . . . . . . . . . . . . . . 14 16
     5.7.  Methodologies  . . . . . . . . . . . . . . . . . . . . . . 15 17
   6.  A Singleton Definition for multiple Bidirectional LSPs
       Setup Delay  . . . . . . . . . . . . . . . . . . . . . . . . . 16 18
     6.1.  Motivation . . . . . . . . . . . . . . . . . . . . . . . . 16 18
     6.2.  Metric Name  . . . . . . . . . . . . . . . . . . . . . . . 16 18
     6.3.  Metric Parameters  . . . . . . . . . . . . . . . . . . . . 16 18
     6.4.  Metric Units . . . . . . . . . . . . . . . . . . . . . . . 16 18
     6.5.  Definition . . . . . . . . . . . . . . . . . . . . . . . . 16 18
     6.6.  Discussion . . . . . . . . . . . . . . . . . . . . . . . . 17 19
     6.7.  Methodologies  . . . . . . . . . . . . . . . . . . . . . . 18 20
   7.  A Singleton Definition for LSP Graceful Release Delay  . . . . 19 21
     7.1.  Motivation . . . . . . . . . . . . . . . . . . . . . . . . 19 21
     7.2.  Metric Name  . . . . . . . . . . . . . . . . . . . . . . . 19 21
     7.3.  Metric Parameters  . . . . . . . . . . . . . . . . . . . . 19 21
     7.4.  Metric Units . . . . . . . . . . . . . . . . . . . . . . . 19 21
     7.5.  Definition . . . . . . . . . . . . . . . . . . . . . . . . 19 21
     7.6.  Discussion . . . . . . . . . . . . . . . . . . . . . . . . 20 22
     7.7.  Methodologies  . . . . . . . . . . . . . . . . . . . . . . 21 23
   8.  Typical Testing Cases  A Definition for Samples of Single Unidirectional LSP
       Setup Delay  . . . . . . . . . . . . . . . . . . . . . . . . . 25
     8.1.  Metric Name  . . . 23
     8.1.  With No LSP in the Network . . . . . . . . . . . . . . . . 23
       8.1.1.  Motivation . . . . 25
     8.2.  Metric Parameters  . . . . . . . . . . . . . . . . . . 23
       8.1.2.  Methodologies . . 25
     8.3.  Metric Units . . . . . . . . . . . . . . . . . . 23
     8.2.  With a Number of LSPs in the Network . . . . . 25
     8.4.  Definition . . . . . . 23
       8.2.1.  Motivation . . . . . . . . . . . . . . . . . . 25
     8.5.  Discussion . . . . 23
       8.2.2.  Methodologies . . . . . . . . . . . . . . . . . . . . 23
   9.  Typical Testing Cases of multiple Unidirectional LSPs
       Setup Delay 26
     8.6.  Methodologies  . . . . . . . . . . . . . . . . . . . . . . 26
     8.7.  Typical testing cases  . . . 25
     9.1.  With No LSP in the Network . . . . . . . . . . . . . . . 26
       8.7.1.  With No LSP in the Network . 25
       9.1.1.  Motivation . . . . . . . . . . . . . 27
       8.7.2.  With a Number of LSPs in the Network . . . . . . . . . 25
       9.1.2.  Methodologies 27
   9.  A Definition for Samples of Multiple Unidirectional LSPs
       Setup Delay  . . . . . . . . . . . . . . . . . . . . 25
     9.2.  With a Number of LSPs in the Network . . . . . 28
     9.1.  Metric Name  . . . . . . 25
       9.2.1.  Motivation . . . . . . . . . . . . . . . . . 28
     9.2.  Metric Parameters  . . . . . 25
       9.2.2.  Methodologies . . . . . . . . . . . . . . . 28
     9.3.  Metric Units . . . . . 25
   10. Typical Testing Cases of Single Bidirectional LSP Setup
       Delay . . . . . . . . . . . . . . . . . . 28
     9.4.  Definition . . . . . . . . . . 27
     10.1. With No LSP in the Network . . . . . . . . . . . . . . 28
     9.5.  Discussion . . 27
       10.1.1. Motivation . . . . . . . . . . . . . . . . . . . . . . 27
       10.1.2. 29
     9.6.  Methodologies  . . . . . . . . . . . . . . . . . . . . 27
     10.2. With a Number of LSPs in the Network . . . . 29
     9.7.  Typical testing cases  . . . . . . . 27
       10.2.1. Motivation . . . . . . . . . . . 29
       9.7.1.  With No LSP in the Network . . . . . . . . . . . 27
       10.2.2. Methodologies . . . 29
       9.7.2.  With a Number of LSPs in the Network . . . . . . . . . 30
   10. A Definition for Samples of Single Bidirectional LSP Setup
       Delay  . . . . . . . . 27
   11. Typical Testing Cases of multiple Bidirectional LSPs Setup
       Delay . . . . . . . . . . . . . . . . . . . . 31
     10.1. Metric Name  . . . . . . . . 29
     11.1. With No LSP in the Network . . . . . . . . . . . . . . . 31
     10.2. Metric Parameters  . 29
       11.1.1. Motivation . . . . . . . . . . . . . . . . . . . 31
     10.3. Metric Units . . . 29
       11.1.2. Methodologies . . . . . . . . . . . . . . . . . . . . 29
     11.2. With a Number of LSPs in the Network 31
     10.4. Definition . . . . . . . . . . . . . 29
       11.2.1. Motivation . . . . . . . . . . . 31
     10.5. Discussion . . . . . . . . . . . 29
       11.2.2. . . . . . . . . . . . . . 32
     10.6. Methodologies  . . . . . . . . . . . . . . . . . . . . 29
   12. Some Statistics Definitions for Metrics to Report . . 32
     10.7. Typical testing cases  . . . . 31
     12.1. The Minimum of Metric . . . . . . . . . . . . . . 32
       10.7.1. With No LSP in the Network . . . . 31
     12.2. The Median of Metric . . . . . . . . . . 33
       10.7.2. With a Number of LSPs in the Network . . . . . . . . . 31
     12.3. The percentile 33
   11. A Definition for Samples of Metric Multiple Bidirectional LSPs
       Setup Delay  . . . . . . . . . . . . . . . . . 31
     12.4. The Failure Probability . . . . . . . . 34
     11.1. Metric Name  . . . . . . . . . 31
   13. Discussion . . . . . . . . . . . . . . 34
     11.2. Metric Parameters  . . . . . . . . . . . . 32
   14. Security Considerations . . . . . . . . 34
     11.3. Metric Units . . . . . . . . . . . . . . . . . . 33
   15. IANA Considerations . . . . . 34
     11.4. Definition . . . . . . . . . . . . . . . . . . . . . . . . 34
   16. Acknowledgements
     11.5. Discussion . . . . . . . . . . . . . . . . . . . . . . . . 35
   17. References
     11.6. Methodologies  . . . . . . . . . . . . . . . . . . . . . . 35
     11.7. Typical testing cases  . . . . 36
     17.1. Normative References . . . . . . . . . . . . . . 35
       11.7.1. With No LSP in the Network . . . . . 36
     17.2. Informative References . . . . . . . . . 35
       11.7.2. With a Number of LSPs in the Network . . . . . . . . . 36
   Authors' Addresses
   12. A Definition for Samples of LSP Graceful Release Delay . . . . 37
     12.1. Metric Name  . . . . . . . . . . . . . . . . . . . . . . . 37
   Intellectual Property and Copyright Statements
     12.2. Metric Parameters  . . . . . . . . . . 39

1.  Introduction

   Generalized Multi-Protocol Label Switching (GMPLS) is one . . . . . . . . . . 37
     12.3. Metric Units . . . . . . . . . . . . . . . . . . . . . . . 37
     12.4. Definition . . . . . . . . . . . . . . . . . . . . . . . . 37
     12.5. Discussion . . . . . . . . . . . . . . . . . . . . . . . . 37
     12.6. Methodologies  . . . . . . . . . . . . . . . . . . . . . . 38
   13. Discussion for unsuccessful setup/release cases  . . . . . . . 39
   14. Some Statistics Definitions for Metrics to Report  . . . . . . 40
     14.1. The Minimum of Metric  . . . . . . . . . . . . . . . . . . 40
     14.2. The Median of Metric . . . . . . . . . . . . . . . . . . . 40
     14.3. The percentile of Metric . . . . . . . . . . . . . . . . . 40
     14.4. The Failure Probability  . . . . . . . . . . . . . . . . . 40
   15. Discussion . . . . . . . . . . . . . . . . . . . . . . . . . . 41
   16. Security Considerations  . . . . . . . . . . . . . . . . . . . 42
   17. IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 43
   18. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 44
   19. References . . . . . . . . . . . . . . . . . . . . . . . . . . 45
     19.1. Normative References . . . . . . . . . . . . . . . . . . . 45
     19.2. Informative References . . . . . . . . . . . . . . . . . . 45
   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 46
   Intellectual Property and Copyright Statements . . . . . . . . . . 48

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.  Dynamic provisioning ability of these
   physically diverse devices differs from each other drastically.

   The introduction of a control plane into optical circuit switching
   networks automates the provisioning of connections and drastically
   reduces connection provision delay.  As more and more services and
   applications are seeking to use GMPLS controled 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 draft defines performance metrics and methodologies that can be
   used to depict the dynamic LSP provisioning performance of GMPLS
   networks, more specifically, performance of the signaling protocol.
   The metrics defined in this document can in the one hand be used to
   depict the averaged performance of GMPLS implementations.  On the
   other hand, it can also be used in operational environments for
   carriers to monitor the control plane operation in realtime.  For
   example, an new object can be added to GMPLS TE STD MIB [RFC4802]
   such that the current and past control plane performance can be
   monitored through network management systems.  The extension of TE-
   MIB to support the metrics defined is out the scope of this document.

2.  Overview of Performance Metrics

   In this memo, to depict the dynamic LSP provisioning performance of a
   GMPLS network, we define 3 performance metrics: unidirectional LSP
   setup delay, bidirectional LSP setup delay, and LSP graceful release
   delay.  The latency of the LSP setup/release signal is similar to the
   Round-trip Delay in IP networks.  So we refer the structures and
   notions introduced and discussed in the IPPM Framework document,
   [RFC2330] [RFC2679] [RFC2681].  The reader is assumed to be familiar
   with the notions in those documents.

3.  A Singleton Definition for Single Unidirectional LSP Setup Delay

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

3.1.  Motivation

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

   o  Single LSP setup delay is an important metric that depicts 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.

   o  The minimum value of this metric provides an indication of the
      delay that will likely be experienced when the LSP traversed 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 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  LSP setup delay variance has different impact on to applications.
      Erratic variation in LSP setup delay makes it difficult to support
      applications that has stringent setup delay requirement.

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

   o  Some applications may only use unidirectional LSPs rather than
      bidirectional ones.  For example, content delivery services in
      multicast method (IPTV) only use unidirectional LSPs.

3.2.  Metric Name

   single unidirectional LSP setup delay

3.3.  Metric Parameters

   o  ID0, the ingress LSR ID

   o  ID1, the egress LSR ID
   o  T, a time when the setup is attempted

3.4.  Metric Units

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

3.5.  Definition

   The single unidirectional LSP setup delay from the ingress node ID0
   to the 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 the ingress node ID0 received the last bit
   of responding RESV message packet from the egress node ID1 at wire-
   time T+dT in the unidirectional LSP setup case.

   The single unidirectional LSP setup delay from the ingress node ID0
   to the 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.

3.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 could be used.  But GMPLS networks may
      accommodate many kinds of devices.  For example, some photonic
      cross-connects (PXCs) have to move the micro mirrors.  This
      physical motion may take several milliseconds.  But the common
      electronic switches finish the nodal process within several
      microseconds.  So the unidirectional LSP setup delay varies
      drastically from a network to another.  In practice, the upper
      bound should be chose carefully.

   o  If ingress node sends out the PATH message to set up LSP, but
      never receive corresponding RESV message, unidirectional LSP setup
      delay is deemed to be undefined.

   o  If ingress node sends out the PATH message to set up LSP but
      receive PathErr message, unidirectional LSP setup delay is also
      deemed to be undefined.  There are many possible reasons for this
      case.  For example, the PATH message has invalid parameters or the
      network has not enough resource to set up the requested LSP, etc.

3.7.  Methodologies

   Generally the methodology would proceed as follows:

   o  Make sure that the network has enough resource 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 in 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 message is PathErr, the
      unidirectional LSP setup delay is deemed to be undefined.

4.  A Singleton Definition for multiple Unidirectional LSP Setup Delay

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

4.1.  Motivation

   multiple unidirectional Label Switched Paths 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 setup a large number of LSPs during a short
      time period can not be deduced by single LSP setup delay

4.2.  Metric Name

   multiple unidirectional LSPs setup delay

4.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 setup

   o  T, a time when the first setup is attempted

4.4.  Metric Units

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

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

   The multiple unidirectional LSPs setup delay at T is undefined, means
   that ingress node ID0 sends all the PATH messages toward the egress
   node ID1 and the first bit of the first PATH message packet is sent
   at wire-time T and that ingress node ID0 does not receive the one or
   more of the corresponding RESV messages within a reasonable period of
   time.

4.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 could be used.  But GMPLS networks may
      accommodate many kinds of devices.  For example, some photonic
      cross-connects (PXCs) have to move the micro mirrors.  This
      physical motion may take several milliseconds.  But the common
      electronic switches finish the nodal process within several
      microseconds.  So the multiple unidirectional LSP setup delay
      varies drastically from a network to another.  In practice, the
      upper bound should be chose carefully.

   o  If 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 is deemed to be
      undefined.

   o  If ingress node sends out the PATH messages to set up the LSPs but
      receives one or more PathErr messages, multiple unidirectional
      LSPs setup delay is also deemed to be undefined.  There are many
      possible reasons for this case.  For example, one of the most
   promising control plane solutions for future transport and service
   network.  GMPLS PATH
      messages has been developed to control and operate different
   kinds of invalid parameters or the 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), has not enough
      resource to set up the requested LSPs, etc.  Dynamic provisioning ability of these
   physically diverse devices differs from each other drastically.

   o  The introduction arrival rate of a control plane into optical circuit switching
   networks automates the provisioning of connections and drastically
   reduces connection provision delay.  As more and more services and
   applications are seeking to use GMPLS controled networks as their
   underlying transport network, and increasingly poisson process Lambda_m should be
      carefully chosen such that in a dynamic way, the
   need one hand the control plane is growing for measuring and characterizing
      not overburdened.On the performance other hand, the arrival rate should also
      be large enough to meet the requirements of
   LSP provisioning in GMPLS networks, such that requirement from applications and or
      services.

4.7.  Methodologies

   Generally the provisioning capability of methodology would proceed as follows:

   o  Make sure that the network can be
   mapped has enough resource to each other.

   This draft defines performance metrics and methodologies that can be
   used set up the
      requested LSPs.

   o  At the ingress node, form the PATH messages according to depict the dynamic connection provisioning performance LSPs'
      requirements.

   o  At the ingress node, select the time for each of
   GMPLS networks.  The metrics defined in this document can in the one
   hand be used PATH messages
      according to depict the averaged performance of GMPLS
   implementations.  On specified poisson process.

   o  At the other hand, it can also be used in
   operational environments for carriers ingress node, sends out the PATH messages according to monitor the control plane
   operation
      selected time.

   o  Store a timestamp (T1) locally in realtime.  For example, extensions can be made to GMPLS
   TE STD MIB [RFC4802] such that the current and past control plane
   performance can be monitored through network management systems.  The
   extension of TE-MIB to support ingress node when the metrics defined first
      PATH message packet is out sent towards the scope egress node.

   o  If all of this document.

2.  Overview the corresponding RESV messages arrives within a
      reasonable period of Performance Metrics

   In this document, to depict time, take the dynamic LSP provisioning performance final timestamp (T2) as soon
      as possible upon the receipt of a GMPLS network, we define 5 performance metrics: single/multiple all the messages.  By subtracting
      the two timestamps, an estimate of multiple unidirectional LSP(s) setup delay, single/multiple bidirectional
   LSP(s) LSPs
      setup delay, and LSP graceful release delay.  The latency delay (T2 -T1) can be computed.

   o  If one or more of the LSP setup/release signal is similar corresponding RESV messages fails to arrive
      within a reasonable period of time, the Round-trip Delay in IP
   networks.  So we refer the structures and notions introduced and
   discussed in the IPPM Framework document, [RFC2330] [RFC2679]
   [RFC2681].  The reader multiple unidirectional
      LSPs setup delay is assumed to be familiar with the notions in
   those documents.

   We further define typical testing cases deemed to obtain samples of be undefined.  Note that the
   defined metrics, namely, when there
      'reasonable' threshold is no LSP in the network, or
   there are a fixed number parameter of LSPs in the network.

3. methodology.

   o  If one of the corresponding response message is PathErr, the
      multiple unidirectional LSPs setup delay is deemed to be
      undefined.

5.  A Singleton Definition for Single Unidirectional Bidirectional LSP Setup Delay

   GMPLS allows establishment of bi-directional symmetric LSPs (not of
   asymmetric LSPs).  This part defines a metric for single unidirectional Label Switched
   Path
   bidirectional LSP setup delay across a GMPLS network.

3.1.

5.1.  Motivation

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

   o  Single  LSP setup delay is an important metric that depicts 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
      applications scheduling.

   o  The minimum value of this metric provides an indication of the
      delay that will likely be experienced when the LSP traversed 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 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  LSP setup delay variance has different impact on to applications.
      Erratic variation in LSP setup delay makes it difficult to support
      applications that has stringent setup delay requirement.

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

   o  Some applications may only use unidirectional  Bidirectional LSPs rather than
      bidirectional ones.  For example, content delivery services in
      multicast method (IPTV) only use unidirectional LSPs.

3.2. are seen as a requirement for many GMPLS
      networks.  Its provisioning performance is important to
      applications that generates bi-directional traffic.

5.2.  Metric Name

   single unidirectional

   Single bidirectional LSP setup delay

3.3.

5.3.  Metric Parameters
   o  ID0, the ingress LSR ID

   o  ID1, the egress LSR ID

   o  T, a time

3.4. when the setup is attempted

5.4.  Metric Units

   The value of single unidirectional bidirectional LSP setup delay is either a real
   number, or an undefined (informally, infinite) number of milliseconds.

3.5.

5.5.  Definition

   The

   For a real number dT, the single unidirectional bidirectional LSP setup delay from the
   ingress node ID0 to
   the egress node [RFC3945] ID1 at T is dT dT, means that ingress
   node ID0 sends out the first bit of a PATH message packet to 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 the ingress node received ID0
   receives the last bit of responding RESV
   message that packet from egress node at wire-time T+dT in the
   unidirectional LSP setup case. T+dT.

   The single unidirectional bidirectional LSP setup delay from the ingress node ID0 to
   the
   egress node ID1 at T is undefined (informally, infinite), 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 that response packet within a
   reasonable period of time.

3.6.

5.6.  Discussion

   The following issues are likely to come up in practice:

   o  The accuracy of unidirectional single bidirectional 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
      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 could be used.  But GMPLS networks may
      accommodate many kinds of devices.  For example, some photonic
      cross-connects (PXCs) have to move the micro mirrors.  This
      physical motion may take several milliseconds.  But the common
      electronic switches finish the nodal process within several
      microseconds.  So the unidirectional LSP bidirectional LSP setup delay varies
      drastically from a 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 varies
      drastically from a network to another.  In will also
      increase obviously.  Thus, in practice, the upper
      bound bound, should be
      chosen carefully.

   o  If the ingress node sends out the PATH message to set up the LSP,
      but never receive receives the corresponding RESV message, unidirectional single
      bidirectional LSP setup delay is deemed to be infinite. undefined.

   o  If the ingress node sends out the PATH message to set up LSP the LSP,
      but
      receive receives PathErr message, unidirectional single bidirectional LSP setup delay
      is also deemed to be infinite. undefined.  There are many possible reasons
      for this case.  For example, the PATH message has invalid
      parameters or the network has not enough resource to set up the
      requested LSP, etc.

3.7. LSP.

5.7.  Methodologies

   Generally the methodology would proceed as follows:

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

   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 in 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 unidirectional 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 unidirectional single bidirectional LSP setup
      delay is deemed to be undefined (informally, infinite). undefined.  Note that the 'reasonable'
      threshold of the unidirectional LSP setup delay is a parameter of the methodology.

   o  If the corresponding response message is PathErr, the
      unidirectional single
      bidirectional LSP setup delay is deemed to be undefined
      (informally, infinite).

4. undefined.

6.  A Singleton Definition for multiple Unidirectional LSP Bidirectional LSPs Setup Delay

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

4.1.

6.1.  Motivation

   multiple unidirectional Label Switched Paths 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 setup a large number of LSPs during a short
      time period can not be deduced by single LSP setup delay

4.2.

6.2.  Metric Name

   multiple unidirectional

   Multiple bidirectional LSPs setup delay

4.3.

6.3.  Metric Parameters

   o  ID0, the ingress LSR ID

   o  ID1, the egress LSR ID

   o  Lambda,  Lambda_m, a rate in reciprocal milliseconds

   o  X, the number of LSPs to setup

   o  T, a time

4.4. when the first setup is attempted

6.4.  Metric Units

   The value of multiple unidirectional bidirectional LSPs setup delay is either a real
   number, or an undefined (informally, infinite) number of milliseconds.

4.5.

6.5.  Definition

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

   o  ingress node ID0 sends the first bit of the first PATH message packet
      to
      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 Lambda_m

   o  ingress node ID1 receives all corresponding RESV message packets
      from egress node, node ID1, and

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

   The multiple unidirectional bidirectional LSPs setup delay from ingress node to
   egress node at T is undefined
   (informally, infinite), undefined, means that ingress node sends all the
   PATH messages toward the to egress and the first bit of the first PATH
   message packet is sent at wire-time T node and that the ingress node does not fails to
   receive the one or more of the corresponding RESV response messages within a reasonable
   period of time.

4.6.

6.6.  Discussion

   The following issues are likely to come up in practice:

   o  The accuracy of multiple unidirectional bidirectional 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
      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 could be used.  But GMPLS networks may
      accommodate many kinds of devices.  For example, some photonic
      cross-connects (PXCs) have to move the micro mirrors.  This
      physical motion may take several milliseconds.  But the common
      electronic switches finish the nodal process within several
      microseconds.  So the multiple unidirectional LSP 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 will also increase obviously.  Thus, 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 receive all the corresponding RESV messages, the unidirectional LSP
      multiple bidirectional LSPs setup delay is deemed to be
      infinite. undefined.

   o  If the ingress node sends out the PATH messages to set up the LSPs
      LSPs, but
      receives receive one or more responding PathErr messages, messages,the
      multiple unidirectional bidirectional LSPs setup delay is also deemed to be infinite.
      undefined.  There are many possible reasons for this case.  For
      example, one or more of the PATH
      message has messages have invalid parameters
      or the network has not enough resource to set up the requested LSPs, etc.
      LSPs.

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

4.7.

6.7.  Methodologies

   Generally the methodology would proceed as follows:

   o  Make sure that the network has enough resource 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, sends 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 arrives 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 bidirectional LSPs
      setup delay (T2 -T1) can be computed.

   o  If one or more of the corresponding RESV messages fails to arrive
      within a reasonable period of time, the multiple unidirectional bidirectional
      LSPs setup delay is deemed to be undefined (informally, infinite). undefined.  Note that the
      'reasonable' threshold is a parameter of the methodology.

   o  If one or more of the corresponding response message messages is PathErr,
      the multiple unidirectional bidirectional LSPs setup delay is deemed to be undefined
      (informally, infinite).

5.
      undefined.

7.  A Singleton Definition for Single Bidirectional LSP Setup Graceful Release Delay

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

5.1.  Motivation

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

   o  LSP setup delay is an important metric that depicts 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
      applications scheduling.

   o  The minimum value of this metric provides an indication

   There are two different kinds of the
      delay that will likely be experienced when the LSP traversed the
      shortest route at the lightest load release mechanisms in the control plane.  As the
      delay itself consists of several components, such as link
      propagation delay GMPLS
   networks: graceful release and nodal processing delay, this metric also
      reflects the status of control plane.  For example, for LSPs
      traversing the same route, longer setup delays may suggest
      congestion forceful release.  Memo 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 current
   version has different impact on to applications.
      Erratic variation in not taken forceful LSP setup delay makes it difficult to support
      applications that has stringent setup release procedure into account.

7.1.  Motivation

   LSP graceful release delay requirement. is useful for several reasons:

   o  The measurement of single bidirectional LSP setup graceful release delay instead is part of
   unidirectional the total cost of
      dynamic LSP setup delay is motivated by provisioning.  For some short duration applications,
      the following factors: LSP release time can not be ignored

   o  Bidirectional LSPs are seen as  The LSP graceful release procedure is more prefered in a requirement for many GMPLS
      controled network, particularly the optical networks.  Its provisioning performance  Since it
      doesn't trigger restoration/protection, it is important to
      applications that generates bi-directional traffic.

5.2. "alarm-free
      connection deletion" in [RFC4208].

7.2.  Metric Name

   Single bidirectional

   LSP setup graceful release delay

5.3.

7.3.  Metric Parameters

   o  ID0, the ingress LSR ID

   o  ID1, the egress LSR ID

   o  T, a time

5.4. when the release is attemped

7.4.  Metric Units

   The value of single bidirectional LSP setup graceful release delay is either a real number, or
   an undefined (informally, infinite) number of milliseconds.

5.5.

7.5.  Definition

   There are two different LSP graceful release procedures, one is
   initiated by the ingress node, and another is initiated by egress
   node.  The two procedures are depicted in the [RFC3473].  We define
   the graceful LSP release delay for these two procedures separately.

   For a real number dT, the single bidirectional LSP setup graceful release 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 Admin Status Object
   with setting the Reflect (R) and Delete (D) bits to egress node at
   wire-time T, that egress node ID1 receives that packet, then
   immediately sends a RESV message packet including Admin Status Object with
   the Delete (D) bit set back to ingress node, and that node.  The ingress node ID0
   sends out PathTear downstream to remove the LSP, and egress node ID1
   receives the last bit of
   that PathTear packet at wire-time T+dT.

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

   The single bidirectional LSP setup graceful release delay from ingress node ID0 to egress node
   ID1 at T is undefined (informally, infinite), undefined, means that ingress node ID0 sends the first
   bit of PATH message to egress node ID1 at wire-time T and that ingress
   (either egress node does not receive that response packet.

5.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 PATH packet, egress node
   does not send corresponding RESV message packet in the ingress node; but synchronization
      between the response, ingress
   node and does not receive that RESV packet, or) the egress node is ID1 does
   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 could be used.  But GMPLS networks may
      accommodate many kinds of devices.  For example, some photonic
      cross-connects (PXCs) have to move the micro mirrors.  This
      physical motion may take several milliseconds.  But the common
      electronic switches finish receive the nodal process PathTear within several
      microseconds.  So the bidirectional LSP setup delay varies
      drastically from a network to another.  In the process reasonable period of
      bidirectional time.

   The LSP setup, if the downstream node overrides the
      label suggested by the upstream node, the setup graceful release delay will also
      increase obviously.  Thus, in practice, the upper bound should be
      chosen carefully.

   o  If the from egress node ID1 to ingress node
   ID0 at T is dT, means that egress node ID1 sends out the PATH first bit of a
   RESV message to set up the LSP,
      but never receives including Admin Status Object with setting the corresponding RESV message, single
      bidirectional LSP setup delay is deemed Reflect
   (R) and Delete (D) bits to be infinite.

   o  If the ingress node at wire-time T. The ingress
   node ID0 sends out the PATH message PathTear downstream to set up remove the LSP,
      but and egress
   node ID1 receives PathErr message, single bidirectional the last bit of PathTear packet at wire-time T+dT.

   The LSP setup graceful release delay
      is also deemed from egress node ID1 to be infinite.  There are many possible reasons
      for this case.  For example, ingress node
   ID0 at T is undefined, means that egress node ID1 sends the PATH first bit
   of RESV message has invalid
      parameters or including Admin Status Object with setting the network has not enough resource
   Reflect (R) and Delete (D) bits to set up the
      requested LSP.

5.7.  Methodologies

   Generally the methodology would proceed as follows:

   o  Make sure ingress node ID0 at wire-time T
   and that the network has enough resource to set up the
      requested LSP.

   o  At the (either 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 in node does not receive the RESV packet,
   ingress node when the
      PATH does not send PathTear message packet is sent towards in response or)
   the egress node.

   o  If node ID1 does not receive the corresponding RESV message arrives PathTear within a reasonable
   period of time, take time.

7.6.  Discussion

   The following issues are likely to come up in practice:

   o  In the final timestamp (T2) as soon as possible
      upon first (second) circumstance, the receipt accuracy of LSP graceful
      release delay at time T depends on the message.  By subtracting clock resolution in the
      ingress (egress) node.  In the first circumstance, synchronization
      between the ingress node and egress node is required; but 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 could be used.  But the two
      timestamps, an estimate of bidirectional LSP setup delay (T2 -T1)
      can upper bound should be computed.
      chosen carefully in practice;
   o  If  In the corresponding RESV first circumstance, if ingress node sends out PATH message fails to arrive within a
      reasonable period of time,
      including Admin Status Object with the single bidirectional Reflect (R) and Delete (D)
      bits set to initiate LSP setup graceful release, but never receive
      corresponding RESV message, LSP graceful release delay is deemed
      to be undefined (informally, infinite).  Note that
      the 'reasonable' threshold is a parameter of the methodology.

   o  If undefined.  In the corresponding response second circumstance, if egress node sends
      out RESV message is PathErr, including Admin Status Object with the single
      bidirectional Reflect
      (R) and Delete (D) bits set to initiate LSP setup graceful release, but
      never receive corresponding PathTear message, LSP graceful release
      delay is deemed to be undefined
      (informally, infinite).

6.  A Singleton Definition for multiple Bidirectional LSPs Setup Delay

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

6.1.  Motivation

   multiple Bidirectional LSPs setup delay is useful for several
   reasons:

   o  Upon traffic interruption caused by network failure or network
      upgrade, carriers undefined;

7.7.  Methodologies

   In the first circumstance, the methodology may require a large number of LSPs be set up
      during a short time period proceed as follows:

   o  The time needed  Make sure the LSP to setup a large number of LSPs during a short
      time period can not be deduced by single LSP setup delay

6.2.  Metric Name

   Multiple bidirectional LSPs setup delay

6.3.  Metric Parameters deleted is set up;

   o  ID0,  At the ingress LSR ID

   o  ID1, node, form the egress LSR ID

   o  Lambda, a rate in reciprocal milliseconds

   o  X, PATH message including Admin Status
      Object with the number of LSPs to setup

   o  T, a time

6.4.  Metric Units

   The value of multiple bidirectional LSPs setup delay is either a real
   number, or an undefined (informally, infinite) number of
   milliseconds.

6.5.  Definition

   Given lambda Reflect (R) and X, for a real number dT, Delete (D) bits set.  A timestamp
      (T1) may be stored locally in the multiple bidirectional
   LSPs setup delay from ingress node to egress node at T is dT, means
   that:

   o ingress node sends the first bit of when the first PATH
      message heading
      for packet is sent towards the egress node at wire-time T node;

   o  all subsequent (X-1) PATH messages are sent according to  Upon receiving the
      specified poisson process PATH message including Admin Status Object with arrival rate lambda

   o  ingress
      the Reflect (R) and Delete (D) bits set, the egress node receives all corresponding sends a
      RESV message packets from
      egress node, including Admin Status Object with the Delete (D) and

   o  ingress node receives
      Reflect (R) bits set.  Or, alternatively, the last RESV message packets at wire-time
      T+dT

   The multiple bidirectional LSPs setup delay from ingress node to egress node at T is undefined (informally, infinite), means that
   ingress node sends all a
      PathErr message with the PATH messages to egress node and that Path_State_Removed flag set upstream;

   o  When the ingress node dose not receive one the RESV message or more the PathErr
      message, it sends a PathTear message to remove the LSP;

   o  Egress node takes a timestamp (T2) once it receives the last bit
      of the response messages.

6.6.  Discussion

   The following issues are likely to come up in practice:

   o PathTear message.  The accuracy of multiple bidirectional LSPs setup LSP graceful release delay depends on
      the clock resolution in is then
      (T2-T1).

   o  If the ingress node; node sends the PATH message downstream, 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 fails to determine
      whether receive the PathTear message within a latency value is infinite or whether it
      reasonable period of time, the LSP graceful release delay is merely very
      large.  Simple upper bounds could
      deemed to be used.  But GMPLS networks may
      accommodate many kinds undefined.  Note that the 'reasonable' threshold is a
      parameter of devices.  For example, some photonic
      cross-connects (PXCs) have to move the micro mirrors.  This
      physical motion may take several milliseconds.  But methodology.

   In the common
      electronic switches finish second circumstance, the nodal process within several
      microseconds.  So methodology would proceed as follows:

   o  Make sure the bidirectional LSP setup delay varies
      drastically from a network to another.  In be deleted is set up;

   o  On the process of
      bidirectional LSP setup, if egress node, form the downstream node overrides RESV message including Admin Status
      Object with the
      label suggested by Reflect (R) and Delete (D) bits set.  A timestamp
      may be stored locally in the upstream node, egress node when the setup delay will also
      increase obviously.  Thus, in practice, RESV message
      packet is sent towards the upper bound should be
      chosen carefully. ingress node;
   o  If  Upon receiving the Admin Status Object with the Reflect (R) and
      Delete (D) bits set in the RESV message, the ingress node sends out the PATH messages a
      PathTear message downstream to set up remove the
      LSPs, but never receive all LSP;

   o  Egress node takes a timestamp (T2) once it receives the corresponding RESV messages, last bit
      of the
      multiple bidirectional LSPs setup PathTear message.  The LSP graceful release delay is deemed to be infinite. then
      (T2-T1).

   o  If the ingress node sends out the PATH messages to set up the
      LSPs, message downstream, but the
      egress node fails to receive one or more responding PathErr messages,the
      multiple bidirectional LSPs setup the PathTear message within a
      reasonable period of time, the LSP graceful release delay is also
      deemed to be
      infinite.  There are many possible reasons undefined.  Note that the 'reasonable' threshold is a
      parameter of the methodology.

8.  A Definition for this case.  For
      example, Samples of Single Unidirectional LSP Setup Delay

   In Section 3, we define the singleton metric of Single unidirectional
   LSP setup delay.  Now we define how to get one or more particular sample of
   Single unidirectional LSP setup delay.  Sampling is to select a
   particular potion of singleton values of the PATH messages have invalid parameters
      or given parameters.  Like
   in [RFC2330], we use Poisson sampling as an example.

8.1.  Metric Name

   Single unidirectional LSP setup delay sample

8.2.  Metric Parameters

   o  ID0, the network has not enough resource to set up ingress LSR ID

   o  ID1, the requested
      LSPs. egress LSR ID

   o  The arrival  T0, a time

   o  Tf, a time

   o  Lambda, a rate of the poisson process lambda should be carefully
      chosen such that in the one hand the control plane is not
      overburdened.On reciprocal seconds

   o  Th, LSP holding time

   o  Td, the other hand, maximum waiting time for successful setup

8.3.  Metric Units

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

   o  T, a time when setup is attemped

   o  dT, either a real number or an undefined number of milli-seconds.

8.4.  Definition

   Given T0, Tf, and lambda, compute a pseudo-random Poisson process
   beginning at or before T0, with average arrival rate should also be
      large enough lambda, and
   ending at or after Tf.  Those time values greater than or equal to meet the requirements of applications T0
   and less than or services.

6.7.  Methodologies

   Generally the methodology would proceed as follows:

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

   o Tf are then selected.  At each of the ingress node, form times
   in this process, we obtain the PATH messages (including value of unidirectional LSP setup
   delay sample at this time.  The value of the
      Upstream Label or suggested label) according to sample is the LSPs'
      requirements.

   o  At sequence
   made up of the ingress node, select resulting <time, LSP setup delay> pairs.  If there are
   no such pairs, the time for each sequence is of length zero and the PATH messages
      according sample is said
   to be empty.

8.5.  Discussion

   The parameters lambda should be carefully chosen.  If the specified poisson process.

   o  At the ingress node, sends out rate is too
   high, too frequent LSP setup/release procedure results in high
   overhead in the PATH messages according to control plane.  In turn, the
      selected time.

   o  Store a timestamp (T1) locally in high overhead will
   increase unidirectional LSP setup delay.  On the ingress node when other hand if the first
      PATH message packet
   rate is sent towards too low, the egress node.

   o  If all sample could not completely reflect the dynamic
   provisioning performance of the corresponding RESV messages arrives within 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
      reasonable period of cross-connect
   operation.  At the same time, take the final timestamp (T2) as soon
      as possible upon time needed in setting up an LSP
   under different traffic may also vary significantly.

   In the receipt case of all the messages.  By subtracting active measurement, the two timestamps, an estimate of multiple bidirectional LSPs
      setup delay (T2 -T1) can parameters Th should be computed.

   o  If one or more
   carefully chosen.  The combination of lambda and Th reflects the corresponding RESV messages fails to arrive
      within a reasonable period load
   of time, the multiple bidirectional
      LSPs setup delay is deemed to be undefined (informally, infinite).
      Note network.  The selection of Th should take into account that
   the 'reasonable' threshold is a parameter network has sufficient resource to perform subsequent tests.  The
   value of the
      methodology.

   o  If Th may be constant during one sampling process for
   simplicity considerations.

   Note that for online or more of the corresponding response messages is PathErr, passive measurements, the multiple bidirectional LSPs setup delay is deemed to be
      undefined (informally, infinite).

7.  A Singleton Definition for LSP Graceful Release Delay

   There are two different kinds holding time of an
   LSP release mechanisms in GMPLS
   networks: graceful release and forceful release.  Memo is determined by actual traffic, hence in current
   version has not taken forceful LSP release procedure into account.

7.1.  Motivation

   LSP graceful release delay this case Th is useful for several reasons: not an
   input parameter.

8.6.  Methodologies

   o  The LSP graceful release delay is part of the total cost selection of
      dynamic LSP provisioning.  For some short duration applications, specific times, using the LSP tear down time can not be ignored specified Poisson
      arrival process, and

   o  The LSP graceful release procedure is more prefered in a GMPLS
      controled network, particularly  Set up the optical networks.  Since it
      doesn't trigger restoration/protection, it is "alarm-free
      connection deletion" in [RFC4208].

7.2.  Metric Name LSP graceful release delay

7.3.  Metric Parameters

   o  ID0, as the ingress LSR ID

   o  ID1, methodology for the singleton unidirectional
      LSP setup delay, and obtain the egress LSR ID

   o  T, a time

7.4.  Metric Units

   The value of unidirectional LSP graceful release setup
      delay

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

   Note that: it is either a real number, or
   an undefined (informally, infinite) number of milliseconds.

7.5.  Definition

   There are two different possible that before the previous LSP graceful release procedures, one is
   initiated by
   procedure completes, the ingress node, next Poisson arrival process has arrived and another
   the LSP setup procedure is initiated by egress
   node.  The two procedures are depicted in initiated.  If there is resource
   contention between the [RFC3473].  We define two LSPs, the graceful LSP release delay for these two procedures separately.

   For a real number dT, setup may fail.

8.7.  Typical testing cases

8.7.1.  With No LSP in the Network

8.7.1.1.  Motivation

   Single unidirectional LSP graceful release setup delay from ingress
   node to egress node at T with no LSP in the network is dT, means that ingress node sends
   important because this reflects the
   first bit inherent delay of an RSVP-TE
   implementation.  The minimum value provides an indication of a PATH message including Admin Status Object with
   setting the Reflect (R) and Delete (D) bits to egress node at wire-
   time T,
   delay that egress node receives will likely be experienced when an LSP traverses the
   shortest route with the lightest load in the control plane.

8.7.1.2.  Methodologies

   Make sure that packet, then immediately sends
   a RESV message including Admin Status Object there is no LSP in the network, and proceed with the Delete (D) bit
   set back to ingress node.  The ingress node sends out PathTear
   downstream to remove
   methodologies described in Section 8.6.

8.7.2.  With a Number of LSPs in the Network

8.7.2.1.  Motivation

   Single unidirectional LSP setup delay with a number of LSPs in the LSP, and egress node receives
   network is important because it reflects the last bit performance of PathTear packet at wire-time T+dT.

   Also as an option, upon receipt of the PATH message including Admin
   Status Object
   operational network with setting considrable load.  This delay can vary
   significantly as the Reflect (R) number of existing LSPs vary.  It can be used as
   a scalability metric of an RSVP-TE implementation.

8.7.2.2.  Methodologies

   Setup the required number of LSPs, and Delete (D) bits, wait until the
   egress node may respond with PathErr message network reaches
   a stable state, then proceed with the
   Path_State_Removed flag set.

   The methodologies described in
   Section 8.6.

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

   In Section 4, we define the singleton metric of multiple
   unidirectional LSPs setup delay.  Now we define how to get one
   particular sample of multiple unidirectional LSP graceful release setup delay.
   Sampling is to select a particular potion of singleton values of the
   given parameters.  Like in [RFC2330], we use Poisson sampling as an
   example.

9.1.  Metric Name

   Multiple unidirectional LSPs setup delay from sample

9.2.  Metric Parameters

   o  ID0, the ingress node to LSR ID

   o  ID1, the egress node at T
   is undefined (informally, infinite), means that ingress node sends LSR ID

   o  T0, a time

   o  Tf, a time

   o  Lambda_m, a rate in the first bit reciprocal seconds

   o  Lambda, a rate in the reciprocal seconds

   o  X, the number of PATH message LSPs to egress node at wire-time T and that
   (either egress node does not receive setup

   o  Td, the PATH packet, egress node
   does not send corresponding RESV message packet in response, ingress
   node does not receive that RESV packet, or) maximum waiting time for successful multiple
      unidirectional LSPs setup

9.3.  Metric Units

   A sequence of pairs; the egress does not
   receive elements of each pair are:

   o  T, a time when the PathTear.

   The LSP graceful release delay from egress node to ingress node at T first setup is attemped

   o  dT, means that egress node sends the first bit either a real number or an undefined number of milli-seconds.

9.4.  Definition

   Given T0, Tf, and lambda, compute a RESV message
   including Admin Status Object pseudo-random Poisson process
   beginning at or before T0, with setting the Reflect (R) average arrival rate lambda, and Delete
   (D) bits to ingress node
   ending at wire-time T. The ingress node sends out
   PathTear downstream or after Tf.  Those time values greater than or equal to remove the LSP, T0
   and egress node receives less than or equal to Tf are then selected.  At each of the
   last bit times
   in this process, we obtain the value of PathTear packet at wire-time T+dT.

   The multiple unidirectional LSP graceful release
   setup delay from egress node to ingress node sample at T this time.  The value of the sample is undefined (informally, infinite), means that egress node sends the
   first bit
   sequence made up of RESV message including Admin Status Object with setting the Reflect (R) resulting <time, setup delay> pairs.  If
   there are no such pairs, the sequence is of length zero and Delete (D) bits the
   sample is said to ingress node at wire-time T
   and that (either ingress node does not receive be empty.

9.5.  Discussion

   The parameter lambda is used as arrival rate of "bacth unidirectional
   LSPs setup" operation.  It regulates the RESV packet,
   ingress node does not send PathTear message packet interval in response or)
   the egress does not receive the PathTear.

7.6.  Discussion between each
   batch operatoin.  The following issues are likely to come up parameter lambda_m is used within each batch
   operation, as described in practice:

   o  In the first (second) circumstance, the accuracy of LSP graceful
      release delay at time T depends on Section 4.

   The parameters lambda and lambda_m should be carefully chosen.  If
   the clock resolution rate is too high, too frequent LSP setup/release procedure
   results in high overhead in the
      ingress (egress) node. control plane.  In turn, the first circumstance, synchronization
      between high
   overhead will increase unidirectional LSP setup delay.  On the ingress node and egress node other
   hand if the rate is required; but too low, the sample could not in completely reflect
   the second circumstance;

   o  A given methodology has to include a way to determine whether a
      latency dynamic provisioning performance of the GMPLS network.  The
   appropriate lambda and lambda_m value is infinite or whether it is merely very large.
      Simple upper bounds could be used.  But depends on the upper bound given network.

   The parameters Td should be
      chosen carefully chosen.  Different switching
   technologies may vary significantly in practice;
   o  In performing a cross-connect
   operation.  At the first circumstance, if ingress node sends out PATH message
      including Admin Status Object with same time, the Reflect (R) and Delete (D)
      bits set to initiate time needed in setting up an LSP graceful release, but never receive
      corresponding RESV message,
   under different traffic may also vary significantly.

9.6.  Methodologies

   o  The selection of specific times, using the specified Poisson
      arrival process, and

   o  Set up the LSP graceful release delay is deemed
      to be infinite.  In as the second circumstance, if egress node sends
      out RESV message including Admin Status Object with methodology for the Reflect
      (R) singleton multiple
      unidirectional LSPs setup delay, and Delete (D) bits set to initiate LSP graceful release, but
      never receive corresponding PathTear message, LSP graceful release obtain the value of multiple
      unidirectional LSPs setup delay

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

   Note that: it is deemed to be infinite;

7.7.  Methodologies

   In possible that before the first circumstance, previous LSP release
   procedure completes, the methodology may proceed as follows:

   o  Make sure next Poisson arrival process has arrived and
   the LSP to be deleted setup procedure is set up;

   o  At the egress node, form initiated.  If there is resource
   contention between the PATH message including Admin Status
      Object with two LSP, the Reflect (R) and Delete (D) bits set.  A timestamp
      (T1) LSP setup may be stored locally fail.

9.7.  Typical testing cases

9.7.1.  With No LSP in the ingress node when Network

9.7.1.1.  Motivation

   multiple unidirectional LSP setup delay with no LSP in the PATH
      message packet network is sent towards
   important because this reflects the egress node;

   o  Upon receiving inherent delay of an RSVP-TE
   implementation.  The minimum value provides an indication of the PATH message including Admin Status Object
   delay that will likely be experienced when an LSPs traverse the
   shortest route with the Reflect (R) and Delete (D) bits set, lightest load in the egress node sends a
      RESV message including Admin Status Object with control plane.

9.7.1.2.  Methodologies

   Make sure that there is no LSP in the Delete (D) network, and
      Reflect (R) bits set.  Or, alternatively, proceed with the egress node sends
   methodologies described in Section 9.6.

9.7.2.  With a
      PathErr message with Number of LSPs in the Path_State_Removed flag set upstream;

   o  When Network

9.7.2.1.  Motivation

   multiple unidirectional LSPs setup delay with a number of LSPs in the ingress node receive
   network is important because it reflects the RESV message or performance of an
   operational network with considrable load.  This delay can vary
   significantly as the PathErr
      message, it sends number of existing LSPs vary.  It can be used as
   a PathTear message to remove scalability metric of an RSVP-TE implementation.

9.7.2.2.  Methodologies

   Setup the required number of LSPs, and wait until the LSP;

   o  Egress node takes network reaches
   a timestamp (T2) once it receives stable state, then proceed with the last bit methodologies described in
   Section 9.6..

10.  A Definition for Samples of the PathTear message.  The Single Bidirectional LSP graceful release delay is then
      (T2-T1). Setup Delay

   In Section 5, we define the second circumstance, the methodology would proceed as follows:

   o  Make sure the singleton metric of Single Bidirectional
   LSP setup delay.  Now we define how to be deleted get one particular sample of
   Single Bidirectional LSP setup delay.  Sampling is set up;

   o  On the egress node, form to select a
   particular potion of singleton values of the RESV message including Admin Status
      Object given parameters.  Like
   in [RFC2330], we use Poisson sampling as an example.

10.1.  Metric Name

   Single Bidirectional LSP setup delay sample with the Reflect (R) and Delete (D) bits set.  A timestamp
      may be stored locally no LSP in the egress node when the RESV message
      packet is sent towards
   network

10.2.  Metric Parameters

   o  ID0, the ingress node; LSR ID

   o  Upon receiving the Admin Status Object with the Reflect (R) and
      Delete (D) bits set in the RESV message,  ID1, the ingress node sends egress LSR ID

   o  T0, a
      PathTear message downstream to remove the LSP; time

   o  Egress node takes  Tf, a timestamp (T2) once it receives time

   o  Lambda, a rate in the last bit reciprocal seconds

   o  Th, LSP holding time

   o  Td, the maximum waiting time for successful setup

10.3.  Metric Units

   A sequence of pairs; the PathTear message.  The LSP graceful release delay elements of each pair are:

   o  T, a time when setup is attemped

   o  dT, either a real number or an undefined number of milli-seconds.

10.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
      (T2-T1).

8.  Typical Testing Cases of Single Unidirectional LSP Setup Delay

   Now we define typical test cases selected.  At each of getting unidirectional LSP setup
   delay.

8.1.  With No LSP the times
   in this process, we obtain the Network

8.1.1.  Motivation

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

8.1.2.  Methodologies

   Make sure that resulting <time, LSP setup delay> pairs.  If there is are no or very few LSPs in such
   pairs, the network. sequence is of length zero and the sample is said to be
   empty.

10.5.  Discussion

   The
   methodology would proceed as follows:

   o  Set up parameters lambda should be carefully chosen.  If the rate is too
   high, too frequent LSP using setup/release procedure results in high
   overhead in the methodology for control plane.  In turn, the singleton single
      unidirectional high overhead will
   increase Bidirectional LSP setup delay, and obtain delay.  On the value other hand if the
   rate is too low, the sample could not completely reflect the dynamic
   provisioning performance of
      unidirectional LSP setup delay

   o  Release the LSP

   o  Repeat this process if multiple samples are needed

   Note that: in case multiple samples are to be obtained, GMPLS network.  The appropriate
   lambda value depends on the interval
   between each process given network.

   The parameters Td should be large enough to guarantee the network
   has already reached a stable state.

8.2.  With a Number of LSPs carefully chosen.  Different switching
   technologies may vary significantly in performing a cross-connect
   operation.  At the Network

8.2.1.  Motivation

   Single unidirectional same time, the time needed in setting up an LSP setup delay with a number
   under different traffic may also vary significantly.

   In the case of LSPs in active measurement, the
   network is important because it parameters Th should be
   carefully chosen.  The combination of lambda and Th reflects the performance load
   of an
   operational network with considrable load.  This delay can vary
   significantly as the number network.  The selection of existing LSPs vary.  It can Th should take into account that
   the network has sufficient resource to perform subsequent tests.  The
   value of Th may be used as
   a scalability metric constant during one sampling process for
   simplicity considerations.

   Note that for online or passive measurements, the holding time of an RSVP-TE implementation.

8.2.2.
   LSP is determined by actual traffic, hence in this case Th is not an
   input parameter.

10.6.  Methodologies

   Setup the required number

   o  The selection of LSPs, and wait until specific times, using the network reaches
   a stable state, then proceed as follows: specified Poisson
      arrival process, and

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

   o  Release the LSP

   o  Repeat this after Th, and wait for the next Poisson arrival
      process if multiple samples are needed

   Note that: in case multiple samples are to be obtained, it is possible that before the interval
   between each process should be large enough to guarantee previous LSP release
   procedure completes, the network next Poisson arrival process has already reached a stable state.

9. arrived and
   the LSP setup procedure is initiated.  If there is resource
   contention between the two LSP, the LSP setup may fail.

10.7.  Typical Testing Cases of multiple Unidirectional LSPs Setup Delay

   Now we define typical test testing cases of getting multiple unidirectional
   LSPs setup delay.

9.1.

10.7.1.  With No LSP in the Network

9.1.1.

10.7.1.1.  Motivation

   multiple unidirectional

   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 a number of LSPs are setup
   with the lightest load in the control plane.

9.1.2.  Methodologies

   Make sure that there is no or very few LSPs in the network.  The
   methodology would proceed as follows:

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

   o  Release traverses the LSPs

   o  Repeat this process if multiple samples are needed

   Note that:
   shortest route with the lightest load in case multiple samples are to be obtained, the interval
   between each process should be large enough to guarantee control plane.

10.7.1.2.  Methodologies

   Make sure that there is no LSP in the network
   has already reached a stable state.

9.2. network, and proceed with the
   methodologies described in Section 10.6.

10.7.2.  With a Number of LSPs in the Network

9.2.1.

10.7.2.1.  Motivation

   multiple unidirectional

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

9.2.2.

10.7.2.2.  Methodologies

   Setup the required number of LSPs, and wait until the network reaches
   a stable state, then proceed as follows:

   o  Set up the LSPs using with the methodology methodologies described in
   Section 10.6. .

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

   In Section 6, we define the singleton metric of multiple
      unidirectional LSP
   bidirectional LSPs setup delay, and obtain the value delay.  Now we define how to get one
   particular sample of multiple
      unidirectional bidirectional LSP setup delay.
   Sampling is to select a particular potion of singleton values of the
   given parameters.  Like in [RFC2330], we use Poisson sampling as an
   example.

11.1.  Metric Name

   Multiple bidirectional LSPs setup delay sample

11.2.  Metric Parameters

   o  Release  ID0, the LSPs ingress LSR ID

   o  Repeat this process if multiple samples are needed

   Note that:  ID1, the egress LSR ID

   o  T0, a time

   o  Tf, a time

   o  Lambda_m, a rate in case multiple samples are the reciprocal seconds

   o  Lambda, a rate in the reciprocal seconds

   o  X, the number of LSPs to be obtained, setup

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

11.3.  Metric Units

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

   o  T, a time when the first setup is attemped

   o  dT, either a real number or an undefined number of milli-seconds.

11.4.  Definition

   Given T0, Tf, and lambda, compute a pseudo-random Poisson process should be large enough
   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 guarantee the network
   has already reached a stable state.

10.  Typical Testing Cases of Single Bidirectional LSP Setup Delay

   Now we define typical test cases Tf are then selected.  At each of getting single bidirectional LSP
   setup delay.

10.1.  With No LSP the times
   in this process, we obtain the Network

10.1.1.  Motivation

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

10.1.2.  Methodologies

   Make sure that resulting <time, setup delay> pairs.  If
   there is are no or very few such pairs, the sequence is of length zero and the
   sample is said to be empty.

11.5.  Discussion

   The parameter lambda is used as arrival rate of "bacth bidirectional
   LSPs in setup" operation.  It regulates the network. interval in between each
   batch operatoin.  The
   methodology would proceed parameter lambda_m is used within each batch
   operation, as follows:

   o  Set up described in Section 6.

   The parameters lambda and lambda_m should be carefully chosen.  If
   the rate is too high, too frequent LSP using the methodology for setup/release procedure
   results in high overhead in the singleton
      bidirectional LSP setup delay, and obtain control plane.  In turn, the value of high
   overhead will increase unidirectional LSP setup delay

   o  Release delay.  On the LSP

   o  Repeat this process other
   hand if multiple samples are needed

   Note that: in case multiple samples are to be obtained, the interval
   between each process should be large enough to guarantee rate is too low, the network
   has already reached a stable state.

10.2.  With a Number sample could not completely reflect
   the dynamic provisioning performance of LSPs 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 the Network

10.2.1.  Motivation

   Single bidirectional LSP setup delay with performing a number of LSPs in cross-connect
   operation.  At the
   network is important because it reflects same time, the performance of time needed in setting up an
   operational network with considrable load.  This delay can LSP
   under different traffic may also vary
   significantly as the number of existing LSPs vary.  It can be used as
   a scalability metric of an RSVP-TE implementation.

10.2.2. significantly.

11.6.  Methodologies

   Setup the required number

   o  The selection of LSPs, and wait until specific times, using the network reaches
   a stable state, then proceed as follows: specified Poisson
      arrival process, and

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

   o  Release the LSP

   o  Repeat this after Th, and wait for the next Poisson arrival
      process if multiple samples are needed

   Note that: in case multiple samples are to be obtained, it is possible that before the interval
   between each process should be large enough to guarantee previous LSP release
   procedure completes, the network next Poisson arrival process has already reached a stable state.

11. arrived and
   the LSP setup procedure is initiated.  If there is resource
   contention between the two LSP, the LSP setup may fail.

11.7.  Typical Testing Cases of multiple Bidirectional LSPs Setup Delay

   Now we define typical test testing cases of getting multiple bidirectional
   LSPs setup delay.

11.1.

11.7.1.  With No LSP in the Network

11.1.1.

11.7.1.1.  Motivation

   multiple 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 a number of an LSPs are setup traverse the
   shortest route with the lightest load in the control plane.

11.1.2.

11.7.1.2.  Methodologies

   Make sure that there is no or very few LSPs in the network.  The
   methodology would proceed as follows:

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

   o  Release the LSPs

   o  Repeat this process if multiple samples are needed

   Note that: in case multiple samples are to be obtained, the interval
   between each process should be large enough to guarantee no LSP in the network
   has already reached a stable state.

11.2. network, and proceed with the
   methodologies described in Section 9.6.

11.7.2.  With a Number of LSPs in the Network

11.2.1.

11.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 considrable 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.

11.2.2.

11.7.2.2.  Methodologies

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

12.  A Definition for Samples of LSP Graceful Release Delay

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

12.1.  Metric Name

   LSP graceful release 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, a rate in reciprocal seconds

   o  Td, the maximum waiting time for successful LSP release

12.3.  Metric Units

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

   o  T, a time, and

   o  dT, either a real number or an undefined number of milli-seconds.

12.4.  Definition

   Given T0, Tf, and lambda, we 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 LSP graceful release delay
   sample at this time.  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.

12.5.  Discussion

   The parameter lambda should be carefully chosen.  If the rate is too
   large, too frequent LSP setup/release procedure results 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 could not completely reflect the
   dynamic provisioning performance of LSPs, and wait until the network reaches
   a stable state, then GMPLS network.  The
   appropriate lambda value depends on the given network.

12.6.  Methodologies

   Generally the methodology would proceed as follows:

   o  Set up  Setup the LSPs LSP to be deleted

   o  The selection of specific times, using the specified Poisson
      arrival process, and

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

   o  Release  Setup the LSPs

   o  Repeat this LSP, and restart the Poisson arrival process, wait for
      the next Poisson arrival process if multiple samples are needed

   Note that:

13.  Discussion for unsuccessful setup/release cases

   As has been mentioned earlier, LSP setup/release 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 case multiple samples are
   one of the intermediat 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 obtained,
   performed to check the interval
   between each process should possible implementation,configuration or other
   deficiency.

   Although not commonly seen, an LSP setup/release attemp may be large enough
   falsely carried out. for example, the setup/release request may be
   targed to a wrong egress node.  Although faulty results may have
   totally different implications to guarantee the network
   has already reached control plane, if compared with
   failure cases, for the purpose of performance evaluation, it is still
   reasonable to treat such results as unsuccessful cases.  Thus the
   unsuccessful cases include both failure and incorrect cases.

   Once a stable state.

12. sample of a particular metric, e.g, single unidirectional LSP
   setup delay, is obtained, we can deduce the unsuccessful cases by
   sorting out from the sample the <time, delay> pairs with undefined
   delay value.

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, or an undefined (informally,
   infinite) number of
   milliseconds.  In the following discussion, we only consider the
   finite values.

12.1.

14.1.  The Minimum of Metric

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

12.2.

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 are not counted in.

12.3.

14.3.  The percentile of Metric

   Given a metric and a percent X between 0% and 100%, the Xth
   percentile of all the dT values in the sample.  In addition, the
   unidirectional LSP setup delay percentile is undefined if the sample
   is empty.

   Example: suppose we take a sample and the results are: Stream1 = <
   <T1, 100 msec>, <T2, 110 msec>, <T3, undefined>, <T4, 90 msec>, <T5,
   500 msec> >

   Then the 50th percentile would be 110 msec, since 90 msec and 100
   msec are smaller, and 110 and 500 msec are larger (undefined values
   are not counted in).

12.4.

14.4.  The Failure Probability

   In the process of LSP setup/release, it may fail for some reason.
   The failure probability is the ratio of the failure unsucessful times to the
   total times.

13.  Note here that both failure and incorrect cases are
   counted as unsucessful cases.

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 or/and 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 procedure.  Similarly, in the LSP graceful release
      delay, the memo has not considered the processing time in the
      endpoint node.

   o  All these metrics are defined from the point of control plane's
      view.  In fact, the control plane and data plane are not always
      synchronized.  In some cases, the LSPs have been set up in the
      control plane.  But the data can not be forwarded immediately.
      The unidirectional/bidirectional LSP setup delay in the data plane
      is longer than in the control plane.

14.

16.  Security Considerations

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

   In the active manner, ingress nodes inject probing messages into the
   control plane.  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.

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

15.

17.  IANA Considerations

   This document makes no requests for IANA action.

16.

18.  Acknowledgements

   We wish to thank Dan Li, Fang Liu (Christine), Zafar Ali, Monique
   Morrow, Al Morton, Adrian Farrel, Deborah Brungard, Thomas D. Nadeau
   for their comments and helps.

   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 NSFC and 863 program of China.

17.

19.  References

17.1.

19.1.  Normative References

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

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

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

   [RFC4802]  Nadeau, T. and A. Farrel, "Generalized Multiprotocol Label
              Switching (GMPLS) Traffic Engineering Management
              Information Base", RFC 4802, February 2007.

17.2.

19.2.  Informative References

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

Authors' Addresses

   Weiqiang Sun
   Shanghai Jiao Tong University
   800 Dongchuan Road
   Shanghai  200240
   CN

   Phone: +86 21 3420 5359
   Email: sunwq@sjtu.edu.cn

   Guoying Zhang
   China Academy of Telecommunication Research,MII.
   Beijing  200240
   CN

   Phone: +86 1068094272
   Email: zhangguoying@mail.ritt.com.cn

   Jianhua Gao
   Huawei Technologies Co., LTD.
   CN

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

   Guowu Xie
   Shanghai Jiao Tong University
   800 Dongchuan Road
   Shanghai  200240
   CN

   Phone: +86 21 3420 4596
   Email: blithe@sjtu.edu.cn

   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
   CN

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

   Xueqing Wei
   Fiberhome Telecommunicaiton Technology Co.,Ltd.
   Wuhan
   CN

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

   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
   CN

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

Full Copyright Statement

   Copyright (C) The IETF Trust (2008).

   This document is subject to the rights, licenses and restrictions
   contained in BCP 78, and except as set forth therein, the authors
   retain all their rights.

   This document and the information contained herein are provided on an
   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
   THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS
   OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
   THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
   WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.

Intellectual Property

   The IETF takes no position regarding the validity or scope of any
   Intellectual Property Rights or other rights that might be claimed to
   pertain to the implementation or use of the technology described in
   this document or the extent to which any license under such rights
   might or might not be available; nor does it represent that it has
   made any independent effort to identify any such rights.  Information
   on the procedures with respect to rights in RFC documents can be
   found in BCP 78 and BCP 79.

   Copies of IPR disclosures made to the IETF Secretariat and any
   assurances of licenses to be made available, or the result of an
   attempt made to obtain a general license or permission for the use of
   such proprietary rights by implementers or users of this
   specification can be obtained from the IETF on-line IPR repository at
   http://www.ietf.org/ipr.

   The IETF invites any interested party to bring to its attention any
   copyrights, patents or patent applications, or other proprietary
   rights that may cover technology that may be required to implement
   this standard.  Please address the information to the IETF at
   ietf-ipr@ietf.org.