draft-ietf-ccamp-dpm-03.txt   draft-ietf-ccamp-dpm-04.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: November 25, 2011 CATR Expires: April 3, 2012 CATR
May 24, 2011 Oct 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-03.txt draft-ietf-ccamp-dpm-04.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 November 25, 2011. This Internet-Draft will expire on April 3, 2012.
Copyright Notice Copyright Notice
Copyright (c) 2011 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
skipping to change at page 3, line 20 skipping to change at page 3, line 20
3. Overview of Performance Metrics . . . . . . . . . . . . . . . 7 3. Overview of Performance Metrics . . . . . . . . . . . . . . . 7
4. Terms used in this document . . . . . . . . . . . . . . . . . 8 4. Terms used in this document . . . . . . . . . . . . . . . . . 8
5. A singleton Definition for RRFD . . . . . . . . . . . . . . . 9 5. A singleton Definition for RRFD . . . . . . . . . . . . . . . 9
5.1. Motivation . . . . . . . . . . . . . . . . . . . . . . . . 9 5.1. Motivation . . . . . . . . . . . . . . . . . . . . . . . . 9
5.2. Metric Name . . . . . . . . . . . . . . . . . . . . . . . 9 5.2. Metric Name . . . . . . . . . . . . . . . . . . . . . . . 9
5.3. Metric Parameters . . . . . . . . . . . . . . . . . . . . 9 5.3. Metric Parameters . . . . . . . . . . . . . . . . . . . . 9
5.4. Metric Units . . . . . . . . . . . . . . . . . . . . . . . 9 5.4. Metric Units . . . . . . . . . . . . . . . . . . . . . . . 9
5.5. Definition . . . . . . . . . . . . . . . . . . . . . . . . 10 5.5. Definition . . . . . . . . . . . . . . . . . . . . . . . . 9
5.6. Discussion . . . . . . . . . . . . . . . . . . . . . . . . 10 5.6. Discussion . . . . . . . . . . . . . . . . . . . . . . . . 10
5.7. Methodologies . . . . . . . . . . . . . . . . . . . . . . 11 5.7. Methodologies . . . . . . . . . . . . . . . . . . . . . . 11
6. A singleton Definition for RSRD . . . . . . . . . . . . . . . 12 6. A singleton Definition for RSRD . . . . . . . . . . . . . . . 12
6.1. Motivation . . . . . . . . . . . . . . . . . . . . . . . . 12 6.1. Motivation . . . . . . . . . . . . . . . . . . . . . . . . 12
6.2. Metric Name . . . . . . . . . . . . . . . . . . . . . . . 12 6.2. Metric Name . . . . . . . . . . . . . . . . . . . . . . . 12
6.3. Metric Parameters . . . . . . . . . . . . . . . . . . . . 12 6.3. Metric Parameters . . . . . . . . . . . . . . . . . . . . 12
6.4. Metric Units . . . . . . . . . . . . . . . . . . . . . . . 12 6.4. Metric Units . . . . . . . . . . . . . . . . . . . . . . . 12
6.5. Definition . . . . . . . . . . . . . . . . . . . . . . . . 13 6.5. Definition . . . . . . . . . . . . . . . . . . . . . . . . 13
6.6. Discussion . . . . . . . . . . . . . . . . . . . . . . . . 13 6.6. Discussion . . . . . . . . . . . . . . . . . . . . . . . . 13
skipping to change at page 3, line 47 skipping to change at page 3, line 47
7.4. Metric Units . . . . . . . . . . . . . . . . . . . . . . . 15 7.4. Metric Units . . . . . . . . . . . . . . . . . . . . . . . 15
7.5. Definition . . . . . . . . . . . . . . . . . . . . . . . . 15 7.5. Definition . . . . . . . . . . . . . . . . . . . . . . . . 15
7.6. Discussion . . . . . . . . . . . . . . . . . . . . . . . . 16 7.6. Discussion . . . . . . . . . . . . . . . . . . . . . . . . 16
7.7. Methodologies . . . . . . . . . . . . . . . . . . . . . . 16 7.7. Methodologies . . . . . . . . . . . . . . . . . . . . . . 16
8. A singleton Definition for PSFD . . . . . . . . . . . . . . . 18 8. A singleton Definition for PSFD . . . . . . . . . . . . . . . 18
8.1. Motivation . . . . . . . . . . . . . . . . . . . . . . . . 18 8.1. Motivation . . . . . . . . . . . . . . . . . . . . . . . . 18
8.2. Metric Name . . . . . . . . . . . . . . . . . . . . . . . 18 8.2. Metric Name . . . . . . . . . . . . . . . . . . . . . . . 18
8.3. Metric Parameters . . . . . . . . . . . . . . . . . . . . 18 8.3. Metric Parameters . . . . . . . . . . . . . . . . . . . . 18
8.4. Metric Units . . . . . . . . . . . . . . . . . . . . . . . 18 8.4. Metric Units . . . . . . . . . . . . . . . . . . . . . . . 18
8.5. Definition . . . . . . . . . . . . . . . . . . . . . . . . 19 8.5. Definition . . . . . . . . . . . . . . . . . . . . . . . . 18
8.6. Discussion . . . . . . . . . . . . . . . . . . . . . . . . 19 8.6. Discussion . . . . . . . . . . . . . . . . . . . . . . . . 19
8.7. Methodologies . . . . . . . . . . . . . . . . . . . . . . 20 8.7. Methodologies . . . . . . . . . . . . . . . . . . . . . . 19
9. A singleton Definition for PSRD . . . . . . . . . . . . . . . 21 9. A singleton Definition for PSRD . . . . . . . . . . . . . . . 21
9.1. Motivation . . . . . . . . . . . . . . . . . . . . . . . . 21 9.1. Motivation . . . . . . . . . . . . . . . . . . . . . . . . 21
9.2. Metric Name . . . . . . . . . . . . . . . . . . . . . . . 21 9.2. Metric Name . . . . . . . . . . . . . . . . . . . . . . . 21
9.3. Metric Parameters . . . . . . . . . . . . . . . . . . . . 21 9.3. Metric Parameters . . . . . . . . . . . . . . . . . . . . 21
9.4. Metric Units . . . . . . . . . . . . . . . . . . . . . . . 21 9.4. Metric Units . . . . . . . . . . . . . . . . . . . . . . . 21
9.5. Definition . . . . . . . . . . . . . . . . . . . . . . . . 21 9.5. Definition . . . . . . . . . . . . . . . . . . . . . . . . 21
9.6. Discussion . . . . . . . . . . . . . . . . . . . . . . . . 22 9.6. Discussion . . . . . . . . . . . . . . . . . . . . . . . . 22
9.7. Methodologies . . . . . . . . . . . . . . . . . . . . . . 22 9.7. Methodologies . . . . . . . . . . . . . . . . . . . . . . 22
skipping to change at page 5, line 39 skipping to change at page 5, line 39
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 availability 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 [I-D.shiomoto-ccamp-switch-programming]. They also can elaborated in [RFC6383]. They also can be used to build more robust
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
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
skipping to change at page 9, line 10 skipping to change at page 9, line 10
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. setup.
As described in [I-D.shiomoto-ccamp-switch-programming], the As described in [RFC6383], the completion of the RSVP-TE signaling
completion of the RSVP-TE signaling process does not necessarily mean process does not necessarily mean that the cross connections along
that the cross connections along the LSP being setup are in place and the LSP being setup are in place and ready to carry traffic. This
ready to carry traffic. This metric defines the time difference metric defines the time difference between the reception of RESV
between the reception of RESV message by the ingress node and the message by the ingress node and the completion of the cross
completion of the cross connection programming along the forward data 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 [RFC6383], the data path may not be
[I-D.shiomoto-ccamp-switch-programming], 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 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.
skipping to change at page 12, line 10 skipping to change at page 12, line 10
signal is received within a reasonable period of time by the signal is received within a reasonable period of time by the
ingress node, RRFD is deemed to be undefined. ingress 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. setup.
As described in [I-D.shiomoto-ccamp-switch-programming], the As described in [RFC6383], the completion of the RSVP-TE signaling
completion of the RSVP-TE signaling process does not necessarily mean process does not necessarily mean that the cross connections along
that the cross connections along the LSP being setup are in place and the LSP being setup are in place and ready to carry traffic. This
ready to carry traffic. This metric defines the time difference metric defines the time difference between the completion of the
between the completion of the signaling process and the completion of signaling process and the completion of the cross connection
the cross connection programming along the reverse data path. This programming along the reverse data path. This metric MAY be used
metric MAY be used together with RRFD to characterize the data path together with RRFD to characterize the data path delay of a
delay of a bidirectional LSP. 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 [RFC6383], the data path may not be
[I-D.shiomoto-ccamp-switch-programming], 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 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.
skipping to change at page 18, line 10 skipping to change at page 18, line 10
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. setup.
As described in [I-D.shiomoto-ccamp-switch-programming], the As described in [RFC6383], the completion of the RSVP-TE signaling
completion of the RSVP-TE signaling process does not necessarily mean process does not necessarily mean that the cross connections along
that the cross connections along the LSP being setup are in place and the LSP being setup are in place and ready to carry traffic. This
ready to carry traffic. This metric defines the time from the PATH metric defines the time from the PATH message sent by the ingress
message sent by the ingress node, till the completion of the cross node, till the completion of the cross connection programming along
connection programming along the LSP forward data path. 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 o For the reasons described in [RFC6383], the data path setup delay
[I-D.shiomoto-ccamp-switch-programming], 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 availability. 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.
skipping to change at page 21, line 19 skipping to change at page 21, line 19
This metric defines the time from the ingress node sends the PATH This metric defines the time from the ingress node sends the PATH
message, till the completion of the cross connection programming message, till the completion of the cross connection programming
along the LSP reverse data path. This metric MAY be used together along the LSP reverse data path. This metric MAY be used together
with PSFD to characterize the data path delay of a bidirectional LSP. 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 o For the reasons described in [RFC6383], the data path setup delay
[I-D.shiomoto-ccamp-switch-programming], 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 availability. 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.
skipping to change at page 32, line 28 skipping to change at page 32, line 28
[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 15.2. Informative References
[I-D.shiomoto-ccamp-switch-programming]
Shiomoto, K. and A. Farrel, "Advice on When It is Safe to
Start Sending Data on Label Switched Paths Established
Using RSVP-TE", draft-shiomoto-ccamp-switch-programming-01
(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 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.
[RFC6383] Shiomoto, K. and A. Farrel, "Advice on When It Is Safe to
Start Sending Data on Label Switched Paths Established
Using RSVP-TE", RFC 6383, September 2011.
Authors' Addresses Authors' Addresses
Weiqiang Sun, Editor Weiqiang Sun, Editor
Shanghai Jiao Tong University Shanghai Jiao Tong University
800 Dongchuan Road 800 Dongchuan Road
Shanghai 200240 Shanghai 200240
China China
Phone: +86 21 3420 5359 Phone: +86 21 3420 5359
Email: sunwq@mit.edu Email: sunwq@mit.edu
skipping to change at page 33, line 42 skipping to change at page 33, line 42
Guowu Xie Guowu Xie
University of California, Riverside University of California, Riverside
900 University Ave. 900 University Ave.
Riverside, CA 92521 Riverside, CA 92521
USA USA
Phone: +1 951 237 8825 Phone: +1 951 237 8825
Email: xieg@cs.ucr.edu Email: xieg@cs.ucr.edu
Rajiv Papneja Rajiv Papneja
Isocore Huawei Technologies
12359 Sunrise Valley Drive, STE 100 Santa Clara, CA 95050
Reston, VA 20190 Reston, VA 20190
USA USA
Phone: +1 703 860 9273 Phone: +1 571 926 8593
Email: rpapneja@isocore.com Email: rajiv.papneja@huawei.com
Contributors 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
 End of changes. 18 change blocks. 
48 lines changed or deleted 41 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/