Network Working Group                                        W. Sun Sun, Ed.
Internet-Draft                                                      SJTU
Intended status: Standards Track                           G. Zhang Zhang, Ed.
Expires: November 29, 2010 April 12, 2011                                             CATR
                                                            May 28,
                                                         October 9, 2010

 Label Switched Path (LSP) Data Path Delay Metric Metrics in Generalized MPLS/
                            MPLS-TE Networks
                      draft-ietf-ccamp-dpm-00.txt
                      draft-ietf-ccamp-dpm-01.txt

Abstract

   When setting up a label switched path (LSP) in Generalized MPLS and
   MPLS/TE networks, the completion of the signaling process does not
   necessarily mean that the cross connection along the LSP have been
   programmed accordingly and in a timely manner.  Meanwhile, the
   completion of signaling process may be used by applications as
   indication that data path has become usable.  The existence of this
   delay and the possible failure of cross connection programming, if
   not properly treated, will result in data loss or even application
   failure.  Characterization of this performance can thus help
   designers to improve the application model and to build more robust
   applications.  This document defines a series of performance metrics
   to evaluate the availability of data path in the signaling process.

Status of this Memo

   This Internet-Draft is submitted in full conformance with the
   provisions of BCP 78 and BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF).  Note that other groups may also distribute
   working documents as Internet-Drafts.  The list of current Internet-
   Drafts is at http://datatracker.ietf.org/drafts/current/.

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

   This Internet-Draft will expire on November 29, 2010. April 12, 2011.

Copyright Notice

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

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

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

Table of Contents

   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  5

   2.  Conventions Used in This Document  . . . . . . . . . . . . . .  6

   3.  Overview of Performance Metrics  . . . . . . . . . . . . . . .  7

   4.  Terms used in this document  . . . . . . . . . . . . . . . . .  8

   5.  A singleton Definition for RRFD  . . . . . . . . . . . . . . .  9
     5.1.  Motivation . . . . . . . . . . . . . . . . . . . . . . . .  9
     5.2.  Metric Name  . . . . . . . . . . . . . . . . . . . . . . .  9
     5.3.  Metric Parameters  . . . . . . . . . . . . . . . . . . . .  9
     5.4.  Metric Units . . . . . . . . . . . . . . . . . . . . . . .  9
     5.5.  Definition . . . . . . . . . . . . . . . . . . . . . . . . 10
     5.6.  Discussion . . . . . . . . . . . . . . . . . . . . . . . . 10
     5.7.  Methodologies  . . . . . . . . . . . . . . . . . . . . . . 11

   6.  A singleton Definition for RSRD  . . . . . . . . . . . . . . . 12
     6.1.  Motivation . . . . . . . . . . . . . . . . . . . . . . . . 12
     6.2.  Metric Name  . . . . . . . . . . . . . . . . . . . . . . . 12
     6.3.  Metric Parameters  . . . . . . . . . . . . . . . . . . . . 12
     6.4.  Metric Units . . . . . . . . . . . . . . . . . . . . . . . 12
     6.5.  Definition . . . . . . . . . . . . . . . . . . . . . . . . 13
     6.6.  Discussion . . . . . . . . . . . . . . . . . . . . . . . . 13
     6.7.  Methodologies  . . . . . . . . . . . . . . . . . . . . . . 14

   7.  A singleton Definition for PRFD  . . . . . . . . . . . . . . . 15
     7.1.  Motivation . . . . . . . . . . . . . . . . . . . . . . . . 15
     7.2.  Metric Name  . . . . . . . . . . . . . . . . . . . . . . . 15
     7.3.  Metric Parameters  . . . . . . . . . . . . . . . . . . . . 15
     7.4.  Metric Units . . . . . . . . . . . . . . . . . . . . . . . 15
     7.5.  Definition . . . . . . . . . . . . . . . . . . . . . . . . 15
     7.6.  Discussion . . . . . . . . . . . . . . . . . . . . . . . . 16
     7.7.  Methodologies  . . . . . . . . . . . . . . . . . . . . . . 16

   8.  A singleton Definition for Samples of Data Path Delay PSFD  . . . . . . . . . . . . . . . 18
     8.1.  Motivation . . . . . . . . . . . . . . . . . . . . . . . . 18
     8.2.  Metric Name  . . . . . . . . . . . . . . . . . . . . . . . 18
     8.2.
     8.3.  Metric Parameters  . . . . . . . . . . . . . . . . . . . . 18
     8.3.
     8.4.  Metric Units . . . . . . . . . . . . . . . . . . . . . . . 18
     8.4.
     8.5.  Definition . . . . . . . . . . . . . . . . . . . . . . . . 18
     8.5. 19
     8.6.  Discussion . . . . . . . . . . . . . . . . . . . . . . . . 19
     8.6.
     8.7.  Methodologies  . . . . . . . . . . . . . . . . . . . . . . 19
     8.7.  Typical testing cases 20

   9.  A singleton Definition for PSRD  . . . . . . . . . . . . . . . 21
     9.1.  Motivation . . . 19
       8.7.1.  With No LSP in the Network . . . . . . . . . . . . . . 19
       8.7.2.  With a Number of LSPs in the Network . . . . . . . 21
     9.2.  Metric Name  . . . . . . . . . . . . . . . . . 20

   9.  Some Statistics Definitions for Metrics to Report . . . . . . 21
     9.1.  The Minimum of
     9.3.  Metric Parameters  . . . . . . . . . . . . . . . . . . . . 21
     9.2.  The Median of
     9.4.  Metric Units . . . . . . . . . . . . . . . . . . . . . . . 21
     9.3.  The percentile of Metric
     9.5.  Definition . . . . . . . . . . . . . . . . . . . . . . . . 21
     9.4.  The Failure Probability
     9.6.  Discussion . . . . . . . . . . . . . . . . . . . . . . 21

   10. Security Considerations . . 22
     9.7.  Methodologies  . . . . . . . . . . . . . . . . . . . . . . 22

   11. IANA Considerations

   10. A Definition for Samples of Data Path Delay  . . . . . . . . . 24
     10.1. Metric Name  . . . . . . . . . . . . . . . . . . . . 23

   12. Acknowledgements . . . 24
     10.2. Metric Parameters  . . . . . . . . . . . . . . . . . . . . 24

   13. References
     10.3. Metric Units . . . . . . . . . . . . . . . . . . . . . . . 24
     10.4. Definition . . . . 25
     13.1. Normative References . . . . . . . . . . . . . . . . . . . 25
     13.2. Informative References . 24
     10.5. Discussion . . . . . . . . . . . . . . . . . . . . . . . . 25

   Authors' Addresses
     10.6. Methodologies  . . . . . . . . . . . . . . . . . . . . . . 25
     10.7. Typical testing cases  . . . . . . 26

