[Docs] [txt|pdf] [Tracker] [Email] [Diff1] [Diff2] [Nits]

Versions: 00 01 02 draft-ietf-ccamp-lsp-dppm

ccamp                                                             G. Xie
Internet-Draft                                                    W. Sun
Intended status: Standards Track           Shanghai Jiao Tong University
Expires: November 26, 2007                                      G. Zhang
                                      China Academy of Telecommunication
                                                           Research,MII.
                                                                  J. Han
                                                                    IXIA
                                                                  X. Wei
                                                               Fiberhome
                                                                  J. Gao
                                                                  Huawei
                                                            May 25, 2007


Label Switched Path (LSP) Dynamical Provisioning Performance Metrics in
                       Generalized MPLS Networks
                    draft-xie-ccamp-lsp-dppm-01.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 November 26, 2007.

Copyright Notice

   Copyright (C) The IETF Trust (2007).




Xie, et al.             Expires November 26, 2007               [Page 1]


Internet-Draft     LSP Dynamical PPM in GMPLS Networks          May 2007


Abstract

   Generalized Multi-Protocol Label Switching (GMPLS) is one of the most
   promising candidate technologies for the future data transmission
   network.  The GMPLS has been developed to control and cooperate
   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 dynamically provisioned connections is
   increasing because optical networks are being deployed in metro area.
   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 dynamical LSP setup/release performance.  These
   metrics can depict the features of the GMPLS network in LSP dynamic
   provisioning.  They can also be used in operational networks for
   carriers to monitor the control plane performance in realtime.




























Xie, et al.             Expires November 26, 2007               [Page 2]


Internet-Draft     LSP Dynamical PPM in GMPLS Networks          May 2007


Table of Contents

   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  5
   2.  Conventions Used in This Document  . . . . . . . . . . . . . .  6
   3.  Overview of Performance Metrics  . . . . . . . . . . . . . . .  7
   4.  A Singleton Definition for Unidirectional LSP Setup Delay  . .  8
     4.1.  Motivation . . . . . . . . . . . . . . . . . . . . . . . .  8
     4.2.  Metric Name  . . . . . . . . . . . . . . . . . . . . . . .  8
     4.3.  Metric Parameters  . . . . . . . . . . . . . . . . . . . .  8
     4.4.  Metric Units . . . . . . . . . . . . . . . . . . . . . . .  9
     4.5.  Definition . . . . . . . . . . . . . . . . . . . . . . . .  9
     4.6.  Discussion . . . . . . . . . . . . . . . . . . . . . . . .  9
     4.7.  Methodologies  . . . . . . . . . . . . . . . . . . . . . . 10
   5.  A Definition for Samples of Unidirectional LSP Setup Delay . . 11
     5.1.  Metric Name  . . . . . . . . . . . . . . . . . . . . . . . 11
     5.2.  Metric Parameters  . . . . . . . . . . . . . . . . . . . . 11
     5.3.  Metric Units . . . . . . . . . . . . . . . . . . . . . . . 11
     5.4.  Definition . . . . . . . . . . . . . . . . . . . . . . . . 11
     5.5.  Discussion . . . . . . . . . . . . . . . . . . . . . . . . 12
     5.6.  Methodologies  . . . . . . . . . . . . . . . . . . . . . . 12
   6.  A Singleton Definition for Bidirectional LSP Setup Delay . . . 13
     6.1.  Motivation . . . . . . . . . . . . . . . . . . . . . . . . 13
     6.2.  Metric Name  . . . . . . . . . . . . . . . . . . . . . . . 14
     6.3.  Metric Parameters  . . . . . . . . . . . . . . . . . . . . 14
     6.4.  Metric Units . . . . . . . . . . . . . . . . . . . . . . . 14
     6.5.  Definition . . . . . . . . . . . . . . . . . . . . . . . . 14
     6.6.  Discussion . . . . . . . . . . . . . . . . . . . . . . . . 15
     6.7.  Methodologies  . . . . . . . . . . . . . . . . . . . . . . 15
   7.  A Definition for Sample of Bidirectional LSP Setup Delay . . . 17
     7.1.  Metric Name  . . . . . . . . . . . . . . . . . . . . . . . 17
     7.2.  Metric Parameters  . . . . . . . . . . . . . . . . . . . . 17
     7.3.  Metric Units . . . . . . . . . . . . . . . . . . . . . . . 17
     7.4.  Definition . . . . . . . . . . . . . . . . . . . . . . . . 17
     7.5.  Discussion . . . . . . . . . . . . . . . . . . . . . . . . 18
     7.6.  Methodologies  . . . . . . . . . . . . . . . . . . . . . . 18
   8.  A Singleton Definition for LSP Graceful Release Delay  . . . . 19
     8.1.  Motivation . . . . . . . . . . . . . . . . . . . . . . . . 19
     8.2.  Metric Name  . . . . . . . . . . . . . . . . . . . . . . . 19
     8.3.  Metric Parameters  . . . . . . . . . . . . . . . . . . . . 19
     8.4.  Metric Units . . . . . . . . . . . . . . . . . . . . . . . 19
     8.5.  Definition . . . . . . . . . . . . . . . . . . . . . . . . 19
     8.6.  Discussion . . . . . . . . . . . . . . . . . . . . . . . . 21
     8.7.  Methodologies  . . . . . . . . . . . . . . . . . . . . . . 22
   9.  A Definition for Samples of LSP Graceful Release Delay . . . . 24
     9.1.  Metric Name  . . . . . . . . . . . . . . . . . . . . . . . 24
     9.2.  Metric Parameters  . . . . . . . . . . . . . . . . . . . . 24
     9.3.  Metric Units . . . . . . . . . . . . . . . . . . . . . . . 24
     9.4.  Definition . . . . . . . . . . . . . . . . . . . . . . . . 24



