doc: Add RFC documents

1 files changed, 1627 insertions, 0 deletions

diff --git a/doc/rfc/rfc6777.txt b/doc/rfc/rfc6777.txt
new file mode 100644
index 0000000..359d7bf
--- /dev/null
+++ b/doc/rfc/rfc6777.txt
@@ -0,0 +1,1627 @@
+
+
+
+
+
+
+Internet Engineering Task Force (IETF)                       W. Sun, Ed.
+Request for Comments: 6777                                          SJTU
+Category: Standards Track                                  G. Zhang, Ed.
+ISSN: 2070-1721                                                     CATR
+                                                                  J. Gao
+                                                                  Huawei
+                                                                  G. Xie
+                                                            UC Riverside
+                                                              R. Papneja
+                                                                  Huawei
+                                                           November 2012
+
+
+ Label Switched Path (LSP) Data Path Delay Metrics in Generalized MPLS
+            and MPLS Traffic Engineering (MPLS-TE) Networks
+
+Abstract
+
+   When setting up a Label Switched Path (LSP) in Generalized MPLS
+   (GMPLS) and MPLS Traffic Engineering (MPLS-TE) networks, the
+   completion of the signaling process does not necessarily mean that
+   the cross-connection along the LSP has been programmed accordingly
+   and in a timely manner.  Meanwhile, the completion of the signaling
+   process may be used by LSP users or applications that control their
+   use as an indication that the data path has become usable.  The
+   existence of the inconsistency between the signaling messages and
+   cross-connection programming, 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 way in which LSPs
+   are used and to make applications or tools that depend on and use
+   LSPs more robust.  This document defines a series of performance
+   metrics to evaluate the connectivity of the data path in the
+   signaling process.
+
+Status of This Memo
+
+   This is an Internet Standards Track document.
+
+   This document is a product of the Internet Engineering Task Force
+   (IETF).  It represents the consensus of the IETF community.  It has
+   received public review and has been approved for publication by the
+   Internet Engineering Steering Group (IESG).  Further information on
+   Internet Standards is available in Section 2 of RFC 5741.
+
+   Information about the current status of this document, any errata,
+   and how to provide feedback on it may be obtained at
+   http://www.rfc-editor.org/info/rfc6777.
+
+
+
+Sun, et al.                  Standards Track                    [Page 1]
+
+RFC 6777               LSP Data Path Delay Metrics         November 2012
+
+
+Copyright Notice
+
+   Copyright (c) 2012 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.
+
+Table of Contents
+
+   1. Introduction ....................................................4
+   2. Conventions Used in This Document ...............................5
+   3. Overview of Performance Metrics .................................5
+   4. Terms Used in This Document .....................................6
+   5. A Singleton Definition for RRFD .................................7
+      5.1. Motivation .................................................7
+      5.2. Metric Name ................................................7
+      5.3. Metric Parameters ..........................................7
+      5.4. Metric Units ...............................................7
+      5.5. Definition .................................................8
+      5.6. Discussion .................................................8
+      5.7. Methodologies ..............................................9
+   6. A Singleton Definition for RSRD ................................10
+      6.1. Motivation ................................................10
+      6.2. Metric Name ...............................................10
+      6.3. Metric Parameters .........................................10
+      6.4. Metric Units ..............................................11
+      6.5. Definition ................................................11
+      6.6. Discussion ................................................11
+      6.7. Methodologies .............................................12
+   7. A Singleton Definition for PRFD ................................13
+      7.1. Motivation ................................................13
+      7.2. Metric Name ...............................................13
+      7.3. Metric Parameters .........................................13
+      7.4. Metric Units ..............................................13
+      7.5. Definition ................................................14
+      7.6. Discussion ................................................14
+      7.7. Methodologies .............................................15
+
+
+
+
+
+
+Sun, et al.                  Standards Track                    [Page 2]
+
+RFC 6777               LSP Data Path Delay Metrics         November 2012
+
+
+   8. A Singleton Definition for PSFD ................................16
+      8.1. Motivation ................................................16
+      8.2. Metric Name ...............................................16
+      8.3. Metric Parameters .........................................16
+      8.4. Metric Units ..............................................16
+      8.5. Definition ................................................17
+      8.6. Discussion ................................................17
+      8.7. Methodologies .............................................18
+   9. A Singleton Definition for PSRD ................................19
+      9.1. Motivation ................................................19
+      9.2. Metric Name ...............................................19
+      9.3. Metric Parameters .........................................19
+      9.4. Metric Units ..............................................19
+      9.5. Definition ................................................20
+      9.6. Discussion ................................................20
+      9.7. Methodologies .............................................21
+   10. A Definition for Samples of Data Path Delay ...................22
+      10.1. Metric Name ..............................................22
+      10.2. Metric Parameters ........................................22
+      10.3. Metric Units .............................................22
+      10.4. Definition ...............................................22
+      10.5. Discussion ...............................................23
+      10.6. Methodologies ............................................23
+      10.7. Typical Testing Cases ....................................23
+           10.7.1. With No LSP in the Network ........................23
+           10.7.2. With a Number of LSPs in the Network ..............24
+   11. Some Statistics Definitions for Metrics to Report .............24
+      11.1. The Minimum of the Metric ................................24
+      11.2. The Median of the Metric .................................24
+      11.3. The Percentile of the Metric .............................24
+      11.4. Failure Probability ......................................25
+           11.4.1. Failure Count .....................................25
+           11.4.2. Failure Ratio .....................................25
+   12. Security Considerations .......................................25
+   13. References ....................................................26
+      13.1. Normative References .....................................26
+      13.2. Informative References ...................................26
+   Appendix A. Acknowledgements ......................................27
+   Appendix B. Contributors ..........................................28
+
+
+
+
+
+
+
+
+
+
+
+
+Sun, et al.                  Standards Track                    [Page 3]
+
+RFC 6777               LSP Data Path Delay Metrics         November 2012
+
+
+1.  Introduction
+
+   Label Switched Paths (LSPs) are established, controlled, and
+   allocated for use by management tools or directly by the components
+   that use them.  In this document, we call such management tools and
+   the components that use LSPs "applications".  Such applications may
+   be Network Management Systems (NMSs); hardware or software components
+   that forward data onto virtual links; programs or tools that use
+   dedicated links; or any other user of an LSP.
+
+   Ideally, the completion of the signaling process means that the
+   signaled LSP 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 ready for
+   use instantly after the signaling process completes.  Implementation
+   deficiency may also cause inconsistency 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 an indication of data path connectivity.  For
+   example, when invoking through the User-Network Interface (UNI)
+   [RFC4208], a client device or an application may use the reception of
+   the correct Resv message as an indication that the data path is fully
+   functional and start to transmit traffic.  This will result 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
+   connectivity of the data path during the signaling process.  The
+   metrics defined in this document complement the control plane metrics
+   defined in [RFC5814].  These metrics can be used to verify the
+   conformance of implementations against related specifications, as
+   elaborated in [RFC6383].  They also can be used to build more robust
+   applications.
+
+
+
+
+
+
+
+
+Sun, et al.                  Standards Track                    [Page 4]
+
+RFC 6777               LSP Data Path Delay Metrics         November 2012
+
+
+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 an 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  Resv Received, Forward Data (RRFD) - the delay between the point
+      when the Resv message is received by the ingress node and the
+      forward data path becomes ready for use.
+
+   o  Resv Sent, Reverse Data (RSRD) - the delay between the point when
+      the Resv message is sent by the egress node and the reverse data
+      path becomes ready for use.
+
+   o  PATH Received, Forward Data (PRFD) - the delay between the point
+      when the PATH message is received by the egress node and the
+      forward data path becomes ready for use.
+
+   o  PATH Sent, Forward Data (PSFD) - the delay between the point when
+      the PATH message is sent by the ingress node and the forward data
+      path becomes ready for use.
+
+   o  PATH Sent, Reverse Data (PSRD) - the delay between the point when
+      the PATH message is sent by the ingress node and the reverse data
+      path becomes ready for use.
+
+   As in [RFC5814], we continue to use the structures and notions
+   introduced and discussed in the IP Performance Metrics (IPPM)
+   Framework documents [RFC2330] [RFC2679] [RFC2681].  The reader is
+   assumed to be familiar with the notions in those documents.  The
+   reader is also assumed to be familiar with the definitions in
+   [RFC5814].
+
+
+
+
+
+Sun, et al.                  Standards Track                    [Page 5]
+
+RFC 6777               LSP Data Path Delay Metrics         November 2012
+
+
+4.  Terms Used in This Document
+
+   o  Forward data path - the data path from the ingress node to the
+      egress node.  Instances of a forward data path include the data
+      path of a unidirectional LSP and a data path from the ingress node
+      to the egress node in a bidirectional LSP.
+
+   o  Reverse data path - the data path from the egress node to the
+      ingress node 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, PRFD, PSFD, and PSRD.  Data path delay as used in this
+      document must be distinguished from the transmission delay along
+      the data path, i.e., the time needed to transmit traffic from one
+      side of the data path to the other.
+
+   o  Error-free signal - data-plane-specific indication of connectivity
+      of the data path.  For example, for interfaces capable of packet
+      switching, the reception of the first error-free packet from one
+      side of the LSP to the other may be used as the error-free signal.
+      For Synchronous Digital Hierarchy/Synchronous Optical Network
+      (SDH/SONET) cross-connects, the disappearance of alarm can be used
+      as the error-free signal.  Throughout this document, we will use
+      "error-free signal" as a general term.  An implementation 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 interacts 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.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Sun, et al.                  Standards Track                    [Page 6]
+
+RFC 6777               LSP Data Path Delay Metrics         November 2012
+
+
+5.  A Singleton Definition for RRFD
+
+   This part defines a metric for forward data path delay when an LSP is
+   set up.
+
+   As described in [RFC6383], the completion of the RSVP-TE signaling
+   process does not necessarily mean that the cross-connections along
+   the LSP being set up are in place and ready to carry traffic.  This
+   metric defines the time difference between the reception of a 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 the following reasons:
+
+   o  For the reasons described in [RFC6383], the data path may not be
+      ready for use 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 an indication of data path connectivity.  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 = Resv Received, Forward Data path
+
+5.3.  Metric Parameters
+
+   o  ID0, the ingress Label Switching Router (LSR) ID
+
+   o  ID1, the egress LSR ID
+
+   o  T, a time when the setup is attempted
+
+5.4.  Metric Units
+
+   The value of RRFD is either a real number of milliseconds or
+   undefined.
+
+
+
+
+
+
+
+Sun, et al.                  Standards Track                    [Page 7]
+
+RFC 6777               LSP Data Path Delay Metrics         November 2012
+
+
+5.5.  Definition
+
+   For a real number dT,
+
+      RRFD from ingress node ID0 to egress node ID1 at T is dT
+
+   means that
+
+   o  ingress node ID0 sends a PATH message to egress node ID1,
+
+   o  the last bit of the corresponding Resv message is received by
+      ingress node ID0 at T, and
+
+   o  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
+      underlying 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 connectivity 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 use small intervals, under the
+      condition that the injected traffic does not exceed the capacity
+      of the forward data path.  The value of such intervals 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 for 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  The accuracy of this metric is also dependent on the physical-
+      layer serialization/deserialization of the test signal for certain
+      data path technologies.  For instance, for an LSP between a pair
+
+
+
+
+Sun, et al.                  Standards Track                    [Page 8]
+
+RFC 6777               LSP Data Path Delay Metrics         November 2012
+
+
+      of low-speed Ethernet interfaces, the time needed to serialize/
+      deserialize a large frame may not be negligible.  In this case, it
+      is RECOMMENDED that the ingress node use small frames.  The
+      average length of the frame MAY be reported.
+
+   o  It is possible that under some implementations, a node may program
+      the cross-connection before it sends a PATH message further
+      downstream, and the data path may be ready for use before a Resv
+      message reaches the ingress node.  In such cases, RRFD can be a
+      negative value.  It is RECOMMENDED that a PRFD measurement be
+      carried out to further characterize the forward data path delay
+      when a negative RRFD value is observed.
+
+   o  If an error-free signal is received by the egress node before a
+      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, this metric value MUST NOT be counted.
+
+5.7.  Methodologies
+
+   Generally, the methodology would proceed as follows:
+
+   o  Make sure that the network has enough resources to set up the
+      requested LSP.
+
+   o  Start the data path measurement and/or monitoring procedures on
+      the ingress node and egress node.  If an error-free signal is
+      received by the egress node before a PATH message is sent, report
+      an error and terminate the 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 message,
+      take the timestamp (T1) on the ingress node as soon as possible.
+
+   o  When an error-free signal is observed on the egress node, take the
+      timestamp (T2) as soon as possible.  An estimate of RRFD (T2 - T1)
+      can be computed.
+
+
+
+
+
+
+Sun, et al.                  Standards Track                    [Page 9]
+
+RFC 6777               LSP Data Path Delay Metrics         November 2012
+
+
+   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 delay when an LSP is
+   set up.
+
+   As described in [RFC6383], the completion of the RSVP-TE signaling
+   process does not necessarily mean that the cross-connections along
+   the LSP being set up are in place and ready to carry traffic.  This
+   metric defines the time difference between the completion of the
+   signaling process and the completion of the cross-connection
+   programming along the reverse data path.  This metric MAY be used
+   together with RRFD to characterize the data path delay of a
+   bidirectional LSP.
+
+6.1.  Motivation
+
+   RSRD is useful for the following reasons:
+
+   o  For the reasons described in [RFC6383], the data path may not be
+      ready for use 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 an indication of data path connectivity.  The
+      existence of this delay and the possible 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.
+
+6.2.  Metric Name
+
+   RSRD = Resv Sent, Reverse Data path
+
+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
+
+
+
+
+Sun, et al.                  Standards Track                   [Page 10]
+
+RFC 6777               LSP Data Path Delay Metrics         November 2012
+
+
+6.4.  Metric Units
+
+   The value of RSRD is either a real number of milliseconds 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
+
+   o  ingress node ID0 sends a PATH message to egress node ID1,
+
+   o  the last bit of the corresponding Resv message is sent by egress
+      node ID1 at T, and
+
+   o  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 likely to come up in practice:
+
+   o  The accuracy of RSRD 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 RSRD is also dependent on how the error-free
+      signal is received and may differ significantly when the
+      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
+      connectivity 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 in this case that the egress node use
+      small intervals, under the condition that the injected traffic
+      does not exceed the capacity of the reverse data path.  The value
+      of the interval MUST be reported.
+
+   o  The accuracy of RSRD is also dependent on the time needed to
+      propagate the error-free signal from the egress node to the
+      ingress node.  A typical value for propagating the error-free
+      signal from the egress node to the ingress node under the same
+      measurement setup MAY be reported.  The methodology to obtain such
+      values is outside the scope of this document.
+
+
+
+Sun, et al.                  Standards Track                   [Page 11]
+
+RFC 6777               LSP Data Path Delay Metrics         November 2012
+
+
+   o  The accuracy of this metric is also dependent on the physical-
+      layer serialization/deserialization of the test signal for certain
+      data path technologies.  For instance, for an LSP between a pair
+      of low-speed Ethernet interfaces, the time needed to serialize/
+      deserialize a large frame may not be negligible.  In this case, it
+      is RECOMMENDED that the egress node use small frames.  The average
+      length of the frame MAY be reported.
+
+   o  If the corresponding Resv message is sent but no error-free signal
+      is received by the ingress node within a reasonable period of
+      time, i.e., a threshold, RSRD MUST be treated as undefined.  The
+      value of the threshold MUST be reported.
+
+   o  If an error-free signal is received before a PATH message is sent
+      on the ingress node, an error MUST be reported and the measurement
+      SHOULD terminate.
+
+   o  If the LSP setup fails, this metric value MUST NOT be counted.
+
+6.7.  Methodologies
+
+   Generally, the methodology would proceed as follows:
+
+   o  Make sure that the network has enough resources to set up the
+      requested LSP.
+
+   o  Start the data path measurement and/or monitoring procedures on
+      the ingress node and egress node.  If an error-free signal is
+      received by the ingress node before a PATH message is sent, report
+      an error and terminate the 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 the corresponding Resv message, take
+      the timestamp (T1) on the egress node as soon as possible.
+
+   o  When an error-free signal is observed on the ingress node, take
+      the timestamp (T2) as soon as possible.  An estimate of RSRD
+      (T2 - T1) can be computed.
+
+   o  If the LSP setup fails, RSRD is not counted.
+
+   o  If no error-free signal is received within a reasonable period of
+      time by the ingress node, RSRD is deemed to be undefined.
+
+
+
+
+
+
+Sun, et al.                  Standards Track                   [Page 12]
+
+RFC 6777               LSP Data Path Delay Metrics         November 2012
+
+
+7.  A Singleton Definition for PRFD
+
+   This part defines a metric for forward data path delay when an LSP is
+   set up.
+
+   In an RSVP-TE implementation, when setting up an LSP, each node may
+   choose to program the cross-connection before it sends a PATH message
+   further downstream.  In this case, the forward data path may become
+   ready for use before the signaling process completes, i.e., before
+   the Resv message reaches the ingress node.  This metric can be used
+   to identify such an implementation practice and give useful
+   information to application designers.
+
+7.1.  Motivation
+
+   PRFD is useful for the following reasons:
+
+   o  PRFD can be used to identify an RSVP-TE implementation practice in
+      which cross-connections are programmed before a PATH message is
+      sent downstream.
+
+   o  The value of PRFD may also help application designers to fine-tune
+      their application model.
+
+7.2.  Metric Name
+
+   PRFD = PATH Received, Forward Data path
+
+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
+
+7.4.  Metric Units
+
+   The value of PRFD is either a real number of milliseconds or
+   undefined.
+
+
+
+
+
+
+
+
+
+
+
+Sun, et al.                  Standards Track                   [Page 13]
+
+RFC 6777               LSP Data Path Delay Metrics         November 2012
+
+
+7.5.  Definition
+
+   For a real number dT,
+
+      PRFD from ingress node ID0 to egress node ID1 at T is dT
+
+   means that
+
+   o  ingress node ID0 sends a PATH message to egress node ID1,
+
+   o  the last bit of the PATH message is received by egress node ID1 at
+      T, and
+
+   o  an error-free signal is received by the egress node ID1 using a
+      data-plane-specific test pattern at T+dT.
+
+7.6.  Discussion
+
+   The following issues are likely to come up in practice:
+
+   o  The accuracy of PRFD depends on the clock resolution of the egress
+      node.  Clock synchronization between the ingress node and egress
+      node is not required.
+
+   o  The accuracy of PRFD is also dependent on how the error-free
+      signal is received and may differ significantly when the
+      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
+      connectivity 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 in this case that the ingress node
+      use 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 is also dependent on the time needed to
+      propagate the error-free signal from the ingress node to the
+      egress node.  A typical value for 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  The accuracy of this metric is also dependent on the physical-
+      layer serialization/deserialization of the test signal for certain
+      data path technologies.  For instance, for an LSP between a pair
+
+
+
+
+Sun, et al.                  Standards Track                   [Page 14]
+
+RFC 6777               LSP Data Path Delay Metrics         November 2012
+
+
+      of low-speed Ethernet interfaces, the time needed to serialize/
+      deserialize a large frame may not be negligible.  In this case, it
+      is RECOMMENDED that the ingress node use small frames.  The
+      average length of the frame MAY be reported.
+
+   o  If an error-free signal is received before a PATH message is sent,
+      an error MUST be reported and the measurement SHOULD terminate.
+
+   o  If the LSP setup fails, this metric value MUST NOT be counted.
+
+   o  This metric SHOULD be used together with RRFD.  It is RECOMMENDED
+      that a PRFD measurement be carried out after a negative RRFD value
+      has already been observed.
+
+7.7.  Methodologies
+
+   Generally, the methodology would proceed as follows:
+
+   o  Make sure that the network has enough resources to set up the
+      requested LSP.
+
+   o  Start the data path measurement and/or monitoring procedures on
+      the ingress node and egress node.  If an error-free signal is
+      received by the egress node before a PATH message is sent, report
+      an error and terminate the 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 PATH message, take the
+      timestamp (T1) on the egress node as soon as possible.
+
+   o  When an error-free signal is observed on the egress node, take the
+      timestamp (T2) as soon as possible.  An estimate of PRFD (T2 - T1)
+      can be computed.
+
+   o  If the LSP setup fails, PRFD is not counted.
+
+   o  If no error-free signal is received within a reasonable period of
+      time by the egress node, PRFD is deemed to be undefined.
+
+
+
+
+
+
+
+
+
+
+
+Sun, et al.                  Standards Track                   [Page 15]
+
+RFC 6777               LSP Data Path Delay Metrics         November 2012
+
+
+8.  A Singleton Definition for PSFD
+
+   This part defines a metric for forward data path delay when an LSP is
+   set up.
+
+   As described in [RFC6383], the completion of the RSVP-TE signaling
+   process does not necessarily mean that the cross-connections along
+   the LSP being set up are in place and ready to carry traffic.  This
+   metric defines the time difference between the point when the PATH
+   message is sent by the ingress node and the completion of the cross-
+   connection programming along the LSP forward data path.
+
+8.1.  Motivation
+
+   PSFD is useful for the following reasons:
+
+   o  For the reasons described in [RFC6383], the data path setup delay
+      may not be consistent with the control plane LSP setup delay.  The
+      data path setup delay metric is more precise for LSP setup
+      performance measurement.
+
+   o  The completion of the signaling process may be used by application
+      designers as an indication of data path connectivity.  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 improve the
+      application model.
+
+8.2.  Metric Name
+
+   PSFD = PATH Sent, Forward Data path
+
+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
+
+8.4.  Metric Units
+
+   The value of PSFD is either a real number of milliseconds or
+   undefined.
+
+
+
+
+
+
+Sun, et al.                  Standards Track                   [Page 16]
+
+RFC 6777               LSP Data Path Delay Metrics         November 2012
+
+
+8.5.  Definition
+
+   For a real number dT,
+
+      PSFD from ingress node ID0 to egress node ID1 at T is dT
+
+   means that
+
+   o  ingress node ID0 sends the first bit of a PATH message to egress
+      node ID1 at T, and
+
+   o  an error-free signal is received by the egress node ID1 using a
+      data-plane-specific test pattern at T+dT.
+
+8.6.  Discussion
+
+   The following issues are likely to come up in practice:
+
+   o  The accuracy of PSFD 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 PSFD is also dependent on how the error-free
+      signal is received and may differ significantly when the
+      underlying 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 connectivity 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 use 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 PSFD is also dependent on the time needed to
+      propagate the error-free signal from the ingress node to the
+      egress node.  A typical value for 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  The accuracy of this metric is also dependent on the physical-
+      layer serialization/deserialization of the test signal for certain
+      data path technologies.  For instance, for an LSP between a pair
+
+
+
+
+
+
+Sun, et al.                  Standards Track                   [Page 17]
+
+RFC 6777               LSP Data Path Delay Metrics         November 2012
+
+
+      of low-speed Ethernet interfaces, the time needed to serialize/
+      deserialize a large frame may not be negligible.  In this case, it
+      is RECOMMENDED that the ingress node use small frames.  The
+      average length of the frame MAY be reported.
+
+   o  If an error-free signal is received before a PATH message is sent,
+      an error MUST be reported and the measurement SHOULD terminate.
+
+   o  If the LSP setup fails, this 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 egress node within a reasonable period
+      of time, i.e., a threshold, PSFD MUST be treated as undefined.
+      The value of the threshold MUST be reported.
+
+8.7.  Methodologies
+
+   Generally, the methodology would proceed as follows:
+
+   o  Make sure that the network has enough resources to set up the
+      requested LSP.
+
+   o  Start the data path measurement and/or monitoring procedures on
+      the ingress node and egress node.  If an error-free signal is
+      received by the egress node before a PATH message is sent, report
+      an error and terminate the measurement.
+
+   o  At the ingress node, form the PATH message according to the LSP
+      requirements and send the message towards the egress node.  A
+      timestamp (T1) may be stored locally in the ingress node when the
+      PATH message packet is sent towards the egress node.
+
+   o  When an error-free signal is observed on the egress node, take the
+      timestamp (T2) as soon as possible.  An estimate of PSFD (T2 - T1)
+      can be computed.
+
+   o  If the LSP setup fails, PSFD is not counted.
+
+   o  If no error-free signal is received within a reasonable period of
+      time by the egress node, PSFD is deemed to be undefined.
+
+
+
+
+
+
+
+
+
+
+
+Sun, et al.                  Standards Track                   [Page 18]
+
+RFC 6777               LSP Data Path Delay Metrics         November 2012
+
+
+9.  A Singleton Definition for PSRD
+
+   This part defines a metric for reverse data path delay when an LSP is
+   set up.
+
+   This metric defines the time difference between the point when the
+   ingress node sends the PATH message and the completion of the cross-
+   connection programming along the LSP reverse data path.  This metric
+   MAY be used together with PSFD to characterize the data path delay of
+   a bidirectional LSP.
+
+9.1.  Motivation
+
+   PSRD is useful for the following reasons:
+
+   o  For the reasons described in [RFC6383], the data path setup delay
+      may not be consistent with the control plane LSP setup delay.  The
+      data path setup delay metric is more precise for LSP setup
+      performance measurement.
+
+   o  The completion of the signaling process may be used by application
+      designers as an indication of data path connectivity.  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 improve the
+      application model.
+
+9.2.  Metric Name
+
+   PSRD = PATH Sent, Reverse Data path
+
+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
+
+9.4.  Metric Units
+
+   The value of PSRD is either a real number of milliseconds or
+   undefined.
+
+
+
+
+
+
+
+Sun, et al.                  Standards Track                   [Page 19]
+
+RFC 6777               LSP Data Path Delay Metrics         November 2012
+
+
+9.5.  Definition
+
+   For a real number dT,
+
+      PSRD from ingress node ID0 to egress node ID1 at T is dT
+
+   means that
+
+   o  ingress node ID0 sends the first bit of a PATH message to egress
+      node ID1 at T, and
+
+   o  an error-free signal is received through the reverse data path
+      by the ingress node ID0 using a data-plane-specific test pattern
+      at T+dT.
+
+9.6.  Discussion
+
+   The following issues are likely to come up in practice:
+
+   o  The accuracy of PSRD depends on the clock resolution of the
+      ingress node.  Clock synchronization between the ingress node and
+      egress node is not required.
+
+   o  The accuracy of PSRD is also dependent on how the error-free
+      signal is received and may differ significantly when the
+      underlying data plane technology is different.  For instance, for
+      an LSP between a pair of Ethernet interfaces, the egress node may
+      use a rate-based method to verify the connectivity 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 egress node use 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 PSRD is also dependent on the time needed to
+      propagate the error-free signal from the egress node to the
+      ingress node.  A typical value for propagating the error-free
+      signal from the egress node to the ingress node under the same
+      measurement setup MAY be reported.  The methodology to obtain such
+      values is outside the scope of this document.
+
+   o  The accuracy of this metric is also dependent on the physical-
+      layer serialization/deserialization of the test signal for certain
+      data path technologies.  For instance, for an LSP between a pair
+
+
+
+
+
+Sun, et al.                  Standards Track                   [Page 20]
+
+RFC 6777               LSP Data Path Delay Metrics         November 2012
+
+
+      of low-speed Ethernet interfaces, the time needed to serialize/
+      deserialize a large frame may not be negligible.  In this case, it
+      is RECOMMENDED that the egress node use small frames.  The average
+      length of the frame MAY be reported.
+
+   o  If an error-free signal is received before a PATH message is sent,
+      an error MUST be reported and the measurement SHOULD terminate.
+
+   o  If the LSP setup fails, this 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 node within a reasonable period
+      of time, i.e., a threshold, PSRD 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 resources to set up the
+      requested LSP.
+
+   o  Start the data path measurement and/or monitoring procedures on
+      the ingress node and egress node.  If an error-free signal is
+      received by the egress node before a PATH message is sent, report
+      an error and terminate the measurement.
+
+   o  At the ingress node, form the PATH message according to the LSP
+      requirements and send the message towards the egress node.  A
+      timestamp (T1) may be stored locally in the ingress node when the
+      PATH message packet is sent towards the egress node.
+
+   o  When an error-free signal is observed on the ingress node, take
+      the timestamp (T2) as soon as possible.  An estimate of PSRD
+      (T2 - T1) can be computed.
+
+   o  If the LSP setup fails, PSRD is not counted.
+
+   o  If no error-free signal is received within a reasonable period of
+      time by the ingress node, PSRD is deemed to be undefined.
+
+
+
+
+
+
+
+
+
+
+
+Sun, et al.                  Standards Track                   [Page 21]
+
+RFC 6777               LSP Data Path Delay Metrics         November 2012
+
+
+10.  A Definition for Samples of Data Path Delay
+
+   In Sections 5, 6, 7, 8, and 9, we defined the singleton metrics of
+   data path delay.  Now, we define how to get one particular sample of
+   such a delay.  Sampling is done to select a particular portion of
+   singleton values of the given parameters.  As in [RFC2330], we use
+   Poisson sampling as an example.
+
+10.1.  Metric Name
+
+   Type <X> data path delay sample, where X is either RRFD, RSRD, PRFD,
+   PSFD, or 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 reciprocal milliseconds
+
+   o  Th, the LSP holding time
+
+   o  Td, the maximum waiting time for successful LSP setup
+
+   o  Ts, the maximum waiting time for an error-free signal
+
+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 milliseconds or undefined
+
+10.4.  Definition
+
+   Given T0, Tf, and Lambda, compute a pseudo-random Poisson process
+   beginning at or before T0, with average arrival rate Lambda, and
+   ending at or after Tf.  Those time values greater than or equal to T0
+   and less than or equal to Tf are then selected.  At each of the times
+   in this process, we obtain the value of a data path delay sample of
+   type <X> at this time.  The value of the sample is the sequence made
+
+
+
+
+Sun, et al.                  Standards Track                   [Page 22]
+
+RFC 6777               LSP Data Path Delay Metrics         November 2012
+
+
+   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.
+
+10.5.  Discussion
+
+   The following issues are likely to come up in practice:
+
+   o  The parameters Lambda, Th, and Td should be carefully chosen, as
+      explained in the discussions for LSP setup 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.
+
+10.6.  Methodologies
+
+   Generally, the methodology would proceed as follows:
+
+   o  Select specific times, using the specified Poisson arrival
+      process.
+
+   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.
+
+10.7.  Typical Testing Cases
+
+10.7.1.  With No LSP in the Network
+
+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.
+
+10.7.1.2.  Methodologies
+
+   Make sure that there is no LSP in the network, and proceed with the
+   methodologies described in Section 10.6.
+
+
+
+
+
+
+
+
+
+Sun, et al.                  Standards Track                   [Page 23]
+
+RFC 6777               LSP Data Path Delay Metrics         November 2012
+
+
+10.7.2.  With a Number of LSPs in the Network
+
+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.
+
+10.7.2.2.  Methodologies
+
+   o  Set up the required number of LSPs.
+
+   o  Wait until the network reaches a stable state.
+
+   o  Then proceed with the methodologies described in Section 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 regarding a GMPLS network.  The value of
+   these metrics is either a real number of milliseconds or undefined.
+   In the following discussion, we only consider the finite values.
+
+11.1.  The Minimum of the Metric
+
+   The minimum of the metric is the minimum of all the dT values in the
+   sample.  In computing this, undefined values SHOULD be treated as
+   infinitely large.  Note that this means that the minimum could thus
+   be undefined if all the dT values are undefined.  In addition, the
+   metric minimum SHOULD be set to undefined if the sample is empty.
+
+11.2.  The Median of the Metric
+
+   The median of the metric is the median of the dT values in the given
+   sample.  In computing the median, the undefined values MUST NOT be
+   included.  The median SHOULD be set to undefined if all the dT values
+   are undefined, or if the sample is empty.  When the number of defined
+   values in the given sample is small, the metric median may not be
+   typical and SHOULD be used carefully.
+
+11.3.  The Percentile of the Metric
+
+   The "empirical distribution function" (EDF) of a set of scalar
+   measurements is a function F(x), which, for any x, gives the
+   fractional proportion of the total measurements that were <= x.
+
+
+
+Sun, et al.                  Standards Track                   [Page 24]
+
+RFC 6777               LSP Data Path Delay Metrics         November 2012
+
+
+   Given a percentage X, the Xth percentile of the metric means the
+   smallest value of x for which F(x) >= X.  In computing the
+   percentile, undefined values MUST NOT be included.
+
+   See [RFC2330] for further details.
+
+11.4.  Failure Probability
+
+   Given the samples of the performance metric, we now offer two
+   statistics of failure events of these samples to report: Failure
+   Count and Failure Ratio.  The two statistics can be applied to both
+   the forward data path and reverse data path.  For example, when a
+   sample of RRFD has been obtained, the forward data path failure
+   statistics can be obtained, while a sample of RSRD can be used to
+   calculate the reverse data path failure statistics.  Detailed
+   definitions of Failure Count and Failure Ratio are given below.
+
+11.4.1.  Failure Count
+
+   Failure Count is defined as the number of the undefined value of the
+   corresponding performance metric in a sample.  The value of Failure
+   Count is an integer.
+
+11.4.2.  Failure Ratio
+
+   Failure Ratio is the percentage of the number of failure events to
+   the total number of requests in a sample.  Here, a 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 security issues other 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
+
+
+
+Sun, et al.                  Standards Track                   [Page 25]
+
+RFC 6777               LSP Data Path Delay Metrics         November 2012
+
+
+   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.
+
+13.  References
+
+13.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.  Informative References
+
+   [RFC2330]  Paxson, V., Almes, G., Mahdavi, J., and M. Mathis,
+              "Framework for IP Performance Metrics", RFC 2330,
+              May 1998.
+
+   [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.
+
+   [RFC5814]  Sun, W. and G. Zhang, "Label Switched Path (LSP) Dynamic
+              Provisioning Performance Metrics in Generalized MPLS
+              Networks", RFC 5814, March 2010.
+
+   [RFC6383]  Shiomoto, K. and A. Farrel, "Advice on When It Is Safe to
+              Start Sending Data on Label Switched Paths Established
+              Using RSVP-TE", RFC 6383, September 2011.
+
+
+
+
+Sun, et al.                  Standards Track                   [Page 26]
+
+RFC 6777               LSP Data Path Delay Metrics         November 2012
+
+
+Appendix A.  Acknowledgements
+
+   We wish to thank Adrian Farrel, Lou Berger, and Al Morton for their
+   comments and help.  We also wish to thank Klaas Wierenga and Alexey
+   Melnikov for their reviews.
+
+   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 their valuable comments.  We also wish to thank the
+   National Natural Science Foundation of China (NSFC) and the
+   863 program of China for their support.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Sun, et al.                  Standards Track                   [Page 27]
+
+RFC 6777               LSP Data Path Delay Metrics         November 2012
+
+
+Appendix B.  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: tm-otani@kddi.com
+
+
+   Ruiquan Jing
+   China Telecom Beijing Research Institute
+   118 Xizhimenwai Avenue
+   Beijing  100035
+   China
+
+   Phone: +86-10-58552000
+   EMail: jingrq@ctbri.com.cn
+
+
+
+
+
+
+
+
+
+
+
+Sun, et al.                  Standards Track                   [Page 28]
+
+RFC 6777               LSP Data Path Delay Metrics         November 2012
+
+
+Authors' Addresses
+
+   Weiqiang Sun (editor)
+   Shanghai Jiao Tong University
+   800 Dongchuan Road
+   Shanghai  200240
+   China
+
+   Phone: +86 21 3420 5359
+   EMail: sun.weiqiang@gmail.com
+
+
+   Guoying Zhang (editor)
+   China Academy of Telecommunication Research, MIIT, China
+   No. 52 Hua Yuan Bei Lu, Haidian District
+   Beijing  100191
+   China
+
+   Phone: +86 1062300103
+   EMail: zhangguoying@catr.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
+   Huawei Technologies
+   Santa Clara, CA  95050
+   Reston, VA  20190
+   USA
+
+   EMail: rajiv.papneja@huawei.com
+
+
+
+
+Sun, et al.                  Standards Track                   [Page 29]
+