1.  Introduction

   Ideally, the completion of the signaling process means that . . . . . . . . . . . . 25
       10.7.1.  With No LSP in the Network  . . . . . . . . . . . . . 25
       10.7.2.  With a Number of LSPs in the Network  . . . . . . . . 25

   11. Some Statistics Definitions for Metrics to Report  . . . . . . 27
     11.1. The Minimum of Metric  . . . . . . . . . . . . . . . . . . 27
     11.2. The Median of Metric . . . . . . . . . . . . . . . . . . . 27
     11.3. The percentile of Metric . . . . . . . . . . . . . . . . . 27
     11.4. The Failure Probability  . . . . . . . . . . . . . . . . . 27
       11.4.1.  Failure Count . . . . . . . . . . . . . . . . . . . . 28
       11.4.2.  Failure Ratio . . . . . . . . . . . . . . . . . . . . 28

   12. Security Considerations  . . . . . . . . . . . . . . . . . . . 29

   13. IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 30

   14. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 31

   15. References . . . . . . . . . . . . . . . . . . . . . . . . . . 32
     15.1. Normative References . . . . . . . . . . . . . . . . . . . 32
     15.2. Informative References . . . . . . . . . . . . . . . . . . 32

   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 33

1.  Introduction

   Ideally, the completion of the signaling process means that the
   signaled label switched path (LSP) (LSP) is available and is ready to carry
   traffic.  However, in actual implementations, vendors may choose to
   program the cross connection in a pipelined manner, so that the
   overall LSP provisioning delay can be reduced.  In such situations,
   the data path may not be available instantly after the signaling
   process completes.  Implementation deficiency may also cause the
   inconsistency in between the signaling process and data path
   provisioning.  For example, if the data plane fails to program the
   cross connection accordingly but does not manage to report this to
   the control plane, the signaling process may complete successfully
   while the corresponding data path will never become functional at
   all.

   On the other hand, the completion of the signaling process may be
   used in many cases as indication of data path availability.  For
   example, when invoking through User Network Interface (UNI), a client
   device or an application may use the reception of the correct RESV
   message as indication that data path is fully functional and start to
   transmit traffic.  This will results in data loss or even application
   failure.

   Although RSVP(-TE) specifications have suggested that the cross
   connections are programmed before signaling messages are propagated
   upstream, it is still worthwhile to verify the conformance of an
   implementation and measure the delay, when necessary.

   This document defines a series of performance metrics to evaluate the
   availability of data path when the signaling process completes.  The
   metrics defined in this document complements the control plane
   metrics defined in [RFC5814].  These metrics can be used to verify
   the conformance of implementations against related specifications, as
   elaborated in [I-D.shiomoto-ccamp-switch-programming].  They also can
   be used to build more robust applications.

2.  Conventions Used in This Document

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

3.  Overview of Performance Metrics

   In this memo, we define five performance metrics to characterize the
   performance of data path provisioning with GMPLS/MPLS-TE signaling.
   These metrics complement the metrics defined in [RFC5814], in the
   sense that the completion of the signaling process for a Label
   Switched Path (LSP) and the programming of cross connections along
   the LSP may not be consistent.  The performance metrics in [RFC5814]
   characterize the performance of LSP provisioning from the pure
   signaling point of view, while the metric in this document takes into
   account the validity of the data path.

   The five metrics are:

   o  RRFD - the delay between RESV message received by ingress node and
      forward data path becomes available.

   o  RSRD - the delay between RESV message sent by egress node and
      reverse data path becomes available.

   o  PRFD - the delay between PATH message received by egress node and
      forward data path becomes available.

   o  PSFD - the delay between PATH message sent by ingress and forward
      data path becomes available.

   o  PSRD - the delay between PATH message sent by ingress and reverse
      data path becomes available.

   As in [RFC5814], we continue to use 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.  The readers are assumed to be familiar
   with the definitions in [RFC5814] as well.

