draft-ietf-ccamp-dpm-08.txt   rfc6777.txt 
Network Working Group W. Sun, Ed. Internet Engineering Task Force (IETF) W. Sun, Ed.
Internet-Draft SJTU Request for Comments: 6777 SJTU
Intended status: Standards Track G. Zhang, Ed. Category: Standards Track G. Zhang, Ed.
Expires: March 5, 2013 CATR ISSN: 2070-1721 CATR
September 1, 2012 J. Gao
Huawei
G. Xie
UC Riverside
R. Papneja
Huawei
November 2012
Label Switched Path (LSP) Data Path Delay Metrics in Generalized MPLS/ Label Switched Path (LSP) Data Path Delay Metrics in Generalized MPLS
MPLS-TE Networks and MPLS Traffic Engineering (MPLS-TE) Networks
draft-ietf-ccamp-dpm-08.txt
Abstract Abstract
When setting up a label switched path (LSP) in Generalized MPLS and When setting up a Label Switched Path (LSP) in Generalized MPLS
MPLS/TE networks, the completion of the signaling process does not (GMPLS) and MPLS Traffic Engineering (MPLS-TE) networks, the
necessarily mean that the cross connection along the LSP have been completion of the signaling process does not necessarily mean that
programmed accordingly and in a timely manner. Meanwhile, the the cross-connection along the LSP has been programmed accordingly
completion of signaling process may be used by LSP users or and in a timely manner. Meanwhile, the completion of the signaling
applications that control their use as indication that data path has process may be used by LSP users or applications that control their
become usable. The existence of the inconsistency between the use as an indication that the data path has become usable. The
signaling messages and cross connection programing, and the possible existence of the inconsistency between the signaling messages and
failure of cross connection programming, if not properly treated, cross-connection programming, and the possible failure of cross-
will result in data loss or even application failure. connection programming, if not properly treated, will result in data
Characterization of this performance can thus help designers to loss or even application failure. Characterization of this
improve the way in which LSPs are used and to make applications or performance can thus help designers to improve the way in which LSPs
tools that depend on and use LSPs more robust. This document defines are used and to make applications or tools that depend on and use
a series of performance metrics to evaluate the connectivity of data LSPs more robust. This document defines a series of performance
path in the signaling process. metrics to evaluate the connectivity of the data path in the
signaling process.
Status of this Memo
This Internet-Draft is submitted in full conformance with the Status of This Memo
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering This is an Internet Standards Track document.
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months This document is a product of the Internet Engineering Task Force
and may be updated, replaced, or obsoleted by other documents at any (IETF). It represents the consensus of the IETF community. It has
time. It is inappropriate to use Internet-Drafts as reference received public review and has been approved for publication by the
material or to cite them other than as "work in progress." Internet Engineering Steering Group (IESG). Further information on
Internet Standards is available in Section 2 of RFC 5741.
This Internet-Draft will expire on March 5, 2013. 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.
Copyright Notice Copyright Notice
Copyright (c) 2012 IETF Trust and the persons identified as the Copyright (c) 2012 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
skipping to change at page 2, line 19 skipping to change at page 2, line 22
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 5 1. Introduction ....................................................4
2. Conventions Used in This Document ...............................5
2. Conventions Used in This Document . . . . . . . . . . . . . . 6 3. Overview of Performance Metrics .................................5
4. Terms Used in This Document .....................................6
3. Overview of Performance Metrics . . . . . . . . . . . . . . . 7 5. A Singleton Definition for RRFD .................................7
5.1. Motivation .................................................7
4. Terms used in this document . . . . . . . . . . . . . . . . . 8 5.2. Metric Name ................................................7
5.3. Metric Parameters ..........................................7
5. A singleton Definition for RRFD . . . . . . . . . . . . . . . 9 5.4. Metric Units ...............................................7
5.1. Motivation . . . . . . . . . . . . . . . . . . . . . . . . 9 5.5. Definition .................................................8
5.2. Metric Name . . . . . . . . . . . . . . . . . . . . . . . 9 5.6. Discussion .................................................8
5.3. Metric Parameters . . . . . . . . . . . . . . . . . . . . 9 5.7. Methodologies ..............................................9
5.4. Metric Units . . . . . . . . . . . . . . . . . . . . . . . 9 6. A Singleton Definition for RSRD ................................10
5.5. Definition . . . . . . . . . . . . . . . . . . . . . . . . 9 6.1. Motivation ................................................10
5.6. Discussion . . . . . . . . . . . . . . . . . . . . . . . . 10 6.2. Metric Name ...............................................10
5.7. Methodologies . . . . . . . . . . . . . . . . . . . . . . 11 6.3. Metric Parameters .........................................10
6.4. Metric Units ..............................................11
6. A singleton Definition for RSRD . . . . . . . . . . . . . . . 12 6.5. Definition ................................................11
6.1. Motivation . . . . . . . . . . . . . . . . . . . . . . . . 12 6.6. Discussion ................................................11
6.2. Metric Name . . . . . . . . . . . . . . . . . . . . . . . 12 6.7. Methodologies .............................................12
6.3. Metric Parameters . . . . . . . . . . . . . . . . . . . . 12 7. A Singleton Definition for PRFD ................................13
6.4. Metric Units . . . . . . . . . . . . . . . . . . . . . . . 12 7.1. Motivation ................................................13
6.5. Definition . . . . . . . . . . . . . . . . . . . . . . . . 13 7.2. Metric Name ...............................................13
6.6. Discussion . . . . . . . . . . . . . . . . . . . . . . . . 13 7.3. Metric Parameters .........................................13
6.7. Methodologies . . . . . . . . . . . . . . . . . . . . . . 14 7.4. Metric Units ..............................................13
7.5. Definition ................................................14
7. A singleton Definition for PRFD . . . . . . . . . . . . . . . 15 7.6. Discussion ................................................14
7.1. Motivation . . . . . . . . . . . . . . . . . . . . . . . . 15 7.7. Methodologies .............................................15
7.2. Metric Name . . . . . . . . . . . . . . . . . . . . . . . 15
7.3. Metric Parameters . . . . . . . . . . . . . . . . . . . . 15
7.4. Metric Units . . . . . . . . . . . . . . . . . . . . . . . 15
7.5. Definition . . . . . . . . . . . . . . . . . . . . . . . . 15
7.6. Discussion . . . . . . . . . . . . . . . . . . . . . . . . 16
7.7. Methodologies . . . . . . . . . . . . . . . . . . . . . . 17
8. A singleton Definition for PSFD . . . . . . . . . . . . . . . 18
8.1. Motivation . . . . . . . . . . . . . . . . . . . . . . . . 18
8.2. Metric Name . . . . . . . . . . . . . . . . . . . . . . . 18
8.3. Metric Parameters . . . . . . . . . . . . . . . . . . . . 18
8.4. Metric Units . . . . . . . . . . . . . . . . . . . . . . . 18
8.5. Definition . . . . . . . . . . . . . . . . . . . . . . . . 18
8.6. Discussion . . . . . . . . . . . . . . . . . . . . . . . . 19
8.7. Methodologies . . . . . . . . . . . . . . . . . . . . . . 20
9. A singleton Definition for PSRD . . . . . . . . . . . . . . . 21
9.1. Motivation . . . . . . . . . . . . . . . . . . . . . . . . 21
9.2. Metric Name . . . . . . . . . . . . . . . . . . . . . . . 21
9.3. Metric Parameters . . . . . . . . . . . . . . . . . . . . 21
9.4. Metric Units . . . . . . . . . . . . . . . . . . . . . . . 21
9.5. Definition . . . . . . . . . . . . . . . . . . . . . . . . 21
9.6. Discussion . . . . . . . . . . . . . . . . . . . . . . . . 22
9.7. Methodologies . . . . . . . . . . . . . . . . . . . . . . 23
10. A Definition for Samples of Data Path Delay . . . . . . . . . 24
10.1. Metric Name . . . . . . . . . . . . . . . . . . . . . . . 24
10.2. Metric Parameters . . . . . . . . . . . . . . . . . . . . 24
10.3. Metric Units . . . . . . . . . . . . . . . . . . . . . . . 24
10.4. Definition . . . . . . . . . . . . . . . . . . . . . . . . 24
10.5. Discussion . . . . . . . . . . . . . . . . . . . . . . . . 25
10.6. Methodologies . . . . . . . . . . . . . . . . . . . . . . 25
10.7. Typical testing cases . . . . . . . . . . . . . . . . . . 25
10.7.1. With No LSP in the Network . . . . . . . . . . . . . 25
10.7.2. With a Number of LSPs in the Network . . . . . . . . 25
11. Some Statistics Definitions for Metrics to Report . . . . . . 27
11.1. The Minimum of Metric . . . . . . . . . . . . . . . . . . 27
11.2. The Median of Metric . . . . . . . . . . . . . . . . . . . 27
11.3. The percentile of Metric . . . . . . . . . . . . . . . . . 27
11.4. The Failure Probability . . . . . . . . . . . . . . . . . 27
11.4.1. Failure Count . . . . . . . . . . . . . . . . . . . . 28
11.4.2. Failure Ratio . . . . . . . . . . . . . . . . . . . . 28
12. Security Considerations . . . . . . . . . . . . . . . . . . . 29
13. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 30
14. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 31
15. References . . . . . . . . . . . . . . . . . . . . . . . . . . 32
15.1. Normative References . . . . . . . . . . . . . . . . . . . 32
15.2. Informative References . . . . . . . . . . . . . . . . . . 32
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 33 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
1. Introduction 1. Introduction
Label Switched Paths (LSPs) are established, controlled, and Label Switched Paths (LSPs) are established, controlled, and
allocated for use by management tools or directly by the components allocated for use by management tools or directly by the components
that use them. In this document we call such management tools and that use them. In this document, we call such management tools and
the components that use LSPs "applications". Such applications may the components that use LSPs "applications". Such applications may
be Network Management Stations (NMSs), hardware or software be Network Management Systems (NMSs); hardware or software components
components that forward data onto virtual links, programs or tools that forward data onto virtual links; programs or tools that use
that use dedicated links, or any other user of an LSP. dedicated links; or any other user of an LSP.
Ideally, the completion of the signaling process means that the Ideally, the completion of the signaling process means that the
signaled LSP is ready to carry traffic. However, in actual signaled LSP is ready to carry traffic. However, in actual
implementations, vendors may choose to program the cross connection implementations, vendors may choose to program the cross-connection
in a pipelined manner, so that the overall LSP provisioning delay can 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 be reduced. In such situations, the data path may not be ready for
use instantly after the signaling process completes. Implementation use instantly after the signaling process completes. Implementation
deficiency may also cause the inconsistency in between the signaling deficiency may also cause inconsistency between the signaling process
process and data path provisioning. For example, if the data plane and data path provisioning. For example, if the data plane fails to
fails to program the cross connection accordingly but does not manage program the cross-connection accordingly but does not manage to
to report this to the control plane, the signaling process may report this to the control plane, the signaling process may complete
complete successfully while the corresponding data path will never successfully while the corresponding data path will never become
become functional at all. functional at all.
On the other hand, the completion of the signaling process may be On the other hand, the completion of the signaling process may be
used in many cases as indication of data path connectivity. For used in many cases as an indication of data path connectivity. For
example, when invoking through User Network Interface (UNI) example, when invoking through the User-Network Interface (UNI)
[RFC4208], a client device or an application may use the reception of [RFC4208], a client device or an application may use the reception of
the correct RESV message as indication that data path is fully the correct Resv message as an indication that the data path is fully
functional and start to transmit traffic. This will result in data functional and start to transmit traffic. This will result in data
loss or even application failure. loss or even application failure.
Although RSVP(-TE) specifications have suggested that the cross Although RSVP(-TE) specifications have suggested that the cross-
connections are programmed before signaling messages are propagated connections are programmed before signaling messages are propagated
upstream, it is still worthwhile to verify the conformance of an upstream, it is still worthwhile to verify the conformance of an
implementation and measure the delay, when necessary. implementation and measure the delay, when necessary.
This document defines a series of performance metrics to evaluate the This document defines a series of performance metrics to evaluate the
connectivity of data path during the signaling process. The metrics connectivity of the data path during the signaling process. The
defined in this document complement the control plane metrics defined metrics defined in this document complement the control plane metrics
in [RFC5814]. These metrics can be used to verify the conformance of defined in [RFC5814]. These metrics can be used to verify the
implementations against related specifications, as elaborated in conformance of implementations against related specifications, as
[RFC6383]. They also can be used to build more robust applications. elaborated in [RFC6383]. They also can be used to build more robust
applications.
2. Conventions Used in This Document 2. Conventions Used in This Document
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [RFC2119]. document are to be interpreted as described in [RFC2119].
3. Overview of Performance Metrics 3. Overview of Performance Metrics
In this memo, we define five performance metrics to characterize the In this memo, we define five performance metrics to characterize the
performance of data path provisioning with GMPLS/MPLS-TE signaling. performance of data path provisioning with GMPLS/MPLS-TE signaling.
These metrics complement the metrics defined in [RFC5814], in the These metrics complement the metrics defined in [RFC5814], in the
sense that the completion of the signaling process for a Label sense that the completion of the signaling process for an LSP and the
Switched Path (LSP) and the programming of cross connections along programming of cross-connections along the LSP may not be consistent.
the LSP may not be consistent. The performance metrics in [RFC5814] The performance metrics in [RFC5814] characterize the performance of
characterize the performance of LSP provisioning from the pure LSP provisioning from the pure signaling point of view, while the
signaling point of view, while the metric in this document takes into metric in this document takes into account the validity of the data
account the validity of the data path. path.
The five metrics are: The five metrics are:
o RRFD - the delay between RESV message received by ingress node and 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. forward data path becomes ready for use.
o RSRD - the delay between RESV message sent by egress node and o Resv Sent, Reverse Data (RSRD) - the delay between the point when
reverse data path becomes ready for use. the Resv message is sent by the egress node and the reverse data
path becomes ready for use.
o PRFD - the delay between PATH message received by egress node and 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. forward data path becomes ready for use.
o PSFD - the delay between PATH message sent by ingress and forward o PATH Sent, Forward Data (PSFD) - the delay between the point when
data path becomes ready for use. the PATH message is sent by the ingress node and the forward data
path becomes ready for use.
o PSRD - the delay between PATH message sent by ingress and reverse o PATH Sent, Reverse Data (PSRD) - the delay between the point when
data path becomes ready for use. 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 As in [RFC5814], we continue to use the structures and notions
introduced and discussed in the IPPM Framework document, [RFC2330] introduced and discussed in the IP Performance Metrics (IPPM)
[RFC2679] [RFC2681]. The reader is assumed to be familiar with the Framework documents [RFC2330] [RFC2679] [RFC2681]. The reader is
notions in those documents. The readers are assumed to be familiar assumed to be familiar with the notions in those documents. The
with the definitions in [RFC5814] as well. reader is also assumed to be familiar with the definitions in
[RFC5814].
4. Terms used in this document 4. Terms Used in This Document
o Forward data path - the data path from the ingress to the egress. o Forward data path - the data path from the ingress node to the
Instances of forward data path include the data path of a uni- egress node. Instances of a forward data path include the data
directional LSP and data path from the ingress node to the egress path of a unidirectional LSP and a data path from the ingress node
node in a bidirectional LSP. to the egress node in a bidirectional LSP.
o Reverse data path - the data path from the egress node to the o Reverse data path - the data path from the egress node to the
ingress node in a bidirectional LSP. ingress node in a bidirectional LSP.
o Data path delay - the time needed to complete the data path o Data path delay - the time needed to complete the data path
configuration, in relation to the signaling process. Five types configuration, in relation to the signaling process. Five types
of data path delay are defined in this document, namely RRFD, of data path delay are defined in this document, namely RRFD,
RSRD, PRFD, PSFD and PSRD. Data path delay used in this document RSRD, PRFD, PSFD, and PSRD. Data path delay as used in this
must be distinguished from the transmission delay along the data document must be distinguished from the transmission delay along
path, i.e., the time needed to transmit traffic from one side of the data path, i.e., the time needed to transmit traffic from one
the data path to the other. side of the data path to the other.
o Error free signal - data plane specific indication of connectivity o Error-free signal - data-plane-specific indication of connectivity
of the data path. For example, for packet switching capable of the data path. For example, for interfaces capable of packet
interfaces, the reception of the first error free packet from one 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. side of the LSP to the other may be used as the error-free signal.
For SDH/SONET cross connects, the disappearance of alarm can be For Synchronous Digital Hierarchy/Synchronous Optical Network
used as the error free signal. Through out this document, we will (SDH/SONET) cross-connects, the disappearance of alarm can be used
use the "error free signal" as a general term. An implementations as the error-free signal. Throughout this document, we will use
must choose a proper data path signal that is specific to the data "error-free signal" as a general term. An implementation must
path technology being tested. 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 o Ingress/egress node - in this memo, an ingress/egress node means a
measurement endpoint with both control plane and data plane measurement endpoint with both control plane and data plane
features. Typically, the control plane part on an ingress/egress features. Typically, the control plane part on an ingress/egress
node interact with the control plane of the network under test. node interacts with the control plane of the network under test.
The data plane part of an ingress/egress node will generate data 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 path signals and send the signal to the data plane of the network
under test, or receive data path signals from the network under under test, or receive data path signals from the network under
test. test.
5. A singleton Definition for RRFD 5. A Singleton Definition for RRFD
This part defines a metric for forward data path delay when an LSP is This part defines a metric for forward data path delay when an LSP is
setup. set up.
As described in [RFC6383], the completion of the RSVP-TE signaling As described in [RFC6383], the completion of the RSVP-TE signaling
process does not necessarily mean that the cross connections along process does not necessarily mean that the cross-connections along
the LSP being setup are in place and ready to carry traffic. This the LSP being set up are in place and ready to carry traffic. This
metric defines the time difference between the reception of RESV metric defines the time difference between the reception of a Resv
message by the ingress node and the completion of the cross message by the ingress node and the completion of the cross-
connection programming along the forward data path. connection programming along the forward data path.
5.1. Motivation 5.1. Motivation
RRFD is useful for several reasons: RRFD is useful for the following reasons:
o For the reasons described in [RFC6383], the data path may not be o For the reasons described in [RFC6383], the data path may not be
ready for use instantly after the completion of the RSVP-TE ready for use instantly after the completion of the RSVP-TE
signaling process. The delay itself is part of the implementation signaling process. The delay itself is part of the implementation
performance. performance.
o The completion of the signaling process may be used by application o The completion of the signaling process may be used by application
designers as indication of data path connectivity. The existence designers as an indication of data path connectivity. The
of this delay and the potential failure of cross connection existence of this delay and the potential failure of cross-
programming, if not properly treated, will result in data loss or connection programming, if not properly treated, will result in
application failure. The typical value of this delay can thus data loss or application failure. The typical value of this delay
help designers to improve the application model. can thus help designers to improve the application model.
5.2. Metric Name 5.2. Metric Name
RRFD = RESV Received, Forward Data path RRFD = Resv Received, Forward Data path
5.3. Metric Parameters 5.3. Metric Parameters
o ID0, the ingress LSR ID o ID0, the ingress Label Switching Router (LSR) ID
o ID1, the egress LSR ID o ID1, the egress LSR ID
o T, a time when the setup is attempted o T, a time when the setup is attempted
5.4. Metric Units 5.4. Metric Units
Either a real number of milli-seconds or undefined. The value of RRFD is either a real number of milliseconds or
undefined.
5.5. Definition 5.5. Definition
For a real number dT, RRFD from ingress node ID0 to egress node ID1 For a real number dT,
at T is dT means that ingress node ID0 send a PATH message to egress
node ID1 and the last bit of the corresponding RESV message is RRFD from ingress node ID0 to egress node ID1 at T is dT
received by ingress node ID0 at T, and an error free signal is
received by egress node ID1 by using a data plane specific test means that
pattern at T+dT.
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 5.6. Discussion
The following issues are likely to come up in practice: The following issues are likely to come up in practice:
o The accuracy of RRFD depends on the clock resolution of both the 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. Clock synchronization between the
ingress node and egress node is required. ingress node and egress node is required.
o The accuracy of RRFD is also dependent on how the error free o The accuracy of RRFD is also dependent on how the error-free
signal is received and may differ significantly when the underline signal is received and may differ significantly when the
data plane technology is different. For instance, for an LSP underlying data plane technology is different. For instance, for
between a pair of Ethernet interfaces, the ingress node may use a an LSP between a pair of Ethernet interfaces, the ingress node may
rate based method to verify the connectivity of the data path and use a rate-based method to verify the connectivity of the data
use the reception of the first error free frame as the error free path and use the reception of the first error-free frame as the
signal. In this case, the interval between two successive frames error-free signal. In this case, the interval between two
has a significant impact on accuracy. It is RECOMMENDED that the successive frames has a significant impact on accuracy. It is
ingress node uses small intervals, under the condition that the RECOMMENDED that the ingress node use small intervals, under the
injected traffic does not exceed the capacity of the forward data condition that the injected traffic does not exceed the capacity
path. The value of such intervals MUST be reported. 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 o The accuracy of RRFD is also dependent on the time needed to
propagate the error free signal from the ingress node to the propagate the error-free signal from the ingress node to the
egress node. A typical value of propagating the error free signal egress node. A typical value for propagating the error-free
from the ingress node to the egress node under the same signal from the ingress node to the egress node under the same
measurement setup MAY be reported. The methodology to obtain such measurement setup MAY be reported. The methodology to obtain such
values is outside the scope of this document. values is outside the scope of this document.
o The accuracy of this metric is also dependent on the physical o The accuracy of this metric is also dependent on the physical-
layer serialization/de-serialization of the test signal for layer serialization/deserialization of the test signal for certain
certain data path technologies. For instance, for an LSP between data path technologies. For instance, for an LSP between a pair
a pair of low speed Ethernet interfaces, the time needed to of low-speed Ethernet interfaces, the time needed to serialize/
serialize/deserialize a large frame may not be negligible. In deserialize a large frame may not be negligible. In this case, it
this case, it is RECOMMENDED that the ingress node uses small is RECOMMENDED that the ingress node use small frames. The
frames. The average length of the frame MAY be reported. average length of the frame MAY be reported.
o It is possible that under some implementations, a node may program o It is possible that under some implementations, a node may program
the cross connection before it sends PATH message further the cross-connection before it sends a PATH message further
downstream and the data path may be ready for use before a RESV 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 message reaches the ingress node. In such cases, RRFD can be a
negative value. It is RECOMMENDED that PRFD measurement is negative value. It is RECOMMENDED that a PRFD measurement be
carried out to further characterize the forward data path delay carried out to further characterize the forward data path delay
when a negative RRFD value is observed. when a negative RRFD value is observed.
o If error free signal is received by the egress node before PATH o If an error-free signal is received by the egress node before a
message is sent on the ingress node, an error MUST be reported and PATH message is sent on the ingress node, an error MUST be
the measurement SHOULD terminate. reported and the measurement SHOULD terminate.
o If the corresponding RESV message is received, but no error free o If the corresponding Resv message is received but no error-free
signal is received by the egress node within a reasonable period signal is received by the egress node within a reasonable period
of time, i.e., a threshold, RRFD MUST be treated as undefined. of time, i.e., a threshold, RRFD MUST be treated as undefined.
The value of the threshold MUST be reported. The value of the threshold MUST be reported.
o If the LSP setup fails, the metric value MUST NOT be counted. o If the LSP setup fails, this metric value MUST NOT be counted.
5.7. Methodologies 5.7. Methodologies
Generally the methodology would proceed as follows: Generally, the methodology would proceed as follows:
o Make sure that the network has enough resource to set up the o Make sure that the network has enough resources to set up the
requested LSP. requested LSP.
o Start the data path measurement and/or monitoring procedures on o Start the data path measurement and/or monitoring procedures on
the ingress node and egress node. If error free signal is the ingress node and egress node. If an error-free signal is
received by the egress node before PATH message is sent, report an received by the egress node before a PATH message is sent, report
error and terminate the measurement. an error and terminate the measurement.
o At the ingress node, form the PATH message according to the LSP o At the ingress node, form the PATH message according to the LSP
requirements and send the message towards the egress node. requirements and send the message towards the egress node.
o Upon receiving the last bit of the corresponding RESV message, o Upon receiving the last bit of the corresponding Resv message,
take the time stamp (T1) on the ingress node as soon as possible. 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 o When an error-free signal is observed on the egress node, take the
time stamp (T2) as soon as possible. An estimate of RRFD (T2 - timestamp (T2) as soon as possible. An estimate of RRFD (T2 - T1)
T1) can be computed. can be computed.
o If the corresponding RESV message arrives, but no error free o If the corresponding Resv message arrives but no error-free signal
signal is received within a reasonable period of time by the is received within a reasonable period of time by the ingress
ingress node, RRFD is deemed to be undefined. node, RRFD is deemed to be undefined.
o If the LSP setup fails, RRFD is not counted. o If the LSP setup fails, RRFD is not counted.
6. A singleton Definition for RSRD 6. A Singleton Definition for RSRD
This part defines a metric for reverse data path delay when an LSP is This part defines a metric for reverse data path delay when an LSP is
setup. set up.
As described in [RFC6383], the completion of the RSVP-TE signaling As described in [RFC6383], the completion of the RSVP-TE signaling
process does not necessarily mean that the cross connections along process does not necessarily mean that the cross-connections along
the LSP being setup are in place and ready to carry traffic. This the LSP being set up are in place and ready to carry traffic. This
metric defines the time difference between the completion of the metric defines the time difference between the completion of the
signaling process and the completion of the cross connection signaling process and the completion of the cross-connection
programming along the reverse data path. This metric MAY be used programming along the reverse data path. This metric MAY be used
together with RRFD to characterize the data path delay of a together with RRFD to characterize the data path delay of a
bidirectional LSP. bidirectional LSP.
6.1. Motivation 6.1. Motivation
RSRD is useful for several reasons: RSRD is useful for the following reasons:
o For the reasons described in [RFC6383], the data path may not be o For the reasons described in [RFC6383], the data path may not be
ready for use instantly after the completion of the RSVP-TE ready for use instantly after the completion of the RSVP-TE
signaling process. The delay itself is part of the implementation signaling process. The delay itself is part of the implementation
performance. performance.
o The completion of the signaling process may be used by application o The completion of the signaling process may be used by application
designers as indication of data path connectivity. The existence designers as an indication of data path connectivity. The
of this delay and the possible failure of cross connection existence of this delay and the possible failure of cross-
programming, if not properly treated, will result in data loss or connection programming, if not properly treated, will result in
application failure. The typical value of this delay can thus data loss or application failure. The typical value of this delay
help designers to improve the application model. can thus help designers to improve the application model.
6.2. Metric Name 6.2. Metric Name
RSRD = RESV sent, Reverse Data path RSRD = Resv Sent, Reverse Data path
6.3. Metric Parameters 6.3. Metric Parameters
o ID0, the ingress LSR ID o ID0, the ingress LSR ID
o ID1, the egress LSR ID o ID1, the egress LSR ID
o T, a time when the setup is attempted o T, a time when the setup is attempted
6.4. Metric Units 6.4. Metric Units
Either a real number of milli-seconds or undefined. The value of RSRD is either a real number of milliseconds or
undefined.
6.5. Definition 6.5. Definition
For a real number dT, RSRD from ingress node ID0 to egress node ID1 For a real number dT,
at T is dT means that ingress node ID0 send a PATH message to egress
node ID1 and the last bit of the corresponding RESV message is sent RSRD from ingress node ID0 to egress node ID1 at T is dT
by egress node ID1 at T, and an error free signal is received by the
ingress node ID0 using a data plane specific test pattern at T+dT. 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 6.6. Discussion
The following issues are likely to come up in practice: The following issues are likely to come up in practice:
o The accuracy of RSRD depends on the clock resolution of both the o The accuracy of RSRD depends on the clock resolution of both the
ingress node and egress node. And clock synchronization between ingress node and egress node. Clock synchronization between the
the ingress node and egress node is required. ingress node and egress node is required.
o The accuracy of RSRD is also dependent on how the error free o The accuracy of RSRD is also dependent on how the error-free
signal is received and may differ significantly when the underline signal is received and may differ significantly when the
data plane technology is different. For instance, for an LSP underlying data plane technology is different. For instance, for
between a pair of Ethernet interfaces, the egress node (sometimes an LSP between a pair of Ethernet interfaces, the egress node
the tester) may use a rate based method to verify the connectivity (sometimes the tester) may use a rate-based method to verify the
of the data path and use the reception of the first error free connectivity of the data path and use the reception of the first
frame as the error free signal. In this case, the interval error-free frame as the error-free signal. In this case, the
between two successive frames has a significant impact on interval between two successive frames has a significant impact on
accuracy. It is RECOMMENDED that in this case the egress node accuracy. It is RECOMMENDED in this case that the egress node use
uses small intervals, under the condition that the injected small intervals, under the condition that the injected traffic
traffic does not exceed the capacity of the reverse data path. does not exceed the capacity of the reverse data path. The value
The value of the interval MUST be reported. of the interval MUST be reported.
o The accuracy of RSRD is also dependent on the time needed to o The accuracy of RSRD is also dependent on the time needed to
propagate the error free signal from the egress node to the propagate the error-free signal from the egress node to the
ingress node. A typical value of propagating the error free ingress node. A typical value for propagating the error-free
signal from the egress node to the ingress node under the same signal from the egress node to the ingress node under the same
measurement setup MAY be reported. The methodology to obtain such measurement setup MAY be reported. The methodology to obtain such
values is outside the scope of this document. values is outside the scope of this document.
o The accuracy of this metric is also dependent on the physical o The accuracy of this metric is also dependent on the physical-
layer serialization/de-serialization of the test signal for layer serialization/deserialization of the test signal for certain
certain data path technologies. For instance, for an LSP between data path technologies. For instance, for an LSP between a pair
a pair of low speed Ethernet interfaces, the time needed to of low-speed Ethernet interfaces, the time needed to serialize/
serialize/deserialize a large frame may not be negligible. In deserialize a large frame may not be negligible. In this case, it
this case, it is RECOMMENDED that the egress node uses small is RECOMMENDED that the egress node use small frames. The average
frames. The average length of the frame MAY be reported. length of the frame MAY be reported.
o If the corresponding RESV message is sent, but no error free o If the corresponding Resv message is sent but no error-free signal
signal is received by the ingress node within a reasonable period is received by the ingress node within a reasonable period of
of time, i.e., a threshold, RSRD MUST be treated as undefined. time, i.e., a threshold, RSRD MUST be treated as undefined. The
The value of the threshold MUST be reported. value of the threshold MUST be reported.
o If error free signal is received before PATH message is sent on o If an error-free signal is received before a PATH message is sent
the ingress node, an error MUST be reported and the measurement on the ingress node, an error MUST be reported and the measurement
SHOULD terminate. SHOULD terminate.
o If the LSP setup fails, the metric value MUST NOT be counted. o If the LSP setup fails, this metric value MUST NOT be counted.
6.7. Methodologies 6.7. Methodologies
Generally the methodology would proceed as follows: Generally, the methodology would proceed as follows:
o Make sure that the network has enough resource to set up the o Make sure that the network has enough resources to set up the
requested LSP. requested LSP.
o Start the data path measurement and/or monitoring procedures on o Start the data path measurement and/or monitoring procedures on
the ingress node and egress node. If error free signal is the ingress node and egress node. If an error-free signal is
received by the ingress node before PATH message is sent, report received by the ingress node before a PATH message is sent, report
an error and terminate the measurement. an error and terminate the measurement.
o At the ingress node, form the PATH message according to the LSP o At the ingress node, form the PATH message according to the LSP
requirements and send the message towards the egress node. requirements and send the message towards the egress node.
o Upon sending the last bit of the corresponding RESV message, take o Upon sending the last bit of the corresponding Resv message, take
the time stamp (T1) on the egress node as soon as possible. the timestamp (T1) on the egress node as soon as possible.
o When an error free signal is observed on the ingress node, take o When an error-free signal is observed on the ingress node, take
the time stamp (T2) as soon as possible. An estimate of RSRD the timestamp (T2) as soon as possible. An estimate of RSRD
(T2-T1) can be computed. (T2 - T1) can be computed.
o If the LSP setup fails, RSRD is not counted. o If the LSP setup fails, RSRD is not counted.
o If no error free signal is received within a reasonable period of o If no error-free signal is received within a reasonable period of
time by the ingress node, RSRD is deemed to be undefined. time by the ingress node, RSRD is deemed to be undefined.
7. A singleton Definition for PRFD 7. A Singleton Definition for PRFD
This part defines a metric for forward data path delay when an LSP is This part defines a metric for forward data path delay when an LSP is
setup. set up.
In an RSVP-TE implementation, when setting up an LSP, each node may In an RSVP-TE implementation, when setting up an LSP, each node may
choose to program the cross connection before it sends PATH message choose to program the cross-connection before it sends a PATH message
further downstream. In this case, the forward data path may become further downstream. In this case, the forward data path may become
ready for use before the signaling process completes, ie. before the ready for use before the signaling process completes, i.e., before
RESV reaches the ingress node. This metric can be used to identify the Resv message reaches the ingress node. This metric can be used
such implementation practice and give useful information to to identify such an implementation practice and give useful
application designers. information to application designers.
7.1. Motivation 7.1. Motivation
PRFD is useful for the following reasons: PRFD is useful for the following reasons:
o PRFD can be used to identify an RSVP-TE implementation practice, o PRFD can be used to identify an RSVP-TE implementation practice in
in which cross connections are programmed before PATH message is which cross-connections are programmed before a PATH message is
sent downtream. sent downstream.
o The value of PRFD may also help application designers to fine tune o The value of PRFD may also help application designers to fine-tune
their application model. their application model.
7.2. Metric Name 7.2. Metric Name
PRFD = PATH received, Forward Data path PRFD = PATH Received, Forward Data path
7.3. Metric Parameters 7.3. Metric Parameters
o ID0, the ingress LSR ID o ID0, the ingress LSR ID
o ID1, the egress LSR ID o ID1, the egress LSR ID
o T, a time when the setup is attempted o T, a time when the setup is attempted
7.4. Metric Units 7.4. Metric Units
Either a real number of milli-seconds or undefined. The value of PRFD is either a real number of milliseconds or
undefined.
7.5. Definition 7.5. Definition
For a real number dT, PRFD from ingress node ID0 to egress node ID1 For a real number dT,
at T is dT means that ingress node ID0 send a PATH message to egress
node ID1 and the last bit of the PATH message is received by egress PRFD from ingress node ID0 to egress node ID1 at T is dT
node ID1 at T, and an error free signal is received by the egress
node ID1 using a data plane specific test pattern at T+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 7.6. Discussion
The following issues are likely to come up in practice: The following issues are likely to come up in practice:
o The accuracy of PRFD depends on the clock resolution of the egress o The accuracy of PRFD depends on the clock resolution of the egress
node. And clock synchronization between the ingress node and node. Clock synchronization between the ingress node and egress
egress node is not required. node is not required.
o The accuracy of PRFD is also dependent on how the error free o The accuracy of PRFD is also dependent on how the error-free
signal is received and may differ significantly when the underline signal is received and may differ significantly when the
data plane technology is different. For instance, for an LSP underlying data plane technology is different. For instance, for
between a pair of Ethernet interfaces, the egress node (sometimes an LSP between a pair of Ethernet interfaces, the egress node
the tester) may use a rate based method to verify the connectivity (sometimes the tester) may use a rate-based method to verify the
of the data path and use the reception of the first error free connectivity of the data path and use the reception of the first
frame as the error free signal. In this case, the interval error-free frame as the error-free signal. In this case, the
between two successive frames has a significant impact on interval between two successive frames has a significant impact on
accuracy. It is RECOMMENDED that in this case the ingress node accuracy. It is RECOMMENDED in this case that the ingress node
uses small intervals, under the condition that the injected use small intervals, under the condition that the injected traffic
traffic does not exceed the capacity of the forward data path. does not exceed the capacity of the forward data path. The value
The value of the interval MUST be reported. of the interval MUST be reported.
o The accuracy of PRFD is also dependent on the time needed to o The accuracy of PRFD is also dependent on the time needed to
propagate the error free signal from the ingress node to the propagate the error-free signal from the ingress node to the
egress node. A typical value of propagating the error free signal egress node. A typical value for propagating the error-free
from the ingress node to the egress node under the same signal from the ingress node to the egress node under the same
measurement setup MAY be reported. The methodology to obtain such measurement setup MAY be reported. The methodology to obtain such
values is outside the scope of this document. values is outside the scope of this document.
o The accuracy of this metric is also dependent on the physical o The accuracy of this metric is also dependent on the physical-
layer serialization/de-serialization of the test signal for layer serialization/deserialization of the test signal for certain
certain data path technologies. For instance, for an LSP between data path technologies. For instance, for an LSP between a pair
a pair of low speed Ethernet interfaces, the time needed to of low-speed Ethernet interfaces, the time needed to serialize/
serialize/deserialize a large frame may not be negligible. In deserialize a large frame may not be negligible. In this case, it
this case, it is RECOMMENDED that the ingress node uses small is RECOMMENDED that the ingress node use small frames. The
frames. The average length of the frame MAY be reported. average length of the frame MAY be reported.
o If error free signal is received before PATH message is sent, an o If an error-free signal is received before a PATH message is sent,
error MUST be reported and the measurement SHOULD terminate. an error MUST be reported and the measurement SHOULD terminate.
o If the LSP setup fails, the metric value MUST NOT be counted. o If the LSP setup fails, this metric value MUST NOT be counted.
o This metric SHOULD be used together with RRFD. It is RECOMMENDED o This metric SHOULD be used together with RRFD. It is RECOMMENDED
that PRFD measurement is carried out after a negetive RRFD value that a PRFD measurement be carried out after a negative RRFD value
has already been observed. has already been observed.
7.7. Methodologies 7.7. Methodologies
Generally the methodology would proceed as follows: Generally, the methodology would proceed as follows:
o Make sure that the network has enough resource to set up the o Make sure that the network has enough resources to set up the
requested LSP. requested LSP.
o Start the data path measurement and/or monitoring procedures on o Start the data path measurement and/or monitoring procedures on
the ingress node and egress node. If error free signal is the ingress node and egress node. If an error-free signal is
received by the egress node before PATH message is sent, report an received by the egress node before a PATH message is sent, report
error and terminate the measurement. an error and terminate the measurement.
o At the ingress node, form the PATH message according to the LSP o At the ingress node, form the PATH message according to the LSP
requirements and send the message towards the egress node. requirements and send the message towards the egress node.
o Upon receiving the last bit of the PATH message, take the time o Upon receiving the last bit of the PATH message, take the
stamp (T1) on the egress node as soon as possible. timestamp (T1) on the egress node as soon as possible.
o When an error free signal is observed on the egress node, take the o When an error-free signal is observed on the egress node, take the
time stamp (T2) as soon as possible. An estimate of PRFD (T2-T1) timestamp (T2) as soon as possible. An estimate of PRFD (T2 - T1)
can be computed. can be computed.
o If the LSP setup fails, PRFD is not counted. o If the LSP setup fails, PRFD is not counted.
o If no error free signal is received within a reasonable period of o If no error-free signal is received within a reasonable period of
time by the egress node, PRFD is deemed to be undefined. time by the egress node, PRFD is deemed to be undefined.
8. A singleton Definition for PSFD 8. A Singleton Definition for PSFD
This part defines a metric for forward data path delay when an LSP is This part defines a metric for forward data path delay when an LSP is
setup. set up.
As described in [RFC6383], the completion of the RSVP-TE signaling As described in [RFC6383], the completion of the RSVP-TE signaling
process does not necessarily mean that the cross connections along process does not necessarily mean that the cross-connections along
the LSP being setup are in place and ready to carry traffic. This the LSP being set up are in place and ready to carry traffic. This
metric defines the time from the PATH message sent by the ingress metric defines the time difference between the point when the PATH
node, till the completion of the cross connection programming along message is sent by the ingress node and the completion of the cross-
the LSP forward data path. connection programming along the LSP forward data path.
8.1. Motivation 8.1. Motivation
PSFD is useful for the following reasons: PSFD is useful for the following reasons:
o For the reasons described in [RFC6383], the data path setup delay o For the reasons described in [RFC6383], the data path setup delay
may not be consistent with the control plane LSP setup delay. The may not be consistent with the control plane LSP setup delay. The
data path setup delay metric is more precise for LSP setup data path setup delay metric is more precise for LSP setup
performance measurement. performance measurement.
o The completion of the signaling process may be used by application o The completion of the signaling process may be used by application
designers as indication of data path connectivity. The difference designers as an indication of data path connectivity. The
between the control plane setup delay and data path delay, and the difference between the control plane setup delay and data path
potential failure of cross connection programming, if not properly delay, and the potential failure of cross-connection programming,
treated, will result in data loss or application failure. This if not properly treated, will result in data loss or application
metric can thus help designers to improve the application model. failure. This metric can thus help designers to improve the
application model.
8.2. Metric Name 8.2. Metric Name
PSFD = Path Sent, Forward Data path PSFD = PATH Sent, Forward Data path
8.3. Metric Parameters 8.3. Metric Parameters
o ID0, the ingress LSR ID o ID0, the ingress LSR ID
o ID1, the egress LSR ID o ID1, the egress LSR ID
o T, a time when the setup is attempted o T, a time when the setup is attempted
8.4. Metric Units 8.4. Metric Units
Either a real number of milli-seconds or undefined. The value of PSFD is either a real number of milliseconds or
undefined.
8.5. Definition 8.5. Definition
For a real number dT, PSFD from ingress node ID0 to egress node ID1 For a real number dT,
at T is dT means that ingress node ID0 sends the first bit of a PATH
message to egress node ID1 at T, and an error free signal is received PSFD from ingress node ID0 to egress node ID1 at T is dT
by the egress node ID1 using a data plane specific test pattern at
T+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 8.6. Discussion
The following issues are likely to come up in practice: The following issues are likely to come up in practice:
o The accuracy of PSFD depends on the clock resolution of both the o The accuracy of PSFD depends on the clock resolution of both the
ingress node and egress node. And clock synchronization between ingress node and egress node. Clock synchronization between the
the ingress node and egress node is required. ingress node and egress node is required.
o The accuracy of this metric is also dependent on how the error o The accuracy of PSFD is also dependent on how the error-free
free signal is received and may differ significantly when the signal is received and may differ significantly when the
underlying data plane technology is different. For instance, for underlying data plane technology is different. For instance, for
an LSP between a pair of Ethernet interfaces, the ingress node may an LSP between a pair of Ethernet interfaces, the ingress node may
use a rate based method to verify the connectivity of the data 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 path and use the reception of the first error-free frame as the
error free signal. In this case, the interval between two error-free signal. In this case, the interval between two
successive frames has a significant impact on accuracy. It is successive frames has a significant impact on accuracy. It is
RECOMMENDED that the ingress node uses small intervals, under the RECOMMENDED that the ingress node use small intervals, under the
condition that the injected traffic does not exceed the capacity condition that the injected traffic does not exceed the capacity
of the forward data path. The value of the interval MUST be of the forward data path. The value of the interval MUST be
reported. reported.
o The accuracy of this metric is also dependent on the time needed o The accuracy of PSFD is also dependent on the time needed to
to propagate the error free signal from the ingress node to the propagate the error-free signal from the ingress node to the
egress node. A typical value of propagating the error free signal egress node. A typical value for propagating the error-free
from the ingress node to the egress node under the same signal from the ingress node to the egress node under the same
measurement setup MAY be reported. The methodology to obtain such measurement setup MAY be reported. The methodology to obtain such
values is outside the scope of this document. values is outside the scope of this document.
o The accuracy of this metric is also dependent on the physical o The accuracy of this metric is also dependent on the physical-
layer serialization/de-serialization of the test signal for layer serialization/deserialization of the test signal for certain
certain data path technologies. For instance, for an LSP between data path technologies. For instance, for an LSP between a pair
a pair of low speed Ethernet interfaces, the time needed to of low-speed Ethernet interfaces, the time needed to serialize/
serialize/deserialize a large frame may not be negligible. In deserialize a large frame may not be negligible. In this case, it
this case, it is RECOMMENDED that the ingress node uses small is RECOMMENDED that the ingress node use small frames. The
frames. The average length of the frame MAY be reported. average length of the frame MAY be reported.
o If error free signal is received before PATH message is sent, an o If an error-free signal is received before a PATH message is sent,
error MUST be reported and the measurement SHOULD terminate. an error MUST be reported and the measurement SHOULD terminate.
o If the LSP setup fails, the metric value MUST NOT be counted. o If the 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 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 signal is received by the egress node within a reasonable period
of time, i.e., a threshold, the metric value MUST be treated as of time, i.e., a threshold, PSFD MUST be treated as undefined.
undefined. The value of the threshold MUST be reported. The value of the threshold MUST be reported.
8.7. Methodologies 8.7. Methodologies
Generally the methodology would proceed as follows: Generally, the methodology would proceed as follows:
o Make sure that the network has enough resource to set up the o Make sure that the network has enough resources to set up the
requested LSP. requested LSP.
o Start the data path measurement and/or monitoring procedures on o Start the data path measurement and/or monitoring procedures on
the ingress node and egress node. If error free signal is the ingress node and egress node. If an error-free signal is
received by the egress node before PATH message is sent, report an received by the egress node before a PATH message is sent, report
error and terminate the measurement. an error and terminate the measurement.
o At the ingress node, form the PATH message according to the LSP o At the ingress node, form the PATH message according to the LSP
requirements and send the message towards the egress node. A requirements and send the message towards the egress node. A
timestamp (T1) may be stored locally in the ingress node when the timestamp (T1) may be stored locally in the ingress node when the
PATH message packet is sent towards the egress node. PATH message packet is sent towards the egress node.
o When an error free signal is observed on the egress node, take the o When an error-free signal is observed on the egress node, take the
time stamp (T2) as soon as possible. An estimate of PSFD (T2-T1) timestamp (T2) as soon as possible. An estimate of PSFD (T2 - T1)
can be computed. can be computed.
o If the LSP setup fails, this metric is not counted. o If the LSP setup fails, PSFD is not counted.
o If no error free signal is received within a reasonable period of o If no error-free signal is received within a reasonable period of
time by the egress node, PSFD is deemed to be undefined. time by the egress node, PSFD is deemed to be undefined.
9. A singleton Definition for PSRD 9. A Singleton Definition for PSRD
This part defines a metric for reverse data path delay when an LSP is This part defines a metric for reverse data path delay when an LSP is
setup. set up.
This metric defines the time from the ingress node sends the PATH This metric defines the time difference between the point when the
message, till the completion of the cross connection programming ingress node sends the PATH message and the completion of the cross-
along the LSP reverse data path. This metric MAY be used together connection programming along the LSP reverse data path. This metric
with PSFD to characterize the data path delay of a bidirectional LSP. MAY be used together with PSFD to characterize the data path delay of
a bidirectional LSP.
9.1. Motivation 9.1. Motivation
PSRD is useful for the following reasons: PSRD is useful for the following reasons:
o For the reasons described in [RFC6383], the data path setup delay o For the reasons described in [RFC6383], the data path setup delay
may not be consistent with the control plane LSP setup delay. The may not be consistent with the control plane LSP setup delay. The
data path setup delay metric is more precise for LSP setup data path setup delay metric is more precise for LSP setup
performance measurement. performance measurement.
o The completion of the signaling process may be used by application o The completion of the signaling process may be used by application
designers as indication of data path connectivity. The difference designers as an indication of data path connectivity. The
between the control plane setup delay and data path delay, and the difference between the control plane setup delay and data path
potential failure of cross connection programming, if not properly delay, and the potential failure of cross-connection programming,
treated, will result in data loss or application failure. This if not properly treated, will result in data loss or application
metric can thus help designers to improve the application model. failure. This metric can thus help designers to improve the
application model.
9.2. Metric Name 9.2. Metric Name
PSRD = Path Sent, Reverse Data path PSRD = PATH Sent, Reverse Data path
9.3. Metric Parameters 9.3. Metric Parameters
o ID0, the ingress LSR ID o ID0, the ingress LSR ID
o ID1, the egress LSR ID o ID1, the egress LSR ID
o T, a time when the setup is attempted o T, a time when the setup is attempted
9.4. Metric Units 9.4. Metric Units
Either a real number of milli-seconds or undefined. The value of PSRD is either a real number of milliseconds or
undefined.
9.5. Definition 9.5. Definition
For a real number dT, PSRD from ingress node ID0 to egress node ID1 For a real number dT,
at T is dT means that ingress node ID0 sends the first bit of a PATH
message to egress node ID1 at T, and an error free signal is received PSRD from ingress node ID0 to egress node ID1 at T is dT
through the reverse data path by the ingress node ID0 using a data
plane specific test pattern at T+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 9.6. Discussion
The following issues are likely to come up in practice: The following issues are likely to come up in practice:
o The accuracy of PSRD depends on the clock resolution of the o The accuracy of PSRD depends on the clock resolution of the
ingress node. And clock synchronization between the ingress node ingress node. Clock synchronization between the ingress node and
and egress node is not required. egress node is not required.
o The accuracy of this metric is also dependent on how the error o The accuracy of PSRD is also dependent on how the error-free
free signal is received and may differ significantly when the signal is received and may differ significantly when the
underlying data plane technology is different. For instance, for underlying data plane technology is different. For instance, for
an LSP between a pair of Ethernet interfaces, the egress node may an LSP between a pair of Ethernet interfaces, the egress node may
use a rate based method to verify the connectivity of the data 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 path and use the reception of the first error-free frame as the
error free signal. In this case, the interval between two error-free signal. In this case, the interval between two
successive frames has a significant impact on accuracy. It is successive frames has a significant impact on accuracy. It is
RECOMMENDED that the egress node uses small intervals, under the RECOMMENDED that the egress node use small intervals, under the
condition that the injected traffic does not exceed the capacity condition that the injected traffic does not exceed the capacity
of the forward data path. The value of the interval MUST be of the forward data path. The value of the interval MUST be
reported. reported.
o The accuracy of this metric is also dependent on the time needed o The accuracy of PSRD is also dependent on the time needed to
to propagate the error free signal from the egress node to the propagate the error-free signal from the egress node to the
ingress node. A typical value of propagating the error free ingress node. A typical value for propagating the error-free
signal from the egress node to the ingress node under the same signal from the egress node to the ingress node under the same
measurement setup MAY be reported. The methodology to obtain such measurement setup MAY be reported. The methodology to obtain such
values is outside the scope of this document. values is outside the scope of this document.
o The accuracy of this metric is also dependent on the physical o The accuracy of this metric is also dependent on the physical-
layer serialization/de-serialization of the test signal for layer serialization/deserialization of the test signal for certain
certain data path technologies. For instance, for an LSP between data path technologies. For instance, for an LSP between a pair
a pair of low speed Ethernet interfaces, the time needed to of low-speed Ethernet interfaces, the time needed to serialize/
serialize/deserialize a large frame may not be negligible. In deserialize a large frame may not be negligible. In this case, it
this case, it is RECOMMENDED that the egress node uses small is RECOMMENDED that the egress node use small frames. The average
frames. The average length of the frame MAY be reported. length of the frame MAY be reported.
o If error free signal is received before PATH message is sent, an o If an error-free signal is received before a PATH message is sent,
error MUST be reported and the measurement SHOULD terminate. 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 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 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 signal is received by the ingress node within a reasonable period
of time, i.e., a threshold, the metric value MUST be treated as of time, i.e., a threshold, PSRD MUST be treated as undefined.
undefined. The value of the threshold MUST be reported. The value of the threshold MUST be reported.
9.7. Methodologies 9.7. Methodologies
Generally the methodology would proceed as follows: Generally, the methodology would proceed as follows:
o Make sure that the network has enough resource to set up the o Make sure that the network has enough resources to set up the
requested LSP. requested LSP.
o Start the data path measurement and/or monitoring procedures on o Start the data path measurement and/or monitoring procedures on
the ingress node and egress node. If error free signal is the ingress node and egress node. If an error-free signal is
received by the egress node before PATH message is sent, report an received by the egress node before a PATH message is sent, report
error and terminate the measurement. an error and terminate the measurement.
o At the ingress node, form the PATH message according to the LSP o At the ingress node, form the PATH message according to the LSP
requirements and send the message towards the egress node. A requirements and send the message towards the egress node. A
timestamp (T1) may be stored locally in the ingress node when the timestamp (T1) may be stored locally in the ingress node when the
PATH message packet is sent towards the egress node. PATH message packet is sent towards the egress node.
o When an error free signal is observed on the ingress node, take o When an error-free signal is observed on the ingress node, take
the time stamp (T2) as soon as possible. An estimate of PSFD the timestamp (T2) as soon as possible. An estimate of PSRD
(T2-T1) can be computed. (T2 - T1) can be computed.
o If the LSP setup fails, this metric is not counted. o If the LSP setup fails, PSRD is not counted.
o If no error free signal is received within a reasonable period of o If no error-free signal is received within a reasonable period of
time by the ingress node, the metric value is deemed to be time by the ingress node, PSRD is deemed to be undefined.
undefined.
10. A Definition for Samples of Data Path Delay 10. A Definition for Samples of Data Path Delay
In Section 5, Section 6, Section 7, Section 8 and Section 9, we In Sections 5, 6, 7, 8, and 9, we defined the singleton metrics of
define the singleton metrics of data path delay. Now we define how data path delay. Now, we define how to get one particular sample of
to get one particular sample of such delay. Sampling is to select a such a delay. Sampling is done to select a particular portion of
particular portion of singleton values of the given parameters. Like singleton values of the given parameters. As in [RFC2330], we use
in [RFC2330], we use Poisson sampling as an example. Poisson sampling as an example.
10.1. Metric Name 10.1. Metric Name
Type <X> Data path delay sample, where X is either RRFD, RSRD, PRFD, Type <X> data path delay sample, where X is either RRFD, RSRD, PRFD,
PSFD and PSRD. PSFD, or PSRD.
10.2. Metric Parameters 10.2. Metric Parameters
o ID0, the ingress LSR ID o ID0, the ingress LSR ID
o ID1, the egress LSR ID o ID1, the egress LSR ID
o T0, a time o T0, a time
o Tf, a time o Tf, a time
o Lambda, a rate in the reciprocal seconds o Lambda, a rate in reciprocal milliseconds
o Th, LSP holding time o Th, the LSP holding time
o Td, the maximum waiting time for successful LSP setup o Td, the maximum waiting time for successful LSP setup
o Ts, the maximum waiting time for error free signal o Ts, the maximum waiting time for an error-free signal
10.3. Metric Units 10.3. Metric Units
A sequence of pairs; the elements of each pair are: A sequence of pairs; the elements of each pair are:
o T, a time when setup is attempted o T, a time when setup is attempted
o dT, either a real number of milli-seconds or undefined o dT, either a real number of milliseconds or undefined
10.4. Definition 10.4. Definition
Given T0, Tf, and Lambda, compute a pseudo-random Poisson process Given T0, Tf, and Lambda, compute a pseudo-random Poisson process
beginning at or before T0, with average arrival rate Lambda, and 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 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 and less than or equal to Tf are then selected. At each of the times
in this process, we obtain the value of data path delay sample of 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 type <X> at this time. The value of the sample is the sequence made
up of the resulting <time, type <X> data path delay> pairs. If there 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 are no such pairs, the sequence is of length zero and the sample is
said to be empty. said to be empty.
10.5. Discussion 10.5. Discussion
The following issues are likely to come up in practice: The following issues are likely to come up in practice:
o The parameters Lambda, Th and Td should be carefully chosen, as o The parameters Lambda, Th, and Td should be carefully chosen, as
explained in the discussions for LSP setup delay (see [RFC5814]). explained in the discussions for LSP setup delay (see [RFC5814]).
o The parameter Ts should be carefully chosen and MUST be reported o The parameter Ts should be carefully chosen and MUST be reported
along with the LSP forward/reverse data path delay sample. along with the LSP forward/reverse data path delay sample.
10.6. Methodologies 10.6. Methodologies
Generally the methodology would proceed as follows: Generally, the methodology would proceed as follows:
o The selection of specific times, using the specified Poisson o Select specific times, using the specified Poisson arrival
arrival process, and process.
o Set up the LSP and obtain the value of type <X> data path delay 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 o Release the LSP after Th, and wait for the next Poisson arrival
process process.
10.7. Typical testing cases 10.7. Typical Testing Cases
10.7.1. With No LSP in the Network 10.7.1. With No LSP in the Network
10.7.1.1. Motivation 10.7.1.1. Motivation
Data path delay with no LSP in the network is important because this Data path delay with no LSP in the network is important because this
reflects the inherent delay of a device implementation. The minimum reflects the inherent delay of a device implementation. The minimum
value provides an indication of the delay that will likely be value provides an indication of the delay that will likely be
experienced when an LSP data path is configured under light traffic experienced when an LSP data path is configured under light traffic
load. load.
skipping to change at page 26, line 10 skipping to change at page 24, line 17
10.7.2.1. Motivation 10.7.2.1. Motivation
Data path delay with a number of LSPs in the network is important Data path delay with a number of LSPs in the network is important
because it reflects the performance of an operational network with because it reflects the performance of an operational network with
considerable load. This delay may vary significantly as the number considerable load. This delay may vary significantly as the number
of existing LSPs varies. It can be used as a scalability metric of a of existing LSPs varies. It can be used as a scalability metric of a
device implementation. device implementation.
10.7.2.2. Methodologies 10.7.2.2. Methodologies
Setup the required number of LSPs, and wait until the network reaches o Set up the required number of LSPs.
a stable state, and then proceed with the methodologies described in
Section 10.6. 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 11. Some Statistics Definitions for Metrics to Report
Given the samples of the performance metric, we now offer several Given the samples of the performance metric, we now offer several
statistics of these samples to report. From these statistics, we can statistics of these samples to report. From these statistics, we can
draw some useful conclusions of a GMPLS network. The value of these draw some useful conclusions regarding a GMPLS network. The value of
metrics is either a real number, or an undefined number of these metrics is either a real number of milliseconds or undefined.
milliseconds. In the following discussion, we only consider the In the following discussion, we only consider the finite values.
finite values.
11.1. The Minimum of Metric 11.1. The Minimum of the Metric
The minimum of metric is the minimum of all the dT values in the 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 sample. In computing this, undefined values SHOULD be treated as
infinitely large. Note that this means that the minimum could thus infinitely large. Note that this means that the minimum could thus
be undefined if all the dT values are undefined. In addition, the be undefined if all the dT values are undefined. In addition, the
metric minimum SHOULD be set to undefined if the sample is empty. metric minimum SHOULD be set to undefined if the sample is empty.
11.2. The Median of Metric 11.2. The Median of the Metric
Metric median is the median of the dT values in the given sample. In The median of the metric is the median of the dT values in the given
computing the median, the undefined values MUST NOT be counted in. sample. In computing the median, the undefined values MUST NOT be
The Median SHOULD be set to undefined if all the dT values are included. The median SHOULD be set to undefined if all the dT values
undefined, or if the sample is empty.When the number of defined 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 values in the given sample is small, the metric median may not be
typical and SHOULD be used carefully. typical and SHOULD be used carefully.
11.3. The percentile of Metric 11.3. The Percentile of the Metric
The "empirical distribution function" (EDF) of a set of scalar The "empirical distribution function" (EDF) of a set of scalar
measurements is a function F(x) which for any x gives the fractional measurements is a function F(x), which, for any x, gives the
proportion of the total measurements that were <= x. fractional proportion of the total measurements that were <= x.
Given a percentage X, the X-th percentile of Metric means the 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, smallest value of x for which F(x) >= X. In computing the
undefined values MUST NOT be included. percentile, undefined values MUST NOT be included.
See [RFC2330] for further details. See [RFC2330] for further details.
11.4. The Failure Probability 11.4. Failure Probability
Given the samples of the performance metric, we now offer two Given the samples of the performance metric, we now offer two
statistics of failure events of these samples to report. The two statistics of failure events of these samples to report: Failure
statistics can be applied to both forward data path and reverse data Count and Failure Ratio. The two statistics can be applied to both
path. For example, when a sample of RRFD has been obtained the the forward data path and reverse data path. For example, when a
forward data path failure statistics can be obtained, while when a sample of RRFD has been obtained, the forward data path failure
sample of RSRD can be used to calculate the reverse data path failure statistics can be obtained, while a sample of RSRD can be used to
statistics. Detailed definitions of the Failure Count and Failure calculate the reverse data path failure statistics. Detailed
Ratio are given below. definitions of Failure Count and Failure Ratio are given below.
11.4.1. Failure Count 11.4.1. Failure Count
Failure Count is defined as the number of the undefined value of the Failure Count is defined as the number of the undefined value of the
corresponding performance metric in a sample. The value of Failure corresponding performance metric in a sample. The value of Failure
Count is an integer. Count is an integer.
11.4.2. Failure Ratio 11.4.2. Failure Ratio
Failure Ratio is the percentage of the number of failure events to Failure Ratio is the percentage of the number of failure events to
the total number of requests in a sample. Here an failure event the total number of requests in a sample. Here, a failure event
means that the signaling completes with no error, while no error free means that the signaling completes with no error, while no error-free
signal is observed. The calculation for Failure Ratio is defined as signal is observed. The calculation for Failure Ratio is defined as
follows: follows:
Failure Ratio = Number of undefined value/(Number of valid metric Failure Ratio = Number of undefined value/(Number of valid metric
values + Number of undefined value) * 100%. values + Number of undefined value) * 100%.
12. Security Considerations 12. Security Considerations
In the control plane, since the measurement endpoints must be In the control plane, since the measurement endpoints must be
conformant to signaling specifications and behave as normal signaling conformant to signaling specifications and behave as normal signaling
endpoints, it will not incur other security issues than normal LSP endpoints, it will not incur security issues other than normal LSP
provisioning. However, the measurement parameters must be carefully provisioning. However, the measurement parameters must be carefully
selected so that the measurements inject trivial amounts of selected so that the measurements inject trivial amounts of
additional traffic into the networks they measure. If they inject additional traffic into the networks they measure. If they inject
"too much" traffic, they can skew the results of the measurement, and "too much" traffic, they can skew the results of the measurement and
in extreme cases cause congestion and denial of service. in extreme cases cause congestion and denial of service.
In the data plane, the measurement endpoint MUST use a signal that is In the data plane, the measurement endpoint MUST use a signal that is
consistent with what is specified in the control plane. For example, consistent with what is specified in the control plane. For example,
in a packet switched case, the traffic injected into the data plane in a packet switched case, the traffic injected into the data plane
MUST NOT exceed the specified rate in the corresponding LSP setup MUST NOT exceed the specified rate in the corresponding LSP setup
request. In a wavelength switched case, the measurement endpoint request. In a wavelength switched case, the measurement endpoint
MUST use the specified or negotiated lambda with appropriate power. MUST use the specified or negotiated lambda with appropriate power.
The security considerations pertaining to the original RSVP protocol The security considerations pertaining to the original RSVP protocol
[RFC2205] and its TE extensions [RFC3209] also remain relevant. [RFC2205] and its TE extensions [RFC3209] also remain relevant.
13. IANA Considerations 13. References
This document makes no requests for IANA action.
14. Acknowledgements
We wish to thank Adrian Farrel, Lou Berger and Al Morton for their
comments and help. We also wish to thank the reviews done by Klaas
Wierenga and Alexey Melnikov.
This document contains ideas as well as text that have appeared in
existing IETF documents. The authors wish to thank G. Almes, S.
Kalidindi and M. Zekauskas.
We also wish to thank Weisheng Hu, Yaohui Jin and Wei Guo in the
state key laboratory of advanced optical communication systems and
networks for the valuable comments. We also wish to thank the
support from NSFC and 863 program of China.
15. References
15.1. Normative References 13.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997. Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2205] Braden, B., Zhang, L., Berson, S., Herzog, S., and S. [RFC2205] Braden, B., Zhang, L., Berson, S., Herzog, S., and S.
Jamin, "Resource ReSerVation Protocol (RSVP) -- Version 1 Jamin, "Resource ReSerVation Protocol (RSVP) -- Version 1
Functional Specification", RFC 2205, September 1997. Functional Specification", RFC 2205, September 1997.
[RFC2679] Almes, G., Kalidindi, S., and M. Zekauskas, "A One-way [RFC2679] Almes, G., Kalidindi, S., and M. Zekauskas, "A One-way
Delay Metric for IPPM", RFC 2679, September 1999. Delay Metric for IPPM", RFC 2679, September 1999.
[RFC2681] Almes, G., Kalidindi, S., and M. Zekauskas, "A Round-trip [RFC2681] Almes, G., Kalidindi, S., and M. Zekauskas, "A Round-trip
Delay Metric for IPPM", RFC 2681, September 1999. Delay Metric for IPPM", RFC 2681, September 1999.
[RFC3209] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V., [RFC3209] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V.,
and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP
Tunnels", RFC 3209, December 2001. Tunnels", RFC 3209, December 2001.
15.2. Informative References 13.2. Informative References
[RFC2330] Paxson, V., Almes, G., Mahdavi, J., and M. Mathis, [RFC2330] Paxson, V., Almes, G., Mahdavi, J., and M. Mathis,
"Framework for IP Performance Metrics", RFC 2330, "Framework for IP Performance Metrics", RFC 2330,
May 1998. May 1998.
[RFC4208] Swallow, G., Drake, J., Ishimatsu, H., and Y. Rekhter, [RFC4208] Swallow, G., Drake, J., Ishimatsu, H., and Y. Rekhter,
"Generalized Multiprotocol Label Switching (GMPLS) User- "Generalized Multiprotocol Label Switching (GMPLS) User-
Network Interface (UNI): Resource ReserVation Protocol- Network Interface (UNI): Resource ReserVation Protocol-
Traffic Engineering (RSVP-TE) Support for the Overlay Traffic Engineering (RSVP-TE) Support for the Overlay
Model", RFC 4208, October 2005. Model", RFC 4208, October 2005.
[RFC5814] Sun, W. and G. Zhang, "Label Switched Path (LSP) Dynamic [RFC5814] Sun, W. and G. Zhang, "Label Switched Path (LSP) Dynamic
Provisioning Performance Metrics in Generalized MPLS Provisioning Performance Metrics in Generalized MPLS
Networks", RFC 5814, March 2010. Networks", RFC 5814, March 2010.
[RFC6383] Shiomoto, K. and A. Farrel, "Advice on When It Is Safe to [RFC6383] Shiomoto, K. and A. Farrel, "Advice on When It Is Safe to
Start Sending Data on Label Switched Paths Established Start Sending Data on Label Switched Paths Established
Using RSVP-TE", RFC 6383, September 2011. Using RSVP-TE", RFC 6383, September 2011.
Authors' Addresses Appendix A. Acknowledgements
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 100083
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 We wish to thank Adrian Farrel, Lou Berger, and Al Morton for their
Email: xieg@cs.ucr.edu comments and help. We also wish to thank Klaas Wierenga and Alexey
Melnikov for their reviews.
Rajiv Papneja This document contains ideas as well as text that have appeared in
Huawei Technologies existing IETF documents. The authors wish to thank G. Almes, S.
Santa Clara, CA 95050 Kalidindi, and M. Zekauskas.
Reston, VA 20190
USA
Phone: +1 571 926 8593 We also wish to thank Weisheng Hu, Yaohui Jin, and Wei Guo in the
Email: rajiv.papneja@huawei.com 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.
Contributors Appendix B. Contributors
Bin Gu Bin Gu
IXIA IXIA
Oriental Kenzo Plaza 8M, 48 Dongzhimen Wai Street, Dongcheng District Oriental Kenzo Plaza 8M, 48 Dongzhimen Wai Street
Dongcheng District
Beijing 200240 Beijing 200240
China China
Phone: +86 13611590766 Phone: +86 13611590766
Email: BGu@ixiacom.com EMail: BGu@ixiacom.com
Xueqin Wei Xueqin Wei
Fiberhome Telecommunication Technology Co., Ltd. Fiberhome Telecommunication Technology Co., Ltd.
Wuhan Wuhan
China China
Phone: +86 13871127882 Phone: +86 13871127882
Email: xqwei@fiberhome.com.cn EMail: xqwei@fiberhome.com.cn
Tomohiro Otani Tomohiro Otani
KDDI R&D Laboratories, Inc. KDDI R&D Laboratories, Inc.
2-1-15 Ohara Kamifukuoka Saitama 2-1-15 Ohara Kamifukuoka Saitama
356-8502 356-8502
Japan Japan
Phone: +81-49-278-7357 Phone: +81-49-278-7357
Email: tm-otani@kddi.com EMail: tm-otani@kddi.com
Ruiquan Jing Ruiquan Jing
China Telecom Beijing Research Institute China Telecom Beijing Research Institute
118 Xizhimenwai Avenue 118 Xizhimenwai Avenue
Beijing 100035 Beijing 100035
China China
Phone: +86-10-58552000 Phone: +86-10-58552000
Email: jingrq@ctbri.com.cn EMail: jingrq@ctbri.com.cn
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
 End of changes. 182 change blocks. 
577 lines changed or deleted 572 lines changed or added

This html diff was produced by rfcdiff 1.41. The latest version is available from http://tools.ietf.org/tools/rfcdiff/