draft-ietf-ccamp-lsp-dppm-10.txt   draft-ietf-ccamp-lsp-dppm-11.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: April 5, 2010 CATR Expires: June 17, 2010 CATR
October 2, 2009 December 14, 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-10.txt draft-ietf-ccamp-lsp-dppm-11.txt
Abstract
Generalized Multi-Protocol Label Switching (GMPLS) is one of the most
promising candidate technologies for future data transmission
network. GMPLS has been developed to control and operate different
kinds of network elements, such as conventional routers, switches,
Dense Wavelength Division Multiplexing (DWDM) systems, Add-Drop
Multiplexers (ADMs), photonic cross-connects (PXCs), optical cross-
connects (OXCs), etc. The dynamic provisioning ability of these
physically diverse devices differs from each other drastically. At
the same time, the need for dynamically provisioned connections is
increasing because optical networks are being deployed in metro
areas. As different applications have varied requirements in the
provisioning performance of optical networks, it is imperative to
define standardized metrics and procedures such that the performance
of networks and application needs can be mapped to each other.
This document provides a series of performance metrics to evaluate
the dynamic Label Switched Path (LSP) provisioning performance in
GMPLS networks, specifically the dynamic LSP setup/release
performance. These metrics can be used to characterize the features
of GMPLS networks in LSP dynamic provisioning.
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. This document may contain material provisions of BCP 78 and BCP 79.
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."
skipping to change at page 1, line 37 skipping to change at page 2, line 4
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 April 5, 2010. This Internet-Draft will expire on June 17, 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
publication of this document (http://trustee.ietf.org/license-info). (http://trustee.ietf.org/license-info) in effect on the date of
Please review these documents carefully, as they describe your rights publication of this document. Please review these documents
and restrictions with respect to this document. carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must
Abstract include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as
Generalized Multi-Protocol Label Switching (GMPLS) is one of the most described in the BSD License.
promising candidate technologies for future data transmission
network. GMPLS has been developed to control and operate different
kinds of network elements, such as conventional routers, switches,
Dense Wavelength Division Multiplexing (DWDM) systems, Add-Drop
Multiplexers (ADMs), photonic cross-connects (PXCs), optical cross-
connects (OXCs), etc. The dynamic provisioning ability of these
physically diverse devices differs from each other drastically. At
the same time, the need for dynamically provisioned connections is
increasing because optical networks are being deployed in metro
areas. As different applications have varied requirements in the
provisioning performance of optical networks, it is imperative to
define standardized metrics and procedures such that the performance
of networks and application needs can be mapped to each other.
This document provides a series of performance metrics to evaluate This document may contain material from IETF Documents or IETF
the dynamic LSP provisioning performance in GMPLS networks, Contributions published or made publicly available before November
specifically the dynamic LSP setup/release performance. These 10, 2008. The person(s) controlling the copyright in some of this
metrics can be used to characterize the features of GMPLS networks in material may not have granted the IETF Trust the right to allow
LSP dynamic provisioning. 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.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 8 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 7
2. Conventions Used in This Document . . . . . . . . . . . . . . 9 2. Conventions Used in This Document . . . . . . . . . . . . . . 8
3. Overview of Performance Metrics . . . . . . . . . . . . . . . 10 3. Overview of Performance Metrics . . . . . . . . . . . . . . . 9
4. A Singleton Definition for Single Unidirectional LSP Setup 4. A Singleton Definition for Single Unidirectional LSP Setup
Delay . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11 Delay . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
4.1. Motivation . . . . . . . . . . . . . . . . . . . . . . . . 11 4.1. Motivation . . . . . . . . . . . . . . . . . . . . . . . . 10
4.2. Metric Name . . . . . . . . . . . . . . . . . . . . . . . 11 4.2. Metric Name . . . . . . . . . . . . . . . . . . . . . . . 10
4.3. Metric Parameters . . . . . . . . . . . . . . . . . . . . 11 4.3. Metric Parameters . . . . . . . . . . . . . . . . . . . . 10
4.4. Metric Units . . . . . . . . . . . . . . . . . . . . . . . 12 4.4. Metric Units . . . . . . . . . . . . . . . . . . . . . . . 11
4.5. Definition . . . . . . . . . . . . . . . . . . . . . . . . 12 4.5. Definition . . . . . . . . . . . . . . . . . . . . . . . . 11
4.6. Discussion . . . . . . . . . . . . . . . . . . . . . . . . 12 4.6. Discussion . . . . . . . . . . . . . . . . . . . . . . . . 11
4.7. Methodologies . . . . . . . . . . . . . . . . . . . . . . 13 4.7. Methodologies . . . . . . . . . . . . . . . . . . . . . . 12
4.8. Metric Reporting . . . . . . . . . . . . . . . . . . . . . 13 4.8. Metric Reporting . . . . . . . . . . . . . . . . . . . . . 12
5. A Singleton Definition for Multiple Unidirectional LSP 5. A Singleton Definition for Multiple Unidirectional LSP
Setup Delay . . . . . . . . . . . . . . . . . . . . . . . . . 14 Setup Delay . . . . . . . . . . . . . . . . . . . . . . . . . 13
5.1. Motivation . . . . . . . . . . . . . . . . . . . . . . . . 14 5.1. Motivation . . . . . . . . . . . . . . . . . . . . . . . . 13
5.2. Metric Name . . . . . . . . . . . . . . . . . . . . . . . 14 5.2. Metric Name . . . . . . . . . . . . . . . . . . . . . . . 13
5.3. Metric Parameters . . . . . . . . . . . . . . . . . . . . 14 5.3. Metric Parameters . . . . . . . . . . . . . . . . . . . . 13
5.4. Metric Units . . . . . . . . . . . . . . . . . . . . . . . 14 5.4. Metric Units . . . . . . . . . . . . . . . . . . . . . . . 13
5.5. Definition . . . . . . . . . . . . . . . . . . . . . . . . 14 5.5. Definition . . . . . . . . . . . . . . . . . . . . . . . . 13
5.6. Discussion . . . . . . . . . . . . . . . . . . . . . . . . 15 5.6. Discussion . . . . . . . . . . . . . . . . . . . . . . . . 14
5.7. Methodologies . . . . . . . . . . . . . . . . . . . . . . 16 5.7. Methodologies . . . . . . . . . . . . . . . . . . . . . . 15
5.8. Metric Reporting . . . . . . . . . . . . . . . . . . . . . 17 5.8. Metric Reporting . . . . . . . . . . . . . . . . . . . . . 16
6. A Singleton Definition for Single Bidirectional LSP Setup 6. A Singleton Definition for Single Bidirectional LSP Setup
Delay . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18 Delay . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
6.1. Motivation . . . . . . . . . . . . . . . . . . . . . . . . 18 6.1. Motivation . . . . . . . . . . . . . . . . . . . . . . . . 17
6.2. Metric Name . . . . . . . . . . . . . . . . . . . . . . . 18 6.2. Metric Name . . . . . . . . . . . . . . . . . . . . . . . 17
6.3. Metric Parameters . . . . . . . . . . . . . . . . . . . . 18 6.3. Metric Parameters . . . . . . . . . . . . . . . . . . . . 17
6.4. Metric Units . . . . . . . . . . . . . . . . . . . . . . . 19 6.4. Metric Units . . . . . . . . . . . . . . . . . . . . . . . 18
6.5. Definition . . . . . . . . . . . . . . . . . . . . . . . . 19 6.5. Definition . . . . . . . . . . . . . . . . . . . . . . . . 18
6.6. Discussion . . . . . . . . . . . . . . . . . . . . . . . . 19 6.6. Discussion . . . . . . . . . . . . . . . . . . . . . . . . 18
6.7. Methodologies . . . . . . . . . . . . . . . . . . . . . . 20 6.7. Methodologies . . . . . . . . . . . . . . . . . . . . . . 19
6.8. Metric Reporting . . . . . . . . . . . . . . . . . . . . . 20 6.8. Metric Reporting . . . . . . . . . . . . . . . . . . . . . 19
7. A Singleton Definition for Multiple Bidirectional LSPs 7. A Singleton Definition for Multiple Bidirectional LSPs
Setup Delay . . . . . . . . . . . . . . . . . . . . . . . . . 22 Setup Delay . . . . . . . . . . . . . . . . . . . . . . . . . 21
7.1. Motivation . . . . . . . . . . . . . . . . . . . . . . . . 22 7.1. Motivation . . . . . . . . . . . . . . . . . . . . . . . . 21
7.2. Metric Name . . . . . . . . . . . . . . . . . . . . . . . 22 7.2. Metric Name . . . . . . . . . . . . . . . . . . . . . . . 21
7.3. Metric Parameters . . . . . . . . . . . . . . . . . . . . 22 7.3. Metric Parameters . . . . . . . . . . . . . . . . . . . . 21
7.4. Metric Units . . . . . . . . . . . . . . . . . . . . . . . 22 7.4. Metric Units . . . . . . . . . . . . . . . . . . . . . . . 21
7.5. Definition . . . . . . . . . . . . . . . . . . . . . . . . 22 7.5. Definition . . . . . . . . . . . . . . . . . . . . . . . . 21
7.6. Discussion . . . . . . . . . . . . . . . . . . . . . . . . 23 7.6. Discussion . . . . . . . . . . . . . . . . . . . . . . . . 22
7.7. Methodologies . . . . . . . . . . . . . . . . . . . . . . 24 7.7. Methodologies . . . . . . . . . . . . . . . . . . . . . . 23
7.8. Metric Reporting . . . . . . . . . . . . . . . . . . . . . 25 7.8. Metric Reporting . . . . . . . . . . . . . . . . . . . . . 24
8. A Singleton Definition for LSP Graceful Release Delay . . . . 26 8. A Singleton Definition for LSP Graceful Release Delay . . . . 25
8.1. Motivation . . . . . . . . . . . . . . . . . . . . . . . . 26 8.1. Motivation . . . . . . . . . . . . . . . . . . . . . . . . 25
8.2. Metric Name . . . . . . . . . . . . . . . . . . . . . . . 26 8.2. Metric Name . . . . . . . . . . . . . . . . . . . . . . . 25
8.3. Metric Parameters . . . . . . . . . . . . . . . . . . . . 26 8.3. Metric Parameters . . . . . . . . . . . . . . . . . . . . 25
8.4. Metric Units . . . . . . . . . . . . . . . . . . . . . . . 26 8.4. Metric Units . . . . . . . . . . . . . . . . . . . . . . . 25
8.5. Definition . . . . . . . . . . . . . . . . . . . . . . . . 26 8.5. Definition . . . . . . . . . . . . . . . . . . . . . . . . 25
8.6. Discussion . . . . . . . . . . . . . . . . . . . . . . . . 27 8.6. Discussion . . . . . . . . . . . . . . . . . . . . . . . . 26
8.7. Methodologies . . . . . . . . . . . . . . . . . . . . . . 28 8.7. Methodologies . . . . . . . . . . . . . . . . . . . . . . 27
8.8. Metric Reporting . . . . . . . . . . . . . . . . . . . . . 29 8.8. Metric Reporting . . . . . . . . . . . . . . . . . . . . . 28
9. A Definition for Samples of Single Unidirectional LSP 9. A Definition for Samples of Single Unidirectional LSP
Setup Delay . . . . . . . . . . . . . . . . . . . . . . . . . 30 Setup Delay . . . . . . . . . . . . . . . . . . . . . . . . . 29
9.1. Metric Name . . . . . . . . . . . . . . . . . . . . . . . 30 9.1. Metric Name . . . . . . . . . . . . . . . . . . . . . . . 29
9.2. Metric Parameters . . . . . . . . . . . . . . . . . . . . 30 9.2. Metric Parameters . . . . . . . . . . . . . . . . . . . . 29
9.3. Metric Units . . . . . . . . . . . . . . . . . . . . . . . 30 9.3. Metric Units . . . . . . . . . . . . . . . . . . . . . . . 29
9.4. Definition . . . . . . . . . . . . . . . . . . . . . . . . 30 9.4. Definition . . . . . . . . . . . . . . . . . . . . . . . . 29
9.5. Discussion . . . . . . . . . . . . . . . . . . . . . . . . 31 9.5. Discussion . . . . . . . . . . . . . . . . . . . . . . . . 30
9.6. Methodologies . . . . . . . . . . . . . . . . . . . . . . 31 9.6. Methodologies . . . . . . . . . . . . . . . . . . . . . . 30
9.7. Typical testing cases . . . . . . . . . . . . . . . . . . 32 9.7. Typical testing cases . . . . . . . . . . . . . . . . . . 31
9.7.1. With no LSP in the Network . . . . . . . . . . . . . . 32 9.7.1. With no LSP in the Network . . . . . . . . . . . . . . 31
9.7.2. With a number of LSPs in the Network . . . . . . . . . 32 9.7.2. With a number of LSPs in the Network . . . . . . . . . 31
9.8. Metric Reporting . . . . . . . . . . . . . . . . . . . . . 32 9.8. Metric Reporting . . . . . . . . . . . . . . . . . . . . . 31
10. A Definition for Samples of Multiple Unidirectional LSPs 10. A Definition for Samples of Multiple Unidirectional LSPs
Setup Delay . . . . . . . . . . . . . . . . . . . . . . . . . 33 Setup Delay . . . . . . . . . . . . . . . . . . . . . . . . . 32
10.1. Metric Name . . . . . . . . . . . . . . . . . . . . . . . 33 10.1. Metric Name . . . . . . . . . . . . . . . . . . . . . . . 32
10.2. Metric Parameters . . . . . . . . . . . . . . . . . . . . 33 10.2. Metric Parameters . . . . . . . . . . . . . . . . . . . . 32
10.3. Metric Units . . . . . . . . . . . . . . . . . . . . . . . 33 10.3. Metric Units . . . . . . . . . . . . . . . . . . . . . . . 32
10.4. Definition . . . . . . . . . . . . . . . . . . . . . . . . 33 10.4. Definition . . . . . . . . . . . . . . . . . . . . . . . . 32
10.5. Discussion . . . . . . . . . . . . . . . . . . . . . . . . 34 10.5. Discussion . . . . . . . . . . . . . . . . . . . . . . . . 33
10.6. Methodologies . . . . . . . . . . . . . . . . . . . . . . 34 10.6. Methodologies . . . . . . . . . . . . . . . . . . . . . . 33
10.7. Typical testing cases . . . . . . . . . . . . . . . . . . 35 10.7. Typical testing cases . . . . . . . . . . . . . . . . . . 34
10.7.1. With No LSP in the Network . . . . . . . . . . . . . . 35 10.7.1. With No LSP in the Network . . . . . . . . . . . . . . 34
10.7.2. With a Number of LSPs in the Network . . . . . . . . . 35 10.7.2. With a Number of LSPs in the Network . . . . . . . . . 34
10.8. Metric Reporting . . . . . . . . . . . . . . . . . . . . . 35 10.8. Metric Reporting . . . . . . . . . . . . . . . . . . . . . 34
11. A Definition for Samples of Single Bidirectional LSP Setup 11. A Definition for Samples of Single Bidirectional LSP Setup
Delay . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36 Delay . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35
11.1. Metric Name . . . . . . . . . . . . . . . . . . . . . . . 36 11.1. Metric Name . . . . . . . . . . . . . . . . . . . . . . . 35
11.2. Metric Parameters . . . . . . . . . . . . . . . . . . . . 36 11.2. Metric Parameters . . . . . . . . . . . . . . . . . . . . 35
11.3. Metric Units . . . . . . . . . . . . . . . . . . . . . . . 36 11.3. Metric Units . . . . . . . . . . . . . . . . . . . . . . . 35
11.4. Definition . . . . . . . . . . . . . . . . . . . . . . . . 36 11.4. Definition . . . . . . . . . . . . . . . . . . . . . . . . 35
11.5. Discussion . . . . . . . . . . . . . . . . . . . . . . . . 37 11.5. Discussion . . . . . . . . . . . . . . . . . . . . . . . . 36
11.6. Methodologies . . . . . . . . . . . . . . . . . . . . . . 37 11.6. Methodologies . . . . . . . . . . . . . . . . . . . . . . 36
11.7. Typical testing cases . . . . . . . . . . . . . . . . . . 38 11.7. Typical testing cases . . . . . . . . . . . . . . . . . . 37
11.7.1. With No LSP in the Network . . . . . . . . . . . . . . 38 11.7.1. With No LSP in the Network . . . . . . . . . . . . . . 37
11.7.2. With a Number of LSPs in the Network . . . . . . . . . 38 11.7.2. With a Number of LSPs in the Network . . . . . . . . . 37
11.8. Metric Reporting . . . . . . . . . . . . . . . . . . . . . 38 11.8. Metric Reporting . . . . . . . . . . . . . . . . . . . . . 37
12. A Definition for Samples of Multiple Bidirectional LSPs 12. A Definition for Samples of Multiple Bidirectional LSPs
Setup Delay . . . . . . . . . . . . . . . . . . . . . . . . . 39 Setup Delay . . . . . . . . . . . . . . . . . . . . . . . . . 38
12.1. Metric Name . . . . . . . . . . . . . . . . . . . . . . . 39 12.1. Metric Name . . . . . . . . . . . . . . . . . . . . . . . 38
12.2. Metric Parameters . . . . . . . . . . . . . . . . . . . . 39 12.2. Metric Parameters . . . . . . . . . . . . . . . . . . . . 38
12.3. Metric Units . . . . . . . . . . . . . . . . . . . . . . . 39 12.3. Metric Units . . . . . . . . . . . . . . . . . . . . . . . 38
12.4. Definition . . . . . . . . . . . . . . . . . . . . . . . . 39 12.4. Definition . . . . . . . . . . . . . . . . . . . . . . . . 38
12.5. Discussion . . . . . . . . . . . . . . . . . . . . . . . . 40 12.5. Discussion . . . . . . . . . . . . . . . . . . . . . . . . 39
12.6. Methodologies . . . . . . . . . . . . . . . . . . . . . . 40 12.6. Methodologies . . . . . . . . . . . . . . . . . . . . . . 39
12.7. Typical testing cases . . . . . . . . . . . . . . . . . . 41 12.7. Typical testing cases . . . . . . . . . . . . . . . . . . 40
12.7.1. With No LSP in the Network . . . . . . . . . . . . . . 41 12.7.1. With No LSP in the Network . . . . . . . . . . . . . . 40
12.7.2. With a Number of LSPs in the Network . . . . . . . . . 41 12.7.2. With a Number of LSPs in the Network . . . . . . . . . 40
12.8. Metric Reporting . . . . . . . . . . . . . . . . . . . . . 41 12.8. Metric Reporting . . . . . . . . . . . . . . . . . . . . . 40
13. A Definition for Samples of LSP Graceful Release Delay . . . . 42 13. A Definition for Samples of LSP Graceful Release Delay . . . . 41
13.1. Metric Name . . . . . . . . . . . . . . . . . . . . . . . 42 13.1. Metric Name . . . . . . . . . . . . . . . . . . . . . . . 41
13.2. Metric Parameters . . . . . . . . . . . . . . . . . . . . 42 13.2. Metric Parameters . . . . . . . . . . . . . . . . . . . . 41
13.3. Metric Units . . . . . . . . . . . . . . . . . . . . . . . 42 13.3. Metric Units . . . . . . . . . . . . . . . . . . . . . . . 41
13.4. Definition . . . . . . . . . . . . . . . . . . . . . . . . 42 13.4. Definition . . . . . . . . . . . . . . . . . . . . . . . . 41
13.5. Discussion . . . . . . . . . . . . . . . . . . . . . . . . 42 13.5. Discussion . . . . . . . . . . . . . . . . . . . . . . . . 41
13.6. Methodologies . . . . . . . . . . . . . . . . . . . . . . 43 13.6. Methodologies . . . . . . . . . . . . . . . . . . . . . . 42
13.7. Metric Reporting . . . . . . . . . . . . . . . . . . . . . 43 13.7. Metric Reporting . . . . . . . . . . . . . . . . . . . . . 42
14. Some Statistics Definitions for Metrics to Report . . . . . . 44 14. Some Statistics Definitions for Metrics to Report . . . . . . 43
14.1. The Minimum of Metric . . . . . . . . . . . . . . . . . . 44 14.1. The Minimum of Metric . . . . . . . . . . . . . . . . . . 43
14.2. The Median of Metric . . . . . . . . . . . . . . . . . . . 44 14.2. The Median of Metric . . . . . . . . . . . . . . . . . . . 43
14.3. The Maximum of Metric . . . . . . . . . . . . . . . . . . 44 14.3. The Maximum of Metric . . . . . . . . . . . . . . . . . . 43
14.4. The Percentile of Metric . . . . . . . . . . . . . . . . . 44 14.4. The Percentile of Metric . . . . . . . . . . . . . . . . . 43
14.5. Failure statistics of Metric . . . . . . . . . . . . . . . 44 14.5. Failure statistics of Metric . . . . . . . . . . . . . . . 43
14.5.1. Failure Count . . . . . . . . . . . . . . . . . . . . 45 14.5.1. Failure Count . . . . . . . . . . . . . . . . . . . . 44
14.5.2. Failure Ratio . . . . . . . . . . . . . . . . . . . . 45 14.5.2. Failure Ratio . . . . . . . . . . . . . . . . . . . . 44
15. Discussion . . . . . . . . . . . . . . . . . . . . . . . . . . 46 15. Discussion . . . . . . . . . . . . . . . . . . . . . . . . . . 45
16. Security Considerations . . . . . . . . . . . . . . . . . . . 47 16. Security Considerations . . . . . . . . . . . . . . . . . . . 46
17. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 48 17. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 47
18. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 49 18. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 48
19. References . . . . . . . . . . . . . . . . . . . . . . . . . . 50 19. References . . . . . . . . . . . . . . . . . . . . . . . . . . 49
19.1. Normative References . . . . . . . . . . . . . . . . . . . 50 19.1. Normative References . . . . . . . . . . . . . . . . . . . 49
19.2. Informative References . . . . . . . . . . . . . . . . . . 50 19.2. Informative References . . . . . . . . . . . . . . . . . . 49
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 52 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 51
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. The dynamic provisioning ability of these connects (OXCs), etc. The dynamic provisioning ability of these
skipping to change at page 10, line 20 skipping to change at page 9, line 20
LSP graceful release delay. The latency of the LSP setup/release LSP graceful release delay. The latency of the LSP setup/release
signal is conceptually similar to the Round-trip Delay in IP signal is conceptually similar to the Round-trip Delay in IP
networks. This enables us to refer to the structures and notions networks. This enables us to refer to the structures and notions
introduced and discussed in the IPPM Framework document, [RFC2330] introduced and discussed in the IPPM Framework document, [RFC2330]
[RFC2679] [RFC2681]. The reader is assumed to be familiar with the [RFC2679] [RFC2681]. The reader is assumed to be familiar with the
notions in those documents. notions in those documents.
Note that data path related metrics, for example, the time between Note that data path related metrics, for example, the time between
the reception of Resv message by ingress node and forward data path the reception of Resv message by ingress node and forward data path
becomes operational, are defined in another document becomes operational, are defined in another document
[I-D.sun-ccamp-dpm]. An implementation MAY choose whether to [I-D.sun-ccamp-dpm]. It is desirable that both measurements are
implement metrics in the two documents together. However, it is performed to complement each other.
RECOMMENDED that both measurements are performed to complement each
other.
4. A Singleton Definition for Single Unidirectional LSP Setup Delay 4. A Singleton Definition for Single Unidirectional LSP Setup Delay
This part defines a metric for single unidirectional Label Switched This part defines a metric for single unidirectional Label Switched
Path setup delay across a GMPLS network. Path setup delay across a GMPLS network.
4.1. Motivation 4.1. Motivation
Single unidirectional Label Switched Path setup delay is useful for Single unidirectional Label Switched Path setup delay is useful for
several reasons: several reasons:
skipping to change at page 12, line 11 skipping to change at page 11, line 11
4.3. Metric Parameters 4.3. Metric Parameters
o ID0, the ingress LSR ID o ID0, the ingress LSR ID
o ID1, the egress LSR ID o ID1, the egress LSR ID
o T, a time when the setup is attempted o T, a time when the setup is attempted
4.4. Metric Units 4.4. Metric Units
The value of single unidirectional LSP setup delay is either a real The value of single unidirectional LSP setup delay is either a real
number, or an undefined number of milliseconds. number of milliseconds, or undefined.
4.5. Definition 4.5. Definition
The single unidirectional LSP setup delay from ingress node ID0 to The single unidirectional LSP setup delay from ingress node ID0 to
egress node ID1 [RFC3945] at T is dT means that ingress node ID0 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 at sends the first bit of a Path message packet to egress node ID1 at
wire-time T, and that ingress node ID0 received the last bit of wire-time T, and that ingress node ID0 received the last bit of
responding Resv message packet from egress node ID1 at wire-time responding Resv message packet from egress node ID1 at wire-time
T+dT. T+dT.
The single unidirectional LSP setup delay from ingress node ID0 to The single unidirectional 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 packet to egress node ID1 at wire-time the first bit of Path message packet to egress node ID1 at wire-time
T and that ingress node ID0 does not receive the corresponding Resv T and that ingress node ID0 does not receive the corresponding Resv
message within a reasonable period of time. message within a reasonable period of time.
The undefined value of this metric indicates an event of Single The undefined value of this metric indicates an event of Single
Unidirectional LSP Setup Failure, and would be used to report a count Unidirectional LSP Setup Failure, and would be used to report a count
or a percentage of Single Unidirectional LSP Setup failures. See or a percentage of Single Unidirectional LSP Setup failures. See
Section 14.5 for definitions of LSP setup/release failures. Section 14.5 for definitions of LSP setup/release failures.
4.6. Discussion 4.6. Discussion
skipping to change at page 13, line 31 skipping to change at page 12, line 31
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 on 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 unidirectional LSP setup delay (T2-T1) can be
computed. computed.
o If the corresponding Resv message fails to arrive within a o If the corresponding Resv message fails to arrive within a
reasonable period of time, the unidirectional LSP setup delay is reasonable period of time, the unidirectional LSP setup delay is
deemed to be undefined. 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 is a PathErr message, the o If the corresponding response is a PathErr message, the
unidirectional LSP setup delay is deemed to be undefined. unidirectional LSP setup delay is deemed to be undefined.
4.8. Metric Reporting 4.8. Metric Reporting
The metric result (either a real or an undefined value) MUST be The metric result (either a real number or undefined) MUST be
reported together with the selected uppper bound. The route that the reported together with the selected upper bound. The route that the
LSP traverses MUST also be reported. The route MAY be collected via LSP traverses MUST also be reported. The route MAY be collected via
use of the record route object, see [RFC3209], or via the management use of the record route object, see [RFC3209], or via the management
plane. The collection of routes via the management plane is out of plane. The collection of routes via the management plane is out of
scope of this document. scope of this document.
5. A Singleton Definition for Multiple Unidirectional LSP Setup Delay 5. A Singleton Definition for Multiple Unidirectional LSP Setup Delay
This part defines a metric for multiple unidirectional Label Switched This part defines a metric for multiple unidirectional Label Switched
Paths setup delay across a GMPLS network. Paths setup delay across a GMPLS network.
5.1. Motivation 5.1. Motivation
Multiple unidirectional Label Switched Paths setup delay is useful Multiple unidirectional Label Switched Paths setup delay is useful
for several reasons: for several reasons:
o Carriers may require a large number of LSPs be set up during a o Carriers may require a large number of LSPs be set up during a
short time period. This request may arise e.g. as a consequence short time period. This request may arise e.g. as a consequence
to interruptions on established LSPs or other network failures. to interruptions on established LSPs or other network failures.
o The time needed to setup a large number of LSPs during a short o The time needed to set up a large number of LSPs during a short
time period can not be deduced from single LSP setup delay. time period can not be deduced from single LSP setup delay.
5.2. Metric Name 5.2. Metric Name
Multiple unidirectional LSPs setup delay Multiple unidirectional LSPs setup delay
5.3. Metric Parameters 5.3. Metric Parameters
o ID0, the ingress LSR ID o ID0, the ingress LSR ID
o ID1, the egress LSR ID o ID1, the egress LSR ID
o 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 set up
o T, a time when the first setup is attempted o T, a time when the first setup is attempted
5.4. Metric Units 5.4. Metric Units
The value of multiple unidirectional LSPs setup delay is either a The value of multiple unidirectional LSPs setup delay is either a
real number, or an undefined number of milliseconds. real number of milliseconds, or undefined.
5.5. Definition 5.5. Definition
Given Lambda_m and X, the multiple unidirectional LSPs setup delay Given Lambda_m and X, the multiple unidirectional 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 unidirectional LSPs setup delay at T is undefined means
that ingress node ID0 sends all the Path messages toward egress node that ingress node ID0 sends all the Path messages toward egress node
ID1 and the first bit of the first Path message packet is sent at ID1 and the first bit of the first Path message packet is sent at
wire-time T and that ingress node ID0 does not receive one or more of wire-time T and that ingress node ID0 does not receive one or more of
the corresponding Resv messages within a reasonable period of time. the corresponding Resv messages within a reasonable period of time.
The undefined value of this metric indicates an event of Multiple The undefined value of this metric indicates an event of Multiple
Unidirectional LSP Setup Failure, and would be used to report a count Unidirectional LSP Setup Failure, and would be used to report a count
or a percentage of Multiple Unidirectional LSP Setup failures. See or a percentage of Multiple Unidirectional LSP Setup failures. See
Section 14.5 for definitions of LSP setup/release failures. Section 14.5 for definitions of LSP setup/release failures.
skipping to change at page 16, line 39 skipping to change at page 15, line 39
o At the ingress node, send 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 on 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 arrive 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 unidirectional LSPs
setup delay (T2 -T1) can be computed. setup delay (T2-T1) can be computed.
o If one or more of the corresponding Resv messages fail 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 unidirectional
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 are PathErr messages, o If one or more of the corresponding response are PathErr messages,
the multiple unidirectional LSPs setup delay is deemed to be the multiple unidirectional LSPs setup delay is deemed to be
undefined. undefined.
5.8. Metric Reporting 5.8. Metric Reporting
The metric result (either a real or an undefined value) MUST be The metric result (either a real number or undefined) MUST be
reported together with the selected uppper bound. The route that the reported together with the selected upper bound. The route that the
LSPs traverse MUST also be reported. The route MAY be collected via LSPs traverse MUST also be reported. The route MAY be collected via
use of the record route object, see [RFC3209], or via the management use of the record route object, see [RFC3209], or via the management
plane. The collection of routes via the management plane is out of plane. The collection of routes via the management plane is out of
scope of this document. scope of this document.
6. A Singleton Definition for Single Bidirectional LSP Setup Delay 6. A Singleton Definition for Single Bidirectional LSP Setup Delay
GMPLS allows establishment of bidirectional symmetric LSPs (not of GMPLS allows establishment of bidirectional symmetric LSPs (not of
asymmetric LSPs). This part defines a metric for single asymmetric LSPs). This part defines a metric for single
bidirectional LSP setup delay across a GMPLS network. bidirectional LSP setup delay across a GMPLS network.
skipping to change at page 19, line 13 skipping to change at page 18, line 13
6.3. Metric Parameters 6.3. Metric Parameters
o ID0, the ingress LSR ID o ID0, the ingress LSR ID
o ID1, the egress LSR ID o ID1, the egress LSR ID
o T, a time when the setup is attempted o T, a time when the setup is attempted
6.4. Metric Units 6.4. Metric Units
The value of single bidirectional LSP setup delay is either a real The value of single bidirectional LSP setup delay is either a real
number, or an undefined number of milliseconds. number of milliseconds, or undefined.
6.5. Definition 6.5. Definition
For a real number dT, the single bidirectional LSP setup delay from For a real number dT, the single bidirectional LSP setup delay from
ingress node 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 the Resv message 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 bidirectional 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.
The undefined value of this metric indicates an event of Single The undefined value of this metric indicates an event of Single
Bidirectional LSP Setup Failure, and would be used to report a count Bidirectional LSP Setup Failure, and would be used to report a count
or a percentage of Single Bidirectional LSP Setup failures. See or a percentage of Single Bidirectional LSP Setup failures. See
Section 14.5 for definitions of LSP setup/release failures. Section 14.5 for definitions of LSP setup/release failures.
6.6. Discussion 6.6. Discussion
skipping to change at page 20, line 7 skipping to change at page 19, line 7
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 MAY 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 micro mirrors. This physical cross-connects (PXCs) have to move micro mirrors. This physical
motion may take several milliseconds. But electronic switches can motion may take several milliseconds. But electronic switches can
finish the nodal processing within several microseconds. So the finish the nodal processing within several microseconds. So the
bidirectional LSP setup delay varies drastically from one network bidirectional LSP setup delay varies drastically from one network
to another. In the process of bidirectional LSP setup, if the to another. In the process of bidirectional LSP setup, if the
downstream node overrides the label suggested by the upstream downstream node overrides the label suggested by the upstream
node, the setup delay may also increase. Thus, In practice, the node, the setup delay may also increase. Thus, in practice, the
upper bound SHOULD be chosen carefully. upper bound SHOULD be chosen carefully.
o If the ingress node sends out the Path message to set up the LSP, o If the ingress node sends out the Path message to set up the LSP,
but never receives the corresponding Resv message, single but never receives the corresponding Resv message, single
bidirectional LSP setup delay MUST be set to undefined. bidirectional 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 a PathErr message, single bidirectional LSP setup but receives a PathErr message, single bidirectional LSP setup
delay MUST be set to 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
skipping to change at page 20, line 36 skipping to change at page 19, line 36
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 on 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 bidirectional LSP setup delay (T2-T1)
can be computed. can be computed.
o If the corresponding Resv message fails to arrive within a o If the corresponding Resv message fails to arrive within a
reasonable period of time, the single bidirectional LSP setup reasonable period of time, the single bidirectional LSP setup
delay is deemed to be undefined. 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 is a PathErr message, the single o If the corresponding response is a PathErr message, the single
bidirectional LSP setup delay is deemed to be undefined. bidirectional LSP setup delay is deemed to be undefined.
6.8. Metric Reporting 6.8. Metric Reporting
The metric result (either a real or an undefined value) MUST be The metric result (either a real number or undefined) MUST be
reported together with the selected uppper bound. The route that the reported together with the selected upper bound. The route that the
LSP traverses MUST also be reported. The route MAY be collected via LSP traverses MUST also be reported. The route MAY be collected via
use of the record route object, see [RFC3209], or via the management use of the record route object, see [RFC3209], or via the management
plane. The collection of routes via the management plane is out of plane. The collection of routes via the management plane is out of
scope of this document. scope of this document.
7. A Singleton Definition for Multiple Bidirectional LSPs Setup Delay 7. A Singleton Definition for Multiple Bidirectional LSPs Setup Delay
This part defines a metric for multiple bidirectional LSPs setup This part defines a metric for multiple bidirectional LSPs setup
delay across a GMPLS network. delay across a GMPLS network.
7.1. Motivation 7.1. Motivation
Multiple bidirectional LSPs setup delay is useful for several Multiple bidirectional LSPs setup delay is useful for several
reasons: reasons:
o Upon traffic interruption caused by network failure or network o Upon traffic interruption caused by network failure or network
upgrade, carriers may require a large number of LSPs be set up upgrade, carriers may require a large number of LSPs be set up
during a short time period during a short time period
o The time needed to setup a large number of LSPs during a short o The time needed to set up a large number of LSPs during a short
time period can not be deduced by single LSP setup delay time period can not be deduced by single LSP setup delay
7.2. Metric Name 7.2. Metric Name
Multiple bidirectional LSPs setup delay Multiple bidirectional LSPs setup delay
7.3. Metric Parameters 7.3. Metric Parameters
o ID0, the ingress LSR ID o ID0, the ingress LSR ID
o ID1, the egress LSR ID o ID1, the egress LSR ID
o 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 set up
o T, a time when the first setup is attempted o T, a time when the first setup is attempted
7.4. Metric Units 7.4. Metric Units
The value of multiple bidirectional LSPs setup delay is either a real The value of multiple bidirectional LSPs setup delay is either a real
number, or an undefined number of milliseconds. number of milliseconds, or undefined.
7.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
bidirectional LSPs setup delay from ingress node to egress node at T bidirectional LSPs setup delay from ingress node to egress node at T
is dT, means that: is 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 packet 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 bidirectional 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 Resv messages within a reasonable receive one or more of the response Resv messages within a reasonable
period of time. period of time.
The undefined value of this metric indicates an event of Multiple The undefined value of this metric indicates an event of Multiple
Bidirectional LSP Setup Failure, and would be used to report a count Bidirectional LSP Setup Failure, and would be used to report a count
or a percentage of Multiple Bidirectional LSP Setup failures. See or a percentage of Multiple Bidirectional LSP Setup failures. See
Section 14.5 for definitions of LSP setup/release failures. Section 14.5 for definitions of LSP setup/release failures.
7.6. Discussion 7.6. Discussion
The following issues are likely to come up in practice: The following issues are likely to come up in practice:
o The accuracy of multiple bidirectional LSPs setup delay depends on o The accuracy of multiple Bidirectional LSPs setup delay depends on
the clock resolution in the ingress node; but synchronization the clock resolution in the ingress node; but synchronization
between the ingress node and egress node is not required since between the ingress node and egress node is not required since
bidirectional LSP setup uses two-way signaling. bidirectional LSP setup uses two-way signaling.
o A given methodology will have to include a way to determine o A given methodology will have to include a way to determine
whether a latency value is infinite or whether it is merely very whether a latency value is infinite or whether it is merely very
large. Simple upper bounds MAY 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 micro mirrors. This physical cross-connects (PXCs) have to move micro mirrors. This physical
motion may take several milliseconds. But electronic switches can motion may take several milliseconds. But electronic switches can
finish the nodal process within several microseconds. So the finish the nodal process within several microseconds. So the
multiple bidirectional LSPs setup delay varies drastically from a multiple bidirectional LSPs setup delay varies drastically from a
network to another. In the process of multiple bidirectional LSPs network to another. In the process of multiple bidirectional LSPs
setup, if the downstream node overrides the label suggested by the setup, if the downstream node overrides the label suggested by the
upstream node, the setup delay may also increase. Thus, In upstream node, the setup delay may also increase. Thus, in
practice, the upper bound SHOULD be chosen carefully. practice, the upper bound SHOULD be chosen carefully.
o If the ingress node sends out the Path messages to set up the o If the ingress node sends out the Path messages to set up the
LSPs, but never receives all the corresponding Resv messages, the LSPs, but never receives all the corresponding Resv messages, the
multiple bidirectional LSPs setup delay MUST be set to undefined. multiple bidirectional 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 receives one or more responding PathErr messages, the LSPs, but receives one or more responding PathErr messages, the
multiple bidirectional LSPs setup delay MUST be set to undefined. multiple bidirectional LSPs setup delay MUST be set to undefined.
There are many possible reasons for this case. For example, one There are many possible reasons for this case. For example, one
skipping to change at page 24, line 44 skipping to change at page 23, line 44
o At the ingress node, send 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 arrive 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 bidirectional LSPs
setup delay (T2 -T1) can be computed. setup delay (T2-T1) can be computed.
o If one or more of the corresponding Resv messages fail 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 bidirectional
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 are PathErr messages, o If one or more of the corresponding response are PathErr messages,
the multiple bidirectional LSPs setup delay is deemed to be the multiple bidirectional LSPs setup delay is deemed to be
undefined. undefined.
7.8. Metric Reporting 7.8. Metric Reporting
The metric result (either a real or an undefined value) MUST be The metric result (either a real number or undefined) MUST be
reported together with the selected uppper bound. The route that the reported together with the selected upper bound. The route that the
LSPs traverse MUST also be reported. The route MAY be collected via LSPs traverse MUST also be reported. The route MAY be collected via
use of the record route object, see [RFC3209], or via the management use of the record route object, see [RFC3209], or via the management
plane. The collection of routes via the management plane is out of plane. The collection of routes via the management plane is out of
scope of this document. scope of this document.
8. 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. This document does networks: graceful release and forceful release. This document does
not take forceful LSP release procedure into account. not take forceful LSP release procedure into account.
skipping to change at page 26, line 38 skipping to change at page 25, line 38
8.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 attempted o T, a time when the release is attempted
8.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 of
an undefined number of milliseconds. milliseconds, or undefined.
8.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 the egress initiated by the ingress node, and another is initiated by the egress
node. The two procedures are depicted in [RFC3473]. We define the node. The two procedures are depicted in [RFC3473]. We define 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
skipping to change at page 27, line 15 skipping to change at page 26, line 15
the Delete (D) bit set back to the ingress node. Ingress node ID0 the Delete (D) bit set back to the ingress node. Ingress node ID0
sends out PathTear downstream to remove the LSP, and egress node ID1 sends out PathTear downstream to remove the LSP, and egress node ID1
receives the last bit of PathTear packet at wire-time T+dT. receives the last bit of PathTear packet at wire-time T+dT.
Also as an option, upon receipt of the Path message including Admin Also as an option, upon receipt of the Path message including Admin
Status Object with the Reflect (R) and Delete (D) bits set, egress Status Object with the Reflect (R) and Delete (D) bits set, egress
node ID1 may respond with a PathErr message with the node ID1 may respond with a 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
bit of Path message to egress node ID1 at wire-time T and that of Path message to egress node ID1 at wire-time T and that (either
(either egress node does not receive the Path packet, egress node egress node does not receive the Path packet, egress node does not
does not send corresponding Resv message packet in response, or send corresponding Resv message packet in response, or ingress node
ingress node does not receive that Resv packet, and) egress node ID1 does not receive that Resv packet, and) egress node ID1 does not
does not receive the PathTear within a reasonable period of time. 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. Ingress node (R) and Delete (D) bits to ingress node at wire-time T. 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. 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, or and that (either ingress node does not receive the Resv packet, or
ingress node does not send PathTear message packet in response, and) ingress node does not send PathTear message packet in response, and)
egress node ID1 does not receive the PathTear within a reasonable egress node ID1 does not receive the PathTear within a reasonable
period of time. period of time.
The undefined value of this metric indicates an event of LSP Graceful The undefined value of this metric indicates an event of LSP Graceful
Release Failure, and would be used to report a count or a percentage Release Failure, and would be used to report a count or a percentage
of LSP Graceful Release failures. See Section 14.5 for definitions of LSP Graceful Release failures. See Section 14.5 for definitions
skipping to change at page 29, line 28 skipping to change at page 28, line 28
(T2-T1). (T2-T1).
o If the egress node sends the Resv message upstream, but it fails o If the egress node sends the Resv message upstream, but it fails
to receive the PathTear message within a reasonable period of to receive the PathTear message within a reasonable period of
time, the LSP graceful release delay is deemed to be undefined. time, the LSP graceful release delay is deemed to be undefined.
Note that the 'reasonable' threshold is a parameter of the Note that the 'reasonable' threshold is a parameter of the
methodology. methodology.
8.8. Metric Reporting 8.8. Metric Reporting
The metric result (either a real or an undefined value) MUST be The metric result (either a real number or undefined) MUST be
reported together with the selected uppper bound and the procedure reported together with the selected upper bound and the procedure
used (eg. either from the ingress node to the egress node, or from used (e.g., either from the ingress node to the egress node, or from
the egress node to the ingress node. See Section 8.5 for more the egress node to the ingress node. See Section 8.5 for more
details). The route that the LSP traverses MUST also be reported. details). The route that the LSP traverses MUST also be reported.
The route MAY be collected via use of the record route object, see The route MAY be collected via use of the record route object, see
[RFC3209], or via the management plane. The collection of routes via [RFC3209], or via the management plane. The collection of routes via
the management plane is out of scope of this document. the management plane is out of scope of this document.
9. A Definition for Samples of Single Unidirectional LSP Setup Delay 9. A Definition for Samples of Single Unidirectional LSP Setup Delay
In Section 4, we have defined the singleton metric of Single In Section 4, we have defined the singleton metric of Single
unidirectional LSP setup delay. Now we define how to get one unidirectional LSP setup delay. Now we define how to get one
particular sample of Single unidirectional LSP setup delay. Sampling particular sample of Single unidirectional LSP setup delay. Sampling
is to select a particular potion of singleton values of the given means to take a number of distinct instances of a skeleton metric
parameters. Like in [RFC2330], we use Poisson sampling as an under a given set of parameters. Like in [RFC2330], we use Poisson
example. sampling as an example.
9.1. Metric Name 9.1. Metric Name
Single unidirectional LSP setup delay sample Single unidirectional LSP setup delay sample
9.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
skipping to change at page 30, line 40 skipping to change at page 29, line 40
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
9.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 attempted o T, a time when setup is attempted
o dT, either a real number or an undefined number of milliseconds. o dT, either a real number of milliseconds, or undefined.
9.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 unidirectional 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
skipping to change at page 33, line 11 skipping to change at page 32, line 11
which the sample is obtained, including the selected parameters, the which the sample is obtained, including the selected parameters, the
route traversed by the LSPs, and the testing case used, MUST also be route traversed by the LSPs, and the testing case used, MUST also be
reported. reported.
10. A Definition for Samples of Multiple Unidirectional LSPs Setup 10. A Definition for Samples of Multiple Unidirectional LSPs Setup
Delay Delay
In Section 5, we have defined the singleton metric of multiple In Section 5, we have defined the singleton metric of multiple
unidirectional LSPs setup delay. Now we define how to get one unidirectional LSPs setup delay. Now we define how to get one
particular sample of multiple unidirectional LSP setup delay. particular sample of multiple unidirectional LSP setup delay.
Sampling is to select a particular potion of singleton values of the Sampling means to take a number of distinct instances of a skeleton
given parameters. Like in [RFC2330], we use Poisson sampling as an metric under a given set of parameters. Like in [RFC2330], we use
example. Poisson sampling as an example.
10.1. Metric Name 10.1. Metric Name
Multiple unidirectional LSPs setup delay sample Multiple unidirectional LSPs setup delay sample
10.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 milliseconds o Lambda_m, a rate in the reciprocal milliseconds
o Lambda, a rate in the reciprocal milliseconds o Lambda, a rate in the reciprocal milliseconds
o X, the number of LSPs to setup o X, the number of LSPs to set up
o Th, LSP holding time o Th, LSP holding time
o Td, the maximum waiting time for successful multiple o Td, the maximum waiting time for successful multiple
unidirectional LSPs setup unidirectional LSPs setup
10.3. Metric Units 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 attempted o T, a time when the first setup is attempted
o dT, either a real number or an undefined number of milliseconds. o dT, either a real number of milliseconds, or undefined.
10.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 time 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 unidirectional 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.
10.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 "batch unidirectional
LSPs setup" operation. It regulates the interval in between each LSPs setup" operation. It regulates the interval in between each
batch operation. 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 5 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 will the rate is too high, too frequent LSP setup/release procedure will
result 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 unidirectional 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
skipping to change at page 36, line 10 skipping to change at page 35, line 10
reported together with the total number of values. The context under reported together with the total number of values. The context under
which the sample is obtained, including the selected parameters, the which the sample is obtained, including the selected parameters, the
route traversed by the LSPs, and the testing case used, MUST also be route traversed by the LSPs, and the testing case used, MUST also be
reported. reported.
11. A Definition for Samples of Single Bidirectional LSP Setup Delay 11. A Definition for Samples of Single Bidirectional LSP Setup Delay
In Section 6, we have defined the singleton metric of Single In Section 6, we have defined the singleton metric of Single
Bidirectional LSP setup delay. Now we define how to get one Bidirectional LSP setup delay. Now we define how to get one
particular sample of Single Bidirectional LSP setup delay. Sampling particular sample of Single Bidirectional LSP setup delay. Sampling
is to select a particular potion of singleton values of the given means to take a number of distinct instances of a skeleton metric
parameters. Like in [RFC2330], we use Poisson sampling as an under a given set of parameters. Like in [RFC2330], we use Poisson
example. sampling as an example.
11.1. Metric Name 11.1. Metric Name
Single Bidirectional LSP setup delay sample with no LSP in the Single Bidirectional LSP setup delay sample with no LSP in the
network network
11.2. Metric Parameters 11.2. Metric Parameters
o ID0, the ingress LSR ID o ID0, the ingress LSR ID
skipping to change at page 36, line 41 skipping to change at page 35, line 41
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
11.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 attempted o T, a time when setup is attempted
o dT, either a real number or an undefined number of milliseconds. o dT, either a real number of milliseconds, or undefined.
11.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 bidirectional LSP setup 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 setup delay> pairs. If there are no such of the resulting <time, LSP setup delay> pairs. If there are no such
skipping to change at page 39, line 5 skipping to change at page 38, line 5
Section 11.6. Section 11.6.
11.8. Metric Reporting 11.8. Metric Reporting
The metric results including both real and undefined values MUST be The metric results including both real and undefined values MUST be
reported together with the total number of values. The context under reported together with the total number of values. The context under
which the sample is obtained, including the selected parameters, the which the sample is obtained, including the selected parameters, the
route traversed by the LSPs, and the testing case used, MUST also be route traversed by the LSPs, and the testing case used, MUST also be
reported. reported.
12. A Definition for Samples of Multiple Bidirectional LSPs Setup 12. A Definition for Samples of Multiple Bidirectional LSPs Setup Delay
Delay
In Section 7, we have defined the singleton metric of multiple In Section 7, we have defined the singleton metric of multiple
bidirectional LSPs setup delay. Now we define how to get one bidirectional LSPs setup delay. Now we define how to get one
particular sample of multiple bidirectional LSP setup delay. particular sample of multiple bidirectional LSP setup delay.
Sampling is to select a particular potion of singleton values of the Sampling means to take a number of distinct instances of a skeleton
given parameters. Like in [RFC2330], we use Poisson sampling as an metric under a given set of parameters. Like in [RFC2330], we use
example. Poisson sampling as an example.
12.1. Metric Name 12.1. Metric Name
Multiple bidirectional LSPs setup delay sample Multiple bidirectional LSPs setup delay sample
12.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 milliseconds o Lambda_m, a rate in the reciprocal milliseconds
o Lambda, a rate in the reciprocal milliseconds o Lambda, a rate in the reciprocal milliseconds
o X, the number of LSPs to setup o X, the number of LSPs to set up
o Th, LSP holding time o Th, LSP holding time
o Td, the maximum waiting time for successful multiple o Td, the maximum waiting time for successful multiple
unidirectional LSPs setup unidirectional LSPs setup
12.3. Metric Units 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 attempted o T, a time when the first setup is attempted
o dT, either a real number or an undefined number of milliseconds. o dT, either a real number of milliseconds, or undefined.
12.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 unidirectional 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.
12.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 "batch bidirectional
LSPs setup" operation. It regulates the interval in between each LSPs setup" operation. It regulates the interval in between each
batch operation. 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 7. 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 will the rate is too high, too frequent LSP setup/release procedure will
result 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 unidirectional 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
skipping to change at page 41, line 27 skipping to change at page 40, line 26
12.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 10.6. methodologies described in Section 10.6.
12.7.2. With a Number of LSPs in the Network 12.7.2. With a Number of LSPs in the Network
12.7.2.1. Motivation 12.7.2.1. Motivation
multiple bidirectional LSPs setup delay with a number of LSPs in the Multiple bidirectional LSPs setup delay with a number of LSPs in the
network is important because it reflects the performance of an network is important because it reflects the performance of an
operational network with considerable load. This delay may vary operational network with considerable load. This delay may vary
significantly as the number of existing LSPs vary. It may 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.
12.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 12.6. Section 12.6.
skipping to change at page 42, line 35 skipping to change at page 41, line 35
o Lambda, a rate in reciprocal milliseconds 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
13.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 milliseconds. o dT, either a real number of milliseconds, or undefined.
13.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
skipping to change at page 44, line 10 skipping to change at page 43, line 10
The metric results including both real and undefined values MUST be The metric results including both real and undefined values MUST be
reported together with the total number of values. The context under reported together with the total number of values. The context under
which the sample is obtained, including the selected parameters, and which the sample is obtained, including the selected parameters, and
the route traversed by the LSPs MUST also be reported. the route traversed by the LSPs MUST also be reported.
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 either a real number of milliseconds, or undefined.
milliseconds. In the following discussion, we only consider the 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 SHOULD be 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 SHOULD be set to 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
skipping to change at page 47, line 11 skipping to change at page 46, line 11
Resv message is received by the initiate node. Therefore, the Resv message is received by the initiate node. Therefore, the
bidirectional LSP setup delay defined in this document does not bidirectional LSP setup delay defined in this document does not
take the confirmation procedure into account. take 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 active measurement, 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. Since the measurement endpoints must be conformant to
so that the measurements inject trivial amounts of additional traffic signaling specifications and behave as normal signaling endpoints, it
will not incur other security issues than normal LSP provisioning.
However, the measurement parameters must be carefully selected so
that the measurements inject trivial amounts of additional traffic
into the networks they measure. If they inject "too much" traffic, 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. A typical
implementation may use the Management Information Base (MIB) to
collect/store the metrics and access to the MIB is limited to the
Network Management Systems (NMSs). In this case, passive monitoring
will not incur other security issues than implementing the MIBs and
NMSs. If an implementation chooses to expose the performance data to
other applications, then it must take into account the possible
security issues it may face. For example, when exposing the
performance data through SNMP, certain authentication method should
be used to ensure that the entity maintaining the performance data
are not subject to unauthorized readings and modifications. Rate
limiting on the performance query may also be desirable to reduce the
risk that the entity maintaining the performance data are overwhelmed
by too much query requests. It is RECOMMENDED that implementers
consider the security features as provided by the SNMPv3 framework
(see [RFC3410], section 8), including full support for the SNMPv3
cryptographic mechanisms (for authentication and privacy).
Besides, the security considerations pertaining to the original RSVP Besides, the security considerations pertaining to the original RSVP
protocol [RFC2205] and its TE extensions [RFC3209] also remain protocol [RFC2205] and its TE extensions [RFC3209] also remain
relevant. relevant.
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. Acknowledgments
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, Adrian Farrel, Deborah Brungard, Lou Berger, Thomas D. Nadeau Morrow, Adrian Farrel, Deborah Brungard, Lou Berger, Thomas D. Nadeau
for their comments and helps. Lou Berger and Adrian Farrel have text for their comments and helps. Lou Berger and Adrian Farrel have text
contributions to this document. contributions to this document.
We wish to thank experts from IPPM and BMWG - Reinhard Schrage, Al We wish to thank experts from IPPM and BMWG - Reinhard Schrage, Al
Morton and Henk Uijterwaal, for reviewing this document. Reinhard Morton and Henk Uijterwaal, for reviewing this document. Reinhard
Schrage has text contributions to this document. Schrage has text contributions to this document.
skipping to change at page 50, line 47 skipping to change at page 49, line 47
[RFC4208] Swallow, G., Drake, J., Ishimatsu, H., and Y. Rekhter, [RFC4208] Swallow, G., Drake, J., Ishimatsu, H., and Y. Rekhter,
"Generalized Multiprotocol Label Switching (GMPLS) User- "Generalized Multiprotocol Label Switching (GMPLS) User-
Network Interface (UNI): Resource ReserVation Protocol- Network Interface (UNI): Resource ReserVation Protocol-
Traffic Engineering (RSVP-TE) Support for the Overlay Traffic Engineering (RSVP-TE) Support for the Overlay
Model", RFC 4208, October 2005. Model", RFC 4208, October 2005.
19.2. Informative References 19.2. Informative References
[I-D.shiomoto-ccamp-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-00 Using RSVP-TE", draft-shiomoto-ccamp-switch-programming-01
(work in progress), February 2009. (work in progress), October 2009.
[I-D.sun-ccamp-dpm] [I-D.sun-ccamp-dpm]
Sun, W., Zhang, G., Gao, J., Xie, G., Papneja, R., Gu, B., Sun, W., Zhang, G., Gao, J., Xie, G., Papneja, R., Gu, B.,
Wei, X., Otani, T., and R. Jing, "Label Switched Path Wei, X., Otani, T., and R. Jing, "Label Switched Path
(LSP) Data Path Delay Metric in Generalized MPLS/ MPLS-TE (LSP) Data Path Delay Metric in Generalized MPLS/ MPLS-TE
Networks", draft-sun-ccamp-dpm-00 (work in progress), Networks", draft-sun-ccamp-dpm-01 (work in progress),
June 2009. December 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.
[RFC3410] Case, J., Mundy, R., Partain, D., and B. Stewart,
"Introduction and Applicability Statements for Internet-
Standard Management Framework", RFC 3410, December 2002.
Authors' Addresses Authors' Addresses
Weiqiang Sun Weiqiang Sun, Editor
Shanghai Jiao Tong University Shanghai Jiao Tong University
800 Dongchuan Road 800 Dongchuan Road
Shanghai 200240 Shanghai 200240
CN China
Phone: +86 21 3420 5359 Phone: +86 21 3420 5359
Email: sunwq@mit.edu Email: sunwq@mit.edu
Guoying Zhang Guoying Zhang, Editor
China Academy of Telecommunication Research,MIIT,China. China Academy of Telecommunication Research, MIIT, China.
No.11 YueTan South Street No.11 YueTan South Street
Beijing 100045 Beijing 100045
CN China
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 China
Phone: +86 755 28973237 Phone: +86 755 28973237
Email: gjhhit@huawei.com Email: gjhhit@huawei.com
Guowu Xie Guowu Xie
University of California, Riverside University of California, Riverside
900 University Ave. 900 University Ave.
Riverside, CA 92521 Riverside, CA 92521
USA USA
skipping to change at page 53, line 4 skipping to change at page 52, line 4
Email: xieg@cs.ucr.edu 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
Contributors
Bin Gu Bin Gu
IXIA IXIA
Oriental Kenzo Plaza 8M,48 Dongzhimen Wai Street,Dongcheng District Oriental Kenzo Plaza 8M, 48 Dongzhimen Wai Street, Dongcheng District
Beijing 200240 Beijing 200240
CN China
Phone: +86 13611590766 Phone: +86 13611590766
Email: BGu@ixiacom.com Email: BGu@ixiacom.com
Xueqin Wei Xueqin Wei
Fiberhome Telecommunicaiton Technology Co.,Ltd. Fiberhome Telecommunication Technology Co., Ltd.
Wuhan Wuhan
CN China
Phone: +86 13871127882 Phone: +86 13871127882
Email: xqwei@fiberhome.com.cn Email: xqwei@fiberhome.com.cn
Tomohiro Otani Tomohiro Otani
KDDI R&D Laboratories, Inc. KDDI R&D Laboratories, Inc.
2-1-15 Ohara Kamifukuoka Saitama 2-1-15 Ohara Kamifukuoka Saitama
356-8502 356-8502
Japan Japan
Phone: +81-49-278-7357 Phone: +81-49-278-7357
Email: otani@kddilabs.jp Email: otani@kddilabs.jp
Ruiquan Jing Ruiquan Jing
China Telecom Beijing Research Institute China Telecom Beijing Research Institute
118 Xizhimenwai Avenue 118 Xizhimenwai Avenue
Beijing 100035 Beijing 100035
CN China
Phone: +86-10-58552000 Phone: +86-10-58552000
Email: jingrq@ctbri.com.cn Email: jingrq@ctbri.com.cn
 End of changes. 91 change blocks. 
255 lines changed or deleted 282 lines changed or added

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