draft-ietf-ccamp-dpm-02.txt   draft-ietf-ccamp-dpm-03.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: May 26, 2011 CATR Expires: November 25, 2011 CATR
November 22, 2010 May 24, 2011
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-02.txt draft-ietf-ccamp-dpm-03.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
skipping to change at page 1, line 43 skipping to change at page 1, line 43
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 May 26, 2011. This Internet-Draft will expire on November 25, 2011.
Copyright Notice Copyright Notice
Copyright (c) 2010 IETF Trust and the persons identified as the Copyright (c) 2011 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
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
skipping to change at page 5, line 26 skipping to change at page 5, line 26
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 availability. 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 results 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 when the signaling process completes. The availability of data path during the signaling process. The metrics
metrics defined in this document complements the control plane defined in this document complements the control plane metrics
metrics defined in [RFC5814]. These metrics can be used to verify defined in [RFC5814]. These metrics can be used to verify the
the conformance of implementations against related specifications, as conformance of implementations against related specifications, as
elaborated in [I-D.shiomoto-ccamp-switch-programming]. They also can elaborated in [I-D.shiomoto-ccamp-switch-programming]. They also can
be used to build more robust applications. 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
skipping to change at page 8, line 12 skipping to change at page 8, line 12
notions in those documents. The readers are assumed to be familiar notions in those documents. The readers are assumed to be familiar
with the definitions in [RFC5814] as well. with the definitions in [RFC5814] as well.
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 to the egress.
Instances of forward data path include the data path of a uni- Instances of forward data path include the data path of a uni-
directional LSP and data path from the ingress node to the egress directional LSP and data path from the ingress node to the egress
node in a bidirectional LSP. node in a bidirectional LSP.
o Reverse data path - the data path from the egress to the ingress o Reverse data path - the data path from the egress node to the
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 availability
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 can 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
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 interact with the control plane of the network under test.
skipping to change at page 10, line 32 skipping to change at page 10, line 32
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 availability 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 the interval 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 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
skipping to change at page 32, line 36 skipping to change at page 32, line 36
15.2. Informative References 15.2. Informative References
[I-D.shiomoto-ccamp-switch-programming] [I-D.shiomoto-ccamp-switch-programming]
Shiomoto, K. and A. Farrel, "Advice on When It is Safe to 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", draft-shiomoto-ccamp-switch-programming-01 Using RSVP-TE", draft-shiomoto-ccamp-switch-programming-01
(work in progress), October 2009. (work in progress), October 2009.
[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 2698. May 1998.
[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.
Authors' Addresses Authors' Addresses
Weiqiang Sun, Editor Weiqiang Sun, Editor
Shanghai Jiao Tong University Shanghai Jiao Tong University
800 Dongchuan Road 800 Dongchuan Road
 End of changes. 10 change blocks. 
15 lines changed or deleted 15 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/