draft-ietf-ccamp-lsp-dppm-01.txt   draft-ietf-ccamp-lsp-dppm-02.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: October 12, 2008 CATR Expires: December 26, 2008 CATR
J. Gao J. Gao
Huawei Huawei
G. Xie G. Xie
SJTU SJTU
April 10, 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-01.txt draft-ietf-ccamp-lsp-dppm-02.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 41 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 October 12, 2008. This Internet-Draft will expire on December 16, 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 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 3, line 7 skipping to change at page 4, line 7
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 Dynamic LSP setup/release performance. These specifically the Dynamic LSP setup/release performance. These
metrics can depict the features of GMPLS networks 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 . . . . . . . . . . . . . . . . . . . . . . . . . 7
2. Overview of Performance Metrics . . . . . . . . . . . . . . . 6 2. Overview of Performance Metrics . . . . . . . . . . . . . . . 8
3. A Singleton Definition for Single Unidirectional LSP Setup 3. A Singleton Definition for Single Unidirectional LSP Setup
Delay . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7 Delay . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
3.1. Motivation . . . . . . . . . . . . . . . . . . . . . . . . 7 3.1. Motivation . . . . . . . . . . . . . . . . . . . . . . . . 9
3.2. Metric Name . . . . . . . . . . . . . . . . . . . . . . . 7 3.2. Metric Name . . . . . . . . . . . . . . . . . . . . . . . 9
3.3. Metric Parameters . . . . . . . . . . . . . . . . . . . . 7 3.3. Metric Parameters . . . . . . . . . . . . . . . . . . . . 9
3.4. Metric Units . . . . . . . . . . . . . . . . . . . . . . . 8 3.4. Metric Units . . . . . . . . . . . . . . . . . . . . . . . 10
3.5. Definition . . . . . . . . . . . . . . . . . . . . . . . . 8 3.5. Definition . . . . . . . . . . . . . . . . . . . . . . . . 10
3.6. Discussion . . . . . . . . . . . . . . . . . . . . . . . . 8 3.6. Discussion . . . . . . . . . . . . . . . . . . . . . . . . 10
3.7. Methodologies . . . . . . . . . . . . . . . . . . . . . . 9 3.7. Methodologies . . . . . . . . . . . . . . . . . . . . . . 11
4. A Singleton Definition for multiple Unidirectional LSP 4. A Singleton Definition for multiple Unidirectional LSP
Setup Delay . . . . . . . . . . . . . . . . . . . . . . . . . 10 Setup Delay . . . . . . . . . . . . . . . . . . . . . . . . . 12
4.1. Motivation . . . . . . . . . . . . . . . . . . . . . . . . 10 4.1. Motivation . . . . . . . . . . . . . . . . . . . . . . . . 12
4.2. Metric Name . . . . . . . . . . . . . . . . . . . . . . . 10 4.2. Metric Name . . . . . . . . . . . . . . . . . . . . . . . 12
4.3. Metric Parameters . . . . . . . . . . . . . . . . . . . . 10 4.3. Metric Parameters . . . . . . . . . . . . . . . . . . . . 12
4.4. Metric Units . . . . . . . . . . . . . . . . . . . . . . . 10 4.4. Metric Units . . . . . . . . . . . . . . . . . . . . . . . 12
4.5. Definition . . . . . . . . . . . . . . . . . . . . . . . . 10 4.5. Definition . . . . . . . . . . . . . . . . . . . . . . . . 12
4.6. Discussion . . . . . . . . . . . . . . . . . . . . . . . . 11 4.6. Discussion . . . . . . . . . . . . . . . . . . . . . . . . 13
4.7. Methodologies . . . . . . . . . . . . . . . . . . . . . . 12 4.7. Methodologies . . . . . . . . . . . . . . . . . . . . . . 14
5. A Singleton Definition for Single Bidirectional LSP Setup 5. A Singleton Definition for Single Bidirectional LSP Setup
Delay . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13 Delay . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
5.1. Motivation . . . . . . . . . . . . . . . . . . . . . . . . 13 5.1. Motivation . . . . . . . . . . . . . . . . . . . . . . . . 15
5.2. Metric Name . . . . . . . . . . . . . . . . . . . . . . . 13 5.2. Metric Name . . . . . . . . . . . . . . . . . . . . . . . 15
5.3. Metric Parameters . . . . . . . . . . . . . . . . . . . . 13 5.3. Metric Parameters . . . . . . . . . . . . . . . . . . . . 15
5.4. Metric Units . . . . . . . . . . . . . . . . . . . . . . . 14 5.4. Metric Units . . . . . . . . . . . . . . . . . . . . . . . 16
5.5. Definition . . . . . . . . . . . . . . . . . . . . . . . . 14 5.5. Definition . . . . . . . . . . . . . . . . . . . . . . . . 16
5.6. Discussion . . . . . . . . . . . . . . . . . . . . . . . . 14 5.6. Discussion . . . . . . . . . . . . . . . . . . . . . . . . 16
5.7. Methodologies . . . . . . . . . . . . . . . . . . . . . . 15 5.7. Methodologies . . . . . . . . . . . . . . . . . . . . . . 17
6. A Singleton Definition for multiple Bidirectional LSPs 6. A Singleton Definition for multiple Bidirectional LSPs
Setup Delay . . . . . . . . . . . . . . . . . . . . . . . . . 16 Setup Delay . . . . . . . . . . . . . . . . . . . . . . . . . 18
6.1. Motivation . . . . . . . . . . . . . . . . . . . . . . . . 16 6.1. Motivation . . . . . . . . . . . . . . . . . . . . . . . . 18
6.2. Metric Name . . . . . . . . . . . . . . . . . . . . . . . 16 6.2. Metric Name . . . . . . . . . . . . . . . . . . . . . . . 18
6.3. Metric Parameters . . . . . . . . . . . . . . . . . . . . 16 6.3. Metric Parameters . . . . . . . . . . . . . . . . . . . . 18
6.4. Metric Units . . . . . . . . . . . . . . . . . . . . . . . 16 6.4. Metric Units . . . . . . . . . . . . . . . . . . . . . . . 18
6.5. Definition . . . . . . . . . . . . . . . . . . . . . . . . 16 6.5. Definition . . . . . . . . . . . . . . . . . . . . . . . . 18
6.6. Discussion . . . . . . . . . . . . . . . . . . . . . . . . 17 6.6. Discussion . . . . . . . . . . . . . . . . . . . . . . . . 19
6.7. Methodologies . . . . . . . . . . . . . . . . . . . . . . 18 6.7. Methodologies . . . . . . . . . . . . . . . . . . . . . . 20
7. A Singleton Definition for LSP Graceful Release Delay . . . . 19 7. A Singleton Definition for LSP Graceful Release Delay . . . . 21
7.1. Motivation . . . . . . . . . . . . . . . . . . . . . . . . 19 7.1. Motivation . . . . . . . . . . . . . . . . . . . . . . . . 21
7.2. Metric Name . . . . . . . . . . . . . . . . . . . . . . . 19 7.2. Metric Name . . . . . . . . . . . . . . . . . . . . . . . 21
7.3. Metric Parameters . . . . . . . . . . . . . . . . . . . . 19 7.3. Metric Parameters . . . . . . . . . . . . . . . . . . . . 21
7.4. Metric Units . . . . . . . . . . . . . . . . . . . . . . . 19 7.4. Metric Units . . . . . . . . . . . . . . . . . . . . . . . 21
7.5. Definition . . . . . . . . . . . . . . . . . . . . . . . . 19 7.5. Definition . . . . . . . . . . . . . . . . . . . . . . . . 21
7.6. Discussion . . . . . . . . . . . . . . . . . . . . . . . . 20 7.6. Discussion . . . . . . . . . . . . . . . . . . . . . . . . 22
7.7. Methodologies . . . . . . . . . . . . . . . . . . . . . . 21 7.7. Methodologies . . . . . . . . . . . . . . . . . . . . . . 23
8. Typical Testing Cases of Single Unidirectional LSP Setup 8. A Definition for Samples of Single Unidirectional LSP
Delay . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23
8.1. With No LSP in the Network . . . . . . . . . . . . . . . . 23
8.1.1. Motivation . . . . . . . . . . . . . . . . . . . . . . 23
8.1.2. Methodologies . . . . . . . . . . . . . . . . . . . . 23
8.2. With a Number of LSPs in the Network . . . . . . . . . . . 23
8.2.1. Motivation . . . . . . . . . . . . . . . . . . . . . . 23
8.2.2. Methodologies . . . . . . . . . . . . . . . . . . . . 23
9. Typical Testing Cases of multiple Unidirectional LSPs
Setup Delay . . . . . . . . . . . . . . . . . . . . . . . . . 25 Setup Delay . . . . . . . . . . . . . . . . . . . . . . . . . 25
9.1. With No LSP in the Network . . . . . . . . . . . . . . . . 25 8.1. Metric Name . . . . . . . . . . . . . . . . . . . . . . . 25
9.1.1. Motivation . . . . . . . . . . . . . . . . . . . . . . 25 8.2. Metric Parameters . . . . . . . . . . . . . . . . . . . . 25
9.1.2. Methodologies . . . . . . . . . . . . . . . . . . . . 25 8.3. Metric Units . . . . . . . . . . . . . . . . . . . . . . . 25
9.2. With a Number of LSPs in the Network . . . . . . . . . . . 25 8.4. Definition . . . . . . . . . . . . . . . . . . . . . . . . 25
9.2.1. Motivation . . . . . . . . . . . . . . . . . . . . . . 25 8.5. Discussion . . . . . . . . . . . . . . . . . . . . . . . . 26
9.2.2. Methodologies . . . . . . . . . . . . . . . . . . . . 25 8.6. Methodologies . . . . . . . . . . . . . . . . . . . . . . 26
10. Typical Testing Cases of Single Bidirectional LSP Setup 8.7. Typical testing cases . . . . . . . . . . . . . . . . . . 26
Delay . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27 8.7.1. With No LSP in the Network . . . . . . . . . . . . . . 27
10.1. With No LSP in the Network . . . . . . . . . . . . . . . . 27 8.7.2. With a Number of LSPs in the Network . . . . . . . . . 27
10.1.1. Motivation . . . . . . . . . . . . . . . . . . . . . . 27 9. A Definition for Samples of Multiple Unidirectional LSPs
10.1.2. Methodologies . . . . . . . . . . . . . . . . . . . . 27 Setup Delay . . . . . . . . . . . . . . . . . . . . . . . . . 28
10.2. With a Number of LSPs in the Network . . . . . . . . . . . 27 9.1. Metric Name . . . . . . . . . . . . . . . . . . . . . . . 28
10.2.1. Motivation . . . . . . . . . . . . . . . . . . . . . . 27 9.2. Metric Parameters . . . . . . . . . . . . . . . . . . . . 28
10.2.2. Methodologies . . . . . . . . . . . . . . . . . . . . 27 9.3. Metric Units . . . . . . . . . . . . . . . . . . . . . . . 28
11. Typical Testing Cases of multiple Bidirectional LSPs Setup 9.4. Definition . . . . . . . . . . . . . . . . . . . . . . . . 28
Delay . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29 9.5. Discussion . . . . . . . . . . . . . . . . . . . . . . . . 29
11.1. With No LSP in the Network . . . . . . . . . . . . . . . . 29 9.6. Methodologies . . . . . . . . . . . . . . . . . . . . . . 29
11.1.1. Motivation . . . . . . . . . . . . . . . . . . . . . . 29 9.7. Typical testing cases . . . . . . . . . . . . . . . . . . 29
11.1.2. Methodologies . . . . . . . . . . . . . . . . . . . . 29 9.7.1. With No LSP in the Network . . . . . . . . . . . . . . 29
11.2. With a Number of LSPs in the Network . . . . . . . . . . . 29 9.7.2. With a Number of LSPs in the Network . . . . . . . . . 30
11.2.1. Motivation . . . . . . . . . . . . . . . . . . . . . . 29 10. A Definition for Samples of Single Bidirectional LSP Setup
11.2.2. Methodologies . . . . . . . . . . . . . . . . . . . . 29 Delay . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31
12. Some Statistics Definitions for Metrics to Report . . . . . . 31 10.1. Metric Name . . . . . . . . . . . . . . . . . . . . . . . 31
12.1. The Minimum of Metric . . . . . . . . . . . . . . . . . . 31 10.2. Metric Parameters . . . . . . . . . . . . . . . . . . . . 31
12.2. The Median of Metric . . . . . . . . . . . . . . . . . . . 31 10.3. Metric Units . . . . . . . . . . . . . . . . . . . . . . . 31
12.3. The percentile of Metric . . . . . . . . . . . . . . . . . 31 10.4. Definition . . . . . . . . . . . . . . . . . . . . . . . . 31
12.4. The Failure Probability . . . . . . . . . . . . . . . . . 31 10.5. Discussion . . . . . . . . . . . . . . . . . . . . . . . . 32
13. Discussion . . . . . . . . . . . . . . . . . . . . . . . . . . 32 10.6. Methodologies . . . . . . . . . . . . . . . . . . . . . . 32
14. Security Considerations . . . . . . . . . . . . . . . . . . . 33 10.7. Typical testing cases . . . . . . . . . . . . . . . . . . 32
15. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 34 10.7.1. With No LSP in the Network . . . . . . . . . . . . . . 33
16. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 35 10.7.2. With a Number of LSPs in the Network . . . . . . . . . 33
17. References . . . . . . . . . . . . . . . . . . . . . . . . . . 36 11. A Definition for Samples of Multiple Bidirectional LSPs
17.1. Normative References . . . . . . . . . . . . . . . . . . . 36 Setup Delay . . . . . . . . . . . . . . . . . . . . . . . . . 34
17.2. Informative References . . . . . . . . . . . . . . . . . . 36 11.1. Metric Name . . . . . . . . . . . . . . . . . . . . . . . 34
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 37 11.2. Metric Parameters . . . . . . . . . . . . . . . . . . . . 34
Intellectual Property and Copyright Statements . . . . . . . . . . 39 11.3. Metric Units . . . . . . . . . . . . . . . . . . . . . . . 34
11.4. Definition . . . . . . . . . . . . . . . . . . . . . . . . 34
11.5. Discussion . . . . . . . . . . . . . . . . . . . . . . . . 35
11.6. Methodologies . . . . . . . . . . . . . . . . . . . . . . 35
11.7. Typical testing cases . . . . . . . . . . . . . . . . . . 35
11.7.1. With No LSP in the Network . . . . . . . . . . . . . . 35
11.7.2. With a Number of LSPs in the Network . . . . . . . . . 36
12. A Definition for Samples of LSP Graceful Release Delay . . . . 37
12.1. Metric Name . . . . . . . . . . . . . . . . . . . . . . . 37
12.2. Metric Parameters . . . . . . . . . . . . . . . . . . . . 37
12.3. Metric Units . . . . . . . . . . . . . . . . . . . . . . . 37
12.4. Definition . . . . . . . . . . . . . . . . . . . . . . . . 37
12.5. Discussion . . . . . . . . . . . . . . . . . . . . . . . . 37
12.6. Methodologies . . . . . . . . . . . . . . . . . . . . . . 38
13. Discussion for unsuccessful setup/release cases . . . . . . . 39
14. Some Statistics Definitions for Metrics to Report . . . . . . 40
14.1. The Minimum of Metric . . . . . . . . . . . . . . . . . . 40
14.2. The Median of Metric . . . . . . . . . . . . . . . . . . . 40
14.3. The percentile of Metric . . . . . . . . . . . . . . . . . 40
14.4. The Failure Probability . . . . . . . . . . . . . . . . . 40
15. Discussion . . . . . . . . . . . . . . . . . . . . . . . . . . 41
16. Security Considerations . . . . . . . . . . . . . . . . . . . 42
17. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 43
18. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 44
19. References . . . . . . . . . . . . . . . . . . . . . . . . . . 45
19.1. Normative References . . . . . . . . . . . . . . . . . . . 45
19.2. Informative References . . . . . . . . . . . . . . . . . . 45
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 46
Intellectual Property and Copyright Statements . . . . . . . . . . 48
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 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 5, line 27 skipping to change at page 7, line 27
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 defines performance metrics and methodologies that can be This draft defines performance metrics and methodologies that can be
used to depict the dynamic connection provisioning performance of used to depict the dynamic LSP provisioning performance of GMPLS
GMPLS networks. The metrics defined in this document can in the one networks, more specifically, performance of the signaling protocol.
hand be used to depict the averaged performance of GMPLS The metrics defined in this document can in the one hand be used to
implementations. On the other hand, it can also be used in depict the averaged performance of GMPLS implementations. On the
operational environments for carriers to monitor the control plane other hand, it can also be used in operational environments for
operation in realtime. For example, extensions can be made to GMPLS carriers to monitor the control plane operation in realtime. For
TE STD MIB [RFC4802] such that the current and past control plane example, an new object can be added to GMPLS TE STD MIB [RFC4802]
performance can be monitored through network management systems. The such that the current and past control plane performance can be
extension of TE-MIB to support the metrics defined is out the scope monitored through network management systems. The extension of TE-
of this document. MIB to support the metrics defined is out the scope of this document.
2. Overview of Performance Metrics 2. Overview of Performance Metrics
In this document, to depict the dynamic LSP provisioning performance In this memo, to depict the dynamic LSP provisioning performance of a
of a GMPLS network, we define 5 performance metrics: single/multiple GMPLS network, we define 3 performance metrics: unidirectional LSP
unidirectional LSP(s) setup delay, single/multiple bidirectional setup delay, bidirectional LSP setup delay, and LSP graceful release
LSP(s) setup delay, and LSP graceful release delay. The latency of delay. The latency of the LSP setup/release signal is similar to the
the LSP setup/release signal is similar to the Round-trip Delay in IP Round-trip Delay in IP networks. So we refer the structures and
networks. So we refer the structures and notions introduced and notions introduced and discussed in the IPPM Framework document,
discussed in the IPPM Framework document, [RFC2330] [RFC2679] [RFC2330] [RFC2679] [RFC2681]. The reader is assumed to be familiar
[RFC2681]. The reader is assumed to be familiar with the notions in with the notions in those documents.
those documents.
We further define typical testing cases to obtain samples of the
defined metrics, namely, when there is no LSP in the network, or
there are a fixed number of LSPs in the network.
3. 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.
3.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:
skipping to change at page 8, line 4 skipping to change at page 10, line 4
3.2. Metric Name 3.2. Metric Name
single unidirectional LSP setup delay single unidirectional LSP setup delay
3.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 when the setup is attempted
3.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 number of milliseconds.
milliseconds.
3.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 ID0
the egress node [RFC3945] at T is dT means that ingress node sends to the egress node ID1 [RFC3945] at T is dT means that ingress node
the first bit of a PATH message packet to egress node at wire-time T, ID0 sends the first bit of a PATH message packet to egress node ID1
and that the ingress node received the last bit of responding RESV at wire-time T, and that the ingress node ID0 received the last bit
message packet from egress node at wire-time T+dT in the of responding RESV message packet from the egress node ID1 at wire-
unidirectional LSP setup case. time T+dT in the 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 ID0
the egress node at T is undefined (informally, infinite), means that to the egress node ID1 at T is undefined, means that ingress node ID0
ingress node sends the first bit of PATH message packet to egress sends the first bit of PATH message packet to egress node ID1 at
node at wire-time T and that ingress node does not receive the wire-time T and that ingress node ID0 does not receive the
corresponding RESV message within a reasonable period of time. corresponding RESV message within a reasonable period of time.
3.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 GMPLS networks may large. Simple upper bounds could be used. But GMPLS networks may
accommodate 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 chosen carefully. bound should be chose 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 undefined.
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 undefined. 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.
3.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.
skipping to change at page 9, line 31 skipping to change at page 11, line 28
egress node. egress node.
o If the corresponding RESV message arrives within a reasonable o If the corresponding RESV message arrives within a reasonable
period of time, take the timestamp (T2) as soon as possible upon period of time, take the timestamp (T2) as soon as possible upon
receipt of the message. By subtracting the two timestamps, an receipt of the message. By subtracting the two timestamps, an
estimate of unidirectional LSP setup delay (T2 -T1) can be estimate of unidirectional LSP setup delay (T2 -T1) can be
computed. computed.
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. Note that the 'reasonable' threshold 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).
4. 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.
4.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:
skipping to change at page 10, line 32 skipping to change at page 12, line 32
4.2. Metric Name 4.2. Metric Name
multiple unidirectional LSPs setup delay multiple unidirectional LSPs setup delay
4.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_m, 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 when the first setup is attempted
4.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 number of milliseconds.
milliseconds.
4.5. Definition 4.5. Definition
Given lambda and X, the multiple unidirectional LSPs setup delay from Given Lambda_m and X, the multiple unidirectional LSPs setup delay
the ingress node to the egress node [RFC3945] at T is dT means: from 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 ID0 sends the first bit of the first PATH message
to egress node at wire-time T packet to egress node ID1 at wire-time T
o all subsequent (X-1) PATH messages are sent according to the
specified poisson process with arrival rate lambda
o ingress node receives all corresponding RESV message packets from o all subsequent (X-1) PATH messages are sent according to the
egress node, and specified poisson process with arrival rate Lambda_m
o ingress node ID0 receives all corresponding RESV message packets
from egress node ID1, and
o ingress node receives the last RESV message packet at wire-time o ingress node ID0 receives the last RESV message packet at wire-
T+dT time T+dT
The multiple unidirectional LSPs setup delay at T is undefined The multiple unidirectional LSPs setup delay at T is undefined, means
(informally, infinite), means that ingress node sends all the PATH that ingress node ID0 sends all the PATH messages toward the egress
messages toward the egress and the first bit of the first PATH node ID1 and the first bit of the first PATH message packet is sent
message packet is sent at wire-time T and that ingress node does not at wire-time T and that ingress node ID0 does not receive the one or
receive the one or more of the corresponding RESV messages within a more of the corresponding RESV messages within a reasonable period of
reasonable period of time. time.
4.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 GMPLS networks may large. Simple upper bounds could be used. But GMPLS networks may
accommodate 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 chosen carefully. upper bound should be chose 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, multiple unidirectional LSP setup delay is deemed to be
infinite. undefined.
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 undefined. 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 messages 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_m should be
chosen such that in the one hand the control plane is not carefully chosen such that in the one hand the control plane is
overburdened.On the other hand, the arrival rate should also be not overburdened.On the other hand, the arrival rate should also
large enough to meet the requirements of applications or services. be large enough to meet the requirements of applications or
services.
4.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.
skipping to change at page 12, line 37 skipping to change at page 14, line 34
PATH message packet is sent towards the egress node. PATH message packet is sent towards the egress node.
o If all of the corresponding RESV messages arrives within a o If all of the corresponding RESV messages arrives within a
reasonable period of time, take the final timestamp (T2) as soon reasonable period of time, take the final timestamp (T2) as soon
as possible upon the receipt of all the messages. By subtracting as possible upon the receipt of all the messages. By subtracting
the two timestamps, an estimate of multiple unidirectional LSPs the two timestamps, an estimate of multiple unidirectional LSPs
setup delay (T2 -T1) can be computed. setup delay (T2 -T1) can be computed.
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. Note that the
Note that the 'reasonable' threshold is a parameter of 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
(informally, infinite). undefined.
5. 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.
5.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
skipping to change at page 14, line 8 skipping to change at page 16, line 8
5.2. Metric Name 5.2. Metric Name
Single bidirectional LSP setup delay Single bidirectional LSP setup delay
5.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 when the setup is attempted
5.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 number of milliseconds.
milliseconds.
5.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 ID0 to egress node ID1 at T is dT, means that ingress
out the first bit of a PATH message including an Upstream Label node ID0 sends out the first bit of a PATH message including an
[RFC3473] heading for egress node at wire-time T, egress node Upstream Label [RFC3473] heading for egress node ID1 at wire-time T,
receives that packet, then immediately sends a RESV message packet egress node ID1 receives that packet, then immediately sends a RESV
back to ingress node, and that ingress node receives the last bit of message packet back to ingress node ID0, and that ingress node ID0
that packet at wire-time T+dT. receives the last bit of 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 ID0 to
node at T is undefined (informally, infinite), means that ingress egress node ID1 at T is undefined, means that ingress node ID0 sends
node sends the first bit of PATH message to egress node at wire-time the first bit of PATH message to egress node ID1 at wire-time T and
T and that ingress node does not receive that response packet. that ingress node ID0 does not receive that response packet within a
reasonable period of time.
5.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.
skipping to change at page 14, line 51 skipping to change at page 16, line 51
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 GMPLS networks may large. Simple upper bounds could be used. But GMPLS networks may
accommodate 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.
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 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 undefined.
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 undefined. 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.
5.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.
skipping to change at page 15, line 37 skipping to change at page 17, line 37
PATH message packet is sent towards the egress node. PATH message packet is sent towards the egress node.
o If the corresponding RESV message arrives within a reasonable o If the corresponding RESV message arrives within a reasonable
period of time, take the final timestamp (T2) as soon as possible period of time, take the final timestamp (T2) as soon as possible
upon the receipt of the message. By subtracting the two upon the receipt of the message. By subtracting the two
timestamps, an estimate of bidirectional LSP setup delay (T2 -T1) timestamps, an estimate of bidirectional LSP setup delay (T2 -T1)
can be computed. can be computed.
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. Note that the 'reasonable'
the 'reasonable' threshold is a parameter of the methodology. 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).
6. 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.
6.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:
skipping to change at page 16, line 32 skipping to change at page 18, line 32
6.2. Metric Name 6.2. Metric Name
Multiple bidirectional LSPs setup delay Multiple bidirectional LSPs setup delay
6.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_m, 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 when the first setup is attempted
6.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 number of milliseconds.
milliseconds.
6.5. Definition 6.5. Definition
Given lambda and X, for a real number dT, the multiple bidirectional Given Lambda_m and X, for a real number dT, the multiple
LSPs setup delay from ingress node to egress node at T is dT, means bidirectional LSPs setup delay from ingress node to egress node at T
that: is dT, means that:
o ingress node sends the first bit of the first PATH message heading o ingress node ID0 sends the first bit of the first PATH message
for egress node at wire-time T heading for egress node ID1 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_m
o ingress node receives all corresponding RESV message packets from o ingress node ID1 receives all corresponding RESV message packets
egress node, and from egress node ID1, and
o ingress node receives the last RESV message packets at wire-time o ingress node ID0 receives the last RESV message packets at wire-
T+dT time 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, means that ingress node sends all the
ingress node sends all the PATH messages to egress node and that the PATH messages to egress node and that the ingress node fails to
ingress node dose not receive one or more of the response messages. receive one or more of the response messages within a reasonable
period of time.
6.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 GMPLS networks may large. Simple upper bounds could be used. But GMPLS networks may
accommodate 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 multiple bidirectional LSPs setup delay
drastically from a network to another. In the process of varies drastically from a network to another. In the process of
bidirectional LSP setup, if the downstream node overrides the multiple bidirectional LSPs setup, if the downstream node
label suggested by the upstream node, the setup delay will also overrides the label suggested by the upstream node, the setup
increase obviously. Thus, in practice, the upper bound should be delay will also increase obviously. Thus, in practice, the upper
chosen carefully. bound should be chosen carefully.
o If the ingress node sends out the PATH messages to set up the o If the ingress node sends out the PATH messages to set up the
LSPs, but never receive all the corresponding RESV messages, the LSPs, but never receive all the corresponding RESV messages, the
multiple bidirectional LSPs setup delay is deemed to be infinite. multiple bidirectional LSPs setup delay is deemed to be undefined.
o If the ingress node sends out the PATH messages to set up the o If the ingress node sends out the PATH messages to set up the
LSPs, but receive one or more responding PathErr messages,the LSPs, but receive one or more responding PathErr messages,the
multiple bidirectional LSPs setup delay is also deemed to be multiple bidirectional LSPs setup delay is also deemed to be
infinite. There are many possible reasons for this case. For undefined. 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_m should be
chosen such that in the one hand the control plane is not carefully chosen such that in the one hand the control plane is
overburdened.On the other hand, the arrival rate should also be not overburdened.On the other hand, the arrival rate should also
large enough to meet the requirements of applications or services. be large enough to meet the requirements of applications or
services.
6.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'
skipping to change at page 18, line 38 skipping to change at page 20, line 40
PATH message packet is sent towards the egress node. PATH message packet is sent towards the egress node.
o If all of the corresponding RESV messages arrives within a o If all of the corresponding RESV messages arrives within a
reasonable period of time, take the final timestamp (T2) as soon reasonable period of time, take the final timestamp (T2) as soon
as possible upon the receipt of all the messages. By subtracting as possible upon the receipt of all the messages. By subtracting
the two timestamps, an estimate of multiple bidirectional LSPs the two timestamps, an estimate of multiple bidirectional LSPs
setup delay (T2 -T1) can be computed. setup delay (T2 -T1) can be computed.
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. Note that the
Note that the 'reasonable' threshold is a parameter of 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.
7. 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 GMPLS There are two different kinds of LSP release mechanisms in GMPLS
networks: 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.
7.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 release 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].
7.2. Metric Name 7.2. Metric Name
LSP graceful release delay LSP graceful release delay
7.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 when the release is attemped
7.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 number of milliseconds.
7.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 ID0 to egress node ID1 at T is dT, means that ingress node ID0
first bit of a PATH message including Admin Status Object with sends the first bit of a PATH message including Admin Status Object
setting the Reflect (R) and Delete (D) bits to egress node at wire- with setting the Reflect (R) and Delete (D) bits to egress node at
time T, that egress node receives that packet, then immediately sends wire-time T, that egress node ID1 receives that packet, then
a RESV message including Admin Status Object with the Delete (D) bit immediately sends a RESV message including Admin Status Object with
set back to ingress node. The ingress node sends out PathTear the Delete (D) bit set back to ingress node. The ingress node ID0
downstream to remove the LSP, and egress node receives the last bit sends out PathTear downstream to remove the LSP, and egress node ID1
of PathTear packet at wire-time T+dT. receives the last bit of PathTear packet at wire-time T+dT.
Also as an option, upon receipt of the PATH message including Admin Also as an option, upon receipt of the PATH message including Admin
Status Object with setting the Reflect (R) and Delete (D) bits, the Status Object with setting the Reflect (R) and Delete (D) bits, the
egress node may respond with PathErr message with the egress node ID1 may respond with PathErr message with the
Path_State_Removed flag set. Path_State_Removed flag set.
The LSP graceful release delay from ingress node to egress node at T The LSP graceful release delay from ingress node ID0 to egress node
is undefined (informally, infinite), means that ingress node sends ID1 at T is undefined, means that ingress node ID0 sends the first
the first bit of PATH message to egress node at wire-time T and that bit of PATH message to egress node ID1 at wire-time T and that
(either egress node does not receive the PATH packet, egress node (either egress node does not receive the PATH packet, egress node
does not send corresponding RESV message packet in response, ingress does not send corresponding RESV message packet in response, ingress
node does not receive that RESV packet, or) the egress does not node does not receive that RESV packet, or) the egress node ID1 does
receive the PathTear. not receive the PathTear within a reasonable period of time.
The LSP graceful release delay from egress node to ingress node at T The LSP graceful release delay from egress node ID1 to ingress node
is dT, means that egress node sends the first bit of a RESV message ID0 at T is dT, means that egress node ID1 sends the first bit of a
including Admin Status Object with setting the Reflect (R) and Delete RESV message including Admin Status Object with setting the Reflect
(D) bits to ingress node at wire-time T. The ingress node sends out (R) and Delete (D) bits to ingress node at wire-time T. The ingress
PathTear downstream to remove the LSP, and egress node receives the node ID0 sends out PathTear downstream to remove the LSP, and egress
last bit of PathTear packet at wire-time T+dT. node ID1 receives the 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 ID1 to ingress node
is undefined (informally, infinite), means that egress node sends the ID0 at T is undefined, means that egress node ID1 sends the first bit
first bit of RESV message including Admin Status Object with setting of RESV message including Admin Status Object with setting the
the Reflect (R) and Delete (D) bits to ingress node at wire-time T Reflect (R) and Delete (D) bits to ingress node ID0 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 node ID1 does not receive the PathTear within a reasonable
period of time.
7.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
latency value is infinite or whether it is merely very large. latency value is infinite or whether it is merely very large.
Simple upper bounds could be used. But the upper bound should be Simple upper bounds could be used. But the upper bound should be
chosen carefully in practice; chosen carefully in practice;
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 undefined. 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 undefined;
7.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 ingress 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;
o Upon receiving the PATH message including Admin Status Object with o Upon receiving the PATH message including Admin Status Object with
the Reflect (R) and Delete (D) bits set, the egress node sends a the Reflect (R) and Delete (D) bits set, the egress node sends a
RESV message including Admin Status Object with the Delete (D) and RESV message including Admin Status Object with the Delete (D) and
Reflect (R) bits set. Or, alternatively, the egress node sends a Reflect (R) bits set. Or, alternatively, the egress node sends a
PathErr message with the Path_State_Removed flag set upstream; PathErr message with the Path_State_Removed flag set upstream;
o When the ingress node receive the RESV message or the PathErr o When the ingress node receive the RESV message or the PathErr
message, it sends a PathTear message to remove the LSP; message, it sends a PathTear message 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).
o If the ingress node sends the PATH message downstream, but the
egress node fails to receive the PathTear message within a
reasonable period of time, the LSP graceful release delay is
deemed to be undefined. Note that the 'reasonable' threshold is a
parameter of the methodology.
In the second circumstance, the methodology would proceed as follows: In the second circumstance, the methodology would 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 On the egress node, form the RESV message including Admin Status o On the egress node, form the RESV 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
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).
8. Typical Testing Cases of Single Unidirectional LSP Setup Delay o If the ingress node sends the PATH message downstream, but the
egress node fails to receive the PathTear message within a
reasonable period of time, the LSP graceful release delay is
deemed to be undefined. Note that the 'reasonable' threshold is a
parameter of the methodology.
Now we define typical test cases of getting unidirectional LSP setup 8. A Definition for Samples of Single Unidirectional LSP Setup Delay
delay.
8.1. With No LSP in the Network In Section 3, we define the singleton metric of Single unidirectional
LSP setup delay. Now we define how to get one particular sample of
Single unidirectional LSP setup delay. Sampling is to select a
particular potion of singleton values of the given parameters. Like
in [RFC2330], we use Poisson sampling as an example.
8.1.1. Motivation 8.1. Metric Name
Single unidirectional LSP setup delay sample
8.2. Metric Parameters
o ID0, the ingress LSR ID
o ID1, the egress LSR ID
o T0, a time
o Tf, a time
o Lambda, a rate in the reciprocal seconds
o Th, LSP holding time
o Td, the maximum waiting time for successful setup
8.3. Metric Units
A sequence of pairs; the elements of each pair are:
o T, a time when setup is attemped
o dT, either a real number or an undefined number of milli-seconds.
8.4. Definition
Given T0, Tf, and lambda, compute a pseudo-random Poisson process
beginning at or before T0, with average arrival rate lambda, and
ending at or after Tf. Those time values greater than or equal to T0
and less than or equal to Tf are then selected. At each of the times
in this process, we obtain the value of unidirectional LSP setup
delay sample at this time. The value of the sample is the sequence
made up of the resulting <time, LSP setup delay> pairs. If there are
no such pairs, the sequence is of length zero and the sample is said
to be empty.
8.5. Discussion
The parameters lambda should be carefully chosen. If the rate is too
high, too frequent LSP setup/release procedure results in high
overhead in the control plane. In turn, the high overhead will
increase unidirectional LSP setup delay. On the other hand if the
rate is too low, the sample could not completely reflect the dynamic
provisioning performance of the GMPLS network. The appropriate
lambda value depends on the given network.
The parameters Td should be carefully chosen. Different switching
technologies may vary significantly in performing a cross-connect
operation. At the same time, the time needed in setting up an LSP
under different traffic may also vary significantly.
In the case of active measurement, the parameters Th should be
carefully chosen. The combination of lambda and Th reflects the load
of the network. The selection of Th should take into account that
the network has sufficient resource to perform subsequent tests. The
value of Th may be constant during one sampling process for
simplicity considerations.
Note that for online or passive measurements, the holding time of an
LSP is determined by actual traffic, hence in this case Th is not an
input parameter.
8.6. Methodologies
o The selection of specific times, using the specified Poisson
arrival process, and
o Set up the LSP as the methodology for the singleton unidirectional
LSP setup delay, and obtain the value of unidirectional LSP setup
delay
o Release the LSP after Th, and wait for the next Poisson arrival
process
Note that: it is possible that before the previous LSP release
procedure completes, the next Poisson arrival process has arrived and
the LSP setup procedure is initiated. If there is resource
contention between the two LSPs, the LSP setup may fail.
8.7. Typical testing cases
8.7.1. With No LSP in the Network
8.7.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.
8.1.2. Methodologies 8.7.1.2. Methodologies
Make sure that there is no or very few LSPs in the network. The
methodology would proceed as follows:
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
o Release the LSP
o Repeat this process if multiple samples are needed
Note that: in case multiple samples are to be obtained, the interval Make sure that there is no LSP in the network, and proceed with the
between each process should be large enough to guarantee the network methodologies described in Section 8.6.
has already reached a stable state.
8.2. With a Number of LSPs in the Network 8.7.2. With a Number of LSPs in the Network
8.2.1. Motivation 8.7.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.
8.2.2. Methodologies 8.7.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 with the methodologies described in
Section 8.6.
o Set up the LSP using the methodology for the singleton single 9. A Definition for Samples of Multiple Unidirectional LSPs Setup Delay
unidirectional LSP setup delay, and obtain the value of
unidirectional LSP setup delay
o Release the LSP In Section 4, we define the singleton metric of multiple
unidirectional LSPs setup delay. Now we define how to get one
particular sample of multiple unidirectional LSP setup delay.
Sampling is to select a particular potion of singleton values of the
given parameters. Like in [RFC2330], we use Poisson sampling as an
example.
o Repeat this process if multiple samples are needed 9.1. Metric Name
Note that: in case multiple samples are to be obtained, the interval Multiple unidirectional LSPs setup delay sample
between each process should be large enough to guarantee the network
has already reached a stable state.
9. Typical Testing Cases of multiple Unidirectional LSPs Setup Delay 9.2. Metric Parameters
Now we define typical test cases of getting multiple unidirectional o ID0, the ingress LSR ID
LSPs setup delay.
9.1. With No LSP in the Network o ID1, the egress LSR ID
9.1.1. Motivation o T0, a time
multiple unidirectional LSP setup delay with no LSP in the network is o Tf, a time
important because this reflects the inherent delay of an RSVP-TE
implementation. The minimum value provides an indication of the
delay that will likely be experienced when a number of LSPs are setup
with the lightest load in the control plane.
9.1.2. Methodologies o Lambda_m, a rate in the reciprocal seconds
Make sure that there is no or very few LSPs in the network. The o Lambda, a rate in the reciprocal seconds
methodology would proceed as follows:
o Set up the LSPs using the methodology for the singleton multiple o X, the number of LSPs to setup
unidirectional LSP setup delay, and obtain the value of multiple
unidirectional LSP setup delay
o Release the LSPs o Td, the maximum waiting time for successful multiple
unidirectional LSPs setup
o Repeat this process if multiple samples are needed 9.3. Metric Units
Note that: in case multiple samples are to be obtained, the interval A sequence of pairs; the elements of each pair are:
between each process should be large enough to guarantee the network
has already reached a stable state.
9.2. With a Number of LSPs in the Network o T, a time when the first setup is attemped
9.2.1. Motivation o dT, either a real number or an undefined number of milli-seconds.
multiple unidirectional LSP setup delay with a number of LSPs in the 9.4. Definition
Given T0, Tf, and lambda, compute a pseudo-random Poisson process
beginning at or before T0, with average arrival rate lambda, and
ending at or after Tf. Those time values greater than or equal to T0
and less than or equal to Tf are then selected. At each of the times
in this process, we obtain the value of multiple unidirectional LSP
setup delay sample at this time. The value of the sample is the
sequence made up of the resulting <time, setup delay> pairs. If
there are no such pairs, the sequence is of length zero and the
sample is said to be empty.
9.5. Discussion
The parameter lambda is used as arrival rate of "bacth unidirectional
LSPs setup" operation. It regulates the interval in between each
batch operatoin. The parameter lambda_m is used within each batch
operation, as described in Section 4.
The parameters lambda and lambda_m should be carefully chosen. If
the rate is too high, too frequent LSP setup/release procedure
results in high overhead in the control plane. In turn, the high
overhead will increase unidirectional LSP setup delay. On the other
hand if the rate is too low, the sample could not completely reflect
the dynamic provisioning performance of the GMPLS network. The
appropriate lambda and lambda_m value depends on the given network.
The parameters Td should be carefully chosen. Different switching
technologies may vary significantly in performing a cross-connect
operation. At the same time, the time needed in setting up an LSP
under different traffic may also vary significantly.
9.6. Methodologies
o The selection of specific times, using the specified Poisson
arrival process, and
o Set up the LSP as the methodology for the singleton multiple
unidirectional LSPs setup delay, and obtain the value of multiple
unidirectional LSPs setup delay
o Release the LSP after Th, and wait for the next Poisson arrival
process
Note that: it is possible that before the previous LSP release
procedure completes, the next Poisson arrival process has arrived and
the LSP setup procedure is initiated. If there is resource
contention between the two LSP, the LSP setup may fail.
9.7. Typical testing cases
9.7.1. With No LSP in the Network
9.7.1.1. Motivation
multiple unidirectional LSP setup delay with no LSP in the network is
important because this reflects the inherent delay of an RSVP-TE
implementation. The minimum value provides an indication of the
delay that will likely be experienced when an LSPs traverse the
shortest route with the lightest load in the control plane.
9.7.1.2. Methodologies
Make sure that there is no LSP in the network, and proceed with the
methodologies described in Section 9.6.
9.7.2. With a Number of LSPs in the Network
9.7.2.1. Motivation
multiple unidirectional 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.
9.2.2. Methodologies 9.7.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 with the methodologies described in
Section 9.6..
o Set up the LSPs using the methodology for the singleton multiple 10. A Definition for Samples of Single Bidirectional LSP Setup Delay
unidirectional LSP setup delay, and obtain the value of multiple
unidirectional LSP setup delay
o Release the LSPs In Section 5, we define the singleton metric of Single Bidirectional
LSP setup delay. Now we define how to get one particular sample of
Single Bidirectional LSP setup delay. Sampling is to select a
particular potion of singleton values of the given parameters. Like
in [RFC2330], we use Poisson sampling as an example.
o Repeat this process if multiple samples are needed 10.1. Metric Name
Note that: in case multiple samples are to be obtained, the interval Single Bidirectional LSP setup delay sample with no LSP in the
between each process should be large enough to guarantee the network network
has already reached a stable state.
10. Typical Testing Cases of Single Bidirectional LSP Setup Delay 10.2. Metric Parameters
Now we define typical test cases of getting single bidirectional LSP o ID0, the ingress LSR ID
setup delay.
10.1. With No LSP in the Network o ID1, the egress LSR ID
10.1.1. Motivation o T0, a time
Single unidirectional LSP setup delay with no LSP in the network is o Tf, a time
important because this reflects the inherent delay of an RSVP-TE
implementation. The minimum value provides an indication of the
delay that will likely be experienced when an LSP traverses the
shortest route with the lightest load in the control plane.
10.1.2. Methodologies o Lambda, a rate in the reciprocal seconds
Make sure that there is no or very few LSPs in the network. The o Th, LSP holding time
methodology would proceed as follows:
o Set up the LSP using the methodology for the singleton o Td, the maximum waiting time for successful setup
bidirectional LSP setup delay, and obtain the value of
unidirectional LSP setup delay
o Release the LSP 10.3. Metric Units
o Repeat this process if multiple samples are needed A sequence of pairs; the elements of each pair are:
Note that: in case multiple samples are to be obtained, the interval o T, a time when setup is attemped
between each process should be large enough to guarantee the network
has already reached a stable state.
10.2. With a Number of LSPs in the Network o dT, either a real number or an undefined number of milli-seconds.
10.2.1. Motivation 10.4. Definition
Given T0, Tf, and lambda, compute a pseudo-random Poisson process
beginning at or before T0, with average arrival rate lambda, and
ending at or after Tf. Those time values greater than or equal to T0
and less than or equal to Tf are then selected. At each of the times
in this process, we obtain the value of Bidirectional LSP setup delay
sample at this time. The value of the sample is the sequence made up
of the resulting <time, LSP setup delay> pairs. If there are no such
pairs, the sequence is of length zero and the sample is said to be
empty.
10.5. Discussion
The parameters lambda should be carefully chosen. If the rate is too
high, too frequent LSP setup/release procedure results in high
overhead in the control plane. In turn, the high overhead will
increase Bidirectional LSP setup delay. On the other hand if the
rate is too low, the sample could not completely reflect the dynamic
provisioning performance of the GMPLS network. The appropriate
lambda value depends on the given network.
The parameters Td should be carefully chosen. Different switching
technologies may vary significantly in performing a cross-connect
operation. At the same time, the time needed in setting up an LSP
under different traffic may also vary significantly.
In the case of active measurement, the parameters Th should be
carefully chosen. The combination of lambda and Th reflects the load
of the network. The selection of Th should take into account that
the network has sufficient resource to perform subsequent tests. The
value of Th may be constant during one sampling process for
simplicity considerations.
Note that for online or passive measurements, the holding time of an
LSP is determined by actual traffic, hence in this case Th is not an
input parameter.
10.6. Methodologies
o The selection of specific times, using the specified Poisson
arrival process, and
o Set up the LSP as the methodology for the singleton bidirectional
LSP setup delay, and obtain the value of bidirectional LSP setup
delay
o Release the LSP after Th, and wait for the next Poisson arrival
process
Note that: it is possible that before the previous LSP release
procedure completes, the next Poisson arrival process has arrived and
the LSP setup procedure is initiated. If there is resource
contention between the two LSP, the LSP setup may fail.
10.7. Typical testing cases
10.7.1. With No LSP in the Network
10.7.1.1. Motivation
Single bidirectional LSP setup delay with no LSP in the network is
important because this reflects the inherent delay of an RSVP-TE
implementation. The minimum value provides an indication of the
delay that will likely be experienced when an LSP traverses the
shortest route with the lightest load in the control plane.
10.7.1.2. Methodologies
Make sure that there is no LSP in the network, and proceed with the
methodologies described in Section 10.6.
10.7.2. With a Number of LSPs in the Network
10.7.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.
10.2.2. Methodologies 10.7.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 with the methodologies described in
Section 10.6. .
o Set up the LSP using the methodology for the singleton 11. A Definition for Samples of Multiple Bidirectional LSPs Setup Delay
bidirectional bidirectional LSP setup delay, and obtain the value
of bidirectional LSP setup delay
o Release the LSP In Section 6, we define the singleton metric of multiple
bidirectional LSPs setup delay. Now we define how to get one
particular sample of multiple bidirectional LSP setup delay.
Sampling is to select a particular potion of singleton values of the
given parameters. Like in [RFC2330], we use Poisson sampling as an
example.
o Repeat this process if multiple samples are needed 11.1. Metric Name
Note that: in case multiple samples are to be obtained, the interval Multiple bidirectional LSPs setup delay sample
between each process should be large enough to guarantee the network
has already reached a stable state.
11. Typical Testing Cases of multiple Bidirectional LSPs Setup Delay 11.2. Metric Parameters
Now we define typical test cases of getting multiple bidirectional o ID0, the ingress LSR ID
LSPs setup delay.
11.1. With No LSP in the Network o ID1, the egress LSR ID
11.1.1. Motivation o T0, a time
multiple bidirectional LSP setup delay with no LSP in the network is o Tf, a time
important because this reflects the inherent delay of an RSVP-TE
implementation. The minimum value provides an indication of the
delay that will likely be experienced when a number of LSPs are setup
with the lightest load in the control plane.
11.1.2. Methodologies o Lambda_m, a rate in the reciprocal seconds
Make sure that there is no or very few LSPs in the network. The o Lambda, a rate in the reciprocal seconds
methodology would proceed as follows:
o Set up the LSPs using the methodology for the singleton multiple o X, the number of LSPs to setup
multiple bidirectional LSP setup delay, and obtain the value of
multiple bidirectional LSP setup delay
o Release the LSPs o Td, the maximum waiting time for successful multiple
unidirectional LSPs setup
o Repeat this process if multiple samples are needed 11.3. Metric Units
Note that: in case multiple samples are to be obtained, the interval A sequence of pairs; the elements of each pair are:
between each process should be large enough to guarantee the network
has already reached a stable state.
11.2. With a Number of LSPs in the Network o T, a time when the first setup is attemped
11.2.1. Motivation o dT, either a real number or an undefined number of milli-seconds.
11.4. Definition
Given T0, Tf, and lambda, compute a pseudo-random Poisson process
beginning at or before T0, with average arrival rate lambda, and
ending at or after Tf. Those time values greater than or equal to T0
and less than or equal to Tf are then selected. At each of the times
in this process, we obtain the value of multiple unidirectional LSP
setup delay sample at this time. The value of the sample is the
sequence made up of the resulting <time, setup delay> pairs. If
there are no such pairs, the sequence is of length zero and the
sample is said to be empty.
11.5. Discussion
The parameter lambda is used as arrival rate of "bacth bidirectional
LSPs setup" operation. It regulates the interval in between each
batch operatoin. The parameter lambda_m is used within each batch
operation, as described in Section 6.
The parameters lambda and lambda_m should be carefully chosen. If
the rate is too high, too frequent LSP setup/release procedure
results in high overhead in the control plane. In turn, the high
overhead will increase unidirectional LSP setup delay. On the other
hand if the rate is too low, the sample could not completely reflect
the dynamic provisioning performance of the GMPLS network. The
appropriate lambda and lambda_m value depends on the given network.
The parameters Td should be carefully chosen. Different switching
technologies may vary significantly in performing a cross-connect
operation. At the same time, the time needed in setting up an LSP
under different traffic may also vary significantly.
11.6. Methodologies
o The selection of specific times, using the specified Poisson
arrival process, and
o Set up the LSP as the methodology for the singleton multiple
bidirectional LSPs setup delay, and obtain the value of multiple
unidirectional LSPs setup delay
o Release the LSP after Th, and wait for the next Poisson arrival
process
Note that: it is possible that before the previous LSP release
procedure completes, the next Poisson arrival process has arrived and
the LSP setup procedure is initiated. If there is resource
contention between the two LSP, the LSP setup may fail.
11.7. Typical testing cases
11.7.1. With No LSP in the Network
11.7.1.1. Motivation
multiple bidirectional LSP setup delay with no LSP in the network is
important because this reflects the inherent delay of an RSVP-TE
implementation. The minimum value provides an indication of the
delay that will likely be experienced when an LSPs traverse the
shortest route with the lightest load in the control plane.
11.7.1.2. Methodologies
Make sure that there is no LSP in the network, and proceed with the
methodologies described in Section 9.6.
11.7.2. With a Number of LSPs in the Network
11.7.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.
11.2.2. Methodologies 11.7.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 with the methodologies described in
Section 11.6..
o Set up the LSPs using the methodology for the singleton multiple 12. A Definition for Samples of LSP Graceful Release Delay
bidirectional LSPs setup delay, and obtain the value of multiple
bidirectional LSPs setup delay
o Release the LSPs In Section 7, we define the singleton metric of LSP graceful release
delay. Now we define how to get one particular sample of LSP
graceful release delay. We also use Poisson sampling as an example.
o Repeat this process if multiple samples are needed 12.1. Metric Name
Note that: in case multiple samples are to be obtained, the interval LSP graceful release delay sample
between each process should be large enough to guarantee the network
has already reached a stable state.
12. Some Statistics Definitions for Metrics to Report 12.2. Metric Parameters
o ID0, the ingress LSR ID
o ID1, the egress LSR ID
o T0, a time
o Tf, a time
o Lambda, a rate in reciprocal seconds
o Td, the maximum waiting time for successful LSP release
12.3. Metric Units
A sequence of pairs; the elements of each pair are:
o T, a time, and
o dT, either a real number or an undefined number of milli-seconds.
12.4. Definition
Given T0, Tf, and lambda, we compute a pseudo-random Poisson process
beginning at or before T0, with average arrival rate lambda, and
ending at or after Tf. Those time values greater than or equal to T0
and less than or equal to Tf are then selected. At each of the times
in this process, we obtain the value of LSP graceful release delay
sample at this time. The value of the sample is the sequence made up
of the resulting <time, LSP graceful delay> pairs. If there are no
such pairs, the sequence is of length zero and the sample is said to
be empty.
12.5. Discussion
The parameter lambda should be carefully chosen. If the rate is too
large, too frequent LSP setup/release procedure results in high
overhead in the control plane. In turn, the high overhead will
increase unidirectional LSP setup delay. On the other hand if the
rate is too small, the sample could not completely reflect the
dynamic provisioning performance of the GMPLS network. The
appropriate lambda value depends on the given network.
12.6. Methodologies
Generally the methodology would proceed as follows:
o Setup the LSP to be deleted
o The selection of specific times, using the specified Poisson
arrival process, and
o Release the LSP as the methodology for the singleton LSP graceful
release delay, and obtain the value of LSP graceful release delay
o Setup the LSP, and restart the Poisson arrival process, wait for
the next Poisson arrival process
13. Discussion for unsuccessful setup/release cases
As has been mentioned earlier, LSP setup/release may fail due to
various reasons. For example, setup/release may fail when the
control plane is overburdened or when there is resource shortage in
one of the intermediat nodes. Since the setup/release failure may
have significant impact on network operation, it is worthwhile to
report each failure cases, so that appropriate operations can be
performed to check the possible implementation,configuration or other
deficiency.
Although not commonly seen, an LSP setup/release attemp may be
falsely carried out. for example, the setup/release request may be
targed to a wrong egress node. Although faulty results may have
totally different implications to the control plane, if compared with
failure cases, for the purpose of performance evaluation, it is still
reasonable to treat such results as unsuccessful cases. Thus the
unsuccessful cases include both failure and incorrect cases.
Once a sample of a particular metric, e.g, single unidirectional LSP
setup delay, is obtained, we can deduce the unsuccessful cases by
sorting out from the sample the <time, delay> pairs with undefined
delay value.
14. 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 number of
infinite) number of milliseconds. In the following discussion, we milliseconds. In the following discussion, we only consider the
only consider the finite values. finite values.
12.1. The Minimum of Metric 14.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 if all the dT values are undefined. In addition, the
undefined. In addition, the metric minimum is undefined if the metric minimum is undefined if the sample is empty.
sample is empty.
12.2. The Median of Metric 14.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.
12.3. The percentile of Metric 14.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).
12.4. The Failure Probability 14.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 unsucessful times to the
total times. total times. Note here that both failure and incorrect cases are
counted as unsucessful cases.
13. Discussion 15. 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 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 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 data can not be forwarded immediately. The control plane. But the data can not be forwarded immediately.
unidirectional/bidirectional LSP setup delay in the data plane is The unidirectional/bidirectional LSP setup delay in the data plane
longer than in the control plane. is longer than in the control plane.
14. 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,
they can skew the results of the measurement, and in extreme cases they can skew the results of the measurement, and in extreme cases
cause congestion and denial of service. cause congestion and denial of service.
When samples of the metrics are collected in a passive manner, e.g., When samples of the metrics are collected in a passive manner, e.g.,
by monitoring the operations on real-life LSPs, the implementation of by monitoring the operations on real-life LSPs, the implementation of
the monitoring and reporting mechanism must be careful so that they the monitoring and reporting mechanism must be careful so that they
will not be used to attack the control plane. will not be used to attack the control plane.
Besides, the security considerations pertaining to the original RSVP Besides, the security considerations pertaining to the original RSVP
protocol [RFC2205] and its TE extensions [RFC3209] also remain protocol [RFC2205] and its TE extensions [RFC3209] also remain
relevant. relevant.
15. IANA Considerations 17. IANA Considerations
This document makes no requests for IANA action. This document makes no requests for IANA action.
16. Acknowledgements 18. 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. References 19. References
17.1. Normative References 19.1. Normative References
[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.
[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.
skipping to change at page 36, line 40 skipping to change at page 45, 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 19.2. Informative References
[RFC2330] Paxson, V., Almes, G., Mahdavi, J., and M. Mathis, [RFC2330] Paxson, V., Almes, G., Mahdavi, J., and M. Mathis,
"Framework for IP Performance Metrics", RFC 2330, "Framework for IP Performance Metrics", RFC 2330,
May 1998. May 1998.
Authors' Addresses Authors' Addresses
Weiqiang Sun Weiqiang Sun
Shanghai Jiao Tong University Shanghai Jiao Tong University
800 Dongchuan Road 800 Dongchuan Road
skipping to change at page 39, line 5 skipping to change at page 47, line 21
Email: BGu@ixiacom.com Email: BGu@ixiacom.com
Xueqing Wei Xueqing Wei
Fiberhome Telecommunicaiton Technology Co.,Ltd. Fiberhome Telecommunicaiton Technology Co.,Ltd.
Wuhan Wuhan
CN CN
Phone: +86 13871127882 Phone: +86 13871127882
Email: xqwei@fiberhome.com.cn Email: xqwei@fiberhome.com.cn
Tomohiro Otani
KDDI R&D Laboratories, Inc.
2-1-15 Ohara Kamifukuoka Saitama
356-8502
Japan
Phone: +81-49-278-7357
Email: otani@kddilabs.jp
Ruiquan Jing
China Telecom Beijing Research Institute
118 Xizhimenwai Avenue
Beijing 100035
CN
Phone: +86-10-58552000
Email: jingrq@ctbri.com.cn
Full Copyright Statement Full Copyright Statement
Copyright (C) The IETF Trust (2008). Copyright (C) The IETF Trust (2008).
This document is subject to the rights, licenses and restrictions This document is subject to the rights, licenses and restrictions
contained in BCP 78, and except as set forth therein, the authors contained in BCP 78, and except as set forth therein, the authors
retain all their rights. retain all their rights.
This document and the information contained herein are provided on an This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
 End of changes. 165 change blocks. 
408 lines changed or deleted 799 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/