4.  Terms used in this document

   o  Forward data path - the data path from the ingress to the egress.
      Instances of forward data path include the data path of a uni-
      directional LSP and data path from the ingress node to the egress
      node in a bidirectional LSP.

   o  Reverse data path - the data path from the egress to the ingress
      in a bidirectional LSP.

   o  Data path delay - the time needed to complete the data
      path configuration, in relation to the signaling process.  five
      types of data path delay are defined in this document, namely
      RRFD, RSRD and PRFD.  Data path delay used in this document must
      be distinguished from the data path transmission delay.

   o  Error free signal - data plane specific indication of availability
      of the data path.  For example, for packet switching capable
      interfaces, the reception of the first error free packet from one
      side of the LSP to the other can be used as the error free signal.
      For SDH/SONET cross connects, the disappearance of alarm can be
      used as the error free signal.  Through out this document, we will
      use the "error free signal" as a general term.  An implementations
      must choose a proper data path signal that is specific to the data
      path technology being tested.

   o  Ingress/egress node - in this memo, an ingress/egress node means a
      measurement endpoint with both control plane and data plane
      features.  Typically, the control plane part on an ingress/egress
      node interact with the control plane of the network under test.
      The data plane part of an ingress/egress node will generate data
      path signals and send the signal to the data plane of the network
      under test, or receive data path signals from the network under
      test.

5.  A singleton Definition for RRFD

   This part defines a metric for forward data path delay when an LSP is
   setup.

   As described in [I-D.shiomoto-ccamp-switch-programming], the
   completion of the RSVP-TE signaling process does not necessarily mean
   that the cross connections along the LSP being setup are in place and
   ready to carry traffic.  This metric defines the time difference
   between the reception of RESV message by the ingress node and the
   completion of the cross connection programming along the forward data
   path.

5.1.  Motivation

   RRFD is useful for several reasons:

   o  For the reasons described in
      [I-D.shiomoto-ccamp-switch-programming], the data path may not be
      available instantly after the completion of the RSVP-TE signaling
      process.  The delay itself is part of the implementation
      performance.

   o  The completion of the signaling process may be used by application
      designers as indication of data path availability.  The existence
      of this delay and the potential failure of cross connection
      programming, if not properly treated, will result in data loss or
      application failure.  The typical value of this delay can thus
      help designers to improve the application model.

5.2.  Metric Name

   RRFD

5.3.  Metric Parameters

   o  ID0, the ingress LSR ID

   o  ID1, the egress LSR ID

   o  T, a time when the setup is attempted

5.4.  Metric Units

   Either a real number of milli-seconds or undefined.

5.5.  Definition

   For a real number dT, RRFD from ingress node ID0 to egress node ID1
   at T is dT means that ingress node ID0 send a PATH message to egress
   node ID1 and the last bit of the corresponding RESV message is
   received by ingress node ID0 at T, and an error free signal is
   received by egress node ID1 by using a data plane specific test
   pattern at T+dT.

5.6.  Discussion

   The following issues are likely to come up in practice:

   o  The accuracy of RRFD depends on the clock resolution of both the
      ingress node and egress node.  Clock synchronization between the
      ingress node and egress node is required.

   o  The accuracy of RRFD is also dependent on how the error free
      signal is received and may differ significantly when the underline
      data plane technology is different.  For instance, for an LSP
      between a pair of Ethernet interfaces, the ingress node may use a
      rate based method to verify the availability of the data path and
      use the reception of the first error free frame as the error free
      signal.  In this case, the interval between two successive frames
      has a significant impact on accuracy.  It is RECOMMENDED that the
      ingress node uses small intervals, under the condition that the
      injected traffic does not exceed the capacity of the forward data
      path.  The value of the interval MUST be reported.

   o  The accuracy of RRFD is also dependent on the time needed to
      propagate the error free signal from the ingress node to the
      egress node.  A typical value of propagating the error free signal
      from the ingress node to the egress node under the same
      measurement setup MAY be reported.  The methodology to obtain such
      values is outside the scope of this document.

   o  It is possible that under some implementations, a node may program
      the cross connection before it sends PATH message further
      downstream and the data path may be available before a RESV
      message reaches the ingress node.  In such cases, RRFD can be a
      negative value.  It is RECOMMENDED that PRFD measurement is
      carried out to further characterize the forward data path delay
      when a negative RRFD value is observed.

   o  If error free signal is received by the egress node before PATH
      message is sent on the ingress node, an error MUST be reported and
      the measurement SHOULD terminate.

   o  If the corresponding RESV message is received, but no error free
      signal is received by the egress node within a reasonable period
      of time, i.e., a threshold, RRFD MUST be treated as undefined.
      The value of the threshold MUST be reported.

   o  If the LSP setup fails, the metric value MUST NOT be counted.

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  Start the data path measurement and/or monitoring procedures on
      the ingress node and egress node.  If error free signal is available and
      received by the egress node before PATH message is ready to carry
   traffic.  However, in actual implementations, vendors may choose to
   program sent, report an
      error and terminate the cross connection in a pipelined manner, so that measurement.

   o  At the ingress node, form the PATH message according to the
   overall LSP provisioning delay
      requirements and send the message towards the egress node.

   o  Upon receiving the last bit of the corresponding RESV message,
      take the time stamp (T1) on the ingress node as soon as possible.

   o  When an error free signal is observed on the egress node, take the
      time stamp (T2) as soon as possible.  An estimate of RRFD (T2 -
      T1) can be reduced.  In such situations, computed.

   o  If the corresponding RESV message arrives, but no error free
      signal is received within a reasonable period of time by the
      ingress node, RRFD is deemed to be undefined.

   o  If the LSP setup fails, RRFD is not counted.

6.  A singleton Definition for RSRD

   This part defines a metric for reverse data path may not be available instantly after delay when an LSP is
   setup.

   As described in [I-D.shiomoto-ccamp-switch-programming], the
   completion of the RSVP-TE signaling process completes.  Implementation deficiency may also cause does not necessarily mean
   that the
   inconsistency cross connections along the LSP being setup are in place and
   ready to carry traffic.  This metric defines the time difference
   between the completion of the signaling process and data path
   provisioning.  For example, if the data plane failed to program completion of
   the cross connection accordingly but does not manage to report this programming along the reverse data path.  This
   metric MAY be used together with RRFD to characterize the control plane, data path
   delay of a bidirectional LSP.

