summaryrefslogtreecommitdiff
path: root/doc/rfc/rfc6777.txt
diff options
context:
space:
mode:
Diffstat (limited to 'doc/rfc/rfc6777.txt')
-rw-r--r--doc/rfc/rfc6777.txt1627
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]
+