draft-ietf-ccamp-lsp-dppm-02.txt   draft-ietf-ccamp-lsp-dppm-03.txt 
Network Working Group W. Sun Network Working Group W. Sun
Internet-Draft SJTU Internet-Draft SJTU
Intended status: Standards Track G. Zhang Intended status: Standards Track G. Zhang
Expires: December 26, 2008 CATR Expires: June 7, 2009 CATR
J. Gao J. Gao
Huawei Huawei
G. Xie G. Xie
SJTU SJTU
December 4, 2008
June 24, 2008
Label Switched Path (LSP) Dynamic Provisioning Performance Metrics in Label Switched Path (LSP) Dynamic Provisioning Performance Metrics in
Generalized MPLS Networks Generalized MPLS Networks
draft-ietf-ccamp-lsp-dppm-02.txt draft-ietf-ccamp-lsp-dppm-03.txt
Status of this Memo Status of this Memo
By submitting this Internet-Draft, each author represents that any By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware applicable patent or other IPR claims of which he or she is aware
have been or will be disclosed, and any of which he or she becomes have been or will be disclosed, and any of which he or she becomes
aware will be disclosed, in accordance with Section 6 of BCP 79. aware will be disclosed, in accordance with Section 6 of BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF), its areas, and its working groups. Note that
skipping to change at page 2, line 5 skipping to change at page 2, line 5
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."
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt. http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html.
This Internet-Draft will expire on December 16, 2008. This Internet-Draft will expire on June 7, 2009.
Abstract Abstract
Generalized Multi-Protocol Label Switching (GMPLS) is one of the most Generalized Multi-Protocol Label Switching (GMPLS) is one of the most
promising candidate technologies for future data transmission promising candidate technologies for future data transmission
network. GMPLS has been developed to control and operate different network. GMPLS has been developed to control and operate different
kinds of network elements, such as conventional routers, switches, kinds of network elements, such as conventional routers, switches,
Dense Wavelength Division Multiplexing (DWDM) systems, Add- Drop Dense Wavelength Division Multiplexing (DWDM) systems, Add- Drop
Multiplexors (ADMs), photonic cross-connects (PXCs), optical cross- Multiplexors (ADMs), photonic cross-connects (PXCs), optical cross-
connects (OXCs), etc. Dynamic provisioning ability of these connects (OXCs), etc. Dynamic provisioning ability of these
skipping to change at page 41, line 19 skipping to change at page 41, line 19
o The unidirectional/bidirectional LSP setup delay is one ingress- o The unidirectional/bidirectional LSP setup delay is one ingress-
egress round trip time plus processing time. But in this egress round trip time plus processing time. But in this
document, unidirectional/bidirectional LSP setup delay has not document, unidirectional/bidirectional LSP setup delay has not
taken the processing time in the end nodes (ingress or/and egress) taken the processing time in the end nodes (ingress or/and egress)
into account. The timestamp T2 is taken after the endpoint node into account. The timestamp T2 is taken after the endpoint node
receives it. Actually, the last node has to take some time to receives it. Actually, the last node has to take some time to
process local procedure. Similarly, in the LSP graceful release process local procedure. Similarly, in the LSP graceful release
delay, the memo has not considered the processing time in the delay, the memo has not considered the processing time in the
endpoint node. endpoint node.
o All these metrics are defined from the point of control plane's o This document assumes that the correct procedures for installing
view. In fact, the control plane and data plane are not always the data plane are followed as described in [RFC3209], [RFC3471],
synchronized. In some cases, the LSPs have been set up in the and [RFC3473]. That is, by the time the egress receives and
control plane. But the data can not be forwarded immediately. processes a Path message, it is safe for the egress to transmit
The unidirectional/bidirectional LSP setup delay in the data plane data on the reverse path, and by the time the ingress receives and
is longer than in the control plane. processes a Resv message it is safe for the ingress to transmit
data on the forward path. This document does not include any
verification that the implementations of the control plane
software are conformant, although such tests could be constructed
with the use of suitable signal generation test equipment. Note
that, in implementing the tests described in this document a
tester should be sure to measure the time taken for the control
plane messages including the processing of those messages by the
nodes under test.
o Bidirectional LSPs may be setup using three way signalling,where
the initiate node will send a RESV_CONF message downsteam upon
receiving the RESV message. The RESV_CONF message is used to
notify the terminate node that it can transfer data upstream.
Actually, both direction should be ready to transfer data when the
RESV message is received by the initiate node. Therefore, the
bidirectional LSP setup delay defined in this document,does not
take the confirmation procedure in to account.
16. Security Considerations 16. Security Considerations
Samples of the metrics can be obtained in either active or passive Samples of the metrics can be obtained in either active or passive
manners. manners.
In the active manner, ingress nodes inject probing messages into the In the active manner, ingress nodes inject probing messages into the
control plane. The measurement parameters must be carefully selected control plane. The measurement parameters must be carefully selected
so that the measurements inject trivial amounts of additional traffic so that the measurements inject trivial amounts of additional traffic
into the networks they measure. If they inject "too much" traffic, into the networks they measure. If they inject "too much" traffic,
skipping to change at page 45, line 23 skipping to change at page 45, line 23
[RFC2679] Almes, G., Kalidindi, S., and M. Zekauskas, "A One-way [RFC2679] Almes, G., Kalidindi, S., and M. Zekauskas, "A One-way
Delay Metric for IPPM", RFC 2679, September 1999. Delay Metric for IPPM", RFC 2679, September 1999.
[RFC2681] Almes, G., Kalidindi, S., and M. Zekauskas, "A Round-trip [RFC2681] Almes, G., Kalidindi, S., and M. Zekauskas, "A Round-trip
Delay Metric for IPPM", RFC 2681, September 1999. Delay Metric for IPPM", RFC 2681, September 1999.
[RFC3209] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V., [RFC3209] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V.,
and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP
Tunnels", RFC 3209, December 2001. Tunnels", RFC 3209, December 2001.
[RFC3471] Berger, L., "Generalized Multi-Protocol Label Switching
(GMPLS) Signaling Functional Description", RFC 3471,
January 2003.
[RFC3473] Berger, L., "Generalized Multi-Protocol Label Switching [RFC3473] Berger, L., "Generalized Multi-Protocol Label Switching
(GMPLS) Signaling Resource ReserVation Protocol-Traffic (GMPLS) Signaling Resource ReserVation Protocol-Traffic
Engineering (RSVP-TE) Extensions", RFC 3473, January 2003. Engineering (RSVP-TE) Extensions", RFC 3473, January 2003.
[RFC3945] Mannie, E., "Generalized Multi-Protocol Label Switching [RFC3945] Mannie, E., "Generalized Multi-Protocol Label Switching
(GMPLS) Architecture", RFC 3945, October 2004. (GMPLS) Architecture", RFC 3945, October 2004.
[RFC4208] Swallow, G., Drake, J., Ishimatsu, H., and Y. Rekhter, [RFC4208] Swallow, G., Drake, J., Ishimatsu, H., and Y. Rekhter,
"Generalized Multiprotocol Label Switching (GMPLS) User- "Generalized Multiprotocol Label Switching (GMPLS) User-
Network Interface (UNI): Resource ReserVation Protocol- Network Interface (UNI): Resource ReserVation Protocol-
 End of changes. 6 change blocks. 
11 lines changed or deleted 31 lines changed or added

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