6.1.  Motivation

   RSRD is useful for several reasons:

   o  For the signaling process may complete successfully
   while reasons described in
      [I-D.shiomoto-ccamp-switch-programming], the corresponding data path will never become functional at
   all.

   On may not be
      available instantly after the other hand, completion of the RSVP-TE signaling
      process.  The delay itself is part of the implementation
      performance.

   o  The completion of the signaling process may be used in many cases by application
      designers as indication of data path availability.  For
   example, when invoking through User Network Interface (UNI), a client
   device or an application may use the reception  The existence
      of the correct RESV
   message as indication that data path is fully functional this delay and start to
   transmit traffic.  This the possible failure of cross connection
      programming, if not properly treated, will results result in data loss or even
      application failure.

   Although RSVP(-TE) specifications have suggested  The typical value of this delay can thus
      help designers to improve the application model.

6.2.  Metric Name

   RSRD

6.3.  Metric Parameters

   o  ID0, the ingress LSR ID

   o  ID1, the egress LSR ID

   o  T, a time when the setup is attempted

6.4.  Metric Units

   Either a real number of milli-seconds or undefined.

6.5.  Definition

   For a real number dT, RSRD from ingress node ID0 to egress node ID1
   at T is dT means that ingress node ID0 send a PATH message to egress
   node ID1 and the cross
   connections are programmed before signaling messages last bit of the corresponding RESV message is sent
   by egress node ID1 at T, and an error free signal is received by the
   ingress node ID0 using a data plane specific test pattern at T+dT.

6.6.  Discussion

   The following issues are propagated
   upstream, it is still worthwhile likely to verify come up in practice:

   o  The accuracy of RSRD depends on the conformance clock resolution of an
   implementation both the
      ingress node and measure egress node.  And clock synchronization between
      the delay, ingress node and egress node is required.

   o  The accuracy of RSRD is also dependent on how the error free
      signal is received and may differ significantly when necessary.

   This document defines the underline
      data plane technology is different.  For instance, for an LSP
      between a series pair of performance metrics Ethernet interfaces, the egress node (sometimes
      the tester) may use a rate based method to evaluate verify the availability
      of the data path when the signaling process completes.  The
   metrics defined in this document complements the control plane
   metrics defined in [RFC5814].  They can be used to verify and use the
   conformance reception of implementations against related specifications, as
   elaborated in [I-D.shiomoto-ccamp-switch-programming].  They also can
   be used to build more robust applications.

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 the first error free
      frame as described in [RFC2119].

3.  Overview of Performance Metrics the error free signal.  In this memo, we define three performance metrics to characterize the
   performance of data path provisioning with GMPLS/MPLS-TE signaling.
   These metrics complement case, the metrics defined in [RFC5814], interval
      between two successive frames has a significant impact on
      accuracy.  It is RECOMMENDED that in this case the
   sense egress node
      uses small intervals, under the condition that the completion injected
      traffic does not exceed the capacity of the signaling process for a Label
   Switched Path (LSP) and the programming reverse data path.
      The value of cross connections along the LSP may not interval MUST be consistent. reported.

   o  The performance metrics in [RFC5814]
   characterize the performance accuracy of LSP provisioning RSRD is also dependent on the time needed to
      propagate the error free signal from the pure
   signaling point egress node to the
      ingress node.  A typical value of view, while propagating the metric in this document takes into
   account error free
      signal from the validity of egress node to the data path. ingress node under the same
      measurement setup MAY be reported.  The three metrics are: methodology to obtain such
      values is outside the scope of this document.

   o  RRFD -  If the delay between corresponding RESV message is sent, but no error free
      signal is received by the ingress node and
      forward data path becomes available.

   o within a reasonable period
      of time, i.e., a threshold, RSRD - MUST be treated as undefined.
      The value of the delay between RESV message sent by egress node and
      reverse data path becomes available. threshold MUST be reported.

   o  PRFD - the delay between  If error free signal is received before PATH message received by egress node and
      forward data path becomes available.

   As in [RFC5814], we continue to use is sent on
      the structures and notions
   introduced ingress node, an error MUST be reported and discussed in the IPPM Framework document, [RFC2330]
   [RFC2679] [RFC2681].  The reader is assumed to be familiar with measurement
      SHOULD terminate.

   o  If the
   notions in those documents.  The readers are assumed to LSP setup fails, the metric value MUST NOT be familiar
   with counted.

6.7.  Methodologies

   Generally the definitions in [RFC5814] methodology would proceed as well.