Xie, et al.             Expires November 26, 2007               [Page 3]


Internet-Draft     LSP Dynamical PPM in GMPLS Networks          May 2007


     9.5.  Discussion . . . . . . . . . . . . . . . . . . . . . . . . 25
     9.6.  Methodologies  . . . . . . . . . . . . . . . . . . . . . . 25
   10. Some Statistics Definitions for Metrics to Report  . . . . . . 26
     10.1. The Minimum of Metric  . . . . . . . . . . . . . . . . . . 26
     10.2. The Median of Metric . . . . . . . . . . . . . . . . . . . 26
     10.3. The percentile of Metric . . . . . . . . . . . . . . . . . 26
     10.4. The failure probability  . . . . . . . . . . . . . . . . . 26
   11. Discussion . . . . . . . . . . . . . . . . . . . . . . . . . . 27
   12. Security Considerations  . . . . . . . . . . . . . . . . . . . 28
   13. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 29
   14. References . . . . . . . . . . . . . . . . . . . . . . . . . . 30
     14.1. References . . . . . . . . . . . . . . . . . . . . . . . . 30
     14.2. Normative References . . . . . . . . . . . . . . . . . . . 31
   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 32
   Intellectual Property and Copyright Statements . . . . . . . . . . 34




































Xie, et al.             Expires November 26, 2007               [Page 4]


Internet-Draft     LSP Dynamical PPM in GMPLS Networks          May 2007


1.  Introduction

   Generalized Multi-Protocol Label Switching (GMPLS) is one of the most
   promising candidate technologies for the future data transmission
   network.  The GMPLS has been developed to control and cooperate
   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 guaranteed high-bandwidth and fast failure recovery feature have
   made optical circuit switching a premier choice in building wide area
   and metro area transport networks.  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 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 intends to define performance metrics and methodologies
   that can be used to depict the dynamic connection provisioning
   performance of GMPLS networks.  The metrics defined in this draft 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
   the TE-MIB 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.

















Xie, et al.             Expires November 26, 2007               [Page 5]


Internet-Draft     LSP Dynamical PPM in GMPLS Networks          May 2007


2.  Conventions Used in This Document

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
   document are to be interpreted as described in [refs.RFC2119].














































Xie, et al.             Expires November 26, 2007               [Page 6]


Internet-Draft     LSP Dynamical PPM in GMPLS Networks          May 2007


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









































Xie, et al.             Expires November 26, 2007               [Page 7]


