idnits 2.17.1 draft-sun-ccamp-dpm-01.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, but was first submitted on or after 10 November 2008. The disclaimer is usually necessary only for documents that revise or obsolete older RFCs, and that take significant amounts of text from those RFCs. If you can contact all authors of the source material and they are willing to grant the BCP78 rights to the IETF Trust, 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 5240 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- ** Obsolete normative reference: RFC 2679 (Obsoleted by RFC 7679) == Outdated reference: A later version (-11) exists of draft-ietf-ccamp-lsp-dppm-10 == Outdated reference: A later version (-05) exists of draft-shiomoto-ccamp-switch-programming-01 Summary: 2 errors (**), 0 flaws (~~), 4 warnings (==), 1 comment (--). 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: Informational G. Zhang, Ed. 5 Expires: June 17, 2010 CATR 6 December 14, 2009 8 Label Switched Path (LSP) Data Path Delay Metric in Generalized MPLS/ 9 MPLS-TE Networks 10 draft-sun-ccamp-dpm-01.txt 12 Abstract 14 When setting up a label switched path (LSP) in Generalized MPLS and 15 MPLS/TE networks, the completion of the signaling process does not 16 necessarily mean that the cross connection along the LSP have been 17 programmed accordingly and in a timely manner. Meanwhile, the 18 completion of signaling process may be used by applications as 19 indication that data path has become usable. The existence of this 20 delay and the possible failure of cross connection programming, if 21 not properly treated, will result in data loss or even application 22 failure. Characterization of this performance can thus help 23 designers to improve the application model and to build more robust 24 applications. This document defines a series of performance metrics 25 to evaluate the availability of data path in the signaling process. 27 Status of this Memo 29 This Internet-Draft is submitted to IETF in full conformance with the 30 provisions of BCP 78 and BCP 79. 32 Internet-Drafts are working documents of the Internet Engineering 33 Task Force (IETF), its areas, and its working groups. Note that 34 other groups may also distribute working documents as Internet- 35 Drafts. 37 Internet-Drafts are draft documents valid for a maximum of six months 38 and may be updated, replaced, or obsoleted by other documents at any 39 time. It is inappropriate to use Internet-Drafts as reference 40 material or to cite them other than as "work in progress." 42 The list of current Internet-Drafts can be accessed at 43 http://www.ietf.org/ietf/1id-abstracts.txt. 45 The list of Internet-Draft Shadow Directories can be accessed at 46 http://www.ietf.org/shadow.html. 48 This Internet-Draft will expire on June 17, 2010. 50 Copyright Notice 52 Copyright (c) 2009 IETF Trust and the persons identified as the 53 document authors. All rights reserved. 55 This document is subject to BCP 78 and the IETF Trust's Legal 56 Provisions Relating to IETF Documents 57 (http://trustee.ietf.org/license-info) in effect on the date of 58 publication of this document. Please review these documents 59 carefully, as they describe your rights and restrictions with respect 60 to this document. Code Components extracted from this document must 61 include Simplified BSD License text as described in Section 4.e of 62 the Trust Legal Provisions and are provided without warranty as 63 described in the BSD License. 65 This document may contain material from IETF Documents or IETF 66 Contributions published or made publicly available before November 67 10, 2008. The person(s) controlling the copyright in some of this 68 material may not have granted the IETF Trust the right to allow 69 modifications of such material outside the IETF Standards Process. 70 Without obtaining an adequate license from the person(s) controlling 71 the copyright in such materials, this document may not be modified 72 outside the IETF Standards Process, and derivative works of it may 73 not be created outside the IETF Standards Process, except to format 74 it for publication as an RFC or to translate it into languages other 75 than English. 77 Table of Contents 79 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 5 81 2. Conventions Used in This Document . . . . . . . . . . . . . . 6 83 3. Overview of Performance Metrics . . . . . . . . . . . . . . . 7 85 4. Terms used in this document . . . . . . . . . . . . . . . . . 8 87 5. A singleton Definition for RRFD . . . . . . . . . . . . . . . 9 88 5.1. Motivation . . . . . . . . . . . . . . . . . . . . . . . . 9 89 5.2. Metric Name . . . . . . . . . . . . . . . . . . . . . . . 9 90 5.3. Metric Parameters . . . . . . . . . . . . . . . . . . . . 9 91 5.4. Metric Units . . . . . . . . . . . . . . . . . . . . . . . 9 92 5.5. Definition . . . . . . . . . . . . . . . . . . . . . . . . 10 93 5.6. Discussion . . . . . . . . . . . . . . . . . . . . . . . . 10 94 5.7. Methodologies . . . . . . . . . . . . . . . . . . . . . . 11 96 6. A singleton Definition for RSRD . . . . . . . . . . . . . . . 12 97 6.1. Motivation . . . . . . . . . . . . . . . . . . . . . . . . 12 98 6.2. Metric Name . . . . . . . . . . . . . . . . . . . . . . . 12 99 6.3. Metric Parameters . . . . . . . . . . . . . . . . . . . . 12 100 6.4. Metric Units . . . . . . . . . . . . . . . . . . . . . . . 12 101 6.5. Definition . . . . . . . . . . . . . . . . . . . . . . . . 13 102 6.6. Discussion . . . . . . . . . . . . . . . . . . . . . . . . 13 103 6.7. Methodologies . . . . . . . . . . . . . . . . . . . . . . 14 105 7. A singleton Definition for PRFD . . . . . . . . . . . . . . . 15 106 7.1. Motivation . . . . . . . . . . . . . . . . . . . . . . . . 15 107 7.2. Metric Name . . . . . . . . . . . . . . . . . . . . . . . 15 108 7.3. Metric Parameters . . . . . . . . . . . . . . . . . . . . 15 109 7.4. Metric Units . . . . . . . . . . . . . . . . . . . . . . . 15 110 7.5. Definition . . . . . . . . . . . . . . . . . . . . . . . . 15 111 7.6. Discussion . . . . . . . . . . . . . . . . . . . . . . . . 16 112 7.7. Methodologies . . . . . . . . . . . . . . . . . . . . . . 16 114 8. A Definition for Samples of Data Path Delay . . . . . . . . . 18 115 8.1. Metric Name . . . . . . . . . . . . . . . . . . . . . . . 18 116 8.2. Metric Parameters . . . . . . . . . . . . . . . . . . . . 18 117 8.3. Metric Units . . . . . . . . . . . . . . . . . . . . . . . 18 118 8.4. Definition . . . . . . . . . . . . . . . . . . . . . . . . 18 119 8.5. Discussion . . . . . . . . . . . . . . . . . . . . . . . . 19 120 8.6. Methodologies . . . . . . . . . . . . . . . . . . . . . . 19 121 8.7. Typical testing cases . . . . . . . . . . . . . . . . . . 19 122 8.7.1. With No LSP in the Network . . . . . . . . . . . . . . 19 123 8.7.2. With a Number of LSPs in the Network . . . . . . . . . 20 125 9. Some Statistics Definitions for Metrics to Report . . . . . . 21 126 9.1. The Minimum of Metric . . . . . . . . . . . . . . . . . . 21 127 9.2. The Median of Metric . . . . . . . . . . . . . . . . . . . 21 128 9.3. The percentile of Metric . . . . . . . . . . . . . . . . . 21 129 9.4. The Failure Probability . . . . . . . . . . . . . . . . . 21 131 10. Security Considerations . . . . . . . . . . . . . . . . . . . 22 133 11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 23 135 12. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 24 137 13. References . . . . . . . . . . . . . . . . . . . . . . . . . . 25 138 13.1. Normative References . . . . . . . . . . . . . . . . . . . 25 139 13.2. Informative References . . . . . . . . . . . . . . . . . . 25 141 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 26 143 1. Introduction 145 Ideally, the completion of the signaling process means that the 146 signaled label switched path (LSP) is available and is ready to carry 147 traffic. However, in actual implementations, vendors may choose to 148 program the cross connection in a pipelined manner, so that the 149 overall LSP provisioning delay can be reduced. In such situations, 150 the data path may not be available instantly after the signaling 151 process completes. Implementation deficiency may also cause the 152 inconsistency in between the signaling process and data path 153 provisioning. For example, if the data plane failed to program the 154 cross connection accordingly but does not manage to report this to 155 the control plane, the signaling process may complete successfully 156 while the corresponding data path will never become functional at 157 all. 159 On the other hand, the completion of the signaling process may be 160 used in many cases as indication of data path availability. For 161 example, when invoking through User Network Interface (UNI), a client 162 device or an application may use the reception of the correct RESV 163 message as indication that data path is fully functional and start to 164 transmit traffic. This will results in data loss or even application 165 failure. 167 Although RSVP(-TE) specifications have suggested that the cross 168 connections are programmed before signaling messages are propagated 169 upstream, it is still worthwhile to verify the conformance of an 170 implementation and measure the delay, when necessary. 172 This document defines a series of performance metrics to evaluate the 173 availability of data path when the signaling process completes. The 174 metrics defined in this document complements the control plane 175 metrics defined in [I-D.ietf-ccamp-lsp-dppm]. They can be used to 176 verify the conformance of implementations against related 177 specifications, as elaborated in 178 [I-D.shiomoto-ccamp-switch-programming]. They also can be used to 179 build more robust applications. 181 2. Conventions Used in This Document 183 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 184 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 185 document are to be interpreted as described in [RFC2119]. 187 3. Overview of Performance Metrics 189 In this memo, we define three performance metrics to characterize the 190 performance of data path provisioning with GMPLS/MPLS-TE signaling. 191 These metrics complement the metrics defined in 192 [I-D.ietf-ccamp-lsp-dppm], in the sense that the completion of the 193 signaling process for a Label Switched Path (LSP) and the programming 194 of cross connections along the LSP may not be consistent. The 195 performance metrics in [I-D.ietf-ccamp-lsp-dppm] characterize the 196 performance of LSP provisioning from the pure signaling point of 197 view, while the metric in this document takes into account the 198 validity of the data path. 200 The three metrics are: 202 o RRFD - the delay between RESV message received by ingress node and 203 forward data path becomes available. 205 o RSRD - the delay between RESV message sent by egress node and 206 reverse data path becomes available. 208 o PRFD - the delay between PATH message received by egress node and 209 forward data path becomes available. 211 As in [I-D.ietf-ccamp-lsp-dppm], we continue to use the structures 212 and notions introduced and discussed in the IPPM Framework document, 213 [RFC2330] [RFC2679] [RFC2681]. The reader is assumed to be familiar 214 with the notions in those documents. The readers are assumed to be 215 familiar with the definitions in [I-D.ietf-ccamp-lsp-dppm] as well. 217 4. Terms used in this document 219 o Forward data path - the data path from the ingress to the egress. 220 Instances of forward data path include the data path of a uni- 221 directional LSP and data path from the ingress node to the egress 222 node in a bidirectional LSP. 224 o Reverse data path - the data path from the egress to the ingress 225 in a bidirectional LSP. 227 o Error free signal - data plane specific indication of availability 228 of the data path. For example, for packet switched interfaces, 229 the reception of the first error free packet from one side of the 230 LSP to the other can be used as the error free signal. For SDH/ 231 SONET cross connects, the disappearance of alarm can be used as 232 the error free signal. Through out this document, we will use the 233 "error free signal" as a general term. An implementations must 234 choose a proper data path signal that is specific to the data path 235 technology being tested. 237 o Ingress/egress node - in this memo, an ingress/egress node means a 238 measurement endpoint with both control plane and data plane 239 features. Typically, the control plane part on an ingress/egress 240 node interact with the control plane of the network under test. 241 The data plane part of an ingress/egress node will generate data 242 path signals and send the signal to the data plane of the network 243 under test, or receive data path signals from the network under 244 test. 246 5. A singleton Definition for RRFD 248 This part defines a metric for forward data path delay when an LSP is 249 setup. 251 As described in [I-D.shiomoto-ccamp-switch-programming], the 252 completion of the RSVP-TE signaling process does not necessarily mean 253 that the cross connections along the LSP being setup are in place and 254 ready to carry traffic. This metric defines the time difference 255 between the reception of RESV message by the ingress node and the 256 completion of the cross connection programming along the forward data 257 path. 259 5.1. Motivation 261 RRFD is useful for several reasons: 263 o For the reasons described in 264 [I-D.shiomoto-ccamp-switch-programming], the data path may not be 265 available instantly after the completion of the RSVP-TE signaling 266 process. The delay itself is part of the implementation 267 performance. 269 o The completion of the signaling process may be used by application 270 designers as indication of data path availability. The existence 271 of this delay and the potential failure of cross connection 272 programming, if not properly treated, will result in data loss or 273 application failure. The typical value of this delay can thus 274 help designers to improve the application model. 276 5.2. Metric Name 278 RRFD 280 5.3. Metric Parameters 282 o ID0, the ingress LSR ID 284 o ID1, the egress LSR ID 286 o T, a time when the setup is attempted 288 5.4. Metric Units 290 Either a real number of milli-seconds or undefined. 292 5.5. Definition 294 For a real number dT, RRFD from ingress node ID0 to egress node ID1 295 at T is dT means that ingress node ID0 send a PATH message to egress 296 node ID1 and the last bit of the corresponding RESV message is 297 received by ingress node ID0 at T, and an error free signal is 298 received by egress node ID1 by using a data plane specific test 299 pattern at T+dT. 301 5.6. Discussion 303 The following issues are likely to come up in practice: 305 o The accuracy of RRFD depends on the clock resolution of both the 306 ingress node and egress node. Clock synchronization between the 307 ingress node and egress node is required. 309 o The accuracy of RRFD is also dependent on how the error free 310 signal is received and may differ significantly when the underline 311 data plane technology is different. For instance, for an LSP 312 between a pair of Ethernet interfaces, the ingress node (sometimes 313 the tester) may use a rate based method to verify the availability 314 of the data path and use the reception of the first error free 315 frame as the error free signal. In this case, the interval 316 between two successive frames has a significant impact on 317 accuracy. It is RECOMMENDED that the ingress node uses small 318 intervals, under the condition that the injected traffic does not 319 exceed the capacity of the forward data path. The value of the 320 interval MUST be reported. 322 o The accuracy of RRFD is also dependent on the time needed to 323 propagate the error free signal from the ingress node to the 324 egress node. A typical value of propagating the error free signal 325 from the ingress node to the egress node under the same 326 measurement setup MAY be reported. The methodology to obtain such 327 values is outside the scope of this document. 329 o It is possible that under some implementations, a node may program 330 the cross connection before it sends PATH message further 331 downstream and the data path may be available before a RESV 332 message reaches the ingress node. In such cases, RRFD can be a 333 negetive value. It is RECOMMENDED that PRFD measurement is 334 carried out to further characterize the forward data path delay 335 when a negetive RRFD value is observed. 337 o If error free signal is received by the egress node before PATH 338 message is sent, an error MUST be reported and the measurement 339 SHOULD terminate. 341 o If the corresponding RESV message is received, but no error free 342 signal is received by the egress node within a reasonable period 343 of time, RRFD MUST be treated as undefined. The value of the 344 threshold MUST be reported. 346 o If the LSP setup fails, RRFD MUST NOT be counted. 348 5.7. Methodologies 350 Generally the methodology would proceed as follows: 352 o Make sure that the network has enough resource to set up the 353 requested LSP. 355 o Start the data path measurement and/or monitoring procedures on 356 the ingress node and egress node. If error free signal is 357 received by the egress node before PATH message is sent, report an 358 error and terminate the mmeasurement. 360 o At the ingress node, form the PATH message according to the LSP 361 requirements and send the message towards the egress node. 363 o Upon receiving the last bit of the corresponding RESV message, 364 take the time stamp (T1) on the ingress node as soon as possible. 366 o When an error free signal is observed on the egress node, take the 367 time stamp (T2) as soon as possible. An estimate of RRFD (T2 - 368 T1) can be computed. 370 o If the corresponding RESV message arrives, but no error free 371 signal is received within a reasonable period of time by the 372 ingress node, RRFD is deemed to be undefined. 374 o If the LSP setup fails, RRFD is not counted. 376 6. A singleton Definition for RSRD 378 This part defines a metric for reverse data path delay when an LSP is 379 setup. 381 As described in [I-D.shiomoto-ccamp-switch-programming], the 382 completion of the RSVP-TE signaling process does not necessarily mean 383 that the cross connections along the LSP being setup are in place and 384 ready to carry traffic. This metric defines the time difference 385 between the completion of the signaling process and the completion of 386 the cross connection programming along the reverse data path. This 387 metric MAY be used together with RRFD to characterize the data path 388 delay of a bidirectional LSP. 390 6.1. Motivation 392 RSRD is useful for several reasons: 394 o For the reasons described in 395 [I-D.shiomoto-ccamp-switch-programming], the data path may not be 396 available instantly after the completion of the RSVP-TE signaling 397 process. The delay itself is part of the implementation 398 performance. 400 o The completion of the signaling process may be used by application 401 designers as indication of data path availability. The existence 402 of this delay and the possible failure of cross connection 403 programming, if not properly treated, will result in data loss or 404 application failure. The typical value of this delay can thus 405 help designers to improve the application model. 407 6.2. Metric Name 409 RSRD 411 6.3. Metric Parameters 413 o ID0, the ingress LSR ID 415 o ID1, the egress LSR ID 417 o T, a time when the setup is attempted 419 6.4. Metric Units 421 Either a real number of milli-seconds or undefined. 423 6.5. Definition 425 For a real number dT, RSRD from ingress node ID0 to egress node ID1 426 at T is dT means that ingress node ID0 send a PATH message to egress 427 node ID1 and the last bit of the corresponding RESV message is sent 428 by egress node ID1 at T, and an error free signal is received by the 429 ingress node ID0 using a data plane specific test pattern at T+dT. 431 6.6. Discussion 433 The following issues are likely to come up in practice: 435 o The accuracy of RSRD depends on the clock resolution of both the 436 ingress node and egress node. And clock synchronization between 437 the ingress node and egress node is required. 439 o The accuracy of RSRD is also dependent on how the error free 440 signal is received and may differ significantly when the underline 441 data plane technology is different. For instance, for an LSP 442 between a pair of Ethernet interfaces, the egress node (sometimes 443 the tester) may use a rate based method to verify the availability 444 of the data path and use the reception of the first error free 445 frame as the error free signal. In this case, the interval 446 between two successive frames has a significant impact on 447 accuracy. It is RECOMMENDED that in this case the egress node 448 uses small intervals, under the condition that the injected 449 traffic does not exceed the capacity of the reverse data path. 450 The value of the interval MUST be reported. 452 o The accuracy of RSRD is also dependent on the time needed to 453 propagate the error free signal from the egress node to the 454 ingress node. A typical value of propagating the error free 455 signal from the egress node to the ingress node under the same 456 measurement setup MAY be reported. The methodology to obtain such 457 values is outside the scope of this document. 459 o If the corresponding RESV message is sent, but no error free 460 signal is received by the ingress node within a reasonable period 461 of time, RSRD MUST be treated as undefined. The value of the 462 threshold MUST be reported. 464 o If error free signal is received before PATH message is sent, an 465 error MUST be reported and the measurement SHOULD terminate. 467 o If the LSP setup fails, RSRD MUST NOT be counted. 469 6.7. Methodologies 471 Generally the methodology would proceed as follows: 473 o Make sure that the network has enough resource to set up the 474 requested LSPs. 476 o Start the data path measurement and/or monitoring procedures on 477 the ingress node and egress node. If error free signal is 478 received by the ingress node before PATH message is sent, report 479 an error and terminate the mmeasurement. 481 o At the ingress node, form the PATH message according to the LSP 482 requirements and send the message towards the egress node. 484 o Upon sending the last bit of the corresponding RESV message, take 485 the time stamp (T1) on the egress node as soon as possible. 487 o When an error free signal is observed on the ingress node, take 488 the time stamp (T2) as soon as possible. An estimate of RSRD 489 (T2-T1) can be computed. 491 o If the LSP setup fails, RSRD is not counted. 493 o If no error free signal is received within a reasonable period of 494 time by the ingress node, RSRD is deemed to be undefined. 496 7. A singleton Definition for PRFD 498 This part defines a metric for forward data path delay when an LSP is 499 setup. 501 In an RSVP-TE implementation, when setting up an LSP, each node may 502 choose to program the cross connection before it sends PATH message 503 further downstream. In this case, the forward data path may become 504 available before the signaling process completes, ie. before the RESV 505 reaches the ingress node. This metric can be used to identify such 506 implementation practice and give useful information to application 507 designers. 509 7.1. Motivation 511 PRFD is useful for the following reasons: 513 o PRFD can be used to identify an RSVP-TE implementation practice, 514 in which cross connections are programmed before PATH message is 515 sent downtream. 517 o The value of PRFD may also help application designers to fine tune 518 their application model. 520 7.2. Metric Name 522 PRFD 524 7.3. Metric Parameters 526 o ID0, the ingress LSR ID 528 o ID1, the egress LSR ID 530 o T, a time when the setup is attempted 532 7.4. Metric Units 534 Either a real number of milli-seconds or undefined. 536 7.5. Definition 538 For a real number dT, PRFD from ingress node ID0 to egress node ID1 539 at T is dT means that ingress node ID0 send a PATH message to egress 540 node ID1 and the last bit of the PATH message is received by egress 541 node ID1 at T, and an error free signal is received by the egress 542 node ID1 using a data plane specific test pattern at T+dT. 544 7.6. Discussion 546 The following issues are likely to come up in practice: 548 o The accuracy of PRFD depends on the clock resolution of the egress 549 node. And clock synchronization between the ingress node and 550 egress node is not required. 552 o The accuracy of PRFD is also dependent on how the error free 553 signal is received and may differ significantly when the underline 554 data plane technology is different. For instance, for an LSP 555 between a pair of Ethernet interfaces, the egress node (sometimes 556 the tester) may use a rate based method to verify the availability 557 of the data path and use the reception of the first error free 558 frame as the error free signal. In this case, the interval 559 between two successive frames has a significant impact on 560 accuracy. It is RECOMMENDED that in this case the ingress node 561 uses small intervals, under the condition that the injected 562 traffic does not exceed the capacity of the forward data path. 563 The value of the interval MUST be reported. 565 o The accuracy of PRFD is also dependent on the time needed to 566 propagate the error free signal from the ingress node to the 567 egress node. A typical value of propagating the error free signal 568 from the ingress node to the egress node under the same 569 measurement setup MAY be reported. The methodology to obtain such 570 values is outside the scope of this document. 572 o If error free signal is received before PATH message is sent, an 573 error MUST be reported and the measurement SHOULD terminate. 575 o If the LSP setup fails, PRFD MUST NOT be counted. 577 o This metric SHOULD be used together with RRFD. It is RECOMMENDED 578 that PRFD measurement is carried out after a negetive RRFD value 579 has already been observed. 581 7.7. Methodologies 583 Generally the methodology would proceed as follows: 585 o Make sure that the network has enough resource to set up the 586 requested LSPs. 588 o Start the data path measurement and/or monitoring procedures on 589 the ingress node and egress node. If error free signal is 590 received by the egress node before PATH message is sent, report an 591 error and terminate the mmeasurement. 593 o At the ingress node, form the PATH message according to the LSP 594 requirements and send the message towards the egress node. 596 o Upon receiving the last bit of the PATH message, take the time 597 stamp (T1) on the egress node as soon as possible. 599 o When an error free signal is observed on the egress node, take the 600 time stamp (T2) as soon as possible. An estimate of PRFD (T2-T1) 601 can be computed. 603 o If the LSP setup fails, PRFD is not counted. 605 o If no error free signal is received within a reasonable period of 606 time by the egress node, PRFD is deemed to be undefined. 608 8. A Definition for Samples of Data Path Delay 610 In Section Section 5, Section 6 and Section 7, we define the 611 singleton metrics of data path delay. Now we define how to get one 612 particular sample of such delay. Sampling is to select a particular 613 potion of singleton values of the given parameters. Like in 614 [RFC2330], we use Poisson sampling as an example. 616 8.1. Metric Name 618 Type Data path delay sample, where X is either RRFD, RSRD or 619 PRFD. 621 8.2. Metric Parameters 623 o ID0, the ingress LSR ID 625 o ID1, the egress LSR ID 627 o T0, a time 629 o Tf, a time 631 o Lambda, a rate in the reciprocal seconds 633 o Th, LSP holding time 635 o Td, the maximum waiting time for successful LSP setup 637 o Ts, the maximum waiting time for error free signal 639 8.3. Metric Units 641 A sequence of pairs; the elements of each pair are: 643 o T, a time when setup is attempted 645 o dT, either a real number of milli-seconds or undefined 647 8.4. Definition 649 Given T0, Tf, and lambda, compute a pseudo-random Poisson process 650 beginning at or before T0, with average arrival rate lambda, and 651 ending at or after Tf. Those time values greater than or equal to T0 652 and less than or equal to Tf are then selected. At each of the times 653 in this process, we obtain the value of data path delay sample of 654 type at this time. The value of the sample is the sequence made 655 up of the resulting data path delay> pairs. If there 656 are no such pairs, the sequence is of length zero and the sample is 657 said to be empty. 659 8.5. Discussion 661 The following issues are likely to come up in practice: 663 o The parameters lambda, Th and Td should be carefully chosen, as 664 explained in the discussions for LSP setup delay. 666 o The parameter Ts should be carefully chosen and MUST be reported 667 along with the LSP forward/reverse data path delay sample. 669 o Note that for online or passive measurements, the holding time of 670 an LSP is determined by actual traffic, hence in this case Th is 671 not an input parameter. 673 8.6. Methodologies 675 Generally the methodology would proceed as follows: 677 o The selection of specific times, using the specified Poisson 678 arrival process, and 680 o Set up the LSP and obtain the value of type data path delay 682 o Release the LSP after Th, and wait for the next Poisson arrival 683 process 685 8.7. Typical testing cases 687 8.7.1. With No LSP in the Network 689 8.7.1.1. Motivation 691 Data path delay with no LSP in the network is important because this 692 reflects the inherent delay of a device implementation. The minimum 693 value provides an indication of the delay that will likely be 694 experienced when an LSP data path is configured under light traffic 695 load. 697 8.7.1.2. Methodologies 699 Make sure that there is no LSP in the network, and proceed with the 700 methodologies described in Section 8.6. 702 8.7.2. With a Number of LSPs in the Network 704 8.7.2.1. Motivation 706 Data path delay with a number of LSPs in the network is important 707 because it reflects the performance of an operational network with 708 considerable load. This delay may vary significantly as the number 709 of existing LSPs varies. It can be used as a scalability metric of a 710 device implementation. 712 8.7.2.2. Methodologies 714 Setup the required number of LSPs, and wait until the network reaches 715 a stable state, and then proceed with the methodologies described in 716 Section 8.6. 718 9. Some Statistics Definitions for Metrics to Report 720 Given the samples of the performance metric, we now offer several 721 statistics of these samples to report. From these statistics, we can 722 draw some useful conclusions of a GMPLS network. The value of these 723 metrics is either a real number, or an undefined number of 724 milliseconds. In the following discussion, we only consider the 725 finite values. 727 9.1. The Minimum of Metric 729 The minimum of metric is the minimum of all the dT values in the 730 sample. In computing this, undefined values SHOULD be treated as 731 infinitely large. Note that this means that the minimum could thus 732 be undefined if all the dT values are undefined. In addition, the 733 metric minimum SHOULD be set to undefined if the sample is empty. 735 9.2. The Median of Metric 737 Metric median is the median of the dT values in the given sample. In 738 computing the median, the undefined values MUST NOT be counted in. 740 9.3. The percentile of Metric 742 Given a metric and a percent X between 0% and 100%, the Xth 743 percentile of all the dT values in the sample. In addition, the 744 percentile is undefined if the sample is empty. 746 Example: suppose we take a sample and the results are: Stream1 = 747 <, , , , 748 >. Then the 50th percentile would be 110 msec, since 90 749 msec and 100 msec are smaller, and 110 and 500 msec are larger 750 (undefined values are not counted in). 752 9.4. The Failure Probability 754 In the process of LSP setup/release, it may fail for some reason. 755 The failure probability is the ratio of the unsuccessful times to the 756 total times. 758 10. Security Considerations 760 In the control plane, since the measurement endpoints must be 761 conformant to signaling specifications and behave as normal signaling 762 endpoints, it will not incur other security issues than normal LSP 763 provisioning. However, the measurement parameters must be carefully 764 selected so that the measurements inject trivial amounts of 765 additional traffic into the networks they measure. If they inject 766 "too much" traffic, they can skew the results of the measurement, and 767 in extreme cases cause congestion and denial of service. 769 In the data plane, the measurement endpoint MUST use a signal that is 770 consistent with what is specified in the control plane. For example, 771 in a packet switched case, the traffic injected into the data plane 772 MUST NOT exceed the specified rate in the corresponding LSP setup 773 request. In a wavelength switched case, the measurement endpoint 774 MUST use the specified or negotiated lambda with appropriate power. 776 The security considerations pertaining to the original RSVP protocol 777 [RFC2205] and its TE extensions [RFC3209] also remain relevant. 779 11. IANA Considerations 781 This document makes no requests for IANA action. 783 12. Acknowledgements 785 We wish to thank Adrian Farrel and Lou Berger for their comments and 786 helps. 788 This document contains ideas as well as text that have appeared in 789 existing IETF documents. The authors wish to thank G. Almes, S. 790 Kalidindi and M. Zekauskas. 792 We also wish to thank Weisheng Hu, Yaohui Jin and Wei Guo in the 793 state key laboratory of advanced optical communication systems and 794 networks for the valuable comments. We also wish to thank the 795 support from NSFC and 863 program of China. 797 13. References 799 13.1. Normative References 801 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 802 Requirement Levels", BCP 14, RFC 2119, March 1997. 804 [RFC2205] Braden, B., Zhang, L., Berson, S., Herzog, S., and S. 805 Jamin, "Resource ReSerVation Protocol (RSVP) -- Version 1 806 Functional Specification", RFC 2205, September 1997. 808 [RFC2679] Almes, G., Kalidindi, S., and M. Zekauskas, "A One-way 809 Delay Metric for IPPM", RFC 2679, September 1999. 811 [RFC2681] Almes, G., Kalidindi, S., and M. Zekauskas, "A Round-trip 812 Delay Metric for IPPM", RFC 2681, September 1999. 814 [RFC3209] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V., 815 and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP 816 Tunnels", RFC 3209, December 2001. 818 13.2. Informative References 820 [I-D.ietf-ccamp-lsp-dppm] 821 Sun, W., Zhang, G., Gao, J., Xie, G., Papneja, R., Gu, B., 822 Wei, X., Otani, T., and R. Jing, "Label Switched Path 823 (LSP) Dynamic Provisioning Performance Metrics in 824 Generalized MPLS Networks", draft-ietf-ccamp-lsp-dppm-10 825 (work in progress), October 2009. 827 [I-D.shiomoto-ccamp-switch-programming] 828 Shiomoto, K. and A. Farrel, "Advice on When It is Safe to 829 Start Sending Data on Label Switched Paths Established 830 Using RSVP-TE", draft-shiomoto-ccamp-switch-programming-01 831 (work in progress), October 2009. 833 [RFC2330] Paxson, V., Almes, G., Mahdavi, J., and M. Mathis, 834 "Framework for IP Performance Metrics", RFC 2330, 835 May 1998. 837 Authors' Addresses 839 Weiqiang Sun, Editor 840 Shanghai Jiao Tong University 841 800 Dongchuan Road 842 Shanghai 200240 843 China 845 Phone: +86 21 3420 5359 846 Email: sunwq@mit.edu 848 Guoying Zhang, Editor 849 China Academy of Telecommunication Research, MIIT, China. 850 No.11 YueTan South Street 851 Beijing 100045 852 China 854 Phone: +86 1068094272 855 Email: zhangguoying@mail.ritt.com.cn 857 Jianhua Gao 858 Huawei Technologies Co., LTD. 859 China 861 Phone: +86 755 28973237 862 Email: gjhhit@huawei.com 864 Guowu Xie 865 University of California, Riverside 866 900 University Ave. 867 Riverside, CA 92521 868 USA 870 Phone: +1 951 237 8825 871 Email: xieg@cs.ucr.edu 873 Rajiv Papneja 874 Isocore 875 12359 Sunrise Valley Drive, STE 100 876 Reston, VA 20190 877 USA 879 Phone: +1 703 860 9273 880 Email: rpapneja@isocore.com 882 Contributors 884 Bin Gu 885 IXIA 886 Oriental Kenzo Plaza 8M, 48 Dongzhimen Wai Street, Dongcheng District 887 Beijing 200240 888 China 890 Phone: +86 13611590766 891 Email: BGu@ixiacom.com 893 Xueqin Wei 894 Fiberhome Telecommunication Technology Co., Ltd. 895 Wuhan 896 China 898 Phone: +86 13871127882 899 Email: xqwei@fiberhome.com.cn 901 Tomohiro Otani 902 KDDI R&D Laboratories, Inc. 903 2-1-15 Ohara Kamifukuoka Saitama 904 356-8502 905 Japan 907 Phone: +81-49-278-7357 908 Email: otani@kddilabs.jp 910 Ruiquan Jing 911 China Telecom Beijing Research Institute 912 118 Xizhimenwai Avenue 913 Beijing 100035 914 China 916 Phone: +86-10-58552000 917 Email: jingrq@ctbri.com.cn