4.  Terms used in this document follows:

   o  Forward data path - the data path from  Make sure that the ingress network has enough resource to set up the egress.
      Instances of forward data path include
      requested LSP.

   o  Start the data path of a uni-
      directional LSP and data path from measurement and/or monitoring procedures on
      the ingress node to the and egress node.  If error free signal is
      received by the ingress node in a bidirectional LSP. before PATH message is sent, report
      an error and terminate the measurement.

   o  Reverse data path -  At the data path from ingress node, form the egress PATH message according to the ingress
      in a bidirectional LSP.

   o  Error free signal - data plane specific indication of availability
      of LSP
      requirements and send the data path.  For example, for packet switched interfaces, message towards the reception of egress node.

   o  Upon sending the first error free packet from one side last bit of the
      LSP to the other can be used as corresponding RESV message, take
      the error free signal.  For SDH/
      SONET cross connects, time stamp (T1) on the disappearance of alarm can be used egress node as
      the soon as possible.

   o  When an error free signal.  Through out this document, we will use the
      "error free signal" as a general term.  An implementations must
      choose a proper data path signal that is specific to the data path
      technology being tested.

   o  Ingress/egress node - in this memo, an ingress/egress node means a
      measurement endpoint with both control plane and data plane
      features.  Typically, the control plane part observed on an ingress/egress
      node interact with the control plane of ingress node, take
      the network under test.
      The data plane part time stamp (T2) as soon as possible.  An estimate of an ingress/egress node will generate data
      path signals and send RSRD
      (T2-T1) can be computed.

   o  If the LSP setup fails, RSRD is not counted.

   o  If no error free signal to the data plane is received within a reasonable period of
      time by the network
      under test, or receive data path signals from the network under
      test.

5. ingress node, RSRD is deemed to be undefined.

7.  A singleton Definition for RRFD PRFD

   This part defines a metric for forward data path delay when an LSP is
   setup.

   As described in [I-D.shiomoto-ccamp-switch-programming], the
   completion of the

   In an RSVP-TE signaling process does not necessarily mean
   that the cross connections along the LSP being setup are in place and
   ready to carry traffic.  This metric defines the time difference
   between the reception of RESV message by the ingress implementation, when setting up an LSP, each node and the
   completion of may
   choose to program the cross connection programming along before it sends PATH message
   further downstream.  In this case, the forward data
   path.

5.1.  Motivation

   RRFD is useful for several reasons:

   o  For the reasons described in
      [I-D.shiomoto-ccamp-switch-programming], the data path may not be become
   available instantly after the completion of before the RSVP-TE signaling
      process.  The delay itself is part of process completes, ie. before the implementation
      performance.

   o  The completion of RESV
   reaches the signaling process may ingress node.  This metric can be used by application
      designers as indication of data path availability.  The existence
      of this delay to identify such
   implementation practice and give useful information to application
   designers.

7.1.  Motivation

   PRFD is useful for the potential failure of cross connection
      programming, if not properly treated, will result following reasons:

   o  PRFD can be used to identify an RSVP-TE implementation practice,
      in data loss or
      application failure. which cross connections are programmed before PATH message is
      sent downtream.

   o  The typical value of this delay can thus PRFD may also help application designers to improve the fine tune
      their application model.

5.2.

7.2.  Metric Name

   RRFD

5.3.

   PRFD

7.3.  Metric Parameters

   o  ID0, the ingress LSR ID

   o  ID1, the egress LSR ID

   o  T, a time when the setup is attempted

5.4.

7.4.  Metric Units

   Either a real number of milli-seconds or undefined.

5.5.

7.5.  Definition

   For a real number dT, RRFD PRFD from ingress node ID0 to egress node ID1
   at T is dT means that ingress node ID0 send a PATH message to egress
   node ID1 and the last bit of the corresponding RESV PATH message is received by ingress egress
   node ID0 ID1 at T, and an error free signal is received by the egress
   node ID1 by using a data plane specific test pattern at T+dT.

5.6.

7.6.  Discussion

   The following issues are likely to come up in practice:

   o  The accuracy of RRFD PRFD depends on the clock resolution of both the
      ingress node and egress
      node.  Clock  And clock synchronization between the ingress node and
      egress node is not required.

   o  The accuracy of RRFD PRFD is also dependent on how the error free
      signal is received and may differ significantly when the underline
      data plane technology is different.  For instance, for an LSP
      between a pair of Ethernet interfaces, the ingress egress node (sometimes
      the tester) may use a rate based method to verify the availability
      of the data path and use the reception of the first error free
      frame as the error free signal.  In this case, the interval
      between two successive frames has a significant impact on
      accuracy.  It is RECOMMENDED that in this case the ingress node
      uses small intervals, under the condition that the injected
      traffic does not exceed the capacity of the forward data path.
      The value of the interval MUST be reported.

   o  The accuracy of RRFD PRFD is also dependent on the time needed to
      propagate the error free signal from the ingress node to the
      egress node.  A typical value of propagating the error free signal
      from the ingress node to the egress node under the same
      measurement setup MAY be reported.  The methodology to obtain such
      values is outside the scope of this document.

   o  It is possible that under some implementations, a node may program
      the cross connection before it sends PATH message further
      downstream and the data path may be available before a RESV
      message reaches the ingress node.  In such cases, RRFD can be a
      negetive value.  It is RECOMMENDED that PRFD measurement is
      carried out to further characterize the forward data path delay
      when a negetive RRFD value is observed.

   o  If error free signal is received by the egress node before PATH message is sent, an
      error MUST be reported and the measurement SHOULD terminate.

   o  If the corresponding RESV message is received, but no error free
      signal is received by the egress node within a reasonable period
      of time, RRFD MUST be treated as undefined.  The value of the
      threshold MUST be reported.

   o  If the LSP setup fails, RRFD the metric value MUST NOT be counted.

5.7.

   o  This metric SHOULD be used together with RRFD.  It is RECOMMENDED
      that PRFD measurement is carried out after a negetive RRFD value
      has already been observed.