Internet-Draft     LSP Dynamical PPM in GMPLS Networks          May 2007


4.  A Singleton Definition for Unidirectional LSP Setup Delay

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

4.1.  Motivation

   Unidirectional 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 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 network 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 unidirectional LSP setup delay instead of
   bidirectional LSP setup delay is motivated by the following factors:

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

4.2.  Metric Name

   Unidirectional LSP setup delay

4.3.  Metric Parameters

   o  ID0, the ingress LSR ID





Xie, et al.             Expires November 26, 2007               [Page 8]


Internet-Draft     LSP Dynamical PPM in GMPLS Networks          May 2007


   o  ID1, the egress LSR ID

   o  T, a time

4.4.  Metric Units

   The value of unidirectional LSP setup delay is either a real number,
   or an undefined (informally, infinite) number of milli-seconds.

4.5.  Definition

   The unidirectional LSP setup delay from ingress node to egress node
   [refs.RFC3945] at T is dT means that ingress node sent the first bit
   of a Path message packet to egress node at wire-time T, and that the
   ingress node received the last bit of responding Resv message packet
   from egress node at wire-time T+dT in the unidirectional LSP setup
   case.

   The unidirectional LSP setup delay from ingress node to egress node
   at T is undefined (informally, infinite), means that ingress node
   sent the first bit of Path message packet to egress node at wire-time
   T and that ingress node did not receive the corresponding Resv
   message within a reasonable period of time.

4.6.  Discussion

   The following issues are likely to come up in practice:

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

   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 the GMPLS network
      accommodates 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 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 sent out the Path message to set up LSP, but never
      receive corresponding Resv message, unidirectional LSP setup delay
      is deemed to be infinite.





Xie, et al.             Expires November 26, 2007               [Page 9]


Internet-Draft     LSP Dynamical PPM in GMPLS Networks          May 2007


   o  If ingress node sent out the Path message to set up LSP but
      receive PathErr message, unidirectional LSP setup delay is also
      deemed to be infinite.  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.

4.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
      the receipt of the packet.  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 (informally, infinite).  Note that the
      'reasonable' threshold of is a parameter of the methodology.

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



















Xie, et al.             Expires November 26, 2007              [Page 10]


Internet-Draft     LSP Dynamical PPM in GMPLS Networks          May 2007


5.  A Definition for Samples of Unidirectional LSP Setup Delay

   In the previous part, we define the singleton metric of
   unidirectional LSP setup delay.  Now we define how to get one
   particular sample of unidirectional LSP setup delay.  Sampling is to
   select a particular potion of singleton values of the given
   parameters.  Like the [refs.RFC2330], we use Poisson sampling as an
   example.

5.1.  Metric Name

   Unidirectional LSP setup delay sample

5.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 'reasonable' threshold

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

   The values of T in the sequence are monotonically increasing.  Note
   that T would be a valid parameter to unidirectional LSP setup delay
   sample, and that dT would be a valid value of unidirectional LSP
   setup delay.

5.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 unidirectional LSP setup
   delay sample at this time.  The value of the sample is the sequence



Xie, et al.             Expires November 26, 2007              [Page 11]


Internet-Draft     LSP Dynamical PPM in GMPLS Networks          May 2007


   made up of the resulting <time, LSP setup delay> pairs.  If there are
   no such pairs, the sequence is of length zero and the sample is said
   to be empty.

5.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 the GMPLS network.  The
   appropriate lambda value depends on the given network.

5.6.  Methodologies

   Generally the methodology would proceed as follows:

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

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

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

   Note that: it is possible that before the previous LSP release
   procedure completes, the next Poisson arrival process has arrived and
   the LSP setup procedure is initiated.  If there is resource
   contention between the two LSP, the LSP setup may fail.




















Xie, et al.             Expires November 26, 2007              [Page 12]


Internet-Draft     LSP Dynamical PPM in GMPLS Networks          May 2007


