idnits 2.17.1 draft-ietf-ccamp-lsp-dppm-11.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** You're using the IETF Trust Provisions' Section 6.b License Notice from 12 Sep 2009 rather than the newer Notice from 28 Dec 2009. (See https://trustee.ietf.org/license-info/) Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document seems to contain a disclaimer for pre-RFC5378 work, and may have content which was first submitted before 10 November 2008. The disclaimer is necessary when there are original authors that you have been unable to contact, or if some do not wish to grant the BCP78 rights to the IETF Trust. If you are able to get all authors (current and original) to grant those rights, you can and should remove the disclaimer; otherwise, the disclaimer is needed and you can ignore this comment. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (December 14, 2009) is 5219 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) ** Obsolete normative reference: RFC 2679 (Obsoleted by RFC 7679) == Outdated reference: A later version (-05) exists of draft-shiomoto-ccamp-switch-programming-01 Summary: 2 errors (**), 0 flaws (~~), 2 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group W. Sun, Ed. 3 Internet-Draft SJTU 4 Intended status: Standards Track G. Zhang, Ed. 5 Expires: June 17, 2010 CATR 6 December 14, 2009 8 Label Switched Path (LSP) Dynamic Provisioning Performance Metrics in 9 Generalized MPLS Networks 10 draft-ietf-ccamp-lsp-dppm-11.txt 12 Abstract 14 Generalized Multi-Protocol Label Switching (GMPLS) is one of the most 15 promising candidate technologies for future data transmission 16 network. GMPLS has been developed to control and operate different 17 kinds of network elements, such as conventional routers, switches, 18 Dense Wavelength Division Multiplexing (DWDM) systems, Add-Drop 19 Multiplexers (ADMs), photonic cross-connects (PXCs), optical cross- 20 connects (OXCs), etc. The dynamic provisioning ability of these 21 physically diverse devices differs from each other drastically. At 22 the same time, the need for dynamically provisioned connections is 23 increasing because optical networks are being deployed in metro 24 areas. As different applications have varied requirements in the 25 provisioning performance of optical networks, it is imperative to 26 define standardized metrics and procedures such that the performance 27 of networks and application needs can be mapped to each other. 29 This document provides a series of performance metrics to evaluate 30 the dynamic Label Switched Path (LSP) provisioning performance in 31 GMPLS networks, specifically the dynamic LSP setup/release 32 performance. These metrics can be used to characterize the features 33 of GMPLS networks in LSP dynamic provisioning. 35 Status of this Memo 37 This Internet-Draft is submitted to IETF in full conformance with the 38 provisions of BCP 78 and BCP 79. 40 Internet-Drafts are working documents of the Internet Engineering 41 Task Force (IETF), its areas, and its working groups. Note that 42 other groups may also distribute working documents as Internet- 43 Drafts. 45 Internet-Drafts are draft documents valid for a maximum of six months 46 and may be updated, replaced, or obsoleted by other documents at any 47 time. It is inappropriate to use Internet-Drafts as reference 48 material or to cite them other than as "work in progress." 49 The list of current Internet-Drafts can be accessed at 50 http://www.ietf.org/ietf/1id-abstracts.txt. 52 The list of Internet-Draft Shadow Directories can be accessed at 53 http://www.ietf.org/shadow.html. 55 This Internet-Draft will expire on June 17, 2010. 57 Copyright Notice 59 Copyright (c) 2009 IETF Trust and the persons identified as the 60 document authors. All rights reserved. 62 This document is subject to BCP 78 and the IETF Trust's Legal 63 Provisions Relating to IETF Documents 64 (http://trustee.ietf.org/license-info) in effect on the date of 65 publication of this document. Please review these documents 66 carefully, as they describe your rights and restrictions with respect 67 to this document. Code Components extracted from this document must 68 include Simplified BSD License text as described in Section 4.e of 69 the Trust Legal Provisions and are provided without warranty as 70 described in the BSD License. 72 This document may contain material from IETF Documents or IETF 73 Contributions published or made publicly available before November 74 10, 2008. The person(s) controlling the copyright in some of this 75 material may not have granted the IETF Trust the right to allow 76 modifications of such material outside the IETF Standards Process. 77 Without obtaining an adequate license from the person(s) controlling 78 the copyright in such materials, this document may not be modified 79 outside the IETF Standards Process, and derivative works of it may 80 not be created outside the IETF Standards Process, except to format 81 it for publication as an RFC or to translate it into languages other 82 than English. 84 Table of Contents 86 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 7 88 2. Conventions Used in This Document . . . . . . . . . . . . . . 8 90 3. Overview of Performance Metrics . . . . . . . . . . . . . . . 9 92 4. A Singleton Definition for Single Unidirectional LSP Setup 93 Delay . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10 94 4.1. Motivation . . . . . . . . . . . . . . . . . . . . . . . . 10 95 4.2. Metric Name . . . . . . . . . . . . . . . . . . . . . . . 10 96 4.3. Metric Parameters . . . . . . . . . . . . . . . . . . . . 10 97 4.4. Metric Units . . . . . . . . . . . . . . . . . . . . . . . 11 98 4.5. Definition . . . . . . . . . . . . . . . . . . . . . . . . 11 99 4.6. Discussion . . . . . . . . . . . . . . . . . . . . . . . . 11 100 4.7. Methodologies . . . . . . . . . . . . . . . . . . . . . . 12 101 4.8. Metric Reporting . . . . . . . . . . . . . . . . . . . . . 12 103 5. A Singleton Definition for Multiple Unidirectional LSP 104 Setup Delay . . . . . . . . . . . . . . . . . . . . . . . . . 13 105 5.1. Motivation . . . . . . . . . . . . . . . . . . . . . . . . 13 106 5.2. Metric Name . . . . . . . . . . . . . . . . . . . . . . . 13 107 5.3. Metric Parameters . . . . . . . . . . . . . . . . . . . . 13 108 5.4. Metric Units . . . . . . . . . . . . . . . . . . . . . . . 13 109 5.5. Definition . . . . . . . . . . . . . . . . . . . . . . . . 13 110 5.6. Discussion . . . . . . . . . . . . . . . . . . . . . . . . 14 111 5.7. Methodologies . . . . . . . . . . . . . . . . . . . . . . 15 112 5.8. Metric Reporting . . . . . . . . . . . . . . . . . . . . . 16 114 6. A Singleton Definition for Single Bidirectional LSP Setup 115 Delay . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17 116 6.1. Motivation . . . . . . . . . . . . . . . . . . . . . . . . 17 117 6.2. Metric Name . . . . . . . . . . . . . . . . . . . . . . . 17 118 6.3. Metric Parameters . . . . . . . . . . . . . . . . . . . . 17 119 6.4. Metric Units . . . . . . . . . . . . . . . . . . . . . . . 18 120 6.5. Definition . . . . . . . . . . . . . . . . . . . . . . . . 18 121 6.6. Discussion . . . . . . . . . . . . . . . . . . . . . . . . 18 122 6.7. Methodologies . . . . . . . . . . . . . . . . . . . . . . 19 123 6.8. Metric Reporting . . . . . . . . . . . . . . . . . . . . . 19 125 7. A Singleton Definition for Multiple Bidirectional LSPs 126 Setup Delay . . . . . . . . . . . . . . . . . . . . . . . . . 21 127 7.1. Motivation . . . . . . . . . . . . . . . . . . . . . . . . 21 128 7.2. Metric Name . . . . . . . . . . . . . . . . . . . . . . . 21 129 7.3. Metric Parameters . . . . . . . . . . . . . . . . . . . . 21 130 7.4. Metric Units . . . . . . . . . . . . . . . . . . . . . . . 21 131 7.5. Definition . . . . . . . . . . . . . . . . . . . . . . . . 21 132 7.6. Discussion . . . . . . . . . . . . . . . . . . . . . . . . 22 133 7.7. Methodologies . . . . . . . . . . . . . . . . . . . . . . 23 134 7.8. Metric Reporting . . . . . . . . . . . . . . . . . . . . . 24 136 8. A Singleton Definition for LSP Graceful Release Delay . . . . 25 137 8.1. Motivation . . . . . . . . . . . . . . . . . . . . . . . . 25 138 8.2. Metric Name . . . . . . . . . . . . . . . . . . . . . . . 25 139 8.3. Metric Parameters . . . . . . . . . . . . . . . . . . . . 25 140 8.4. Metric Units . . . . . . . . . . . . . . . . . . . . . . . 25 141 8.5. Definition . . . . . . . . . . . . . . . . . . . . . . . . 25 142 8.6. Discussion . . . . . . . . . . . . . . . . . . . . . . . . 26 143 8.7. Methodologies . . . . . . . . . . . . . . . . . . . . . . 27 144 8.8. Metric Reporting . . . . . . . . . . . . . . . . . . . . . 28 146 9. A Definition for Samples of Single Unidirectional LSP 147 Setup Delay . . . . . . . . . . . . . . . . . . . . . . . . . 29 148 9.1. Metric Name . . . . . . . . . . . . . . . . . . . . . . . 29 149 9.2. Metric Parameters . . . . . . . . . . . . . . . . . . . . 29 150 9.3. Metric Units . . . . . . . . . . . . . . . . . . . . . . . 29 151 9.4. Definition . . . . . . . . . . . . . . . . . . . . . . . . 29 152 9.5. Discussion . . . . . . . . . . . . . . . . . . . . . . . . 30 153 9.6. Methodologies . . . . . . . . . . . . . . . . . . . . . . 30 154 9.7. Typical testing cases . . . . . . . . . . . . . . . . . . 31 155 9.7.1. With no LSP in the Network . . . . . . . . . . . . . . 31 156 9.7.2. With a number of LSPs in the Network . . . . . . . . . 31 157 9.8. Metric Reporting . . . . . . . . . . . . . . . . . . . . . 31 159 10. A Definition for Samples of Multiple Unidirectional LSPs 160 Setup Delay . . . . . . . . . . . . . . . . . . . . . . . . . 32 161 10.1. Metric Name . . . . . . . . . . . . . . . . . . . . . . . 32 162 10.2. Metric Parameters . . . . . . . . . . . . . . . . . . . . 32 163 10.3. Metric Units . . . . . . . . . . . . . . . . . . . . . . . 32 164 10.4. Definition . . . . . . . . . . . . . . . . . . . . . . . . 32 165 10.5. Discussion . . . . . . . . . . . . . . . . . . . . . . . . 33 166 10.6. Methodologies . . . . . . . . . . . . . . . . . . . . . . 33 167 10.7. Typical testing cases . . . . . . . . . . . . . . . . . . 34 168 10.7.1. With No LSP in the Network . . . . . . . . . . . . . . 34 169 10.7.2. With a Number of LSPs in the Network . . . . . . . . . 34 170 10.8. Metric Reporting . . . . . . . . . . . . . . . . . . . . . 34 172 11. A Definition for Samples of Single Bidirectional LSP Setup 173 Delay . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35 174 11.1. Metric Name . . . . . . . . . . . . . . . . . . . . . . . 35 175 11.2. Metric Parameters . . . . . . . . . . . . . . . . . . . . 35 176 11.3. Metric Units . . . . . . . . . . . . . . . . . . . . . . . 35 177 11.4. Definition . . . . . . . . . . . . . . . . . . . . . . . . 35 178 11.5. Discussion . . . . . . . . . . . . . . . . . . . . . . . . 36 179 11.6. Methodologies . . . . . . . . . . . . . . . . . . . . . . 36 180 11.7. Typical testing cases . . . . . . . . . . . . . . . . . . 37 181 11.7.1. With No LSP in the Network . . . . . . . . . . . . . . 37 182 11.7.2. With a Number of LSPs in the Network . . . . . . . . . 37 183 11.8. Metric Reporting . . . . . . . . . . . . . . . . . . . . . 37 185 12. A Definition for Samples of Multiple Bidirectional LSPs 186 Setup Delay . . . . . . . . . . . . . . . . . . . . . . . . . 38 187 12.1. Metric Name . . . . . . . . . . . . . . . . . . . . . . . 38 188 12.2. Metric Parameters . . . . . . . . . . . . . . . . . . . . 38 189 12.3. Metric Units . . . . . . . . . . . . . . . . . . . . . . . 38 190 12.4. Definition . . . . . . . . . . . . . . . . . . . . . . . . 38 191 12.5. Discussion . . . . . . . . . . . . . . . . . . . . . . . . 39 192 12.6. Methodologies . . . . . . . . . . . . . . . . . . . . . . 39 193 12.7. Typical testing cases . . . . . . . . . . . . . . . . . . 40 194 12.7.1. With No LSP in the Network . . . . . . . . . . . . . . 40 195 12.7.2. With a Number of LSPs in the Network . . . . . . . . . 40 196 12.8. Metric Reporting . . . . . . . . . . . . . . . . . . . . . 40 198 13. A Definition for Samples of LSP Graceful Release Delay . . . . 41 199 13.1. Metric Name . . . . . . . . . . . . . . . . . . . . . . . 41 200 13.2. Metric Parameters . . . . . . . . . . . . . . . . . . . . 41 201 13.3. Metric Units . . . . . . . . . . . . . . . . . . . . . . . 41 202 13.4. Definition . . . . . . . . . . . . . . . . . . . . . . . . 41 203 13.5. Discussion . . . . . . . . . . . . . . . . . . . . . . . . 41 204 13.6. Methodologies . . . . . . . . . . . . . . . . . . . . . . 42 205 13.7. Metric Reporting . . . . . . . . . . . . . . . . . . . . . 42 207 14. Some Statistics Definitions for Metrics to Report . . . . . . 43 208 14.1. The Minimum of Metric . . . . . . . . . . . . . . . . . . 43 209 14.2. The Median of Metric . . . . . . . . . . . . . . . . . . . 43 210 14.3. The Maximum of Metric . . . . . . . . . . . . . . . . . . 43 211 14.4. The Percentile of Metric . . . . . . . . . . . . . . . . . 43 212 14.5. Failure statistics of Metric . . . . . . . . . . . . . . . 43 213 14.5.1. Failure Count . . . . . . . . . . . . . . . . . . . . 44 214 14.5.2. Failure Ratio . . . . . . . . . . . . . . . . . . . . 44 216 15. Discussion . . . . . . . . . . . . . . . . . . . . . . . . . . 45 218 16. Security Considerations . . . . . . . . . . . . . . . . . . . 46 220 17. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 47 222 18. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 48 224 19. References . . . . . . . . . . . . . . . . . . . . . . . . . . 49 225 19.1. Normative References . . . . . . . . . . . . . . . . . . . 49 226 19.2. Informative References . . . . . . . . . . . . . . . . . . 49 228 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 51 230 1. Introduction 232 Generalized Multi-Protocol Label Switching (GMPLS) is one of the most 233 promising control plane solutions for future transport and service 234 network. GMPLS has been developed to control and operate different 235 kinds of network elements, such as conventional routers, switches, 236 Dense Wavelength Division Multiplexing (DWDM) systems, Add-Drop 237 Multiplexors (ADMs), photonic cross-connects (PXCs), optical cross- 238 connects (OXCs), etc. The dynamic provisioning ability of these 239 physically diverse devices differs from each other drastically. 241 The introduction of a control plane into optical circuit switching 242 networks provides the basis for automating the provisioning of 243 connections and drastically reduces connection provision delay. As 244 more and more services and applications are seeking to use GMPLS 245 controlled networks as their underlying transport network, and 246 increasingly in a dynamic way, the need is growing for measuring and 247 characterizing the performance of LSP provisioning in GMPLS networks, 248 such that requirement from applications and the provisioning 249 capability of the network can be mapped to each other. 251 This draft defines performance metrics and methodologies that can be 252 used to characterize the dynamic LSP provisioning performance of 253 GMPLS networks, more specifically, performance of the signaling 254 protocol. The metrics defined in this document can be used to 255 characterize the average performance of GMPLS implementations. 257 2. Conventions Used in This Document 259 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 260 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 261 document are to be interpreted as described in [RFC2119]. 263 3. Overview of Performance Metrics 265 In this memo, to characterize the dynamic LSP provisioning 266 performance of a GMPLS network, we define 3 performance metrics: 267 unidirectional LSP setup delay, bidirectional LSP setup delay, and 268 LSP graceful release delay. The latency of the LSP setup/release 269 signal is conceptually similar to the Round-trip Delay in IP 270 networks. This enables us to refer to the structures and notions 271 introduced and discussed in the IPPM Framework document, [RFC2330] 272 [RFC2679] [RFC2681]. The reader is assumed to be familiar with the 273 notions in those documents. 275 Note that data path related metrics, for example, the time between 276 the reception of Resv message by ingress node and forward data path 277 becomes operational, are defined in another document 278 [I-D.sun-ccamp-dpm]. It is desirable that both measurements are 279 performed to complement each other. 281 4. A Singleton Definition for Single Unidirectional LSP Setup Delay 283 This part defines a metric for single unidirectional Label Switched 284 Path setup delay across a GMPLS network. 286 4.1. Motivation 288 Single unidirectional Label Switched Path setup delay is useful for 289 several reasons: 291 o Single LSP setup delay is an important metric that characterizes 292 the provisioning performance of a GMPLS network. Longer LSP setup 293 delay will most likely incur higher overhead for the requesting 294 application, especially when the LSP duration itself is comparable 295 to the LSP setup delay. 297 o The minimum value of this metric provides an indication of the 298 delay that will likely be experienced when the LSP traversed the 299 shortest route at the lightest load in the control plane. As the 300 delay itself consists of several components, such as link 301 propagation delay and nodal processing delay, this metric also 302 reflects the status of control plane. For example, for LSPs 303 traversing the same route, longer setup delays may suggest 304 congestion in the control channel or high control element load. 305 For this reason, this metric is useful for testing and diagnostic 306 purposes. 308 o The observed variance in a sample of LSP setup delay metric values 309 variance may serve as an early indicator on the feasibility of 310 support of applications that have stringent setup delay 311 requirements. 313 The measurement of single unidirectional LSP setup delay instead of 314 bidirectional LSP setup delay is motivated by the following factors: 316 o Some applications may use only unidirectional LSPs rather than 317 bidirectional ones. For example, content delivery services with 318 multicasting may use only unidirectional LSPs. 320 4.2. Metric Name 322 Single unidirectional LSP setup delay 324 4.3. Metric Parameters 326 o ID0, the ingress LSR ID 327 o ID1, the egress LSR ID 329 o T, a time when the setup is attempted 331 4.4. Metric Units 333 The value of single unidirectional LSP setup delay is either a real 334 number of milliseconds, or undefined. 336 4.5. Definition 338 The single unidirectional LSP setup delay from ingress node ID0 to 339 egress node ID1 [RFC3945] at T is dT means that ingress node ID0 340 sends the first bit of a Path message packet to egress node ID1 at 341 wire-time T, and that ingress node ID0 received the last bit of 342 responding Resv message packet from egress node ID1 at wire-time 343 T+dT. 345 The single unidirectional LSP setup delay from ingress node ID0 to 346 egress node ID1 at T is undefined means that ingress node ID0 sends 347 the first bit of Path message packet to egress node ID1 at wire-time 348 T and that ingress node ID0 does not receive the corresponding Resv 349 message within a reasonable period of time. 351 The undefined value of this metric indicates an event of Single 352 Unidirectional LSP Setup Failure, and would be used to report a count 353 or a percentage of Single Unidirectional LSP Setup failures. See 354 Section 14.5 for definitions of LSP setup/release failures. 356 4.6. Discussion 358 The following issues are likely to come up in practice: 360 o The accuracy of unidirectional LSP setup delay at time T depends 361 on the clock resolution in the ingress node; but synchronization 362 between the ingress node and egress node is not required since 363 unidirectional LSP setup uses two-way signaling. 365 o A given methodology will have to include a way to determine 366 whether a latency value is infinite or whether it is merely very 367 large. Simple upper bounds MAY be used. But GMPLS networks may 368 accommodate many kinds of devices. For example, some photonic 369 cross-connects (PXCs) have to move micro mirrors. This physical 370 motion may take several milliseconds. But the common electronic 371 switches can finish the nodal processing within several 372 microseconds. So the unidirectional LSP setup delay varies 373 drastically from one network to another. In practice, the upper 374 bound SHOULD be chosen carefully. 376 o If ingress node sends out the Path message to set up an LSP, but 377 never receives the corresponding Resv message, the unidirectional 378 LSP setup delay MUST be set to undefined. 380 o If the ingress node sends out the Path message to set up an LSP 381 but receives a PathErr message, the unidirectional LSP setup delay 382 MUST be set to undefined. There are many possible reasons for 383 this case. For example, the Path message has invalid parameters 384 or the network does not have enough resource to set up the 385 requested LSP, etc. 387 4.7. Methodologies 389 Generally the methodology would proceed as follows: 391 o Make sure that the network has enough resource to set up the 392 requested LSP. 394 o At the ingress node, form the Path message according to the LSP 395 requirements. A timestamp (T1) may be stored locally on the 396 ingress node when the Path message packet is sent towards the 397 egress node. 399 o If the corresponding Resv message arrives within a reasonable 400 period of time, take the timestamp (T2) as soon as possible upon 401 receipt of the message. By subtracting the two timestamps, an 402 estimate of unidirectional LSP setup delay (T2-T1) can be 403 computed. 405 o If the corresponding Resv message fails to arrive within a 406 reasonable period of time, the unidirectional LSP setup delay is 407 deemed to be undefined. Note that the 'reasonable' threshold is a 408 parameter of the methodology. 410 o If the corresponding response is a PathErr message, the 411 unidirectional LSP setup delay is deemed to be undefined. 413 4.8. Metric Reporting 415 The metric result (either a real number or undefined) MUST be 416 reported together with the selected upper bound. The route that the 417 LSP traverses MUST also be reported. The route MAY be collected via 418 use of the record route object, see [RFC3209], or via the management 419 plane. The collection of routes via the management plane is out of 420 scope of this document. 422 5. A Singleton Definition for Multiple Unidirectional LSP Setup Delay 424 This part defines a metric for multiple unidirectional Label Switched 425 Paths setup delay across a GMPLS network. 427 5.1. Motivation 429 Multiple unidirectional Label Switched Paths setup delay is useful 430 for several reasons: 432 o Carriers may require a large number of LSPs be set up during a 433 short time period. This request may arise e.g. as a consequence 434 to interruptions on established LSPs or other network failures. 436 o The time needed to set up a large number of LSPs during a short 437 time period can not be deduced from single LSP setup delay. 439 5.2. Metric Name 441 Multiple unidirectional LSPs setup delay 443 5.3. Metric Parameters 445 o ID0, the ingress LSR ID 447 o ID1, the egress LSR ID 449 o Lambda_m, a rate in reciprocal milliseconds 451 o X, the number of LSPs to set up 453 o T, a time when the first setup is attempted 455 5.4. Metric Units 457 The value of multiple unidirectional LSPs setup delay is either a 458 real number of milliseconds, or undefined. 460 5.5. Definition 462 Given Lambda_m and X, the multiple unidirectional LSPs setup delay 463 from the ingress node to the egress node [RFC3945] at T is dT means: 465 o ingress node ID0 sends the first bit of the first Path message 466 packet to egress node ID1 at wire-time T 468 o all subsequent (X-1) Path messages are sent according to the 469 specified Poisson process with arrival rate Lambda_m 471 o ingress node ID0 receives all corresponding Resv message packets 472 from egress node ID1, and 474 o ingress node ID0 receives the last Resv message packet at wire- 475 time T+dT 477 The multiple unidirectional LSPs setup delay at T is undefined means 478 that ingress node ID0 sends all the Path messages toward egress node 479 ID1 and the first bit of the first Path message packet is sent at 480 wire-time T and that ingress node ID0 does not receive one or more of 481 the corresponding Resv messages within a reasonable period of time. 483 The undefined value of this metric indicates an event of Multiple 484 Unidirectional LSP Setup Failure, and would be used to report a count 485 or a percentage of Multiple Unidirectional LSP Setup failures. See 486 Section 14.5 for definitions of LSP setup/release failures. 488 5.6. Discussion 490 The following issues are likely to come up in practice: 492 o The accuracy of multiple unidirectional LSPs setup delay at time T 493 depends on the clock resolution in the ingress node; but 494 synchronization between the ingress node and egress node is not 495 required since unidirectional LSP setup uses two-way signaling. 497 o A given methodology will have to include a way to determine 498 whether a latency value is infinite or whether it is merely very 499 large. Simple upper bounds MAY be used. But GMPLS networks may 500 accommodate many kinds of devices. For example, some photonic 501 cross-connects (PXCs) have to move micro mirrors. This physical 502 motion may take several milliseconds. But electronic switches can 503 finish the nodal processing within several microseconds. So the 504 multiple unidirectional LSP setup delay varies drastically from 505 one network to another. In practice, the upper bound SHOULD be 506 chosen carefully. 508 o If ingress node sends out the multiple Path messages to set up the 509 LSPs, but never receives one or more of the corresponding Resv 510 messages, multiple unidirectional LSP setup delay MUST be set to 511 undefined. 513 o If ingress node sends out the Path messages to set up the LSPs but 514 receives one or more PathErr messages, multiple unidirectional 515 LSPs setup delay MUST be set to undefined. There are many 516 possible reasons for this case. For example, one of the Path 517 messages has invalid parameters or the network has not enough 518 resource to set up the requested LSPs, etc. 520 o The arrival rate of the Poisson process Lambda_m SHOULD be chosen 521 carefully such that in the one hand the control plane is not 522 overburdened. On the other hand, the arrival rate is large enough 523 to meet the requirements of applications or services. 525 o It is important that all the LSPs MUST traverse the same route. 526 If there are multiple routes between the Ingress node ID0 and 527 Egress node ID1, EROs or an alternate method, e.g., static 528 configuration, MUST be used to ensure that all LSPs traverse the 529 same route. 531 5.7. Methodologies 533 Generally the methodology would proceed as follows: 535 o Make sure that the network has enough resource to set up the 536 requested LSPs. 538 o At the ingress node, form the Path messages according to the LSPs' 539 requirements. 541 o At the ingress node, select the time for each of the Path messages 542 according to the specified Poisson process. 544 o At the ingress node, send out the Path messages according to the 545 selected time. 547 o Store a timestamp (T1) locally on the ingress node when the first 548 Path message packet is sent towards the egress node. 550 o If all of the corresponding Resv messages arrive within a 551 reasonable period of time, take the final timestamp (T2) as soon 552 as possible upon the receipt of all the messages. By subtracting 553 the two timestamps, an estimate of multiple unidirectional LSPs 554 setup delay (T2-T1) can be computed. 556 o If one or more of the corresponding Resv messages fail to arrive 557 within a reasonable period of time, the multiple unidirectional 558 LSPs setup delay is deemed to be undefined. Note that the 559 'reasonable' threshold is a parameter of the methodology. 561 o If one or more of the corresponding response are PathErr messages, 562 the multiple unidirectional LSPs setup delay is deemed to be 563 undefined. 565 5.8. Metric Reporting 567 The metric result (either a real number or undefined) MUST be 568 reported together with the selected upper bound. The route that the 569 LSPs traverse MUST also be reported. The route MAY be collected via 570 use of the record route object, see [RFC3209], or via the management 571 plane. The collection of routes via the management plane is out of 572 scope of this document. 574 6. A Singleton Definition for Single Bidirectional LSP Setup Delay 576 GMPLS allows establishment of bidirectional symmetric LSPs (not of 577 asymmetric LSPs). This part defines a metric for single 578 bidirectional LSP setup delay across a GMPLS network. 580 6.1. Motivation 582 Single bidirectional Label Switched Path setup delay is useful for 583 several reasons: 585 o LSP setup delay is an important metric that characterizes the 586 provisioning performance of a GMPLS network. Longer LSP setup 587 delay will incur higher overhead for the requesting application, 588 especially when the LSP duration is comparable to the LSP setup 589 delay. Thus, measuring the setup delay is important for 590 application scheduling. 592 o The minimum value of this metric provides an indication of the 593 delay that will likely be experienced when the LSP traversed the 594 shortest route at the lightest load in the control plane. As the 595 delay itself consists of several components, such as link 596 propagation delay and nodal processing delay, this metric also 597 reflects the status of control plane. For example, for LSPs 598 traversing the same route, longer setup delays may suggest 599 congestion in the control channel or high control element load. 600 For this reason, this metric is useful for testing and diagnostic 601 purposes. 603 o LSP setup delay variance has different impact on applications. 604 Erratic variation in LSP setup delay makes it difficult to support 605 applications that have stringent setup delay requirement. 607 The measurement of single bidirectional LSP setup delay instead of 608 unidirectional LSP setup delay is motivated by the following factors: 610 o Bidirectional LSPs are seen as a requirement for many GMPLS 611 networks. Its provisioning performance is important to 612 applications that generate bidirectional traffic. 614 6.2. Metric Name 616 Single bidirectional LSP setup delay 618 6.3. Metric Parameters 619 o ID0, the ingress LSR ID 621 o ID1, the egress LSR ID 623 o T, a time when the setup is attempted 625 6.4. Metric Units 627 The value of single bidirectional LSP setup delay is either a real 628 number of milliseconds, or undefined. 630 6.5. Definition 632 For a real number dT, the single bidirectional LSP setup delay from 633 ingress node ID0 to egress node ID1 at T is dT, means that ingress 634 node ID0 sends out the first bit of a Path message including an 635 Upstream Label [RFC3473] heading for egress node ID1 at wire-time T, 636 egress node ID1 receives that packet, then immediately sends a Resv 637 message packet back to ingress node ID0, and that ingress node ID0 638 receives the last bit of the Resv message packet at wire-time T+dT. 640 The single bidirectional LSP setup delay from ingress node ID0 to 641 egress node ID1 at T is undefined means that ingress node ID0 sends 642 the first bit of Path message to egress node ID1 at wire-time T and 643 that ingress node ID0 does not receive that response packet within a 644 reasonable period of time. 646 The undefined value of this metric indicates an event of Single 647 Bidirectional LSP Setup Failure, and would be used to report a count 648 or a percentage of Single Bidirectional LSP Setup failures. See 649 Section 14.5 for definitions of LSP setup/release failures. 651 6.6. Discussion 653 The following issues are likely to come up in practice: 655 o The accuracy of single bidirectional LSP setup delay depends on 656 the clock resolution in the ingress node; but synchronization 657 between the ingress node and egress node is not required since 658 single bidirectional LSP setup uses two-way signaling. 660 o A given methodology will have to include a way to determine 661 whether a latency value is infinite or whether it is merely very 662 large. Simple upper bounds MAY be used. But GMPLS networks may 663 accommodate many kinds of devices. For example, some photonic 664 cross-connects (PXCs) have to move micro mirrors. This physical 665 motion may take several milliseconds. But electronic switches can 666 finish the nodal processing within several microseconds. So the 667 bidirectional LSP setup delay varies drastically from one network 668 to another. In the process of bidirectional LSP setup, if the 669 downstream node overrides the label suggested by the upstream 670 node, the setup delay may also increase. Thus, in practice, the 671 upper bound SHOULD be chosen carefully. 673 o If the ingress node sends out the Path message to set up the LSP, 674 but never receives the corresponding Resv message, single 675 bidirectional LSP setup delay MUST be set to undefined. 677 o If the ingress node sends out the Path message to set up the LSP, 678 but receives a PathErr message, single bidirectional LSP setup 679 delay MUST be set to undefined. There are many possible reasons 680 for this case. For example, the Path message has invalid 681 parameters or the network has not enough resource to set up the 682 requested LSP. 684 6.7. Methodologies 686 Generally the methodology would proceed as follows: 688 o Make sure that the network has enough resource to set up the 689 requested LSP. 691 o At the ingress node, form the Path message (including the Upstream 692 Label or suggested label) according to the LSP requirements. A 693 timestamp (T1) may be stored locally on the ingress node when the 694 Path message packet is sent towards the egress node. 696 o If the corresponding Resv message arrives within a reasonable 697 period of time, take the final timestamp (T2) as soon as possible 698 upon the receipt of the message. By subtracting the two 699 timestamps, an estimate of bidirectional LSP setup delay (T2-T1) 700 can be computed. 702 o If the corresponding Resv message fails to arrive within a 703 reasonable period of time, the single bidirectional LSP setup 704 delay is deemed to be undefined. Note that the 'reasonable' 705 threshold is a parameter of the methodology. 707 o If the corresponding response is a PathErr message, the single 708 bidirectional LSP setup delay is deemed to be undefined. 710 6.8. Metric Reporting 712 The metric result (either a real number or undefined) MUST be 713 reported together with the selected upper bound. The route that the 714 LSP traverses MUST also be reported. The route MAY be collected via 715 use of the record route object, see [RFC3209], or via the management 716 plane. The collection of routes via the management plane is out of 717 scope of this document. 719 7. A Singleton Definition for Multiple Bidirectional LSPs Setup Delay 721 This part defines a metric for multiple bidirectional LSPs setup 722 delay across a GMPLS network. 724 7.1. Motivation 726 Multiple bidirectional LSPs setup delay is useful for several 727 reasons: 729 o Upon traffic interruption caused by network failure or network 730 upgrade, carriers may require a large number of LSPs be set up 731 during a short time period 733 o The time needed to set up a large number of LSPs during a short 734 time period can not be deduced by single LSP setup delay 736 7.2. Metric Name 738 Multiple bidirectional LSPs setup delay 740 7.3. Metric Parameters 742 o ID0, the ingress LSR ID 744 o ID1, the egress LSR ID 746 o Lambda_m, a rate in reciprocal milliseconds 748 o X, the number of LSPs to set up 750 o T, a time when the first setup is attempted 752 7.4. Metric Units 754 The value of multiple bidirectional LSPs setup delay is either a real 755 number of milliseconds, or undefined. 757 7.5. Definition 759 Given Lambda_m and X, for a real number dT, the multiple 760 bidirectional LSPs setup delay from ingress node to egress node at T 761 is dT, means that: 763 o Ingress node ID0 sends the first bit of the first Path message 764 heading for egress node ID1 at wire-time T 766 o All subsequent (X-1) Path messages are sent according to the 767 specified Poisson process with arrival rate Lambda_m 769 o Ingress node ID1 receives all corresponding Resv message packets 770 from egress node ID1, and 772 o Ingress node ID0 receives the last Resv message packet at wire- 773 time T+dT 775 The multiple bidirectional LSPs setup delay from ingress node to 776 egress node at T is undefined means that ingress node sends all the 777 Path messages to egress node and that the ingress node fails to 778 receive one or more of the response Resv messages within a reasonable 779 period of time. 781 The undefined value of this metric indicates an event of Multiple 782 Bidirectional LSP Setup Failure, and would be used to report a count 783 or a percentage of Multiple Bidirectional LSP Setup failures. See 784 Section 14.5 for definitions of LSP setup/release failures. 786 7.6. Discussion 788 The following issues are likely to come up in practice: 790 o The accuracy of multiple Bidirectional LSPs setup delay depends on 791 the clock resolution in the ingress node; but synchronization 792 between the ingress node and egress node is not required since 793 bidirectional LSP setup uses two-way signaling. 795 o A given methodology will have to include a way to determine 796 whether a latency value is infinite or whether it is merely very 797 large. Simple upper bounds MAY be used. But GMPLS networks may 798 accommodate many kinds of devices. For example, some photonic 799 cross-connects (PXCs) have to move micro mirrors. This physical 800 motion may take several milliseconds. But electronic switches can 801 finish the nodal process within several microseconds. So the 802 multiple bidirectional LSPs setup delay varies drastically from a 803 network to another. In the process of multiple bidirectional LSPs 804 setup, if the downstream node overrides the label suggested by the 805 upstream node, the setup delay may also increase. Thus, in 806 practice, the upper bound SHOULD be chosen carefully. 808 o If the ingress node sends out the Path messages to set up the 809 LSPs, but never receives all the corresponding Resv messages, the 810 multiple bidirectional LSPs setup delay MUST be set to undefined. 812 o If the ingress node sends out the Path messages to set up the 813 LSPs, but receives one or more responding PathErr messages, the 814 multiple bidirectional LSPs setup delay MUST be set to undefined. 815 There are many possible reasons for this case. For example, one 816 or more of the Path messages have invalid parameters or the 817 network has not enough resource to set up the requested LSPs. 819 o The arrival rate of the Poisson process Lambda_m SHOULD be 820 carefully chosen such that on the one hand the control plane is 821 not overburdened. On the other hand, the arrival rate is large 822 enough to meet the requirements of applications or services. 824 o It is important that all the LSPs MUST traverse the same route. 825 If there are multiple routes between the Ingress node ID0 and 826 Egress node ID1, EROs or an alternate method, e.g., static 827 configuration, MUST be used to ensure that all LSPs traverse the 828 same route. 830 7.7. Methodologies 832 Generally the methodology would proceed as follows: 834 o Make sure that the network has enough resource to set up the 835 requested LSPs. 837 o At the ingress node, form the Path messages (including the 838 Upstream Label or suggested label) according to the LSPs' 839 requirements. 841 o At the ingress node, select the time for each of the Path messages 842 according to the specified Poisson process. 844 o At the ingress node, send out the Path messages according to the 845 selected time. 847 o Store a timestamp (T1) locally in the ingress node when the first 848 Path message packet is sent towards the egress node. 850 o If all of the corresponding Resv messages arrive within a 851 reasonable period of time, take the final timestamp (T2) as soon 852 as possible upon the receipt of all the messages. By subtracting 853 the two timestamps, an estimate of multiple bidirectional LSPs 854 setup delay (T2-T1) can be computed. 856 o If one or more of the corresponding Resv messages fail to arrive 857 within a reasonable period of time, the multiple bidirectional 858 LSPs setup delay is deemed to be undefined. Note that the 859 'reasonable' threshold is a parameter of the methodology. 861 o If one or more of the corresponding response are PathErr messages, 862 the multiple bidirectional LSPs setup delay is deemed to be 863 undefined. 865 7.8. Metric Reporting 867 The metric result (either a real number or undefined) MUST be 868 reported together with the selected upper bound. The route that the 869 LSPs traverse MUST also be reported. The route MAY be collected via 870 use of the record route object, see [RFC3209], or via the management 871 plane. The collection of routes via the management plane is out of 872 scope of this document. 874 8. A Singleton Definition for LSP Graceful Release Delay 876 There are two different kinds of LSP release mechanisms in GMPLS 877 networks: graceful release and forceful release. This document does 878 not take forceful LSP release procedure into account. 880 8.1. Motivation 882 LSP graceful release delay is useful for several reasons: 884 o The LSP graceful release delay is part of the total cost of 885 dynamic LSP provisioning. For some short duration applications, 886 the LSP release time can not be ignored 888 o The LSP graceful release procedure is more preferred in a GMPLS 889 controlled network, particularly the optical networks. Since it 890 doesn't trigger restoration/protection, it is "alarm-free 891 connection deletion" in [RFC4208]. 893 8.2. Metric Name 895 LSP graceful release delay 897 8.3. Metric Parameters 899 o ID0, the ingress LSR ID 901 o ID1, the egress LSR ID 903 o T, a time when the release is attempted 905 8.4. Metric Units 907 The value of LSP graceful release delay is either a real number of 908 milliseconds, or undefined. 910 8.5. Definition 912 There are two different LSP graceful release procedures, one is 913 initiated by the ingress node, and another is initiated by the egress 914 node. The two procedures are depicted in [RFC3473]. We define the 915 graceful LSP release delay for these two procedures separately. 917 For a real number dT, the LSP graceful release delay from ingress 918 node ID0 to egress node ID1 at T is dT, means that ingress node ID0 919 sends the first bit of a Path message including Admin Status Object 920 with the Reflect (R) and Delete (D) bits set to the egress node at 921 wire-time T, that egress node ID1 receives that packet, then 922 immediately sends a Resv message including Admin Status Object with 923 the Delete (D) bit set back to the ingress node. Ingress node ID0 924 sends out PathTear downstream to remove the LSP, and egress node ID1 925 receives the last bit of PathTear packet at wire-time T+dT. 927 Also as an option, upon receipt of the Path message including Admin 928 Status Object with the Reflect (R) and Delete (D) bits set, egress 929 node ID1 may respond with a PathErr message with the 930 Path_State_Removed flag set. 932 The LSP graceful release delay from ingress node ID0 to egress node 933 ID1 at T is undefined means that ingress node ID0 sends the first bit 934 of Path message to egress node ID1 at wire-time T and that (either 935 egress node does not receive the Path packet, egress node does not 936 send corresponding Resv message packet in response, or ingress node 937 does not receive that Resv packet, and) egress node ID1 does not 938 receive the PathTear within a reasonable period of time. 940 The LSP graceful release delay from egress node ID1 to ingress node 941 ID0 at T is dT means that egress node ID1 sends the first bit of a 942 Resv message including Admin Status Object with setting the Reflect 943 (R) and Delete (D) bits to ingress node at wire-time T. Ingress node 944 ID0 sends out PathTear downstream to remove the LSP, and egress node 945 ID1 receives the last bit of PathTear packet at wire-time T+dT. 947 The LSP graceful release delay from egress node ID1 to ingress node 948 ID0 at T is undefined means that egress node ID1 sends the first bit 949 of Resv message including Admin Status Object with setting the 950 Reflect (R) and Delete (D) bits to ingress node ID0 at wire-time T 951 and that (either ingress node does not receive the Resv packet, or 952 ingress node does not send PathTear message packet in response, and) 953 egress node ID1 does not receive the PathTear within a reasonable 954 period of time. 956 The undefined value of this metric indicates an event of LSP Graceful 957 Release Failure, and would be used to report a count or a percentage 958 of LSP Graceful Release failures. See Section 14.5 for definitions 959 of LSP setup/release failures. 961 8.6. Discussion 963 The following issues are likely to come up in practice: 965 o In the first (second) circumstance, the accuracy of LSP graceful 966 release delay at time T depends on the clock resolution in the 967 ingress (egress) node. In the first circumstance, synchronization 968 between the ingress node and egress node is required; but not in 969 the second circumstance; 971 o A given methodology has to include a way to determine whether a 972 latency value is infinite or whether it is merely very large. 973 Simple upper bounds MAY be used. But the upper bound SHOULD be 974 chosen carefully in practice; 976 o In the first circumstance, if the ingress node sends out Path 977 message including Admin Status Object with the Reflect (R) and 978 Delete (D) bits set to initiate LSP graceful release, but the 979 egress node never receives the corresponding PathTear message, LSP 980 graceful release delay MUST be set to undefined. 982 o In the second circumstance, if the egress node sends out the Resv 983 message including Admin Status Object with the Reflect (R) and 984 Delete (D) bits set to initiate LSP graceful release, but never 985 receives the corresponding PathTear message, LSP graceful release 986 delay MUST be set to undefined. 988 8.7. Methodologies 990 In the first circumstance, the methodology may proceed as follows: 992 o Make sure the LSP to be deleted is set up; 994 o At the ingress node, form the Path message including Admin Status 995 Object with the Reflect (R) and Delete (D) bits set. A timestamp 996 (T1) may be stored locally on the ingress node when the Path 997 message packet is sent towards the egress node; 999 o Upon receiving the Path message including Admin Status Object with 1000 the Reflect (R) and Delete (D) bits set, the egress node sends a 1001 Resv message including Admin Status Object with the Delete (D) and 1002 Reflect (R) bits set. Alternatively, the egress node sends a 1003 PathErr message with the Path_State_Removed flag set upstream; 1005 o When the ingress node receive the Resv message or the PathErr 1006 message, it sends a PathTear message to remove the LSP; 1008 o The egress node takes a timestamp (T2) once it receives the last 1009 bit of the PathTear message. The LSP graceful release delay is 1010 then (T2-T1). 1012 o If the ingress node sends the Path message downstream, but the 1013 egress node fails to receive the PathTear message within a 1014 reasonable period of time, the LSP graceful release delay is 1015 deemed to be undefined. Note that the 'reasonable' threshold is a 1016 parameter of the methodology. 1018 In the second circumstance, the methodology would proceed as follows: 1020 o Make sure the LSP to be deleted is set up; 1022 o On the egress node, form the Resv message including Admin Status 1023 Object with the Reflect (R) and Delete (D) bits set. A timestamp 1024 may be stored locally on the egress node when the Resv message 1025 packet is sent towards the ingress node; 1027 o Upon receiving the Admin Status Object with the Reflect (R) and 1028 Delete (D) bits set in the Resv message, the ingress node sends a 1029 PathTear message downstream to remove the LSP; 1031 o Egress node takes a timestamp (T2) once it receives the last bit 1032 of the PathTear message. The LSP graceful release delay is then 1033 (T2-T1). 1035 o If the egress node sends the Resv message upstream, but it fails 1036 to receive the PathTear message within a reasonable period of 1037 time, the LSP graceful release delay is deemed to be undefined. 1038 Note that the 'reasonable' threshold is a parameter of the 1039 methodology. 1041 8.8. Metric Reporting 1043 The metric result (either a real number or undefined) MUST be 1044 reported together with the selected upper bound and the procedure 1045 used (e.g., either from the ingress node to the egress node, or from 1046 the egress node to the ingress node. See Section 8.5 for more 1047 details). The route that the LSP traverses MUST also be reported. 1048 The route MAY be collected via use of the record route object, see 1049 [RFC3209], or via the management plane. The collection of routes via 1050 the management plane is out of scope of this document. 1052 9. A Definition for Samples of Single Unidirectional LSP Setup Delay 1054 In Section 4, we have defined the singleton metric of Single 1055 unidirectional LSP setup delay. Now we define how to get one 1056 particular sample of Single unidirectional LSP setup delay. Sampling 1057 means to take a number of distinct instances of a skeleton metric 1058 under a given set of parameters. Like in [RFC2330], we use Poisson 1059 sampling as an example. 1061 9.1. Metric Name 1063 Single unidirectional LSP setup delay sample 1065 9.2. Metric Parameters 1067 o ID0, the ingress LSR ID 1069 o ID1, the egress LSR ID 1071 o T0, a time 1073 o Tf, a time 1075 o Lambda, a rate in the reciprocal milliseconds 1077 o Th, LSP holding time 1079 o Td, the maximum waiting time for successful setup 1081 9.3. Metric Units 1083 A sequence of pairs; the elements of each pair are: 1085 o T, a time when setup is attempted 1087 o dT, either a real number of milliseconds, or undefined. 1089 9.4. Definition 1091 Given T0, Tf, and Lambda, compute a pseudo-random Poisson process 1092 beginning at or before T0, with average arrival rate Lambda, and 1093 ending at or after Tf. Those time values greater than or equal to T0 1094 and less than or equal to Tf are then selected. At each of the times 1095 in this process, we obtain the value of unidirectional LSP setup 1096 delay sample at this time. The value of the sample is the sequence 1097 made up of the resulting pairs. If there are 1098 no such pairs, the sequence is of length zero and the sample is said 1099 to be empty. 1101 9.5. Discussion 1103 The parameter Lambda should be carefully chosen. If the rate is too 1104 high, too frequent LSP setup/release procedure will result in high 1105 overhead in the control plane. In turn, the high overhead will 1106 increase unidirectional LSP setup delay. On the other hand if the 1107 rate is too low, the sample could not completely reflect the dynamic 1108 provisioning performance of the GMPLS network. The appropriate 1109 Lambda value depends on the given network. 1111 The parameters Td should be carefully chosen. Different switching 1112 technologies may vary significantly in performing a cross-connect 1113 operation. At the same time, the time needed in setting up an LSP 1114 under different traffic may also vary significantly. 1116 In the case of active measurement, the parameters Th should be 1117 carefully chosen. The combination of Lambda and Th reflects the load 1118 of the network. The selection of Th should take into account that 1119 the network has sufficient resource to perform subsequent tests. The 1120 value of Th MAY be constant during one sampling process for 1121 simplicity considerations. 1123 Note that for online or passive measurements, the arrival rate and 1124 LSP holding time are determined by actual traffic, hence in this case 1125 Lambda and Th are not input parameters. 1127 It is important that in obtaining a sample all the LSPs MUST traverse 1128 the same route. If there are multiple routes between the Ingress 1129 node ID0 and Egress node ID1, EROs or an alternate method, e.g., 1130 static configuration, MUST be used to ensure that all LSPs traverse 1131 the same route. 1133 9.6. Methodologies 1135 o Select the times using the specified Poisson arrival process, and 1137 o Set up the LSP as the methodology for the singleton unidirectional 1138 LSP setup delay, and obtain the value of unidirectional LSP setup 1139 delay 1141 o Release the LSP after Th, and wait for the next Poisson arrival 1142 event 1144 Note that: it is possible that before the previous LSP release 1145 procedure completes, the next Poisson arrival event arrives and the 1146 LSP setup procedure is initiated. If there is resource contention 1147 between the two LSPs, the LSP setup may fail. Ways to avoid such 1148 contention are outside the scope of this document. 1150 9.7. Typical testing cases 1152 9.7.1. With no LSP in the Network 1154 9.7.1.1. Motivation 1156 Single unidirectional LSP setup delay with no LSP in the network is 1157 important because this reflects the inherent delay of an RSVP-TE 1158 implementation. The minimum value provides an indication of the 1159 delay that will likely be experienced when an LSP traverses the 1160 shortest route with the lightest load in the control plane. 1162 9.7.1.2. Methodologies 1164 Make sure that there is no LSP in the network, and proceed with the 1165 methodologies described in Section 9.6 1167 9.7.2. With a number of LSPs in the Network 1169 9.7.2.1. Motivation 1171 Single unidirectional LSP setup delay with a number of LSPs in the 1172 network is important because it reflects the performance of an 1173 operational network with considerable load. This delay may vary 1174 significantly as the number of existing LSPs vary. It can be used as 1175 a scalability metric of an RSVP-TE implementation. 1177 9.7.2.2. Methodologies 1179 Setup the required number of LSPs, and wait until the network reaches 1180 a stable state, then proceed with the methodologies described in 1181 Section 9.6. 1183 9.8. Metric Reporting 1185 The metric results including both real and undefined values MUST be 1186 reported together with the total number of values. The context under 1187 which the sample is obtained, including the selected parameters, the 1188 route traversed by the LSPs, and the testing case used, MUST also be 1189 reported. 1191 10. A Definition for Samples of Multiple Unidirectional LSPs Setup 1192 Delay 1194 In Section 5, we have defined the singleton metric of multiple 1195 unidirectional LSPs setup delay. Now we define how to get one 1196 particular sample of multiple unidirectional LSP setup delay. 1197 Sampling means to take a number of distinct instances of a skeleton 1198 metric under a given set of parameters. Like in [RFC2330], we use 1199 Poisson sampling as an example. 1201 10.1. Metric Name 1203 Multiple unidirectional LSPs setup delay sample 1205 10.2. Metric Parameters 1207 o ID0, the ingress LSR ID 1209 o ID1, the egress LSR ID 1211 o T0, a time 1213 o Tf, a time 1215 o Lambda_m, a rate in the reciprocal milliseconds 1217 o Lambda, a rate in the reciprocal milliseconds 1219 o X, the number of LSPs to set up 1221 o Th, LSP holding time 1223 o Td, the maximum waiting time for successful multiple 1224 unidirectional LSPs setup 1226 10.3. Metric Units 1228 A sequence of pairs; the elements of each pair are: 1230 o T, a time when the first setup is attempted 1232 o dT, either a real number of milliseconds, or undefined. 1234 10.4. Definition 1236 Given T0, Tf, and Lambda, compute a pseudo-random Poisson process 1237 beginning at or before T0, with average arrival rate Lambda, and 1238 ending at or after Tf. Those time values greater than or equal to T0 1239 and less than or equal to Tf are then selected. At each of the time 1240 in this process, we obtain the value of multiple unidirectional LSP 1241 setup delay sample at this time. The value of the sample is the 1242 sequence made up of the resulting pairs. If 1243 there are no such pairs, the sequence is of length zero and the 1244 sample is said to be empty. 1246 10.5. Discussion 1248 The parameter Lambda is used as arrival rate of "batch unidirectional 1249 LSPs setup" operation. It regulates the interval in between each 1250 batch operation. The parameter Lambda_m is used within each batch 1251 operation, as described in Section 5 1253 The parameters Lambda and Lambda_m should be carefully chosen. If 1254 the rate is too high, too frequent LSP setup/release procedure will 1255 result in high overhead in the control plane. In turn, the high 1256 overhead will increase unidirectional LSP setup delay. On the other 1257 hand if the rate is too low, the sample could not completely reflect 1258 the dynamic provisioning performance of the GMPLS network. The 1259 appropriate Lambda and Lambda_m value depends on the given network. 1261 The parameters Td should be carefully chosen. Different switching 1262 technologies may vary significantly in performing a cross-connect 1263 operation. At the same time, the time needed in setting up an LSP 1264 under different traffic may also vary significantly. 1266 It is important that in obtaining a sample all the LSPs MUST traverse 1267 the same route. If there are multiple routes between the Ingress 1268 node ID0 and Egress node ID1, EROs or an alternate method, e.g., 1269 static configuration, MUST be used to ensure that all LSPs traverse 1270 the same route. 1272 10.6. Methodologies 1274 o Select the times using the specified Poisson arrival process, and 1276 o Set up the LSP as the methodology for the singleton multiple 1277 unidirectional LSPs setup delay, and obtain the value of multiple 1278 unidirectional LSPs setup delay 1280 o Release the LSP after Th, and wait for the next Poisson arrival 1281 event 1283 Note that: it is possible that before the previous LSP release 1284 procedure completes, the next Poisson arrival event arrives and the 1285 LSP setup procedure is initiated. If there is resource contention 1286 between the two LSPs, the LSP setup may fail. Ways to avoid such 1287 contention are outside the scope of this document. 1289 10.7. Typical testing cases 1291 10.7.1. With No LSP in the Network 1293 10.7.1.1. Motivation 1295 Multiple unidirectional LSP setup delay with no LSP in the network is 1296 important because this reflects the inherent delay of an RSVP-TE 1297 implementation. The minimum value provides an indication of the 1298 delay that will likely be experienced when LSPs traverse the shortest 1299 route with the lightest load in the control plane. 1301 10.7.1.2. Methodologies 1303 Make sure that there is no LSP in the network, and proceed with the 1304 methodologies described in Section 10.6. 1306 10.7.2. With a Number of LSPs in the Network 1308 10.7.2.1. Motivation 1310 Multiple unidirectional LSPs setup delay with a number of LSPs in the 1311 network is important because it reflects the performance of an 1312 operational network with considerable load. This delay can vary 1313 significantly as the number of existing LSPs vary. It can be used as 1314 a scalability metric of an RSVP-TE implementation. 1316 10.7.2.2. Methodologies 1318 Setup the required number of LSPs, and wait until the network reaches 1319 a stable state, then proceed with the methodologies described in 1320 Section 10.6. 1322 10.8. Metric Reporting 1324 The metric results including both real and undefined values MUST be 1325 reported together with the total number of values. The context under 1326 which the sample is obtained, including the selected parameters, the 1327 route traversed by the LSPs, and the testing case used, MUST also be 1328 reported. 1330 11. A Definition for Samples of Single Bidirectional LSP Setup Delay 1332 In Section 6, we have defined the singleton metric of Single 1333 Bidirectional LSP setup delay. Now we define how to get one 1334 particular sample of Single Bidirectional LSP setup delay. Sampling 1335 means to take a number of distinct instances of a skeleton metric 1336 under a given set of parameters. Like in [RFC2330], we use Poisson 1337 sampling as an example. 1339 11.1. Metric Name 1341 Single Bidirectional LSP setup delay sample with no LSP in the 1342 network 1344 11.2. Metric Parameters 1346 o ID0, the ingress LSR ID 1348 o ID1, the egress LSR ID 1350 o T0, a time 1352 o Tf, a time 1354 o Lambda, a rate in the reciprocal milliseconds 1356 o Th, LSP holding time 1358 o Td, the maximum waiting time for successful setup 1360 11.3. Metric Units 1362 A sequence of pairs; the elements of each pair are: 1364 o T, a time when setup is attempted 1366 o dT, either a real number of milliseconds, or undefined. 1368 11.4. Definition 1370 Given T0, Tf, and Lambda, compute a pseudo-random Poisson process 1371 beginning at or before T0, with average arrival rate Lambda, and 1372 ending at or after Tf. Those time values greater than or equal to T0 1373 and less than or equal to Tf are then selected. At each of the times 1374 in this process, we obtain the value of bidirectional LSP setup delay 1375 sample at this time. The value of the sample is the sequence made up 1376 of the resulting pairs. If there are no such 1377 pairs, the sequence is of length zero and the sample is said to be 1378 empty. 1380 11.5. Discussion 1382 The parameters Lambda should be carefully chosen. If the rate is too 1383 high, too frequent LSP setup/release procedure will result in high 1384 overhead in the control plane. In turn, the high overhead will 1385 increase bidirectional LSP setup delay. On the other hand if the 1386 rate is too low, the sample could not completely reflect the dynamic 1387 provisioning performance of the GMPLS network. The appropriate 1388 Lambda value depends on the given network. 1390 The parameters Td should be carefully chosen. Different switching 1391 technologies may vary significantly in performing a cross-connect 1392 operation. At the same time, the time needed in setting up an LSP 1393 under different traffic may also vary significantly. 1395 In the case of active measurement, the parameters Th should be 1396 carefully chosen. The combination of Lambda and Th reflects the load 1397 of the network. The selection of Th SHOULD take into account that 1398 the network has sufficient resource to perform subsequent tests. The 1399 value of Th MAY be constant during one sampling process for 1400 simplicity considerations. 1402 Note that for online or passive measurements, the arrival rate and 1403 the LSP holding time are determined by actual traffic, hence in this 1404 case Lambda and Th are not input parameters. 1406 It is important that in obtaining a sample all the LSPs MUST traverse 1407 the same route. If there are multiple routes between the Ingress 1408 node ID0 and Egress node ID1, EROs or an alternate method, e.g., 1409 static configuration, MUST be used to ensure that all LSPs traverse 1410 the same route. 1412 11.6. Methodologies 1414 o Select the times using the specified Poisson arrival process, and 1416 o Set up the LSP as the methodology for the singleton bidirectional 1417 LSP setup delay, and obtain the value of bidirectional LSP setup 1418 delay 1420 o Release the LSP after Th, and wait for the next Poisson arrival 1421 event 1423 Note that: it is possible that before the previous LSP release 1424 procedure completes, the next Poisson arrival event arrives and the 1425 LSP setup procedure is initiated. If there is resource contention 1426 between the two LSPs, the LSP setup may fail. Ways to avoid such 1427 contention are outside the scope of this document. 1429 11.7. Typical testing cases 1431 11.7.1. With No LSP in the Network 1433 11.7.1.1. Motivation 1435 Single bidirectional LSP setup delay with no LSP in the network is 1436 important because this reflects the inherent delay of an RSVP-TE 1437 implementation. The minimum value provides an indication of the 1438 delay that will likely be experienced when an LSP traverses the 1439 shortest route with the lightest load in the control plane. 1441 11.7.1.2. Methodologies 1443 Make sure that there is no LSP in the network, and proceed with the 1444 methodologies described in Section 11.6. 1446 11.7.2. With a Number of LSPs in the Network 1448 11.7.2.1. Motivation 1450 Single bidirectional LSP setup delay with a number of LSPs in the 1451 network is important because it reflects the performance of an 1452 operational network with considerable load. This delay can vary 1453 significantly as the number of existing LSPs varies. It can be used 1454 as a scalability metric of an RSVP-TE implementation. 1456 11.7.2.2. Methodologies 1458 Setup the required number of LSPs, and wait until the network reaches 1459 a stable state, then proceed with the methodologies described in 1460 Section 11.6. 1462 11.8. Metric Reporting 1464 The metric results including both real and undefined values MUST be 1465 reported together with the total number of values. The context under 1466 which the sample is obtained, including the selected parameters, the 1467 route traversed by the LSPs, and the testing case used, MUST also be 1468 reported. 1470 12. A Definition for Samples of Multiple Bidirectional LSPs Setup Delay 1472 In Section 7, we have defined the singleton metric of multiple 1473 bidirectional LSPs setup delay. Now we define how to get one 1474 particular sample of multiple bidirectional LSP setup delay. 1475 Sampling means to take a number of distinct instances of a skeleton 1476 metric under a given set of parameters. Like in [RFC2330], we use 1477 Poisson sampling as an example. 1479 12.1. Metric Name 1481 Multiple bidirectional LSPs setup delay sample 1483 12.2. Metric Parameters 1485 o ID0, the ingress LSR ID 1487 o ID1, the egress LSR ID 1489 o T0, a time 1491 o Tf, a time 1493 o Lambda_m, a rate in the reciprocal milliseconds 1495 o Lambda, a rate in the reciprocal milliseconds 1497 o X, the number of LSPs to set up 1499 o Th, LSP holding time 1501 o Td, the maximum waiting time for successful multiple 1502 unidirectional LSPs setup 1504 12.3. Metric Units 1506 A sequence of pairs; the elements of each pair are: 1508 o T, a time when the first setup is attempted 1510 o dT, either a real number of milliseconds, or undefined. 1512 12.4. Definition 1514 Given T0, Tf, and Lambda, compute a pseudo-random Poisson process 1515 beginning at or before T0, with average arrival rate Lambda, and 1516 ending at or after Tf. Those time values greater than or equal to T0 1517 and less than or equal to Tf are then selected. At each of the times 1518 in this process, we obtain the value of multiple unidirectional LSP 1519 setup delay sample at this time. The value of the sample is the 1520 sequence made up of the resulting pairs. If 1521 there are no such pairs, the sequence is of length zero and the 1522 sample is said to be empty. 1524 12.5. Discussion 1526 The parameter Lambda is used as arrival rate of "batch bidirectional 1527 LSPs setup" operation. It regulates the interval in between each 1528 batch operation. The parameter Lambda_m is used within each batch 1529 operation, as described in Section 7. 1531 The parameters Lambda and Lambda_m should be carefully chosen. If 1532 the rate is too high, too frequent LSP setup/release procedure will 1533 result in high overhead in the control plane. In turn, the high 1534 overhead will increase unidirectional LSP setup delay. On the other 1535 hand if the rate is too low, the sample could not completely reflect 1536 the dynamic provisioning performance of the GMPLS network. The 1537 appropriate Lambda and Lambda_m value depends on the given network. 1539 The parameters Td should be carefully chosen. Different switching 1540 technologies may vary significantly in performing a cross-connect 1541 operation. At the same time, the time needed in setting up an LSP 1542 under different traffic may also vary significantly. 1544 It is important that in obtaining a sample all the LSPs MUST traverse 1545 the same route. If there are multiple routes between the Ingress 1546 node ID0 and Egress node ID1, EROs or an alternate method, e.g., 1547 static configuration, MUST be used to ensure that all LSPs traverse 1548 the same route. 1550 12.6. Methodologies 1552 o Select the times using the specified Poisson arrival process, and 1554 o Set up the LSP as the methodology for the singleton multiple 1555 bidirectional LSPs setup delay, and obtain the value of multiple 1556 unidirectional LSPs setup delay 1558 o Release the LSP after Th, and wait for the next Poisson arrival 1559 event 1561 Note that: it is possible that before the previous LSP release 1562 procedure completes, the next Poisson arrival event arrives and the 1563 LSP setup procedure is initiated. If there is resource contention 1564 between the two LSPs, the LSP setup may fail. Ways to avoid such 1565 contention are outside the scope of this document. 1567 12.7. Typical testing cases 1569 12.7.1. With No LSP in the Network 1571 12.7.1.1. Motivation 1573 Multiple bidirectional LSPs setup delay with no LSP in the network is 1574 important because this reflects the inherent delay of an RSVP-TE 1575 implementation. The minimum value provides an indication of the 1576 delay that will likely be experienced when an LSPs traverse the 1577 shortest route with the lightest load in the control plane. 1579 12.7.1.2. Methodologies 1581 Make sure that there is no LSP in the network, and proceed with the 1582 methodologies described in Section 10.6. 1584 12.7.2. With a Number of LSPs in the Network 1586 12.7.2.1. Motivation 1588 Multiple bidirectional LSPs setup delay with a number of LSPs in the 1589 network is important because it reflects the performance of an 1590 operational network with considerable load. This delay may vary 1591 significantly as the number of existing LSPs vary. It may be used as 1592 a scalability metric of an RSVP-TE implementation. 1594 12.7.2.2. Methodologies 1596 Setup the required number of LSPs, and wait until the network reaches 1597 a stable state, then proceed with the methodologies described in 1598 Section 12.6. 1600 12.8. Metric Reporting 1602 The metric results including both real and undefined values MUST be 1603 reported together with the total number of values. The context under 1604 which the sample is obtained, including the selected parameters, the 1605 route traversed by the LSPs, and the testing case used, MUST also be 1606 reported. 1608 13. A Definition for Samples of LSP Graceful Release Delay 1610 In Section 8, we have defined the singleton metric of LSP graceful 1611 release delay. Now we define how to get one particular sample of LSP 1612 graceful release delay. We also use Poisson sampling as an example. 1614 13.1. Metric Name 1616 LSP graceful release delay sample 1618 13.2. Metric Parameters 1620 o ID0, the ingress LSR ID 1622 o ID1, the egress LSR ID 1624 o T0, a time 1626 o Tf, a time 1628 o Lambda, a rate in reciprocal milliseconds 1630 o Td, the maximum waiting time for successful LSP release 1632 13.3. Metric Units 1634 A sequence of pairs; the elements of each pair are: 1636 o T, a time, and 1638 o dT, either a real number of milliseconds, or undefined. 1640 13.4. Definition 1642 Given T0, Tf, and Lambda, we compute a pseudo-random Poisson process 1643 beginning at or before T0, with average arrival rate Lambda, and 1644 ending at or after Tf. Those time values greater than or equal to T0 1645 and less than or equal to Tf are then selected. At each of the times 1646 in this process, we obtain the value of LSP graceful release delay 1647 sample at this time. The value of the sample is the sequence made up 1648 of the resulting pairs. If there are no 1649 such pairs, the sequence is of length zero and the sample is said to 1650 be empty. 1652 13.5. Discussion 1654 The parameter Lambda should be carefully chosen. If the rate is too 1655 large, too frequent LSP setup/release procedure will result in high 1656 overhead in the control plane. In turn, the high overhead will 1657 increase unidirectional LSP setup delay. On the other hand if the 1658 rate is too small, the sample could not completely reflect the 1659 dynamic provisioning performance of the GMPLS network. The 1660 appropriate Lambda value depends on the given network. 1662 It is important that in obtaining a sample all the LSPs MUST traverse 1663 the same route. If there are multiple routes between the Ingress 1664 node ID0 and Egress node ID1, EROs or an alternate method, e.g., 1665 static configuration, MUST be used to ensure that all LSPs traverse 1666 the same route. 1668 13.6. Methodologies 1670 Generally the methodology would proceed as follows: 1672 o Setup the LSP to be deleted 1674 o Select the times using the specified Poisson arrival process, and 1676 o Release the LSP as the methodology for the singleton LSP graceful 1677 release delay, and obtain the value of LSP graceful release delay 1679 o Setup the LSP, and restart the Poisson arrival process, wait for 1680 the next Poisson arrival event 1682 13.7. Metric Reporting 1684 The metric results including both real and undefined values MUST be 1685 reported together with the total number of values. The context under 1686 which the sample is obtained, including the selected parameters, and 1687 the route traversed by the LSPs MUST also be reported. 1689 14. Some Statistics Definitions for Metrics to Report 1691 Given the samples of the performance metric, we now offer several 1692 statistics of these samples to report. From these statistics, we can 1693 draw some useful conclusions of a GMPLS network. The value of these 1694 metrics is either either a real number of milliseconds, or undefined. 1695 In the following discussion, we only consider the finite values. 1697 14.1. The Minimum of Metric 1699 The minimum of metric is the minimum of all the dT values in the 1700 sample. In computing this, undefined values SHOULD be treated as 1701 infinitely large. Note that this means that the minimum could thus 1702 be undefined if all the dT values are undefined. In addition, the 1703 metric minimum SHOULD be set to undefined if the sample is empty. 1705 14.2. The Median of Metric 1707 Metric median is the median of the dT values in the given sample. In 1708 computing the median, the undefined values MUST NOT be included. 1710 14.3. The Maximum of Metric 1712 The maximum of metric is the maximum of all the dT values in the 1713 sample. In computing this, undefined values MUST NOT be included. 1714 Note that this means that measurements that exceed the upper bound 1715 are not reported in this statistic. This is an important 1716 consideration when evaluating the maximum when the number of 1717 undefined measurements is non-zero. 1719 14.4. The Percentile of Metric 1721 The "empirical distribution function" (EDF) of a set of scalar 1722 measurements is a function F(x) which for any x gives the fractional 1723 proportion of the total measurements that were <= x. 1725 Given a percentage X, the X-th percentile of Metric means the 1726 smallest value of x for which F(x) >= X. In computing the percentile, 1727 undefined values MUST NOT be included. 1729 See [RFC2330] for further details. 1731 14.5. Failure statistics of Metric 1733 In the process of LSP setup/release, it may fail due to various 1734 reasons. For example, setup/release may fail when the control plane 1735 is overburdened or when there is resource shortage in one of the 1736 intermediate nodes. Since the setup/release failure may have 1737 significant impact on network operation, it is worthwhile to report 1738 each failure cases, so that appropriate operations can be performed 1739 to check the possible implementation, configuration or other 1740 deficiencies. 1742 Five types of failure events are defined in previous sections: 1744 o Single Unidirectional LSP Setup Failure 1746 o Multiple Unidirectional LSP Setup Failure 1748 o Single Bidirectional LSP Setup Failure 1750 o Multiple Bidirectional LSP Setup Failure 1752 o LSP graceful release failure 1754 Given the samples of the performance metric, we now offer two 1755 statistics of failure events of these samples to report. 1757 14.5.1. Failure Count 1759 Failure Count is defined as the number of the undefined value of the 1760 corresponding performance metric (failure events) in a sample. The 1761 value of Failure Count is an integer. 1763 14.5.2. Failure Ratio 1765 Failure Ratio is the percentage of the number of failure events to 1766 the total number of requests in a sample. The calculation for 1767 Failure Ratio is defined as follows: 1769 X type failure ratio = Number of X type failure events/(Number of 1770 valid X type metric values + Number of X type failure events) * 100%. 1772 15. Discussion 1774 It is worthwhile to point out that: 1776 o The unidirectional/bidirectional LSP setup delay is one ingress- 1777 egress round trip time plus processing time. But in this 1778 document, unidirectional/bidirectional LSP setup delay has not 1779 taken the processing time in the end nodes (ingress or/and egress) 1780 into account. The timestamp T2 is taken after the endpoint node 1781 receives it. Actually, the last node has to take some time to 1782 process local procedure. Similarly, in the LSP graceful release 1783 delay, the memo has not considered the processing time in the end 1784 node. 1786 o This document assumes that the correct procedures for installing 1787 the data plane are followed as described in [RFC3209], [RFC3471], 1788 and [RFC3473]. That is, by the time the egress receives and 1789 processes a Path message, it is safe for the egress to transmit 1790 data on the reverse path, and by the time the ingress receives and 1791 processes a Resv message it is safe for the ingress to transmit 1792 data on the forward path. See 1793 [I-D.shiomoto-ccamp-switch-programming] for detailed explanations. 1794 This document does not include any verification that the 1795 implementations of the control plane software are conformant, 1796 although such tests MAY be constructed with the use of suitable 1797 signal generation test equipment. In [I-D.sun-ccamp-dpm], we 1798 defined a series of metrics to do such verifications. However, it 1799 is RECOMMENDED that both the measurements defined in this document 1800 and the measurements defined in [I-D.sun-ccamp-dpm] are performed 1801 to complement each other. 1803 o Note that, in implementing the tests described in this document a 1804 tester should be sure to measure the time taken for the control 1805 plane messages including the processing of those messages by the 1806 nodes under test. 1808 o Bidirectional LSPs may be setup using three way signaling, where 1809 the initiating node will send a ResvConf message downstream upon 1810 receiving the Resv message. The ResvConf message is used to 1811 notify the terminate node that it can transfer data upstream. 1812 Actually, both direction should be ready to transfer data when the 1813 Resv message is received by the initiate node. Therefore, the 1814 bidirectional LSP setup delay defined in this document does not 1815 take the confirmation procedure into account. 1817 16. Security Considerations 1819 Samples of the metrics can be obtained in either active or passive 1820 manners. 1822 In active measurement, ingress nodes inject probing messages into the 1823 control plane. Since the measurement endpoints must be conformant to 1824 signaling specifications and behave as normal signaling endpoints, it 1825 will not incur other security issues than normal LSP provisioning. 1826 However, the measurement parameters must be carefully selected so 1827 that the measurements inject trivial amounts of additional traffic 1828 into the networks they measure. If they inject "too much" traffic, 1829 they can skew the results of the measurement, and in extreme cases 1830 cause congestion and denial of service. 1832 When samples of the metrics are collected in a passive manner, e.g., 1833 by monitoring the operations on real-life LSPs, the implementation of 1834 the monitoring and reporting mechanism must be careful so that they 1835 will not be used to attack the control plane. A typical 1836 implementation may use the Management Information Base (MIB) to 1837 collect/store the metrics and access to the MIB is limited to the 1838 Network Management Systems (NMSs). In this case, passive monitoring 1839 will not incur other security issues than implementing the MIBs and 1840 NMSs. If an implementation chooses to expose the performance data to 1841 other applications, then it must take into account the possible 1842 security issues it may face. For example, when exposing the 1843 performance data through SNMP, certain authentication method should 1844 be used to ensure that the entity maintaining the performance data 1845 are not subject to unauthorized readings and modifications. Rate 1846 limiting on the performance query may also be desirable to reduce the 1847 risk that the entity maintaining the performance data are overwhelmed 1848 by too much query requests. It is RECOMMENDED that implementers 1849 consider the security features as provided by the SNMPv3 framework 1850 (see [RFC3410], section 8), including full support for the SNMPv3 1851 cryptographic mechanisms (for authentication and privacy). 1853 Besides, the security considerations pertaining to the original RSVP 1854 protocol [RFC2205] and its TE extensions [RFC3209] also remain 1855 relevant. 1857 17. IANA Considerations 1859 This document makes no requests for IANA action. 1861 18. Acknowledgments 1863 We wish to thank Dan Li, Fang Liu (Christine), Zafar Ali, Monique 1864 Morrow, Adrian Farrel, Deborah Brungard, Lou Berger, Thomas D. Nadeau 1865 for their comments and helps. Lou Berger and Adrian Farrel have text 1866 contributions to this document. 1868 We wish to thank experts from IPPM and BMWG - Reinhard Schrage, Al 1869 Morton and Henk Uijterwaal, for reviewing this document. Reinhard 1870 Schrage has text contributions to this document. 1872 This document contains ideas as well as text that have appeared in 1873 existing IETF documents. The authors wish to thank G. Almes, S. 1874 Kalidindi and M. Zekauskas. 1876 We also wish to thank Weisheng Hu, Yaohui Jin and Wei Guo in the 1877 state key laboratory of advanced optical communication systems and 1878 networks for the valuable comments. We also wish to thank the 1879 support from NSFC and 863 program of China. 1881 19. References 1883 19.1. Normative References 1885 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1886 Requirement Levels", BCP 14, RFC 2119, March 1997. 1888 [RFC2205] Braden, B., Zhang, L., Berson, S., Herzog, S., and S. 1889 Jamin, "Resource ReSerVation Protocol (RSVP) -- Version 1 1890 Functional Specification", RFC 2205, September 1997. 1892 [RFC2679] Almes, G., Kalidindi, S., and M. Zekauskas, "A One-way 1893 Delay Metric for IPPM", RFC 2679, September 1999. 1895 [RFC2681] Almes, G., Kalidindi, S., and M. Zekauskas, "A Round-trip 1896 Delay Metric for IPPM", RFC 2681, September 1999. 1898 [RFC3209] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V., 1899 and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP 1900 Tunnels", RFC 3209, December 2001. 1902 [RFC3471] Berger, L., "Generalized Multi-Protocol Label Switching 1903 (GMPLS) Signaling Functional Description", RFC 3471, 1904 January 2003. 1906 [RFC3473] Berger, L., "Generalized Multi-Protocol Label Switching 1907 (GMPLS) Signaling Resource ReserVation Protocol-Traffic 1908 Engineering (RSVP-TE) Extensions", RFC 3473, January 2003. 1910 [RFC3945] Mannie, E., "Generalized Multi-Protocol Label Switching 1911 (GMPLS) Architecture", RFC 3945, October 2004. 1913 [RFC4208] Swallow, G., Drake, J., Ishimatsu, H., and Y. Rekhter, 1914 "Generalized Multiprotocol Label Switching (GMPLS) User- 1915 Network Interface (UNI): Resource ReserVation Protocol- 1916 Traffic Engineering (RSVP-TE) Support for the Overlay 1917 Model", RFC 4208, October 2005. 1919 19.2. Informative References 1921 [I-D.shiomoto-ccamp-switch-programming] 1922 Shiomoto, K. and A. Farrel, "Advice on When It is Safe to 1923 Start Sending Data on Label Switched Paths Established 1924 Using RSVP-TE", draft-shiomoto-ccamp-switch-programming-01 1925 (work in progress), October 2009. 1927 [I-D.sun-ccamp-dpm] 1928 Sun, W., Zhang, G., Gao, J., Xie, G., Papneja, R., Gu, B., 1929 Wei, X., Otani, T., and R. Jing, "Label Switched Path 1930 (LSP) Data Path Delay Metric in Generalized MPLS/ MPLS-TE 1931 Networks", draft-sun-ccamp-dpm-01 (work in progress), 1932 December 2009. 1934 [RFC2330] Paxson, V., Almes, G., Mahdavi, J., and M. Mathis, 1935 "Framework for IP Performance Metrics", RFC 2330, 1936 May 1998. 1938 [RFC3410] Case, J., Mundy, R., Partain, D., and B. Stewart, 1939 "Introduction and Applicability Statements for Internet- 1940 Standard Management Framework", RFC 3410, December 2002. 1942 Authors' Addresses 1944 Weiqiang Sun, Editor 1945 Shanghai Jiao Tong University 1946 800 Dongchuan Road 1947 Shanghai 200240 1948 China 1950 Phone: +86 21 3420 5359 1951 Email: sunwq@mit.edu 1953 Guoying Zhang, Editor 1954 China Academy of Telecommunication Research, MIIT, China. 1955 No.11 YueTan South Street 1956 Beijing 100045 1957 China 1959 Phone: +86 1068094272 1960 Email: zhangguoying@mail.ritt.com.cn 1962 Jianhua Gao 1963 Huawei Technologies Co., LTD. 1964 China 1966 Phone: +86 755 28973237 1967 Email: gjhhit@huawei.com 1969 Guowu Xie 1970 University of California, Riverside 1971 900 University Ave. 1972 Riverside, CA 92521 1973 USA 1975 Phone: +1 951 237 8825 1976 Email: xieg@cs.ucr.edu 1978 Rajiv Papneja 1979 Isocore 1980 12359 Sunrise Valley Drive, STE 100 1981 Reston, VA 20190 1982 USA 1984 Phone: +1 703 860 9273 1985 Email: rpapneja@isocore.com 1987 Contributors 1989 Bin Gu 1990 IXIA 1991 Oriental Kenzo Plaza 8M, 48 Dongzhimen Wai Street, Dongcheng District 1992 Beijing 200240 1993 China 1995 Phone: +86 13611590766 1996 Email: BGu@ixiacom.com 1998 Xueqin Wei 1999 Fiberhome Telecommunication Technology Co., Ltd. 2000 Wuhan 2001 China 2003 Phone: +86 13871127882 2004 Email: xqwei@fiberhome.com.cn 2006 Tomohiro Otani 2007 KDDI R&D Laboratories, Inc. 2008 2-1-15 Ohara Kamifukuoka Saitama 2009 356-8502 2010 Japan 2012 Phone: +81-49-278-7357 2013 Email: otani@kddilabs.jp 2015 Ruiquan Jing 2016 China Telecom Beijing Research Institute 2017 118 Xizhimenwai Avenue 2018 Beijing 100035 2019 China 2021 Phone: +86-10-58552000 2022 Email: jingrq@ctbri.com.cn