7.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  Start the data path measurement and/or monitoring procedures on
      the ingress node and egress node.  If error free signal is
      received by the egress node before PATH message is sent, report an
      error and terminate the mmeasurement. measurement.

   o  At the ingress node, form the PATH message according to the LSP
      requirements and send the message towards the egress node.

   o  Upon receiving the last bit of the corresponding RESV PATH message, take the time
      stamp (T1) on the ingress egress node as soon as possible.

   o  When an error free signal is observed on the egress node, take the
      time stamp (T2) as soon as possible.  An estimate of RRFD (T2 -
      T1) PRFD (T2-T1)
      can be computed.

   o  If the corresponding RESV message arrives, but LSP setup fails, PRFD is not counted.

   o  If no error free signal is received within a reasonable period of
      time by the
      ingress egress node, RRFD PRFD is deemed to be undefined.

   o  If the LSP setup fails, RRFD is not counted.

6.

8.  A singleton Definition for RSRD PSFD

   This part defines a metric for reverse forward data path delay when an LSP is
   setup.

   As described in [I-D.shiomoto-ccamp-switch-programming], the
   completion of the RSVP-TE signaling process does not necessarily mean
   that the cross connections along the LSP being setup are in place and
   ready to carry traffic.  This metric defines the time difference
   between from the completion of PATH
   message sent by the signaling process and ingress node, till the completion of the cross
   connection programming along the reverse LSP forward data path.  This
   metric MAY be used together with RRFD to characterize the data path
   delay of a bidirectional LSP.

6.1.

8.1.  Motivation

   RSRD

   PSFD is useful for several the following reasons:

   o  For the reasons described in
      [I-D.shiomoto-ccamp-switch-programming], the data path setup delay
      may not be
      available instantly after the completion of consistent with the RSVP-TE signaling
      process. control plane LSP setup delay.  The
      data path setup delay itself metric is part of the implementation
      performance. more precise for LSP setup
      performance measurement.

   o  The completion of the signaling process may be used by application
      designers as indication of data path availability.  The existence
      of this difference
      between the control plane setup delay and data path delay, and the possible
      potential failure of cross connection programming, if not properly
      treated, will result in data loss or application failure.  The typical value of this delay  This
      metric can thus help designers to improve the application model.

6.2.

8.2.  Metric Name

   RSRD

6.3.

   PSFD

8.3.  Metric Parameters

   o  ID0, the ingress LSR ID

   o  ID1, the egress LSR ID

   o  T, a time when the setup is attempted

6.4.

8.4.  Metric Units

   Either a real number of milli-seconds or undefined.

6.5.

8.5.  Definition

   For a real number dT, RSRD PSFD from ingress node ID0 to egress node ID1
   at T is dT means that ingress node ID0 send a PATH message to egress
   node ID1 and sends the last first bit of the corresponding RESV a PATH
   message is sent
   by to egress node ID1 at T, and an error free signal is received
   by the
   ingress egress node ID0 ID1 using a data plane specific test pattern at
   T+dT.

6.6.

8.6.  Discussion

   The following issues are likely to come up in practice:

   o  The accuracy of RSRD PSFD depends on the clock resolution of both the
      ingress node and egress node.  And clock synchronization between
      the ingress node and egress node is required.

   o  The accuracy of RSRD this metric is also dependent on how the error
      free signal is received and may differ significantly when the underline
      underlying data plane technology is different.  For instance, for
      an LSP between a pair of Ethernet interfaces, the egress ingress node (sometimes
      the tester) may
      use a rate based method to verify the availability of the data
      path and use the reception of the first error free frame as the
      error free signal.  In this case, the interval between two
      successive frames has a significant impact on accuracy.  It is
      RECOMMENDED that in this case the egress ingress node uses small intervals, under the
      condition that the injected traffic does not exceed the capacity
      of the reverse forward data path.  The value of the interval MUST be
      reported.

   o  The accuracy of RSRD this metric is also dependent on the time needed
      to propagate the error free signal from the egress ingress node to the
      ingress
      egress node.  A typical value of propagating the error free signal
      from the egress ingress node to the ingress egress node under the same
      measurement setup MAY be reported.  The methodology to obtain such
      values is outside the scope of this document.

   o  If the corresponding RESV error free signal is received before PATH message is sent, an
      error MUST be reported and the measurement SHOULD terminate.

   o  If the LSP setup fails, the metric value MUST NOT be counted.

   o  If the PATH message is sent by the ingress node, but no error free
      signal is received by the ingress egress node within a reasonable period
      of time, RSRD MUST be treated as undefined.  The value of the
      threshold MUST be reported.

   o  If error free signal is received before PATH message is sent, an
      error i.e., a threshold, the metric value MUST be reported and the measurement SHOULD terminate.

   o  If treated as
      undefined.  The value of the LSP setup fails, RSRD threshold MUST NOT be counted.

6.7. reported.

8.7.  Methodologies

   Generally the methodology would proceed as follows:

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

   o  Start the data path measurement and/or monitoring procedures on
      the ingress node and egress node.  If error free signal is
      received by the ingress egress node before PATH message is sent, report an
      error and terminate the mmeasurement. measurement.

   o  At the ingress node, form the PATH message according to the LSP
      requirements and send the message towards the egress node.

   o  Upon sending the last bit of  A
      timestamp (T1) may be stored locally in the corresponding RESV message, take ingress node when the time stamp (T1) on
      PATH message packet is sent towards the egress node as soon as possible. node.

   o  When an error free signal is observed on the ingress egress node, take the
      time stamp (T2) as soon as possible.  An estimate of RSRD PSFD (T2-T1)
      can be computed.

   o  If the LSP setup fails, RSRD this metric is not counted.

   o  If no error free signal is received within a reasonable period of
      time by the ingress egress node, RSRD PSFD is deemed to be undefined.

7.