6.  A Singleton Definition for Bidirectional LSP Setup Delay

   Bidirectional optical LSPs (or lightpaths) are seen as a requirement
   for most optical networking service.  GMPLS allows establishment of
   bi-directional symmetric LSPs (not of asymmetric LSPs).  A symmetric
   bidirectional LSP has the same traffic engineering requirements
   including fate sharing, protection and restoration, LSRs, and
   resource requirements (e.g., delay and delay variance) in either
   direction.

   The disadvantage of unidirectional LSP: Normally to establish a
   bidirectional LSP when using RSVP-TE [refs.RFC3209] or CR-LDP
   [refs.RFC3212] two unidirectional paths must be independently
   established.  This approach has the following disadvantages:

   o  Reduces the setup delay to one ingress-egress round trip time plus
      processing time in the nodes en-route;

   o  Reduces the signal overhead in the control plane;

   o  Allows suggesting a label by an upstream node to reduce the setup
      delay.

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

6.1.  Motivation

   Unidirectional 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 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 network or high control element load.
      For this reason, this metric is useful for testing and diagnostic
      purposes.



Xie, et al.             Expires November 26, 2007              [Page 13]


Internet-Draft     LSP Dynamical PPM in GMPLS Networks          May 2007


   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 bidirectional LSP setup delay instead of
   unidirectional LSP setup delay is motivated by the following factors:

   o  Bidirectional LSPs are seen as a requirement for many GMPLS
      network while the LSPs are unidirectional in nature in the MPLS
      network.  For most applications, the communication is
      bidirectional.  So bidirectional LSP latency is necessary and more
      reasonable than unidirectional LSP latency.

6.2.  Metric Name

   Bidirectional LSP setup delay

6.3.  Metric Parameters

   o  ID0, the ingress LSR ID

   o  ID1, the egress LSR ID

   o  T, a time

6.4.  Metric Units

   The value of bidirectional LSP setup delay is either a real number,
   or an undefined (informally, infinite) number of milli-seconds.

6.5.  Definition

   For a real number dT, the bidirectional LSP setup delay from ingress
   node to egress node at T is dT, means that ingress node sent out the
   first bit of a Path message include an Upstream Label [refs.RFC3473]
   heading for egress node at wire-time T, egress node received that
   packet, then immediately sent a Resv message packet back to ingress
   node, and that ingress node received the last bit of that packet at
   wire-time T+dT.

   The bidirectional LSP setup delay from ingress node to egress node at
   T is undefined (informally, infinite), means that ingress node sent
   the first bit of Path message to egress node at wire-time T and that
   (either egress node did not receive the packet, egress node did not
   send corresponding Resv message packet in response, or) ingress node
   did not receive that response packet.





Xie, et al.             Expires November 26, 2007              [Page 14]


Internet-Draft     LSP Dynamical PPM in GMPLS Networks          May 2007


6.6.  Discussion

   The following issues are likely to come up in practice:

   o  The accuracy of 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.

   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 the GMPLS network
      accommodates 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 process within several
      microseconds.  So the 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 will also
      increase obviously.  Thus, in practice, the upper bound should be
      chosen carefully.

   o  If ingress node sent out the Path message to set up the LSP, but
      never receive corresponding Resv message, bidirectional LSP setup
      delay is deemed to be infinite.

   o  If ingress node sent out the Path message to set up the LSP, but
      receive PathErr message, bidirectional LSP setup delay is also
      deemed to be infinite.  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.

6.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 packet.  By subtracting the two
      timestamps, an estimate of bidirectional LSP setup delay (T2 -T1)



Xie, et al.             Expires November 26, 2007              [Page 15]


Internet-Draft     LSP Dynamical PPM in GMPLS Networks          May 2007


      can be computed.

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

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









































Xie, et al.             Expires November 26, 2007              [Page 16]


Internet-Draft     LSP Dynamical PPM in GMPLS Networks          May 2007


7.  A Definition for Sample of Bidirectional LSP Setup Delay

   In the previous part, we define the singleton metric of bidirectional
   LSP setup delay.  Now we define how to get one particular sample of
   bidirectional LSP setup delay.  We also use Poisson sampling as an
   example.

7.1.  Metric Name

   Bidirectional LSP setup delay sample

7.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 'reasonable' threshold

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

   The values of T in the sequence are monotonic increasing.  Note that
   T would be a valid parameter to bidirectional LSP setup delay sample,
   and that dT would be a valid value of bidirectional LSP setup delay.

