draft-ietf-ccamp-lsp-dppm-00.txt   draft-ietf-ccamp-lsp-dppm-01.txt 
ccamp 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: September 27, 2008 CATR Expires: October 12, 2008 CATR
J. Gao J. Gao
Huawei Huawei
G. Xie G. Xie
SJTU SJTU
R. Papneja
Isocore
B. Gu
IXIA
X. Wei
Fiberhome
March 26, 2008
Label Switched Path (LSP) Dynamical Provisioning Performance Metrics in April 10, 2008
Label Switched Path (LSP) Dynamic Provisioning Performance Metrics in
Generalized MPLS Networks Generalized MPLS Networks
draft-ietf-ccamp-lsp-dppm-00.txt draft-ietf-ccamp-lsp-dppm-01.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 1, line 46 skipping to change at page 1, line 41
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 September 27, 2008. This Internet-Draft will expire on October 12, 2008.
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 the future data transmission promising candidate technologies for future data transmission
network. The GMPLS has been developed to control and cooperate network. GMPLS has been developed to control and operate different
different kinds of network elements, such as conventional routers, kinds of network elements, such as conventional routers, switches,
switches, Dense Wavelength Division Multiplexing (DWDM) systems, Add- Dense Wavelength Division Multiplexing (DWDM) systems, Add- Drop
Drop Multiplexors (ADMs), photonic cross-connects (PXCs), optical Multiplexors (ADMs), photonic cross-connects (PXCs), optical cross-
cross-connects (OXCs), etc. Dynamic provisioning ability of these connects (OXCs), etc. Dynamic provisioning ability of these
physically diverse devices differs from each other drastically. At physically diverse devices differs from each other drastically. At
the same time, the need for dynamically provisioned connections is the same time, the need for Dynamicly provisioned connections is
increasing because optical networks are being deployed in metro area. increasing because optical networks are being deployed in metro
As different applications have varied requirements in the areas. As different applications have varied requirements in the
provisioning performance of optical networks, it is imperative to provisioning performance of optical networks, it is imperative to
define standardized metrics and procedures such that the performance define standardized metrics and procedures such that the performance
of networks and application needs can be mapped to each other. of networks and application needs can be mapped to each other.
This document provides a series of performance metrics to evaluate This document provides a series of performance metrics to evaluate
the dynamic LSP provisioning performance in GMPLS networks, the dynamic LSP provisioning performance in GMPLS networks,
specifically the dynamical LSP setup/release performance. These specifically the Dynamic LSP setup/release performance. These
metrics can depict the features of the GMPLS network in LSP dynamic metrics can depict the features of GMPLS networks in LSP dynamic
provisioning. They can also be used in operational networks for provisioning. They can also be used in operational networks for
carriers to monitor the control plane performance in realtime. carriers to monitor the control plane performance in realtime.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 5 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 5
2. Conventions Used in This Document . . . . . . . . . . . . . . 6 2. Overview of Performance Metrics . . . . . . . . . . . . . . . 6
3. Overview of Performance Metrics . . . . . . . . . . . . . . . 7 3. A Singleton Definition for Single Unidirectional LSP Setup
4. A Singleton Definition for single unidirectional LSP Setup Delay . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
Delay . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8 3.1. Motivation . . . . . . . . . . . . . . . . . . . . . . . . 7
4.1. Motivation . . . . . . . . . . . . . . . . . . . . . . . . 8 3.2. Metric Name . . . . . . . . . . . . . . . . . . . . . . . 7
4.2. Metric Name . . . . . . . . . . . . . . . . . . . . . . . 8 3.3. Metric Parameters . . . . . . . . . . . . . . . . . . . . 7
4.3. Metric Parameters . . . . . . . . . . . . . . . . . . . . 8 3.4. Metric Units . . . . . . . . . . . . . . . . . . . . . . . 8
4.4. Metric Units . . . . . . . . . . . . . . . . . . . . . . . 9 3.5. Definition . . . . . . . . . . . . . . . . . . . . . . . . 8
4.5. Definition . . . . . . . . . . . . . . . . . . . . . . . . 9 3.6. Discussion . . . . . . . . . . . . . . . . . . . . . . . . 8
4.6. Discussion . . . . . . . . . . . . . . . . . . . . . . . . 9 3.7. Methodologies . . . . . . . . . . . . . . . . . . . . . . 9
4.7. Methodologies . . . . . . . . . . . . . . . . . . . . . . 10 4. A Singleton Definition for multiple Unidirectional LSP
5. A Singleton Definition for multiple unidirectional LSP Setup Delay . . . . . . . . . . . . . . . . . . . . . . . . . 10
Setup Delay . . . . . . . . . . . . . . . . . . . . . . . . . 11 4.1. Motivation . . . . . . . . . . . . . . . . . . . . . . . . 10
5.1. Motivation . . . . . . . . . . . . . . . . . . . . . . . . 11 4.2. Metric Name . . . . . . . . . . . . . . . . . . . . . . . 10
5.2. Metric Name . . . . . . . . . . . . . . . . . . . . . . . 11 4.3. Metric Parameters . . . . . . . . . . . . . . . . . . . . 10
5.3. Metric Parameters . . . . . . . . . . . . . . . . . . . . 11 4.4. Metric Units . . . . . . . . . . . . . . . . . . . . . . . 10
5.4. Metric Units . . . . . . . . . . . . . . . . . . . . . . . 11 4.5. Definition . . . . . . . . . . . . . . . . . . . . . . . . 10
5.5. Definition . . . . . . . . . . . . . . . . . . . . . . . . 11 4.6. Discussion . . . . . . . . . . . . . . . . . . . . . . . . 11
5.6. Discussion . . . . . . . . . . . . . . . . . . . . . . . . 12 4.7. Methodologies . . . . . . . . . . . . . . . . . . . . . . 12
5.7. Methodologies . . . . . . . . . . . . . . . . . . . . . . 13 5. A Singleton Definition for Single Bidirectional LSP Setup
6. A Singleton Definition for single Bidirectional LSP Setup Delay . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
Delay . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14 5.1. Motivation . . . . . . . . . . . . . . . . . . . . . . . . 13
6.1. Motivation . . . . . . . . . . . . . . . . . . . . . . . . 14 5.2. Metric Name . . . . . . . . . . . . . . . . . . . . . . . 13
6.2. Metric Name . . . . . . . . . . . . . . . . . . . . . . . 14 5.3. Metric Parameters . . . . . . . . . . . . . . . . . . . . 13
6.3. Metric Parameters . . . . . . . . . . . . . . . . . . . . 14 5.4. Metric Units . . . . . . . . . . . . . . . . . . . . . . . 14
6.4. Metric Units . . . . . . . . . . . . . . . . . . . . . . . 15 5.5. Definition . . . . . . . . . . . . . . . . . . . . . . . . 14
6.5. Definition . . . . . . . . . . . . . . . . . . . . . . . . 15 5.6. Discussion . . . . . . . . . . . . . . . . . . . . . . . . 14
6.6. Discussion . . . . . . . . . . . . . . . . . . . . . . . . 15 5.7. Methodologies . . . . . . . . . . . . . . . . . . . . . . 15
6.7. Methodologies . . . . . . . . . . . . . . . . . . . . . . 16 6. A Singleton Definition for multiple Bidirectional LSPs
7. A Singleton Definition for multiple Bidirectional LSPs Setup Delay . . . . . . . . . . . . . . . . . . . . . . . . . 16
Setup Delay . . . . . . . . . . . . . . . . . . . . . . . . . 17 6.1. Motivation . . . . . . . . . . . . . . . . . . . . . . . . 16
7.1. Motivation . . . . . . . . . . . . . . . . . . . . . . . . 17 6.2. Metric Name . . . . . . . . . . . . . . . . . . . . . . . 16
7.2. Metric Name . . . . . . . . . . . . . . . . . . . . . . . 17 6.3. Metric Parameters . . . . . . . . . . . . . . . . . . . . 16
7.3. Metric Parameters . . . . . . . . . . . . . . . . . . . . 17 6.4. Metric Units . . . . . . . . . . . . . . . . . . . . . . . 16
7.4. Metric Units . . . . . . . . . . . . . . . . . . . . . . . 17 6.5. Definition . . . . . . . . . . . . . . . . . . . . . . . . 16
7.5. Definition . . . . . . . . . . . . . . . . . . . . . . . . 17 6.6. Discussion . . . . . . . . . . . . . . . . . . . . . . . . 17
7.6. Discussion . . . . . . . . . . . . . . . . . . . . . . . . 18 6.7. Methodologies . . . . . . . . . . . . . . . . . . . . . . 18
7.7. Methodologies . . . . . . . . . . . . . . . . . . . . . . 19 7. A Singleton Definition for LSP Graceful Release Delay . . . . 19
8. A Singleton Definition for LSP Graceful Release Delay . . . . 20 7.1. Motivation . . . . . . . . . . . . . . . . . . . . . . . . 19
8.1. Motivation . . . . . . . . . . . . . . . . . . . . . . . . 20 7.2. Metric Name . . . . . . . . . . . . . . . . . . . . . . . 19
8.2. Metric Name . . . . . . . . . . . . . . . . . . . . . . . 20 7.3. Metric Parameters . . . . . . . . . . . . . . . . . . . . 19
8.3. Metric Parameters . . . . . . . . . . . . . . . . . . . . 20 7.4. Metric Units . . . . . . . . . . . . . . . . . . . . . . . 19
8.4. Metric Units . . . . . . . . . . . . . . . . . . . . . . . 20 7.5. Definition . . . . . . . . . . . . . . . . . . . . . . . . 19
8.5. Definition . . . . . . . . . . . . . . . . . . . . . . . . 20 7.6. Discussion . . . . . . . . . . . . . . . . . . . . . . . . 20
8.6. Discussion . . . . . . . . . . . . . . . . . . . . . . . . 21 7.7. Methodologies . . . . . . . . . . . . . . . . . . . . . . 21
8.7. Methodologies . . . . . . . . . . . . . . . . . . . . . . 22 8. Typical Testing Cases of Single Unidirectional LSP Setup
9. Typical Testing cases of single Unidirectional LSP Setup Delay . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23
Delay . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24 8.1. With No LSP in the Network . . . . . . . . . . . . . . . . 23
9.1. With no LSP in the Network . . . . . . . . . . . . . . . . 24 8.1.1. Motivation . . . . . . . . . . . . . . . . . . . . . . 23
9.1.1. Motivation . . . . . . . . . . . . . . . . . . . . . . 24 8.1.2. Methodologies . . . . . . . . . . . . . . . . . . . . 23
9.1.2. Methodologies . . . . . . . . . . . . . . . . . . . . 24 8.2. With a Number of LSPs in the Network . . . . . . . . . . . 23
9.2. With a Number of LSPs in the Network . . . . . . . . . . . 24 8.2.1. Motivation . . . . . . . . . . . . . . . . . . . . . . 23
9.2.1. Motivation . . . . . . . . . . . . . . . . . . . . . . 24 8.2.2. Methodologies . . . . . . . . . . . . . . . . . . . . 23
9.2.2. Methodologies . . . . . . . . . . . . . . . . . . . . 24 9. Typical Testing Cases of multiple Unidirectional LSPs
10. Typical Testing cases of multiple Unidirectional LSPs Setup Delay . . . . . . . . . . . . . . . . . . . . . . . . . 25
Setup Delay . . . . . . . . . . . . . . . . . . . . . . . . . 26 9.1. With No LSP in the Network . . . . . . . . . . . . . . . . 25
10.1. With no LSP in the Network . . . . . . . . . . . . . . . . 26 9.1.1. Motivation . . . . . . . . . . . . . . . . . . . . . . 25
10.1.1. Motivation . . . . . . . . . . . . . . . . . . . . . . 26 9.1.2. Methodologies . . . . . . . . . . . . . . . . . . . . 25
10.1.2. Methodologies . . . . . . . . . . . . . . . . . . . . 26 9.2. With a Number of LSPs in the Network . . . . . . . . . . . 25
10.2. With a Number of LSPs in the Network . . . . . . . . . . . 26 9.2.1. Motivation . . . . . . . . . . . . . . . . . . . . . . 25
10.2.1. Motivation . . . . . . . . . . . . . . . . . . . . . . 26 9.2.2. Methodologies . . . . . . . . . . . . . . . . . . . . 25
10.2.2. Methodologies . . . . . . . . . . . . . . . . . . . . 26 10. Typical Testing Cases of Single Bidirectional LSP Setup
11. Typical Testing cases of single Bidirectional LSP Setup Delay . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27
Delay . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28 10.1. With No LSP in the Network . . . . . . . . . . . . . . . . 27
11.1. With no LSP in the Network . . . . . . . . . . . . . . . . 28 10.1.1. Motivation . . . . . . . . . . . . . . . . . . . . . . 27
11.1.1. Motivation . . . . . . . . . . . . . . . . . . . . . . 28 10.1.2. Methodologies . . . . . . . . . . . . . . . . . . . . 27
11.1.2. Methodologies . . . . . . . . . . . . . . . . . . . . 28 10.2. With a Number of LSPs in the Network . . . . . . . . . . . 27
11.2. With a Number of LSPs in the Network . . . . . . . . . . . 28 10.2.1. Motivation . . . . . . . . . . . . . . . . . . . . . . 27
11.2.1. Motivation . . . . . . . . . . . . . . . . . . . . . . 28 10.2.2. Methodologies . . . . . . . . . . . . . . . . . . . . 27
11.2.2. Methodologies . . . . . . . . . . . . . . . . . . . . 28 11. Typical Testing Cases of multiple Bidirectional LSPs Setup
12. Typical Testing cases of multiple Bidirectional LSPs Setup Delay . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29
Delay . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30 11.1. With No LSP in the Network . . . . . . . . . . . . . . . . 29
12.1. With no LSP in the Network . . . . . . . . . . . . . . . . 30 11.1.1. Motivation . . . . . . . . . . . . . . . . . . . . . . 29
12.1.1. Motivation . . . . . . . . . . . . . . . . . . . . . . 30 11.1.2. Methodologies . . . . . . . . . . . . . . . . . . . . 29
12.1.2. Methodologies . . . . . . . . . . . . . . . . . . . . 30 11.2. With a Number of LSPs in the Network . . . . . . . . . . . 29
12.2. With a Number of LSPs in the Network . . . . . . . . . . . 30 11.2.1. Motivation . . . . . . . . . . . . . . . . . . . . . . 29
12.2.1. Motivation . . . . . . . . . . . . . . . . . . . . . . 30 11.2.2. Methodologies . . . . . . . . . . . . . . . . . . . . 29
12.2.2. Methodologies . . . . . . . . . . . . . . . . . . . . 30 12. Some Statistics Definitions for Metrics to Report . . . . . . 31
13. Some Statistics Definitions for Metrics to Report . . . . . . 32 12.1. The Minimum of Metric . . . . . . . . . . . . . . . . . . 31
13.1. The Minimum of Metric . . . . . . . . . . . . . . . . . . 32 12.2. The Median of Metric . . . . . . . . . . . . . . . . . . . 31
13.2. The Median of Metric . . . . . . . . . . . . . . . . . . . 32 12.3. The percentile of Metric . . . . . . . . . . . . . . . . . 31
13.3. The percentile of Metric . . . . . . . . . . . . . . . . . 32 12.4. The Failure Probability . . . . . . . . . . . . . . . . . 31
13.4. The failure probability . . . . . . . . . . . . . . . . . 32 13. Discussion . . . . . . . . . . . . . . . . . . . . . . . . . . 32
14. Discussion . . . . . . . . . . . . . . . . . . . . . . . . . . 33 14. Security Considerations . . . . . . . . . . . . . . . . . . . 33
15. Security Considerations . . . . . . . . . . . . . . . . . . . 34 15. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 34
16. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 35 16. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 35
17. Normative References . . . . . . . . . . . . . . . . . . . . . 36 17. References . . . . . . . . . . . . . . . . . . . . . . . . . . 36
17.1. Normative References . . . . . . . . . . . . . . . . . . . 36
17.2. Informative References . . . . . . . . . . . . . . . . . . 36
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 37 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 37
Intellectual Property and Copyright Statements . . . . . . . . . . 39 Intellectual Property and Copyright Statements . . . . . . . . . . 39
1. Introduction 1. Introduction
Generalized Multi-Protocol Label Switching (GMPLS) is one of the most Generalized Multi-Protocol Label Switching (GMPLS) is one of the most
promising control plane solutions for future transport and service promising control plane solutions for future transport and service
network. GMPLS has been developed to control and cooperate 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
physically diverse devices differs from each other drastically. physically diverse devices differs from each other drastically.
The introduction of a control plane into optical circuit switching The introduction of a control plane into optical circuit switching
networks automates the provisioning of connections and drastically networks automates the provisioning of connections and drastically
reduces connection provision delay. As more and more services and reduces connection provision delay. As more and more services and
applications are seeking to use GMPLS controled networks as their applications are seeking to use GMPLS controled networks as their
underlying transport network, and increasingly in a dynamic way, the underlying transport network, and increasingly in a dynamic way, the
need is growing for measuring and characterizing the performance of need is growing for measuring and characterizing the performance of
LSP provisioning in GMPLS networks, such that requirement from LSP provisioning in GMPLS networks, such that requirement from
applications and the provisioning capability of the network can be applications and the provisioning capability of the network can be
mapped to each other. mapped to each other.
This draft intends to define performance metrics and methodologies This draft defines performance metrics and methodologies that can be
that can be used to depict the dynamic connection provisioning used to depict the dynamic connection provisioning performance of
performance of GMPLS networks. The metrics defined in this draft can GMPLS networks. The metrics defined in this document can in the one
in the one hand be used to depict the averaged performance of GMPLS hand be used to depict the averaged performance of GMPLS
implementations. On the other hand, it can also be used in implementations. On the other hand, it can also be used in
operational environments for carriers to monitor the control plane operational environments for carriers to monitor the control plane
operation in realtime. For example, an new object can be added to operation in realtime. For example, extensions can be made to GMPLS
the GMPLS TE STD MIB [RFC4802] such that the current and past control TE STD MIB [RFC4802] such that the current and past control plane
plane performance can be monitored through network management performance can be monitored through network management systems. The
systems. The extension of TE-MIB to support the metrics defined is extension of TE-MIB to support the metrics defined is out the scope
out the scope of this document. of this document.
2. Conventions Used in This Document
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 2. Overview of Performance Metrics
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [RFC2119].
3. Overview of Performance Metrics In this document, to depict the dynamic LSP provisioning performance
of a GMPLS network, we define 5 performance metrics: single/multiple
unidirectional LSP(s) setup delay, single/multiple bidirectional
LSP(s) setup delay, and LSP graceful release delay. The latency of
the LSP setup/release signal is similar to the Round-trip Delay in IP
networks. So we refer the structures and notions introduced and
discussed in the IPPM Framework document, [RFC2330] [RFC2679]
[RFC2681]. The reader is assumed to be familiar with the notions in
those documents.
In this memo, to depict the dynamic LSP provisioning performance of a We further define typical testing cases to obtain samples of the
GMPLS network, we define 3 performance metrics: unidirectional LSP defined metrics, namely, when there is no LSP in the network, or
setup delay, bidirectional LSP setup delay, and LSP graceful release there are a fixed number of LSPs in the network.
delay. The latency of the LSP setup/release signal is similar to the
Round-trip Delay in IP networks. So we refer the structures and
notions introduced and discussed in the IPPM Framework document,
[RFC2330] [RFC2679] [RFC2681]. The reader is assumed to be familiar
with the notions in those documents.
4. A Singleton Definition for single unidirectional LSP Setup Delay 3. A Singleton Definition for Single Unidirectional LSP Setup Delay
This part defines a metric for single unidirectional Label Switched This part defines a metric for single unidirectional Label Switched
Path setup delay across a GMPLS network. Path setup delay across a GMPLS network.
4.1. Motivation 3.1. Motivation
Single unidirectional Label Switched Path setup delay is useful for Single unidirectional Label Switched Path setup delay is useful for
several reasons: several reasons:
o Single LSP setup delay is an important metric that depicts the o Single LSP setup delay is an important metric that depicts the
provisioning performance of a GMPLS network. Longer LSP setup provisioning performance of a GMPLS network. Longer LSP setup
delay will incur higher overhead for the requesting application, delay will incur higher overhead for the requesting application,
especially when the LSP duration is comparable to the LSP setup especially when the LSP duration is comparable to the LSP setup
delay. delay.
skipping to change at page 8, line 43 skipping to change at page 7, line 43
Erratic variation in LSP setup delay makes it difficult to support Erratic variation in LSP setup delay makes it difficult to support
applications that has stringent setup delay requirement. applications that has stringent setup delay requirement.
The measurement of single unidirectional LSP setup delay instead of The measurement of single unidirectional LSP setup delay instead of
bidirectional LSP setup delay is motivated by the following factors: bidirectional LSP setup delay is motivated by the following factors:
o Some applications may only use unidirectional LSPs rather than o Some applications may only use unidirectional LSPs rather than
bidirectional ones. For example, content delivery services in bidirectional ones. For example, content delivery services in
multicast method (IPTV) only use unidirectional LSPs. multicast method (IPTV) only use unidirectional LSPs.
4.2. Metric Name 3.2. Metric Name
single unidirectional LSP setup delay single unidirectional LSP setup delay
4.3. Metric Parameters 3.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 o T, a time
4.4. Metric Units 3.4. Metric Units
The value of single unidirectional LSP setup delay is either a real The value of single unidirectional LSP setup delay is either a real
number, or an undefined (informally, infinite) number of number, or an undefined (informally, infinite) number of
milliseconds. milliseconds.
4.5. Definition 3.5. Definition
The single unidirectional LSP setup delay from the ingress node to The single unidirectional LSP setup delay from the ingress node to
the egress node [RFC3945] at T is dT means that ingress node sends the egress node [RFC3945] at T is dT means that ingress node sends
the first bit of a PATH message packet to egress node at wire-time T, the first bit of a PATH message packet to egress node at wire-time T,
and that the ingress node received the last bit of responding RESV and that the ingress node received the last bit of responding RESV
message packet from egress node at wire-time T+dT in the message packet from egress node at wire-time T+dT in the
unidirectional LSP setup case. unidirectional LSP setup case.
The single unidirectional LSP setup delay from the ingress node to The single unidirectional LSP setup delay from the ingress node to
the egress node at T is undefined (informally, infinite), means that the egress node at T is undefined (informally, infinite), means that
ingress node sends the first bit of PATH message packet to egress ingress node sends the first bit of PATH message packet to egress
node at wire-time T and that ingress node does not receive the node at wire-time T and that ingress node does not receive the
corresponding RESV message within a reasonable period of time. corresponding RESV message within a reasonable period of time.
4.6. Discussion 3.6. Discussion
The following issues are likely to come up in practice: The following issues are likely to come up in practice:
o The accuracy of unidirectional LSP setup delay at time T depends o The accuracy of unidirectional LSP setup delay at time T depends
on the clock resolution in the ingress node; but synchronization on the clock resolution in the ingress node; but synchronization
between the ingress node and egress node is not required since between the ingress node and egress node is not required since
unidirectional LSP setup uses two-way signaling. unidirectional LSP setup uses two-way signaling.
o A given methodology will have to include a way to determine o A given methodology will have to include a way to determine
whether a latency value is infinite or whether it is merely very whether a latency value is infinite or whether it is merely very
large. Simple upper bounds could be used. But the GMPLS network large. Simple upper bounds could be used. But GMPLS networks may
accommodates many kinds of devices. For example, some photonic accommodate many kinds of devices. For example, some photonic
cross-connects (PXCs) have to move the micro mirrors. This cross-connects (PXCs) have to move the micro mirrors. This
physical motion may take several milliseconds. But the common physical motion may take several milliseconds. But the common
electronic switches finish the nodal process within several electronic switches finish the nodal process within several
microseconds. So the unidirectional LSP setup delay varies microseconds. So the unidirectional LSP setup delay varies
drastically from a network to another. In practice, the upper drastically from a network to another. In practice, the upper
bound should be chose carefully. bound should be chosen carefully.
o If ingress node sends out the PATH message to set up LSP, but o If ingress node sends out the PATH message to set up LSP, but
never receive corresponding RESV message, unidirectional LSP setup never receive corresponding RESV message, unidirectional LSP setup
delay is deemed to be infinite. delay is deemed to be infinite.
o If ingress node sends out the PATH message to set up LSP but o If ingress node sends out the PATH message to set up LSP but
receive PathErr message, unidirectional LSP setup delay is also receive PathErr message, unidirectional LSP setup delay is also
deemed to be infinite. There are many possible reasons for this deemed to be infinite. There are many possible reasons for this
case. For example, the PATH message has invalid parameters or the case. For example, the PATH message has invalid parameters or the
network has not enough resource to set up the requested LSP, etc. network has not enough resource to set up the requested LSP, etc.
4.7. Methodologies 3.7. Methodologies
Generally the methodology would proceed as follows: Generally the methodology would proceed as follows:
o Make sure that the network has enough resource to set up the o Make sure that the network has enough resource to set up the
requested LSP. requested LSP.
o At the ingress node, form the PATH message according to the LSP o At the ingress node, form the PATH message according to the LSP
requirements. A timestamp (T1) may be stored locally in the requirements. A timestamp (T1) may be stored locally in the
ingress node when the PATH message packet is sent towards the ingress node when the PATH message packet is sent towards the
egress node. egress node.
skipping to change at page 11, line 5 skipping to change at page 10, line 5
o If the corresponding RESV message fails to arrive within a o If the corresponding RESV message fails to arrive within a
reasonable period of time, the unidirectional LSP setup delay is reasonable period of time, the unidirectional LSP setup delay is
deemed to be undefined (informally, infinite). Note that the deemed to be undefined (informally, infinite). Note that the
'reasonable' threshold of the unidirectional LSP setup delay is a 'reasonable' threshold of the unidirectional LSP setup delay is a
parameter of the methodology. parameter of the methodology.
o If the corresponding response message is PathErr, the o If the corresponding response message is PathErr, the
unidirectional LSP setup delay is deemed to be undefined unidirectional LSP setup delay is deemed to be undefined
(informally, infinite). (informally, infinite).
5. A Singleton Definition for multiple unidirectional LSP Setup Delay 4. A Singleton Definition for multiple Unidirectional LSP Setup Delay
This part defines a metric for multiple unidirectional Label Switched This part defines a metric for multiple unidirectional Label Switched
Paths setup delay across a GMPLS network. Paths setup delay across a GMPLS network.
5.1. Motivation 4.1. Motivation
multiple unidirectional Label Switched Paths setup delay is useful multiple unidirectional Label Switched Paths setup delay is useful
for several reasons: for several reasons:
o Upon traffic interruption caused by network failure or network o Upon traffic interruption caused by network failure or network
upgrade, carriers may require a large number of LSPs be set up upgrade, carriers may require a large number of LSPs be set up
during a short time period during a short time period
o The time needed to setup a large number of LSPs during a short o The time needed to setup a large number of LSPs during a short
time period can not be deduced by single LSP setup delay time period can not be deduced by single LSP setup delay
5.2. Metric Name 4.2. Metric Name
multiple unidirectional LSPs setup delay multiple unidirectional LSPs setup delay
5.3. Metric Parameters 4.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 Lambda, a rate in reciprocal milliseconds o Lambda, a rate in reciprocal milliseconds
o X, the number of LSPs to setup o X, the number of LSPs to setup
o T, a time o T, a time
5.4. Metric Units 4.4. Metric Units
The value of multiple unidirectional LSPs setup delay is either a The value of multiple unidirectional LSPs setup delay is either a
real number, or an undefined (informally, infinite) number of real number, or an undefined (informally, infinite) number of
milliseconds. milliseconds.
5.5. Definition 4.5. Definition
Given lambda and X, the multiple unidirectional LSPs setup delay from Given lambda and X, the multiple unidirectional LSPs setup delay from
the ingress node to the egress node [RFC3945] at T is dT means: the ingress node to the egress node [RFC3945] at T is dT means:
o ingress node sends the first bit of the first PATH message packet o ingress node sends the first bit of the first PATH message packet
to egress node at wire-time T to egress node at wire-time T
o all subsequent (X-1) PATH messages are sent according to the o all subsequent (X-1) PATH messages are sent according to the
specified poisson process with arrival rate lambda specified poisson process with arrival rate lambda
o ingress node receives all corresponding RESV message packets from o ingress node receives all corresponding RESV message packets from
skipping to change at page 12, line 20 skipping to change at page 11, line 20
o ingress node receives the last RESV message packet at wire-time o ingress node receives the last RESV message packet at wire-time
T+dT T+dT
The multiple unidirectional LSPs setup delay at T is undefined The multiple unidirectional LSPs setup delay at T is undefined
(informally, infinite), means that ingress node sends all the PATH (informally, infinite), means that ingress node sends all the PATH
messages toward the egress and the first bit of the first PATH messages toward the egress and the first bit of the first PATH
message packet is sent at wire-time T and that ingress node does not message packet is sent at wire-time T and that ingress node does not
receive the one or more of the corresponding RESV messages within a receive the one or more of the corresponding RESV messages within a
reasonable period of time. reasonable period of time.
5.6. Discussion 4.6. Discussion
The following issues are likely to come up in practice: The following issues are likely to come up in practice:
o The accuracy of multiple unidirectional LSPs setup delay at time T o The accuracy of multiple unidirectional LSPs setup delay at time T
depends on the clock resolution in the ingress node; but depends on the clock resolution in the ingress node; but
synchronization between the ingress node and egress node is not synchronization between the ingress node and egress node is not
required since unidirectional LSP setup uses two-way signaling. required since unidirectional LSP setup uses two-way signaling.
o A given methodology will have to include a way to determine o A given methodology will have to include a way to determine
whether a latency value is infinite or whether it is merely very whether a latency value is infinite or whether it is merely very
large. Simple upper bounds could be used. But the GMPLS network large. Simple upper bounds could be used. But GMPLS networks may
accommodates many kinds of devices. For example, some photonic accommodate many kinds of devices. For example, some photonic
cross-connects (PXCs) have to move the micro mirrors. This cross-connects (PXCs) have to move the micro mirrors. This
physical motion may take several milliseconds. But the common physical motion may take several milliseconds. But the common
electronic switches finish the nodal process within several electronic switches finish the nodal process within several
microseconds. So the multiple unidirectional LSP setup delay microseconds. So the multiple unidirectional LSP setup delay
varies drastically from a network to another. In practice, the varies drastically from a network to another. In practice, the
upper bound should be chose carefully. upper bound should be chosen carefully.
o If ingress node sends out the multiple PATH messages to set up the o If ingress node sends out the multiple PATH messages to set up the
LSPs, but never receives one or more of the corresponding RESV LSPs, but never receives one or more of the corresponding RESV
messages, the unidirectional LSP setup delay is deemed to be messages, the unidirectional LSP setup delay is deemed to be
infinite. infinite.
o If ingress node sends out the PATH messages to set up the LSPs but o If ingress node sends out the PATH messages to set up the LSPs but
receives one or more PathErr messages, multiple unidirectional receives one or more PathErr messages, multiple unidirectional
LSPs setup delay is also deemed to be infinite. There are many LSPs setup delay is also deemed to be infinite. There are many
possible reasons for this case. For example, one of the PATH possible reasons for this case. For example, one of the PATH
message has invalid parameters or the network has not enough message has invalid parameters or the network has not enough
resource to set up the requested LSPs, etc. resource to set up the requested LSPs, etc.
o The arrival rate of the poisson process lambda should be carefully o The arrival rate of the poisson process lambda should be carefully
chosen such that in the one hand the control plane is not chosen such that in the one hand the control plane is not
overburdened.On the other hand, the arrival rate should also be overburdened.On the other hand, the arrival rate should also be
large enough to meet the requirements of applications or services. large enough to meet the requirements of applications or services.
5.7. Methodologies 4.7. Methodologies
Generally the methodology would proceed as follows: Generally the methodology would proceed as follows:
o Make sure that the network has enough resource to set up the o Make sure that the network has enough resource to set up the
requested LSPs. requested LSPs.
o At the ingress node, form the PATH messages according to the LSPs' o At the ingress node, form the PATH messages according to the LSPs'
requirements. requirements.
o At the ingress node, select the time for each of the PATH messages o At the ingress node, select the time for each of the PATH messages
skipping to change at page 14, line 5 skipping to change at page 13, line 5
o If one or more of the corresponding RESV messages fails to arrive o If one or more of the corresponding RESV messages fails to arrive
within a reasonable period of time, the multiple unidirectional within a reasonable period of time, the multiple unidirectional
LSPs setup delay is deemed to be undefined (informally, infinite). LSPs setup delay is deemed to be undefined (informally, infinite).
Note that the 'reasonable' threshold is a parameter of the Note that the 'reasonable' threshold is a parameter of the
methodology. methodology.
o If one of the corresponding response message is PathErr, the o If one of the corresponding response message is PathErr, the
multiple unidirectional LSPs setup delay is deemed to be undefined multiple unidirectional LSPs setup delay is deemed to be undefined
(informally, infinite). (informally, infinite).
6. A Singleton Definition for single Bidirectional LSP Setup Delay 5. A Singleton Definition for Single Bidirectional LSP Setup Delay
GMPLS allows establishment of bi-directional symmetric LSPs (not of GMPLS allows establishment of bi-directional symmetric LSPs (not of
asymmetric LSPs). This part defines a metric for single asymmetric LSPs). This part defines a metric for single
bidirectional LSP setup delay across a GMPLS network. bidirectional LSP setup delay across a GMPLS network.
6.1. Motivation 5.1. Motivation
Single bidirectional Label Switched Path setup delay is useful for Single bidirectional Label Switched Path setup delay is useful for
several reasons: several reasons:
o LSP setup delay is an important metric that depicts the o LSP setup delay is an important metric that depicts the
provisioning performance of a GMPLS network. Longer LSP setup provisioning performance of a GMPLS network. Longer LSP setup
delay will incur higher overhead for the requesting application, delay will incur higher overhead for the requesting application,
especially when the LSP duration is comparable to the LSP setup especially when the LSP duration is comparable to the LSP setup
delay. Thus, measuring the setup delay is important for delay. Thus, measuring the setup delay is important for
applications scheduling. applications scheduling.
skipping to change at page 14, line 45 skipping to change at page 13, line 45
Erratic variation in LSP setup delay makes it difficult to support Erratic variation in LSP setup delay makes it difficult to support
applications that has stringent setup delay requirement. applications that has stringent setup delay requirement.
The measurement of single bidirectional LSP setup delay instead of The measurement of single bidirectional LSP setup delay instead of
unidirectional LSP setup delay is motivated by the following factors: unidirectional LSP setup delay is motivated by the following factors:
o Bidirectional LSPs are seen as a requirement for many GMPLS o Bidirectional LSPs are seen as a requirement for many GMPLS
networks. Its provisioning performance is important to networks. Its provisioning performance is important to
applications that generates bi-directional traffic. applications that generates bi-directional traffic.
6.2. Metric Name 5.2. Metric Name
Single bidirectional LSP setup delay Single bidirectional LSP setup delay
6.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 o T, a time
6.4. Metric Units 5.4. Metric Units
The value of single bidirectional LSP setup delay is either a real The value of single bidirectional LSP setup delay is either a real
number, or an undefined (informally, infinite) number of number, or an undefined (informally, infinite) number of
milliseconds. milliseconds.
6.5. Definition 5.5. Definition
For a real number dT, the single bidirectional LSP setup delay from For a real number dT, the single bidirectional LSP setup delay from
ingress node to egress node at T is dT, means that ingress node sends ingress node to egress node at T is dT, means that ingress node sends
out the first bit of a PATH message including an Upstream Label out the first bit of a PATH message including an Upstream Label
[RFC3473] heading for egress node at wire-time T, egress node [RFC3473] heading for egress node at wire-time T, egress node
receives that packet, then immediately sends a RESV message packet receives that packet, then immediately sends a RESV message packet
back to ingress node, and that ingress node receives the last bit of back to ingress node, and that ingress node receives the last bit of
that packet at wire-time T+dT. that packet at wire-time T+dT.
The single bidirectional LSP setup delay from ingress node to egress The single bidirectional LSP setup delay from ingress node to egress
node at T is undefined (informally, infinite), means that ingress node at T is undefined (informally, infinite), means that ingress
node sends the first bit of PATH message to egress node at wire-time node sends the first bit of PATH message to egress node at wire-time
T and that ingress node does not receive that response packet. T and that ingress node does not receive that response packet.
6.6. Discussion 5.6. Discussion
The following issues are likely to come up in practice: The following issues are likely to come up in practice:
o The accuracy of single bidirectional LSP setup delay depends on o The accuracy of single bidirectional LSP setup delay depends on
the clock resolution in the ingress node; but synchronization the clock resolution in the ingress node; but synchronization
between the ingress node and egress node is not required since between the ingress node and egress node is not required since
single bidirectional LSP setup uses two-way signaling. single bidirectional LSP setup uses two-way signaling.
o A given methodology will have to include a way to determine o A given methodology will have to include a way to determine
whether a latency value is infinite or whether it is merely very whether a latency value is infinite or whether it is merely very
large. Simple upper bounds could be used. But the GMPLS network large. Simple upper bounds could be used. But GMPLS networks may
accommodates many kinds of devices. For example, some photonic accommodate many kinds of devices. For example, some photonic
cross-connects (PXCs) have to move the micro mirrors. This cross-connects (PXCs) have to move the micro mirrors. This
physical motion may take several milliseconds. But the common physical motion may take several milliseconds. But the common
electronic switches finish the nodal process within several electronic switches finish the nodal process within several
microseconds. So the bidirectional LSP setup delay varies microseconds. So the bidirectional LSP setup delay varies
drastically from a network to another. In the process of drastically from a network to another. In the process of
bidirectional LSP setup, if the downstream node overrides the bidirectional LSP setup, if the downstream node overrides the
label suggested by the upstream node, the setup delay will also label suggested by the upstream node, the setup delay will also
increase obviously. Thus, in practice, the upper bound should be increase obviously. Thus, in practice, the upper bound should be
chosen carefully. chosen carefully.
skipping to change at page 16, line 17 skipping to change at page 15, line 17
but never receives the corresponding RESV message, single but never receives the corresponding RESV message, single
bidirectional LSP setup delay is deemed to be infinite. bidirectional LSP setup delay is deemed to be infinite.
o If the ingress node sends out the PATH message to set up the LSP, o If the ingress node sends out the PATH message to set up the LSP,
but receives PathErr message, single bidirectional LSP setup delay but receives PathErr message, single bidirectional LSP setup delay
is also deemed to be infinite. There are many possible reasons is also deemed to be infinite. There are many possible reasons
for this case. For example, the PATH message has invalid for this case. For example, the PATH message has invalid
parameters or the network has not enough resource to set up the parameters or the network has not enough resource to set up the
requested LSP. requested LSP.
6.7. Methodologies 5.7. Methodologies
Generally the methodology would proceed as follows: Generally the methodology would proceed as follows:
o Make sure that the network has enough resource to set up the o Make sure that the network has enough resource to set up the
requested LSP. requested LSP.
o At the ingress node, form the PATH message (including the Upstream o At the ingress node, form the PATH message (including the Upstream
Label or suggested label) according to the LSP requirements. A Label or suggested label) according to the LSP requirements. A
timestamp (T1) may be stored locally in the ingress node when the timestamp (T1) may be stored locally in the ingress node when the
PATH message packet is sent towards the egress node. PATH message packet is sent towards the egress node.
skipping to change at page 17, line 5 skipping to change at page 16, line 5
o If the corresponding RESV message fails to arrive within a o If the corresponding RESV message fails to arrive within a
reasonable period of time, the single bidirectional LSP setup reasonable period of time, the single bidirectional LSP setup
delay is deemed to be undefined (informally, infinite). Note that delay is deemed to be undefined (informally, infinite). Note that
the 'reasonable' threshold is a parameter of the methodology. the 'reasonable' threshold is a parameter of the methodology.
o If the corresponding response message is PathErr, the single o If the corresponding response message is PathErr, the single
bidirectional LSP setup delay is deemed to be undefined bidirectional LSP setup delay is deemed to be undefined
(informally, infinite). (informally, infinite).
7. A Singleton Definition for multiple Bidirectional LSPs Setup Delay 6. A Singleton Definition for multiple Bidirectional LSPs Setup Delay
This part defines a metric for multiple bidirectional LSPs setup This part defines a metric for multiple bidirectional LSPs setup
delay across a GMPLS network. delay across a GMPLS network.
7.1. Motivation 6.1. Motivation
multiple Bidirectional LSPs setup delay is useful for several multiple Bidirectional LSPs setup delay is useful for several
reasons: reasons:
o Upon traffic interruption caused by network failure or network o Upon traffic interruption caused by network failure or network
upgrade, carriers may require a large number of LSPs be set up upgrade, carriers may require a large number of LSPs be set up
during a short time period during a short time period
o The time needed to setup a large number of LSPs during a short o The time needed to setup a large number of LSPs during a short
time period can not be deduced by single LSP setup delay time period can not be deduced by single LSP setup delay
7.2. Metric Name 6.2. Metric Name
Multiple bidirectional LSPs setup delay Multiple bidirectional LSPs setup delay
7.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 Lambda, a rate in reciprocal milliseconds o Lambda, a rate in reciprocal milliseconds
o X, the number of LSPs to setup o X, the number of LSPs to setup
o T, a time o T, a time
7.4. Metric Units 6.4. Metric Units
The value of multiple bidirectional LSPs setup delay is either a real The value of multiple bidirectional LSPs setup delay is either a real
number, or an undefined (informally, infinite) number of number, or an undefined (informally, infinite) number of
milliseconds. milliseconds.
7.5. Definition 6.5. Definition
Given lambda and X, for a real number dT, the multiple bidirectional Given lambda and X, for a real number dT, the multiple bidirectional
LSPs setup delay from ingress node to egress node at T is dT, means LSPs setup delay from ingress node to egress node at T is dT, means
that: that:
o ingress node sends the first bit of the first PATH message heading o ingress node sends the first bit of the first PATH message heading
for egress node at wire-time T for egress node at wire-time T
o all subsequent (X-1) PATH messages are sent according to the o all subsequent (X-1) PATH messages are sent according to the
specified poisson process with arrival rate lambda specified poisson process with arrival rate lambda
skipping to change at page 18, line 18 skipping to change at page 17, line 18
egress node, and egress node, and
o ingress node receives the last RESV message packets at wire-time o ingress node receives the last RESV message packets at wire-time
T+dT T+dT
The multiple bidirectional LSPs setup delay from ingress node to The multiple bidirectional LSPs setup delay from ingress node to
egress node at T is undefined (informally, infinite), means that egress node at T is undefined (informally, infinite), means that
ingress node sends all the PATH messages to egress node and that the ingress node sends all the PATH messages to egress node and that the
ingress node dose not receive one or more of the response messages. ingress node dose not receive one or more of the response messages.
7.6. Discussion 6.6. Discussion
The following issues are likely to come up in practice: The following issues are likely to come up in practice:
o The accuracy of multiple bidirectional LSPs setup delay depends on o The accuracy of multiple bidirectional LSPs setup delay depends on
the clock resolution in the ingress node; but synchronization the clock resolution in the ingress node; but synchronization
between the ingress node and egress node is not required since between the ingress node and egress node is not required since
bidirectional LSP setup uses two-way signaling. bidirectional LSP setup uses two-way signaling.
o A given methodology will have to include a way to determine o A given methodology will have to include a way to determine
whether a latency value is infinite or whether it is merely very whether a latency value is infinite or whether it is merely very
large. Simple upper bounds could be used. But the GMPLS network large. Simple upper bounds could be used. But GMPLS networks may
accommodates many kinds of devices. For example, some photonic accommodate many kinds of devices. For example, some photonic
cross-connects (PXCs) have to move the micro mirrors. This cross-connects (PXCs) have to move the micro mirrors. This
physical motion may take several milliseconds. But the common physical motion may take several milliseconds. But the common
electronic switches finish the nodal process within several electronic switches finish the nodal process within several
microseconds. So the bidirectional LSP setup delay varies microseconds. So the bidirectional LSP setup delay varies
drastically from a network to another. In the process of drastically from a network to another. In the process of
bidirectional LSP setup, if the downstream node overrides the bidirectional LSP setup, if the downstream node overrides the
label suggested by the upstream node, the setup delay will also label suggested by the upstream node, the setup delay will also
increase obviously. Thus, in practice, the upper bound should be increase obviously. Thus, in practice, the upper bound should be
chosen carefully. chosen carefully.
skipping to change at page 19, line 10 skipping to change at page 18, line 10
infinite. There are many possible reasons for this case. For infinite. There are many possible reasons for this case. For
example, one or more of the PATH messages have invalid parameters example, one or more of the PATH messages have invalid parameters
or the network has not enough resource to set up the requested or the network has not enough resource to set up the requested
LSPs. LSPs.
o The arrival rate of the poisson process lambda should be carefully o The arrival rate of the poisson process lambda should be carefully
chosen such that in the one hand the control plane is not chosen such that in the one hand the control plane is not
overburdened.On the other hand, the arrival rate should also be overburdened.On the other hand, the arrival rate should also be
large enough to meet the requirements of applications or services. large enough to meet the requirements of applications or services.
7.7. Methodologies 6.7. Methodologies
Generally the methodology would proceed as follows: Generally the methodology would proceed as follows:
o Make sure that the network has enough resource to set up the o Make sure that the network has enough resource to set up the
requested LSPs. requested LSPs.
o At the ingress node, form the PATH messages (including the o At the ingress node, form the PATH messages (including the
Upstream Label or suggested label) according to the LSPs' Upstream Label or suggested label) according to the LSPs'
requirements. requirements.
skipping to change at page 20, line 5 skipping to change at page 19, line 5
o If one or more of the corresponding RESV messages fails to arrive o If one or more of the corresponding RESV messages fails to arrive
within a reasonable period of time, the multiple bidirectional within a reasonable period of time, the multiple bidirectional
LSPs setup delay is deemed to be undefined (informally, infinite). LSPs setup delay is deemed to be undefined (informally, infinite).
Note that the 'reasonable' threshold is a parameter of the Note that the 'reasonable' threshold is a parameter of the
methodology. methodology.
o If one or more of the corresponding response messages is PathErr, o If one or more of the corresponding response messages is PathErr,
the multiple bidirectional LSPs setup delay is deemed to be the multiple bidirectional LSPs setup delay is deemed to be
undefined (informally, infinite). undefined (informally, infinite).
8. A Singleton Definition for LSP Graceful Release Delay 7. A Singleton Definition for LSP Graceful Release Delay
There are two different kinds of LSP release mechanisms in the GMPLS There are two different kinds of LSP release mechanisms in GMPLS
network: graceful release and forceful release. Memo in current networks: graceful release and forceful release. Memo in current
version has not taken forceful LSP release procedure into account. version has not taken forceful LSP release procedure into account.
8.1. Motivation 7.1. Motivation
LSP graceful release delay is useful for several reasons: LSP graceful release delay is useful for several reasons:
o The LSP graceful release delay is part of the total cost of o The LSP graceful release delay is part of the total cost of
dynamic LSP provisioning. For some short duration applications, dynamic LSP provisioning. For some short duration applications,
the LSP tear down time can not be ignored the LSP tear down time can not be ignored
o The LSP graceful release procedure is more prefered in a GMPLS o The LSP graceful release procedure is more prefered in a GMPLS
controled network, particularly the optical networks. Since it controled network, particularly the optical networks. Since it
doesn't trigger restoration/protection, it is "alarm-free doesn't trigger restoration/protection, it is "alarm-free
connection deletion" in [RFC4208]. connection deletion" in [RFC4208].
8.2. Metric Name 7.2. Metric Name
LSP graceful release delay LSP graceful release delay
8.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 o T, a time
8.4. Metric Units 7.4. Metric Units
The value of LSP graceful release delay is either a real number, or The value of LSP graceful release delay is either a real number, or
an undefined (informally, infinite) number of milliseconds. an undefined (informally, infinite) number of milliseconds.
8.5. Definition 7.5. Definition
There are two different LSP graceful release procedures, one is There are two different LSP graceful release procedures, one is
initiated by the ingress node, and another is initiated by egress initiated by the ingress node, and another is initiated by egress
node. The two procedures are depicted in the [RFC3473]. We define node. The two procedures are depicted in the [RFC3473]. We define
the graceful LSP release delay for these two procedures separately. the graceful LSP release delay for these two procedures separately.
For a real number dT, the LSP graceful release delay from ingress For a real number dT, the LSP graceful release delay from ingress
node to egress node at T is dT, means that ingress node sends the node to egress node at T is dT, means that ingress node sends the
first bit of a PATH message including Admin Status Object with first bit of a PATH message including Admin Status Object with
setting the Reflect (R) and Delete (D) bits to egress node at wire- setting the Reflect (R) and Delete (D) bits to egress node at wire-
skipping to change at page 21, line 37 skipping to change at page 20, line 37
last bit of PathTear packet at wire-time T+dT. last bit of PathTear packet at wire-time T+dT.
The LSP graceful release delay from egress node to ingress node at T The LSP graceful release delay from egress node to ingress node at T
is undefined (informally, infinite), means that egress node sends the is undefined (informally, infinite), means that egress node sends the
first bit of RESV message including Admin Status Object with setting first bit of RESV message including Admin Status Object with setting
the Reflect (R) and Delete (D) bits to ingress node at wire-time T the Reflect (R) and Delete (D) bits to ingress node at wire-time T
and that (either ingress node does not receive the RESV packet, and that (either ingress node does not receive the RESV packet,
ingress node does not send PathTear message packet in response or) ingress node does not send PathTear message packet in response or)
the egress does not receive the PathTear. the egress does not receive the PathTear.
8.6. Discussion 7.6. Discussion
The following issues are likely to come up in practice: The following issues are likely to come up in practice:
o In the first (second) circumstance, the accuracy of LSP graceful o In the first (second) circumstance, the accuracy of LSP graceful
release delay at time T depends on the clock resolution in the release delay at time T depends on the clock resolution in the
ingress (egress) node. In the first circumstance, synchronization ingress (egress) node. In the first circumstance, synchronization
between the ingress node and egress node is required; but not in between the ingress node and egress node is required; but not in
the second circumstance; the second circumstance;
o A given methodology has to include a way to determine whether a o A given methodology has to include a way to determine whether a
skipping to change at page 22, line 14 skipping to change at page 21, line 14
o In the first circumstance, if ingress node sends out PATH message o In the first circumstance, if ingress node sends out PATH message
including Admin Status Object with the Reflect (R) and Delete (D) including Admin Status Object with the Reflect (R) and Delete (D)
bits set to initiate LSP graceful release, but never receive bits set to initiate LSP graceful release, but never receive
corresponding RESV message, LSP graceful release delay is deemed corresponding RESV message, LSP graceful release delay is deemed
to be infinite. In the second circumstance, if egress node sends to be infinite. In the second circumstance, if egress node sends
out RESV message including Admin Status Object with the Reflect out RESV message including Admin Status Object with the Reflect
(R) and Delete (D) bits set to initiate LSP graceful release, but (R) and Delete (D) bits set to initiate LSP graceful release, but
never receive corresponding PathTear message, LSP graceful release never receive corresponding PathTear message, LSP graceful release
delay is deemed to be infinite; delay is deemed to be infinite;
8.7. Methodologies 7.7. Methodologies
In the first circumstance, the methodology may proceed as follows: In the first circumstance, the methodology may proceed as follows:
o Make sure the LSP to be deleted is set up; o Make sure the LSP to be deleted is set up;
o At the egress node, form the PATH message including Admin Status o At the egress node, form the PATH message including Admin Status
Object with the Reflect (R) and Delete (D) bits set. A timestamp Object with the Reflect (R) and Delete (D) bits set. A timestamp
(T1) may be stored locally in the ingress node when the PATH (T1) may be stored locally in the ingress node when the PATH
message packet is sent towards the egress node; message packet is sent towards the egress node;
skipping to change at page 24, line 5 skipping to change at page 23, line 5
may be stored locally in the egress node when the RESV message may be stored locally in the egress node when the RESV message
packet is sent towards the ingress node; packet is sent towards the ingress node;
o Upon receiving the Admin Status Object with the Reflect (R) and o Upon receiving the Admin Status Object with the Reflect (R) and
Delete (D) bits set in the RESV message, the ingress node sends a Delete (D) bits set in the RESV message, the ingress node sends a
PathTear message downstream to remove the LSP; PathTear message downstream to remove the LSP;
o Egress node takes a timestamp (T2) once it receives the last bit o Egress node takes a timestamp (T2) once it receives the last bit
of the PathTear message. The LSP graceful release delay is then of the PathTear message. The LSP graceful release delay is then
(T2-T1). (T2-T1).
9. Typical Testing cases of single Unidirectional LSP Setup Delay 8. Typical Testing Cases of Single Unidirectional LSP Setup Delay
Now we define typical test cases of getting unidirectional LSP setup Now we define typical test cases of getting unidirectional LSP setup
delay. delay.
9.1. With no LSP in the Network 8.1. With No LSP in the Network
9.1.1. Motivation 8.1.1. Motivation
Single unidirectional LSP setup delay with no LSP in the network is Single unidirectional LSP setup delay with no LSP in the network is
important because this reflects the inherent delay of an RSVP-TE important because this reflects the inherent delay of an RSVP-TE
implementation. The minimum value provides an indication of the implementation. The minimum value provides an indication of the
delay that will likely be experienced when an LSP traverses the delay that will likely be experienced when an LSP traverses the
shortest route with the lightest load in the control plane. shortest route with the lightest load in the control plane.
9.1.2. Methodologies 8.1.2. Methodologies
Make sure that there is no or very few LSPs in the network. The Make sure that there is no or very few LSPs in the network. The
methodology would proceed as follows: methodology would proceed as follows:
o Set up the LSP using the methodology for the singleton single o Set up the LSP using the methodology for the singleton single
unidirectional LSP setup delay, and obtain the value of unidirectional LSP setup delay, and obtain the value of
unidirectional LSP setup delay unidirectional LSP setup delay
o Release the LSP o Release the LSP
o Repeat this process if multiple samples are needed o Repeat this process if multiple samples are needed
Note that: in case multiple samples are to be obtained, the interval Note that: in case multiple samples are to be obtained, the interval
between each process should be large enough to guarantee the network between each process should be large enough to guarantee the network
has already reached a stable state. has already reached a stable state.
9.2. With a Number of LSPs in the Network 8.2. With a Number of LSPs in the Network
9.2.1. Motivation 8.2.1. Motivation
Single unidirectional LSP setup delay with a number of LSPs in the Single unidirectional LSP setup delay with a number of LSPs in the
network is important because it reflects the performance of an network is important because it reflects the performance of an
operational network with considrable load. This delay can vary operational network with considrable load. This delay can vary
significantly as the number of existing LSPs vary. It can be used as significantly as the number of existing LSPs vary. It can be used as
a scalability metric of an RSVP-TE implementation. a scalability metric of an RSVP-TE implementation.
9.2.2. Methodologies 8.2.2. Methodologies
Setup the required number of LSPs, and wait until the network reaches Setup the required number of LSPs, and wait until the network reaches
a stable state, then proceed as follows: a stable state, then proceed as follows:
o Set up the LSP using the methodology for the singleton single o Set up the LSP using the methodology for the singleton single
unidirectional LSP setup delay, and obtain the value of unidirectional LSP setup delay, and obtain the value of
unidirectional LSP setup delay unidirectional LSP setup delay
o Release the LSP o Release the LSP
o Repeat this process if multiple samples are needed o Repeat this process if multiple samples are needed
Note that: in case multiple samples are to be obtained, the interval Note that: in case multiple samples are to be obtained, the interval
between each process should be large enough to guarantee the network between each process should be large enough to guarantee the network
has already reached a stable state. has already reached a stable state.
10. Typical Testing cases of multiple Unidirectional LSPs Setup Delay 9. Typical Testing Cases of multiple Unidirectional LSPs Setup Delay
Now we define typical test cases of getting multiple unidirectional Now we define typical test cases of getting multiple unidirectional
LSPs setup delay. LSPs setup delay.
10.1. With no LSP in the Network 9.1. With No LSP in the Network
10.1.1. Motivation 9.1.1. Motivation
multiple unidirectional LSP setup delay with no LSP in the network is multiple unidirectional LSP setup delay with no LSP in the network is
important because this reflects the inherent delay of an RSVP-TE important because this reflects the inherent delay of an RSVP-TE
implementation. The minimum value provides an indication of the implementation. The minimum value provides an indication of the
delay that will likely be experienced when a number of LSPs are setup delay that will likely be experienced when a number of LSPs are setup
with the lightest load in the control plane. with the lightest load in the control plane.
10.1.2. Methodologies 9.1.2. Methodologies
Make sure that there is no or very few LSPs in the network. The Make sure that there is no or very few LSPs in the network. The
methodology would proceed as follows: methodology would proceed as follows:
o Set up the LSPs using the methodology for the singleton multiple o Set up the LSPs using the methodology for the singleton multiple
unidirectional LSP setup delay, and obtain the value of multiple unidirectional LSP setup delay, and obtain the value of multiple
unidirectional LSP setup delay unidirectional LSP setup delay
o Release the LSPs o Release the LSPs
o Repeat this process if multiple samples are needed o Repeat this process if multiple samples are needed
Note that: in case multiple samples are to be obtained, the interval Note that: in case multiple samples are to be obtained, the interval
between each process should be large enough to guarantee the network between each process should be large enough to guarantee the network
has already reached a stable state. has already reached a stable state.
10.2. With a Number of LSPs in the Network 9.2. With a Number of LSPs in the Network
10.2.1. Motivation 9.2.1. Motivation
multiple unidirectional LSP setup delay with a number of LSPs in the multiple unidirectional LSP setup delay with a number of LSPs in the
network is important because it reflects the performance of an network is important because it reflects the performance of an
operational network with considrable load. This delay can vary operational network with considrable load. This delay can vary
significantly as the number of existing LSPs vary. It can be used as significantly as the number of existing LSPs vary. It can be used as
a scalability metric of an RSVP-TE implementation. a scalability metric of an RSVP-TE implementation.
10.2.2. Methodologies 9.2.2. Methodologies
Setup the required number of LSPs, and wait until the network reaches Setup the required number of LSPs, and wait until the network reaches
a stable state, then proceed as follows: a stable state, then proceed as follows:
o Set up the LSPs using the methodology for the singleton multiple o Set up the LSPs using the methodology for the singleton multiple
unidirectional LSP setup delay, and obtain the value of multiple unidirectional LSP setup delay, and obtain the value of multiple
unidirectional LSP setup delay unidirectional LSP setup delay
o Release the LSPs o Release the LSPs
o Repeat this process if multiple samples are needed o Repeat this process if multiple samples are needed
Note that: in case multiple samples are to be obtained, the interval Note that: in case multiple samples are to be obtained, the interval
between each process should be large enough to guarantee the network between each process should be large enough to guarantee the network
has already reached a stable state. has already reached a stable state.
11. Typical Testing cases of single Bidirectional LSP Setup Delay 10. Typical Testing Cases of Single Bidirectional LSP Setup Delay
Now we define typical test cases of getting single bidirectional LSP Now we define typical test cases of getting single bidirectional LSP
setup delay. setup delay.
11.1. With no LSP in the Network 10.1. With No LSP in the Network
11.1.1. Motivation 10.1.1. Motivation
Single unidirectional LSP setup delay with no LSP in the network is Single unidirectional LSP setup delay with no LSP in the network is
important because this reflects the inherent delay of an RSVP-TE important because this reflects the inherent delay of an RSVP-TE
implementation. The minimum value provides an indication of the implementation. The minimum value provides an indication of the
delay that will likely be experienced when an LSP traverses the delay that will likely be experienced when an LSP traverses the
shortest route with the lightest load in the control plane. shortest route with the lightest load in the control plane.
11.1.2. Methodologies 10.1.2. Methodologies
Make sure that there is no or very few LSPs in the network. The Make sure that there is no or very few LSPs in the network. The
methodology would proceed as follows: methodology would proceed as follows:
o Set up the LSP using the methodology for the singleton o Set up the LSP using the methodology for the singleton
bidirectional LSP setup delay, and obtain the value of bidirectional LSP setup delay, and obtain the value of
unidirectional LSP setup delay unidirectional LSP setup delay
o Release the LSP o Release the LSP
o Repeat this process if multiple samples are needed o Repeat this process if multiple samples are needed
Note that: in case multiple samples are to be obtained, the interval Note that: in case multiple samples are to be obtained, the interval
between each process should be large enough to guarantee the network between each process should be large enough to guarantee the network
has already reached a stable state. has already reached a stable state.
11.2. With a Number of LSPs in the Network 10.2. With a Number of LSPs in the Network
11.2.1. Motivation 10.2.1. Motivation
Single bidirectional LSP setup delay with a number of LSPs in the Single bidirectional LSP setup delay with a number of LSPs in the
network is important because it reflects the performance of an network is important because it reflects the performance of an
operational network with considrable load. This delay can vary operational network with considrable load. This delay can vary
significantly as the number of existing LSPs vary. It can be used as significantly as the number of existing LSPs vary. It can be used as
a scalability metric of an RSVP-TE implementation. a scalability metric of an RSVP-TE implementation.
11.2.2. Methodologies 10.2.2. Methodologies
Setup the required number of LSPs, and wait until the network reaches Setup the required number of LSPs, and wait until the network reaches
a stable state, then proceed as follows: a stable state, then proceed as follows:
o Set up the LSP using the methodology for the singleton o Set up the LSP using the methodology for the singleton
bidirectional bidirectional LSP setup delay, and obtain the value bidirectional bidirectional LSP setup delay, and obtain the value
of bidirectional LSP setup delay of bidirectional LSP setup delay
o Release the LSP o Release the LSP
o Repeat this process if multiple samples are needed o Repeat this process if multiple samples are needed
Note that: in case multiple samples are to be obtained, the interval Note that: in case multiple samples are to be obtained, the interval
between each process should be large enough to guarantee the network between each process should be large enough to guarantee the network
has already reached a stable state. has already reached a stable state.
12. Typical Testing cases of multiple Bidirectional LSPs Setup Delay 11. Typical Testing Cases of multiple Bidirectional LSPs Setup Delay
Now we define typical test cases of getting multiple bidirectional Now we define typical test cases of getting multiple bidirectional
LSPs setup delay. LSPs setup delay.
12.1. With no LSP in the Network 11.1. With No LSP in the Network
12.1.1. Motivation 11.1.1. Motivation
multiple bidirectional LSP setup delay with no LSP in the network is multiple bidirectional LSP setup delay with no LSP in the network is
important because this reflects the inherent delay of an RSVP-TE important because this reflects the inherent delay of an RSVP-TE
implementation. The minimum value provides an indication of the implementation. The minimum value provides an indication of the
delay that will likely be experienced when a number of LSPs are setup delay that will likely be experienced when a number of LSPs are setup
with the lightest load in the control plane. with the lightest load in the control plane.
12.1.2. Methodologies 11.1.2. Methodologies
Make sure that there is no or very few LSPs in the network. The Make sure that there is no or very few LSPs in the network. The
methodology would proceed as follows: methodology would proceed as follows:
o Set up the LSPs using the methodology for the singleton multiple o Set up the LSPs using the methodology for the singleton multiple
multiple bidirectional LSP setup delay, and obtain the value of multiple bidirectional LSP setup delay, and obtain the value of
multiple bidirectional LSP setup delay multiple bidirectional LSP setup delay
o Release the LSPs o Release the LSPs
o Repeat this process if multiple samples are needed o Repeat this process if multiple samples are needed
Note that: in case multiple samples are to be obtained, the interval Note that: in case multiple samples are to be obtained, the interval
between each process should be large enough to guarantee the network between each process should be large enough to guarantee the network
has already reached a stable state. has already reached a stable state.
12.2. With a Number of LSPs in the Network 11.2. With a Number of LSPs in the Network
12.2.1. Motivation 11.2.1. Motivation
multiple bidirectional LSPs setup delay with a number of LSPs in the multiple bidirectional LSPs setup delay with a number of LSPs in the
network is important because it reflects the performance of an network is important because it reflects the performance of an
operational network with considrable load. This delay can vary operational network with considrable load. This delay can vary
significantly as the number of existing LSPs vary. It can be used as significantly as the number of existing LSPs vary. It can be used as
a scalability metric of an RSVP-TE implementation. a scalability metric of an RSVP-TE implementation.
12.2.2. Methodologies 11.2.2. Methodologies
Setup the required number of LSPs, and wait until the network reaches Setup the required number of LSPs, and wait until the network reaches
a stable state, then proceed as follows: a stable state, then proceed as follows:
o Set up the LSPs using the methodology for the singleton multiple o Set up the LSPs using the methodology for the singleton multiple
bidirectional LSPs setup delay, and obtain the value of multiple bidirectional LSPs setup delay, and obtain the value of multiple
bidirectional LSPs setup delay bidirectional LSPs setup delay
o Release the LSPs o Release the LSPs
o Repeat this process if multiple samples are needed o Repeat this process if multiple samples are needed
Note that: in case multiple samples are to be obtained, the interval Note that: in case multiple samples are to be obtained, the interval
between each process should be large enough to guarantee the network between each process should be large enough to guarantee the network
has already reached a stable state. has already reached a stable state.
13. Some Statistics Definitions for Metrics to Report 12. Some Statistics Definitions for Metrics to Report
Given the samples of the performance metric, we now offer several Given the samples of the performance metric, we now offer several
statistics of these samples to report. From these statistics, we can statistics of these samples to report. From these statistics, we can
draw some useful conclusions of a GMPLS network. The value of these draw some useful conclusions of a GMPLS network. The value of these
metrics is either a real number, or an undefined (informally, metrics is either a real number, or an undefined (informally,
infinite) number of milliseconds. In the following discussion, we infinite) number of milliseconds. In the following discussion, we
only consider the finite values. only consider the finite values.
13.1. The Minimum of Metric 12.1. The Minimum of Metric
The minimum of metric is the minimum of all the dT values in the The minimum of metric is the minimum of all the dT values in the
sample. In computing this, undefined values are treated as sample. In computing this, undefined values are treated as
infinitely large. Note that this means that the minimum could thus infinitely large. Note that this means that the minimum could thus
be undefined (informally, infinite) if all the dT values are be undefined (informally, infinite) if all the dT values are
undefined. In addition, the metric minimum is undefined if the undefined. In addition, the metric minimum is undefined if the
sample is empty. sample is empty.
13.2. The Median of Metric 12.2. The Median of Metric
Metric median is the median of the dT values in the given sample. In Metric median is the median of the dT values in the given sample. In
computing the median, the undefined values are not counted in. computing the median, the undefined values are not counted in.
13.3. The percentile of Metric 12.3. The percentile of Metric
Given a metric and a percent X between 0% and 100%, the Xth Given a metric and a percent X between 0% and 100%, the Xth
percentile of all the dT values in the sample. In addition, the percentile of all the dT values in the sample. In addition, the
unidirectional LSP setup delay percentile is undefined if the sample unidirectional LSP setup delay percentile is undefined if the sample
is empty. is empty.
Example: suppose we take a sample and the results are: Stream1 = < Example: suppose we take a sample and the results are: Stream1 = <
<T1, 100 msec>, <T2, 110 msec>, <T3, undefined>, <T4, 90 msec>, <T5, <T1, 100 msec>, <T2, 110 msec>, <T3, undefined>, <T4, 90 msec>, <T5,
500 msec> > 500 msec> >
Then the 50th percentile would be 110 msec, since 90 msec and 100 Then the 50th percentile would be 110 msec, since 90 msec and 100
msec are smaller, and 110 and 500 msec are larger (undefined values msec are smaller, and 110 and 500 msec are larger (undefined values
are not counted in). are not counted in).
13.4. The failure probability 12.4. The Failure Probability
In the process of LSP setup/release, it may fail for some reason. In the process of LSP setup/release, it may fail for some reason.
The failure probability is the ratio of the failure times to the The failure probability is the ratio of the failure times to the
total times. total times.
14. Discussion 13. Discussion
It is worthwhile to point out that: It is worthwhile to point out that:
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 the draft, egress round trip time plus processing time. But in this
unidirectional/bidirectional LSP setup delay has not taken the document, unidirectional/bidirectional LSP setup delay has not
processing time in the end nodes (ingress or/and egress) into taken the processing time in the end nodes (ingress or/and egress)
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 All these metrics are defined from the point of control plane's
view. In fact, the control plane and data plane are not always view. In fact, the control plane and data plane are not always
synchronized. In some cases, the LSPs have been set up in the synchronized. In some cases, the LSPs have been set up in the
control plane. But the data can not be forwarded immediately. control plane. But data can not be forwarded immediately. The
The unidirectional/bidirectional LSP setup delay in the data plane unidirectional/bidirectional LSP setup delay in the data plane is
is longer than in the control plane. longer than in the control plane.
15. Security Considerations 14. Security Considerations
The security considerations pertaining to the original RSVP protocol Samples of the metrics can be obtained in either active or passive
[RFC2205] and its TE extensions [RFC3209] remain relevant. manners.
In the active manner, ingress nodes inject probing messages into the
control plane. The measurement parameters must be carefully selected
so that the measurements inject trivial amounts of additional traffic
into the networks they measure. If they inject "too much" traffic,
they can skew the results of the measurement, and in extreme cases
cause congestion and denial of service.
When samples of the metrics are collected in a passive manner, e.g.,
by monitoring the operations on real-life LSPs, the implementation of
the monitoring and reporting mechanism must be careful so that they
will not be used to attack the control plane.
Besides, the security considerations pertaining to the original RSVP
protocol [RFC2205] and its TE extensions [RFC3209] also remain
relevant.
15. IANA Considerations
This document makes no requests for IANA action.
16. Acknowledgements 16. Acknowledgements
We wish to thank Dan Li, Fang Liu (Christine), Zafar Ali, Monique We wish to thank Dan Li, Fang Liu (Christine), Zafar Ali, Monique
Morrow, Al Morton, Adrian Farrel, Deborah Brungard, Thomas D. Nadeau Morrow, Al Morton, Adrian Farrel, Deborah Brungard, Thomas D. Nadeau
for their comments and helps. for their 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.
17. Normative References 17. References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 17.1. Normative References
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2205] Braden, B., Zhang, L., Berson, S., Herzog, S., and S. [RFC2205] Braden, B., Zhang, L., Berson, S., Herzog, S., and S.
Jamin, "Resource ReSerVation Protocol (RSVP) -- Version 1 Jamin, "Resource ReSerVation Protocol (RSVP) -- Version 1
Functional Specification", RFC 2205, September 1997. Functional Specification", RFC 2205, September 1997.
[RFC2330] Paxson, V., Almes, G., Mahdavi, J., and M. Mathis,
"Framework for IP Performance Metrics", RFC 2330,
May 1998.
[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.
skipping to change at page 37, line 5 skipping to change at page 36, line 40
[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-
Traffic Engineering (RSVP-TE) Support for the Overlay Traffic Engineering (RSVP-TE) Support for the Overlay
Model", RFC 4208, October 2005. Model", RFC 4208, October 2005.
[RFC4802] Nadeau, T. and A. Farrel, "Generalized Multiprotocol Label [RFC4802] Nadeau, T. and A. Farrel, "Generalized Multiprotocol Label
Switching (GMPLS) Traffic Engineering Management Switching (GMPLS) Traffic Engineering Management
Information Base", RFC 4802, February 2007. Information Base", RFC 4802, February 2007.
17.2. Informative References
[RFC2330] Paxson, V., Almes, G., Mahdavi, J., and M. Mathis,
"Framework for IP Performance Metrics", RFC 2330,
May 1998.
Authors' Addresses Authors' Addresses
Weiqiang Sun Weiqiang Sun
Shanghai Jiao Tong University Shanghai Jiao Tong University
800 Dongchuan Road 800 Dongchuan Road
Shanghai 200240 Shanghai 200240
CN CN
Phone: +86 21 3420 5359 Phone: +86 21 3420 5359
Email: sunwq@sjtu.edu.cn Email: sunwq@sjtu.edu.cn
 End of changes. 106 change blocks. 
236 lines changed or deleted 253 lines changed or added

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