9.  A singleton Definition for PRFD PSRD

   This part defines a metric for forward reverse data path delay when an LSP is
   setup.

   In an RSVP-TE implementation, when setting up an LSP, each node may
   choose to program

   This metric defines the cross connection before it time from the ingress node sends PATH message
   further downstream.  In this case, the forward data path may become
   available before PATH
   message, till the signaling process completes, ie. before completion of the RESV
   reaches cross connection programming
   along the ingress node. LSP reverse data path.  This metric can MAY be used together
   with PSFD to identify such
   implementation practice and give useful information to application
   designers.

7.1. characterize the data path delay of a bidirectional LSP.

9.1.  Motivation

   PRFD

   PSRD is useful for the following reasons:

   o  PRFD can be used to identify an RSVP-TE implementation practice,  For the reasons described in which cross connections are programmed before PATH message
      [I-D.shiomoto-ccamp-switch-programming], the data path setup delay
      may not be consistent with the control plane LSP setup delay.  The
      data path setup delay metric is
      sent downtream. more precise for LSP setup
      performance measurement.

   o  The value completion of PRFD the signaling process may also help be used by application
      designers as indication of data path availability.  The difference
      between the control plane setup delay and data path delay, and the
      potential failure of cross connection programming, if not properly
      treated, will result in data loss or application failure.  This
      metric can thus help designers to fine tune
      their improve the application model.

7.2.

9.2.  Metric Name

   PRFD

7.3.

   PSRD

9.3.  Metric Parameters

   o  ID0, the ingress LSR ID

   o  ID1, the egress LSR ID

   o  T, a time when the setup is attempted

7.4.

9.4.  Metric Units

   Either a real number of milli-seconds or undefined.

7.5.

9.5.  Definition

   For a real number dT, PRFD PSRD from ingress node ID0 to egress node ID1
   at T is dT means that ingress node ID0 send a PATH message to egress
   node ID1 and sends the last first bit of the a PATH
   message is received by to egress node ID1 at T, and an error free signal is received
   through the reverse data path by the egress ingress node ID1 ID0 using a data
   plane specific test pattern at T+dT.

7.6.

9.6.  Discussion

   The following issues are likely to come up in practice:

   o  The accuracy of PRFD PSRD depends on the clock resolution of the egress
      ingress node.  And clock synchronization between the ingress node
      and egress node is not required.

   o  The accuracy of PRFD this metric is also dependent on how the error
      free signal is received and may differ significantly when the underline
      underlying data plane technology is different.  For instance, for
      an LSP between a pair of Ethernet interfaces, the egress node (sometimes
      the tester) may
      use a rate based method to verify the availability of the data
      path and use the reception of the first error free frame as the
      error free signal.  In this case, the interval between two
      successive frames has a significant impact on accuracy.  It is
      RECOMMENDED that in this case the ingress egress node uses small intervals, under the
      condition that the injected traffic does not exceed the capacity
      of the forward data path.  The value of the interval MUST be
      reported.

   o  The accuracy of PRFD this metric is also dependent on the time needed
      to propagate the error free signal from the ingress egress node to the
      egress
      ingress node.  A typical value of propagating the error free
      signal from the ingress egress node to the egress ingress node under the same
      measurement setup MAY be reported.  The methodology to obtain such
      values is outside the scope of this document.

   o  If error free signal is received before PATH message is sent, an
      error MUST be reported and the measurement SHOULD terminate.

   o  If the LSP setup fails, PRFD this metric value MUST NOT be counted.

   o  This metric SHOULD be used together with RRFD.  It  If the PATH message is RECOMMENDED
      that PRFD measurement sent by the ingress node, but no error free
      signal is carried out after received by the ingress node within a negetive RRFD reasonable period
      of time, i.e., a threshold, the metric value
      has already been observed.

7.7. MUST be treated as
      undefined.  The value of the threshold MUST be reported.

9.7.  Methodologies

   Generally the methodology would proceed as follows:

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

   o  Start the data path measurement and/or monitoring procedures on
      the ingress node and egress node.  If error free signal is
      received by the egress node before PATH message is sent, report an
      error and terminate the mmeasurement. measurement.

   o  At the ingress node, form the PATH message according to the LSP
      requirements and send the message towards the egress node.

   o  Upon receiving  A
      timestamp (T1) may be stored locally in the last bit of ingress node when the
      PATH message, take the time
      stamp (T1) on message packet is sent towards the egress node as soon as possible. node.

   o  When an error free signal is observed on the egress ingress node, take
      the time stamp (T2) as soon as possible.  An estimate of PRFD PSFD
      (T2-T1) can be computed.

   o  If the LSP setup fails, PRFD this metric is not counted.

   o  If no error free signal is received within a reasonable period of
      time by the egress ingress node, PRFD the metric value is deemed to be
      undefined.

8.

10.  A Definition for Samples of Data Path Delay

   In Section Section 5, Section 6 and 6, Section 7, Section 8 and Section 9, we
   define the singleton metrics of data path delay.  Now we define how
   to get one particular sample of such 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.

8.1.

10.1.  Metric Name

   Type <X> Data path delay sample, where X is either RRFD, RSRD or
   PRFD.

8.2. RSRD, PRFD,
   PSFD and PSRD.

10.2.  Metric Parameters

   o  ID0, the ingress LSR ID

   o  ID1, the egress LSR ID

   o  T0, a time

   o  Tf, a time

   o  Lambda, a rate in the reciprocal seconds

   o  Th, LSP holding time

   o  Td, the maximum waiting time for successful LSP setup

   o  Ts, the maximum waiting time for error free signal

8.3.

10.3.  Metric Units

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

   o  T, a time when setup is attempted

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

8.4.