7.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 unidirectional LSP setup
   delay sample at this time.  The value of the sample is the sequence
   made up of the resulting < time, bidirectional setup delay > pairs.
   If there are no such pairs, the sequence is of length zero and the
   sample is said to be empty.



Xie, et al.             Expires November 26, 2007              [Page 17]


Internet-Draft     LSP Dynamical PPM in GMPLS Networks          May 2007


7.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 the GMPLS network.  The
   appropriate lambda value depends on the given network.

7.6.  Methodologies

   Generally the methodology would proceed as follows:

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

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

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

   Note that: it is possible that before the previous LSP release
   procedure completes, the next Poisson arrival process has arrived and
   the LSP setup procedure is initiated.  If there is resource
   contention between these two LSP, the LSP setup may fail.























Xie, et al.             Expires November 26, 2007              [Page 18]


Internet-Draft     LSP Dynamical PPM in GMPLS Networks          May 2007


8.  A Singleton Definition for LSP Graceful Release Delay

   There are two different kinds of LSP release mechanism in the GMPLS
   network: graceful release and forceful release.  As a matter of fact,
   the forceful release employs PathErr message to tear down the LSP.
   Memo in current version has not taken forceful LSP release procedure
   into account.

8.1.  Motivation

   LSP graceful release delay is useful for several reasons:

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

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

8.2.  Metric Name

   LSP graceful release delay

8.3.  Metric Parameters

   o  ID0, the ingress LSR ID

   o  ID1, the egress LSR ID

   o  T, a time

8.4.  Metric Units

   The value of LSP graceful release delay is either a real number, or
   an undefined (informally, infinite) number of milli-seconds.

8.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 [refs.RFC2330].  We
   define the graceful LSP release delay for the two procedures
   separately.

   In the first circumstance where release procedure is initiated by the
   ingress node, ingress node sets the administrative status of an LSP



Xie, et al.             Expires November 26, 2007              [Page 19]


Internet-Draft     LSP Dynamical PPM in GMPLS Networks          May 2007


   before tearing it down.  It is useful particularly in optical
   networks.  The LSP graceful release procedure initiated from ingress
   SHOULD proceed as follow:

   o  The ingress node initiates an LSP deletion by sending out the Path
      message including an Admin Status Object and setting the Reflect
      (R) and Delete (D) bits.  At the same time, the ingress node sets
      a timer for the responding PathErr;

   o  Transit nodes and egress node process the Admin Status Object as
      described [refs.RFC2330].  The egress MAY respond with a PathErr
      message with the Path_State_Removed flag set;

   o  Upon receiving the Admin Status Object with the Delete (D) bit set
      in the Resv message before the timer times out, the ingress node
      sends a PathTear message downstream to remove the LSP and normal
      RSVP processing takes place.  If the timer times out and the
      responding PathErr message has not arrived, the ingress node will
      also send out PathTear message.

   For a real number dT, the LSP graceful release delay from ingress
   node to egress node at T is dT, means that ingress node sent the
   first bit of a Path message include Admin Status Object with setting
   the Reflect (R) and Delete (D) bits to egress node at wire-time T,
   that egress node received that packet, then immediately sent a Resv
   message including Admin Status Object with the Delete (D) bit set
   back to ingress node.  The ingress node sends out PathTear downstream
   to remove the LSP, and egress node received the last bit of PathTear
   packet at wire-time T+dT.

   The LSP graceful release delay from ingress node to egress node at T
   is undefined (informally, infinite), means that ingress node sent the
   first bit of Path message to egress node at wire-time T and that
   (either egress node did not receive the Path packet, egress node did
   not send corresponding Resv message packet in response, ingress node
   did not receive that Resv packet, or) the egress did not receive the
   PathTear.

   In the second circumstance, the graceful LSP release procedure
   initiated from egress SHOULD proceed as follow:

   o  The egress node indicates its desire for deletion by inserting an
      Admin Status Object in a Resv message and setting the Reflect (R)
      and Delete (D) bits.

   o  Transit nodes process the Admin Status Object as described above.





