draft-ietf-ccamp-dpm-05.txt   draft-ietf-ccamp-dpm-06.txt 
Network Working Group W. Sun, Ed. Network Working Group W. Sun, Ed.
Internet-Draft SJTU Internet-Draft SJTU
Intended status: Standards Track G. Zhang, Ed. Intended status: Standards Track G. Zhang, Ed.
Expires: August 4, 2012 CATR Expires: December 10, 2012 CATR
February 1, 2012 June 8, 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 MPLS-TE Networks
draft-ietf-ccamp-dpm-05.txt draft-ietf-ccamp-dpm-06.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 and
MPLS/TE networks, the completion of the signaling process does not MPLS/TE networks, the completion of the signaling process does not
necessarily mean that the cross connection along the LSP have been necessarily mean that the cross connection along the LSP have been
programmed accordingly and in a timely manner. Meanwhile, the programmed accordingly and in a timely manner. Meanwhile, the
completion of signaling process may be used by applications as completion of signaling process may be used by applications as
indication that data path has become usable. The existence of this indication that data path has become usable. The existence of this
delay and the possible failure of cross connection programming, if delay and the possible failure of cross connection programming, if
not properly treated, will result in data loss or even application not properly treated, will result in data loss or even application
failure. Characterization of this performance can thus help failure. Characterization of this performance can thus help
designers to improve the application model and to build more robust designers to improve the application model and to build more robust
applications. This document defines a series of performance metrics applications. This document defines a series of performance metrics
to evaluate the availability of data path in the signaling process. to evaluate the connectivity of data path in the signaling process.
Status of this Memo Status of this Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on August 4, 2012. This Internet-Draft will expire on December 10, 2012.
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
skipping to change at page 2, line 50 skipping to change at page 2, line 50
6.6. Discussion . . . . . . . . . . . . . . . . . . . . . . . . 12 6.6. Discussion . . . . . . . . . . . . . . . . . . . . . . . . 12
6.7. Methodologies . . . . . . . . . . . . . . . . . . . . . . 13 6.7. Methodologies . . . . . . . . . . . . . . . . . . . . . . 13
7. A singleton Definition for PRFD . . . . . . . . . . . . . . . 14 7. A singleton Definition for PRFD . . . . . . . . . . . . . . . 14
7.1. Motivation . . . . . . . . . . . . . . . . . . . . . . . . 14 7.1. Motivation . . . . . . . . . . . . . . . . . . . . . . . . 14
7.2. Metric Name . . . . . . . . . . . . . . . . . . . . . . . 14 7.2. Metric Name . . . . . . . . . . . . . . . . . . . . . . . 14
7.3. Metric Parameters . . . . . . . . . . . . . . . . . . . . 14 7.3. Metric Parameters . . . . . . . . . . . . . . . . . . . . 14
7.4. Metric Units . . . . . . . . . . . . . . . . . . . . . . . 14 7.4. Metric Units . . . . . . . . . . . . . . . . . . . . . . . 14
7.5. Definition . . . . . . . . . . . . . . . . . . . . . . . . 14 7.5. Definition . . . . . . . . . . . . . . . . . . . . . . . . 14
7.6. Discussion . . . . . . . . . . . . . . . . . . . . . . . . 15 7.6. Discussion . . . . . . . . . . . . . . . . . . . . . . . . 15
7.7. Methodologies . . . . . . . . . . . . . . . . . . . . . . 15 7.7. Methodologies . . . . . . . . . . . . . . . . . . . . . . 16
8. A singleton Definition for PSFD . . . . . . . . . . . . . . . 17 8. A singleton Definition for PSFD . . . . . . . . . . . . . . . 17
8.1. Motivation . . . . . . . . . . . . . . . . . . . . . . . . 17 8.1. Motivation . . . . . . . . . . . . . . . . . . . . . . . . 17
8.2. Metric Name . . . . . . . . . . . . . . . . . . . . . . . 17 8.2. Metric Name . . . . . . . . . . . . . . . . . . . . . . . 17
8.3. Metric Parameters . . . . . . . . . . . . . . . . . . . . 17 8.3. Metric Parameters . . . . . . . . . . . . . . . . . . . . 17
8.4. Metric Units . . . . . . . . . . . . . . . . . . . . . . . 17 8.4. Metric Units . . . . . . . . . . . . . . . . . . . . . . . 17
8.5. Definition . . . . . . . . . . . . . . . . . . . . . . . . 17 8.5. Definition . . . . . . . . . . . . . . . . . . . . . . . . 17
8.6. Discussion . . . . . . . . . . . . . . . . . . . . . . . . 18 8.6. Discussion . . . . . . . . . . . . . . . . . . . . . . . . 18
8.7. Methodologies . . . . . . . . . . . . . . . . . . . . . . 18 8.7. Methodologies . . . . . . . . . . . . . . . . . . . . . . 19
9. A singleton Definition for PSRD . . . . . . . . . . . . . . . 20 9. A singleton Definition for PSRD . . . . . . . . . . . . . . . 20
9.1. Motivation . . . . . . . . . . . . . . . . . . . . . . . . 20 9.1. Motivation . . . . . . . . . . . . . . . . . . . . . . . . 20
9.2. Metric Name . . . . . . . . . . . . . . . . . . . . . . . 20 9.2. Metric Name . . . . . . . . . . . . . . . . . . . . . . . 20
9.3. Metric Parameters . . . . . . . . . . . . . . . . . . . . 20 9.3. Metric Parameters . . . . . . . . . . . . . . . . . . . . 20
9.4. Metric Units . . . . . . . . . . . . . . . . . . . . . . . 20 9.4. Metric Units . . . . . . . . . . . . . . . . . . . . . . . 20
9.5. Definition . . . . . . . . . . . . . . . . . . . . . . . . 20 9.5. Definition . . . . . . . . . . . . . . . . . . . . . . . . 20
9.6. Discussion . . . . . . . . . . . . . . . . . . . . . . . . 21 9.6. Discussion . . . . . . . . . . . . . . . . . . . . . . . . 21
9.7. Methodologies . . . . . . . . . . . . . . . . . . . . . . 21 9.7. Methodologies . . . . . . . . . . . . . . . . . . . . . . 22
10. A Definition for Samples of Data Path Delay . . . . . . . . . 23 10. A Definition for Samples of Data Path Delay . . . . . . . . . 23
10.1. Metric Name . . . . . . . . . . . . . . . . . . . . . . . 23 10.1. Metric Name . . . . . . . . . . . . . . . . . . . . . . . 23
10.2. Metric Parameters . . . . . . . . . . . . . . . . . . . . 23 10.2. Metric Parameters . . . . . . . . . . . . . . . . . . . . 23
10.3. Metric Units . . . . . . . . . . . . . . . . . . . . . . . 23 10.3. Metric Units . . . . . . . . . . . . . . . . . . . . . . . 23
10.4. Definition . . . . . . . . . . . . . . . . . . . . . . . . 23 10.4. Definition . . . . . . . . . . . . . . . . . . . . . . . . 23
10.5. Discussion . . . . . . . . . . . . . . . . . . . . . . . . 24 10.5. Discussion . . . . . . . . . . . . . . . . . . . . . . . . 24
10.6. Methodologies . . . . . . . . . . . . . . . . . . . . . . 24 10.6. Methodologies . . . . . . . . . . . . . . . . . . . . . . 24
10.7. Typical testing cases . . . . . . . . . . . . . . . . . . 24 10.7. Typical testing cases . . . . . . . . . . . . . . . . . . 24
10.7.1. With No LSP in the Network . . . . . . . . . . . . . 24 10.7.1. With No LSP in the Network . . . . . . . . . . . . . 24
skipping to change at page 4, line 22 skipping to change at page 4, line 22
may not be ready for use instantly after the signaling process may not be ready for use instantly after the signaling process
completes. Implementation deficiency may also cause the completes. Implementation deficiency may also cause the
inconsistency in between the signaling process and data path inconsistency in between the signaling process and data path
provisioning. For example, if the data plane fails to program the provisioning. For example, if the data plane fails to program the
cross connection accordingly but does not manage to report this to cross connection accordingly but does not manage to report this to
the control plane, the signaling process may complete successfully the control plane, the signaling process may complete successfully
while the corresponding data path will never become functional at while the corresponding data path will never become functional at
all. 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 availability. For used in many cases as indication of data path connectivity. For
example, when invoking through User Network Interface (UNI), a client example, when invoking through User Network Interface (UNI), a client
device or an application may use the reception of the correct RESV device or an application may use the reception of the correct RESV
message as indication that data path is fully functional and start to message as indication that data path is fully functional and start to
transmit traffic. This will result in data loss or even application transmit traffic. This will result in data loss or even application
failure. 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
availability of data path during the signaling process. The metrics connectivity of data path during the signaling process. The metrics
defined in this document complements the control plane metrics defined in this document complements the control plane metrics
defined in [RFC5814]. These metrics can be used to verify the defined in [RFC5814]. These metrics can be used to verify the
conformance of implementations against related specifications, as conformance of implementations against related specifications, as
elaborated in [RFC6383]. They also can be used to build more robust elaborated in [RFC6383]. They also can be used to build more robust
applications. 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
skipping to change at page 7, line 23 skipping to change at page 7, line 23
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 used in this document
must be distinguished from the transmission delay along the data must be distinguished from the transmission delay along the data
path, i.e., the time needed to transmit traffic from one side of path, i.e., the time needed to transmit traffic from one side of
the data path to the other. the data path to the other.
o Error free signal - data plane specific indication of availability 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 packet switching capable
interfaces, the reception of the first error free packet from one interfaces, 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 SDH/SONET cross connects, the disappearance of alarm can be
used as the error free signal. Through out this document, we will used as the error free signal. Through out this document, we will
use the "error free signal" as a general term. An implementations use the "error free signal" as a general term. An implementations
must choose a proper data path signal that is specific to the data must choose a proper data path signal that is specific to the data
path technology being tested. 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
skipping to change at page 8, line 27 skipping to change at page 8, line 27
5.1. Motivation 5.1. Motivation
RRFD is useful for several reasons: RRFD is useful for several 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 availability. The existence designers as indication of data path connectivity. The existence
of this delay and the potential failure of cross connection of this delay and the potential failure of cross connection
programming, if not properly treated, will result in data loss or programming, if not properly treated, will result in data loss or
application failure. The typical value of this delay can thus application failure. The typical value of this delay can thus
help designers to improve the application model. help designers to improve the application model.
5.2. Metric Name 5.2. Metric Name
RRFD RRFD = RESV Received, Forward Data path
5.3. Metric Parameters 5.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
5.4. Metric Units 5.4. Metric Units
skipping to change at page 9, line 21 skipping to change at page 9, line 21
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 underline
data plane technology is different. For instance, for an LSP data plane technology is different. For instance, for an LSP
between a pair of Ethernet interfaces, the ingress node may use a between a pair of Ethernet interfaces, the ingress node may use a
rate based method to verify the availability of the data path and rate based method to verify the connectivity of the data path and
use the reception of the first error free frame as the error free use the reception of the first error free frame as the error free
signal. In this case, the interval between two successive frames signal. In this case, the interval between two successive frames
has a significant impact on accuracy. It is RECOMMENDED that the has a significant impact on accuracy. It is RECOMMENDED that the
ingress node uses small intervals, under the condition that the ingress node uses small intervals, under the condition that the
injected traffic does not exceed the capacity of the forward data injected traffic does not exceed the capacity of the forward data
path. The value of such intervals MUST be reported. 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 of propagating the error free signal
from the ingress node to the egress node under the same 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
layer serialization/de-serialization of the test signal for
certain data path technologies. For instance, for an LSP between
a pair of low speed Ethernet interfaces, the time needed to
serialize/deserialize a large frame may not be negligible. In
this case, it is RECOMMENDED that the ingress node uses small
frames. The 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 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 PRFD measurement is
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 error free signal is received by the egress node before PATH
message is sent on the ingress node, an error MUST be reported and message is sent on the ingress node, an error MUST be reported and
skipping to change at page 11, line 29 skipping to change at page 11, line 29
6.1. Motivation 6.1. Motivation
RSRD is useful for several reasons: RSRD is useful for several 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 availability. The existence designers as indication of data path connectivity. The existence
of this delay and the possible failure of cross connection of this delay and the possible failure of cross connection
programming, if not properly treated, will result in data loss or programming, if not properly treated, will result in data loss or
application failure. The typical value of this delay can thus application failure. The typical value of this delay can thus
help designers to improve the application model. help designers to improve the application model.
6.2. Metric Name 6.2. Metric Name
RSRD 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
skipping to change at page 12, line 25 skipping to change at page 12, line 25
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. And clock synchronization between
the ingress node and egress node is required. the 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 underline
data plane technology is different. For instance, for an LSP data plane technology is different. For instance, for an LSP
between a pair of Ethernet interfaces, the egress node (sometimes between a pair of Ethernet interfaces, the egress node (sometimes
the tester) may use a rate based method to verify the availability the tester) may use a rate based method to verify the connectivity
of the data path and use the reception of the first error free of the data path and use the reception of the first error free
frame as the error free signal. In this case, the interval frame as the error free signal. In this case, the interval
between two successive frames has a significant impact on between two successive frames has a significant impact on
accuracy. It is RECOMMENDED that in this case the egress node accuracy. It is RECOMMENDED that in this case the egress node
uses small intervals, under the condition that the injected uses small intervals, under the condition that the injected
traffic does not exceed the capacity of the reverse data path. traffic does not exceed the capacity of the reverse data path.
The value of the interval MUST be reported. The value 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 of 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
layer serialization/de-serialization of the test signal for
certain data path technologies. For instance, for an LSP between
a pair of low speed Ethernet interfaces, the time needed to
serialize/deserialize a large frame may not be negligible. In
this case, it is RECOMMENDED that the egress node uses small
frames. The average 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 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, RSRD MUST be treated as undefined. of time, i.e., a threshold, RSRD MUST be treated as undefined.
The value of the threshold MUST be reported. The value of the threshold MUST be reported.
o If error free signal is received before PATH message is sent on o If error free signal is received before PATH message is sent on
the ingress node, an error MUST be reported and the measurement 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, the metric value MUST NOT be counted.
skipping to change at page 14, line 31 skipping to change at page 14, line 31
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 which cross connections are programmed before PATH message is in which cross connections are programmed before PATH message is
sent downtream. sent downtream.
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 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
skipping to change at page 15, line 17 skipping to change at page 15, line 17
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. And clock synchronization between the ingress node and
egress node is not required. egress 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 underline
data plane technology is different. For instance, for an LSP data plane technology is different. For instance, for an LSP
between a pair of Ethernet interfaces, the egress node (sometimes between a pair of Ethernet interfaces, the egress node (sometimes
the tester) may use a rate based method to verify the availability the tester) may use a rate based method to verify the connectivity
of the data path and use the reception of the first error free of the data path and use the reception of the first error free
frame as the error free signal. In this case, the interval frame as the error free signal. In this case, the interval
between two successive frames has a significant impact on between two successive frames has a significant impact on
accuracy. It is RECOMMENDED that in this case the ingress node accuracy. It is RECOMMENDED that in this case the ingress node
uses small intervals, under the condition that the injected uses small intervals, under the condition that the injected
traffic does not exceed the capacity of the forward data path. traffic does not exceed the capacity of the forward data path.
The value of the interval MUST be reported. The value 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 of propagating the error free signal
from the ingress node to the egress node under the same 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
layer serialization/de-serialization of the test signal for
certain data path technologies. For instance, for an LSP between
a pair of low speed Ethernet interfaces, the time needed to
serialize/deserialize a large frame may not be negligible. In
this case, it is RECOMMENDED that the ingress node uses small
frames. The average length of the frame MAY be reported.
o If error free signal is received before PATH message is sent, an o If error free signal is received before PATH message is sent, an
error MUST be reported and the measurement SHOULD terminate. 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, the 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 PRFD measurement is carried out after a negetive RRFD value
has already been observed. has already been observed.
7.7. Methodologies 7.7. Methodologies
skipping to change at page 17, line 27 skipping to change at page 17, line 27
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 availability. The difference designers as indication of data path connectivity. The difference
between the control plane setup delay and data path delay, and the between the control plane setup delay and data path delay, and the
potential failure of cross connection programming, if not properly potential failure of cross connection programming, if not properly
treated, will result in data loss or application failure. This treated, will result in data loss or application failure. This
metric can thus help designers to improve the application model. metric can thus help designers to improve the application model.
8.2. Metric Name 8.2. Metric Name
PSFD 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
skipping to change at page 18, line 20 skipping to change at page 18, line 20
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. And clock synchronization between
the ingress node and egress node is required. the ingress node and egress node is required.
o The accuracy of this metric is also dependent on how the error o The accuracy of this metric is also dependent on how the error
free signal is received and may differ significantly when the free 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 availability 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 uses 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 this metric is also dependent on the time needed
to propagate the error free signal from the ingress node to the to 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 of propagating the error free signal
from the ingress node to the egress node under the same 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
layer serialization/de-serialization of the test signal for
certain data path technologies. For instance, for an LSP between
a pair of low speed Ethernet interfaces, the time needed to
serialize/deserialize a large frame may not be negligible. In
this case, it is RECOMMENDED that the ingress node uses small
frames. The average length of the frame MAY be reported.
o If error free signal is received before PATH message is sent, an o If error free signal is received before PATH message is sent, an
error MUST be reported and the measurement SHOULD terminate. 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, the 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, the metric value MUST be treated as
undefined. The value of the threshold MUST be reported. undefined. The value of the threshold MUST be reported.
skipping to change at page 20, line 25 skipping to change at page 20, line 25
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 availability. The difference designers as indication of data path connectivity. The difference
between the control plane setup delay and data path delay, and the between the control plane setup delay and data path delay, and the
potential failure of cross connection programming, if not properly potential failure of cross connection programming, if not properly
treated, will result in data loss or application failure. This treated, will result in data loss or application failure. This
metric can thus help designers to improve the application model. metric can thus help designers to improve the application model.
9.2. Metric Name 9.2. Metric Name
PSRD 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
skipping to change at page 21, line 18 skipping to change at page 21, line 18
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. And clock synchronization between the ingress node
and egress node is not required. and egress node is not required.
o The accuracy of this metric is also dependent on how the error o The accuracy of this metric is also dependent on how the error
free signal is received and may differ significantly when the free 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 availability 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 uses 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 this metric is also dependent on the time needed
to propagate the error free signal from the egress node to the to 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 of 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
layer serialization/de-serialization of the test signal for
certain data path technologies. For instance, for an LSP between
a pair of low speed Ethernet interfaces, the time needed to
serialize/deserialize a large frame may not be negligible. In
this case, it is RECOMMENDED that the egress node uses small
frames. The average length of the frame MAY be reported.
o If error free signal is received before PATH message is sent, an o If error free signal is received before PATH message is sent, an
error MUST be reported and the measurement SHOULD terminate. 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, the metric value MUST be treated as
undefined. The value of the threshold MUST be reported. undefined. The value of the threshold MUST be reported.
skipping to change at page 30, line 8 skipping to change at page 30, line 8
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. IANA Considerations
This document makes no requests for IANA action. This document makes no requests for IANA action.
14. Acknowledgements 14. Acknowledgements
We wish to thank Adrian Farrel, Lou Berger and Al Morton for their We wish to thank Adrian Farrel, Lou Berger and Al Morton for their
comments and helps. comments and help.
This document contains ideas as well as text that have appeared in This document contains ideas as well as text that have appeared in
existing IETF documents. The authors wish to thank G. Almes, S. existing IETF documents. The authors wish to thank G. Almes, S.
Kalidindi and M. Zekauskas. Kalidindi and M. Zekauskas.
We also wish to thank Weisheng Hu, Yaohui Jin and Wei Guo in the We also wish to thank Weisheng Hu, Yaohui Jin and Wei Guo in the
state key laboratory of advanced optical communication systems and state key laboratory of advanced optical communication systems and
networks for the valuable comments. We also wish to thank the networks for the valuable comments. We also wish to thank the
support from NSFC and 863 program of China. support from NSFC and 863 program of China.
skipping to change at page 32, line 23 skipping to change at page 32, line 23
Phone: +86 21 3420 5359 Phone: +86 21 3420 5359
Email: sun.weiqiang@gmail.com Email: sun.weiqiang@gmail.com
Guoying Zhang, Editor Guoying Zhang, Editor
China Academy of Telecommunication Research, MIIT, China. China Academy of Telecommunication Research, MIIT, China.
No.52 Hua Yuan Bei Lu,Haidian District No.52 Hua Yuan Bei Lu,Haidian District
Beijing 100083 Beijing 100083
China China
Phone: +86 1062300103 Phone: +86 1062300103
EMail: zhangguoying@mail.ritt.com.cn EMail: zhangguoying@catr.cn
Jianhua Gao Jianhua Gao
Huawei Technologies Co., LTD. Huawei Technologies Co., LTD.
China China
Phone: +86 755 28973237 Phone: +86 755 28973237
Email: gjhhit@huawei.com Email: gjhhit@huawei.com
Guowu Xie Guowu Xie
University of California, Riverside University of California, Riverside
 End of changes. 31 change blocks. 
27 lines changed or deleted 67 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/