10.4.  Definition

   Given T0, Tf, and lambda, Lambda, compute a pseudo-random Poisson process
   beginning at or before T0, with average arrival rate lambda, 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 data path delay sample of
   type <X> at this time.  The value of the sample is the sequence made
   up of the resulting <time, type <X> data path delay> pairs.  If there
   are no such pairs, the sequence is of length zero and the sample is
   said to be empty.

8.5.

10.5.  Discussion

   The following issues are likely to come up in practice:

   o  The parameters lambda, Lambda, Th and Td should be carefully chosen, as
      explained in the discussions for LSP setup delay. delay (see [RFC5814]).

   o  The parameter Ts should be carefully chosen and MUST be reported
      along with the LSP forward/reverse data path delay sample.

   o  Note that for online or passive measurements, the holding time of
      an LSP is determined by actual traffic, hence in this case Th is
      not an input parameter.

8.6. be reported
      along with the LSP forward/reverse data path delay sample.

10.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 and obtain the value of type <X> data path delay

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

8.7.

10.7.  Typical testing cases

8.7.1.

10.7.1.  With No LSP in the Network

8.7.1.1.

10.7.1.1.  Motivation

   Data path delay with no LSP in the network is important because this
   reflects the inherent delay of a device implementation.  The minimum
   value provides an indication of the delay that will likely be
   experienced when an LSP data path is configured under light traffic
   load.

8.7.1.2.

10.7.1.2.  Methodologies

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

8.7.2. 10.6.

10.7.2.  With a Number of LSPs in the Network

8.7.2.1.

10.7.2.1.  Motivation

   Data path delay with a number of LSPs in the network is important
   because it reflects the performance of an operational network with
   considerable load.  This delay may vary significantly as the number
   of existing LSPs varies.  It can be used as a scalability metric of a
   device implementation.

8.7.2.2.

10.7.2.2.  Methodologies

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

9. 10.6.

11.  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 number of
   milliseconds.  In the following discussion, we only consider the
   finite values.

9.1.

11.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 SHOULD be treated as
   infinitely large.  Note that this means that the minimum could thus
   be undefined if all the dT values are undefined.  In addition, the
   metric minimum SHOULD be set to undefined if the sample is empty.

9.2.

11.2.  The Median of Metric

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

9.3.
   The Median SHOULD be set to undefined if all the dT values are
   undefined, or if the sample is empty.

11.3.  The percentile of Metric

   Given

   The "empirical distribution function" (EDF) of a metric and set of scalar
   measurements is a percent X between 0% and 100%, function F(x) which for any x gives the Xth
   percentile fractional
   proportion of all the dT values in total measurements that were <= x.

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

   See [RFC2330] for further details.

11.4.  The Failure Probability

   Given the sample is empty.

   Example: suppose samples of the performance metric, we take now offer two
   statistics of failure events of these samples to report.  The two
   statistics can be applied to both forward data path and reverse data
   path.  For example, when a sample and the results are: Stream1 =
   <<T1, 100 msec>, <T2, 110 msec>, <T3, undefined>, <T4, 90 msec>,
   <T5,500 msec>>.  Then of RRFD has been obtained the 50th percentile would
   forward data path failure statistics can be 110 msec, since 90
   msec and 100 msec are smaller, and 110 obtained, while when a
   sample of RSRD can be used to calculate the reverse data path failure
   statistics.  Detailed definitions of the Failure Count and 500 msec are larger
   (undefined values Failure
   Ratio are not counted in).

9.4.  The given below.

11.4.1.  Failure Probability

   In Count

   Failure Count is defined as the process number of LSP setup/release, it may fail for some reason. the undefined value of the
   corresponding performance metric in a sample.  The failure probability value of Failure
   Count is an integer.

11.4.2.  Failure Ratio

   Failure Ratio is the ratio percentage of the unsuccessful times number of failure events to
   the total times.

10. number of requests in a sample.  Here an failure event
   means that the signaling completes with no error, while no error free
   signal is observed.  The calculation for Failure Ratio is defined as
   follows:

   Failure Ratio = Number of undefined value/(Number of valid metric
   values + Number of undefined value) * 100%.

12.  Security Considerations

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

   In the data plane, the measurement endpoint MUST use a signal that is
   consistent with what is specified in the control plane.  For example,
   in a packet switched case, the traffic injected into the data plane
   MUST NOT exceed the specified rate in the corresponding LSP setup
   request.  In a wavelength switched case, the measurement endpoint
   MUST use the specified or negotiated lambda with appropriate power.

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

11.

13.  IANA Considerations

   This document makes no requests for IANA action.

12.

14.  Acknowledgements

   We wish to thank Adrian Farrel and Lou Berger 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.

13.

15.  References

13.1.

15.1.  Normative References

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

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

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

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

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

13.2.

15.2.  Informative References

   [I-D.shiomoto-ccamp-switch-programming]
              Shiomoto, K. and A. Farrel, "Advice on When It is Safe to
              Start Sending Data on Label Switched Paths Established
              Using RSVP-TE", draft-shiomoto-ccamp-switch-programming-01
              (work in progress), October 2009.

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

   [RFC5814]  Sun, W. and G. Zhang, "Label Switched Path (LSP) Dynamic
              Provisioning Performance Metrics in Generalized MPLS
              Networks", RFC 5814, March 2010.

Authors' Addresses

   Weiqiang Sun, Editor
   Shanghai Jiao Tong University
   800 Dongchuan Road
   Shanghai  200240
   China

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

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

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

   Jianhua Gao
   Huawei Technologies Co., LTD.
   China

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

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

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

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

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

Contributors

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

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

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

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

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

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

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

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