draft-ietf-ccamp-lsp-dppm-11.txt   rfc5814.txt 
Network Working Group W. Sun, Ed. Internet Engineering Task Force (IETF) W. Sun, Ed.
Internet-Draft SJTU Request for Comments: 5814 SJTU
Intended status: Standards Track G. Zhang, Ed. Category: Standards Track G. Zhang, Ed.
Expires: June 17, 2010 CATR ISSN: 2070-1721 CATR
December 14, 2009 March 2010
Label Switched Path (LSP) Dynamic Provisioning Performance Metrics in Label Switched Path (LSP) Dynamic Provisioning Performance Metrics
Generalized MPLS Networks in Generalized MPLS Networks
draft-ietf-ccamp-lsp-dppm-11.txt
Abstract Abstract
Generalized Multi-Protocol Label Switching (GMPLS) is one of the most Generalized Multi-Protocol Label Switching (GMPLS) is one of the most
promising candidate technologies for future data transmission promising candidate technologies for a future data transmission
network. GMPLS has been developed to control and operate different network. GMPLS has been developed to control and operate different
kinds of network elements, such as conventional routers, switches, kinds of network elements, such as conventional routers, switches,
Dense Wavelength Division Multiplexing (DWDM) systems, Add-Drop Dense Wavelength Division Multiplexing (DWDM) systems, Add-Drop
Multiplexers (ADMs), photonic cross-connects (PXCs), optical cross- Multiplexers (ADMs), photonic cross-connects (PXCs), optical cross-
connects (OXCs), etc. The dynamic provisioning ability of these connects (OXCs), etc. These physically diverse devices differ
physically diverse devices differs from each other drastically. At drastically from one another in dynamic provisioning ability. At the
the same time, the need for dynamically provisioned connections is same time, the need for dynamically provisioned connections is
increasing because optical networks are being deployed in metro increasing because optical networks are being deployed in metro
areas. As different applications have varied requirements in the areas. As different applications have varied requirements in the
provisioning performance of optical networks, it is imperative to provisioning performance of optical networks, it is imperative to
define standardized metrics and procedures such that the performance define standardized metrics and procedures such that the performance
of networks and application needs can be mapped to each other. of networks and application needs can be mapped to each other.
This document provides a series of performance metrics to evaluate This document provides a series of performance metrics to evaluate
the dynamic Label Switched Path (LSP) provisioning performance in the dynamic Label Switched Path (LSP) provisioning performance in
GMPLS networks, specifically the dynamic LSP setup/release GMPLS networks, specifically the dynamic LSP setup/release
performance. These metrics can be used to characterize the features performance. These metrics can be used to characterize the features
of GMPLS networks in LSP dynamic provisioning. 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
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet-
Drafts.
Internet-Drafts are draft documents valid for a maximum of six months This is an Internet Standards Track document.
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at This document is a product of the Internet Engineering Task Force
http://www.ietf.org/shadow.html. (IETF). It represents the consensus of the IETF community. It has
received public review and has been approved for publication by the
Internet Engineering Steering Group (IESG). Further information on
Internet Standards is available in Section 2 of RFC 5741.
This Internet-Draft will expire on June 17, 2010. Information about the current status of this document, any errata,
and how to provide feedback on it may be obtained at
http://www.rfc-editor.org/info/rfc5814.
Copyright Notice Copyright Notice
Copyright (c) 2009 IETF Trust and the persons identified as the Copyright (c) 2010 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 Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the BSD License. described in the Simplified BSD License.
This document may contain material from IETF Documents or IETF This document may contain material from IETF Documents or IETF
Contributions published or made publicly available before November Contributions published or made publicly available before November
10, 2008. The person(s) controlling the copyright in some of this 10, 2008. The person(s) controlling the copyright in some of this
material may not have granted the IETF Trust the right to allow material may not have granted the IETF Trust the right to allow
modifications of such material outside the IETF Standards Process. modifications of such material outside the IETF Standards Process.
Without obtaining an adequate license from the person(s) controlling Without obtaining an adequate license from the person(s) controlling
the copyright in such materials, this document may not be modified the copyright in such materials, this document may not be modified
outside the IETF Standards Process, and derivative works of it may outside the IETF Standards Process, and derivative works of it may
not be created outside the IETF Standards Process, except to format not be created outside the IETF Standards Process, except to format
it for publication as an RFC or to translate it into languages other it for publication as an RFC or to translate it into languages other
than English. than English.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 7 1. Introduction ....................................................6
2. Conventions Used in This Document ...............................6
2. Conventions Used in This Document . . . . . . . . . . . . . . 8 3. Overview of Performance Metrics .................................6
4. A Singleton Definition for Single Unidirectional LSP
3. Overview of Performance Metrics . . . . . . . . . . . . . . . 9 Setup Delay .....................................................7
4.1. Motivation .................................................7
4. A Singleton Definition for Single Unidirectional LSP Setup 4.2. Metric Name ................................................7
Delay . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10 4.3. Metric Parameters ..........................................8
4.1. Motivation . . . . . . . . . . . . . . . . . . . . . . . . 10 4.4. Metric Units ...............................................8
4.2. Metric Name . . . . . . . . . . . . . . . . . . . . . . . 10 4.5. Definition .................................................8
4.3. Metric Parameters . . . . . . . . . . . . . . . . . . . . 10 4.6. Discussion .................................................8
4.4. Metric Units . . . . . . . . . . . . . . . . . . . . . . . 11 4.7. Methodologies ..............................................9
4.5. Definition . . . . . . . . . . . . . . . . . . . . . . . . 11 4.8. Metric Reporting ...........................................9
4.6. Discussion . . . . . . . . . . . . . . . . . . . . . . . . 11 5. A Singleton Definition for Multiple Unidirectional LSPs
4.7. Methodologies . . . . . . . . . . . . . . . . . . . . . . 12 Setup Delay ....................................................10
4.8. Metric Reporting . . . . . . . . . . . . . . . . . . . . . 12 5.1. Motivation ................................................10
5.2. Metric Name ...............................................10
5. A Singleton Definition for Multiple Unidirectional LSP 5.3. Metric Parameters .........................................10
Setup Delay . . . . . . . . . . . . . . . . . . . . . . . . . 13 5.4. Metric Units ..............................................10
5.1. Motivation . . . . . . . . . . . . . . . . . . . . . . . . 13 5.5. Definition ................................................11
5.2. Metric Name . . . . . . . . . . . . . . . . . . . . . . . 13 5.6. Discussion ................................................11
5.3. Metric Parameters . . . . . . . . . . . . . . . . . . . . 13 5.7. Methodologies .............................................12
5.4. Metric Units . . . . . . . . . . . . . . . . . . . . . . . 13 5.8. Metric Reporting ..........................................13
5.5. Definition . . . . . . . . . . . . . . . . . . . . . . . . 13 6. A Singleton Definition for Single Bidirectional LSP
5.6. Discussion . . . . . . . . . . . . . . . . . . . . . . . . 14 Setup Delay ....................................................13
5.7. Methodologies . . . . . . . . . . . . . . . . . . . . . . 15 6.1. Motivation ................................................13
5.8. Metric Reporting . . . . . . . . . . . . . . . . . . . . . 16 6.2. Metric Name ...............................................14
6.3. Metric Parameters .........................................14
6. A Singleton Definition for Single Bidirectional LSP Setup 6.4. Metric Units ..............................................14
Delay . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17 6.5. Definition ................................................14
6.1. Motivation . . . . . . . . . . . . . . . . . . . . . . . . 17 6.6. Discussion ................................................15
6.2. Metric Name . . . . . . . . . . . . . . . . . . . . . . . 17 6.7. Methodologies .............................................15
6.3. Metric Parameters . . . . . . . . . . . . . . . . . . . . 17 6.8. Metric Reporting ..........................................16
6.4. Metric Units . . . . . . . . . . . . . . . . . . . . . . . 18 7. A Singleton Definition for Multiple Bidirectional LSPs
6.5. Definition . . . . . . . . . . . . . . . . . . . . . . . . 18 Setup Delay ....................................................16
6.6. Discussion . . . . . . . . . . . . . . . . . . . . . . . . 18 7.1. Motivation ................................................16
6.7. Methodologies . . . . . . . . . . . . . . . . . . . . . . 19 7.2. Metric Name ...............................................16
6.8. Metric Reporting . . . . . . . . . . . . . . . . . . . . . 19 7.3. Metric Parameters .........................................17
7.4. Metric Units ..............................................17
7. A Singleton Definition for Multiple Bidirectional LSPs 7.5. Definition ................................................17
Setup Delay . . . . . . . . . . . . . . . . . . . . . . . . . 21 7.6. Discussion ................................................18
7.1. Motivation . . . . . . . . . . . . . . . . . . . . . . . . 21 7.7. Methodologies .............................................19
7.2. Metric Name . . . . . . . . . . . . . . . . . . . . . . . 21 7.8. Metric Reporting ..........................................19
7.3. Metric Parameters . . . . . . . . . . . . . . . . . . . . 21 8. A Singleton Definition for LSP Graceful Release Delay ..........20
7.4. Metric Units . . . . . . . . . . . . . . . . . . . . . . . 21 8.1. Motivation ................................................20
7.5. Definition . . . . . . . . . . . . . . . . . . . . . . . . 21 8.2. Metric Name ...............................................20
7.6. Discussion . . . . . . . . . . . . . . . . . . . . . . . . 22 8.3. Metric Parameters .........................................20
7.7. Methodologies . . . . . . . . . . . . . . . . . . . . . . 23 8.4. Metric Units ..............................................20
7.8. Metric Reporting . . . . . . . . . . . . . . . . . . . . . 24 8.5. Definition ................................................20
8.6. Discussion ................................................22
8. A Singleton Definition for LSP Graceful Release Delay . . . . 25 8.7. Methodologies .............................................22
8.1. Motivation . . . . . . . . . . . . . . . . . . . . . . . . 25 8.8. Metric Reporting ..........................................23
8.2. Metric Name . . . . . . . . . . . . . . . . . . . . . . . 25 9. A Definition for Samples of Single Unidirectional LSP
8.3. Metric Parameters . . . . . . . . . . . . . . . . . . . . 25 Setup Delay ....................................................24
8.4. Metric Units . . . . . . . . . . . . . . . . . . . . . . . 25 9.1. Metric Name ...............................................24
8.5. Definition . . . . . . . . . . . . . . . . . . . . . . . . 25 9.2. Metric Parameters .........................................24
8.6. Discussion . . . . . . . . . . . . . . . . . . . . . . . . 26 9.3. Metric Units ..............................................24
8.7. Methodologies . . . . . . . . . . . . . . . . . . . . . . 27 9.4. Definition ................................................24
8.8. Metric Reporting . . . . . . . . . . . . . . . . . . . . . 28 9.5. Discussion ................................................25
9.6. Methodologies .............................................25
9. A Definition for Samples of Single Unidirectional LSP 9.7. Typical Testing Cases .....................................26
Setup Delay . . . . . . . . . . . . . . . . . . . . . . . . . 29 9.7.1. With No LSP in the Network .........................26
9.1. Metric Name . . . . . . . . . . . . . . . . . . . . . . . 29 9.7.2. With a Number of LSPs in the Network ...............26
9.2. Metric Parameters . . . . . . . . . . . . . . . . . . . . 29 9.8. Metric Reporting ..........................................26
9.3. Metric Units . . . . . . . . . . . . . . . . . . . . . . . 29 10. A Definition for Samples of Multiple Unidirectional
9.4. Definition . . . . . . . . . . . . . . . . . . . . . . . . 29 LSPs Setup Delay ..............................................26
9.5. Discussion . . . . . . . . . . . . . . . . . . . . . . . . 30 10.1. Metric Name ..............................................27
9.6. Methodologies . . . . . . . . . . . . . . . . . . . . . . 30 10.2. Metric Parameters ........................................27
9.7. Typical testing cases . . . . . . . . . . . . . . . . . . 31 10.3. Metric Units .............................................27
9.7.1. With no LSP in the Network . . . . . . . . . . . . . . 31 10.4. Definition ...............................................27
9.7.2. With a number of LSPs in the Network . . . . . . . . . 31 10.5. Discussion ...............................................28
9.8. Metric Reporting . . . . . . . . . . . . . . . . . . . . . 31 10.6. Methodologies ............................................28
10.7. Typical Testing Cases ....................................29
10. A Definition for Samples of Multiple Unidirectional LSPs 10.7.1. With No LSP in the Network ........................29
Setup Delay . . . . . . . . . . . . . . . . . . . . . . . . . 32 10.7.2. With a Number of LSPs in the Network ..............29
10.1. Metric Name . . . . . . . . . . . . . . . . . . . . . . . 32 10.8. Metric Reporting .........................................29
10.2. Metric Parameters . . . . . . . . . . . . . . . . . . . . 32 11. A Definition for Samples of Single Bidirectional LSP
10.3. Metric Units . . . . . . . . . . . . . . . . . . . . . . . 32 Setup Delay ...................................................30
10.4. Definition . . . . . . . . . . . . . . . . . . . . . . . . 32 11.1. Metric Name ..............................................30
10.5. Discussion . . . . . . . . . . . . . . . . . . . . . . . . 33 11.2. Metric Parameters ........................................30
10.6. Methodologies . . . . . . . . . . . . . . . . . . . . . . 33 11.3. Metric Units .............................................30
10.7. Typical testing cases . . . . . . . . . . . . . . . . . . 34 11.4. Definition ...............................................30
10.7.1. With No LSP in the Network . . . . . . . . . . . . . . 34 11.5. Discussion ...............................................31
10.7.2. With a Number of LSPs in the Network . . . . . . . . . 34 11.6. Methodologies ............................................31
10.8. Metric Reporting . . . . . . . . . . . . . . . . . . . . . 34 11.7. Typical Testing Cases ....................................32
11.7.1. With No LSP in the Network ........................32
11. A Definition for Samples of Single Bidirectional LSP Setup 11.7.2. With a Number of LSPs in the Network ..............32
Delay . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35 11.8. Metric Reporting .........................................32
11.1. Metric Name . . . . . . . . . . . . . . . . . . . . . . . 35 12. A Definition for Samples of Multiple Bidirectional
11.2. Metric Parameters . . . . . . . . . . . . . . . . . . . . 35 LSPs Setup Delay ..............................................32
11.3. Metric Units . . . . . . . . . . . . . . . . . . . . . . . 35 12.1. Metric Name ..............................................33
11.4. Definition . . . . . . . . . . . . . . . . . . . . . . . . 35 12.2. Metric Parameters ........................................33
11.5. Discussion . . . . . . . . . . . . . . . . . . . . . . . . 36 12.3. Metric Units .............................................33
11.6. Methodologies . . . . . . . . . . . . . . . . . . . . . . 36 12.4. Definition ...............................................33
11.7. Typical testing cases . . . . . . . . . . . . . . . . . . 37 12.5. Discussion ...............................................34
11.7.1. With No LSP in the Network . . . . . . . . . . . . . . 37 12.6. Methodologies ............................................34
11.7.2. With a Number of LSPs in the Network . . . . . . . . . 37 12.7. Typical Testing Cases ....................................35
11.8. Metric Reporting . . . . . . . . . . . . . . . . . . . . . 37 12.7.1. With No LSP in the Network ........................35
12.7.2. With a Number of LSPs in the Network ..............35
12. A Definition for Samples of Multiple Bidirectional LSPs 12.8. Metric Reporting .........................................35
Setup Delay . . . . . . . . . . . . . . . . . . . . . . . . . 38 13. A Definition for Samples of LSP Graceful Release Delay ........35
12.1. Metric Name . . . . . . . . . . . . . . . . . . . . . . . 38 13.1. Metric Name ..............................................36
12.2. Metric Parameters . . . . . . . . . . . . . . . . . . . . 38 13.2. Metric Parameters ........................................36
12.3. Metric Units . . . . . . . . . . . . . . . . . . . . . . . 38 13.3. Metric Units .............................................36
12.4. Definition . . . . . . . . . . . . . . . . . . . . . . . . 38 13.4. Definition ...............................................36
12.5. Discussion . . . . . . . . . . . . . . . . . . . . . . . . 39 13.5. Discussion ...............................................36
12.6. Methodologies . . . . . . . . . . . . . . . . . . . . . . 39 13.6. Methodologies ............................................37
12.7. Typical testing cases . . . . . . . . . . . . . . . . . . 40 13.7. Metric Reporting .........................................37
12.7.1. With No LSP in the Network . . . . . . . . . . . . . . 40 14. Some Statistics Definitions for Metrics to Report .............37
12.7.2. With a Number of LSPs in the Network . . . . . . . . . 40 14.1. The Minimum of Metric ....................................37
12.8. Metric Reporting . . . . . . . . . . . . . . . . . . . . . 40 14.2. The Median of Metric .....................................37
14.3. The Maximum of Metric ....................................38
13. A Definition for Samples of LSP Graceful Release Delay . . . . 41 14.4. The Percentile of Metric .................................38
13.1. Metric Name . . . . . . . . . . . . . . . . . . . . . . . 41 14.5. Failure Statistics of Metric .............................38
13.2. Metric Parameters . . . . . . . . . . . . . . . . . . . . 41 14.5.1. Failure Count .....................................39
13.3. Metric Units . . . . . . . . . . . . . . . . . . . . . . . 41 14.5.2. Failure Ratio .....................................39
13.4. Definition . . . . . . . . . . . . . . . . . . . . . . . . 41 15. Discussion ....................................................39
13.5. Discussion . . . . . . . . . . . . . . . . . . . . . . . . 41 16. Security Considerations .......................................40
13.6. Methodologies . . . . . . . . . . . . . . . . . . . . . . 42 17. Acknowledgments ...............................................41
13.7. Metric Reporting . . . . . . . . . . . . . . . . . . . . . 42 18. References ....................................................41
18.1. Normative References .....................................41
14. Some Statistics Definitions for Metrics to Report . . . . . . 43 18.2. Informative References ...................................42
14.1. The Minimum of Metric . . . . . . . . . . . . . . . . . . 43 Appendix A. Authors' Addresses ...................................43
14.2. The Median of Metric . . . . . . . . . . . . . . . . . . . 43
14.3. The Maximum of Metric . . . . . . . . . . . . . . . . . . 43
14.4. The Percentile of Metric . . . . . . . . . . . . . . . . . 43
14.5. Failure statistics of Metric . . . . . . . . . . . . . . . 43
14.5.1. Failure Count . . . . . . . . . . . . . . . . . . . . 44
14.5.2. Failure Ratio . . . . . . . . . . . . . . . . . . . . 44
15. Discussion . . . . . . . . . . . . . . . . . . . . . . . . . . 45
16. Security Considerations . . . . . . . . . . . . . . . . . . . 46
17. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 47
18. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 48
19. References . . . . . . . . . . . . . . . . . . . . . . . . . . 49
19.1. Normative References . . . . . . . . . . . . . . . . . . . 49
19.2. Informative References . . . . . . . . . . . . . . . . . . 49
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. These physically diverse devices differ
physically diverse devices differs from each other drastically. drastically from one another in dynamic provisioning ability.
The introduction of a control plane into optical circuit switching The introduction of a control plane into optical circuit switching
networks provides the basis for automating the provisioning of networks provides the basis for automating the provisioning of
connections and drastically reduces connection provision delay. As connections and drastically reduces connection provision delay. As
more and more services and applications are seeking to use GMPLS more and more services and applications are seeking to use GMPLS-
controlled networks as their underlying transport network, and controlled networks as their underlying transport network, and
increasingly in a dynamic way, the need is growing for measuring and increasingly in a dynamic way, the need is growing for measuring and
characterizing the performance of LSP provisioning in GMPLS networks, characterizing the performance of LSP provisioning in GMPLS networks,
such that requirement from applications and the provisioning such that requirement from applications and the provisioning
capability of the network can be mapped to each other. capability of the network can be mapped to each other.
This draft defines performance metrics and methodologies that can be This document defines performance metrics and methodologies that can
used to characterize the dynamic LSP provisioning performance of be used to characterize the dynamic LSP provisioning performance of
GMPLS networks, more specifically, performance of the signaling GMPLS networks, more specifically, performance of the signaling
protocol. The metrics defined in this document can be used to protocol. The metrics defined in this document can be used to
characterize the average performance of GMPLS implementations. characterize the average performance of GMPLS implementations.
2. Conventions Used in This Document 2. Conventions Used in This Document
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [RFC2119]. document are to be interpreted as described in [RFC2119].
3. Overview of Performance Metrics 3. Overview of Performance Metrics
In this memo, to characterize the dynamic LSP provisioning In this memo, to characterize the dynamic LSP provisioning
performance of a GMPLS network, we define 3 performance metrics: performance of a GMPLS network, we define three performance metrics:
unidirectional LSP setup delay, bidirectional LSP setup delay, and unidirectional LSP setup delay, bidirectional LSP setup delay, and
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 IP Performance Metrics (IPPM)
[RFC2679] [RFC2681]. The reader is assumed to be familiar with the Framework documents, [RFC2330] [RFC2679] [RFC2681]. The reader is
notions in those documents. assumed to be familiar with the 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 a Resv message by the ingress node and when the
becomes operational, are defined in another document forward data path becomes operational, are defined in another
[I-D.sun-ccamp-dpm]. It is desirable that both measurements are document [CCAMP-DPM]. It is desirable that both measurements are
performed to complement each other. 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 section defines a metric for single unidirectional Label
Path setup delay across a GMPLS network. Switched 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:
o Single LSP setup delay is an important metric that characterizes o Single LSP setup delay is an important metric that characterizes
the provisioning performance of a GMPLS network. Longer LSP setup the provisioning performance of a GMPLS network. Longer LSP setup
delay will most likely incur higher overhead for the requesting delay will most likely incur higher overhead for the requesting
application, especially when the LSP duration itself is comparable application, especially when the LSP duration itself is comparable
to the LSP setup delay. to the LSP setup delay.
o The minimum value of this metric provides an indication of the o The minimum value of this metric provides an indication of the
delay that will likely be experienced when the LSP traversed the delay that will likely be experienced when the LSP traverses the
shortest route at the lightest load in the control plane. As the shortest route at the lightest load in the control plane. As the
delay itself consists of several components, such as link delay itself consists of several components, such as link
propagation delay and nodal processing delay, this metric also propagation delay and nodal processing delay, this metric also
reflects the status of control plane. For example, for LSPs reflects the status of the control plane. For example, for LSPs
traversing the same route, longer setup delays may suggest traversing the same route, longer setup delays may suggest
congestion in the control channel or high control element load. congestion in the control channel or high control element load.
For this reason, this metric is useful for testing and diagnostic For this reason, this metric is useful for testing and diagnostic
purposes. purposes.
o The observed variance in a sample of LSP setup delay metric values o The observed variance in a sample of LSP setup delay metric values
variance may serve as an early indicator on the feasibility of variance may serve as an early indicator on the feasibility of
support of applications that have stringent setup delay support of applications that have stringent setup delay
requirements. requirements.
skipping to change at page 10, line 50 skipping to change at page 8, line 7
o Some applications may use only unidirectional LSPs rather than o Some applications may use only unidirectional LSPs rather than
bidirectional ones. For example, content delivery services with bidirectional ones. For example, content delivery services with
multicasting may use only unidirectional LSPs. multicasting may use only unidirectional LSPs.
4.2. Metric Name 4.2. Metric Name
Single unidirectional LSP setup delay Single unidirectional LSP setup delay
4.3. Metric Parameters 4.3. Metric Parameters
o ID0, the ingress LSR ID o ID0, the ingress Label Switching Router (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 of milliseconds, or undefined. 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
The following issues are likely to come up in practice: The following issues are likely to come up in practice:
o The accuracy of unidirectional LSP setup delay at time T depends o The accuracy of unidirectional LSP setup delay at time T depends
on the clock resolution in the ingress node; but synchronization on the clock resolution in the ingress node; but synchronization
between the ingress node and egress node is not required since between the ingress node and egress node is not required since
unidirectional LSP setup uses two-way signaling. unidirectional LSP setup uses two-way signaling.
o A given methodology will have to include a way to determine o A given methodology will have to include a way to determine
whether a latency value is infinite or whether it is merely very whether a latency value is infinite or whether it is merely very
large. Simple upper bounds 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 the common electronic motion may take several milliseconds, but the common electronic
switches can finish the nodal processing within several switches can finish the nodal processing within several
microseconds. So the unidirectional LSP setup delay varies microseconds. So the unidirectional LSP setup delay varies
drastically from one network to another. In practice, the upper drastically from one network to another. In practice, the upper
bound SHOULD be chosen carefully. bound SHOULD be chosen carefully.
o If ingress node sends out the Path message to set up an LSP, but o If the ingress node sends out the Path message to set up an LSP,
never receives the corresponding Resv message, the unidirectional but never receives the corresponding Resv message, the
LSP setup delay MUST be set to undefined. unidirectional LSP setup delay MUST be set to undefined.
o If the ingress node sends out the Path message to set up an LSP o If the ingress node sends out the Path message to set up an LSP
but receives a PathErr message, the unidirectional LSP setup delay but receives a PathErr message, the unidirectional LSP setup delay
MUST be set to undefined. There are many possible reasons for MUST be set to undefined. There are many possible reasons for
this case. For example, the Path message has invalid parameters this case; for example, the Path message has invalid parameters or
or the network does not have enough resource to set up the the network does not have enough resources to set up the requested
requested LSP, etc. LSP, etc.
4.7. Methodologies 4.7. Methodologies
Generally the methodology would proceed as follows: Generally, the methodology would proceed as follows:
o Make sure that the network has enough resource to set up the o Make sure that the network has enough resources to set up the
requested LSP. requested LSP.
o At the ingress node, form the Path message according to the LSP o At the ingress node, form the Path message according to the LSP
requirements. A timestamp (T1) may be stored locally 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 number or undefined) MUST be The metric result (either a real number or undefined) MUST be
reported together with the selected upper 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 LSPs Setup Delay
This part defines a metric for multiple unidirectional Label Switched This section defines a metric for multiple unidirectional Label
Paths setup delay across a GMPLS network. Switched 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 that a large number of LSPs be set up during
short time period. This request may arise e.g. as a consequence a short time period. This request may arise, e.g., as a
to interruptions on established LSPs or other network failures. consequence to interruptions on established LSPs or other network
failures.
o The time needed to set up 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 cannot 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 set up 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 of milliseconds, or undefined. 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 If the multiple unidirectional LSPs setup delay at T is "undefined",
that ingress node ID0 sends all the Path messages toward egress node this means that:
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 o ingress node ID0 sends all the Path messages toward egress node
the corresponding Resv messages within a reasonable period of time. ID1,
o the first bit of the first Path message packet is sent at wire-
time T, and
o ingress node ID0 does not receive one or more of 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.
5.6. Discussion 5.6. Discussion
The following issues are likely to come up in practice: The following issues are likely to come up in practice:
o The accuracy of multiple unidirectional LSPs setup delay at time T o The accuracy of multiple unidirectional LSPs setup delay at time T
depends on the clock resolution in the ingress node; but depends on the clock resolution in the ingress node; but
synchronization between the ingress node and egress node is not synchronization between the ingress node and egress node is not
required since unidirectional LSP setup uses two-way signaling. required since unidirectional LSP setup uses two-way signaling.
o A given methodology will have to include a way to determine o A given methodology will have to include a way to determine
whether a latency value is infinite or whether it is merely very whether a latency value is infinite or whether it is merely very
large. Simple upper bounds 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
multiple unidirectional LSP setup delay varies drastically from multiple unidirectional LSP setup delay varies drastically from
one network to another. In practice, the upper bound SHOULD be one network to another. In practice, the upper bound SHOULD be
chosen carefully. chosen carefully.
o If ingress node sends out the multiple Path messages to set up the o If the ingress node sends out the multiple Path messages to set up
LSPs, but never receives one or more of the corresponding Resv the LSPs, but never receives one or more of the corresponding Resv
messages, multiple unidirectional LSP setup delay MUST be set to messages, multiple unidirectional LSP setup delay MUST be set to
undefined. undefined.
o If ingress node sends out the Path messages to set up the LSPs but o If the ingress node sends out the Path messages to set up the LSPs
receives one or more PathErr messages, multiple unidirectional but receives one or more PathErr messages, multiple unidirectional
LSPs setup delay MUST be set to undefined. There are many LSPs setup delay MUST be set to undefined. There are many
possible reasons for this case. For example, one of the Path possible reasons for this case. For example, one of the Path
messages has invalid parameters or the network has not enough messages has invalid parameters or the network does not have
resource to set up the requested LSPs, etc. enough resources to set up the requested LSPs, etc.
o The arrival rate of the Poisson process Lambda_m SHOULD be chosen o The arrival rate of the Poisson process Lambda_m SHOULD be chosen
carefully such that in the one hand the control plane is not carefully such that on the one hand, the control plane is not
overburdened. On the other hand, the arrival rate is large enough overburdened. On the other hand, the arrival rate is large enough
to meet the requirements of applications or services. to meet the requirements of applications or services.
o It is important that all the LSPs MUST traverse the same route. o It is important that all the LSPs MUST traverse the same route.
If there are multiple routes between the Ingress node ID0 and If there are multiple routes between the ingress node ID0 and
Egress node ID1, EROs or an alternate method, e.g., static egress node ID1, Explicit Route Objects (EROs), or an alternate
configuration, MUST be used to ensure that all LSPs traverse the method, e.g., static configuration, MUST be used to ensure that
same route. all LSPs traverse the same route.
5.7. Methodologies 5.7. Methodologies
Generally the methodology would proceed as follows: Generally, the methodology would proceed as follows:
o Make sure that the network has enough resource to set up the o Make sure that the network has enough resources to set up the
requested LSPs. requested LSPs.
o At the ingress node, form the Path messages according to the LSPs' o At the ingress node, form the Path messages according to the LSPs'
requirements. requirements.
o At the ingress node, select the time for each of the Path messages o At the ingress node, select the time for each of the Path messages
according to the specified Poisson process. according to the specified Poisson process.
o At the ingress node, 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.
skipping to change at page 15, line 44 skipping to change at page 13, line 14
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 responses are PathErr
the multiple unidirectional LSPs setup delay is deemed to be messages, the multiple unidirectional LSPs setup delay is deemed
undefined. to be undefined.
5.8. Metric Reporting 5.8. Metric Reporting
The metric result (either a real number or undefined) MUST be The metric result (either a real number or undefined) MUST be
reported together with the selected upper 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 section defines a metric for single
bidirectional LSP setup delay across a GMPLS network. bidirectional LSP setup delay across a GMPLS network.
6.1. Motivation 6.1. Motivation
Single bidirectional Label Switched Path setup delay is useful for Single bidirectional Label Switched Path setup delay is useful for
several reasons: several reasons:
o LSP setup delay is an important metric that characterizes the o LSP setup delay is an important metric that characterizes the
provisioning performance of a GMPLS network. Longer LSP setup provisioning performance of a GMPLS network. Longer LSP setup
delay will incur higher overhead for the requesting application, delay will incur higher overhead for the requesting application,
especially when the LSP duration is comparable to the LSP setup especially when the LSP duration is comparable to the LSP setup
delay. Thus, measuring the setup delay is important for delay. Thus, measuring the setup delay is important for
application scheduling. application scheduling.
o The minimum value of this metric provides an indication of the o The minimum value of this metric provides an indication of the
delay that will likely be experienced when the LSP traversed the delay that will likely be experienced when the LSP traverses the
shortest route at the lightest load in the control plane. As the shortest route at the lightest load in the control plane. As the
delay itself consists of several components, such as link delay itself consists of several components, such as link
propagation delay and nodal processing delay, this metric also propagation delay and nodal processing delay, this metric also
reflects the status of control plane. For example, for LSPs reflects the status of the control plane. For example, for LSPs
traversing the same route, longer setup delays may suggest traversing the same route, longer setup delays may suggest
congestion in the control channel or high control element load. congestion in the control channel or high control element load.
For this reason, this metric is useful for testing and diagnostic For this reason, this metric is useful for testing and diagnostic
purposes. purposes.
o LSP setup delay variance has different impact on applications. o LSP setup delay variance has a different impact on applications.
Erratic variation in LSP setup delay makes it difficult to support Erratic variation in LSP setup delay makes it difficult to support
applications that have stringent setup delay requirement. applications that have stringent setup delay requirement.
The measurement of single bidirectional LSP setup delay instead of The measurement of single bidirectional LSP setup delay instead of
unidirectional LSP setup delay is motivated by the following factors: unidirectional LSP setup delay is motivated by the following factors:
o Bidirectional LSPs are seen as a requirement for many GMPLS o Bidirectional LSPs are seen as a requirement for many GMPLS
networks. Its provisioning performance is important to networks. Its provisioning performance is important to
applications that generate bidirectional traffic. applications that generate bidirectional traffic.
skipping to change at page 18, line 4 skipping to change at page 14, line 25
o Bidirectional LSPs are seen as a requirement for many GMPLS o Bidirectional LSPs are seen as a requirement for many GMPLS
networks. Its provisioning performance is important to networks. Its provisioning performance is important to
applications that generate bidirectional traffic. applications that generate bidirectional traffic.
6.2. Metric Name 6.2. Metric Name
Single bidirectional LSP setup delay Single bidirectional LSP setup delay
6.3. Metric Parameters 6.3. Metric Parameters
o ID0, the ingress LSR ID o ID0, the ingress LSR ID
o ID1, the egress LSR ID o ID1, the egress LSR ID
o 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 of milliseconds, or undefined. 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 If 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", this means that ingress node ID0
the first bit of Path message to egress node ID1 at wire-time T and sends the first bit of a Path message to egress node ID1 at wire-time
that ingress node ID0 does not receive that response packet within a T and that ingress node ID0 does not receive that response packet
reasonable period of time. 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
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
The following issues are likely to come up in practice: The following issues are likely to come up in practice:
o The accuracy of single bidirectional LSP setup delay depends on o The accuracy of single bidirectional LSP setup delay depends on
the clock resolution in the ingress node; but synchronization the clock resolution in the ingress node; but synchronization
between the ingress node and egress node is not required since between the ingress node and egress node is not required since
single bidirectional LSP setup uses two-way signaling. single bidirectional LSP setup uses two-way signaling.
o A given methodology will have to include a way to determine o A given methodology will have to include a way to determine
whether a latency value is infinite or whether it is merely very whether a latency value is infinite or whether it is merely very
large. Simple upper bounds 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
parameters or the network has not enough resource to set up the parameters or the network does not have enough resources to set up
requested LSP. the requested LSP.
6.7. Methodologies 6.7. Methodologies
Generally the methodology would proceed as follows: Generally, the methodology would proceed as follows:
o Make sure that the network has enough resource to set up the o Make sure that the network has enough resources to set up the
requested LSP. requested LSP.
o At the ingress node, form the Path message (including the Upstream o At the ingress node, form the Path message (including the Upstream
Label or suggested label) according to the LSP requirements. A Label or suggested label) according to the LSP requirements. A
timestamp (T1) may be stored locally 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 number or undefined) MUST be The metric result (either a real number or undefined) MUST be
reported together with the selected upper 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 section 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 set up 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 cannot 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 set up 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 of milliseconds, or undefined. 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 If 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", this means that the ingress node
Path messages to egress node and that the ingress node fails to sends all the Path messages to the egress node and that the ingress
receive one or more of the response Resv messages within a reasonable node fails to receive one or more of the response Resv messages
period of time. 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
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
or more of the Path messages have invalid parameters or the or more of the Path messages have invalid parameters or the
network has not enough resource to set up the requested LSPs. network does not have enough resources to set up the requested
LSPs.
o The arrival rate of the Poisson process Lambda_m SHOULD be o The arrival rate of the Poisson process Lambda_m SHOULD be
carefully chosen such that on the one hand the control plane is carefully chosen such that on the one hand, the control plane is
not overburdened. On the other hand, the arrival rate is large not overburdened. On the other hand, the arrival rate is large
enough to meet the requirements of applications or services. enough to meet the requirements of applications or services.
o It is important that all the LSPs MUST traverse the same route. o It is important that all the LSPs MUST traverse the same route.
If there are multiple routes between the Ingress node ID0 and If there are multiple routes between the ingress node ID0 and
Egress node ID1, EROs or an alternate method, e.g., static egress node ID1, EROs, or an alternate method, e.g., static
configuration, MUST be used to ensure that all LSPs traverse the configuration, MUST be used to ensure that all LSPs traverse the
same route. same route.
7.7. Methodologies 7.7. Methodologies
Generally the methodology would proceed as follows: Generally, the methodology would proceed as follows:
o Make sure that the network has enough resource to set up the o Make sure that the network has enough resources to set up the
requested LSPs. requested LSPs.
o At the ingress node, form the Path messages (including the o At the ingress node, form the Path messages (including the
Upstream Label or suggested label) according to the LSPs' Upstream Label or suggested label) according to the LSPs'
requirements. requirements.
o At the ingress node, select the time for each of the Path messages o At the ingress node, select the time for each of the Path messages
according to the specified Poisson process. according to the specified Poisson process.
o At the ingress node, send out the Path messages according to the o At the ingress node, send out the Path messages according to the
skipping to change at page 23, line 49 skipping to change at page 19, line 34
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 responses are PathErr
the multiple bidirectional LSPs setup delay is deemed to be messages, the multiple bidirectional LSPs setup delay is deemed to
undefined. be undefined.
7.8. Metric Reporting 7.8. Metric Reporting
The metric result (either a real number or undefined) MUST be The metric result (either a real number or undefined) MUST be
reported together with the selected upper 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.
skipping to change at page 25, line 17 skipping to change at page 20, line 17
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.
8.1. Motivation 8.1. Motivation
LSP graceful release delay is useful for several reasons: LSP graceful release delay is useful for several reasons:
o The LSP graceful release delay is part of the total cost of o The LSP graceful release delay is part of the total cost of
dynamic LSP provisioning. For some short duration applications, dynamic LSP provisioning. For some short duration applications,
the LSP release time can not be ignored the LSP release time cannot be ignored.
o The LSP graceful release procedure is more preferred in a GMPLS o The LSP graceful release procedure is more preferred in a GMPLS
controlled network, particularly the optical networks. Since it controlled network, particularly the optical networks. Since it
doesn't trigger restoration/protection, it is "alarm-free doesn't trigger restoration/protection, it is "alarm-free
connection deletion" in [RFC4208]. connection deletion" in [RFC4208].
8.2. Metric Name 8.2. Metric Name
LSP graceful release delay LSP graceful release delay
skipping to change at page 25, line 39 skipping to change at page 20, line 39
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 of The value of LSP graceful release delay is either a real number of
milliseconds, or undefined. 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, if 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, this means that ingress node
sends the first bit of a Path message including Admin Status Object ID0 sends the first bit of a Path message including an Admin Status
with the Reflect (R) and Delete (D) bits set to the egress node at Object with the Reflect (R) and Delete (D) bits set to the egress
wire-time T, that egress node ID1 receives that packet, then node at wire-time T, that egress node ID1 receives that packet, then
immediately sends a Resv message including Admin Status Object with immediately sends a Resv message including an Admin Status Object
the Delete (D) bit set back to the ingress node. Ingress node ID0 with the Delete (D) bit set back to the ingress node. Ingress node
sends out PathTear downstream to remove the LSP, and egress node ID1 ID0 sends the PathTear message downstream to remove the LSP, and
receives the last bit of PathTear packet at wire-time T+dT. egress node ID1 receives the last bit of PathTear packet at wire-time
T+dT.
Also as an option, upon receipt of the Path message including Admin Also, as an option, upon receipt of the Path message including an
Status Object with the Reflect (R) and Delete (D) bits set, egress Admin Status Object with the Reflect (R) and Delete (D) bits set,
node ID1 may respond with a PathErr message with the egress 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 bit ID1 at T is undefined means that ingress node ID0 sends the first bit
of Path message to egress node ID1 at wire-time T and that (either of Path message to egress node ID1 at wire-time T and that (either
egress node does not receive the Path packet, egress node does not the egress node does not receive the Path packet, the egress node
send corresponding Resv message packet in response, or ingress node does not send a corresponding Resv message packet in response, or the
does not receive that Resv packet, and) egress node ID1 does not ingress node does not receive that Resv packet, and) egress node ID1
receive the PathTear within a reasonable period of time. does not receive the PathTear message within a reasonable period of
time.
The LSP graceful release delay from egress node ID1 to ingress node If the LSP graceful release delay from egress node ID1 to ingress
ID0 at T is dT means that egress node ID1 sends the first bit of a node ID0 at T is dT, this means that egress node ID1 sends the first
Resv message including Admin Status Object with setting the Reflect bit of a Resv message including an Admin Status Object with the
(R) and Delete (D) bits to ingress node at wire-time T. Ingress node Reflect (R) and Delete (D) bits set to the ingress node at wire-time
ID0 sends out PathTear downstream to remove the LSP, and egress node T. Ingress node ID0 sends a PathTear message downstream to remove
ID1 receives the last bit of PathTear packet at wire-time T+dT. the LSP, and egress node ID1 receives the last bit of PathTear packet
at wire-time T+dT.
The LSP graceful release delay from egress node ID1 to ingress node If the LSP graceful release delay from egress node ID1 to ingress
ID0 at T is undefined means that egress node ID1 sends the first bit node ID0 at T is "undefined", this means that egress node ID1 sends
of Resv message including Admin Status Object with setting the the first bit of Resv message including an Admin Status Object with
Reflect (R) and Delete (D) bits to ingress node ID0 at wire-time T the Reflect (R) and Delete (D) bits set to the ingress node ID0 at
and that (either ingress node does not receive the Resv packet, or wire-time T and that (either the ingress node does not receive the
ingress node does not send PathTear message packet in response, and) Resv packet or the ingress node does not send PathTear message packet
egress node ID1 does not receive the PathTear within a reasonable in response, and) egress node ID1 does not receive the PathTear
period of time. message within a reasonable 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
of LSP setup/release failures. of LSP setup/release failures.
8.6. Discussion 8.6. Discussion
The following issues are likely to come up in practice: The following issues are likely to come up in practice:
o In the first (second) circumstance, the accuracy of LSP graceful o In the first (second) circumstance, the accuracy of LSP graceful
release delay at time T depends on the clock resolution in the release delay at time T depends on the clock resolution in the
ingress (egress) node. In the first circumstance, synchronization ingress (egress) node. In the first circumstance, synchronization
between the ingress node and egress node is required; but not in between the ingress node and egress node is required, but it is
the second circumstance; not in the second circumstance.
o A given methodology has to include a way to determine whether a o A given methodology has to include a way to determine whether a
latency value is infinite or whether it is merely very large. latency value is infinite or whether it is merely very large.
Simple upper bounds MAY be used. But the upper bound SHOULD be Simple upper bounds MAY be used, but the upper bound SHOULD be
chosen carefully in practice; chosen carefully in practice.
o In the first circumstance, if the ingress node sends out Path o In the first circumstance, if the ingress node sends out Path
message including Admin Status Object with the Reflect (R) and message including an Admin Status Object with the Reflect (R) and
Delete (D) bits set to initiate LSP graceful release, but the Delete (D) bits set to initiate LSP graceful release, but the
egress node never receives the corresponding PathTear message, LSP egress node never receives the corresponding PathTear message, LSP
graceful release delay MUST be set to undefined. graceful release delay MUST be set to undefined.
o In the second circumstance, if the egress node sends out the Resv o In the second circumstance, if the egress node sends out the Resv
message including Admin Status Object with the Reflect (R) and message including an Admin Status Object with the Reflect (R) and
Delete (D) bits set to initiate LSP graceful release, but never Delete (D) bits set to initiate LSP graceful release, but never
receives the corresponding PathTear message, LSP graceful release receives the corresponding PathTear message, LSP graceful release
delay MUST be set to undefined. delay MUST be set to undefined.
8.7. Methodologies 8.7. Methodologies
In the first circumstance, the methodology may proceed as follows: In the first circumstance, the methodology may proceed as follows:
o Make sure the LSP to be deleted is set up; o Make sure the LSP to be deleted is set up;
o At the ingress node, form the Path message including Admin Status o At the ingress node, form the Path message including an Admin
Object with the Reflect (R) and Delete (D) bits set. A timestamp Status Object with the Reflect (R) and Delete (D) bits set. A
(T1) may be stored locally on the ingress node when the Path timestamp (T1) may be stored locally on the ingress node when the
message packet is sent towards the egress node; Path message packet is sent towards the egress node.
o Upon receiving the Path message including Admin Status Object with o Upon receiving the Path message including an Admin Status Object
the Reflect (R) and Delete (D) bits set, the egress node sends a with the Reflect (R) and Delete (D) bits set, the egress node
Resv message including Admin Status Object with the Delete (D) and sends a Resv message including an Admin Status Object with the
Reflect (R) bits set. Alternatively, the egress node sends a Delete (D) and Reflect (R) bits set. Alternatively, the egress
PathErr message with the Path_State_Removed flag set upstream; node sends a PathErr message with the Path_State_Removed flag set
upstream.
o When the ingress node receive the Resv message or the PathErr o When the ingress node receives the Resv message or the PathErr
message, it sends a PathTear message to remove the LSP; message, it sends a PathTear message to remove the LSP.
o The egress node takes a timestamp (T2) once it receives the last o The egress node takes a timestamp (T2) once it receives the last
bit of the PathTear message. The LSP graceful release delay is bit of the PathTear message. The LSP graceful release delay is
then (T2-T1). then (T2-T1).
o If the ingress node sends the Path message downstream, but the o If the ingress node sends the Path message downstream, but the
egress node fails to receive the PathTear message within a egress node fails to receive the PathTear message within a
reasonable period of time, the LSP graceful release delay is reasonable period of time, the LSP graceful release delay is
deemed to be undefined. Note that the 'reasonable' threshold is a deemed to be undefined. Note that the "reasonable" threshold is a
parameter of the methodology. parameter of the methodology.
In the second circumstance, the methodology would proceed as follows: In the second circumstance, the methodology would proceed as follows:
o Make sure the LSP to be deleted is set up; o Make sure the LSP to be deleted is set up;
o On the egress node, form the Resv message including Admin Status o On the egress node, form the Resv message including an Admin
Object with the Reflect (R) and Delete (D) bits set. A timestamp Status Object with the Reflect (R) and Delete (D) bits set. A
may be stored locally on the egress node when the Resv message timestamp may be stored locally on the egress node when the Resv
packet is sent towards the ingress node; message packet is sent towards the ingress node.
o Upon receiving the Admin Status Object with the Reflect (R) and o Upon receiving the Admin Status Object with the Reflect (R) and
Delete (D) bits set in the Resv message, the ingress node sends a Delete (D) bits set in the Resv message, the ingress node sends a
PathTear message downstream to remove the LSP; PathTear message downstream to remove the LSP.
o Egress node takes a timestamp (T2) once it receives the last bit o The egress node takes a timestamp (T2) once it receives the last
of the PathTear message. The LSP graceful release delay is then bit of the PathTear message. The LSP graceful release delay is
(T2-T1). then (T2-T1).
o If the 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 number or undefined) MUST be The metric result (either a real number or undefined) MUST be
reported together with the selected upper bound and the procedure reported together with the selected upper bound and the procedure
used (e.g., 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 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
means to take a number of distinct instances of a skeleton metric means to take a number of distinct instances of a skeleton metric
under a given set of parameters. Like in [RFC2330], we use Poisson under a given set of parameters. As in [RFC2330], we use Poisson
sampling as an 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
skipping to change at page 29, line 40 skipping to change at page 24, 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 of milliseconds, or undefined. 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. The value of the sample is the sequence made up of the
made up of the resulting <time, LSP setup delay> pairs. If there are resulting <time, LSP setup delay> pairs. If there are no such pairs,
no such pairs, the sequence is of length zero and the sample is said the sequence is of length zero and the sample is said to be empty.
to be empty.
9.5. Discussion 9.5. Discussion
The parameter Lambda should be carefully chosen. If the rate is too The parameter Lambda should be carefully chosen. If the rate is too
high, too frequent LSP setup/release procedure will result in high high, too frequent LSP setup/release procedure will result in high
overhead in the control plane. In turn, the high overhead will overhead in the control plane. In turn, the high overhead will
increase unidirectional LSP setup delay. On the other hand if the increase unidirectional LSP setup delay. On the other hand, if the
rate is too low, the sample could not completely reflect the dynamic rate is too low, the sample might not completely reflect the dynamic
provisioning performance of the GMPLS network. The appropriate provisioning performance of the GMPLS network. The appropriate
Lambda value depends on the given network. Lambda value depends on the given network.
The parameters Td should be carefully chosen. Different switching The parameters Td should be carefully chosen. Different switching
technologies may vary significantly in performing a cross-connect technologies may vary significantly in performing a cross-connect
operation. At the same time, the time needed in setting up an LSP operation. At the same time, the time needed in setting up an LSP
under different traffic may also vary significantly. under different traffic may also vary significantly.
In the case of active measurement, the parameters Th should be In the case of active measurement, the parameters Th should be
carefully chosen. The combination of Lambda and Th reflects the load carefully chosen. The combination of Lambda and Th reflects the load
of the network. The selection of Th should take into account that of the network. The selection of Th should take into account that
the network has sufficient resource to perform subsequent tests. The the network has sufficient resources to perform subsequent tests.
value of Th MAY be constant during one sampling process for The value of Th MAY be constant during one sampling process for
simplicity considerations. simplicity considerations.
Note that for online or passive measurements, the arrival rate and Note that for online or passive measurements, the arrival rate and
LSP holding time are determined by actual traffic, hence in this case LSP holding time are determined by actual traffic; hence, in this
Lambda and Th are not input parameters. case, Lambda and Th are not input parameters.
It is important that in obtaining a sample all the LSPs MUST traverse It is important that, in obtaining a sample, all the LSPs MUST
the same route. If there are multiple routes between the Ingress traverse the same route. If there are multiple routes between the
node ID0 and Egress node ID1, EROs or an alternate method, e.g., ingress node ID0 and egress node ID1, EROs, or an alternate method,
static configuration, MUST be used to ensure that all LSPs traverse e.g., static configuration, MUST be used to ensure that all LSPs
the same route. traverse the same route.
9.6. Methodologies 9.6. Methodologies
o Select the times using the specified Poisson arrival process, and o Select the times using the specified Poisson arrival process,
o Set up the LSP as the methodology for the singleton unidirectional o Set up the LSP as the methodology for the singleton unidirectional
LSP setup delay, and obtain the value of unidirectional LSP setup LSP setup delay, and obtain the value of unidirectional LSP setup
delay delay, and
o Release the LSP after Th, and wait for the next Poisson arrival o Release the LSP after Th, and wait for the next Poisson arrival
event event.
Note that: it is possible that before the previous LSP release Note: it is possible that before the previous LSP release procedure
procedure completes, the next Poisson arrival event arrives and the completes, the next Poisson arrival event arrives and the LSP setup
LSP setup procedure is initiated. If there is resource contention procedure is initiated. If there is resource contention between the
between the two LSPs, the LSP setup may fail. Ways to avoid such two LSPs, the LSP setup may fail. Ways to avoid such contention are
contention are outside the scope of this document. outside the scope of this document.
9.7. Typical testing cases 9.7. Typical Testing Cases
9.7.1. With no LSP in the Network 9.7.1. With No LSP in the Network
9.7.1.1. Motivation 9.7.1.1. Motivation
Single unidirectional LSP setup delay with no LSP in the network is Single unidirectional LSP setup delay with no LSP in the network is
important because this reflects the inherent delay of an RSVP-TE important because this reflects the inherent delay of a Resource
implementation. The minimum value provides an indication of the Reservation Protocol - Traffic Engineering (RSVP-TE) implementation.
delay that will likely be experienced when an LSP traverses the The minimum value provides an indication of the delay that will
shortest route with the lightest load in the control plane. likely be experienced when an LSP traverses the shortest route with
the lightest load in the control plane.
9.7.1.2. Methodologies 9.7.1.2. Methodologies
Make sure that there is no LSP in the network, and proceed with the Make sure that there is no LSP in the network and proceed with the
methodologies described in Section 9.6 methodologies described in Section 9.6
9.7.2. With a number of LSPs in the Network 9.7.2. With a Number of LSPs in the Network
9.7.2.1. Motivation 9.7.2.1. Motivation
Single unidirectional LSP setup delay with a number of LSPs in the Single unidirectional LSP setup delay with a number of LSPs in the
network is important because it reflects the performance of an network is important because it reflects the performance of an
operational network with considerable load. This delay may vary operational network with considerable load. This delay may vary
significantly as the number of existing LSPs vary. It can be used as significantly as the number of existing LSPs vary. It can be used as
a scalability metric of an RSVP-TE implementation. a scalability metric of an RSVP-TE implementation.
9.7.2.2. Methodologies 9.7.2.2. Methodologies
Setup the required number of LSPs, and wait until the network reaches Set up the required number of LSPs, and wait until the network
a stable state, then proceed with the methodologies described in reaches a stable state; then, proceed with the methodologies
Section 9.6. described in Section 9.6.
9.8. Metric Reporting 9.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.
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 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 LSPs setup delay.
Sampling means to take a number of distinct instances of a skeleton Sampling means to take a number of distinct instances of a skeleton
metric under a given set of parameters. Like in [RFC2330], we use metric under a given set of parameters. As in [RFC2330], we use
Poisson sampling as an 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
skipping to change at page 32, line 46 skipping to change at page 27, line 40
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 of milliseconds, or undefined. 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 an 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 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. The value of the sample is the sequence made up
sequence made up of the resulting <time, setup delay> pairs. If of the resulting <time, setup delay> pairs. If there are no such
there are no such pairs, the sequence is of length zero and the pairs, the sequence is of length zero and the sample is said to be
sample is said to be empty. empty.
10.5. Discussion 10.5. Discussion
The parameter Lambda is used as arrival rate of "batch unidirectional The parameter Lambda is used as an arrival rate of "batch
LSPs setup" operation. It regulates the interval in between each unidirectional LSPs setup" operation. It regulates the interval in
batch operation. The parameter Lambda_m is used within each batch between each batch operation. The parameter Lambda_m is used within
operation, as described in Section 5 each batch operation, as described in Section 5
The parameters Lambda and Lambda_m should be carefully chosen. If The parameters Lambda and Lambda_m should be carefully chosen. If
the rate is too high, too frequent LSP setup/release procedure will the rate is too high, overly frequent LSP setup/release procedure
result in high overhead in the control plane. In turn, the high will 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 might not completely reflect
the dynamic provisioning performance of the GMPLS network. The the dynamic provisioning performance of the GMPLS network. The
appropriate Lambda and Lambda_m value depends on the given network. appropriate Lambda and Lambda_m value depends on the given network.
The parameters Td should be carefully chosen. Different switching The parameters Td should be carefully chosen. Different switching
technologies may vary significantly in performing a cross-connect technologies may vary significantly in performing a cross-connect
operation. At the same time, the time needed in setting up an LSP operation. At the same time, the time needed in setting up an LSP
under different traffic may also vary significantly. under different traffic may also vary significantly.
It is important that in obtaining a sample all the LSPs MUST traverse It is important that, in obtaining a sample, all the LSPs MUST
the same route. If there are multiple routes between the Ingress traverse the same route. If there are multiple routes between the
node ID0 and Egress node ID1, EROs or an alternate method, e.g., ingress node ID0 and egress node ID1, EROs, or an alternate method,
static configuration, MUST be used to ensure that all LSPs traverse e.g., static configuration, MUST be used to ensure that all LSPs
the same route. traverse the same route.
10.6. Methodologies 10.6. Methodologies
o Select the times using the specified Poisson arrival process, and o Select the times using the specified Poisson arrival process,
o Set up the LSP as the methodology for the singleton multiple o Set up the LSP as the methodology for the singleton multiple
unidirectional LSPs setup delay, and obtain the value of multiple unidirectional LSPs setup delay, and obtain the value of multiple
unidirectional LSPs setup delay unidirectional LSPs setup delay, and
o Release the LSP after Th, and wait for the next Poisson arrival o Release the LSP after Th, and wait for the next Poisson arrival
event event.
Note that: it is possible that before the previous LSP release Note: it is possible that before the previous LSP release procedure
procedure completes, the next Poisson arrival event arrives and the completes, the next Poisson arrival event arrives and the LSP setup
LSP setup procedure is initiated. If there is resource contention procedure is initiated. If there is resource contention between the
between the two LSPs, the LSP setup may fail. Ways to avoid such two LSPs, the LSP setup may fail. Ways to avoid such contention are
contention are outside the scope of this document. outside the scope of this document.
10.7. Typical testing cases 10.7. Typical Testing Cases
10.7.1. With No LSP in the Network 10.7.1. With No LSP in the Network
10.7.1.1. Motivation 10.7.1.1. Motivation
Multiple unidirectional LSP setup delay with no LSP in the network is Multiple unidirectional LSPs setup delay with no LSP in the network
important because this reflects the inherent delay of an RSVP-TE is important because this reflects the inherent delay of an RSVP-TE
implementation. The minimum value provides an indication of the implementation. The minimum value provides an indication of the
delay that will likely be experienced when LSPs traverse the shortest delay that will likely be experienced when LSPs traverse the shortest
route with the lightest load in the control plane. route with the lightest load in the control plane.
10.7.1.2. Methodologies 10.7.1.2. Methodologies
Make sure that there is no LSP in the network, and proceed with the Make sure that there is no LSP in the network and proceed with the
methodologies described in Section 10.6. methodologies described in Section 10.6.
10.7.2. With a Number of LSPs in the Network 10.7.2. With a Number of LSPs in the Network
10.7.2.1. Motivation 10.7.2.1. Motivation
Multiple unidirectional LSPs setup delay with a number of LSPs in the Multiple unidirectional LSPs setup delay with a number of LSPs in the
network is important because it reflects the performance of an network is important because it reflects the performance of an
operational network with considerable load. This delay can vary operational network with considerable load. This delay can vary
significantly as the number of existing LSPs vary. It can be used as significantly as the number of existing LSPs vary. It can be used as
a scalability metric of an RSVP-TE implementation. a scalability metric of an RSVP-TE implementation.
10.7.2.2. Methodologies 10.7.2.2. Methodologies
Setup the required number of LSPs, and wait until the network reaches Set up the required number of LSPs, and wait until the network
a stable state, then proceed with the methodologies described in reaches a stable state; then, proceed with the methodologies
Section 10.6. described in Section 10.6.
10.8. Metric Reporting 10.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.
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 defined the singleton metric of single bidirectional
Bidirectional LSP setup delay. Now we define how to get one LSP setup delay. Now we define how to get one particular sample of
particular sample of Single Bidirectional LSP setup delay. Sampling single bidirectional LSP setup delay. Sampling means to take a
means to take a number of distinct instances of a skeleton metric number of distinct instances of a skeleton metric under a given set
under a given set of parameters. Like in [RFC2330], we use Poisson of parameters. As in [RFC2330], we use Poisson sampling as an
sampling as an example. 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
o ID1, the egress LSR ID o ID1, the egress LSR ID
o T0, a time o T0, a time
skipping to change at page 35, line 41 skipping to change at page 30, 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 of milliseconds, or undefined. 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 an 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. The value of the sample is the sequence made up of the
of the resulting <time, LSP setup delay> pairs. If there are no such resulting <time, LSP setup delay> pairs. If there are no such pairs,
pairs, the sequence is of length zero and the sample is said to be the sequence is of length zero and the sample is said to be empty.
empty.
11.5. Discussion 11.5. Discussion
The parameters Lambda should be carefully chosen. If the rate is too The parameters Lambda should be carefully chosen. If the rate is too
high, too frequent LSP setup/release procedure will result in high high, overly frequent LSP setup/release procedure will result in high
overhead in the control plane. In turn, the high overhead will overhead in the control plane. In turn, the high overhead will
increase bidirectional LSP setup delay. On the other hand if the increase bidirectional LSP setup delay. On the other hand, if the
rate is too low, the sample could not completely reflect the dynamic rate is too low, the sample might not completely reflect the dynamic
provisioning performance of the GMPLS network. The appropriate provisioning performance of the GMPLS network. The appropriate
Lambda value depends on the given network. Lambda value depends on the given network.
The parameters Td should be carefully chosen. Different switching The parameters Td should be carefully chosen. Different switching
technologies may vary significantly in performing a cross-connect technologies may vary significantly in performing a cross-connect
operation. At the same time, the time needed in setting up an LSP operation. At the same time, the time needed to set up an LSP under
under different traffic may also vary significantly. different traffic may also vary significantly.
In the case of active measurement, the parameters Th should be In the case of active measurement, the parameters Th should be
carefully chosen. The combination of Lambda and Th reflects the load carefully chosen. The combination of Lambda and Th reflects the load
of the network. The selection of Th SHOULD take into account that of the network. The selection of Th SHOULD take into account that
the network has sufficient resource to perform subsequent tests. The the network has sufficient resources to perform subsequent tests.
value of Th MAY be constant during one sampling process for The value of Th MAY be constant during one sampling process for
simplicity considerations. simplicity considerations.
Note that for online or passive measurements, the arrival rate and Note that for online or passive measurements, the arrival rate and
the LSP holding time are determined by actual traffic, hence in this the LSP holding time are determined by actual traffic; hence, in this
case Lambda and Th are not input parameters. case, Lambda and Th are not input parameters.
It is important that in obtaining a sample all the LSPs MUST traverse It is important that, in obtaining a sample, all the LSPs MUST
the same route. If there are multiple routes between the Ingress traverse the same route. If there are multiple routes between the
node ID0 and Egress node ID1, EROs or an alternate method, e.g., ingress node ID0 and egress node ID1, EROs, or an alternate method,
static configuration, MUST be used to ensure that all LSPs traverse e.g., static configuration, MUST be used to ensure that all LSPs
the same route. traverse the same route.
11.6. Methodologies 11.6. Methodologies
o Select the times using the specified Poisson arrival process, and o Select the times using the specified Poisson arrival process,
o Set up the LSP as the methodology for the singleton bidirectional o Set up the LSP as the methodology for the singleton bidirectional
LSP setup delay, and obtain the value of bidirectional LSP setup LSP setup delay, and obtain the value of bidirectional LSP setup
delay delay, and
o Release the LSP after Th, and wait for the next Poisson arrival o Release the LSP after Th, and wait for the next Poisson arrival
event event.
Note that: it is possible that before the previous LSP release Note: it is possible that before the previous LSP release procedure
procedure completes, the next Poisson arrival event arrives and the completes, the next Poisson arrival event arrives and the LSP setup
LSP setup procedure is initiated. If there is resource contention procedure is initiated. If there is resource contention between the
between the two LSPs, the LSP setup may fail. Ways to avoid such two LSPs, the LSP setup may fail. Ways to avoid such contention are
contention are outside the scope of this document. outside the scope of this document.
11.7. Typical testing cases 11.7. Typical Testing Cases
11.7.1. With No LSP in the Network 11.7.1. With No LSP in the Network
11.7.1.1. Motivation 11.7.1.1. Motivation
Single bidirectional LSP setup delay with no LSP in the network is Single bidirectional LSP setup delay with no LSP in the network is
important because this reflects the inherent delay of an RSVP-TE important because this reflects the inherent delay of an RSVP-TE
implementation. The minimum value provides an indication of the implementation. The minimum value provides an indication of the
delay that will likely be experienced when an LSP traverses the delay that will likely be experienced when an LSP traverses the
shortest route with the lightest load in the control plane. shortest route with the lightest load in the control plane.
11.7.1.2. Methodologies 11.7.1.2. Methodologies
Make sure that there is no LSP in the network, and proceed with the Make sure that there is no LSP in the network and proceed with the
methodologies described in Section 11.6. methodologies described in Section 11.6.
11.7.2. With a Number of LSPs in the Network 11.7.2. With a Number of LSPs in the Network
11.7.2.1. Motivation 11.7.2.1. Motivation
Single bidirectional LSP setup delay with a number of LSPs in the Single bidirectional LSP setup delay with a number of LSPs in the
network is important because it reflects the performance of an network is important because it reflects the performance of an
operational network with considerable load. This delay can vary operational network with considerable load. This delay can vary
significantly as the number of existing LSPs varies. It can be used significantly as the number of existing LSPs varies. It can be used
as a scalability metric of an RSVP-TE implementation. as a scalability metric of an RSVP-TE implementation.
11.7.2.2. Methodologies 11.7.2.2. Methodologies
Setup the required number of LSPs, and wait until the network reaches Set up the required number of LSPs and wait until the network reaches
a stable state, then proceed with the methodologies described in a stable state; then, proceed with the methodologies described in
Section 11.6. Section 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 Delay 12. A Definition for Samples of Multiple Bidirectional LSPs Setup Delay
In Section 7, we have defined the singleton metric of multiple In Section 7, we 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 means to take a number of distinct instances of a skeleton Sampling means to take a number of distinct instances of a skeleton
metric under a given set of parameters. Like in [RFC2330], we use metric under a given set of parameters. As in [RFC2330], we use
Poisson sampling as an 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
skipping to change at page 38, line 45 skipping to change at page 33, line 40
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 of milliseconds, or undefined. 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 an 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. The value of the sample is the sequence made up
sequence made up of the resulting <time, setup delay> pairs. If of the resulting <time, setup delay> pairs. If there are no such
there are no such pairs, the sequence is of length zero and the pairs, the sequence is of length zero and the sample is said to be
sample is said to be empty. empty.
12.5. Discussion 12.5. Discussion
The parameter Lambda is used as arrival rate of "batch bidirectional The parameter Lambda is used as an arrival rate of "batch
LSPs setup" operation. It regulates the interval in between each bidirectional LSPs setup" operation. It regulates the interval in
batch operation. The parameter Lambda_m is used within each batch between each batch operation. The parameter Lambda_m is used within
operation, as described in Section 7. each batch 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, overly frequent LSP setup/release procedure
result in high overhead in the control plane. In turn, the high will 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 might not completely reflect
the dynamic provisioning performance of the GMPLS network. The the dynamic provisioning performance of the GMPLS network. The
appropriate Lambda and Lambda_m value depends on the given network. appropriate Lambda and Lambda_m values depend on the given network.
The parameters Td should be carefully chosen. Different switching The parameters Td should be carefully chosen. Different switching
technologies may vary significantly in performing a cross-connect technologies may vary significantly in performing a cross-connect
operation. At the same time, the time needed in setting up an LSP operation. At the same time, the time needed to set up an LSP under
under different traffic may also vary significantly. different traffic may also vary significantly.
It is important that in obtaining a sample all the LSPs MUST traverse It is important that, in obtaining a sample, all the LSPs MUST
the same route. If there are multiple routes between the Ingress traverse the same route. If there are multiple routes between the
node ID0 and Egress node ID1, EROs or an alternate method, e.g., ingress node ID0 and egress node ID1, EROs, or an alternate method,
static configuration, MUST be used to ensure that all LSPs traverse e.g., static configuration, MUST be used to ensure that all LSPs
the same route. traverse the same route.
12.6. Methodologies 12.6. Methodologies
o Select the times using the specified Poisson arrival process, and o Select the times using the specified Poisson arrival process,
o Set up the LSP as the methodology for the singleton multiple o Set up the LSP as the methodology for the singleton multiple
bidirectional LSPs setup delay, and obtain the value of multiple bidirectional LSPs setup delay, and obtain the value of multiple
unidirectional LSPs setup delay unidirectional LSPs setup delay, and
o Release the LSP after Th, and wait for the next Poisson arrival o Release the LSP after Th, and wait for the next Poisson arrival
event event.
Note that: it is possible that before the previous LSP release Note: it is possible that before the previous LSP release procedure
procedure completes, the next Poisson arrival event arrives and the completes, the next Poisson arrival event arrives and the LSP setup
LSP setup procedure is initiated. If there is resource contention procedure is initiated. If there is resource contention between the
between the two LSPs, the LSP setup may fail. Ways to avoid such two LSPs, the LSP setup may fail. Ways to avoid such contention are
contention are outside the scope of this document. outside the scope of this document.
12.7. Typical testing cases 12.7. Typical Testing Cases
12.7.1. With No LSP in the Network 12.7.1. With No LSP in the Network
12.7.1.1. Motivation 12.7.1.1. Motivation
Multiple bidirectional LSPs setup delay with no LSP in the network is Multiple bidirectional LSPs setup delay with no LSP in the network is
important because this reflects the inherent delay of an RSVP-TE important because this reflects the inherent delay of an RSVP-TE
implementation. The minimum value provides an indication of the implementation. The minimum value provides an indication of the
delay that will likely be experienced when an LSPs traverse the delay that will likely be experienced when an LSPs traverse the
shortest route with the lightest load in the control plane. shortest route with the lightest load in the control plane.
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 Set up the required number of LSPs, and wait until the network
a stable state, then proceed with the methodologies described in reaches a stable state; then, proceed with the methodologies
Section 12.6. described in Section 12.6.
12.8. Metric Reporting 12.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.
13. A Definition for Samples of LSP Graceful Release Delay 13. A Definition for Samples of LSP Graceful Release Delay
In Section 8, we have defined the singleton metric of LSP graceful In Section 8, we defined the singleton metric of LSP graceful release
release delay. Now we define how to get one particular sample of LSP delay. Now we define how to get one particular sample of LSP
graceful release delay. We also use Poisson sampling as an example. graceful release delay. We also use Poisson sampling as an example.
13.1. Metric Name 13.1. Metric Name
LSP graceful release delay sample LSP graceful release delay sample
13.2. Metric Parameters 13.2. Metric Parameters
o ID0, the ingress LSR ID o ID0, the ingress LSR ID
skipping to change at page 41, line 35 skipping to change at page 36, line 29
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 of milliseconds, or undefined. 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 an 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. The value of the sample is the sequence made up of the
of the resulting <time, LSP graceful delay> pairs. If there are no resulting <time, LSP graceful delay> pairs. If there are no such
such pairs, the sequence is of length zero and the sample is said to pairs, the sequence is of length zero and the sample is said to be
be empty. empty.
13.5. Discussion 13.5. Discussion
The parameter Lambda should be carefully chosen. If the rate is too The parameter Lambda should be carefully chosen. If the rate is too
large, too frequent LSP setup/release procedure will result in high large, overly frequent LSP setup/release procedure will result in
overhead in the control plane. In turn, the high overhead will high overhead in the control plane. In turn, the high overhead will
increase unidirectional LSP setup delay. On the other hand if the increase unidirectional LSP setup delay. On the other hand, if the
rate is too small, the sample could not completely reflect the rate is too small, the sample might not completely reflect the
dynamic provisioning performance of the GMPLS network. The dynamic provisioning performance of the GMPLS network. The
appropriate Lambda value depends on the given network. appropriate Lambda value depends on the given network.
It is important that in obtaining a sample all the LSPs MUST traverse It is important that, in obtaining a sample, all the LSPs MUST
the same route. If there are multiple routes between the Ingress traverse the same route. If there are multiple routes between the
node ID0 and Egress node ID1, EROs or an alternate method, e.g., ingress node ID0 and egress node ID1, EROs, or an alternate method,
static configuration, MUST be used to ensure that all LSPs traverse e.g., static configuration, MUST be used to ensure that all LSPs
the same route. traverse the same route.
13.6. Methodologies 13.6. Methodologies
Generally the methodology would proceed as follows: Generally, the methodology would proceed as follows:
o Setup the LSP to be deleted o Set up the LSP to be deleted
o Select the times using the specified Poisson arrival process, and o Select the times using the specified Poisson arrival process,
o Release the LSP as the methodology for the singleton LSP graceful o Release the LSP as the methodology for the singleton LSP graceful
release delay, and obtain the value of LSP graceful release delay release delay, and obtain the value of LSP graceful release delay,
and
o Setup the LSP, and restart the Poisson arrival process, wait for o Set up the LSP, and restart the Poisson arrival process, wait for
the next Poisson arrival event the next Poisson arrival event.
13.7. Metric Reporting 13.7. 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, 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 either a real number of milliseconds, or undefined. metrics is either a real number of milliseconds or undefined. In the
In the following discussion, we only consider the finite values. following discussion, we only consider the 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 the 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
Metric median is the median of the dT values in the given sample. In Metric median is the median of the dT values in the given sample. In
computing the median, the undefined values MUST NOT be included. computing the median, the undefined values MUST NOT be included.
14.3. The Maximum of Metric 14.3. The Maximum of Metric
The maximum of metric is the maximum of all the dT values in the The maximum of the metric is the maximum of all the dT values in the
sample. In computing this, undefined values MUST NOT be included. sample. In computing this, undefined values MUST NOT be included.
Note that this means that measurements that exceed the upper bound Note that this means that measurements that exceed the upper bound
are not reported in this statistic. This is an important are not reported in this statistic. This is an important
consideration when evaluating the maximum when the number of consideration when evaluating the maximum when the number of
undefined measurements is non-zero. undefined measurements is non-zero.
14.4. The Percentile of Metric 14.4. The Percentile of Metric
The "empirical distribution function" (EDF) of a set of scalar The "empirical distribution function" (EDF) of a set of scalar
measurements is a function F(x) which for any x gives the fractional measurements is a function F(x), which, for any x, gives the
proportion of the total measurements that were <= x. fractional proportion of the total measurements that were <= x.
Given a percentage X, the X-th percentile of Metric means the Given a percentage X, the X-th percentile of the metric means the
smallest value of x for which F(x) >= X. In computing the percentile, smallest value of x for which F(x) >= X. In computing the
undefined values MUST NOT be included. percentile, undefined values MUST NOT be included.
See [RFC2330] for further details. See [RFC2330] for further details.
14.5. Failure statistics of Metric 14.5. Failure Statistics of Metric
In the process of LSP setup/release, it may fail due to various In the process of LSP setup/release, it may fail due to various
reasons. For example, setup/release may fail when the control plane reasons. For example, setup/release may fail when the control plane
is overburdened or when there is resource shortage in one of the is overburdened or when there is resource shortage in one of the
intermediate nodes. Since the setup/release failure may have intermediate nodes. Since the setup/release failure may have
significant impact on network operation, it is worthwhile to report significant impact on network operation, it is worthwhile to report
each failure cases, so that appropriate operations can be performed each failure cases, so that appropriate operations can be performed
to check the possible implementation, configuration or other to check the possible implementation, configuration or other
deficiencies. deficiencies.
Five types of failure events are defined in previous sections: Five types of failure events are defined in previous sections:
o Single Unidirectional LSP Setup Failure o Single Unidirectional LSP Setup Failure
o Multiple Unidirectional LSP Setup Failure o Multiple Unidirectional LSP Setup Failure
o Single Bidirectional LSP Setup Failure o Single Bidirectional LSP Setup Failure
o Multiple Bidirectional LSP Setup Failure o Multiple Bidirectional LSP Setup Failure
o LSP graceful release failure o LSP Graceful Release Failure
Given the samples of the performance metric, we now offer two Given the samples of the performance metric, we now offer two
statistics of failure events of these samples to report. statistics of failure events of these samples to report.
14.5.1. Failure Count 14.5.1. Failure Count
Failure Count is defined as the number of the undefined value of the Failure Count is defined as the number of the undefined value of the
corresponding performance metric (failure events) in a sample. The corresponding performance metric (failure events) in a sample. The
value of Failure Count is an integer. value of Failure Count is an integer.
skipping to change at page 45, line 10 skipping to change at page 39, line 25
Failure Ratio is defined as follows: Failure Ratio is defined as follows:
X type failure ratio = Number of X type failure events/(Number of X type failure ratio = Number of X type failure events/(Number of
valid X type metric values + Number of X type failure events) * 100%. valid X type metric values + Number of X type failure events) * 100%.
15. Discussion 15. Discussion
It is worthwhile to point out that: It is worthwhile to point out that:
o The unidirectional/bidirectional LSP setup delay is one ingress- o The unidirectional/bidirectional LSP setup delay is one ingress-
egress round trip time plus processing time. But in this egress round-trip time plus processing time. But in this
document, unidirectional/bidirectional LSP setup delay has not document, unidirectional/bidirectional LSP setup delay has not
taken the processing time in the end nodes (ingress or/and egress) taken the processing time in the end nodes (ingress and/or egress)
into account. The timestamp T2 is taken after the endpoint node into account. The timestamp T2 is taken after the endpoint node
receives it. Actually, the last node has to take some time to receives it. Actually, the last node has to take some time to
process local procedure. Similarly, in the LSP graceful release process local procedures. Similarly, in the LSP graceful release
delay, the memo has not considered the processing time in the end delay, the memo has not considered the processing time in the end
node. node.
o This document assumes that the correct procedures for installing o This document assumes that the correct procedures for installing
the data plane are followed as described in [RFC3209], [RFC3471], the data plane are followed as described in [RFC3209], [RFC3471],
and [RFC3473]. That is, by the time the egress receives and and [RFC3473]. That is, by the time the egress receives and
processes a Path message, it is safe for the egress to transmit processes a Path message, it is safe for the egress to transmit
data on the reverse path, and by the time the ingress receives and data on the reverse path, and by the time the ingress receives and
processes a Resv message it is safe for the ingress to transmit processes a Resv message it is safe for the ingress to transmit
data on the forward path. See data on the forward path. See [CCAMP-SWITCH] for detailed
[I-D.shiomoto-ccamp-switch-programming] for detailed explanations. explanations. This document does not include any verification
This document does not include any verification that the that the implementations of the control plane software are
implementations of the control plane software are conformant, conformant, although such tests MAY be constructed with the use of
although such tests MAY be constructed with the use of suitable suitable signal generation test equipment. In [CCAMP-DPM], we
signal generation test equipment. In [I-D.sun-ccamp-dpm], we
defined a series of metrics to do such verifications. However, it defined a series of metrics to do such verifications. However, it
is RECOMMENDED that both the measurements defined in this document is RECOMMENDED that both the measurements defined in this document
and the measurements defined in [I-D.sun-ccamp-dpm] are performed and the measurements defined in [CCAMP-DPM] are performed to
to complement each other. complement each other.
o Note that, in implementing the tests described in this document a o Note that, in implementing the tests described in this document, a
tester should be sure to measure the time taken for the control tester should be sure to measure the time taken for the control
plane messages including the processing of those messages by the plane messages including the processing of those messages by the
nodes under test. nodes under test.
o Bidirectional LSPs may be setup using three way signaling, where o Bidirectional LSPs may be set up using three-way signaling, where
the initiating node will send a ResvConf message downstream upon the initiating node will send a ResvConf message downstream upon
receiving the Resv message. The ResvConf message is used to receiving the Resv message. The ResvConf message is used to
notify the terminate node that it can transfer data upstream. notify the terminate node that it can transfer data upstream.
Actually, both direction should be ready to transfer data when the Actually, both directions should be ready to transfer data when
Resv message is received by the initiate node. Therefore, the the Resv message is received by the initiating node. Therefore,
bidirectional LSP setup delay defined in this document does not the bidirectional LSP setup delay defined in this document does
take the confirmation procedure into account. not 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. Since the measurement endpoints must be conformant to control plane. Since the measurement endpoints must be conformant to
signaling specifications and behave as normal signaling endpoints, it signaling specifications and behave as normal signaling endpoints, it
will not incur other security issues than normal LSP provisioning. will not incur other security issues than normal LSP provisioning.
However, the measurement parameters must be carefully selected so However, the measurement parameters must be carefully selected so
that the measurements inject trivial amounts of additional traffic 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. A typical will not be used to attack the control plane. A typical
implementation may use the Management Information Base (MIB) to implementation may use the Management Information Base (MIB) to
collect/store the metrics and access to the MIB is limited to the collect/store the metrics and access to the MIB is limited to the
Network Management Systems (NMSs). In this case, passive monitoring Network Management Systems (NMSs). In this case, passive monitoring
will not incur other security issues than implementing the MIBs and will not incur other security issues than implementing the MIBs and
NMSs. If an implementation chooses to expose the performance data to NMSs. If an implementation chooses to expose the performance data to
other applications, then it must take into account the possible other applications, then it must take into account the possible
security issues it may face. For example, when exposing the security issues it may face. For example, when exposing the
performance data through SNMP, certain authentication method should performance data through Simple Network Management Protocol (SNMP),
be used to ensure that the entity maintaining the performance data certain authentication methods should be used to ensure that the
are not subject to unauthorized readings and modifications. Rate entity maintaining the performance data are not subject to
limiting on the performance query may also be desirable to reduce the unauthorized readings and modifications. Rate limiting on the
risk that the entity maintaining the performance data are overwhelmed performance query may also be desirable to reduce the risk that the
by too much query requests. It is RECOMMENDED that implementers entity maintaining the performance data are overwhelmed by too many
consider the security features as provided by the SNMPv3 framework query requests. It is RECOMMENDED that implementers consider the
(see [RFC3410], section 8), including full support for the SNMPv3 security features as provided by the SNMPv3 framework (see [RFC3410],
cryptographic mechanisms (for authentication and privacy). section 8), including full support for the SNMPv3 cryptographic
mechanisms (for authentication and privacy).
Besides, the security considerations pertaining to the original RSVP Additionally, the security considerations pertaining to the original
protocol [RFC2205] and its TE extensions [RFC3209] also remain RSVP protocol [RFC2205] and its TE extensions [RFC3209] also remain
relevant. relevant.
17. IANA Considerations 17. Acknowledgments
This document makes no requests for IANA action.
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 help. Lou Berger and Adrian Farrel have made
contributions to this document. text 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 made text contributions to this document.
This document contains ideas as well as text that have appeared in This document contains ideas as well as text that have appeared in
existing IETF documents. The authors wish to thank G. Almes, S. existing IETF documents. The authors wish to thank G. Almes, S.
Kalidindi and M. Zekauskas. Kalidindi, and M. Zekauskas.
We also wish to thank Weisheng Hu, Yaohui Jin and Wei Guo in the We also wish to thank Weisheng Hu, Yaohui Jin, and Wei Guo in the
state key laboratory of advanced optical communication systems and state key laboratory of advanced optical communication systems and
networks for the valuable comments. We also wish to thank the networks for the valuable comments. We also wish to thank the
support from NSFC and 863 program of China. support from National Natural Science Foundation of China (NSFC) and
863 program of China.
19. References
19.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2205] Braden, B., Zhang, L., Berson, S., Herzog, S., and S.
Jamin, "Resource ReSerVation Protocol (RSVP) -- Version 1
Functional Specification", RFC 2205, September 1997.
[RFC2679] Almes, G., Kalidindi, S., and M. Zekauskas, "A One-way 18. References
Delay Metric for IPPM", RFC 2679, September 1999.
[RFC2681] Almes, G., Kalidindi, S., and M. Zekauskas, "A Round-trip 18.1. Normative References
Delay Metric for IPPM", RFC 2681, September 1999.
[RFC3209] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V., [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP Requirement Levels", BCP 14, RFC 2119, March 1997.
Tunnels", RFC 3209, December 2001.
[RFC3471] Berger, L., "Generalized Multi-Protocol Label Switching [RFC2205] Braden, B., Zhang, L., Berson, S., Herzog, S., and S.
(GMPLS) Signaling Functional Description", RFC 3471, Jamin, "Resource ReSerVation Protocol (RSVP) --
January 2003. Version 1 Functional Specification", RFC 2205,
September 1997.
[RFC3473] Berger, L., "Generalized Multi-Protocol Label Switching [RFC2679] Almes, G., Kalidindi, S., and M. Zekauskas, "A One-
(GMPLS) Signaling Resource ReserVation Protocol-Traffic way Delay Metric for IPPM", RFC 2679, September 1999.
Engineering (RSVP-TE) Extensions", RFC 3473, January 2003.
[RFC3945] Mannie, E., "Generalized Multi-Protocol Label Switching [RFC2681] Almes, G., Kalidindi, S., and M. Zekauskas, "A Round-
(GMPLS) Architecture", RFC 3945, October 2004. trip Delay Metric for IPPM", RFC 2681,
September 1999.
[RFC4208] Swallow, G., Drake, J., Ishimatsu, H., and Y. Rekhter, [RFC3209] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan,
"Generalized Multiprotocol Label Switching (GMPLS) User- V., and G. Swallow, "RSVP-TE: Extensions to RSVP for
Network Interface (UNI): Resource ReserVation Protocol- LSP Tunnels", RFC 3209, December 2001.
Traffic Engineering (RSVP-TE) Support for the Overlay
Model", RFC 4208, October 2005.
19.2. Informative References [RFC3471] Berger, L., "Generalized Multi-Protocol Label
Switching (GMPLS) Signaling Functional Description",
RFC 3471, January 2003.
[I-D.shiomoto-ccamp-switch-programming] [RFC3473] Berger, L., "Generalized Multi-Protocol Label
Shiomoto, K. and A. Farrel, "Advice on When It is Safe to Switching (GMPLS) Signaling Resource ReserVation
Start Sending Data on Label Switched Paths Established Protocol-Traffic Engineering (RSVP-TE) Extensions",
Using RSVP-TE", draft-shiomoto-ccamp-switch-programming-01 RFC 3473, January 2003.
(work in progress), October 2009.
[I-D.sun-ccamp-dpm] [RFC3945] Mannie, E., "Generalized Multi-Protocol Label
Sun, W., Zhang, G., Gao, J., Xie, G., Papneja, R., Gu, B., Switching (GMPLS) Architecture", RFC 3945,
Wei, X., Otani, T., and R. Jing, "Label Switched Path October 2004.
(LSP) Data Path Delay Metric in Generalized MPLS/ MPLS-TE
Networks", draft-sun-ccamp-dpm-01 (work in progress),
December 2009.
[RFC2330] Paxson, V., Almes, G., Mahdavi, J., and M. Mathis, [RFC4208] Swallow, G., Drake, J., Ishimatsu, H., and Y.
"Framework for IP Performance Metrics", RFC 2330, Rekhter, "Generalized Multiprotocol Label Switching
May 1998. (GMPLS) User-Network Interface (UNI): Resource
ReserVation Protocol-Traffic Engineering (RSVP-TE)
Support for the Overlay Model", RFC 4208,
October 2005.
[RFC3410] Case, J., Mundy, R., Partain, D., and B. Stewart, 18.2. Informative References
"Introduction and Applicability Statements for Internet-
Standard Management Framework", RFC 3410, December 2002.
Authors' Addresses [CCAMP-DPM] Sun, W., Zhang, G., Gao, J., Xie, G., Papneja, R.,
Gu, B., Wei, X., Otani, T., and R. Jing, "Label
Switched Path (LSP) Data Path Delay Metric in
Generalized MPLS/ MPLS-TE Networks", Work
in Progress, December 2009.
Weiqiang Sun, Editor [CCAMP-SWITCH] Shiomoto, K. and A. Farrel, "Advice on When It is
Shanghai Jiao Tong University Safe to Start Sending Data on Label Switched Paths
800 Dongchuan Road Established Using RSVP-TE", Work in Progress,
Shanghai 200240 October 2009.
China
Phone: +86 21 3420 5359 [RFC2330] Paxson, V., Almes, G., Mahdavi, J., and M. Mathis,
Email: sunwq@mit.edu "Framework for IP Performance Metrics", RFC 2330,
May 1998.
Guoying Zhang, Editor [RFC3410] Case, J., Mundy, R., Partain, D., and B. Stewart,
China Academy of Telecommunication Research, MIIT, China. "Introduction and Applicability Statements for
No.11 YueTan South Street Internet-Standard Management Framework", RFC 3410,
Beijing 100045 December 2002.
China
Phone: +86 1068094272 Appendix A. Authors' Addresses
Email: zhangguoying@mail.ritt.com.cn
Jianhua Gao Jianhua Gao
Huawei Technologies Co., LTD. Huawei Technologies Co., LTD.
China 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
Phone: +1 951 237 8825 Phone: +1 951 237 8825
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
China China
Phone: +86 13611590766 Phone: +86 13611590766
Email: BGu@ixiacom.com EMail: BGu@ixiacom.com
Xueqin Wei Xueqin Wei
Fiberhome Telecommunication Technology Co., Ltd. Fiberhome Telecommunication Technology Co., Ltd.
Wuhan Wuhan
China 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
China China
Phone: +86-10-58552000 Phone: +86-10-58552000
Email: jingrq@ctbri.com.cn EMail: jingrq@ctbri.com.cn
Editors' Addresses
Weiqiang Sun (editor)
Shanghai Jiao Tong University
800 Dongchuan Road
Shanghai 200240
China
Phone: +86 21 3420 5359
EMail: sunwq@mit.edu
Guoying Zhang (editor)
China Academy of Telecommunication Research, MIIT, China.
No.52 Hua Yuan Bei Lu,Haidian District
Beijing 100083
China
Phone: +86 1062300103
EMail: zhangguoying@mail.ritt.com.cn
 End of changes. 243 change blocks. 
651 lines changed or deleted 618 lines changed or added

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