Xie, et al.             Expires November 26, 2007              [Page 20]


Internet-Draft     LSP Dynamical PPM in GMPLS Networks          May 2007


   o  Upon receiving the Admin Status Object with the Delete (D) bit set
      in the Resv message, the ingress node sends a PathTear message
      downstream to remove the LSP and normal RSVP processing takes
      place.

   Note: In this circumstance, the initiator of the LSP release
   procedure is the egress, and the terminator is the ingress.

   The LSP graceful release delay from egress node to ingress node at T
   is dT, means that egress node sent the first bit of a Resv message
   including Admin Status Object with setting the Reflect (R) and Delete
   (D) bits to ingress node at wire-time T, that ingress node received
   the packet, then immediately sent a PathTear message downstream to
   egress node.  The ingress node sends out PathTear downstream to
   remove the LSP, and egress node received the last bit of PathTear
   packet at wire-time T+dT.

   The LSP graceful release delay from egress node to ingress node at T
   is undefined (informally, infinite), means that egress node sent the
   first bit of Resv message including Admin Status Object with setting
   the Reflect (R) and Delete (D) bits to ingress node at wire-time T
   and that (either ingress node did not receive the Resv packet,
   ingress node did not send PathTear message packet in response or) the
   egress did not receive the PathTear.

8.6.  Discussion

   The following issues are likely to come up in practice:

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

   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 upper bound should be
      chosen carefully in practice;

   o  In the first circumstance, if ingress node sent out Path message
      including Admin Status Object with the Reflect (R) and Delete (D)
      bits set to initiate LSP graceful release, but never receive
      corresponding Resv message, LSP graceful release delay is deemed
      to be infinite.  In the second circumstance, if egress node sent
      out Resv message including Admin Status Object with the Reflect
      (R) and Delete (D) bits set to initiate LSP graceful release, but
      never receive corresponding PathTear message, LSP graceful release
      delay is deemed to be infinite;



Xie, et al.             Expires November 26, 2007              [Page 21]


Internet-Draft     LSP Dynamical PPM in GMPLS Networks          May 2007


   o  It is possible that some nodes along an LSP will not support the
      Admin Status Object.  In the case of a non-supporting intermediate
      node(s), the object will pass through the node(s) unmodified and
      normal processing can continue.  In the case of a non-supporting
      ingress/egress node, the Admin Status Object will not be reflected
      back in the Resv Message.  To support the case of a non-supporting
      ingress/egress node, the ingress (egress in the second
      circumstance) SHOULD only wait a configurable period of time for
      the updated Admin Status Object in a Resv message.  Once the
      period of time has elapsed, the ingress (egress in the second
      circumstance) node sends a PathTear message.

8.7.  Methodologies

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

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

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

   o  Intermediate nodes process the Admin Status Object as described in
      [refs.RFC2330], and forward the Path message to the ingress node;

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

   o  When the egress node receives the PathTear message, take a
      timestamp (T2) as soon as possible.  The LSP graceful release
      delay (T2-T1) is this timestamp minus the initial timestamp.

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

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

   o  At the initiator node (egress node in this case), form the Resv
      message including Admin Status Object with the Reflect (R) and
      Delete (D) bits set.  A timestamp may be stored locally in the
      initiator node when the Path message packet is sent towards the
      terminator node;

   o  Intermediate nodes process the Admin Status Object as described in
      [refs.RFC2330], and forward the Path message to the terminator
      node;




Xie, et al.             Expires November 26, 2007              [Page 22]


Internet-Draft     LSP Dynamical PPM in GMPLS Networks          May 2007


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

   o  When the initiator node receives the PathTear message, take a
      timestamp as soon as possible.  The LSP graceful release delay is
      this timestamp minus the initial timestamp.












































Xie, et al.             Expires November 26, 2007              [Page 23]


Internet-Draft     LSP Dynamical PPM in GMPLS Networks          May 2007


9.  A Definition for Samples of LSP Graceful Release Delay

   In the previous part, 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.

9.1.  Metric Name

   LSP graceful release delay sample

