draft-ietf-ccamp-dpm-01.txt   draft-ietf-ccamp-dpm-02.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: April 12, 2011 CATR Expires: May 26, 2011 CATR
October 9, 2010 November 22, 2010
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-01.txt draft-ietf-ccamp-dpm-02.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 April 12, 2011. This Internet-Draft will expire on May 26, 2011.
Copyright Notice Copyright Notice
Copyright (c) 2010 IETF Trust and the persons identified as the Copyright (c) 2010 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 5, line 8 skipping to change at page 5, line 8
15. References . . . . . . . . . . . . . . . . . . . . . . . . . . 32 15. References . . . . . . . . . . . . . . . . . . . . . . . . . . 32
15.1. Normative References . . . . . . . . . . . . . . . . . . . 32 15.1. Normative References . . . . . . . . . . . . . . . . . . . 32
15.2. Informative References . . . . . . . . . . . . . . . . . . 32 15.2. Informative References . . . . . . . . . . . . . . . . . . 32
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 33 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 33
1. Introduction 1. Introduction
Ideally, the completion of the signaling process means that the Ideally, the completion of the signaling process means that the
signaled label switched path (LSP) is available and is ready to carry signaled label switched path (LSP) is ready to carry traffic.
traffic. However, in actual implementations, vendors may choose to However, in actual implementations, vendors may choose to program the
program the cross connection in a pipelined manner, so that the cross connection in a pipelined manner, so that the overall LSP
overall LSP provisioning delay can be reduced. In such situations, provisioning delay can be reduced. In such situations, the data path
the data path may not be available instantly after the signaling may not be ready for use instantly after the signaling process
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 availability. For
example, when invoking through User Network Interface (UNI), a client example, when invoking through User Network Interface (UNI), a client
skipping to change at page 7, line 20 skipping to change at page 7, line 20
sense that the completion of the signaling process for a Label sense that the completion of the signaling process for a Label
Switched Path (LSP) and the programming of cross connections along Switched Path (LSP) and the programming of cross connections along
the LSP may not be consistent. The performance metrics in [RFC5814] the LSP may not be consistent. The performance metrics in [RFC5814]
characterize the performance of LSP provisioning from the pure characterize the performance of LSP provisioning from the pure
signaling point of view, while the metric in this document takes into signaling point of view, while the metric in this document takes into
account the validity of the data path. account the validity of the data path.
The five metrics are: The five metrics are:
o RRFD - the delay between RESV message received by ingress node and o RRFD - the delay between RESV message received by ingress node and
forward data path becomes available. forward data path becomes ready for use.
o RSRD - the delay between RESV message sent by egress node and o RSRD - the delay between RESV message sent by egress node and
reverse data path becomes available. reverse data path becomes ready for use.
o PRFD - the delay between PATH message received by egress node and o PRFD - the delay between PATH message received by egress node and
forward data path becomes available. forward data path becomes ready for use.
o PSFD - the delay between PATH message sent by ingress and forward o PSFD - the delay between PATH message sent by ingress and forward
data path becomes available. data path becomes ready for use.
o PSRD - the delay between PATH message sent by ingress and reverse o PSRD - the delay between PATH message sent by ingress and reverse
data path becomes available. 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 IPPM Framework document, [RFC2330]
[RFC2679] [RFC2681]. The reader is assumed to be familiar with the [RFC2679] [RFC2681]. The reader is assumed to be familiar with the
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 to the ingress
in a bidirectional LSP. in a bidirectional LSP.
o Data path delay - the time needed to complete the data o Data path delay - the time needed to complete the data path
path configuration, in relation to the signaling process. five configuration, in relation to the signaling process. Five types
types of data path delay are defined in this document, namely of data path delay are defined in this document, namely RRFD,
RRFD, RSRD and PRFD. Data path delay used in this document must RSRD, PRFD, PSFD and PSRD. Data path delay used in this document
be distinguished from the data path transmission delay. must be distinguished from the transmission delay along the data
path, i.e., the time needed to transmit traffic from one side of
the data path to the other.
o Error free signal - data plane specific indication of 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 can 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.
skipping to change at page 9, line 24 skipping to change at page 9, line 24
between the reception of RESV message by the ingress node and the between the reception of RESV message by the ingress node and the
completion of the cross connection programming along the forward data completion of the cross connection programming along the forward data
path. path.
5.1. Motivation 5.1. Motivation
RRFD is useful for several reasons: RRFD is useful for several reasons:
o For the reasons described in o For the reasons described in
[I-D.shiomoto-ccamp-switch-programming], the data path may not be [I-D.shiomoto-ccamp-switch-programming], the data path may not be
available instantly after the completion of the RSVP-TE signaling ready for use instantly after the completion of the RSVP-TE
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 availability. 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
skipping to change at page 10, line 43 skipping to change at page 10, line 43
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
downstream and the data path may be available 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
the measurement SHOULD terminate. 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
skipping to change at page 12, line 25 skipping to change at page 12, line 25
the cross connection programming along the reverse data path. This the cross connection programming along the reverse data path. This
metric MAY be used together with RRFD to characterize the data path metric MAY be used together with RRFD to characterize the data path
delay of a bidirectional LSP. delay of a bidirectional LSP.
6.1. Motivation 6.1. Motivation
RSRD is useful for several reasons: RSRD is useful for several reasons:
o For the reasons described in o For the reasons described in
[I-D.shiomoto-ccamp-switch-programming], the data path may not be [I-D.shiomoto-ccamp-switch-programming], the data path may not be
available instantly after the completion of the RSVP-TE signaling ready for use instantly after the completion of the RSVP-TE
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 availability. 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
skipping to change at page 15, line 13 skipping to change at page 15, line 13
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. setup.
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 PATH message
further downstream. In this case, the forward data path may become further downstream. In this case, the forward data path may become
available before the signaling process completes, ie. before the RESV ready for use before the signaling process completes, ie. before the
reaches the ingress node. This metric can be used to identify such RESV reaches the ingress node. This metric can be used to identify
implementation practice and give useful information to application such implementation practice and give useful information to
designers. 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 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
skipping to change at page 31, line 7 skipping to change at page 31, line 7
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 and Lou Berger for their comments and We wish to thank Adrian Farrel, Lou Berger and Al Morton for their
helps. comments and helps.
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 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 1998. May 2698.
[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
skipping to change at page 34, line 31 skipping to change at page 34, line 31
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: otani@kddilabs.jp 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
 End of changes. 17 change blocks. 
33 lines changed or deleted 35 lines changed or added

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