draft-ietf-ccamp-lsp-dppm-09.txt   draft-ietf-ccamp-lsp-dppm-10.txt 
Network Working Group W. Sun, Ed. Network Working Group W. Sun, Ed.
Internet-Draft SJTU Internet-Draft SJTU
Intended status: Standards Track G. Zhang, Ed. Intended status: Standards Track G. Zhang, Ed.
Expires: February 3, 2010 CATR Expires: April 5, 2010 CATR
September 27, 2009 October 2, 2009
Label Switched Path (LSP) Dynamic Provisioning Performance Metrics in Label Switched Path (LSP) Dynamic Provisioning Performance Metrics in
Generalized MPLS Networks Generalized MPLS Networks
draft-ietf-ccamp-lsp-dppm-09.txt draft-ietf-ccamp-lsp-dppm-10.txt
Status of this Memo Status of this Memo
This Internet-Draft is submitted to IETF in full conformance with the This Internet-Draft is submitted to IETF in full conformance with the
provisions of BCP 78 and BCP 79. This document may contain material provisions of BCP 78 and BCP 79. This document may contain material
from IETF Documents or IETF Contributions published or made publicly from IETF Documents or IETF Contributions published or made publicly
available before November 10, 2008. The person(s) controlling the available before November 10, 2008. The person(s) controlling the
copyright in some of this material may not have granted the IETF copyright in some of this material may not have granted the IETF
Trust the right to allow modifications of such material outside the Trust the right to allow modifications of such material outside the
IETF Standards Process. Without obtaining an adequate license from IETF Standards Process. Without obtaining an adequate license from
skipping to change at page 1, line 44 skipping to change at page 1, line 44
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt. http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html.
This Internet-Draft will expire on March 31, 2010. This Internet-Draft will expire on April 5, 2010.
Copyright Notice Copyright Notice
Copyright (c) 2009 IETF Trust and the persons identified as the Copyright (c) 2009 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents in effect on the date of Provisions Relating to IETF Documents in effect on the date of
publication of this document (http://trustee.ietf.org/license-info). publication of this document (http://trustee.ietf.org/license-info).
Please review these documents carefully, as they describe your rights Please review these documents carefully, as they describe your rights
skipping to change at page 4, line 33 skipping to change at page 4, line 33
5. A Singleton Definition for Multiple Unidirectional LSP 5. A Singleton Definition for Multiple Unidirectional LSP
Setup Delay . . . . . . . . . . . . . . . . . . . . . . . . . 14 Setup Delay . . . . . . . . . . . . . . . . . . . . . . . . . 14
5.1. Motivation . . . . . . . . . . . . . . . . . . . . . . . . 14 5.1. Motivation . . . . . . . . . . . . . . . . . . . . . . . . 14
5.2. Metric Name . . . . . . . . . . . . . . . . . . . . . . . 14 5.2. Metric Name . . . . . . . . . . . . . . . . . . . . . . . 14
5.3. Metric Parameters . . . . . . . . . . . . . . . . . . . . 14 5.3. Metric Parameters . . . . . . . . . . . . . . . . . . . . 14
5.4. Metric Units . . . . . . . . . . . . . . . . . . . . . . . 14 5.4. Metric Units . . . . . . . . . . . . . . . . . . . . . . . 14
5.5. Definition . . . . . . . . . . . . . . . . . . . . . . . . 14 5.5. Definition . . . . . . . . . . . . . . . . . . . . . . . . 14
5.6. Discussion . . . . . . . . . . . . . . . . . . . . . . . . 15 5.6. Discussion . . . . . . . . . . . . . . . . . . . . . . . . 15
5.7. Methodologies . . . . . . . . . . . . . . . . . . . . . . 16 5.7. Methodologies . . . . . . . . . . . . . . . . . . . . . . 16
5.8. Metric Reporting . . . . . . . . . . . . . . . . . . . . . 16 5.8. Metric Reporting . . . . . . . . . . . . . . . . . . . . . 17
6. A Singleton Definition for Single Bidirectional LSP Setup 6. A Singleton Definition for Single Bidirectional LSP Setup
Delay . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17 Delay . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
6.1. Motivation . . . . . . . . . . . . . . . . . . . . . . . . 17 6.1. Motivation . . . . . . . . . . . . . . . . . . . . . . . . 18
6.2. Metric Name . . . . . . . . . . . . . . . . . . . . . . . 17 6.2. Metric Name . . . . . . . . . . . . . . . . . . . . . . . 18
6.3. Metric Parameters . . . . . . . . . . . . . . . . . . . . 17 6.3. Metric Parameters . . . . . . . . . . . . . . . . . . . . 18
6.4. Metric Units . . . . . . . . . . . . . . . . . . . . . . . 18 6.4. Metric Units . . . . . . . . . . . . . . . . . . . . . . . 19
6.5. Definition . . . . . . . . . . . . . . . . . . . . . . . . 18 6.5. Definition . . . . . . . . . . . . . . . . . . . . . . . . 19
6.6. Discussion . . . . . . . . . . . . . . . . . . . . . . . . 18 6.6. Discussion . . . . . . . . . . . . . . . . . . . . . . . . 19
6.7. Methodologies . . . . . . . . . . . . . . . . . . . . . . 19 6.7. Methodologies . . . . . . . . . . . . . . . . . . . . . . 20
6.8. Metric Reporting . . . . . . . . . . . . . . . . . . . . . 20 6.8. Metric Reporting . . . . . . . . . . . . . . . . . . . . . 20
7. A Singleton Definition for Multiple Bidirectional LSPs 7. A Singleton Definition for Multiple Bidirectional LSPs
Setup Delay . . . . . . . . . . . . . . . . . . . . . . . . . 21 Setup Delay . . . . . . . . . . . . . . . . . . . . . . . . . 22
7.1. Motivation . . . . . . . . . . . . . . . . . . . . . . . . 21 7.1. Motivation . . . . . . . . . . . . . . . . . . . . . . . . 22
7.2. Metric Name . . . . . . . . . . . . . . . . . . . . . . . 21 7.2. Metric Name . . . . . . . . . . . . . . . . . . . . . . . 22
7.3. Metric Parameters . . . . . . . . . . . . . . . . . . . . 21 7.3. Metric Parameters . . . . . . . . . . . . . . . . . . . . 22
7.4. Metric Units . . . . . . . . . . . . . . . . . . . . . . . 21 7.4. Metric Units . . . . . . . . . . . . . . . . . . . . . . . 22
7.5. Definition . . . . . . . . . . . . . . . . . . . . . . . . 21 7.5. Definition . . . . . . . . . . . . . . . . . . . . . . . . 22
7.6. Discussion . . . . . . . . . . . . . . . . . . . . . . . . 22 7.6. Discussion . . . . . . . . . . . . . . . . . . . . . . . . 23
7.7. Methodologies . . . . . . . . . . . . . . . . . . . . . . 23 7.7. Methodologies . . . . . . . . . . . . . . . . . . . . . . 24
7.8. Metric Reporting . . . . . . . . . . . . . . . . . . . . . 24 7.8. Metric Reporting . . . . . . . . . . . . . . . . . . . . . 25
8. A Singleton Definition for LSP Graceful Release Delay . . . . 25 8. A Singleton Definition for LSP Graceful Release Delay . . . . 26
8.1. Motivation . . . . . . . . . . . . . . . . . . . . . . . . 25 8.1. Motivation . . . . . . . . . . . . . . . . . . . . . . . . 26
8.2. Metric Name . . . . . . . . . . . . . . . . . . . . . . . 25 8.2. Metric Name . . . . . . . . . . . . . . . . . . . . . . . 26
8.3. Metric Parameters . . . . . . . . . . . . . . . . . . . . 25 8.3. Metric Parameters . . . . . . . . . . . . . . . . . . . . 26
8.4. Metric Units . . . . . . . . . . . . . . . . . . . . . . . 25 8.4. Metric Units . . . . . . . . . . . . . . . . . . . . . . . 26
8.5. Definition . . . . . . . . . . . . . . . . . . . . . . . . 25 8.5. Definition . . . . . . . . . . . . . . . . . . . . . . . . 26
8.6. Discussion . . . . . . . . . . . . . . . . . . . . . . . . 26 8.6. Discussion . . . . . . . . . . . . . . . . . . . . . . . . 27
8.7. Methodologies . . . . . . . . . . . . . . . . . . . . . . 27 8.7. Methodologies . . . . . . . . . . . . . . . . . . . . . . 28
8.8. Metric Reporting . . . . . . . . . . . . . . . . . . . . . 28 8.8. Metric Reporting . . . . . . . . . . . . . . . . . . . . . 29
9. A Definition for Samples of Single Unidirectional LSP 9. A Definition for Samples of Single Unidirectional LSP
Setup Delay . . . . . . . . . . . . . . . . . . . . . . . . . 29 Setup Delay . . . . . . . . . . . . . . . . . . . . . . . . . 30
9.1. Metric Name . . . . . . . . . . . . . . . . . . . . . . . 29 9.1. Metric Name . . . . . . . . . . . . . . . . . . . . . . . 30
9.2. Metric Parameters . . . . . . . . . . . . . . . . . . . . 29 9.2. Metric Parameters . . . . . . . . . . . . . . . . . . . . 30
9.3. Metric Units . . . . . . . . . . . . . . . . . . . . . . . 29 9.3. Metric Units . . . . . . . . . . . . . . . . . . . . . . . 30
9.4. Definition . . . . . . . . . . . . . . . . . . . . . . . . 29 9.4. Definition . . . . . . . . . . . . . . . . . . . . . . . . 30
9.5. Discussion . . . . . . . . . . . . . . . . . . . . . . . . 30 9.5. Discussion . . . . . . . . . . . . . . . . . . . . . . . . 31
9.6. Methodologies . . . . . . . . . . . . . . . . . . . . . . 30 9.6. Methodologies . . . . . . . . . . . . . . . . . . . . . . 31
9.7. Typical testing cases . . . . . . . . . . . . . . . . . . 31 9.7. Typical testing cases . . . . . . . . . . . . . . . . . . 32
9.7.1. With no LSP in the Network . . . . . . . . . . . . . . 31 9.7.1. With no LSP in the Network . . . . . . . . . . . . . . 32
9.7.2. With a number of LSPs in the Network . . . . . . . . . 31 9.7.2. With a number of LSPs in the Network . . . . . . . . . 32
9.8. Metric Reporting . . . . . . . . . . . . . . . . . . . . . 31 9.8. Metric Reporting . . . . . . . . . . . . . . . . . . . . . 32
10. A Definition for Samples of Multiple Unidirectional LSPs 10. A Definition for Samples of Multiple Unidirectional LSPs
Setup Delay . . . . . . . . . . . . . . . . . . . . . . . . . 32 Setup Delay . . . . . . . . . . . . . . . . . . . . . . . . . 33
10.1. Metric Name . . . . . . . . . . . . . . . . . . . . . . . 32 10.1. Metric Name . . . . . . . . . . . . . . . . . . . . . . . 33
10.2. Metric Parameters . . . . . . . . . . . . . . . . . . . . 32 10.2. Metric Parameters . . . . . . . . . . . . . . . . . . . . 33
10.3. Metric Units . . . . . . . . . . . . . . . . . . . . . . . 32 10.3. Metric Units . . . . . . . . . . . . . . . . . . . . . . . 33
10.4. Definition . . . . . . . . . . . . . . . . . . . . . . . . 32 10.4. Definition . . . . . . . . . . . . . . . . . . . . . . . . 33
10.5. Discussion . . . . . . . . . . . . . . . . . . . . . . . . 33 10.5. Discussion . . . . . . . . . . . . . . . . . . . . . . . . 34
10.6. Methodologies . . . . . . . . . . . . . . . . . . . . . . 33 10.6. Methodologies . . . . . . . . . . . . . . . . . . . . . . 34
10.7. Typical testing cases . . . . . . . . . . . . . . . . . . 34 10.7. Typical testing cases . . . . . . . . . . . . . . . . . . 35
10.7.1. With No LSP in the Network . . . . . . . . . . . . . . 34 10.7.1. With No LSP in the Network . . . . . . . . . . . . . . 35
10.7.2. With a Number of LSPs in the Network . . . . . . . . . 34 10.7.2. With a Number of LSPs in the Network . . . . . . . . . 35
10.8. Metric Reporting . . . . . . . . . . . . . . . . . . . . . 34 10.8. Metric Reporting . . . . . . . . . . . . . . . . . . . . . 35
11. A Definition for Samples of Single Bidirectional LSP Setup 11. A Definition for Samples of Single Bidirectional LSP Setup
Delay . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35 Delay . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36
11.1. Metric Name . . . . . . . . . . . . . . . . . . . . . . . 35 11.1. Metric Name . . . . . . . . . . . . . . . . . . . . . . . 36
11.2. Metric Parameters . . . . . . . . . . . . . . . . . . . . 35 11.2. Metric Parameters . . . . . . . . . . . . . . . . . . . . 36
11.3. Metric Units . . . . . . . . . . . . . . . . . . . . . . . 35 11.3. Metric Units . . . . . . . . . . . . . . . . . . . . . . . 36
11.4. Definition . . . . . . . . . . . . . . . . . . . . . . . . 35 11.4. Definition . . . . . . . . . . . . . . . . . . . . . . . . 36
11.5. Discussion . . . . . . . . . . . . . . . . . . . . . . . . 36 11.5. Discussion . . . . . . . . . . . . . . . . . . . . . . . . 37
11.6. Methodologies . . . . . . . . . . . . . . . . . . . . . . 36 11.6. Methodologies . . . . . . . . . . . . . . . . . . . . . . 37
11.7. Typical testing cases . . . . . . . . . . . . . . . . . . 37 11.7. Typical testing cases . . . . . . . . . . . . . . . . . . 38
11.7.1. With No LSP in the Network . . . . . . . . . . . . . . 37 11.7.1. With No LSP in the Network . . . . . . . . . . . . . . 38
11.7.2. With a Number of LSPs in the Network . . . . . . . . . 37 11.7.2. With a Number of LSPs in the Network . . . . . . . . . 38
11.8. Metric Reporting . . . . . . . . . . . . . . . . . . . . . 37 11.8. Metric Reporting . . . . . . . . . . . . . . . . . . . . . 38
12. A Definition for Samples of Multiple Bidirectional LSPs 12. A Definition for Samples of Multiple Bidirectional LSPs
Setup Delay . . . . . . . . . . . . . . . . . . . . . . . . . 38 Setup Delay . . . . . . . . . . . . . . . . . . . . . . . . . 39
12.1. Metric Name . . . . . . . . . . . . . . . . . . . . . . . 38 12.1. Metric Name . . . . . . . . . . . . . . . . . . . . . . . 39
12.2. Metric Parameters . . . . . . . . . . . . . . . . . . . . 38 12.2. Metric Parameters . . . . . . . . . . . . . . . . . . . . 39
12.3. Metric Units . . . . . . . . . . . . . . . . . . . . . . . 38 12.3. Metric Units . . . . . . . . . . . . . . . . . . . . . . . 39
12.4. Definition . . . . . . . . . . . . . . . . . . . . . . . . 38 12.4. Definition . . . . . . . . . . . . . . . . . . . . . . . . 39
12.5. Discussion . . . . . . . . . . . . . . . . . . . . . . . . 39 12.5. Discussion . . . . . . . . . . . . . . . . . . . . . . . . 40
12.6. Methodologies . . . . . . . . . . . . . . . . . . . . . . 39 12.6. Methodologies . . . . . . . . . . . . . . . . . . . . . . 40
12.7. Typical testing cases . . . . . . . . . . . . . . . . . . 40 12.7. Typical testing cases . . . . . . . . . . . . . . . . . . 41
12.7.1. With No LSP in the Network . . . . . . . . . . . . . . 40 12.7.1. With No LSP in the Network . . . . . . . . . . . . . . 41
12.7.2. With a Number of LSPs in the Network . . . . . . . . . 40 12.7.2. With a Number of LSPs in the Network . . . . . . . . . 41
12.8. Metric Reporting . . . . . . . . . . . . . . . . . . . . . 40 12.8. Metric Reporting . . . . . . . . . . . . . . . . . . . . . 41
13. A Definition for Samples of LSP Graceful Release Delay . . . . 41 13. A Definition for Samples of LSP Graceful Release Delay . . . . 42
13.1. Metric Name . . . . . . . . . . . . . . . . . . . . . . . 41 13.1. Metric Name . . . . . . . . . . . . . . . . . . . . . . . 42
13.2. Metric Parameters . . . . . . . . . . . . . . . . . . . . 41 13.2. Metric Parameters . . . . . . . . . . . . . . . . . . . . 42
13.3. Metric Units . . . . . . . . . . . . . . . . . . . . . . . 41 13.3. Metric Units . . . . . . . . . . . . . . . . . . . . . . . 42
13.4. Definition . . . . . . . . . . . . . . . . . . . . . . . . 41 13.4. Definition . . . . . . . . . . . . . . . . . . . . . . . . 42
13.5. Discussion . . . . . . . . . . . . . . . . . . . . . . . . 41 13.5. Discussion . . . . . . . . . . . . . . . . . . . . . . . . 42
13.6. Methodologies . . . . . . . . . . . . . . . . . . . . . . 42 13.6. Methodologies . . . . . . . . . . . . . . . . . . . . . . 43
13.7. Metric Reporting . . . . . . . . . . . . . . . . . . . . . 42 13.7. Metric Reporting . . . . . . . . . . . . . . . . . . . . . 43
14. Some Statistics Definitions for Metrics to Report . . . . . . 43 14. Some Statistics Definitions for Metrics to Report . . . . . . 44
14.1. The Minimum of Metric . . . . . . . . . . . . . . . . . . 43 14.1. The Minimum of Metric . . . . . . . . . . . . . . . . . . 44
14.2. The Median of Metric . . . . . . . . . . . . . . . . . . . 43 14.2. The Median of Metric . . . . . . . . . . . . . . . . . . . 44
14.3. The Maximum of Metric . . . . . . . . . . . . . . . . . . 43 14.3. The Maximum of Metric . . . . . . . . . . . . . . . . . . 44
14.4. The Percentile of Metric . . . . . . . . . . . . . . . . . 43 14.4. The Percentile of Metric . . . . . . . . . . . . . . . . . 44
14.5. Failure statistics of Metric . . . . . . . . . . . . . . . 43 14.5. Failure statistics of Metric . . . . . . . . . . . . . . . 44
14.5.1. Failure Count . . . . . . . . . . . . . . . . . . . . 44 14.5.1. Failure Count . . . . . . . . . . . . . . . . . . . . 45
14.5.2. Failure Ratio . . . . . . . . . . . . . . . . . . . . 44 14.5.2. Failure Ratio . . . . . . . . . . . . . . . . . . . . 45
15. Discussion . . . . . . . . . . . . . . . . . . . . . . . . . . 45 15. Discussion . . . . . . . . . . . . . . . . . . . . . . . . . . 46
16. Security Considerations . . . . . . . . . . . . . . . . . . . 46 16. Security Considerations . . . . . . . . . . . . . . . . . . . 47
17. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 47 17. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 48
18. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 48 18. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 49
19. References . . . . . . . . . . . . . . . . . . . . . . . . . . 49 19. References . . . . . . . . . . . . . . . . . . . . . . . . . . 50
19.1. Normative References . . . . . . . . . . . . . . . . . . . 49 19.1. Normative References . . . . . . . . . . . . . . . . . . . 50
19.2. Informative References . . . . . . . . . . . . . . . . . . 49 19.2. Informative References . . . . . . . . . . . . . . . . . . 50
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 51 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 52
1. Introduction 1. Introduction
Generalized Multi-Protocol Label Switching (GMPLS) is one of the most Generalized Multi-Protocol Label Switching (GMPLS) is one of the most
promising control plane solutions for future transport and service promising control plane solutions for future transport and service
network. GMPLS has been developed to control and operate different network. GMPLS has been developed to control and operate different
kinds of network elements, such as conventional routers, switches, kinds of network elements, such as conventional routers, switches,
Dense Wavelength Division Multiplexing (DWDM) systems, Add-Drop Dense Wavelength Division Multiplexing (DWDM) systems, Add-Drop
Multiplexors (ADMs), photonic cross-connects (PXCs), optical cross- Multiplexors (ADMs), photonic cross-connects (PXCs), optical cross-
connects (OXCs), etc. The dynamic provisioning ability of these connects (OXCs), etc. The dynamic provisioning ability of these
skipping to change at page 12, line 51 skipping to change at page 12, line 51
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 and the value MUST be reported. bound SHOULD be chosen carefully.
o If ingress node sends out the Path message to set up an LSP, but o If ingress node sends out the Path message to set up an LSP, but
never receives the corresponding Resv message, the unidirectional never receives the corresponding Resv message, the unidirectional
LSP setup delay MUST be set to undefined. 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 the network does not have enough resource to set up the or the network does not have enough resource to set up the
skipping to change at page 13, line 46 skipping to change at page 13, line 46
deemed to be undefined. Note that the 'reasonable' threshold is a deemed to be undefined. Note that the 'reasonable' threshold is a
parameter of the methodology. parameter of the methodology.
o If the corresponding response is a PathErr message, the o If the corresponding response is a PathErr message, the
unidirectional LSP setup delay is deemed to be undefined. unidirectional LSP setup delay is deemed to be undefined.
4.8. Metric Reporting 4.8. Metric Reporting
The metric result (either a real or an undefined value) MUST be The metric result (either a real or an undefined value) MUST be
reported together with the selected uppper bound. The route that the reported together with the selected uppper bound. The route that the
LSP tranverses MUST also be reported. LSP traverses MUST also be reported. The route MAY be collected via
use of the record route object, see [RFC3209], or via the management
plane. The collection of routes via the management plane is out of
scope of this document.
5. A Singleton Definition for Multiple Unidirectional LSP Setup Delay 5. A Singleton Definition for Multiple Unidirectional LSP Setup Delay
This part defines a metric for multiple unidirectional Label Switched This part defines a metric for multiple unidirectional Label Switched
Paths setup delay across a GMPLS network. Paths setup delay across a GMPLS network.
5.1. Motivation 5.1. Motivation
Multiple unidirectional Label Switched Paths setup delay is useful Multiple unidirectional Label Switched Paths setup delay is useful
for several reasons: for several reasons:
skipping to change at page 15, line 40 skipping to change at page 15, line 40
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 and the value MUST be reported. chosen carefully.
o If ingress node sends out the multiple Path messages to set up the o If ingress node sends out the multiple Path messages to set up the
LSPs, but never receives one or more of the corresponding Resv LSPs, but never receives one or more of the corresponding Resv
messages, 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 ingress node sends out the Path messages to set up the LSPs but
receives one or more PathErr messages, multiple unidirectional receives one or more PathErr messages, multiple unidirectional
LSPs setup delay 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 has not enough
resource to set up the requested LSPs, etc. resource to set up the requested LSPs, etc.
o The arrival rate of the Poisson process Lambda_m SHOULD be 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 in 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.
If there are multiple routes between the Ingress node ID0 and
Egress node ID1, EROs or an alternate method, e.g., static
configuration, MUST be used to ensure that 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 resource to set up the
requested LSPs. requested LSPs.
o At the ingress node, form the Path messages according to the LSPs' o At the ingress node, form the Path messages according to the LSPs'
requirements. requirements.
skipping to change at page 16, line 48 skipping to change at page 17, line 9
'reasonable' threshold is a parameter of the methodology. 'reasonable' threshold is a parameter of the methodology.
o If one or more of the corresponding response are PathErr messages, o If one or more of the corresponding response are PathErr messages,
the multiple unidirectional LSPs setup delay is deemed to be the multiple unidirectional LSPs setup delay is deemed to be
undefined. undefined.
5.8. Metric Reporting 5.8. Metric Reporting
The metric result (either a real or an undefined value) MUST be The metric result (either a real or an undefined value) MUST be
reported together with the selected uppper bound. The route that the reported together with the selected uppper bound. The route that the
LSPs tranverse MUST also be reported. LSPs traverse MUST also be reported. The route MAY be collected via
use of the record route object, see [RFC3209], or via the management
plane. The collection of routes via the management plane is out of
scope of this document.
6. A Singleton Definition for Single Bidirectional LSP Setup Delay 6. A Singleton Definition for Single Bidirectional LSP Setup Delay
GMPLS allows establishment of bidirectional symmetric LSPs (not of GMPLS allows establishment of bidirectional symmetric LSPs (not of
asymmetric LSPs). This part defines a metric for single asymmetric LSPs). This part defines a metric for single
bidirectional LSP setup delay across a GMPLS network. bidirectional LSP setup delay across a GMPLS network.
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
skipping to change at page 19, line 8 skipping to change at page 20, line 8
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 and the value MUST be upper bound SHOULD be chosen carefully.
reported.
o If the ingress node sends out the Path message to set up the LSP, o If the ingress node sends out the Path message to set up the LSP,
but never receives the corresponding Resv message, single but never receives the corresponding Resv message, single
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 has not enough resource to set up the
skipping to change at page 20, line 9 skipping to change at page 20, line 51
delay is deemed to be undefined. Note that the 'reasonable' delay is deemed to be undefined. Note that the 'reasonable'
threshold is a parameter of the methodology. threshold is a parameter of the methodology.
o If the corresponding response is a PathErr message, the single o If the corresponding response is a PathErr message, the single
bidirectional LSP setup delay is deemed to be undefined. bidirectional LSP setup delay is deemed to be undefined.
6.8. Metric Reporting 6.8. Metric Reporting
The metric result (either a real or an undefined value) MUST be The metric result (either a real or an undefined value) MUST be
reported together with the selected uppper bound. The route that the reported together with the selected uppper bound. The route that the
LSP tranverses MUST also be reported. LSP traverses MUST also be reported. The route MAY be collected via
use of the record route object, see [RFC3209], or via the management
plane. The collection of routes via the management plane is out of
scope of this document.
7. A Singleton Definition for Multiple Bidirectional LSPs Setup Delay 7. A Singleton Definition for Multiple Bidirectional LSPs Setup Delay
This part defines a metric for multiple bidirectional LSPs setup This part defines a metric for multiple bidirectional LSPs setup
delay across a GMPLS network. delay across a GMPLS network.
7.1. Motivation 7.1. Motivation
Multiple bidirectional LSPs setup delay is useful for several Multiple bidirectional LSPs setup delay is useful for several
reasons: reasons:
skipping to change at page 22, line 45 skipping to change at page 23, line 45
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 and the value practice, the upper bound SHOULD be chosen carefully.
MUST be reported.
o If the ingress node sends out the Path messages to set up the o If the ingress node sends out the Path messages to set up the
LSPs, but never 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 has not enough resource 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.
If there are multiple routes between the Ingress node ID0 and
Egress node ID1, EROs or an alternate method, e.g., static
configuration, MUST be used to ensure that all LSPs traverse the
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 resource to set up the
requested LSPs. requested LSPs.
o At the ingress node, form the Path messages (including the o At the ingress node, form the Path messages (including the
Upstream Label or suggested label) according to the LSPs' Upstream Label or suggested label) according to the LSPs'
requirements. requirements.
skipping to change at page 24, line 9 skipping to change at page 25, line 13
'reasonable' threshold is a parameter of the methodology. 'reasonable' threshold is a parameter of the methodology.
o If one or more of the corresponding response are PathErr messages, o If one or more of the corresponding response are PathErr messages,
the multiple bidirectional LSPs setup delay is deemed to be the multiple bidirectional LSPs setup delay is deemed to be
undefined. undefined.
7.8. Metric Reporting 7.8. Metric Reporting
The metric result (either a real or an undefined value) MUST be The metric result (either a real or an undefined value) MUST be
reported together with the selected uppper bound. The route that the reported together with the selected uppper bound. The route that the
LSPs tranverse MUST also be reported. LSPs traverse MUST also be reported. The route MAY be collected via
use of the record route object, see [RFC3209], or via the management
plane. The collection of routes via the management plane is out of
scope of this document.
8. A Singleton Definition for LSP Graceful Release Delay 8. A Singleton Definition for LSP Graceful Release Delay
There are two different kinds of LSP release mechanisms in GMPLS There are two different kinds of LSP release mechanisms in GMPLS
networks: graceful release and forceful release. This document does networks: graceful release and forceful release. This document does
not take forceful LSP release procedure into account. not take forceful LSP release procedure into account.
8.1. Motivation 8.1. Motivation
LSP graceful release delay is useful for several reasons: LSP graceful release delay is useful for several reasons:
skipping to change at page 27, line 8 skipping to change at page 28, line 8
o In the first (second) circumstance, the accuracy of LSP graceful o In the first (second) circumstance, the accuracy of LSP graceful
release delay at time T depends on the clock resolution in the release delay at time T depends on the clock resolution in the
ingress (egress) node. In the first circumstance, synchronization ingress (egress) node. In the first circumstance, synchronization
between the ingress node and egress node is required; but not in between the ingress node and egress node is required; but not in
the second circumstance; the second circumstance;
o A given methodology has to include a way to determine whether a o A given methodology has to include a way to determine whether a
latency value is infinite or whether it is merely very large. latency value is infinite or whether it is merely very large.
Simple upper bounds 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 and the value MUST be reported; 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 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 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
skipping to change at page 28, line 32 skipping to change at page 29, line 32
time, the LSP graceful release delay is deemed to be undefined. time, the LSP graceful release delay is deemed to be undefined.
Note that the 'reasonable' threshold is a parameter of the Note that the 'reasonable' threshold is a parameter of the
methodology. methodology.
8.8. Metric Reporting 8.8. Metric Reporting
The metric result (either a real or an undefined value) MUST be The metric result (either a real or an undefined value) MUST be
reported together with the selected uppper bound and the procedure reported together with the selected uppper bound and the procedure
used (eg. either from the ingress node to the egress node, or from used (eg. 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 tranverses 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
[RFC3209], or via the management plane. The collection of routes via
the management plane is out of scope of this document.
9. A Definition for Samples of Single Unidirectional LSP Setup Delay 9. A Definition for Samples of Single Unidirectional LSP Setup Delay
In Section 4, we have defined the singleton metric of Single In Section 4, we have defined the singleton metric of Single
unidirectional LSP setup delay. Now we define how to get one unidirectional LSP setup delay. Now we define how to get one
particular sample of Single unidirectional LSP setup delay. Sampling particular sample of Single unidirectional LSP setup delay. Sampling
is to select a particular potion of singleton values of the given is to select a particular potion of singleton values of the given
parameters. Like in [RFC2330], we use Poisson sampling as an parameters. Like in [RFC2330], we use Poisson sampling as an
example. example.
skipping to change at page 30, line 32 skipping to change at page 31, line 32
of the network. The selection of Th should take into account that of the network. The selection of Th should take into account that
the network has sufficient resource to perform subsequent tests. The the network has sufficient resource to perform subsequent tests. The
value of Th MAY be constant during one sampling process for value of Th MAY be constant during one sampling process for
simplicity considerations. simplicity considerations.
Note that for online or passive measurements, the 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 case
Lambda and Th are not input parameters. 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 traverse
the same route. Ways to realize this is outside the scope of this the same route. If there are multiple routes between the Ingress
document. However, it is desirable that the method used have minimal node ID0 and Egress node ID1, EROs or an alternate method, e.g.,
impact on the signaling process and the method SHOULD be reported. static configuration, MUST be used to ensure that all LSPs 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, and
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
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
skipping to change at page 31, line 43 skipping to change at page 32, line 43
Setup the required number of LSPs, and wait until the network reaches Setup the required number of LSPs, and wait until the network reaches
a stable state, then proceed with the methodologies described in a stable state, then proceed with the methodologies described in
Section 9.6. Section 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 have defined the singleton metric of multiple
unidirectional LSPs setup delay. Now we define how to get one unidirectional LSPs setup delay. Now we define how to get one
particular sample of multiple unidirectional LSP setup delay. particular sample of multiple unidirectional LSP setup delay.
Sampling is to select a particular potion of singleton values of the Sampling is to select a particular potion of singleton values of the
given parameters. Like in [RFC2330], we use Poisson sampling as an given parameters. Like in [RFC2330], we use Poisson sampling as an
skipping to change at page 33, line 32 skipping to change at page 34, line 32
hand if the rate is too low, the sample could not completely reflect hand if the rate is too low, the sample could not completely reflect
the dynamic provisioning performance of the GMPLS network. The the dynamic provisioning performance of the GMPLS network. The
appropriate Lambda and Lambda_m value depends on the given network. appropriate Lambda and Lambda_m value depends on the given network.
The parameters Td should be carefully chosen. Different switching The parameters Td should be carefully chosen. Different switching
technologies may vary significantly in performing a cross-connect technologies may vary significantly in performing a cross-connect
operation. At the same time, the time needed in setting up an LSP operation. At the same time, the time needed in setting up an LSP
under different traffic may also vary significantly. under different traffic may also vary significantly.
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 traverse
the same route. Ways to realize this is outside the scope of this the same route. If there are multiple routes between the Ingress
document. However, it is desirable that the method used have minimal node ID0 and Egress node ID1, EROs or an alternate method, e.g.,
impact on the signaling process and the method SHOULD be reported. static configuration, MUST be used to ensure that all LSPs 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, and
o Set up the LSP as the methodology for the singleton multiple o Set up the LSP as the methodology for the singleton multiple
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
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
skipping to change at page 34, line 43 skipping to change at page 35, line 44
Setup the required number of LSPs, and wait until the network reaches Setup the required number of LSPs, and wait until the network reaches
a stable state, then proceed with the methodologies described in a stable state, then proceed with the methodologies described in
Section 10.6. Section 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 have defined the singleton metric of Single
Bidirectional LSP setup delay. Now we define how to get one Bidirectional LSP setup delay. Now we define how to get one
particular sample of Single Bidirectional LSP setup delay. Sampling particular sample of Single Bidirectional LSP setup delay. Sampling
is to select a particular potion of singleton values of the given is to select a particular potion of singleton values of the given
parameters. Like in [RFC2330], we use Poisson sampling as an parameters. Like in [RFC2330], we use Poisson sampling as an
example. example.
skipping to change at page 36, line 33 skipping to change at page 37, line 33
of the network. The selection of Th SHOULD take into account that of the network. The selection of Th SHOULD take into account that
the network has sufficient resource to perform subsequent tests. The the network has sufficient resource to perform subsequent tests. The
value of Th MAY be constant during one sampling process for value of Th MAY be constant during one sampling process for
simplicity considerations. simplicity considerations.
Note that for online or passive measurements, the 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 traverse
the same route. Ways to realize this is outside the scope of this the same route. If there are multiple routes between the Ingress
document. However, it is desirable that the method used have minimal node ID0 and Egress node ID1, EROs or an alternate method, e.g.,
impact on the signaling process and the method SHOULD be reported. static configuration, MUST be used to ensure that all LSPs 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, and
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
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
skipping to change at page 37, line 44 skipping to change at page 38, line 45
Setup the required number of LSPs, and wait until the network reaches Setup the required number of LSPs, and wait until the network reaches
a stable state, then proceed with the methodologies described in a stable state, then proceed with the methodologies described in
Section 11.6. Section 11.6.
11.8. Metric Reporting 11.8. Metric Reporting
The metric results including both real and undefined values MUST be The metric results including both real and undefined values MUST be
reported together with the total number of values. The context under reported together with the total number of values. The context under
which the sample is obtained, including the selected parameters, the which the sample is obtained, including the selected parameters, the
route traversed by the LSPs, and the testing case used MUST also be route traversed by the LSPs, and the testing case used, MUST also be
reported. reported.
12. A Definition for Samples of Multiple Bidirectional LSPs Setup 12. A Definition for Samples of Multiple Bidirectional LSPs Setup
Delay Delay
In Section 7, we have defined the singleton metric of multiple In Section 7, we have defined the singleton metric of multiple
bidirectional LSPs setup delay. Now we define how to get one bidirectional LSPs setup delay. Now we define how to get one
particular sample of multiple bidirectional LSP setup delay. particular sample of multiple bidirectional LSP setup delay.
Sampling is to select a particular potion of singleton values of the Sampling is to select a particular potion of singleton values of the
given parameters. Like in [RFC2330], we use Poisson sampling as an given parameters. Like in [RFC2330], we use Poisson sampling as an
skipping to change at page 39, line 32 skipping to change at page 40, line 32
hand if the rate is too low, the sample could not completely reflect hand if the rate is too low, the sample could not completely reflect
the dynamic provisioning performance of the GMPLS network. The the dynamic provisioning performance of the GMPLS network. The
appropriate Lambda and Lambda_m value depends on the given network. appropriate Lambda and Lambda_m value depends on the given network.
The parameters Td should be carefully chosen. Different switching The parameters Td should be carefully chosen. Different switching
technologies may vary significantly in performing a cross-connect technologies may vary significantly in performing a cross-connect
operation. At the same time, the time needed in setting up an LSP operation. At the same time, the time needed in setting up an LSP
under different traffic may also vary significantly. under different traffic may also vary significantly.
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 traverse
the same route. Ways to realize this is outside the scope of this the same route. If there are multiple routes between the Ingress
document. However, it is desirable that the method used have minimal node ID0 and Egress node ID1, EROs or an alternate method, e.g.,
impact on the signaling process and the method SHOULD be reported. static configuration, MUST be used to ensure that all LSPs 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, and
o Set up the LSP as the methodology for the singleton multiple o Set up the LSP as the methodology for the singleton multiple
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
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
skipping to change at page 40, line 43 skipping to change at page 41, line 44
Setup the required number of LSPs, and wait until the network reaches Setup the required number of LSPs, and wait until the network reaches
a stable state, then proceed with the methodologies described in a stable state, then proceed with the methodologies described in
Section 12.6. Section 12.6.
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 have defined the singleton metric of LSP graceful
release delay. Now we define how to get one particular sample of LSP release delay. Now we define how to get one particular sample of LSP
graceful release delay. We also use Poisson sampling as an example. graceful release delay. We also use Poisson sampling as an example.
13.1. Metric Name 13.1. Metric Name
skipping to change at page 42, line 11 skipping to change at page 43, line 11
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, 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 small, the sample could not completely reflect the rate is too small, the sample could not completely reflect the
dynamic provisioning performance of the GMPLS network. The dynamic provisioning performance of the GMPLS network. The
appropriate Lambda value depends on the given network. appropriate Lambda value depends on the given network.
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 traverse
the same route. Ways to realize this is outside the scope of this the same route. If there are multiple routes between the Ingress
document. However, it is desirable that the method used have minimal node ID0 and Egress node ID1, EROs or an alternate method, e.g.,
impact on the signaling process and the method SHOULD be reported. static configuration, MUST be used to ensure that all LSPs 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 Setup 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, and
o Release the LSP as the methodology for the singleton LSP graceful o Release the LSP as the methodology for the singleton LSP graceful
 End of changes. 40 change blocks. 
130 lines changed or deleted 160 lines changed or added

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