draft-ietf-ccamp-lsp-dppm-05.txt   draft-ietf-ccamp-lsp-dppm-06.txt 
Network Working Group W. Sun, Ed. Network Working Group W. Sun, Ed.
Internet-Draft SJTU Internet-Draft SJTU
Intended status: Standards Track G. Zhang, Ed. Intended status: Standards Track G. Zhang, Ed.
Expires: September 29, 2009 CATR Expires: January 10, 2010 CATR
March 28, 2009 July 9, 2009
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-05.txt draft-ietf-ccamp-lsp-dppm-06.txt
Status of this Memo Status of this Memo
This Internet-Draft is submitted to IETF in full conformance with the This Internet-Draft is submitted to IETF in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79. This document may contain material
from IETF Documents or IETF Contributions published or made publicly
available before November 10, 2008. The person(s) controlling the
copyright in some of this material may not have granted the IETF
Trust the right to allow modifications of such material outside the
IETF Standards Process. Without obtaining an adequate license from
the person(s) controlling the copyright in such materials, this
document may not be modified outside the IETF Standards Process, and
derivative works of it may not be created outside the IETF Standards
Process, except to format it for publication as an RFC or to
translate it into languages other than English.
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
other groups may also distribute working documents as Internet- other groups may also distribute working documents as Internet-
Drafts. Drafts.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt. http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html.
This Internet-Draft will expire on September 29, 2009. This Internet-Draft will expire on January 10, 2010.
Copyright Notice Copyright Notice
Copyright (c) 2009 IETF Trust and the persons identified as the Copyright (c) 2009 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents in effect on the date of Provisions Relating to IETF Documents in effect on the date of
publication of this document (http://trustee.ietf.org/license-info). publication of this document (http://trustee.ietf.org/license-info).
Please review these documents carefully, as they describe your rights Please review these documents carefully, as they describe your rights
and restrictions with respect to this document. and restrictions with respect to this document.
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- Multiplexers (ADMs), photonic cross-connects (PXCs), optical cross-
connects (OXCs), etc. Dynamic provisioning ability of these connects (OXCs), etc. Dynamic provisioning ability of these
physically diverse devices differs from each other drastically. At physically diverse devices differs from each other drastically. At
the same time, the need for Dynamicly provisioned connections is the same time, the need for dynamically provisioned connections is
increasing because optical networks are being deployed in metro increasing because optical networks are being deployed in metro
areas. As different applications have varied requirements in the areas. As different applications have varied requirements in the
provisioning performance of optical networks, it is imperative to provisioning performance of optical networks, it is imperative to
define standardized metrics and procedures such that the performance define standardized metrics and procedures such that the performance
of networks and application needs can be mapped to each other. of networks and application needs can be mapped to each other.
This document provides a series of performance metrics to evaluate This document provides a series of performance metrics to evaluate
the dynamic LSP provisioning performance in GMPLS networks, the dynamic LSP provisioning performance in GMPLS networks,
specifically the 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 . . . . . . . . . . . . . . . . . . . . . . . . . 6 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 7
2. Overview of Performance Metrics . . . . . . . . . . . . . . . 7
3. A Singleton Definition for Single Unidirectional LSP Setup 2. Conventions Used in This Document . . . . . . . . . . . . . . 8
Delay . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
3.1. Motivation . . . . . . . . . . . . . . . . . . . . . . . . 8 3. Overview of Performance Metrics . . . . . . . . . . . . . . . 9
3.2. Metric Name . . . . . . . . . . . . . . . . . . . . . . . 8
3.3. Metric Parameters . . . . . . . . . . . . . . . . . . . . 8 4. A Singleton Definition for Single Uni-directional LSP
3.4. Metric Units . . . . . . . . . . . . . . . . . . . . . . . 9 Setup Delay . . . . . . . . . . . . . . . . . . . . . . . . . 10
3.5. Definition . . . . . . . . . . . . . . . . . . . . . . . . 9 4.1. Motivation . . . . . . . . . . . . . . . . . . . . . . . . 10
3.6. Discussion . . . . . . . . . . . . . . . . . . . . . . . . 9 4.2. Metric Name . . . . . . . . . . . . . . . . . . . . . . . 10
3.7. Methodologies . . . . . . . . . . . . . . . . . . . . . . 10 4.3. Metric Parameters . . . . . . . . . . . . . . . . . . . . 10
4. A Singleton Definition for multiple Unidirectional LSP
Setup Delay . . . . . . . . . . . . . . . . . . . . . . . . . 11
4.1. Motivation . . . . . . . . . . . . . . . . . . . . . . . . 11
4.2. Metric Name . . . . . . . . . . . . . . . . . . . . . . . 11
4.3. Metric Parameters . . . . . . . . . . . . . . . . . . . . 11
4.4. Metric Units . . . . . . . . . . . . . . . . . . . . . . . 11 4.4. Metric Units . . . . . . . . . . . . . . . . . . . . . . . 11
4.5. Definition . . . . . . . . . . . . . . . . . . . . . . . . 11 4.5. Definition . . . . . . . . . . . . . . . . . . . . . . . . 11
4.6. Discussion . . . . . . . . . . . . . . . . . . . . . . . . 12 4.6. Discussion . . . . . . . . . . . . . . . . . . . . . . . . 11
4.7. Methodologies . . . . . . . . . . . . . . . . . . . . . . 13 4.7. Methodologies . . . . . . . . . . . . . . . . . . . . . . 12
5. A Singleton Definition for Single Bidirectional LSP Setup
Delay . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14 5. A Singleton Definition for multiple Uni-directional LSP
5.1. Motivation . . . . . . . . . . . . . . . . . . . . . . . . 14 Setup Delay . . . . . . . . . . . . . . . . . . . . . . . . . 13
5.2. Metric Name . . . . . . . . . . . . . . . . . . . . . . . 14 5.1. Motivation . . . . . . . . . . . . . . . . . . . . . . . . 13
5.3. Metric Parameters . . . . . . . . . . . . . . . . . . . . 14 5.2. Metric Name . . . . . . . . . . . . . . . . . . . . . . . 13
5.4. Metric Units . . . . . . . . . . . . . . . . . . . . . . . 15 5.3. Metric Parameters . . . . . . . . . . . . . . . . . . . . 13
5.5. Definition . . . . . . . . . . . . . . . . . . . . . . . . 15 5.4. Metric Units . . . . . . . . . . . . . . . . . . . . . . . 13
5.6. Discussion . . . . . . . . . . . . . . . . . . . . . . . . 15 5.5. Definition . . . . . . . . . . . . . . . . . . . . . . . . 13
5.7. Methodologies . . . . . . . . . . . . . . . . . . . . . . 16 5.6. Discussion . . . . . . . . . . . . . . . . . . . . . . . . 14
6. A Singleton Definition for multiple Bidirectional LSPs 5.7. Methodologies . . . . . . . . . . . . . . . . . . . . . . 15
Setup Delay . . . . . . . . . . . . . . . . . . . . . . . . . 17
6.1. Motivation . . . . . . . . . . . . . . . . . . . . . . . . 17 6. A Singleton Definition for Single Bi-directional LSP
6.2. Metric Name . . . . . . . . . . . . . . . . . . . . . . . 17 Setup Delay . . . . . . . . . . . . . . . . . . . . . . . . . 16
6.1. Motivation . . . . . . . . . . . . . . . . . . . . . . . . 16
6.2. Metric Name . . . . . . . . . . . . . . . . . . . . . . . 16
6.3. Metric Parameters . . . . . . . . . . . . . . . . . . . . 17 6.3. Metric Parameters . . . . . . . . . . . . . . . . . . . . 17
6.4. Metric Units . . . . . . . . . . . . . . . . . . . . . . . 17 6.4. Metric Units . . . . . . . . . . . . . . . . . . . . . . . 17
6.5. Definition . . . . . . . . . . . . . . . . . . . . . . . . 17 6.5. Definition . . . . . . . . . . . . . . . . . . . . . . . . 17
6.6. Discussion . . . . . . . . . . . . . . . . . . . . . . . . 18 6.6. Discussion . . . . . . . . . . . . . . . . . . . . . . . . 17
6.7. Methodologies . . . . . . . . . . . . . . . . . . . . . . 19 6.7. Methodologies . . . . . . . . . . . . . . . . . . . . . . 18
7. A Singleton Definition for LSP Graceful Release Delay . . . . 20
7.1. Motivation . . . . . . . . . . . . . . . . . . . . . . . . 20 7. A Singleton Definition for multiple Bi-directional LSPs
7.2. Metric Name . . . . . . . . . . . . . . . . . . . . . . . 20 Setup Delay . . . . . . . . . . . . . . . . . . . . . . . . . 19
7.3. Metric Parameters . . . . . . . . . . . . . . . . . . . . 20 7.1. Motivation . . . . . . . . . . . . . . . . . . . . . . . . 19
7.4. Metric Units . . . . . . . . . . . . . . . . . . . . . . . 20 7.2. Metric Name . . . . . . . . . . . . . . . . . . . . . . . 19
7.5. Definition . . . . . . . . . . . . . . . . . . . . . . . . 20 7.3. Metric Parameters . . . . . . . . . . . . . . . . . . . . 19
7.6. Discussion . . . . . . . . . . . . . . . . . . . . . . . . 21 7.4. Metric Units . . . . . . . . . . . . . . . . . . . . . . . 19
7.7. Methodologies . . . . . . . . . . . . . . . . . . . . . . 22 7.5. Definition . . . . . . . . . . . . . . . . . . . . . . . . 19
8. A Definition for Samples of Single Unidirectional LSP 7.6. Discussion . . . . . . . . . . . . . . . . . . . . . . . . 20
Setup Delay . . . . . . . . . . . . . . . . . . . . . . . . . 24 7.7. Methodologies . . . . . . . . . . . . . . . . . . . . . . 21
8.1. Metric Name . . . . . . . . . . . . . . . . . . . . . . . 24 8. A Singleton Definition for LSP Graceful Release Delay . . . . 22
8.2. Metric Parameters . . . . . . . . . . . . . . . . . . . . 24 8.1. Motivation . . . . . . . . . . . . . . . . . . . . . . . . 22
8.3. Metric Units . . . . . . . . . . . . . . . . . . . . . . . 24 8.2. Metric Name . . . . . . . . . . . . . . . . . . . . . . . 22
8.4. Definition . . . . . . . . . . . . . . . . . . . . . . . . 24 8.3. Metric Parameters . . . . . . . . . . . . . . . . . . . . 22
8.5. Discussion . . . . . . . . . . . . . . . . . . . . . . . . 25 8.4. Metric Units . . . . . . . . . . . . . . . . . . . . . . . 22
8.6. Methodologies . . . . . . . . . . . . . . . . . . . . . . 25 8.5. Definition . . . . . . . . . . . . . . . . . . . . . . . . 22
8.7. Typical testing cases . . . . . . . . . . . . . . . . . . 25 8.6. Discussion . . . . . . . . . . . . . . . . . . . . . . . . 23
8.7.1. With No LSP in the Network . . . . . . . . . . . . . . 26 8.7. Methodologies . . . . . . . . . . . . . . . . . . . . . . 24
8.7.2. With a Number of LSPs in the Network . . . . . . . . . 26
9. A Definition for Samples of Multiple Unidirectional LSPs 9. A Definition for Samples of Single Uni-directional LSP
Setup Delay . . . . . . . . . . . . . . . . . . . . . . . . . 27 Setup Delay . . . . . . . . . . . . . . . . . . . . . . . . . 26
9.1. Metric Name . . . . . . . . . . . . . . . . . . . . . . . 27 9.1. Metric Name . . . . . . . . . . . . . . . . . . . . . . . 26
9.2. Metric Parameters . . . . . . . . . . . . . . . . . . . . 27 9.2. Metric Parameters . . . . . . . . . . . . . . . . . . . . 26
9.3. Metric Units . . . . . . . . . . . . . . . . . . . . . . . 27 9.3. Metric Units . . . . . . . . . . . . . . . . . . . . . . . 26
9.4. Definition . . . . . . . . . . . . . . . . . . . . . . . . 27 9.4. Definition . . . . . . . . . . . . . . . . . . . . . . . . 26
9.5. Discussion . . . . . . . . . . . . . . . . . . . . . . . . 28 9.5. Discussion . . . . . . . . . . . . . . . . . . . . . . . . 27
9.6. Methodologies . . . . . . . . . . . . . . . . . . . . . . 28 9.6. Methodologies . . . . . . . . . . . . . . . . . . . . . . 27
9.7. Typical testing cases . . . . . . . . . . . . . . . . . . 28 9.7. Typical testing cases . . . . . . . . . . . . . . . . . . 27
9.7.1. With No LSP in the Network . . . . . . . . . . . . . . 28 9.7.1. With no LSP in the Network . . . . . . . . . . . . . . 28
9.7.2. With a Number of LSPs in the Network . . . . . . . . . 29 9.7.2. With a number of LSPs in the Network . . . . . . . . . 28
10. A Definition for Samples of Single Bidirectional LSP Setup
Delay . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30 10. A Definition for Samples of Multiple Uni-directional LSPs
10.1. Metric Name . . . . . . . . . . . . . . . . . . . . . . . 30 Setup Delay . . . . . . . . . . . . . . . . . . . . . . . . . 29
10.2. Metric Parameters . . . . . . . . . . . . . . . . . . . . 30 10.1. Metric Name . . . . . . . . . . . . . . . . . . . . . . . 29
10.3. Metric Units . . . . . . . . . . . . . . . . . . . . . . . 30 10.2. Metric Parameters . . . . . . . . . . . . . . . . . . . . 29
10.4. Definition . . . . . . . . . . . . . . . . . . . . . . . . 30 10.3. Metric Units . . . . . . . . . . . . . . . . . . . . . . . 29
10.5. Discussion . . . . . . . . . . . . . . . . . . . . . . . . 31 10.4. Definition . . . . . . . . . . . . . . . . . . . . . . . . 29
10.6. Methodologies . . . . . . . . . . . . . . . . . . . . . . 31 10.5. Discussion . . . . . . . . . . . . . . . . . . . . . . . . 30
10.7. Typical testing cases . . . . . . . . . . . . . . . . . . 31 10.6. Methodologies . . . . . . . . . . . . . . . . . . . . . . 30
10.7.1. With No LSP in the Network . . . . . . . . . . . . . . 32 10.7. Typical testing cases . . . . . . . . . . . . . . . . . . 30
10.7.2. With a Number of LSPs in the Network . . . . . . . . . 32 10.7.1. With No LSP in the Network . . . . . . . . . . . . . . 31
11. A Definition for Samples of Multiple Bidirectional LSPs 10.7.2. With a Number of LSPs in the Network . . . . . . . . . 31
Setup Delay . . . . . . . . . . . . . . . . . . . . . . . . . 33
11.1. Metric Name . . . . . . . . . . . . . . . . . . . . . . . 33 11. A Definition for Samples of Single Bi-directional LSP
11.2. Metric Parameters . . . . . . . . . . . . . . . . . . . . 33 Setup Delay . . . . . . . . . . . . . . . . . . . . . . . . . 32
11.3. Metric Units . . . . . . . . . . . . . . . . . . . . . . . 33 11.1. Metric Name . . . . . . . . . . . . . . . . . . . . . . . 32
11.4. Definition . . . . . . . . . . . . . . . . . . . . . . . . 33 11.2. Metric Parameters . . . . . . . . . . . . . . . . . . . . 32
11.5. Discussion . . . . . . . . . . . . . . . . . . . . . . . . 34 11.3. Metric Units . . . . . . . . . . . . . . . . . . . . . . . 32
11.6. Methodologies . . . . . . . . . . . . . . . . . . . . . . 34 11.4. Definition . . . . . . . . . . . . . . . . . . . . . . . . 32
11.5. Discussion . . . . . . . . . . . . . . . . . . . . . . . . 33
11.6. Methodologies . . . . . . . . . . . . . . . . . . . . . . 33
11.7. Typical testing cases . . . . . . . . . . . . . . . . . . 34 11.7. Typical testing cases . . . . . . . . . . . . . . . . . . 34
11.7.1. With No LSP in the Network . . . . . . . . . . . . . . 34 11.7.1. With No LSP in the Network . . . . . . . . . . . . . . 34
11.7.2. With a Number of LSPs in the Network . . . . . . . . . 35 11.7.2. With a Number of LSPs in the Network . . . . . . . . . 34
12. A Definition for Samples of LSP Graceful Release Delay . . . . 36
12.1. Metric Name . . . . . . . . . . . . . . . . . . . . . . . 36 12. A Definition for Samples of Multiple Bi-directional LSPs
12.2. Metric Parameters . . . . . . . . . . . . . . . . . . . . 36 Setup Delay . . . . . . . . . . . . . . . . . . . . . . . . . 35
12.3. Metric Units . . . . . . . . . . . . . . . . . . . . . . . 36 12.1. Metric Name . . . . . . . . . . . . . . . . . . . . . . . 35
12.4. Definition . . . . . . . . . . . . . . . . . . . . . . . . 36 12.2. Metric Parameters . . . . . . . . . . . . . . . . . . . . 35
12.3. Metric Units . . . . . . . . . . . . . . . . . . . . . . . 35
12.4. Definition . . . . . . . . . . . . . . . . . . . . . . . . 35
12.5. Discussion . . . . . . . . . . . . . . . . . . . . . . . . 36 12.5. Discussion . . . . . . . . . . . . . . . . . . . . . . . . 36
12.6. Methodologies . . . . . . . . . . . . . . . . . . . . . . 37 12.6. Methodologies . . . . . . . . . . . . . . . . . . . . . . 36
13. Discussion for unsuccessful setup/release cases . . . . . . . 38 12.7. Typical testing cases . . . . . . . . . . . . . . . . . . 36
14. Some Statistics Definitions for Metrics to Report . . . . . . 39 12.7.1. With No LSP in the Network . . . . . . . . . . . . . . 37
14.1. The Minimum of Metric . . . . . . . . . . . . . . . . . . 39 12.7.2. With a Number of LSPs in the Network . . . . . . . . . 37
14.2. The Median of Metric . . . . . . . . . . . . . . . . . . . 39
14.3. The percentile of Metric . . . . . . . . . . . . . . . . . 39 13. A Definition for Samples of LSP Graceful Release Delay . . . . 38
14.4. The Failure Probability . . . . . . . . . . . . . . . . . 39 13.1. Metric Name . . . . . . . . . . . . . . . . . . . . . . . 38
15. Discussion . . . . . . . . . . . . . . . . . . . . . . . . . . 40 13.2. Metric Parameters . . . . . . . . . . . . . . . . . . . . 38
16. Security Considerations . . . . . . . . . . . . . . . . . . . 41 13.3. Metric Units . . . . . . . . . . . . . . . . . . . . . . . 38
17. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 42 13.4. Definition . . . . . . . . . . . . . . . . . . . . . . . . 38
18. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 43 13.5. Discussion . . . . . . . . . . . . . . . . . . . . . . . . 38
19. References . . . . . . . . . . . . . . . . . . . . . . . . . . 44 13.6. Methodologies . . . . . . . . . . . . . . . . . . . . . . 39
19.1. Normative References . . . . . . . . . . . . . . . . . . . 44
19.2. Informative References . . . . . . . . . . . . . . . . . . 44 14. Some Statistics Definitions for Metrics to Report . . . . . . 40
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 46 14.1. The Minimum of Metric . . . . . . . . . . . . . . . . . . 40
14.2. The Median of Metric . . . . . . . . . . . . . . . . . . . 40
14.3. The percentile of Metric . . . . . . . . . . . . . . . . . 40
14.4. Failure statistics of Metric . . . . . . . . . . . . . . . 40
14.4.1. Failure Count . . . . . . . . . . . . . . . . . . . . 41
14.4.2. Failure Ratio . . . . . . . . . . . . . . . . . . . . 41
15. Discussion . . . . . . . . . . . . . . . . . . . . . . . . . . 42
16. Security Considerations . . . . . . . . . . . . . . . . . . . 43
17. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 44
18. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 45
19. References . . . . . . . . . . . . . . . . . . . . . . . . . . 46
19.1. Normative References . . . . . . . . . . . . . . . . . . . 46
19.2. Informative References . . . . . . . . . . . . . . . . . . 46
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 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
physically diverse devices differs from each other drastically. physically diverse devices differs from each other drastically.
The introduction of a control plane into optical circuit switching The introduction of a control plane into optical circuit switching
networks automates the provisioning of connections and drastically networks automates the provisioning of connections and drastically
reduces connection provision delay. As more and more services and reduces connection provision delay. As more and more services and
applications are seeking to use GMPLS controled networks as their applications are seeking to use GMPLS controlled 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 LSP provisioning performance of GMPLS used to depict the dynamic LSP provisioning performance of GMPLS
networks, more specifically, performance of the signaling protocol. networks, more specifically, performance of the signaling protocol.
The metrics defined in this document can in the one hand be used to The metrics defined in this document can on the one hand be used to
depict the averaged performance of GMPLS implementations. On the depict the average performance of GMPLS implementations. On the
other hand, it can also be used in operational environments for other hand, it can also be used in operational environments for
carriers to monitor the control plane operation in realtime. For carriers to monitor the control plane operation in real-time. For
example, an new object can be added to GMPLS TE STD MIB [RFC4802] example, a new object can be added to GMPLS TE STD MIB [RFC4802] so
such that the current and past control plane performance can be that the current and past control plane performance can be monitored
monitored through network management systems. The extension of TE- through network management systems. The extension of TE-MIB to
MIB to support the metrics defined is out the scope of this document. support the defined metrics is outside the scope of this document.
2. Overview of Performance Metrics 2. Conventions Used in This Document
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [RFC2119].
3. Overview of Performance Metrics
In this memo, to depict the dynamic LSP provisioning performance of a In this memo, to depict the dynamic LSP provisioning performance of a
GMPLS network, we define 3 performance metrics: unidirectional LSP GMPLS network, we define 3 performance metrics: uni-directional LSP
setup delay, bidirectional LSP setup delay, and LSP graceful release setup delay, bi-directional LSP setup delay, and LSP graceful release
delay. The latency of the LSP setup/release signal is similar to the delay. The latency of the LSP setup/release signal is similar to the
Round-trip Delay in IP networks. So we refer the structures and Round-trip Delay in IP networks. So we refer the structures and
notions introduced and discussed in the IPPM Framework document, notions introduced and discussed in the IPPM Framework document,
[RFC2330] [RFC2679] [RFC2681]. The reader is assumed to be familiar [RFC2330] [RFC2679] [RFC2681]. The reader is assumed to be familiar
with the notions in those documents. with the notions in those documents.
3. A Singleton Definition for Single Unidirectional LSP Setup Delay Note that data path related metrics, for example, the time between
the reception of RESV message by ingress node and forward data path
becomes operational, are defined in another document
[I-D.sun-ccamp-dpm]. An implementation MAY choose whether to
implement metrics in the two documents together. However, it is
RECOMMENDED that both measurements are performed to complement each
other.
This part defines a metric for single unidirectional Label Switched 4. A Singleton Definition for Single Uni-directional LSP Setup Delay
This part defines a metric for single uni-directional Label Switched
Path setup delay across a GMPLS network. Path setup delay across a GMPLS network.
3.1. Motivation 4.1. Motivation
Single unidirectional Label Switched Path setup delay is useful for Single uni-directional Label Switched Path setup delay is useful for
several reasons: several reasons:
o Single LSP setup delay is an important metric that depicts the o Single LSP setup delay is an important metric that depicts the
provisioning performance of a GMPLS network. Longer LSP setup provisioning performance of a GMPLS network. Longer LSP setup
delay will incur higher overhead for the requesting application, delay will incur higher overhead for the requesting application,
especially when the LSP duration is comparable to the LSP setup especially when the LSP duration is comparable to the LSP setup
delay. delay.
o The minimum value of this metric provides an indication of the o The minimum value of this metric provides an indication of the
delay that will likely be experienced when the LSP traversed the delay that will likely be experienced when the LSP traversed the
shortest route at the lightest load in the control plane. As the shortest route at the lightest load in the control plane. As the
delay itself consists of several components, such as link delay itself consists of several components, such as link
propagation delay and nodal processing delay, this metric also propagation delay and nodal processing delay, this metric also
reflects the status of control plane. For example, for LSPs reflects the status of control plane. For example, for LSPs
traversing the same route, longer setup delays may suggest traversing the same route, longer setup delays may suggest
congestion in the control channel or high control element load. congestion in the control channel or high control element load.
For this reason, this metric is useful for testing and diagnostic For this reason, this metric is useful for testing and diagnostic
purposes. purposes.
o LSP setup delay variance has different impact on to applications. o LSP setup delay variance has different impact on applications.
Erratic variation in LSP setup delay makes it difficult to support Erratic variation in LSP setup delay makes it difficult to support
applications that has stringent setup delay requirement. applications that have stringent setup delay requirement.
The measurement of single unidirectional LSP setup delay instead of The measurement of single uni-directional LSP setup delay instead of
bidirectional LSP setup delay is motivated by the following factors: bi-directional LSP setup delay is motivated by the following factors:
o Some applications may only use unidirectional LSPs rather than o Some applications may use only uni-directional LSPs rather than
bidirectional ones. For example, content delivery services in bi-directional ones. For example, content delivery services with
multicast method (IPTV) only use unidirectional LSPs. multicasting may use only uni-directional LSPs.
3.2. Metric Name 4.2. Metric Name
single unidirectional LSP setup delay single uni-directional LSP setup delay
3.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 T, a time when the setup is attempted o T, a time when the setup is attempted
3.4. Metric Units 4.4. Metric Units
The value of single unidirectional LSP setup delay is either a real The value of single uni-directional LSP setup delay is either a real
number, or an undefined number of milliseconds. number, or an undefined number of milliseconds.
3.5. Definition 4.5. Definition
The single unidirectional LSP setup delay from the ingress node ID0 The single uni-directional LSP setup delay from the ingress node ID0
to the egress node ID1 [RFC3945] at T is dT means that ingress node to the egress node ID1 [RFC3945] at T is dT means that ingress node
ID0 sends the first bit of a PATH message packet to egress node ID1 ID0 sends the first bit of a PATH message packet to egress node ID1
at wire-time T, and that the ingress node ID0 received the last bit at wire-time T, and that the ingress node ID0 received the last bit
of responding RESV message packet from the egress node ID1 at wire- of responding RESV message packet from the egress node ID1 at wire-
time T+dT in the unidirectional LSP setup case. time T+dT in the uni-directional LSP setup case.
The single unidirectional LSP setup delay from the ingress node ID0 The single uni-directional LSP setup delay from the ingress node ID0
to the egress node ID1 at T is undefined, means that ingress node ID0 to the egress node ID1 at T is undefined, means that ingress node ID0
sends the first bit of PATH message packet to egress node ID1 at sends the first bit of PATH message packet to egress node ID1 at
wire-time T and that ingress node ID0 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 The undefined value of this metric indicates an event of Single Uni-
directional LSP Setup Failure, and would be used to report a count or
an percentage of Single Uni-directional LSP Setup failures. See
section Section 14.4 for definitions of LSP setup/release failures.
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 unidirectional LSP setup delay at time T depends o The accuracy of uni-directional 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. uni-directional 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 MAY 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 micro mirrors. This physical
physical motion may take several milliseconds. But the common motion may take several milliseconds. But the common electronic
electronic switches finish the nodal process within several switches can finish the nodal processing within several
microseconds. So the unidirectional LSP setup delay varies microseconds. So the uni-directional LSP setup delay varies
drastically from a network to another. In practice, the upper drastically from one network to another. In practice, the upper
bound should be chose carefully. bound should be chosen carefully and the value MUST be reported.
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 receives the corresponding RESV message, uni-directional LSP
delay is deemed to be undefined. setup delay MUST be set to 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 receives PathErr message, uni-directional LSP setup delay MUST be
deemed to be undefined. There are many possible reasons for this set to undefined. There are many possible reasons for this case.
case. For example, the PATH message has invalid parameters or the For example, the PATH message has invalid parameters or the
network has not enough resource to set up the requested LSP, etc. network does not have enough resource to set up the requested LSP,
etc.
3.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 LSP. requested LSP.
o At the ingress node, form the PATH message according to the LSP o At the ingress node, form the PATH message according to the LSP
requirements. A timestamp (T1) may be stored locally in the requirements. A timestamp (T1) may be stored locally on the
ingress node when the PATH message packet is sent towards the ingress node when the PATH message packet is sent towards the
egress node. egress node.
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 uni-directional 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 uni-directional LSP setup delay is
deemed to be undefined. Note that the 'reasonable' threshold is a deemed to be undefined. Note that the 'reasonable' threshold 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 uni-
unidirectional LSP setup delay is deemed to be undefined. directional LSP setup delay is deemed to be undefined.
4. A Singleton Definition for multiple Unidirectional LSP Setup Delay 5. A Singleton Definition for multiple Uni-directional LSP Setup Delay
This part defines a metric for multiple unidirectional Label Switched This part defines a metric for multiple uni-directional Label
Paths setup delay across a GMPLS network. Switched Paths setup delay across a GMPLS network.
4.1. Motivation 5.1. Motivation
multiple unidirectional Label Switched Paths setup delay is useful Multiple uni-directional Label Switched Paths setup delay is useful
for several reasons: for several reasons:
o Upon traffic interruption caused by network failure or network o Upon traffic interruption caused by network failure or network
upgrade, carriers may require a large number of LSPs be set up upgrade, carriers may require a large number of LSPs be set up
during a short time period during a short time period.
o The time needed to setup a large number of LSPs during a short o The time needed to setup a large number of LSPs during a short
time period can not be deduced by single LSP setup delay time period can not be deduced by single LSP setup delay.
4.2. Metric Name 5.2. Metric Name
multiple unidirectional LSPs setup delay Multiple uni-directional LSPs setup delay
4.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 Lambda_m, 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 when the first setup is attempted o T, a time when the first setup is attempted
4.4. Metric Units 5.4. Metric Units
The value of multiple unidirectional LSPs setup delay is either a The value of multiple uni-directional LSPs setup delay is either a
real number, or an undefined number of milliseconds. real number, or an undefined number of milliseconds.
4.5. Definition 5.5. Definition
Given Lambda_m and X, the multiple unidirectional LSPs setup delay Given Lambda_m and X, the multiple uni-directional LSPs setup delay
from 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 ID0 sends the first bit of the first PATH message o ingress node ID0 sends the first bit of the first PATH message
packet to egress node ID1 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 o all subsequent (X-1) PATH messages are sent according to the
specified poisson process with arrival rate Lambda_m specified Poisson process with arrival rate Lambda_m
o ingress node ID0 receives all corresponding RESV message packets o ingress node ID0 receives all corresponding RESV message packets
from egress node ID1, and from egress node ID1, and
o ingress node ID0 receives the last RESV message packet at wire- o ingress node ID0 receives the last RESV message packet at wire-
time T+dT time T+dT
The multiple unidirectional LSPs setup delay at T is undefined, means The multiple uni-directional LSPs setup delay at T is undefined,
that ingress node ID0 sends all the PATH messages toward the egress means that ingress node ID0 sends all the PATH messages toward the
node ID1 and the first bit of the first PATH message packet is sent egress node ID1 and the first bit of the first PATH message packet is
at wire-time T and that ingress node ID0 does not receive the one or sent at wire-time T and that ingress node ID0 does not receive the
more of the corresponding RESV messages within a reasonable period of one or more of the corresponding RESV messages within a reasonable
time. period of time.
4.6. Discussion The undefined value of this metric indicates an event of Multiple
Uni-directional LSP Setup Failure, and would be used to report a
count or an percentage of Multiple Uni-directional LSP Setup
failures. See section Section 14.4 for definitions of LSP setup/
release failures.
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 multiple unidirectional LSPs setup delay at time T o The accuracy of multiple uni-directional LSPs setup delay at time
depends on the clock resolution in the ingress node; but T 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 uni-directional 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 MAY 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 micro mirrors. This physical
physical motion may take several milliseconds. But the common motion may take several milliseconds. But electronic switches can
electronic switches finish the nodal process within several finish the nodal processing within several microseconds. So the
microseconds. So the multiple unidirectional LSP setup delay multiple uni-directional LSP setup delay varies drastically from
varies drastically from a network to another. In practice, the one network to another. In practice, the upper bound should be
upper bound should be chose carefully. chosen carefully and the value MUST be reported.
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, multiple unidirectional LSP setup delay is deemed to be messages, multiple uni-directional LSP setup delay MUST be set to
undefined. 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 uni-directional
LSPs setup delay is also deemed to be undefined. There are many LSPs setup delay MUST be set to 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
messages 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_m should be o The arrival rate of the Poisson process Lambda_m should be chosen
carefully chosen such that in the one hand the control plane is carefully such that in the one hand the control plane is not
not overburdened.On the other hand, the arrival rate should also overburdened. On the other hand, the arrival rate is large enough
be large enough to meet the requirements of applications or to meet the requirements of applications or services.
services.
4.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 LSPs. requested LSPs.
o At the ingress node, form the PATH messages according to the LSPs' o At the ingress node, form the PATH messages according to the LSPs'
requirements. requirements.
o At the ingress node, select the time for each of the PATH messages o At the ingress node, select the time for each of the PATH messages
according to the specified poisson process. according to the specified Poisson process.
o At the ingress node, sends out the PATH messages according to the o At the ingress node, send out the PATH messages according to the
selected time. selected time.
o Store a timestamp (T1) locally in the ingress node when the first o Store a timestamp (T1) locally on the ingress node when the first
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 arrive 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 uni-directional 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 fail to arrive
within a reasonable period of time, the multiple unidirectional within a reasonable period of time, the multiple uni-directional
LSPs setup delay is deemed to be undefined. Note that the LSPs setup delay is deemed to be undefined. Note that the
'reasonable' threshold is a parameter of the methodology. 'reasonable' threshold is a parameter of the methodology.
o If one of the corresponding response message is PathErr, the o If one or more of the corresponding response messages are PathErr,
multiple unidirectional LSPs setup delay is deemed to be the multiple uni-directional LSPs setup delay is deemed to be
undefined. undefined.
5. A Singleton Definition for Single Bidirectional LSP Setup Delay 6. A Singleton Definition for Single Bi-directional 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 bi-
bidirectional LSP setup delay across a GMPLS network. directional LSP setup delay across a GMPLS network.
5.1. Motivation 6.1. Motivation
Single bidirectional Label Switched Path setup delay is useful for Single bi-directional Label Switched Path setup delay is useful for
several reasons: several reasons:
o LSP setup delay is an important metric that depicts the o LSP setup delay is an important metric that depicts the
provisioning performance of a GMPLS network. Longer LSP setup provisioning performance of a GMPLS network. Longer LSP setup
delay will incur higher overhead for the requesting application, delay will incur higher overhead for the requesting application,
especially when the LSP duration is comparable to the LSP setup especially when the LSP duration is comparable to the LSP setup
delay. Thus, measuring the setup delay is important for delay. Thus, measuring the setup delay is important for
applications scheduling. application scheduling.
o The minimum value of this metric provides an indication of the o The minimum value of this metric provides an indication of the
delay that will likely be experienced when the LSP traversed the delay that will likely be experienced when the LSP traversed the
shortest route at the lightest load in the control plane. As the shortest route at the lightest load in the control plane. As the
delay itself consists of several components, such as link delay itself consists of several components, such as link
propagation delay and nodal processing delay, this metric also propagation delay and nodal processing delay, this metric also
reflects the status of control plane. For example, for LSPs reflects the status of control plane. For example, for LSPs
traversing the same route, longer setup delays may suggest traversing the same route, longer setup delays may suggest
congestion in the control channel or high control element load. congestion in the control channel or high control element load.
For this reason, this metric is useful for testing and diagnostic For this reason, this metric is useful for testing and diagnostic
purposes. purposes.
o LSP setup delay variance has different impact on to applications. o LSP setup delay variance has different impact on applications.
Erratic variation in LSP setup delay makes it difficult to support Erratic variation in LSP setup delay makes it difficult to support
applications that has stringent setup delay requirement. applications that have stringent setup delay requirement.
The measurement of single bidirectional LSP setup delay instead of The measurement of single bi-directional LSP setup delay instead of
unidirectional LSP setup delay is motivated by the following factors: uni-directional LSP setup delay is motivated by the following
factors:
o Bidirectional LSPs are seen as a requirement for many GMPLS o Bi-directional LSPs are seen as a requirement for many GMPLS
networks. Its provisioning performance is important to networks. Its provisioning performance is important to
applications that generates bi-directional traffic. applications that generate bi-directional traffic.
5.2. Metric Name 6.2. Metric Name
Single bidirectional LSP setup delay Single bi-directional LSP setup delay
6.3. Metric Parameters
5.3. Metric Parameters
o ID0, the ingress LSR ID o ID0, the ingress LSR ID
o ID1, the egress LSR ID o ID1, the egress LSR ID
o T, a time when the setup is attempted o T, a time when the setup is attempted
5.4. Metric Units 6.4. Metric Units
The value of single bidirectional LSP setup delay is either a real The value of single bi-directional LSP setup delay is either a real
number, or an undefined number of milliseconds. number, or an undefined number of milliseconds.
5.5. Definition 6.5. Definition
For a real number dT, the single bidirectional LSP setup delay from For a real number dT, the single bi-directional LSP setup delay from
ingress node ID0 to egress node ID1 at T is dT, means that ingress ingress node ID0 to egress node ID1 at T is dT, means that ingress
node ID0 sends out the first bit of a PATH message including an node ID0 sends out the first bit of a PATH message including an
Upstream Label [RFC3473] heading for egress node ID1 at wire-time T, Upstream Label [RFC3473] heading for egress node ID1 at wire-time T,
egress node ID1 receives that packet, then immediately sends a RESV egress node ID1 receives that packet, then immediately sends a RESV
message packet back to ingress node ID0, and that ingress node ID0 message packet back to ingress node ID0, and that ingress node ID0
receives the last bit of that packet at wire-time T+dT. receives the last bit of the RESV message packet at wire-time T+dT.
The single bidirectional LSP setup delay from ingress node ID0 to The single bi-directional LSP setup delay from ingress node ID0 to
egress node ID1 at T is undefined, means that ingress node ID0 sends egress node ID1 at T is undefined, means that ingress node ID0 sends
the first bit of PATH message to egress node ID1 at wire-time T and the first bit of PATH message to egress node ID1 at wire-time T and
that ingress node ID0 does not receive that response packet within a that ingress node ID0 does not receive that response packet within a
reasonable period of time. reasonable period of time.
5.6. Discussion The undefined value of this metric indicates an event of Single Bi-
directional LSP Setup Failure, and would be used to report a count or
an percentage of Single Bi-directional LSP Setup failures. See
section Section 14.4 for definitions of LSP setup/release failures.
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 single bidirectional LSP setup delay depends on o The accuracy of single bi-directional 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 bi-directional 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 MAY 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 micro mirrors. This physical
physical motion may take several milliseconds. But the common motion may take several milliseconds. But electronic switches can
electronic switches finish the nodal process within several finish the nodal processing within several microseconds. So the
microseconds. So the bidirectional LSP setup delay varies bi-directional LSP setup delay varies drastically from one network
drastically from a network to another. In the process of to another. In the process of bi-directional LSP setup, if the
bidirectional LSP setup, if the downstream node overrides the downstream node overrides the label suggested by the upstream
label suggested by the upstream node, the setup delay will also node, the setup delay may also increase. Thus, in practice, the
increase obviously. Thus, in practice, the upper bound, should be upper bound should be chosen carefully and the value MUST be
chosen carefully. reported.
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 bi-
bidirectional LSP setup delay is deemed to be undefined. directional LSP setup delay MUST be set to 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 bi-directional LSP setup
is also deemed to be undefined. There are many possible reasons delay MUST be set to 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 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 LSP. requested LSP.
o At the ingress node, form the PATH message (including the Upstream o At the ingress node, form the PATH message (including the Upstream
Label or suggested label) according to the LSP requirements. A Label or suggested label) according to the LSP requirements. A
timestamp (T1) may be stored locally in the ingress node when the timestamp (T1) may be stored locally on the ingress node when the
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 bi-directional 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 bi-directional LSP setup
delay is deemed to be undefined. Note that the 'reasonable' delay is deemed to be undefined. Note that 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 bi-
bidirectional LSP setup delay is deemed to be undefined. directional LSP setup delay is deemed to be undefined.
6. A Singleton Definition for multiple Bidirectional LSPs Setup Delay 7. A Singleton Definition for multiple Bi-directional LSPs Setup Delay
This part defines a metric for multiple bidirectional LSPs setup This part defines a metric for multiple bi-directional LSPs setup
delay across a GMPLS network. delay across a GMPLS network.
6.1. Motivation 7.1. Motivation
multiple Bidirectional LSPs setup delay is useful for several multiple bi-directional LSPs setup delay is useful for several
reasons: reasons:
o Upon traffic interruption caused by network failure or network o Upon traffic interruption caused by network failure or network
upgrade, carriers may require a large number of LSPs be set up upgrade, carriers may require a large number of LSPs be set up
during a short time period during a short time period
o The time needed to setup a large number of LSPs during a short o The time needed to setup a large number of LSPs during a short
time period can not be deduced by single LSP setup delay time period can not be deduced by single LSP setup delay
6.2. Metric Name 7.2. Metric Name
Multiple bidirectional LSPs setup delay Multiple bi-directional LSPs setup delay
6.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 Lambda_m, 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 when the first setup is attempted o T, a time when the first setup is attempted
6.4. Metric Units 7.4. Metric Units
The value of multiple bidirectional LSPs setup delay is either a real The value of multiple bi-directional LSPs setup delay is either a
number, or an undefined number of milliseconds. real number, or an undefined number of milliseconds.
6.5. Definition 7.5. Definition
Given Lambda_m and X, for a real number dT, the multiple Given Lambda_m and X, for a real number dT, the multiple bi-
bidirectional LSPs setup delay from ingress node to egress node at T directional LSPs setup delay from ingress node to egress node at T is
is dT, means that: dT, means that:
o ingress node ID0 sends the first bit of the first PATH message o ingress node ID0 sends the first bit of the first PATH message
heading for egress node ID1 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_m specified Poisson process with arrival rate Lambda_m
o ingress node ID1 receives all corresponding RESV message packets o ingress node ID1 receives all corresponding RESV message packets
from egress node ID1, and from egress node ID1, and
o ingress node ID0 receives the last RESV message packets at wire- o ingress node ID0 receives the last RESV message packet at wire-
time T+dT time T+dT
The multiple bidirectional LSPs setup delay from ingress node to The multiple bi-directional LSPs setup delay from ingress node to
egress node at T is undefined, means that ingress node sends all the egress node at T is undefined, means that ingress node sends all the
PATH messages to egress node and that the ingress node fails to PATH messages to egress node and that the ingress node fails to
receive one or more of the response messages within a reasonable receive one or more of the response RESV messages within a reasonable
period of time. period of time.
6.6. Discussion The undefined value of this metric indicates an event of Multiple Bi-
directional LSP Setup Failure, and would be used to report a count or
an percentage of Multiple Bi-directional LSP Setup failures. See
section Section 14.4 for definitions of LSP setup/release failures.
7.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 bi-directional LSPs setup delay depends
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 bi-
bidirectional LSP setup uses two-way signaling. directional 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 MAY 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 micro mirrors. This physical
physical motion may take several milliseconds. But the common motion may take several milliseconds. But electronic switches can
electronic switches finish the nodal process within several finish the nodal process within several microseconds. So the
microseconds. So the multiple bidirectional LSPs setup delay multiple bi-directional LSPs setup delay varies drastically from a
varies drastically from a network to another. In the process of network to another. In the process of multiple bi-directional
multiple bidirectional LSPs setup, if the downstream node LSPs setup, if the downstream node overrides the label suggested
overrides the label suggested by the upstream node, the setup by the upstream node, the setup delay may also increase. Thus, in
delay will also increase obviously. Thus, in practice, the upper practice, the upper bound should be chosen carefully and the value
bound should be chosen carefully. MUST be reported.
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 receives all the corresponding RESV messages, the
multiple bidirectional LSPs setup delay is deemed to be undefined. multiple bi-directional LSPs setup delay MUST be set to 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 receives one or more responding PathErr messages, the
multiple bidirectional LSPs setup delay is also deemed to be multiple bi-directional LSPs setup delay MUST be set to undefined.
undefined. There are many possible reasons for this case. For There are many possible reasons for this case. For example, one
example, one or more of the PATH messages have invalid parameters or more of the PATH messages have invalid parameters or the
or the network has not enough resource to set up the requested network has not enough resource to set up the requested LSPs.
LSPs.
o The arrival rate of the poisson process Lambda_m should be o The arrival rate of the Poisson process Lambda_m should be
carefully chosen such that in the one hand the control plane is carefully chosen such that on the one hand the control plane is
not overburdened.On the other hand, the arrival rate should also not overburdened. On the other hand, the arrival rate is large
be large enough to meet the requirements of applications or enough to meet the requirements of applications or services.
services.
6.7. Methodologies 7.7. Methodologies
Generally the methodology would proceed as follows: Generally the methodology would proceed as follows:
o Make sure that the network has enough resource to set up the o Make sure that the network has enough resource to set up the
requested LSPs. requested LSPs.
o At the ingress node, form the PATH messages (including the o At the ingress node, form the PATH messages (including the
Upstream Label or suggested label) according to the LSPs' Upstream Label or suggested label) according to the LSPs'
requirements. requirements.
o At the ingress node, select the time for each of the PATH messages o At the ingress node, select the time for each of the PATH messages
according to the specified poisson process. according to the specified Poisson process.
o At the ingress node, sends out the PATH messages according to the o At the ingress node, send out the PATH messages according to the
selected time. selected time.
o Store a timestamp (T1) locally in the ingress node when the first o Store a timestamp (T1) locally in the ingress node when the first
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 arrive 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 bi-directional 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 fail to arrive
within a reasonable period of time, the multiple bidirectional within a reasonable period of time, the multiple bi-directional
LSPs setup delay is deemed to be undefined. Note that the LSPs setup delay is deemed to be undefined. Note that the
'reasonable' threshold is a parameter of the methodology. 'reasonable' threshold is a parameter of the methodology.
o If one or more of the corresponding response messages is PathErr, o If one or more of the corresponding response messages are PathErr,
the multiple bidirectional LSPs setup delay is deemed to be the multiple bi-directional LSPs setup delay is deemed to be
undefined. undefined.
7. A Singleton Definition for LSP Graceful Release Delay 8. 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. This document does
version has not taken forceful LSP release procedure into account. not take forceful LSP release procedure into account.
7.1. Motivation 8.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 release 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 preferred in a GMPLS
controled network, particularly the optical networks. Since it controlled 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 8.2. Metric Name
LSP graceful release delay LSP graceful release delay
7.3. Metric Parameters 8.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 when the release is attemped o T, a time when the release is attempted
7.4. Metric Units 8.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 number of milliseconds. an undefined number of milliseconds.
7.5. Definition 8.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 the egress
node. The two procedures are depicted in the [RFC3473]. We define node. The two procedures are depicted in [RFC3473]. We define the
the graceful LSP release delay for these two procedures separately. 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 ID0 to egress node ID1 at T is dT, means that ingress node ID0 node ID0 to egress node ID1 at T is dT, means that ingress node ID0
sends the first bit of a PATH message including Admin Status Object sends the first bit of a PATH message including Admin Status Object
with setting the Reflect (R) and Delete (D) bits to egress node at with the Reflect (R) and Delete (D) bits set to the egress node at
wire-time T, that egress node ID1 receives that packet, then wire-time T, that the egress node ID1 receives that packet, then
immediately sends a RESV message including Admin Status Object with immediately sends a RESV message including Admin Status Object with
the Delete (D) bit set back to ingress node. The ingress node ID0 the Delete (D) bit set back to the ingress node. The ingress node
sends out PathTear downstream to remove the LSP, and egress node ID1 ID0 sends out PathTear downstream to remove the LSP, and egress node
receives the last bit of PathTear packet at wire-time T+dT. ID1 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 the Reflect (R) and Delete (D) bits set, the
egress node ID1 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 ID0 to egress node The LSP graceful release delay from ingress node ID0 to egress node
ID1 at T is undefined, means that ingress node ID0 sends the first ID1 at T is undefined, means that ingress node ID0 sends the first
bit of PATH message to egress node ID1 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, or
node does not receive that RESV packet, or) the egress node ID1 does ingress node does not receive that RESV packet, and) the egress node
not receive the PathTear within a reasonable period of time. ID1 does not receive the PathTear within a reasonable period of time.
The LSP graceful release delay from egress node ID1 to ingress node The LSP graceful release delay from egress node ID1 to ingress node
ID0 at T is dT, means that egress node ID1 sends the first bit of a ID0 at T is dT, means that egress node ID1 sends the first bit of a
RESV message including Admin Status Object with setting the Reflect RESV message including Admin Status Object with setting the Reflect
(R) and Delete (D) bits to ingress node at wire-time T. The ingress (R) and Delete (D) bits to ingress node at wire-time T. The ingress
node ID0 sends out PathTear downstream to remove the LSP, and egress node ID0 sends out PathTear downstream to remove the LSP, and egress
node ID1 receives the 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 ID1 to ingress node The LSP graceful release delay from egress node ID1 to ingress node
ID0 at T is undefined, means that egress node ID1 sends the first bit ID0 at T is undefined, means that egress node ID1 sends the first bit
of RESV message including Admin Status Object with setting the of RESV message including Admin Status Object with setting the
Reflect (R) and Delete (D) bits to ingress node ID0 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, or
ingress node does not send PathTear message packet in response or) ingress node does not send PathTear message packet in response, and)
the egress node ID1 does not receive the PathTear within a reasonable the egress node ID1 does not receive the PathTear within a reasonable
period of time. period of time.
7.6. Discussion The undefined value of this metric indicates an event of LSP Graceful
Release Failure, and would be used to report a count or an percentage
of LSP Graceful Release failures. See section Section 14.4 for
definitions of LSP setup/release failures.
8.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 MAY be used. But the upper bound should be
chosen carefully in practice; chosen carefully in practice and the value MUST be reported;
o In the first circumstance, if ingress node sends out PATH message
including Admin Status Object with the Reflect (R) and Delete (D)
bits set to initiate LSP graceful release, but never receive
corresponding RESV message, LSP graceful release delay is deemed
to be undefined. In the second circumstance, if egress node sends
out RESV message including Admin Status Object with the Reflect
(R) and Delete (D) bits set to initiate LSP graceful release, but
never receive corresponding PathTear message, LSP graceful release
delay is deemed to be undefined;
7.7. Methodologies o In the first circumstance, if the ingress node sends out PATH
message including Admin Status Object with the Reflect (R) and
Delete (D) bits set to initiate LSP graceful release, but the
egress node never receives the corresponding PathTear message, LSP
graceful release delay MUST be set to undefined.
o In the second circumstance, if the egress node sends out the RESV
message including Admin Status Object with the Reflect (R) and
Delete (D) bits set to initiate LSP graceful release, but never
receives the corresponding PathTear message, LSP graceful release
delay MUST be set to undefined.
8.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 ingress 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 on 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. 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 The egress node takes a timestamp (T2) once it receives the last
of the PathTear message. The LSP graceful release delay is then bit of the PathTear message. The LSP graceful release delay is
(T2-T1). then (T2-T1).
o If the ingress node sends the PATH message downstream, but the o If the ingress node sends the PATH message downstream, but the
egress node fails to receive the PathTear message within a egress node fails to receive the PathTear message within a
reasonable period of time, the LSP graceful release delay is reasonable period of time, the LSP graceful release delay is
deemed to be undefined. Note that the 'reasonable' threshold is a deemed to be undefined. Note that the 'reasonable' threshold is a
parameter of the methodology. 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 on 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).
o If the ingress node sends the PATH message downstream, but the o If the egress node sends the RESV message upstream, but it fails
egress node fails to receive the PathTear message within a to receive the PathTear message within a reasonable period of
reasonable period of time, the LSP graceful release delay is time, the LSP graceful release delay is deemed to be undefined.
deemed to be undefined. Note that the 'reasonable' threshold is a Note that the 'reasonable' threshold is a parameter of the
parameter of the methodology. methodology.
8. A Definition for Samples of Single Unidirectional LSP Setup Delay 9. A Definition for Samples of Single Uni-directional LSP Setup Delay
In Section 3, we define the singleton metric of Single unidirectional In Section 4, we have defined the singleton metric of Single uni-
LSP setup delay. Now we define how to get one particular sample of directional LSP setup delay. Now we define how to get one particular
Single unidirectional LSP setup delay. Sampling is to select a sample of Single uni-directional LSP setup delay. Sampling is to
particular potion of singleton values of the given parameters. Like select a particular potion of singleton values of the given
in [RFC2330], we use Poisson sampling as an example. parameters. Like in [RFC2330], we use Poisson sampling as an
example.
8.1. Metric Name 9.1. Metric Name
Single unidirectional LSP setup delay sample Single uni-directional LSP setup delay sample
8.2. Metric Parameters 9.2. 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 T0, a time o T0, a time
o Tf, a time o Tf, a time
o Lambda, a rate in the reciprocal seconds o Lambda, a rate in the reciprocal milliseconds
o Th, LSP holding time o Th, LSP holding time
o Td, the maximum waiting time for successful setup o Td, the maximum waiting time for successful setup
8.3. Metric Units 9.3. Metric Units
A sequence of pairs; the elements of each pair are: A sequence of pairs; the elements of each pair are:
o T, a time when setup is attemped o T, a time when setup is attempted
o dT, either a real number or an undefined number of milli-seconds. o dT, either a real number or an undefined number of milliseconds.
8.4. Definition 9.4. Definition
Given T0, Tf, and lambda, compute a pseudo-random Poisson process Given T0, Tf, and lambda, compute a pseudo-random Poisson process
beginning at or before T0, with average arrival rate lambda, and 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 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 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 in this process, we obtain the value of uni-directional LSP setup
delay sample at this time. The value of the sample is the sequence 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 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 no such pairs, the sequence is of length zero and the sample is said
to be empty. to be empty.
8.5. Discussion 9.5. Discussion
The parameters lambda should be carefully chosen. If the rate is too The parameter lambda should be carefully chosen. If the rate is too
high, too frequent LSP setup/release procedure results in high high, too frequent LSP setup/release procedure will result in high
overhead in the control plane. In turn, the high overhead will overhead in the control plane. In turn, the high overhead will
increase unidirectional LSP setup delay. On the other hand if the increase uni-directional LSP setup delay. On the other hand if the
rate is too low, the sample could not completely reflect the dynamic rate is too low, the sample could not completely reflect the dynamic
provisioning performance of the GMPLS network. The appropriate provisioning performance of the GMPLS network. The appropriate
lambda value depends on the given network. lambda value depends on the given network.
The parameters Td should be carefully chosen. Different switching The parameters Td should be carefully chosen. Different switching
technologies may vary significantly in performing a cross-connect technologies may vary significantly in performing a cross-connect
operation. At the same time, the time needed in setting up an LSP operation. At the same time, the time needed in setting up an LSP
under different traffic may also vary significantly. under different traffic may also vary significantly.
In the case of active measurement, the parameters Th should be In the case of active measurement, the parameters Th should be
carefully chosen. The combination of lambda and Th reflects the load carefully chosen. The combination of lambda and Th reflects the load
of the network. The selection of Th should take into account that of the network. The selection of Th should take into account that
the network has sufficient resource to perform subsequent tests. The the network has sufficient resource to perform subsequent tests. The
value of Th may be constant during one sampling process for value of Th MAY be constant during one sampling process for
simplicity considerations. simplicity considerations.
Note that for online or passive measurements, the holding time of an Note that for online or passive measurements, the arrival rate and
LSP is determined by actual traffic, hence in this case Th is not an LSP holding time are determined by actual traffic, hence in this case
input parameter. Lambda and Th are not input parameters.
8.6. Methodologies 9.6. Methodologies
o The selection of specific times, using the specified Poisson o Select the times using the specified Poisson arrival process, and
arrival process, and
o Set up the LSP as the methodology for the singleton unidirectional o Set up the LSP as the methodology for the singleton uni-
LSP setup delay, and obtain the value of unidirectional LSP setup directional LSP setup delay, and obtain the value of uni-
delay directional LSP setup delay
o Release the LSP after Th, and wait for the next Poisson arrival o Release the LSP after Th, and wait for the next Poisson arrival
process event
Note that: it is possible that before the previous LSP release Note that: it is possible that before the previous LSP release
procedure completes, the next Poisson arrival process has arrived and procedure completes, the next Poisson arrival event arrives and the
the LSP setup procedure is initiated. If there is resource LSP setup procedure is initiated. If there is resource contention
contention between the two LSPs, the LSP setup may fail. between the two LSPs, the LSP setup may fail. Ways to avoid such
contention are outside the scope of this document.
8.7. Typical testing cases 9.7. Typical testing cases
8.7.1. With No LSP in the Network 9.7.1. With no LSP in the Network
8.7.1.1. Motivation 9.7.1.1. Motivation
Single unidirectional LSP setup delay with no LSP in the network is Single uni-directional 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.7.1.2. Methodologies 9.7.1.2. Methodologies
Make sure that there is no LSP in the network, and proceed with the Make sure that there is no LSP in the network, and proceed with the
methodologies described in Section 8.6. methodologies described in Section 9.6.
8.7.2. With a Number of LSPs in the Network 9.7.2. With a number of LSPs in the Network
8.7.2.1. Motivation 9.7.2.1. Motivation
Single unidirectional LSP setup delay with a number of LSPs in the Single uni-directional 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 considerable load. This delay may 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.7.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 with the methodologies described in a stable state, then proceed with the methodologies described in
Section 8.6. Section 9.6.
9. A Definition for Samples of Multiple Unidirectional LSPs Setup Delay 10. A Definition for Samples of Multiple Uni-directional LSPs Setup
Delay
In Section 4, we define the singleton metric of multiple In Section 5, we have defined the singleton metric of multiple uni-
unidirectional LSPs setup delay. Now we define how to get one directional LSPs setup delay. Now we define how to get one
particular sample of multiple unidirectional LSP setup delay. particular sample of multiple uni-directional LSP setup delay.
Sampling is to select a particular potion of singleton values of the Sampling is to select a particular potion of singleton values of the
given parameters. Like in [RFC2330], we use Poisson sampling as an given parameters. Like in [RFC2330], we use Poisson sampling as an
example. example.
9.1. Metric Name 10.1. Metric Name
Multiple unidirectional LSPs setup delay sample Multiple uni-directional LSPs setup delay sample
9.2. Metric Parameters 10.2. 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 T0, a time o T0, a time
o Tf, a time o Tf, a time
o Lambda_m, a rate in the reciprocal seconds o Lambda_m, a rate in the reciprocal milliseconds
o Lambda, a rate in the reciprocal seconds o Lambda, a rate in the reciprocal milliseconds
o X, the number of LSPs to setup o X, the number of LSPs to setup
o Td, the maximum waiting time for successful multiple o Th, LSP holding time
unidirectional LSPs setup
9.3. Metric Units o Td, the maximum waiting time for successful multiple uni-
directional LSPs setup
10.3. Metric Units
A sequence of pairs; the elements of each pair are: A sequence of pairs; the elements of each pair are:
o T, a time when the first setup is attemped o T, a time when the first setup is attempted
o dT, either a real number or an undefined number of milli-seconds. o dT, either a real number or an undefined number of milliseconds.
9.4. Definition 10.4. Definition
Given T0, Tf, and lambda, compute a pseudo-random Poisson process Given T0, Tf, and lambda, compute a pseudo-random Poisson process
beginning at or before T0, with average arrival rate lambda, and 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 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 and less than or equal to Tf are then selected. At each of the time
in this process, we obtain the value of multiple unidirectional LSP in this process, we obtain the value of multiple uni-directional LSP
setup delay sample at this time. The value of the sample is the setup delay sample at this time. The value of the sample is the
sequence made up of the resulting <time, setup delay> pairs. If sequence made up of the resulting <time, setup delay> pairs. If
there are no such pairs, the sequence is of length zero and the there are no such pairs, the sequence is of length zero and the
sample is said to be empty. sample is said to be empty.
9.5. Discussion 10.5. Discussion
The parameter lambda is used as arrival rate of "bacth unidirectional The parameter lambda is used as arrival rate of "bacth uni-
LSPs setup" operation. It regulates the interval in between each directional LSPs setup" operation. It regulates the interval in
batch operatoin. The parameter lambda_m is used within each batch between each batch operation. The parameter lambda_m is used within
operation, as described in Section 4. each batch operation, as described in Section 5.
The parameters lambda and lambda_m should be carefully chosen. If The parameters lambda and lambda_m should be carefully chosen. If
the rate is too high, too frequent LSP setup/release procedure the rate is too high, too frequent LSP setup/release procedure will
results in high overhead in the control plane. In turn, the high result in high overhead in the control plane. In turn, the high
overhead will increase unidirectional LSP setup delay. On the other overhead will increase uni-directional LSP setup delay. On the other
hand if the rate is too low, the sample could not completely reflect hand if the rate is too low, the sample could not completely reflect
the dynamic provisioning performance of the GMPLS network. The the dynamic provisioning performance of the GMPLS network. The
appropriate lambda and lambda_m value depends on the given network. appropriate lambda and lambda_m value depends on the given network.
The parameters Td should be carefully chosen. Different switching The parameters Td should be carefully chosen. Different switching
technologies may vary significantly in performing a cross-connect technologies may vary significantly in performing a cross-connect
operation. At the same time, the time needed in setting up an LSP operation. At the same time, the time needed in setting up an LSP
under different traffic may also vary significantly. under different traffic may also vary significantly.
9.6. Methodologies 10.6. Methodologies
o The selection of specific times, using the specified Poisson o Select the times using the specified Poisson arrival process, and
arrival process, and
o Set up the LSP as the methodology for the singleton multiple o Set up the LSP as the methodology for the singleton multiple uni-
unidirectional LSPs setup delay, and obtain the value of multiple directional LSPs setup delay, and obtain the value of multiple
unidirectional LSPs setup delay uni-directional LSPs setup delay
o Release the LSP after Th, and wait for the next Poisson arrival o Release the LSP after Th, and wait for the next Poisson arrival
process event
Note that: it is possible that before the previous LSP release Note that: it is possible that before the previous LSP release
procedure completes, the next Poisson arrival process has arrived and procedure completes, the next Poisson arrival event arrives and the
the LSP setup procedure is initiated. If there is resource LSP setup procedure is initiated. If there is resource contention
contention between the two LSP, the LSP setup may fail. between the two LSPs, the LSP setup may fail. Ways to avoid such
contention are outside the scope of this document.
9.7. Typical testing cases 10.7. Typical testing cases
9.7.1. With No LSP in the Network 10.7.1. With No LSP in the Network
9.7.1.1. Motivation 10.7.1.1. Motivation
multiple unidirectional LSP setup delay with no LSP in the network is Multiple uni-directional LSP setup delay with no LSP in the network
important because this reflects the inherent delay of an RSVP-TE is 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 LSPs traverse the delay that will likely be experienced when LSPs traverse the shortest
shortest route with the lightest load in the control plane. route with the lightest load in the control plane.
9.7.1.2. Methodologies 10.7.1.2. Methodologies
Make sure that there is no LSP in the network, and proceed with the Make sure that there is no LSP in the network, and proceed with the
methodologies described in Section 9.6. methodologies described in Section 10.6.
9.7.2. With a Number of LSPs in the Network 10.7.2. With a Number of LSPs in the Network
9.7.2.1. Motivation 10.7.2.1. Motivation
multiple unidirectional LSPs setup delay with a number of LSPs in the Multiple uni-directional LSPs setup delay with a number of LSPs in
network is important because it reflects the performance of an the network is important because it reflects the performance of an
operational network with considrable load. This delay can vary operational network with considerable 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.7.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 with the methodologies described in a stable state, then proceed with the methodologies described in
Section 9.6.. Section 10.6..
10. A Definition for Samples of Single Bidirectional LSP Setup Delay 11. A Definition for Samples of Single Bi-directional LSP Setup Delay
In Section 5, we define the singleton metric of Single Bidirectional In Section 6, we have defined the singleton metric of Single Bi-
LSP setup delay. Now we define how to get one particular sample of directional LSP setup delay. Now we define how to get one particular
Single Bidirectional LSP setup delay. Sampling is to select a sample of Single Bi-directional LSP setup delay. Sampling is to
particular potion of singleton values of the given parameters. Like select a particular potion of singleton values of the given
in [RFC2330], we use Poisson sampling as an example. parameters. Like in [RFC2330], we use Poisson sampling as an
example.
10.1. Metric Name 11.1. Metric Name
Single Bidirectional LSP setup delay sample with no LSP in the Single Bi-directional LSP setup delay sample with no LSP in the
network network
10.2. Metric Parameters 11.2. 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 T0, a time o T0, a time
o Tf, a time o Tf, a time
o Lambda, a rate in the reciprocal seconds o Lambda, a rate in the reciprocal milliseconds
o Th, LSP holding time o Th, LSP holding time
o Td, the maximum waiting time for successful setup o Td, the maximum waiting time for successful setup
10.3. Metric Units 11.3. Metric Units
A sequence of pairs; the elements of each pair are: A sequence of pairs; the elements of each pair are:
o T, a time when setup is attemped o T, a time when setup is attempted
o dT, either a real number or an undefined number of milli-seconds. o dT, either a real number or an undefined number of milliseconds.
10.4. Definition 11.4. Definition
Given T0, Tf, and lambda, compute a pseudo-random Poisson process Given T0, Tf, and lambda, compute a pseudo-random Poisson process
beginning at or before T0, with average arrival rate lambda, and 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 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 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 in this process, we obtain the value of Bi-directional LSP setup
sample at this time. The value of the sample is the sequence made up delay sample at this time. The value of the sample is the sequence
of the resulting <time, LSP setup delay> pairs. If there are no such made up of the resulting <time, LSP setup delay> pairs. If there are
pairs, the sequence is of length zero and the sample is said to be no such pairs, the sequence is of length zero and the sample is said
empty. to be empty.
10.5. Discussion 11.5. Discussion
The parameters lambda should be carefully chosen. If the rate is too The parameters lambda should be carefully chosen. If the rate is too
high, too frequent LSP setup/release procedure results in high high, too frequent LSP setup/release procedure will result in high
overhead in the control plane. In turn, the high overhead will overhead in the control plane. In turn, the high overhead will
increase Bidirectional LSP setup delay. On the other hand if the increase Bi-directional LSP setup delay. On the other hand if the
rate is too low, the sample could not completely reflect the dynamic rate is too low, the sample could not completely reflect the dynamic
provisioning performance of the GMPLS network. The appropriate provisioning performance of the GMPLS network. The appropriate
lambda value depends on the given network. lambda value depends on the given network.
The parameters Td should be carefully chosen. Different switching The parameters Td should be carefully chosen. Different switching
technologies may vary significantly in performing a cross-connect technologies may vary significantly in performing a cross-connect
operation. At the same time, the time needed in setting up an LSP operation. At the same time, the time needed in setting up an LSP
under different traffic may also vary significantly. under different traffic may also vary significantly.
In the case of active measurement, the parameters Th should be In the case of active measurement, the parameters Th should be
carefully chosen. The combination of lambda and Th reflects the load carefully chosen. The combination of lambda and Th reflects the load
of the network. The selection of Th should take into account that of the network. The selection of Th SHOULD take into account that
the network has sufficient resource to perform subsequent tests. The the network has sufficient resource to perform subsequent tests. The
value of Th may be constant during one sampling process for value of Th MAY be constant during one sampling process for
simplicity considerations. simplicity considerations.
Note that for online or passive measurements, the holding time of an Note that for online or passive measurements, the arrival rate and
LSP is determined by actual traffic, hence in this case Th is not an the LSP holding time are determined by actual traffic, hence in this
input parameter. case Lambda and Th are not an input parameter.
10.6. Methodologies 11.6. Methodologies
o The selection of specific times, using the specified Poisson o Select the times using the specified Poisson arrival process, and
arrival process, and
o Set up the LSP as the methodology for the singleton bidirectional o Set up the LSP as the methodology for the singleton bi-directional
LSP setup delay, and obtain the value of bidirectional LSP setup LSP setup delay, and obtain the value of bi-directional LSP setup
delay delay
o Release the LSP after Th, and wait for the next Poisson arrival o Release the LSP after Th, and wait for the next Poisson arrival
process event
Note that: it is possible that before the previous LSP release Note that: it is possible that before the previous LSP release
procedure completes, the next Poisson arrival process has arrived and procedure completes, the next Poisson arrival event arrives and the
the LSP setup procedure is initiated. If there is resource LSP setup procedure is initiated. If there is resource contention
contention between the two LSP, the LSP setup may fail. between the two LSPs, the LSP setup may fail. Ways to avoid such
contention are outside the scope of this document.
10.7. Typical testing cases 11.7. Typical testing cases
10.7.1. With No LSP in the Network 11.7.1. With No LSP in the Network
10.7.1.1. Motivation 11.7.1.1. Motivation
Single bidirectional LSP setup delay with no LSP in the network is Single bi-directional 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.
10.7.1.2. Methodologies 11.7.1.2. Methodologies
Make sure that there is no LSP in the network, and proceed with the Make sure that there is no LSP in the network, and proceed with the
methodologies described in Section 10.6. methodologies described in Section 11.6.
10.7.2. With a Number of LSPs in the Network 11.7.2. With a Number of LSPs in the Network
10.7.2.1. Motivation 11.7.2.1. Motivation
Single bidirectional LSP setup delay with a number of LSPs in the Single bi-directional 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 considerable 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 varies. It can be used
a scalability metric of an RSVP-TE implementation. as a scalability metric of an RSVP-TE implementation.
10.7.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 with the methodologies described in a stable state, then proceed with the methodologies described in
Section 10.6. . Section 11.6. .
11. A Definition for Samples of Multiple Bidirectional LSPs Setup Delay 12. A Definition for Samples of Multiple Bi-directional LSPs Setup
Delay
In Section 6, we define the singleton metric of multiple In Section 7, we have defined the singleton metric of multiple bi-
bidirectional LSPs setup delay. Now we define how to get one directional LSPs setup delay. Now we define how to get one
particular sample of multiple bidirectional LSP setup delay. particular sample of multiple bi-directional LSP setup delay.
Sampling is to select a particular potion of singleton values of the Sampling is to select a particular potion of singleton values of the
given parameters. Like in [RFC2330], we use Poisson sampling as an given parameters. Like in [RFC2330], we use Poisson sampling as an
example. example.
11.1. Metric Name 12.1. Metric Name
Multiple bidirectional LSPs setup delay sample Multiple bi-directional LSPs setup delay sample
11.2. Metric Parameters 12.2. 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 T0, a time o T0, a time
o Tf, a time o Tf, a time
o Lambda_m, a rate in the reciprocal seconds o Lambda_m, a rate in the reciprocal milliseconds
o Lambda, a rate in the reciprocal seconds o Lambda, a rate in the reciprocal milliseconds
o X, the number of LSPs to setup o X, the number of LSPs to setup
o Td, the maximum waiting time for successful multiple o Th, LSP holding time
unidirectional LSPs setup
11.3. Metric Units o Td, the maximum waiting time for successful multiple uni-
directional LSPs setup
12.3. Metric Units
A sequence of pairs; the elements of each pair are: A sequence of pairs; the elements of each pair are:
o T, a time when the first setup is attemped o T, a time when the first setup is attempted
o dT, either a real number or an undefined number of milli-seconds. o dT, either a real number or an undefined number of milliseconds.
11.4. Definition 12.4. Definition
Given T0, Tf, and lambda, compute a pseudo-random Poisson process Given T0, Tf, and lambda, compute a pseudo-random Poisson process
beginning at or before T0, with average arrival rate lambda, and 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 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 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 in this process, we obtain the value of multiple uni-directional LSP
setup delay sample at this time. The value of the sample is the setup delay sample at this time. The value of the sample is the
sequence made up of the resulting <time, setup delay> pairs. If sequence made up of the resulting <time, setup delay> pairs. If
there are no such pairs, the sequence is of length zero and the there are no such pairs, the sequence is of length zero and the
sample is said to be empty. sample is said to be empty.
11.5. Discussion 12.5. Discussion
The parameter lambda is used as arrival rate of "bacth bidirectional The parameter lambda is used as arrival rate of "bacth bi-directional
LSPs setup" operation. It regulates the interval in between each LSPs setup" operation. It regulates the interval in between each
batch operatoin. The parameter lambda_m is used within each batch batch operation. The parameter lambda_m is used within each batch
operation, as described in Section 6. operation, as described in Section 7.
The parameters lambda and lambda_m should be carefully chosen. If The parameters lambda and lambda_m should be carefully chosen. If
the rate is too high, too frequent LSP setup/release procedure the rate is too high, too frequent LSP setup/release procedure will
results in high overhead in the control plane. In turn, the high result in high overhead in the control plane. In turn, the high
overhead will increase unidirectional LSP setup delay. On the other overhead will increase uni-directional LSP setup delay. On the other
hand if the rate is too low, the sample could not completely reflect hand if the rate is too low, the sample could not completely reflect
the dynamic provisioning performance of the GMPLS network. The the dynamic provisioning performance of the GMPLS network. The
appropriate lambda and lambda_m value depends on the given network. appropriate lambda and lambda_m value depends on the given network.
The parameters Td should be carefully chosen. Different switching The parameters Td should be carefully chosen. Different switching
technologies may vary significantly in performing a cross-connect technologies may vary significantly in performing a cross-connect
operation. At the same time, the time needed in setting up an LSP operation. At the same time, the time needed in setting up an LSP
under different traffic may also vary significantly. under different traffic may also vary significantly.
11.6. Methodologies 12.6. Methodologies
o The selection of specific times, using the specified Poisson o Select the times using the specified Poisson arrival process, and
arrival process, and
o Set up the LSP as the methodology for the singleton multiple o Set up the LSP as the methodology for the singleton multiple bi-
bidirectional LSPs setup delay, and obtain the value of multiple directional LSPs setup delay, and obtain the value of multiple
unidirectional LSPs setup delay uni-directional LSPs setup delay
o Release the LSP after Th, and wait for the next Poisson arrival o Release the LSP after Th, and wait for the next Poisson arrival
process event
Note that: it is possible that before the previous LSP release Note that: it is possible that before the previous LSP release
procedure completes, the next Poisson arrival process has arrived and procedure completes, the next Poisson arrival event arrives and the
the LSP setup procedure is initiated. If there is resource LSP setup procedure is initiated. If there is resource contention
contention between the two LSP, the LSP setup may fail. between the two LSPs, the LSP setup may fail. Ways to avoid such
contention are outside the scope of this document.
11.7. Typical testing cases 12.7. Typical testing cases
11.7.1. With No LSP in the Network 12.7.1. With No LSP in the Network
11.7.1.1. Motivation 12.7.1.1. Motivation
multiple bidirectional LSP setup delay with no LSP in the network is Multiple bi-directional LSPs setup delay with no LSP in the network
important because this reflects the inherent delay of an RSVP-TE is 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 LSPs traverse the delay that will likely be experienced when an LSPs traverse the
shortest route with the lightest load in the control plane. shortest route with the lightest load in the control plane.
11.7.1.2. Methodologies 12.7.1.2. Methodologies
Make sure that there is no LSP in the network, and proceed with the Make sure that there is no LSP in the network, and proceed with the
methodologies described in Section 9.6. methodologies described in Section 10.6.
11.7.2. With a Number of LSPs in the Network 12.7.2. With a Number of LSPs in the Network
11.7.2.1. Motivation 12.7.2.1. Motivation
multiple bidirectional LSPs setup delay with a number of LSPs in the multiple bi-directional 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 considerable load. This delay may vary
significantly as the number of existing LSPs vary. It can be used as significantly as the number of existing LSPs vary. It may be used as
a scalability metric of an RSVP-TE implementation. a scalability metric of an RSVP-TE implementation.
11.7.2.2. Methodologies 12.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 with the methodologies described in a stable state, then proceed with the methodologies described in
Section 11.6.. Section 12.6..
12. A Definition for Samples of LSP Graceful Release Delay 13. A Definition for Samples of LSP Graceful Release Delay
In Section 7, we define the singleton metric of LSP graceful release In Section 8, we have defined the singleton metric of LSP graceful
delay. Now we define how to get one particular sample of LSP release delay. Now we define how to get one particular sample of LSP
graceful release delay. We also use Poisson sampling as an example. graceful release delay. We also use Poisson sampling as an example.
12.1. Metric Name 13.1. Metric Name
LSP graceful release delay sample LSP graceful release delay sample
12.2. Metric Parameters 13.2. 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 T0, a time o T0, a time
o Tf, a time o Tf, a time
o Lambda, a rate in reciprocal seconds o Lambda, a rate in reciprocal milliseconds
o Td, the maximum waiting time for successful LSP release o Td, the maximum waiting time for successful LSP release
12.3. Metric Units 13.3. Metric Units
A sequence of pairs; the elements of each pair are: A sequence of pairs; the elements of each pair are:
o T, a time, and o T, a time, and
o dT, either a real number or an undefined number of milli-seconds. o dT, either a real number or an undefined number of milliseconds.
12.4. Definition 13.4. Definition
Given T0, Tf, and lambda, we compute a pseudo-random Poisson process Given T0, Tf, and lambda, we compute a pseudo-random Poisson process
beginning at or before T0, with average arrival rate lambda, and 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 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 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 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 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 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 such pairs, the sequence is of length zero and the sample is said to
be empty. be empty.
12.5. Discussion 13.5. Discussion
The parameter lambda should be carefully chosen. If the rate is too The parameter lambda should be carefully chosen. If the rate is too
large, too frequent LSP setup/release procedure results in high large, too frequent LSP setup/release procedure will result in high
overhead in the control plane. In turn, the high overhead will overhead in the control plane. In turn, the high overhead will
increase unidirectional LSP setup delay. On the other hand if the increase uni-directional LSP setup delay. On the other hand if the
rate is too small, the sample could not completely reflect the rate is too small, the sample could not completely reflect the
dynamic provisioning performance of the GMPLS network. The dynamic provisioning performance of the GMPLS network. The
appropriate lambda value depends on the given network. appropriate lambda value depends on the given network.
12.6. Methodologies 13.6. Methodologies
Generally the methodology would proceed as follows: Generally the methodology would proceed as follows:
o Setup the LSP to be deleted o Setup the LSP to be deleted
o The selection of specific times, using the specified Poisson o Select the times using the specified Poisson arrival process, and
arrival process, and
o Release the LSP as the methodology for the singleton LSP graceful o Release the LSP as the methodology for the singleton LSP graceful
release delay, and obtain the value of LSP graceful release delay release delay, and obtain the value of LSP graceful release delay
o Setup the LSP, and restart the Poisson arrival process, wait for o Setup the LSP, and restart the Poisson arrival process, wait for
the next Poisson arrival process the next Poisson arrival event
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 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 number of metrics is either a real number, or an undefined number of
milliseconds. In the following discussion, we only consider the milliseconds. In the following discussion, we only consider the
finite values. finite values.
14.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 SHOULD be 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 if all the dT values are undefined. In addition, the be undefined if all the dT values are undefined. In addition, the
metric minimum is undefined if the sample is empty. metric minimum SHOULD be set to undefined if the sample is empty.
14.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 MUST NOT be counted in.
14.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 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).
14.4. The Failure Probability 14.4. Failure statistics of Metric
In the process of LSP setup/release, it may fail for some reason. In the process of LSP setup/release, it may fail due to various
The failure probability is the ratio of the unsucessful times to the reasons. For example, setup/release may fail when the control plane
total times. Note here that both failure and incorrect cases are is overburdened or when there is resource shortage in one of the
counted as unsucessful cases. intermediate 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
deficiencies.
Five types of failure events are defined in previous sections:
o Single Uni-directional LSP Setup Failure
o Multiple Uni-directional LSP Setup Failure
o Single Bi-directional LSP Setup Failure
o Multiple Bi-directional LSP Setup Failure
o LSP graceful release failure
Given the samples of the performance metric, we now offer two
statistics of failure events of these samples to report.
14.4.1. Failure Count
Failure Count is defined as the number of the undefined value of the
corresponding performance metric (failure events) in a sample. The
unit of Failure Count is numerical.
14.4.2. Failure Ratio
Failure Ratio is the percentage of the number of failure events to
the total number of requests in a sample. The calculation for
Failure Ratio is defined as follows:
X type failure ratio = Number of X type failure events/(Number of
valid X type metric values + Number of X type failure events) * 100%.
15. 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 uni-directional/bi-directional 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, uni-directional/bi-directional 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 end
endpoint node. node.
o This document assumes that the correct procedures for installing o This document assumes that the correct procedures for installing
the data plane are followed as described in [RFC3209], [RFC3471], the data plane are followed as described in [RFC3209], [RFC3471],
and [RFC3473]. That is, by the time the egress receives and and [RFC3473]. That is, by the time the egress receives and
processes a Path message, it is safe for the egress to transmit processes a Path message, it is safe for the egress to transmit
data on the reverse path, and by the time the ingress receives and data on the reverse path, and by the time the ingress receives and
processes a Resv message it is safe for the ingress to transmit processes a RESV message it is safe for the ingress to transmit
data on the forward path. See [switch-programming] for detailed data on the forward path. See
explanations. This document does not include any verification that [I-D.shiomoto-ccamp-switch-programming] for detailed explanations.
the implementations of the control plane software are conformant, This document does not include any verification that the
although such tests could be constructed with the use of suitable implementations of the control plane software are conformant,
signal generation test equipment. Note that, in implementing the although such tests MAY be constructed with the use of suitable
tests described in this document a tester should be sure to signal generation test equipment. In [I-D.sun-ccamp-dpm], we
measure the time taken for the control plane messages including defined a series of metrics to do such verifications. However, it
the processing of those messages by the nodes under test. is RECOMMENDED that both the measurements defined in this document
and the measurements defined in [I-D.sun-ccamp-dpm] are performed
to complement each other.
o Bidirectional LSPs may be setup using three way signalling,where o Note that, in implementing the tests described in this document a
the initiate node will send a RESV_CONF message downsteam upon tester should be sure to measure the time taken for the control
plane messages including the processing of those messages by the
nodes under test.
o Bi-directional LSPs may be setup using three way signalling, where
the initiating node will send a RESV_CONF message downsteam upon
receiving the RESV message. The RESV_CONF message is used to receiving the RESV message. The RESV_CONF message is used to
notify the terminate node that it can transfer data upstream. notify the terminate node that it can transfer data upstream.
Actually, both direction should be ready to transfer data when the Actually, both direction should be ready to transfer data when the
RESV message is received by the initiate node. Therefore, the RESV message is received by the initiate node. Therefore, the bi-
bidirectional LSP setup delay defined in this document,does not directional LSP setup delay defined in this document does not take
take the confirmation procedure in to account. the confirmation procedure into account.
16. Security Considerations 16. Security Considerations
Samples of the metrics can be obtained in either active or passive Samples of the metrics can be obtained in either active or passive
manners. manners.
In the active manner, ingress nodes inject probing messages into the In active measurement, 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.
skipping to change at page 43, line 8 skipping to change at page 45, line 8
protocol [RFC2205] and its TE extensions [RFC3209] also remain protocol [RFC2205] and its TE extensions [RFC3209] also remain
relevant. relevant.
17. IANA Considerations 17. IANA Considerations
This document makes no requests for IANA action. This document makes no requests for IANA action.
18. 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, Henk Uijterwaal, Adrian Farrel, Deborah Brungard,
for their comments and helps. Lou Berger, Thomas D. Nadeau 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.
19. References 19. References
19.1. Normative References 19.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2205] Braden, B., Zhang, L., Berson, S., Herzog, S., and S. [RFC2205] Braden, B., Zhang, L., Berson, S., Herzog, S., and S.
Jamin, "Resource ReSerVation Protocol (RSVP) -- Version 1 Jamin, "Resource ReSerVation Protocol (RSVP) -- Version 1
Functional Specification", RFC 2205, September 1997. Functional Specification", RFC 2205, September 1997.
[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 44, line 46 skipping to change at page 46, line 49
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.
19.2. Informative References 19.2. Informative References
[switch-programming] [I-D.shiomoto-ccamp-switch-programming]
Shiomoto, K. and A. Farrel, "Advice on When It is Safe to Shiomoto, K. and A. Farrel, "Advice on When It is Safe to
Start Sending Data on Label Switched Paths Established Start Sending Data on Label Switched Paths Established
Using RSVP-TE", draft-shiomoto-ccamp-switch-programming, Using RSVP-TE", draft-shiomoto-ccamp-switch-programming-00
work in progress. (work in progress), February 2009.
[I-D.sun-ccamp-dpm]
Sun, W., Zhang, G., Gao, J., Xie, G., Papneja, R., Gu, B.,
Wei, X., Otani, T., and R. Jing, "Label Switched Path
(LSP) Data Path Delay Metric in Generalized MPLS/ MPLS-TE
Networks", draft-sun-ccamp-dpm-00 (work in progress),
June 2009.
[RFC2330] Paxson, V., Almes, G., Mahdavi, J., and M. Mathis, [RFC2330] Paxson, V., Almes, G., Mahdavi, J., and M. Mathis,
"Framework for IP Performance Metrics", RFC 2330, "Framework for IP Performance Metrics", RFC 2330,
May 1998. May 1998.
Authors' Addresses Authors' Addresses
Weiqiang Sun Weiqiang Sun
Shanghai Jiao Tong University Shanghai Jiao Tong University
800 Dongchuan Road 800 Dongchuan Road
Shanghai 200240 Shanghai 200240
CN CN
Phone: +86 21 3420 5359 Phone: +86 21 3420 5359
Email: sunwq@mit.edu Email: sunwq@mit.edu
Guoying Zhang Guoying Zhang
China Academy of Telecommunication Research,MII. China Academy of Telecommunication Research,MIIT,China.
Beijing 200240 No.11 YueTan South Street
Beijing 100045
CN CN
Phone: +86 1068094272 Phone: +86 1068094272
Email: zhangguoying@mail.ritt.com.cn Email: zhangguoying@mail.ritt.com.cn
Jianhua Gao Jianhua Gao
Huawei Technologies Co., LTD. Huawei Technologies Co., LTD.
CN CN
Phone: +86 755 28973237 Phone: +86 755 28973237
Email: gjhhit@huawei.com Email: gjhhit@huawei.com
Guowu Xie Guowu Xie
Shanghai Jiao Tong University University of California, Riverside
800 Dongchuan Road 900 University Ave.
Shanghai 200240 Riverside, CA 92521
CN USA
Phone: +86 21 3420 4596 Phone: +1 951 237 8825
Email: blithe@sjtu.edu.cn Email: xieg@cs.ucr.edu
Rajiv Papneja Rajiv Papneja
Isocore Isocore
12359 Sunrise Valley Drive, STE 100 12359 Sunrise Valley Drive, STE 100
Reston, VA 20190 Reston, VA 20190
USA USA
Phone: +1 703 860 9273 Phone: +1 703 860 9273
Email: rpapneja@isocore.com Email: rpapneja@isocore.com
Bin Gu Bin Gu
 End of changes. 330 change blocks. 
638 lines changed or deleted 745 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/