idnits 2.17.1 draft-xie-ccamp-lsp-dppm-02.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 27. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 1332. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 1343. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 1350. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 1356. 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 : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** There is 1 instance of too long lines in the document, the longest one being 1 character in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust Copyright Line does not match the current year == The document doesn't use any RFC 2119 keywords, yet seems to have RFC 2119 boilerplate text. -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (November 19, 2007) is 6002 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) ** Downref: Normative reference to an Informational RFC: RFC 2330 ** Obsolete normative reference: RFC 2679 (Obsoleted by RFC 7679) Summary: 5 errors (**), 0 flaws (~~), 2 warnings (==), 7 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 ccamp W. Sun 3 Internet-Draft SJTU 4 Intended status: Standards Track G. Zhang 5 Expires: May 22, 2008 CATR 6 J. Gao 7 Huawei 8 G. Xie 9 SJTU 10 R. Papneja 11 Isocore 12 B. Gu 13 IXIA 14 X. Wei 15 Fiberhome 16 November 19, 2007 18 Label Switched Path (LSP) Dynamical Provisioning Performance Metrics in 19 Generalized MPLS Networks 20 draft-xie-ccamp-lsp-dppm-02.txt 22 Status of this Memo 24 By submitting this Internet-Draft, each author represents that any 25 applicable patent or other IPR claims of which he or she is aware 26 have been or will be disclosed, and any of which he or she becomes 27 aware will be disclosed, in accordance with Section 6 of BCP 79. 29 Internet-Drafts are working documents of the Internet Engineering 30 Task Force (IETF), its areas, and its working groups. Note that 31 other groups may also distribute working documents as Internet- 32 Drafts. 34 Internet-Drafts are draft documents valid for a maximum of six months 35 and may be updated, replaced, or obsoleted by other documents at any 36 time. It is inappropriate to use Internet-Drafts as reference 37 material or to cite them other than as "work in progress." 39 The list of current Internet-Drafts can be accessed at 40 http://www.ietf.org/ietf/1id-abstracts.txt. 42 The list of Internet-Draft Shadow Directories can be accessed at 43 http://www.ietf.org/shadow.html. 45 Copyright Notice 46 Copyright (C) The IETF Trust (2007). 48 Abstract 50 Generalized Multi-Protocol Label Switching (GMPLS) is one of the most 51 promising candidate technologies for the future data transmission 52 network. The GMPLS has been developed to control and cooperate 53 different kinds of network elements, such as conventional routers, 54 switches, Dense Wavelength Division Multiplexing (DWDM) systems, Add- 55 Drop Multiplexors (ADMs), photonic cross-connects (PXCs), optical 56 cross-connects (OXCs), etc. Dynamic provisioning ability of these 57 physically diverse devices differs from each other drastically. At 58 the same time, the need for dynamically provisioned connections is 59 increasing because optical networks are being deployed in metro area. 60 As different applications have varied requirements in the 61 provisioning performance of optical networks, it is imperative to 62 define standardized metrics and procedures such that the performance 63 of networks and application needs can be mapped to each other. 65 This document provides a series of performance metrics to evaluate 66 the dynamic LSP provisioning performance in GMPLS networks, 67 specifically the dynamical LSP setup/release performance. These 68 metrics can depict the features of the GMPLS network in LSP dynamic 69 provisioning. They can also be used in operational networks for 70 carriers to monitor the control plane performance in realtime. 72 Table of Contents 74 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 6 75 2. Conventions Used in This Document . . . . . . . . . . . . . . 7 76 3. Overview of Performance Metrics . . . . . . . . . . . . . . . 8 77 4. A Singleton Definition for single unidirectional LSP Setup 78 Delay . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9 79 4.1. Motivation . . . . . . . . . . . . . . . . . . . . . . . . 9 80 4.2. Metric Name . . . . . . . . . . . . . . . . . . . . . . . 9 81 4.3. Metric Parameters . . . . . . . . . . . . . . . . . . . . 9 82 4.4. Metric Units . . . . . . . . . . . . . . . . . . . . . . . 10 83 4.5. Definition . . . . . . . . . . . . . . . . . . . . . . . . 10 84 4.6. Discussion . . . . . . . . . . . . . . . . . . . . . . . . 10 85 4.7. Methodologies . . . . . . . . . . . . . . . . . . . . . . 11 86 5. A Singleton Definition for multiple unidirectional LSP 87 Setup Delay . . . . . . . . . . . . . . . . . . . . . . . . . 12 88 5.1. Motivation . . . . . . . . . . . . . . . . . . . . . . . . 12 89 5.2. Metric Name . . . . . . . . . . . . . . . . . . . . . . . 12 90 5.3. Metric Parameters . . . . . . . . . . . . . . . . . . . . 12 91 5.4. Metric Units . . . . . . . . . . . . . . . . . . . . . . . 12 92 5.5. Definition . . . . . . . . . . . . . . . . . . . . . . . . 12 93 5.6. Discussion . . . . . . . . . . . . . . . . . . . . . . . . 13 94 5.7. Methodologies . . . . . . . . . . . . . . . . . . . . . . 14 95 6. A Singleton Definition for single Bidirectional LSP Setup 96 Delay . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15 97 6.1. Motivation . . . . . . . . . . . . . . . . . . . . . . . . 15 98 6.2. Metric Name . . . . . . . . . . . . . . . . . . . . . . . 15 99 6.3. Metric Parameters . . . . . . . . . . . . . . . . . . . . 15 100 6.4. Metric Units . . . . . . . . . . . . . . . . . . . . . . . 16 101 6.5. Definition . . . . . . . . . . . . . . . . . . . . . . . . 16 102 6.6. Discussion . . . . . . . . . . . . . . . . . . . . . . . . 16 103 6.7. Methodologies . . . . . . . . . . . . . . . . . . . . . . 17 104 7. A Singleton Definition for multiple Bidirectional LSPs 105 Setup Delay . . . . . . . . . . . . . . . . . . . . . . . . . 18 106 7.1. Motivation . . . . . . . . . . . . . . . . . . . . . . . . 18 107 7.2. Metric Name . . . . . . . . . . . . . . . . . . . . . . . 18 108 7.3. Metric Parameters . . . . . . . . . . . . . . . . . . . . 18 109 7.4. Metric Units . . . . . . . . . . . . . . . . . . . . . . . 18 110 7.5. Definition . . . . . . . . . . . . . . . . . . . . . . . . 18 111 7.6. Discussion . . . . . . . . . . . . . . . . . . . . . . . . 19 112 7.7. Methodologies . . . . . . . . . . . . . . . . . . . . . . 20 113 8. A Singleton Definition for LSP Graceful Release Delay . . . . 21 114 8.1. Motivation . . . . . . . . . . . . . . . . . . . . . . . . 21 115 8.2. Metric Name . . . . . . . . . . . . . . . . . . . . . . . 21 116 8.3. Metric Parameters . . . . . . . . . . . . . . . . . . . . 21 117 8.4. Metric Units . . . . . . . . . . . . . . . . . . . . . . . 21 118 8.5. Definition . . . . . . . . . . . . . . . . . . . . . . . . 21 119 8.6. Discussion . . . . . . . . . . . . . . . . . . . . . . . . 22 120 8.7. Methodologies . . . . . . . . . . . . . . . . . . . . . . 23 121 9. Typical Testing cases of single Unidirectional LSP Setup 122 Delay . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25 123 9.1. With no LSP in the Network . . . . . . . . . . . . . . . . 25 124 9.1.1. Motivation . . . . . . . . . . . . . . . . . . . . . . 25 125 9.1.2. Methodologies . . . . . . . . . . . . . . . . . . . . 25 126 9.2. With a Number of LSPs in the Network . . . . . . . . . . . 25 127 9.2.1. Motivation . . . . . . . . . . . . . . . . . . . . . . 25 128 9.2.2. Methodologies . . . . . . . . . . . . . . . . . . . . 25 129 10. Typical Testing cases of multiple Unidirectional LSPs 130 Setup Delay . . . . . . . . . . . . . . . . . . . . . . . . . 27 131 10.1. With no LSP in the Network . . . . . . . . . . . . . . . . 27 132 10.1.1. Motivation . . . . . . . . . . . . . . . . . . . . . . 27 133 10.1.2. Methodologies . . . . . . . . . . . . . . . . . . . . 27 134 10.2. With a Number of LSPs in the Network . . . . . . . . . . . 27 135 10.2.1. Motivation . . . . . . . . . . . . . . . . . . . . . . 27 136 10.2.2. Methodologies . . . . . . . . . . . . . . . . . . . . 27 137 11. Typical Testing cases of single Bidirectional LSP Setup 138 Delay . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29 139 11.1. With no LSP in the Network . . . . . . . . . . . . . . . . 29 140 11.1.1. Motivation . . . . . . . . . . . . . . . . . . . . . . 29 141 11.1.2. Methodologies . . . . . . . . . . . . . . . . . . . . 29 142 11.2. With a Number of LSPs in the Network . . . . . . . . . . . 29 143 11.2.1. Motivation . . . . . . . . . . . . . . . . . . . . . . 29 144 11.2.2. Methodologies . . . . . . . . . . . . . . . . . . . . 29 145 12. Typical Testing cases of multiple Bidirectional LSPs Setup 146 Delay . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31 147 12.1. With no LSP in the Network . . . . . . . . . . . . . . . . 31 148 12.1.1. Motivation . . . . . . . . . . . . . . . . . . . . . . 31 149 12.1.2. Methodologies . . . . . . . . . . . . . . . . . . . . 31 150 12.2. With a Number of LSPs in the Network . . . . . . . . . . . 31 151 12.2.1. Motivation . . . . . . . . . . . . . . . . . . . . . . 31 152 12.2.2. Methodologies . . . . . . . . . . . . . . . . . . . . 31 153 13. Some Statistics Definitions for Metrics to Report . . . . . . 33 154 13.1. The Minimum of Metric . . . . . . . . . . . . . . . . . . 33 155 13.2. The Median of Metric . . . . . . . . . . . . . . . . . . . 33 156 13.3. The percentile of Metric . . . . . . . . . . . . . . . . . 33 157 13.4. The failure probability . . . . . . . . . . . . . . . . . 33 158 14. Discussion . . . . . . . . . . . . . . . . . . . . . . . . . . 34 159 15. Security Considerations . . . . . . . . . . . . . . . . . . . 35 160 16. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 36 161 17. Normative References . . . . . . . . . . . . . . . . . . . . . 37 162 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 38 163 Intellectual Property and Copyright Statements . . . . . . . . . . 40 165 1. Introduction 167 Generalized Multi-Protocol Label Switching (GMPLS) is one of the most 168 promising control plane solutions for future transport and service 169 network. GMPLS has been developed to control and cooperate different 170 kinds of network elements, such as conventional routers, switches, 171 Dense Wavelength Division Multiplexing (DWDM) systems, Add-Drop 172 Multiplexors (ADMs), photonic cross-connects (PXCs), optical cross- 173 connects (OXCs), etc. Dynamic provisioning ability of these 174 physically diverse devices differs from each other drastically. 176 The introduction of a control plane into optical circuit switching 177 networks automates the provisioning of connections and drastically 178 reduces connection provision delay. As more and more services and 179 applications are seeking to use GMPLS controled networks as their 180 underlying transport network, and increasingly in a dynamic way, the 181 need is growing for measuring and characterizing the performance of 182 LSP provisioning in GMPLS networks, such that requirement from 183 applications and the provisioning capability of the network can be 184 mapped to each other. 186 This draft intends to define performance metrics and methodologies 187 that can be used to depict the dynamic connection provisioning 188 performance of GMPLS networks. The metrics defined in this draft can 189 in the one hand be used to depict the averaged performance of GMPLS 190 implementations. On the other hand, it can also be used in 191 operational environments for carriers to monitor the control plane 192 operation in realtime. For example, an new object can be added to 193 the GMPLS TE STD MIB [RFC4802] such that the current and past control 194 plane performance can be monitored through network management 195 systems. The extension of TE-MIB to support the metrics defined is 196 out the scope of this document. 198 2. Conventions Used in This Document 200 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 201 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 202 document are to be interpreted as described in [RFC2119]. 204 3. Overview of Performance Metrics 206 In this memo, to depict the dynamic LSP provisioning performance of a 207 GMPLS network, we define 3 performance metrics: unidirectional LSP 208 setup delay, bidirectional LSP setup delay, and LSP graceful release 209 delay. The latency of the LSP setup/release signal is similar to the 210 Round-trip Delay in IP networks. So we refer the structures and 211 notions introduced and discussed in the IPPM Framework document, 212 [RFC2330] [RFC2679] [RFC2681]. The reader is assumed to be familiar 213 with the notions in those documents. 215 4. A Singleton Definition for single unidirectional LSP Setup Delay 217 This part defines a metric for single unidirectional Label Switched 218 Path setup delay across a GMPLS network. 220 4.1. Motivation 222 Single unidirectional Label Switched Path setup delay is useful for 223 several reasons: 225 o Single LSP setup delay is an important metric that depicts the 226 provisioning performance of a GMPLS network. Longer LSP setup 227 delay will incur higher overhead for the requesting application, 228 especially when the LSP duration is comparable to the LSP setup 229 delay. 231 o The minimum value of this metric provides an indication of the 232 delay that will likely be experienced when the LSP traversed the 233 shortest route at the lightest load in the control plane. As the 234 delay itself consists of several components, such as link 235 propagation delay and nodal processing delay, this metric also 236 reflects the status of control plane. For example, for LSPs 237 traversing the same route, longer setup delays may suggest 238 congestion in the control channel or high control element load. 239 For this reason, this metric is useful for testing and diagnostic 240 purposes. 242 o LSP setup delay variance has different impact on to applications. 243 Erratic variation in LSP setup delay makes it difficult to support 244 applications that has stringent setup delay requirement. 246 The measurement of single unidirectional LSP setup delay instead of 247 bidirectional LSP setup delay is motivated by the following factors: 249 o Some applications may only use unidirectional LSPs rather than 250 bidirectional ones. For example, content delivery services in 251 multicast method (IPTV) only use unidirectional LSPs. 253 4.2. Metric Name 255 single unidirectional LSP setup delay 257 4.3. Metric Parameters 259 o ID0, the ingress LSR ID 261 o ID1, the egress LSR ID 262 o T, a time 264 4.4. Metric Units 266 The value of single unidirectional LSP setup delay is either a real 267 number, or an undefined (informally, infinite) number of 268 milliseconds. 270 4.5. Definition 272 The single unidirectional LSP setup delay from the ingress node to 273 the egress node [RFC3945] at T is dT means that ingress node sends 274 the first bit of a PATH message packet to egress node at wire-time T, 275 and that the ingress node received the last bit of responding RESV 276 message packet from egress node at wire-time T+dT in the 277 unidirectional LSP setup case. 279 The single unidirectional LSP setup delay from the ingress node to 280 the egress node at T is undefined (informally, infinite), means that 281 ingress node sends the first bit of PATH message packet to egress 282 node at wire-time T and that ingress node does not receive the 283 corresponding RESV message within a reasonable period of time. 285 4.6. Discussion 287 The following issues are likely to come up in practice: 289 o The accuracy of unidirectional LSP setup delay at time T depends 290 on the clock resolution in the ingress node; but synchronization 291 between the ingress node and egress node is not required since 292 unidirectional LSP setup uses two-way signaling. 294 o A given methodology will have to include a way to determine 295 whether a latency value is infinite or whether it is merely very 296 large. Simple upper bounds could be used. But the GMPLS network 297 accommodates many kinds of devices. For example, some photonic 298 cross-connects (PXCs) have to move the micro mirrors. This 299 physical motion may take several milliseconds. But the common 300 electronic switches finish the nodal process within several 301 microseconds. So the unidirectional LSP setup delay varies 302 drastically from a network to another. In practice, the upper 303 bound should be chosen carefully. 305 o If ingress node sends out the PATH message to set up LSP, but 306 never receive corresponding RESV message, unidirectional LSP setup 307 delay is deemed to be infinite. 309 o If ingress node sends out the PATH message to set up LSP but 310 receive PathErr message, unidirectional LSP setup delay is also 311 deemed to be infinite. There are many possible reasons for this 312 case. For example, the PATH message has invalid parameters or the 313 network has not enough resource to set up the requested LSP, etc. 315 4.7. Methodologies 317 Generally the methodology would proceed as follows: 319 o Make sure that the network has enough resource to set up the 320 requested LSP. 322 o At the ingress node, form the PATH message according to the LSP 323 requirements. A timestamp (T1) may be stored locally in the 324 ingress node when the PATH message packet is sent towards the 325 egress node. 327 o If the corresponding RESV message arrives within a reasonable 328 period of time, take the timestamp (T2) as soon as possible upon 329 receipt of the message. By subtracting the two timestamps, an 330 estimate of unidirectional LSP setup delay (T2 -T1) can be 331 computed. 333 o If the corresponding RESV message fails to arrive within a 334 reasonable period of time, the unidirectional LSP setup delay is 335 deemed to be undefined (informally, infinite). Note that the 336 'reasonable' threshold of the unidirectional LSP setup delay is a 337 parameter of the methodology. 339 o If the corresponding response message is PathErr, the 340 unidirectional LSP setup delay is deemed to be undefined 341 (informally, infinite). 343 5. A Singleton Definition for multiple unidirectional LSP Setup Delay 345 This part defines a metric for multiple unidirectional Label Switched 346 Paths setup delay across a GMPLS network. 348 5.1. Motivation 350 multiple unidirectional Label Switched Paths setup delay is useful 351 for several reasons: 353 o Upon traffic interruption caused by network failure or network 354 upgrade, carriers may require a large number of LSPs be set up 355 during a short time period 357 o The time needed to set up a large number of LSPs during a short 358 time period can not be deduced by single LSP setup delay 360 5.2. Metric Name 362 multiple unidirectional LSPs setup delay 364 5.3. Metric Parameters 366 o ID0, the ingress LSR ID 368 o ID1, the egress LSR ID 370 o Lambda, a rate in reciprocal milliseconds 372 o X, the number of LSPs to set up 374 o T, a time 376 5.4. Metric Units 378 The value of multiple unidirectional LSPs setup delay is either a 379 real number, or an undefined (informally, infinite) number of 380 milliseconds. 382 5.5. Definition 384 Given lambda and X, the multiple unidirectional LSPs setup delay from 385 the ingress node to the egress node [RFC3945] at T is dT means: 387 o ingress node sends the first bit of the first PATH message packet 388 to egress node at wire-time T 390 o all subsequent (X-1) PATH messages are sent according to the 391 specified poisson process with arrival rate lambda 393 o ingress node receives all corresponding RESV message packets from 394 egress node, and 396 o ingress node receives the last RESV message packet at wire-time 397 T+dT 399 The multiple unidirectional LSPs setup delay at T is undefined 400 (informally, infinite), means that ingress node sends all the PATH 401 messages toward the egress and the first bit of the first PATH 402 message packet is sent at wire-time T and that ingress node does not 403 receive the one or more of the corresponding RESV messages within a 404 reasonable period of time. 406 5.6. Discussion 408 The following issues are likely to come up in practice: 410 o The accuracy of multiple unidirectional LSPs setup delay at time T 411 depends on the clock resolution in the ingress node; but 412 synchronization between the ingress node and egress node is not 413 required since unidirectional LSP setup uses two-way signaling. 415 o A given methodology will have to include a way to determine 416 whether a latency value is infinite or whether it is merely very 417 large. Simple upper bounds could be used. But the GMPLS network 418 accommodates many kinds of devices. For example, some photonic 419 cross-connects (PXCs) have to move the micro mirrors. This 420 physical motion may take several milliseconds. But the common 421 electronic switches finish the nodal process within several 422 microseconds. So the multiple unidirectional LSP setup delay 423 varies drastically from a network to another. In practice, the 424 upper bound should be chosen carefully. 426 o If ingress node sends out the multiple PATH messages to set up the 427 LSPs, but never receives one or more of the corresponding RESV 428 messages, the unidirectional LSP setup delay is deemed to be 429 infinite. 431 o If ingress node sends out the PATH messages to set up the LSPs but 432 receives one or more PathErr messages, multiple unidirectional 433 LSPs setup delay is also deemed to be infinite. There are many 434 possible reasons for this case. For example, one of the PATH 435 message has invalid parameters or the network has not enough 436 resource to set up the requested LSPs, etc. 438 o The arrival rate of the poisson process lambda should be carefully 439 chosen such that in the one hand the control plane is not 440 overburdened.On the other hand, the arrival rate should also be 441 large enough to meet the requirements of applications or services. 443 5.7. Methodologies 445 Generally the methodology would proceed as follows: 447 o Make sure that the network has enough resource to set up the 448 requested LSPs. 450 o At the ingress node, form the PATH messages according to the LSPs' 451 requirements. 453 o At the ingress node, select the time for each of the PATH messages 454 according to the specified poisson process. 456 o At the ingress node, sends out the PATH messages according to the 457 selected time. 459 o Store a timestamp (T1) locally in the ingress node when the first 460 PATH message packet is sent towards the egress node. 462 o If all of the corresponding RESV messages arrives within a 463 reasonable period of time, take the final timestamp (T2) as soon 464 as possible upon the receipt of all the messages. By subtracting 465 the two timestamps, an estimate of multiple unidirectional LSPs 466 setup delay (T2 -T1) can be computed. 468 o If one or more of the corresponding RESV messages fails to arrive 469 within a reasonable period of time, the multiple unidirectional 470 LSPs setup delay is deemed to be undefined (informally, infinite). 471 Note that the 'reasonable' threshold is a parameter of the 472 methodology. 474 o If one of the corresponding response message is PathErr, the 475 multiple unidirectional LSPs setup delay is deemed to be undefined 476 (informally, infinite). 478 6. A Singleton Definition for single Bidirectional LSP Setup Delay 480 GMPLS allows establishment of bi-directional symmetric LSPs (not of 481 asymmetric LSPs). This part defines a metric for single 482 bidirectional LSP setup delay across a GMPLS network. 484 6.1. Motivation 486 Single bidirectional Label Switched Path setup delay is useful for 487 several reasons: 489 o LSP setup delay is an important metric that depicts the 490 provisioning performance of a GMPLS network. Longer LSP setup 491 delay will incur higher overhead for the requesting application, 492 especially when the LSP duration is comparable to the LSP setup 493 delay. Thus, measuring the setup delay is important for 494 applications scheduling. 496 o The minimum value of this metric provides an indication of the 497 delay that will likely be experienced when the LSP traversed the 498 shortest route at the lightest load in the control plane. As the 499 delay itself consists of several components, such as link 500 propagation delay and nodal processing delay, this metric also 501 reflects the status of control plane. For example, for LSPs 502 traversing the same route, longer setup delays may suggest 503 congestion in the control channel or high control element load. 504 For this reason, this metric is useful for testing and diagnostic 505 purposes. 507 o LSP setup delay variance has different impact on to applications. 508 Erratic variation in LSP setup delay makes it difficult to support 509 applications that has stringent setup delay requirement. 511 The measurement of single bidirectional LSP setup delay instead of 512 unidirectional LSP setup delay is motivated by the following factors: 514 o Bidirectional LSPs are seen as a requirement for many GMPLS 515 networks. Its provisioning performance is important to 516 applications that generates bi-directional traffic. 518 6.2. Metric Name 520 Single bidirectional LSP setup delay 522 6.3. Metric Parameters 523 o ID0, the ingress LSR ID 525 o ID1, the egress LSR ID 527 o T, a time 529 6.4. Metric Units 531 The value of single bidirectional LSP setup delay is either a real 532 number, or an undefined (informally, infinite) number of 533 milliseconds. 535 6.5. Definition 537 For a real number dT, the single bidirectional LSP setup delay from 538 ingress node to egress node at T is dT, means that ingress node sends 539 out the first bit of a PATH message including an Upstream Label 540 [RFC3473] heading for egress node at wire-time T, egress node 541 receives that packet, then immediately sends a RESV message packet 542 back to ingress node, and that ingress node receives the last bit of 543 that packet at wire-time T+dT. 545 The single bidirectional LSP setup delay from ingress node to egress 546 node at T is undefined (informally, infinite), means that ingress 547 node sends the first bit of PATH message to egress node at wire-time 548 T and that ingress node does not receive that response packet. 550 6.6. Discussion 552 The following issues are likely to come up in practice: 554 o The accuracy of single bidirectional LSP setup delay depends on 555 the clock resolution in the ingress node; but synchronization 556 between the ingress node and egress node is not required since 557 single bidirectional LSP setup uses two-way signaling. 559 o A given methodology will have to include a way to determine 560 whether a latency value is infinite or whether it is merely very 561 large. Simple upper bounds could be used. But the GMPLS network 562 accommodates many kinds of devices. For example, some photonic 563 cross-connects (PXCs) have to move the micro mirrors. This 564 physical motion may take several milliseconds. But the common 565 electronic switches finish the nodal process within several 566 microseconds. So the bidirectional LSP setup delay varies 567 drastically from a network to another. In the process of 568 bidirectional LSP setup, if the downstream node overrides the 569 label suggested by the upstream node, the setup delay will also 570 increase obviously. Thus, in practice, the upper bound should be 571 chosen carefully. 573 o If the ingress node sends out the PATH message to set up the LSP, 574 but never receives the corresponding RESV message, single 575 bidirectional LSP setup delay is deemed to be infinite. 577 o If the ingress node sends out the PATH message to set up the LSP, 578 but receives PathErr message, single bidirectional LSP setup delay 579 is also deemed to be infinite. There are many possible reasons 580 for this case. For example, the PATH message has invalid 581 parameters or the network has not enough resource to set up the 582 requested LSP. 584 6.7. Methodologies 586 Generally the methodology would proceed as follows: 588 o Make sure that the network has enough resource to set up the 589 requested LSP. 591 o At the ingress node, form the PATH message (including the Upstream 592 Label or suggested label) according to the LSP requirements. A 593 timestamp (T1) may be stored locally in the ingress node when the 594 PATH message packet is sent towards the egress node. 596 o If the corresponding RESV message arrives within a reasonable 597 period of time, take the final timestamp (T2) as soon as possible 598 upon the receipt of the message. By subtracting the two 599 timestamps, an estimate of bidirectional LSP setup delay (T2 -T1) 600 can be computed. 602 o If the corresponding RESV message fails to arrive within a 603 reasonable period of time, the single bidirectional LSP setup 604 delay is deemed to be undefined (informally, infinite). Note that 605 the 'reasonable' threshold is a parameter of the methodology. 607 o If the corresponding response message is PathErr, the single 608 bidirectional LSP setup delay is deemed to be undefined 609 (informally, infinite). 611 7. A Singleton Definition for multiple Bidirectional LSPs Setup Delay 613 This part defines a metric for multiple bidirectional LSPs setup 614 delay across a GMPLS network. 616 7.1. Motivation 618 multiple Bidirectional LSPs setup delay is useful for several 619 reasons: 621 o Upon traffic interruption caused by network failure or network 622 upgrade, carriers may require a large number of LSPs be set up 623 during a short time period 625 o The time needed to setup a large number of LSPs during a short 626 time period can not be deduced by single LSP setup delay 628 7.2. Metric Name 630 Multiple bidirectional LSPs setup delay 632 7.3. Metric Parameters 634 o ID0, the ingress LSR ID 636 o ID1, the egress LSR ID 638 o Lambda, a rate in reciprocal milliseconds 640 o X, the number of LSPs to setup 642 o T, a time 644 7.4. Metric Units 646 The value of multiple bidirectional LSPs setup delay is either a real 647 number, or an undefined (informally, infinite) number of 648 milliseconds. 650 7.5. Definition 652 Given lambda and X, for a real number dT, the multiple bidirectional 653 LSPs setup delay from ingress node to egress node at T is dT, means 654 that: 656 o ingress node sends the first bit of the first PATH message heading 657 for egress node at wire-time T 659 o all subsequent (X-1) PATH messages are sent according to the 660 specified poisson process with arrival rate lambda 662 o ingress node receives all corresponding RESV message packets from 663 egress node, and 665 o ingress node receives the last RESV message packets at wire-time 666 T+dT 668 The multiple bidirectional LSPs setup delay from ingress node to 669 egress node at T is undefined (informally, infinite), means that 670 ingress node sends all the PATH messages to egress node and that the 671 ingress node dose not receive one or more of the response messages. 673 7.6. Discussion 675 The following issues are likely to come up in practice: 677 o The accuracy of multiple bidirectional LSPs setup delay depends on 678 the clock resolution in the ingress node; but synchronization 679 between the ingress node and egress node is not required since 680 bidirectional LSP setup uses two-way signaling. 682 o A given methodology will have to include a way to determine 683 whether a latency value is infinite or whether it is merely very 684 large. Simple upper bounds could be used. But the GMPLS network 685 accommodates many kinds of devices. For example, some photonic 686 cross-connects (PXCs) have to move the micro mirrors. This 687 physical motion may take several milliseconds. But the common 688 electronic switches finish the nodal process within several 689 microseconds. So the bidirectional LSP setup delay varies 690 drastically from a network to another. In the process of 691 bidirectional LSP setup, if the downstream node overrides the 692 label suggested by the upstream node, the setup delay will also 693 increase obviously. Thus, in practice, the upper bound should be 694 chosen carefully. 696 o If the ingress node sends out the PATH messages to set up the 697 LSPs, but never receive all the corresponding RESV messages, the 698 multiple bidirectional LSPs setup delay is deemed to be infinite. 700 o If the ingress node sends out the PATH messages to set up the 701 LSPs, but receive one or more responding PathErr messages,the 702 multiple bidirectional LSPs setup delay is also deemed to be 703 infinite. There are many possible reasons for this case. For 704 example, one or more of the PATH messages have invalid parameters 705 or the network has not enough resource to set up the requested 706 LSPs. 708 o The arrival rate of the poisson process lambda should be carefully 709 chosen such that in the one hand the control plane is not 710 overburdened.On the other hand, the arrival rate should also be 711 large enough to meet the requirements of applications or services. 713 7.7. Methodologies 715 Generally the methodology would proceed as follows: 717 o Make sure that the network has enough resource to set up the 718 requested LSPs. 720 o At the ingress node, form the PATH messages (including the 721 Upstream Label or suggested label) according to the LSPs' 722 requirements. 724 o At the ingress node, select the time for each of the PATH messages 725 according to the specified poisson process. 727 o At the ingress node, sends out the PATH messages according to the 728 selected time. 730 o Store a timestamp (T1) locally in the ingress node when the first 731 PATH message packet is sent towards the egress node. 733 o If all of the corresponding RESV messages arrives within a 734 reasonable period of time, take the final timestamp (T2) as soon 735 as possible upon the receipt of all the messages. By subtracting 736 the two timestamps, an estimate of multiple bidirectional LSPs 737 setup delay (T2 -T1) can be computed. 739 o If one or more of the corresponding RESV messages fails to arrive 740 within a reasonable period of time, the multiple bidirectional 741 LSPs setup delay is deemed to be undefined (informally, infinite). 742 Note that the 'reasonable' threshold is a parameter of the 743 methodology. 745 o If one or more of the corresponding response messages is PathErr, 746 the multiple bidirectional LSPs setup delay is deemed to be 747 undefined (informally, infinite). 749 8. A Singleton Definition for LSP Graceful Release Delay 751 There are two different kinds of LSP release mechanisms in the GMPLS 752 network: graceful release and forceful release. Memo in current 753 version has not taken forceful LSP release procedure into account. 755 8.1. Motivation 757 LSP graceful release delay is useful for several reasons: 759 o The LSP graceful release delay is part of the total cost of 760 dynamic LSP provisioning. For some short duration applications, 761 the LSP tear down time can not be ignored 763 o The LSP graceful release procedure is more prefered in a GMPLS 764 controled network, particularly the optical networks. Since it 765 doesn't trigger restoration/protection, it is "alarm-free 766 connection deletion" in [RFC4208]. 768 8.2. Metric Name 770 LSP graceful release delay 772 8.3. Metric Parameters 774 o ID0, the ingress LSR ID 776 o ID1, the egress LSR ID 778 o T, a time 780 8.4. Metric Units 782 The value of LSP graceful release delay is either a real number, or 783 an undefined (informally, infinite) number of milliseconds. 785 8.5. Definition 787 There are two different LSP graceful release procedures, one is 788 initiated by the ingress node, and another is initiated by egress 789 node. The two procedures are depicted in the [RFC3473]. We define 790 the graceful LSP release delay for these two procedures separately. 792 For a real number dT, the LSP graceful release delay from ingress 793 node to egress node at T is dT, means that ingress node sends the 794 first bit of a PATH message including Admin Status Object with 795 setting the Reflect (R) and Delete (D) bits to egress node at wire- 796 time T, that egress node receives that packet, then immediately sends 797 a RESV message including Admin Status Object with the Delete (D) bit 798 set back to ingress node. The ingress node sends out PathTear 799 downstream to remove the LSP, and egress node receives the last bit 800 of PathTear packet at wire-time T+dT. 802 Also as an option, upon receipt of the PATH message including Admin 803 Status Object with setting the Reflect (R) and Delete (D) bits, the 804 egress node may respond with PathErr message with the 805 Path_State_Removed flag set. 807 The LSP graceful release delay from ingress node to egress node at T 808 is undefined (informally, infinite), means that ingress node sends 809 the first bit of PATH message to egress node at wire-time T and that 810 (either egress node does not receive the PATH packet, egress node 811 does not send corresponding RESV message packet in response, ingress 812 node does not receive that RESV packet, or) the egress does not 813 receive the PathTear. 815 The LSP graceful release delay from egress node to ingress node at T 816 is dT, means that egress node sends the first bit of a RESV message 817 including Admin Status Object with setting the Reflect (R) and Delete 818 (D) bits to ingress node at wire-time T. The ingress node sends out 819 PathTear downstream to remove the LSP, and egress node receives the 820 last bit of PathTear packet at wire-time T+dT. 822 The LSP graceful release delay from egress node to ingress node at T 823 is undefined (informally, infinite), means that egress node sends the 824 first bit of RESV message including Admin Status Object with setting 825 the Reflect (R) and Delete (D) bits to ingress node at wire-time T 826 and that (either ingress node does not receive the RESV packet, 827 ingress node does not send PathTear message packet in response or) 828 the egress does not receive the PathTear. 830 8.6. Discussion 832 The following issues are likely to come up in practice: 834 o In the first (second) circumstance, the accuracy of LSP graceful 835 release delay at time T depends on the clock resolution in the 836 ingress (egress) node. In the first circumstance, synchronization 837 between the ingress node and egress node is required; but not in 838 the second circumstance; 840 o A given methodology has to include a way to determine whether a 841 latency value is infinite or whether it is merely very large. 842 Simple upper bounds could be used. But the upper bound should be 843 chosen carefully in practice; 845 o In the first circumstance, if ingress node sends out PATH message 846 including Admin Status Object with the Reflect (R) and Delete (D) 847 bits set to initiate LSP graceful release, but never receive 848 corresponding RESV message, LSP graceful release delay is deemed 849 to be infinite. In the second circumstance, if egress node sends 850 out RESV message including Admin Status Object with the Reflect 851 (R) and Delete (D) bits set to initiate LSP graceful release, but 852 never receive corresponding PathTear message, LSP graceful release 853 delay is deemed to be infinite; 855 8.7. Methodologies 857 In the first circumstance, the methodology may proceed as follows: 859 o Make sure the LSP to be deleted is set up; 861 o At the egress node, form the PATH message including Admin Status 862 Object with the Reflect (R) and Delete (D) bits set. A timestamp 863 (T1) may be stored locally in the ingress node when the PATH 864 message packet is sent towards the egress node; 866 o Upon receiving the PATH message including Admin Status Object with 867 the Reflect (R) and Delete (D) bits set, the egress node sends a 868 RESV message including Admin Status Object with the Delete (D) and 869 Reflect (R) bits set. Or, alternatively, the egress node sends a 870 PathErr message with the Path_State_Removed flag set upstream; 872 o When the ingress node receive the RESV message or the PathErr 873 message, it sends a PathTear message to remove the LSP; 875 o Egress node takes a timestamp (T2) once it receives the last bit 876 of the PathTear message. The LSP graceful release delay is then 877 (T2-T1). 879 In the second circumstance, the methodology would proceed as follows: 881 o Make sure the LSP to be deleted is set up; 883 o On the egress node, form the RESV message including Admin Status 884 Object with the Reflect (R) and Delete (D) bits set. A timestamp 885 may be stored locally in the egress node when the RESV message 886 packet is sent towards the ingress node; 888 o Upon receiving the Admin Status Object with the Reflect (R) and 889 Delete (D) bits set in the RESV message, the ingress node sends a 890 PathTear message downstream to remove the LSP; 892 o Egress node takes a timestamp (T2) once it receives the last bit 893 of the PathTear message. The LSP graceful release delay is then 894 (T2-T1). 896 9. Typical Testing cases of single Unidirectional LSP Setup Delay 898 Now we define typical test cases of getting unidirectional LSP setup 899 delay. 901 9.1. With no LSP in the Network 903 9.1.1. Motivation 905 Single unidirectional LSP setup delay with no LSP in the network is 906 important because this reflects the inherent delay of an RSVP-TE 907 implementation. The minimum value provides an indication of the 908 delay that will likely be experienced when an LSP traverses the 909 shortest route with the lightest load in the control plane. 911 9.1.2. Methodologies 913 Make sure that there is no or very few LSPs in the network. The 914 methodology would proceed as follows: 916 o Set up the LSP using the methodology for the singleton single 917 unidirectional LSP setup delay, and obtain the value of 918 unidirectional LSP setup delay 920 o Release the LSP 922 o Repeat this process if multiple samples are needed 924 Note that: in case multiple samples are to be obtained, the interval 925 between each process should be large enough to guarantee the network 926 has already reached a stable state. 928 9.2. With a Number of LSPs in the Network 930 9.2.1. Motivation 932 Single unidirectional LSP setup delay with a number of LSPs in the 933 network is important because it reflects the performance of an 934 operational network with considrable load. This delay can vary 935 significantly as the number of existing LSPs vary. It can be used as 936 a scalability metric of an RSVP-TE implementation. 938 9.2.2. Methodologies 940 Setup the required number of LSPs, and wait until the network reaches 941 a stable state, then proceed as follows: 943 o Set up the LSP using the methodology for the singleton single 944 unidirectional LSP setup delay, and obtain the value of 945 unidirectional LSP setup delay 947 o Release the LSP 949 o Repeat this process if multiple samples are needed 951 Note that: in case multiple samples are to be obtained, the interval 952 between each process should be large enough to guarantee the network 953 has already reached a stable state. 955 10. Typical Testing cases of multiple Unidirectional LSPs Setup Delay 957 Now we define typical test cases of getting multiple unidirectional 958 LSPs setup delay. 960 10.1. With no LSP in the Network 962 10.1.1. Motivation 964 multiple unidirectional LSP setup delay with no LSP in the network is 965 important because this reflects the inherent delay of an RSVP-TE 966 implementation. The minimum value provides an indication of the 967 delay that will likely be experienced when a number of LSPs are set up 968 with the lightest load in the control plane. 970 10.1.2. Methodologies 972 Make sure that there is no or very few LSPs in the network. The 973 methodology would proceed as follows: 975 o Set up the LSPs using the methodology for the singleton multiple 976 unidirectional LSP setup delay, and obtain the value of multiple 977 unidirectional LSP setup delay 979 o Release the LSPs 981 o Repeat this process if multiple samples are needed 983 Note that: in case multiple samples are to be obtained, the interval 984 between each process should be large enough to guarantee the network 985 has already reached a stable state. 987 10.2. With a Number of LSPs in the Network 989 10.2.1. Motivation 991 multiple unidirectional LSP setup delay with a number of LSPs in the 992 network is important because it reflects the performance of an 993 operational network with considrable load. This delay can vary 994 significantly as the number of existing LSPs vary. It can be used as 995 a scalability metric of an RSVP-TE implementation. 997 10.2.2. Methodologies 999 Setup the required number of LSPs, and wait until the network reaches 1000 a stable state, then proceed as follows: 1002 o Set up the LSPs using the methodology for the singleton multiple 1003 unidirectional LSP setup delay, and obtain the value of multiple 1004 unidirectional LSP setup delay 1006 o Release the LSPs 1008 o Repeat this process if multiple samples are needed 1010 Note that: in case multiple samples are to be obtained, the interval 1011 between each process should be large enough to guarantee the network 1012 has already reached a stable state. 1014 11. Typical Testing cases of single Bidirectional LSP Setup Delay 1016 Now we define typical test cases of getting single bidirectional LSP 1017 setup delay. 1019 11.1. With no LSP in the Network 1021 11.1.1. Motivation 1023 Single unidirectional LSP setup delay with no LSP in the network is 1024 important because this reflects the inherent delay of an RSVP-TE 1025 implementation. The minimum value provides an indication of the 1026 delay that will likely be experienced when an LSP traverses the 1027 shortest route with the lightest load in the control plane. 1029 11.1.2. Methodologies 1031 Make sure that there is no or very few LSPs in the network. The 1032 methodology would proceed as follows: 1034 o Set up the LSP using the methodology for the singleton 1035 bidirectional LSP setup delay, and obtain the value of 1036 unidirectional LSP setup delay 1038 o Release the LSP 1040 o Repeat this process if multiple samples are needed 1042 Note that: in case multiple samples are to be obtained, the interval 1043 between each process should be large enough to guarantee the network 1044 has already reached a stable state. 1046 11.2. With a Number of LSPs in the Network 1048 11.2.1. Motivation 1050 Single bidirectional LSP setup delay with a number of LSPs in the 1051 network is important because it reflects the performance of an 1052 operational network with considrable load. This delay can vary 1053 significantly as the number of existing LSPs vary. It can be used as 1054 a scalability metric of an RSVP-TE implementation. 1056 11.2.2. Methodologies 1058 Setup the required number of LSPs, and wait until the network reaches 1059 a stable state, then proceed as follows: 1061 o Set up the LSP using the methodology for the singleton 1062 bidirectional bidirectional LSP setup delay, and obtain the value 1063 of bidirectional LSP setup delay 1065 o Release the LSP 1067 o Repeat this process if multiple samples are needed 1069 Note that: in case multiple samples are to be obtained, the interval 1070 between each process should be large enough to guarantee the network 1071 has already reached a stable state. 1073 12. Typical Testing cases of multiple Bidirectional LSPs Setup Delay 1075 Now we define typical test cases of getting multiple bidirectional 1076 LSPs setup delay. 1078 12.1. With no LSP in the Network 1080 12.1.1. Motivation 1082 multiple bidirectional LSP setup delay with no LSP in the network is 1083 important because this reflects the inherent delay of an RSVP-TE 1084 implementation. The minimum value provides an indication of the 1085 delay that will likely be experienced when a number of LSPs are setup 1086 with the lightest load in the control plane. 1088 12.1.2. Methodologies 1090 Make sure that there is no or very few LSPs in the network. The 1091 methodology would proceed as follows: 1093 o Set up the LSPs using the methodology for the singleton multiple 1094 multiple bidirectional LSP setup delay, and obtain the value of 1095 multiple bidirectional LSP setup delay 1097 o Release the LSPs 1099 o Repeat this process if multiple samples are needed 1101 Note that: in case multiple samples are to be obtained, the interval 1102 between each process should be large enough to guarantee the network 1103 has already reached a stable state. 1105 12.2. With a Number of LSPs in the Network 1107 12.2.1. Motivation 1109 multiple bidirectional LSPs setup delay with a number of LSPs in the 1110 network is important because it reflects the performance of an 1111 operational network with considrable load. This delay can vary 1112 significantly as the number of existing LSPs vary. It can be used as 1113 a scalability metric of an RSVP-TE implementation. 1115 12.2.2. Methodologies 1117 Setup the required number of LSPs, and wait until the network reaches 1118 a stable state, then proceed as follows: 1120 o Set up the LSPs using the methodology for the singleton multiple 1121 bidirectional LSPs setup delay, and obtain the value of multiple 1122 bidirectional LSPs setup delay 1124 o Release the LSPs 1126 o Repeat this process if multiple samples are needed 1128 Note that: in case multiple samples are to be obtained, the interval 1129 between each process should be large enough to guarantee the network 1130 has already reached a stable state. 1132 13. Some Statistics Definitions for Metrics to Report 1134 Given the samples of the performance metric, we now offer several 1135 statistics of these samples to report. From these statistics, we can 1136 draw some useful conclusions of a GMPLS network. The value of these 1137 metrics is either a real number, or an undefined (informally, 1138 infinite) number of milliseconds. In the following discussion, we 1139 only consider the finite values. 1141 13.1. The Minimum of Metric 1143 The minimum of metric is the minimum of all the dT values in the 1144 sample. In computing this, undefined values are treated as 1145 infinitely large. Note that this means that the minimum could thus 1146 be undefined (informally, infinite) if all the dT values are 1147 undefined. In addition, the metric minimum is undefined if the 1148 sample is empty. 1150 13.2. The Median of Metric 1152 Metric median is the median of the dT values in the given sample. In 1153 computing the median, the undefined values are not counted in. 1155 13.3. The percentile of Metric 1157 Given a metric and a percent X between 0% and 100%, the Xth 1158 percentile of all the dT values in the sample. In addition, the 1159 unidirectional LSP setup delay percentile is undefined if the sample 1160 is empty. 1162 Example: suppose we take a sample and the results are: Stream1 = < 1163 , , , , > 1166 Then the 50th percentile would be 110 msec, since 90 msec and 100 1167 msec are smaller, and 110 and 500 msec are larger (undefined values 1168 are not counted in). 1170 13.4. The failure probability 1172 In the process of LSP setup/release, it may fail for some reason. 1173 The failure probability is the ratio of the failure times to the 1174 total times. 1176 14. Discussion 1178 It is worthwhile to point out that: 1180 o The unidirectional/bidirectional LSP setup delay is one ingress- 1181 egress round trip time plus processing time. But in the draft, 1182 unidirectional/bidirectional LSP setup delay has not taken the 1183 processing time in the end nodes (ingress or/and egress) into 1184 account. The timestamp T2 is taken after the endpoint node 1185 receives it. Actually, the last node has to take some time to 1186 process local procedure. Similarly, in the LSP graceful release 1187 delay, the memo has not considered the processing time in the 1188 endpoint node. 1190 o All these metrics are defined from the point of control plane's 1191 view. In fact, the control plane and data plane are not always 1192 synchronized. In some cases, the LSPs have been set up in the 1193 control plane. But the data can not be forwarded immediately. 1194 The unidirectional/bidirectional LSP setup delay in the data plane 1195 is longer than in the control plane. 1197 15. Security Considerations 1199 The security considerations pertaining to the original RSVP protocol 1200 [RFC2205] and its TE extensions [RFC3209] remain relevant. 1202 16. Acknowledgements 1204 We wish to thank Dan Li, Fang Liu (Christine), Zafar Ali, Monique 1205 Morrow, Al Morton, Adrian Farrel, Deborah Brungard, Thomas D. Nadeau 1206 for their comments and helps. 1208 This document contains ideas as well as text that have appeared in 1209 existing IETF documents. The authors wish to thank G. Almes, S. 1210 Kalidindi and M. Zekauskas. 1212 We also wish to thank Weisheng Hu, Yaohui Jin and Wei Guo in the 1213 state key laboratory of advanced optical communication systems and 1214 networks for the valuable comments. We also wish to thank the 1215 support from NSFC and 863 program of China. 1217 17. Normative References 1219 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1220 Requirement Levels", BCP 14, RFC 2119, March 1997. 1222 [RFC2205] Braden, B., Zhang, L., Berson, S., Herzog, S., and S. 1223 Jamin, "Resource ReSerVation Protocol (RSVP) -- Version 1 1224 Functional Specification", RFC 2205, September 1997. 1226 [RFC2330] Paxson, V., Almes, G., Mahdavi, J., and M. Mathis, 1227 "Framework for IP Performance Metrics", RFC 2330, 1228 May 1998. 1230 [RFC2679] Almes, G., Kalidindi, S., and M. Zekauskas, "A One-way 1231 Delay Metric for IPPM", RFC 2679, September 1999. 1233 [RFC2681] Almes, G., Kalidindi, S., and M. Zekauskas, "A Round-trip 1234 Delay Metric for IPPM", RFC 2681, September 1999. 1236 [RFC3209] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V., 1237 and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP 1238 Tunnels", RFC 3209, December 2001. 1240 [RFC3473] Berger, L., "Generalized Multi-Protocol Label Switching 1241 (GMPLS) Signaling Resource ReserVation Protocol-Traffic 1242 Engineering (RSVP-TE) Extensions", RFC 3473, January 2003. 1244 [RFC3945] Mannie, E., "Generalized Multi-Protocol Label Switching 1245 (GMPLS) Architecture", RFC 3945, October 2004. 1247 [RFC4208] Swallow, G., Drake, J., Ishimatsu, H., and Y. Rekhter, 1248 "Generalized Multiprotocol Label Switching (GMPLS) User- 1249 Network Interface (UNI): Resource ReserVation Protocol- 1250 Traffic Engineering (RSVP-TE) Support for the Overlay 1251 Model", RFC 4208, October 2005. 1253 [RFC4802] Nadeau, T. and A. Farrel, "Generalized Multiprotocol Label 1254 Switching (GMPLS) Traffic Engineering Management 1255 Information Base", RFC 4802, February 2007. 1257 Authors' Addresses 1259 Weiqiang Sun 1260 Shanghai Jiao Tong University 1261 800 Dongchuan Road 1262 Shanghai 200240 1263 CN 1265 Phone: +86 21 3420 5359 1266 Email: sunwq@sjtu.edu.cn 1268 Guoying Zhang 1269 China Academy of Telecommunication Research,MII. 1270 Beijing 200240 1271 CN 1273 Phone: +86 1068094272 1274 Email: zhangguoying@mail.ritt.com.cn 1276 Jianhua Gao 1277 Huawei Technologies Co., LTD. 1278 CN 1280 Phone: +86 755 28973237 1281 Email: gjhhit@huawei.com 1283 Guowu Xie 1284 Shanghai Jiao Tong University 1285 800 Dongchuan Road 1286 Shanghai 200240 1287 CN 1289 Phone: +86 21 3420 4596 1290 Email: blithe@sjtu.edu.cn 1292 Rajiv Papneja 1293 Isocore 1294 12359 Sunrise Valley Drive, STE 100 1295 Reston, VA 20190 1296 USA 1298 Phone: +1 703 860 9273 1299 Email: rpapneja@isocore.com 1300 Bin Gu 1301 IXIA 1302 Oriental Kenzo Plaza 8M,48 Dongzhimen Wai Street,Dongcheng District 1303 Beijing 200240 1304 CN 1306 Phone: +86 13611590766 1307 Email: BGu@ixiacom.com 1309 Xueqing Wei 1310 Fiberhome Telecommunicaiton Technology Co.,Ltd. 1311 Wuhan 1312 CN 1314 Phone: +86 13871127882 1315 Email: xqwei@fiberhome.com.cn 1317 Full Copyright Statement 1319 Copyright (C) The IETF Trust (2007). 1321 This document is subject to the rights, licenses and restrictions 1322 contained in BCP 78, and except as set forth therein, the authors 1323 retain all their rights. 1325 This document and the information contained herein are provided on an 1326 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 1327 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST 1328 AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, 1329 EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT 1330 THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY 1331 IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR 1332 PURPOSE. 1334 Intellectual Property 1336 The IETF takes no position regarding the validity or scope of any 1337 Intellectual Property Rights or other rights that might be claimed to 1338 pertain to the implementation or use of the technology described in 1339 this document or the extent to which any license under such rights 1340 might or might not be available; nor does it represent that it has 1341 made any independent effort to identify any such rights. Information 1342 on the procedures with respect to rights in RFC documents can be 1343 found in BCP 78 and BCP 79. 1345 Copies of IPR disclosures made to the IETF Secretariat and any 1346 assurances of licenses to be made available, or the result of an 1347 attempt made to obtain a general license or permission for the use of 1348 such proprietary rights by implementers or users of this 1349 specification can be obtained from the IETF on-line IPR repository at 1350 http://www.ietf.org/ipr. 1352 The IETF invites any interested party to bring to its attention any 1353 copyrights, patents or patent applications, or other proprietary 1354 rights that may cover technology that may be required to implement 1355 this standard. Please address the information to the IETF at 1356 ietf-ipr@ietf.org. 1358 Acknowledgement 1360 Funding for the RFC Editor function is provided by the IETF 1361 Administrative Support Activity (IASA).