9.2.  Metric Parameters

   o  ID0, the ingress LSR ID

   o  ID1, the egress LSR ID

   o  T0, a time

   o  Tf, a time

   o  Lambda, a rate in reciprocal seconds

   o  Td, the 'reasonable' threshold

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

   The values of T in the sequence are monotonic increasing.  Note that
   T would be a valid parameter to unidirectional LSP setup delay
   sample, and that dT would be a valid value of Type-P-Round-trip-
   Delay.

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



Xie, et al.             Expires November 26, 2007              [Page 24]


Internet-Draft     LSP Dynamical PPM in GMPLS Networks          May 2007


9.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 the GMPLS network.  The
   appropriate lambda value depends on the given network.

9.6.  Methodologies

   Generally the methodology would proceed as follows:

   o  Setup the 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 LSP graceful
      release delay, and obtain the value of LSP graceful release delay

   o  Setup the LSP, and restart the Poisson arrival process, wait for
      the next Poisson arrival process



























Xie, et al.             Expires November 26, 2007              [Page 25]


Internet-Draft     LSP Dynamical PPM in GMPLS Networks          May 2007


10.  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 milli-seconds.  In the following discussion, we
   only consider the finite values.

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

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

10.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 and 'undefined' are larger
   (undefined values are not counted in).

10.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 times to the
   total times.








Xie, et al.             Expires November 26, 2007              [Page 26]


Internet-Draft     LSP Dynamical PPM in GMPLS Networks          May 2007


11.  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 the article,
      unidirectional/bidirectional LSP setup delay has not taken the
      processing time in the last node (ingress or egress) into account.
      The timestamp T2 are taken after the last 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 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.
































Xie, et al.             Expires November 26, 2007              [Page 27]


Internet-Draft     LSP Dynamical PPM in GMPLS Networks          May 2007


12.  Security Considerations

   The security considerations pertaining to the original RSVP protocol
   [refs.RFC2205] and its TE extensions [refs.RFC3209] remain relevant.















































Xie, et al.             Expires November 26, 2007              [Page 28]


Internet-Draft     LSP Dynamical PPM in GMPLS Networks          May 2007


13.  Acknowledgements

   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.











































Xie, et al.             Expires November 26, 2007              [Page 29]


Internet-Draft     LSP Dynamical PPM in GMPLS Networks          May 2007


14.  References

14.1.  References

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

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

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

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

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

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

   [refs.RFC3212]
              Jamoussi, B., Andersson, L., Callon, R., Dantu, R., Wu,
              L., Doolan, P., Worster, T., Feldman, N., Fredette, A.,
              Girish, M., Gray, E., Heinanen, J., Kilty, T., and A.
              Malis, "Constraint-Based LSP Setup using LDP", RFC 3212,
              January 2002.

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

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




Xie, et al.             Expires November 26, 2007              [Page 30]


Internet-Draft     LSP Dynamical PPM in GMPLS Networks          May 2007


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

14.2.  Normative References

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








































Xie, et al.             Expires November 26, 2007              [Page 31]


Internet-Draft     LSP Dynamical PPM in GMPLS Networks          May 2007


Authors' Addresses

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

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


   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


   Jianghui Han
   IXIA
   Oriental Kenzo Plaza 8M,48 Dongzhimen Wai Street,Dongcheng District
   Beijing  200240
   CN

   Phone: +86 13801156004
   Email: JHan@ixiacom.com


   Xueqing Wei
   Fiberhome Technologies, Wuhan, China
   CN

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




Xie, et al.             Expires November 26, 2007              [Page 32]


Internet-Draft     LSP Dynamical PPM in GMPLS Networks          May 2007


   Jianhua Gao
   Huawei Technologies Co., LTD.
   CN

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













































Xie, et al.             Expires November 26, 2007              [Page 33]


Internet-Draft     LSP Dynamical PPM in GMPLS Networks          May 2007


Full Copyright Statement

   Copyright (C) The IETF Trust (2007).

   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.


Acknowledgment

   Funding for the RFC Editor function is provided by the IETF
   Administrative Support Activity (IASA).





Xie, et al.             Expires November 26, 2007              [Page 34]


Html markup produced by rfcmarkup 1.129d, available from https://tools.ietf.org/tools/rfcmarkup/