idnits 2.17.1 draft-ietf-ccamp-dpm-08.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. 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 date (September 1, 2012) is 4226 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) ** Obsolete normative reference: RFC 2679 (Obsoleted by RFC 7679) Summary: 1 error (**), 0 flaws (~~), 1 warning (==), 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: Standards Track G. Zhang, Ed. 5 Expires: March 5, 2013 CATR 6 September 1, 2012 8 Label Switched Path (LSP) Data Path Delay Metrics in Generalized MPLS/ 9 MPLS-TE Networks 10 draft-ietf-ccamp-dpm-08.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 LSP users or 19 applications that control their use as indication that data path has 20 become usable. The existence of the inconsistency between the 21 signaling messages and cross connection programing, and the possible 22 failure of cross connection programming, if not properly treated, 23 will result in data loss or even application failure. 24 Characterization of this performance can thus help designers to 25 improve the way in which LSPs are used and to make applications or 26 tools that depend on and use LSPs more robust. This document defines 27 a series of performance metrics to evaluate the connectivity of data 28 path in the signaling process. 30 Status of this Memo 32 This Internet-Draft is submitted in full conformance with the 33 provisions of BCP 78 and BCP 79. 35 Internet-Drafts are working documents of the Internet Engineering 36 Task Force (IETF). Note that other groups may also distribute 37 working documents as Internet-Drafts. The list of current Internet- 38 Drafts is at http://datatracker.ietf.org/drafts/current/. 40 Internet-Drafts are draft documents valid for a maximum of six months 41 and may be updated, replaced, or obsoleted by other documents at any 42 time. It is inappropriate to use Internet-Drafts as reference 43 material or to cite them other than as "work in progress." 45 This Internet-Draft will expire on March 5, 2013. 47 Copyright Notice 48 Copyright (c) 2012 IETF Trust and the persons identified as the 49 document authors. All rights reserved. 51 This document is subject to BCP 78 and the IETF Trust's Legal 52 Provisions Relating to IETF Documents 53 (http://trustee.ietf.org/license-info) in effect on the date of 54 publication of this document. Please review these documents 55 carefully, as they describe your rights and restrictions with respect 56 to this document. Code Components extracted from this document must 57 include Simplified BSD License text as described in Section 4.e of 58 the Trust Legal Provisions and are provided without warranty as 59 described in the Simplified BSD License. 61 Table of Contents 63 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 5 65 2. Conventions Used in This Document . . . . . . . . . . . . . . 6 67 3. Overview of Performance Metrics . . . . . . . . . . . . . . . 7 69 4. Terms used in this document . . . . . . . . . . . . . . . . . 8 71 5. A singleton Definition for RRFD . . . . . . . . . . . . . . . 9 72 5.1. Motivation . . . . . . . . . . . . . . . . . . . . . . . . 9 73 5.2. Metric Name . . . . . . . . . . . . . . . . . . . . . . . 9 74 5.3. Metric Parameters . . . . . . . . . . . . . . . . . . . . 9 75 5.4. Metric Units . . . . . . . . . . . . . . . . . . . . . . . 9 76 5.5. Definition . . . . . . . . . . . . . . . . . . . . . . . . 9 77 5.6. Discussion . . . . . . . . . . . . . . . . . . . . . . . . 10 78 5.7. Methodologies . . . . . . . . . . . . . . . . . . . . . . 11 80 6. A singleton Definition for RSRD . . . . . . . . . . . . . . . 12 81 6.1. Motivation . . . . . . . . . . . . . . . . . . . . . . . . 12 82 6.2. Metric Name . . . . . . . . . . . . . . . . . . . . . . . 12 83 6.3. Metric Parameters . . . . . . . . . . . . . . . . . . . . 12 84 6.4. Metric Units . . . . . . . . . . . . . . . . . . . . . . . 12 85 6.5. Definition . . . . . . . . . . . . . . . . . . . . . . . . 13 86 6.6. Discussion . . . . . . . . . . . . . . . . . . . . . . . . 13 87 6.7. Methodologies . . . . . . . . . . . . . . . . . . . . . . 14 89 7. A singleton Definition for PRFD . . . . . . . . . . . . . . . 15 90 7.1. Motivation . . . . . . . . . . . . . . . . . . . . . . . . 15 91 7.2. Metric Name . . . . . . . . . . . . . . . . . . . . . . . 15 92 7.3. Metric Parameters . . . . . . . . . . . . . . . . . . . . 15 93 7.4. Metric Units . . . . . . . . . . . . . . . . . . . . . . . 15 94 7.5. Definition . . . . . . . . . . . . . . . . . . . . . . . . 15 95 7.6. Discussion . . . . . . . . . . . . . . . . . . . . . . . . 16 96 7.7. Methodologies . . . . . . . . . . . . . . . . . . . . . . 17 98 8. A singleton Definition for PSFD . . . . . . . . . . . . . . . 18 99 8.1. Motivation . . . . . . . . . . . . . . . . . . . . . . . . 18 100 8.2. Metric Name . . . . . . . . . . . . . . . . . . . . . . . 18 101 8.3. Metric Parameters . . . . . . . . . . . . . . . . . . . . 18 102 8.4. Metric Units . . . . . . . . . . . . . . . . . . . . . . . 18 103 8.5. Definition . . . . . . . . . . . . . . . . . . . . . . . . 18 104 8.6. Discussion . . . . . . . . . . . . . . . . . . . . . . . . 19 105 8.7. Methodologies . . . . . . . . . . . . . . . . . . . . . . 20 107 9. A singleton Definition for PSRD . . . . . . . . . . . . . . . 21 108 9.1. Motivation . . . . . . . . . . . . . . . . . . . . . . . . 21 109 9.2. Metric Name . . . . . . . . . . . . . . . . . . . . . . . 21 110 9.3. Metric Parameters . . . . . . . . . . . . . . . . . . . . 21 111 9.4. Metric Units . . . . . . . . . . . . . . . . . . . . . . . 21 112 9.5. Definition . . . . . . . . . . . . . . . . . . . . . . . . 21 113 9.6. Discussion . . . . . . . . . . . . . . . . . . . . . . . . 22 114 9.7. Methodologies . . . . . . . . . . . . . . . . . . . . . . 23 116 10. A Definition for Samples of Data Path Delay . . . . . . . . . 24 117 10.1. Metric Name . . . . . . . . . . . . . . . . . . . . . . . 24 118 10.2. Metric Parameters . . . . . . . . . . . . . . . . . . . . 24 119 10.3. Metric Units . . . . . . . . . . . . . . . . . . . . . . . 24 120 10.4. Definition . . . . . . . . . . . . . . . . . . . . . . . . 24 121 10.5. Discussion . . . . . . . . . . . . . . . . . . . . . . . . 25 122 10.6. Methodologies . . . . . . . . . . . . . . . . . . . . . . 25 123 10.7. Typical testing cases . . . . . . . . . . . . . . . . . . 25 124 10.7.1. With No LSP in the Network . . . . . . . . . . . . . 25 125 10.7.2. With a Number of LSPs in the Network . . . . . . . . 25 127 11. Some Statistics Definitions for Metrics to Report . . . . . . 27 128 11.1. The Minimum of Metric . . . . . . . . . . . . . . . . . . 27 129 11.2. The Median of Metric . . . . . . . . . . . . . . . . . . . 27 130 11.3. The percentile of Metric . . . . . . . . . . . . . . . . . 27 131 11.4. The Failure Probability . . . . . . . . . . . . . . . . . 27 132 11.4.1. Failure Count . . . . . . . . . . . . . . . . . . . . 28 133 11.4.2. Failure Ratio . . . . . . . . . . . . . . . . . . . . 28 135 12. Security Considerations . . . . . . . . . . . . . . . . . . . 29 137 13. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 30 139 14. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 31 141 15. References . . . . . . . . . . . . . . . . . . . . . . . . . . 32 142 15.1. Normative References . . . . . . . . . . . . . . . . . . . 32 143 15.2. Informative References . . . . . . . . . . . . . . . . . . 32 145 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 33 147 1. Introduction 149 Label Switched Paths (LSPs) are established, controlled, and 150 allocated for use by management tools or directly by the components 151 that use them. In this document we call such management tools and 152 the components that use LSPs "applications". Such applications may 153 be Network Management Stations (NMSs), hardware or software 154 components that forward data onto virtual links, programs or tools 155 that use dedicated links, or any other user of an LSP. 157 Ideally, the completion of the signaling process means that the 158 signaled LSP is ready to carry traffic. However, in actual 159 implementations, vendors may choose to program the cross connection 160 in a pipelined manner, so that the overall LSP provisioning delay can 161 be reduced. In such situations, the data path may not be ready for 162 use instantly after the signaling process completes. Implementation 163 deficiency may also cause the inconsistency in between the signaling 164 process and data path provisioning. For example, if the data plane 165 fails to program the cross connection accordingly but does not manage 166 to report this to the control plane, the signaling process may 167 complete successfully while the corresponding data path will never 168 become functional at all. 170 On the other hand, the completion of the signaling process may be 171 used in many cases as indication of data path connectivity. For 172 example, when invoking through User Network Interface (UNI) 173 [RFC4208], a client device or an application may use the reception of 174 the correct RESV message as indication that data path is fully 175 functional and start to transmit traffic. This will result in data 176 loss or even application failure. 178 Although RSVP(-TE) specifications have suggested that the cross 179 connections are programmed before signaling messages are propagated 180 upstream, it is still worthwhile to verify the conformance of an 181 implementation and measure the delay, when necessary. 183 This document defines a series of performance metrics to evaluate the 184 connectivity of data path during the signaling process. The metrics 185 defined in this document complement the control plane metrics defined 186 in [RFC5814]. These metrics can be used to verify the conformance of 187 implementations against related specifications, as elaborated in 188 [RFC6383]. They also can be used to build more robust applications. 190 2. Conventions Used in This Document 192 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 193 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 194 document are to be interpreted as described in [RFC2119]. 196 3. Overview of Performance Metrics 198 In this memo, we define five performance metrics to characterize the 199 performance of data path provisioning with GMPLS/MPLS-TE signaling. 200 These metrics complement the metrics defined in [RFC5814], in the 201 sense that the completion of the signaling process for a Label 202 Switched Path (LSP) and the programming of cross connections along 203 the LSP may not be consistent. The performance metrics in [RFC5814] 204 characterize the performance of LSP provisioning from the pure 205 signaling point of view, while the metric in this document takes into 206 account the validity of the data path. 208 The five metrics are: 210 o RRFD - the delay between RESV message received by ingress node and 211 forward data path becomes ready for use. 213 o RSRD - the delay between RESV message sent by egress node and 214 reverse data path becomes ready for use. 216 o PRFD - the delay between PATH message received by egress node and 217 forward data path becomes ready for use. 219 o PSFD - the delay between PATH message sent by ingress and forward 220 data path becomes ready for use. 222 o PSRD - the delay between PATH message sent by ingress and reverse 223 data path becomes ready for use. 225 As in [RFC5814], we continue to use the structures and notions 226 introduced and discussed in the IPPM Framework document, [RFC2330] 227 [RFC2679] [RFC2681]. The reader is assumed to be familiar with the 228 notions in those documents. The readers are assumed to be familiar 229 with the definitions in [RFC5814] as well. 231 4. Terms used in this document 233 o Forward data path - the data path from the ingress to the egress. 234 Instances of forward data path include the data path of a uni- 235 directional LSP and data path from the ingress node to the egress 236 node in a bidirectional LSP. 238 o Reverse data path - the data path from the egress node to the 239 ingress node in a bidirectional LSP. 241 o Data path delay - the time needed to complete the data path 242 configuration, in relation to the signaling process. Five types 243 of data path delay are defined in this document, namely RRFD, 244 RSRD, PRFD, PSFD and PSRD. Data path delay used in this document 245 must be distinguished from the transmission delay along the data 246 path, i.e., the time needed to transmit traffic from one side of 247 the data path to the other. 249 o Error free signal - data plane specific indication of connectivity 250 of the data path. For example, for packet switching capable 251 interfaces, the reception of the first error free packet from one 252 side of the LSP to the other may be used as the error free signal. 253 For SDH/SONET cross connects, the disappearance of alarm can be 254 used as the error free signal. Through out this document, we will 255 use the "error free signal" as a general term. An implementations 256 must choose a proper data path signal that is specific to the data 257 path technology being tested. 259 o Ingress/egress node - in this memo, an ingress/egress node means a 260 measurement endpoint with both control plane and data plane 261 features. Typically, the control plane part on an ingress/egress 262 node interact with the control plane of the network under test. 263 The data plane part of an ingress/egress node will generate data 264 path signals and send the signal to the data plane of the network 265 under test, or receive data path signals from the network under 266 test. 268 5. A singleton Definition for RRFD 270 This part defines a metric for forward data path delay when an LSP is 271 setup. 273 As described in [RFC6383], the completion of the RSVP-TE signaling 274 process does not necessarily mean that the cross connections along 275 the LSP being setup are in place and ready to carry traffic. This 276 metric defines the time difference between the reception of RESV 277 message by the ingress node and the completion of the cross 278 connection programming along the forward data path. 280 5.1. Motivation 282 RRFD is useful for several reasons: 284 o For the reasons described in [RFC6383], the data path may not be 285 ready for use instantly after the completion of the RSVP-TE 286 signaling process. The delay itself is part of the implementation 287 performance. 289 o The completion of the signaling process may be used by application 290 designers as indication of data path connectivity. The existence 291 of this delay and the potential failure of cross connection 292 programming, if not properly treated, will result in data loss or 293 application failure. The typical value of this delay can thus 294 help designers to improve the application model. 296 5.2. Metric Name 298 RRFD = RESV Received, Forward Data path 300 5.3. Metric Parameters 302 o ID0, the ingress LSR ID 304 o ID1, the egress LSR ID 306 o T, a time when the setup is attempted 308 5.4. Metric Units 310 Either a real number of milli-seconds or undefined. 312 5.5. Definition 314 For a real number dT, RRFD from ingress node ID0 to egress node ID1 315 at T is dT means that ingress node ID0 send a PATH message to egress 316 node ID1 and the last bit of the corresponding RESV message is 317 received by ingress node ID0 at T, and an error free signal is 318 received by egress node ID1 by using a data plane specific test 319 pattern at T+dT. 321 5.6. Discussion 323 The following issues are likely to come up in practice: 325 o The accuracy of RRFD depends on the clock resolution of both the 326 ingress node and egress node. Clock synchronization between the 327 ingress node and egress node is required. 329 o The accuracy of RRFD is also dependent on how the error free 330 signal is received and may differ significantly when the underline 331 data plane technology is different. For instance, for an LSP 332 between a pair of Ethernet interfaces, the ingress node may use a 333 rate based method to verify the connectivity of the data path and 334 use the reception of the first error free frame as the error free 335 signal. In this case, the interval between two successive frames 336 has a significant impact on accuracy. It is RECOMMENDED that the 337 ingress node uses small intervals, under the condition that the 338 injected traffic does not exceed the capacity of the forward data 339 path. The value of such intervals MUST be reported. 341 o The accuracy of RRFD is also dependent on the time needed to 342 propagate the error free signal from the ingress node to the 343 egress node. A typical value of propagating the error free signal 344 from the ingress node to the egress node under the same 345 measurement setup MAY be reported. The methodology to obtain such 346 values is outside the scope of this document. 348 o The accuracy of this metric is also dependent on the physical 349 layer serialization/de-serialization of the test signal for 350 certain data path technologies. For instance, for an LSP between 351 a pair of low speed Ethernet interfaces, the time needed to 352 serialize/deserialize a large frame may not be negligible. In 353 this case, it is RECOMMENDED that the ingress node uses small 354 frames. The average length of the frame MAY be reported. 356 o It is possible that under some implementations, a node may program 357 the cross connection before it sends PATH message further 358 downstream and the data path may be ready for use before a RESV 359 message reaches the ingress node. In such cases, RRFD can be a 360 negative value. It is RECOMMENDED that PRFD measurement is 361 carried out to further characterize the forward data path delay 362 when a negative RRFD value is observed. 364 o If error free signal is received by the egress node before PATH 365 message is sent on the ingress node, an error MUST be reported and 366 the measurement SHOULD terminate. 368 o If the corresponding RESV message is received, but no error free 369 signal is received by the egress node within a reasonable period 370 of time, i.e., a threshold, RRFD MUST be treated as undefined. 371 The value of the threshold MUST be reported. 373 o If the LSP setup fails, the metric value MUST NOT be counted. 375 5.7. Methodologies 377 Generally the methodology would proceed as follows: 379 o Make sure that the network has enough resource to set up the 380 requested LSP. 382 o Start the data path measurement and/or monitoring procedures on 383 the ingress node and egress node. If error free signal is 384 received by the egress node before PATH message is sent, report an 385 error and terminate the measurement. 387 o At the ingress node, form the PATH message according to the LSP 388 requirements and send the message towards the egress node. 390 o Upon receiving the last bit of the corresponding RESV message, 391 take the time stamp (T1) on the ingress node as soon as possible. 393 o When an error free signal is observed on the egress node, take the 394 time stamp (T2) as soon as possible. An estimate of RRFD (T2 - 395 T1) can be computed. 397 o If the corresponding RESV message arrives, but no error free 398 signal is received within a reasonable period of time by the 399 ingress node, RRFD is deemed to be undefined. 401 o If the LSP setup fails, RRFD is not counted. 403 6. A singleton Definition for RSRD 405 This part defines a metric for reverse data path delay when an LSP is 406 setup. 408 As described in [RFC6383], the completion of the RSVP-TE signaling 409 process does not necessarily mean that the cross connections along 410 the LSP being setup are in place and ready to carry traffic. This 411 metric defines the time difference between the completion of the 412 signaling process and the completion of the cross connection 413 programming along the reverse data path. This metric MAY be used 414 together with RRFD to characterize the data path delay of a 415 bidirectional LSP. 417 6.1. Motivation 419 RSRD is useful for several reasons: 421 o For the reasons described in [RFC6383], the data path may not be 422 ready for use instantly after the completion of the RSVP-TE 423 signaling process. The delay itself is part of the implementation 424 performance. 426 o The completion of the signaling process may be used by application 427 designers as indication of data path connectivity. The existence 428 of this delay and the possible failure of cross connection 429 programming, if not properly treated, will result in data loss or 430 application failure. The typical value of this delay can thus 431 help designers to improve the application model. 433 6.2. Metric Name 435 RSRD = RESV sent, Reverse Data path 437 6.3. Metric Parameters 439 o ID0, the ingress LSR ID 441 o ID1, the egress LSR ID 443 o T, a time when the setup is attempted 445 6.4. Metric Units 447 Either a real number of milli-seconds or undefined. 449 6.5. Definition 451 For a real number dT, RSRD from ingress node ID0 to egress node ID1 452 at T is dT means that ingress node ID0 send a PATH message to egress 453 node ID1 and the last bit of the corresponding RESV message is sent 454 by egress node ID1 at T, and an error free signal is received by the 455 ingress node ID0 using a data plane specific test pattern at T+dT. 457 6.6. Discussion 459 The following issues are likely to come up in practice: 461 o The accuracy of RSRD depends on the clock resolution of both the 462 ingress node and egress node. And clock synchronization between 463 the ingress node and egress node is required. 465 o The accuracy of RSRD is also dependent on how the error free 466 signal is received and may differ significantly when the underline 467 data plane technology is different. For instance, for an LSP 468 between a pair of Ethernet interfaces, the egress node (sometimes 469 the tester) may use a rate based method to verify the connectivity 470 of the data path and use the reception of the first error free 471 frame as the error free signal. In this case, the interval 472 between two successive frames has a significant impact on 473 accuracy. It is RECOMMENDED that in this case the egress node 474 uses small intervals, under the condition that the injected 475 traffic does not exceed the capacity of the reverse data path. 476 The value of the interval MUST be reported. 478 o The accuracy of RSRD is also dependent on the time needed to 479 propagate the error free signal from the egress node to the 480 ingress node. A typical value of propagating the error free 481 signal from the egress node to the ingress node under the same 482 measurement setup MAY be reported. The methodology to obtain such 483 values is outside the scope of this document. 485 o The accuracy of this metric is also dependent on the physical 486 layer serialization/de-serialization of the test signal for 487 certain data path technologies. For instance, for an LSP between 488 a pair of low speed Ethernet interfaces, the time needed to 489 serialize/deserialize a large frame may not be negligible. In 490 this case, it is RECOMMENDED that the egress node uses small 491 frames. The average length of the frame MAY be reported. 493 o If the corresponding RESV message is sent, but no error free 494 signal is received by the ingress node within a reasonable period 495 of time, i.e., a threshold, RSRD MUST be treated as undefined. 496 The value of the threshold MUST be reported. 498 o If error free signal is received before PATH message is sent on 499 the ingress node, an error MUST be reported and the measurement 500 SHOULD terminate. 502 o If the LSP setup fails, the metric value MUST NOT be counted. 504 6.7. Methodologies 506 Generally the methodology would proceed as follows: 508 o Make sure that the network has enough resource to set up the 509 requested LSP. 511 o Start the data path measurement and/or monitoring procedures on 512 the ingress node and egress node. If error free signal is 513 received by the ingress node before PATH message is sent, report 514 an error and terminate the measurement. 516 o At the ingress node, form the PATH message according to the LSP 517 requirements and send the message towards the egress node. 519 o Upon sending the last bit of the corresponding RESV message, take 520 the time stamp (T1) on the egress node as soon as possible. 522 o When an error free signal is observed on the ingress node, take 523 the time stamp (T2) as soon as possible. An estimate of RSRD 524 (T2-T1) can be computed. 526 o If the LSP setup fails, RSRD is not counted. 528 o If no error free signal is received within a reasonable period of 529 time by the ingress node, RSRD is deemed to be undefined. 531 7. A singleton Definition for PRFD 533 This part defines a metric for forward data path delay when an LSP is 534 setup. 536 In an RSVP-TE implementation, when setting up an LSP, each node may 537 choose to program the cross connection before it sends PATH message 538 further downstream. In this case, the forward data path may become 539 ready for use before the signaling process completes, ie. before the 540 RESV reaches the ingress node. This metric can be used to identify 541 such implementation practice and give useful information to 542 application designers. 544 7.1. Motivation 546 PRFD is useful for the following reasons: 548 o PRFD can be used to identify an RSVP-TE implementation practice, 549 in which cross connections are programmed before PATH message is 550 sent downtream. 552 o The value of PRFD may also help application designers to fine tune 553 their application model. 555 7.2. Metric Name 557 PRFD = PATH received, Forward Data path 559 7.3. Metric Parameters 561 o ID0, the ingress LSR ID 563 o ID1, the egress LSR ID 565 o T, a time when the setup is attempted 567 7.4. Metric Units 569 Either a real number of milli-seconds or undefined. 571 7.5. Definition 573 For a real number dT, PRFD from ingress node ID0 to egress node ID1 574 at T is dT means that ingress node ID0 send a PATH message to egress 575 node ID1 and the last bit of the PATH message is received by egress 576 node ID1 at T, and an error free signal is received by the egress 577 node ID1 using a data plane specific test pattern at T+dT. 579 7.6. Discussion 581 The following issues are likely to come up in practice: 583 o The accuracy of PRFD depends on the clock resolution of the egress 584 node. And clock synchronization between the ingress node and 585 egress node is not required. 587 o The accuracy of PRFD is also dependent on how the error free 588 signal is received and may differ significantly when the underline 589 data plane technology is different. For instance, for an LSP 590 between a pair of Ethernet interfaces, the egress node (sometimes 591 the tester) may use a rate based method to verify the connectivity 592 of the data path and use the reception of the first error free 593 frame as the error free signal. In this case, the interval 594 between two successive frames has a significant impact on 595 accuracy. It is RECOMMENDED that in this case the ingress node 596 uses small intervals, under the condition that the injected 597 traffic does not exceed the capacity of the forward data path. 598 The value of the interval MUST be reported. 600 o The accuracy of PRFD is also dependent on the time needed to 601 propagate the error free signal from the ingress node to the 602 egress node. A typical value of propagating the error free signal 603 from the ingress node to the egress node under the same 604 measurement setup MAY be reported. The methodology to obtain such 605 values is outside the scope of this document. 607 o The accuracy of this metric is also dependent on the physical 608 layer serialization/de-serialization of the test signal for 609 certain data path technologies. For instance, for an LSP between 610 a pair of low speed Ethernet interfaces, the time needed to 611 serialize/deserialize a large frame may not be negligible. In 612 this case, it is RECOMMENDED that the ingress node uses small 613 frames. The average length of the frame MAY be reported. 615 o If error free signal is received before PATH message is sent, an 616 error MUST be reported and the measurement SHOULD terminate. 618 o If the LSP setup fails, the metric value MUST NOT be counted. 620 o This metric SHOULD be used together with RRFD. It is RECOMMENDED 621 that PRFD measurement is carried out after a negetive RRFD value 622 has already been observed. 624 7.7. Methodologies 626 Generally the methodology would proceed as follows: 628 o Make sure that the network has enough resource to set up the 629 requested LSP. 631 o Start the data path measurement and/or monitoring procedures on 632 the ingress node and egress node. If error free signal is 633 received by the egress node before PATH message is sent, report an 634 error and terminate the measurement. 636 o At the ingress node, form the PATH message according to the LSP 637 requirements and send the message towards the egress node. 639 o Upon receiving the last bit of the PATH message, take the time 640 stamp (T1) on the egress node as soon as possible. 642 o When an error free signal is observed on the egress node, take the 643 time stamp (T2) as soon as possible. An estimate of PRFD (T2-T1) 644 can be computed. 646 o If the LSP setup fails, PRFD is not counted. 648 o If no error free signal is received within a reasonable period of 649 time by the egress node, PRFD is deemed to be undefined. 651 8. A singleton Definition for PSFD 653 This part defines a metric for forward data path delay when an LSP is 654 setup. 656 As described in [RFC6383], the completion of the RSVP-TE signaling 657 process does not necessarily mean that the cross connections along 658 the LSP being setup are in place and ready to carry traffic. This 659 metric defines the time from the PATH message sent by the ingress 660 node, till the completion of the cross connection programming along 661 the LSP forward data path. 663 8.1. Motivation 665 PSFD is useful for the following reasons: 667 o For the reasons described in [RFC6383], the data path setup delay 668 may not be consistent with the control plane LSP setup delay. The 669 data path setup delay metric is more precise for LSP setup 670 performance measurement. 672 o The completion of the signaling process may be used by application 673 designers as indication of data path connectivity. The difference 674 between the control plane setup delay and data path delay, and the 675 potential failure of cross connection programming, if not properly 676 treated, will result in data loss or application failure. This 677 metric can thus help designers to improve the application model. 679 8.2. Metric Name 681 PSFD = Path Sent, Forward Data path 683 8.3. Metric Parameters 685 o ID0, the ingress LSR ID 687 o ID1, the egress LSR ID 689 o T, a time when the setup is attempted 691 8.4. Metric Units 693 Either a real number of milli-seconds or undefined. 695 8.5. Definition 697 For a real number dT, PSFD from ingress node ID0 to egress node ID1 698 at T is dT means that ingress node ID0 sends the first bit of a PATH 699 message to egress node ID1 at T, and an error free signal is received 700 by the egress node ID1 using a data plane specific test pattern at 701 T+dT. 703 8.6. Discussion 705 The following issues are likely to come up in practice: 707 o The accuracy of PSFD depends on the clock resolution of both the 708 ingress node and egress node. And clock synchronization between 709 the ingress node and egress node is required. 711 o The accuracy of this metric is also dependent on how the error 712 free signal is received and may differ significantly when the 713 underlying data plane technology is different. For instance, for 714 an LSP between a pair of Ethernet interfaces, the ingress node may 715 use a rate based method to verify the connectivity of the data 716 path and use the reception of the first error free frame as the 717 error free signal. In this case, the interval between two 718 successive frames has a significant impact on accuracy. It is 719 RECOMMENDED that the ingress node uses small intervals, under the 720 condition that the injected traffic does not exceed the capacity 721 of the forward data path. The value of the interval MUST be 722 reported. 724 o The accuracy of this metric is also dependent on the time needed 725 to propagate the error free signal from the ingress node to the 726 egress node. A typical value of propagating the error free signal 727 from the ingress node to the egress node under the same 728 measurement setup MAY be reported. The methodology to obtain such 729 values is outside the scope of this document. 731 o The accuracy of this metric is also dependent on the physical 732 layer serialization/de-serialization of the test signal for 733 certain data path technologies. For instance, for an LSP between 734 a pair of low speed Ethernet interfaces, the time needed to 735 serialize/deserialize a large frame may not be negligible. In 736 this case, it is RECOMMENDED that the ingress node uses small 737 frames. The average length of the frame MAY be reported. 739 o If error free signal is received before PATH message is sent, an 740 error MUST be reported and the measurement SHOULD terminate. 742 o If the LSP setup fails, the metric value MUST NOT be counted. 744 o If the PATH message is sent by the ingress node, but no error free 745 signal is received by the egress node within a reasonable period 746 of time, i.e., a threshold, the metric value MUST be treated as 747 undefined. The value of the threshold MUST be reported. 749 8.7. Methodologies 751 Generally the methodology would proceed as follows: 753 o Make sure that the network has enough resource to set up the 754 requested LSP. 756 o Start the data path measurement and/or monitoring procedures on 757 the ingress node and egress node. If error free signal is 758 received by the egress node before PATH message is sent, report an 759 error and terminate the measurement. 761 o At the ingress node, form the PATH message according to the LSP 762 requirements and send the message towards the egress node. A 763 timestamp (T1) may be stored locally in the ingress node when the 764 PATH message packet is sent towards the egress node. 766 o When an error free signal is observed on the egress node, take the 767 time stamp (T2) as soon as possible. An estimate of PSFD (T2-T1) 768 can be computed. 770 o If the LSP setup fails, this metric is not counted. 772 o If no error free signal is received within a reasonable period of 773 time by the egress node, PSFD is deemed to be undefined. 775 9. A singleton Definition for PSRD 777 This part defines a metric for reverse data path delay when an LSP is 778 setup. 780 This metric defines the time from the ingress node sends the PATH 781 message, till the completion of the cross connection programming 782 along the LSP reverse data path. This metric MAY be used together 783 with PSFD to characterize the data path delay of a bidirectional LSP. 785 9.1. Motivation 787 PSRD is useful for the following reasons: 789 o For the reasons described in [RFC6383], the data path setup delay 790 may not be consistent with the control plane LSP setup delay. The 791 data path setup delay metric is more precise for LSP setup 792 performance measurement. 794 o The completion of the signaling process may be used by application 795 designers as indication of data path connectivity. The difference 796 between the control plane setup delay and data path delay, and the 797 potential failure of cross connection programming, if not properly 798 treated, will result in data loss or application failure. This 799 metric can thus help designers to improve the application model. 801 9.2. Metric Name 803 PSRD = Path Sent, Reverse Data path 805 9.3. Metric Parameters 807 o ID0, the ingress LSR ID 809 o ID1, the egress LSR ID 811 o T, a time when the setup is attempted 813 9.4. Metric Units 815 Either a real number of milli-seconds or undefined. 817 9.5. Definition 819 For a real number dT, PSRD from ingress node ID0 to egress node ID1 820 at T is dT means that ingress node ID0 sends the first bit of a PATH 821 message to egress node ID1 at T, and an error free signal is received 822 through the reverse data path by the ingress node ID0 using a data 823 plane specific test pattern at T+dT. 825 9.6. Discussion 827 The following issues are likely to come up in practice: 829 o The accuracy of PSRD depends on the clock resolution of the 830 ingress node. And clock synchronization between the ingress node 831 and egress node is not required. 833 o The accuracy of this metric is also dependent on how the error 834 free signal is received and may differ significantly when the 835 underlying data plane technology is different. For instance, for 836 an LSP between a pair of Ethernet interfaces, the egress node may 837 use a rate based method to verify the connectivity of the data 838 path and use the reception of the first error free frame as the 839 error free signal. In this case, the interval between two 840 successive frames has a significant impact on accuracy. It is 841 RECOMMENDED that the egress node uses small intervals, under the 842 condition that the injected traffic does not exceed the capacity 843 of the forward data path. The value of the interval MUST be 844 reported. 846 o The accuracy of this metric is also dependent on the time needed 847 to propagate the error free signal from the egress node to the 848 ingress node. A typical value of propagating the error free 849 signal from the egress node to the ingress node under the same 850 measurement setup MAY be reported. The methodology to obtain such 851 values is outside the scope of this document. 853 o The accuracy of this metric is also dependent on the physical 854 layer serialization/de-serialization of the test signal for 855 certain data path technologies. For instance, for an LSP between 856 a pair of low speed Ethernet interfaces, the time needed to 857 serialize/deserialize a large frame may not be negligible. In 858 this case, it is RECOMMENDED that the egress node uses small 859 frames. The average length of the frame MAY be reported. 861 o If error free signal is received before PATH message is sent, an 862 error MUST be reported and the measurement SHOULD terminate. 864 o If the LSP setup fails, this metric value MUST NOT be counted. 866 o If the PATH message is sent by the ingress node, but no error free 867 signal is received by the ingress node within a reasonable period 868 of time, i.e., a threshold, the metric value MUST be treated as 869 undefined. The value of the threshold MUST be reported. 871 9.7. Methodologies 873 Generally the methodology would proceed as follows: 875 o Make sure that the network has enough resource to set up the 876 requested LSP. 878 o Start the data path measurement and/or monitoring procedures on 879 the ingress node and egress node. If error free signal is 880 received by the egress node before PATH message is sent, report an 881 error and terminate the measurement. 883 o At the ingress node, form the PATH message according to the LSP 884 requirements and send the message towards the egress node. A 885 timestamp (T1) may be stored locally in the ingress node when the 886 PATH message packet is sent towards the egress node. 888 o When an error free signal is observed on the ingress node, take 889 the time stamp (T2) as soon as possible. An estimate of PSFD 890 (T2-T1) can be computed. 892 o If the LSP setup fails, this metric is not counted. 894 o If no error free signal is received within a reasonable period of 895 time by the ingress node, the metric value is deemed to be 896 undefined. 898 10. A Definition for Samples of Data Path Delay 900 In Section 5, Section 6, Section 7, Section 8 and Section 9, we 901 define the singleton metrics of data path delay. Now we define how 902 to get one particular sample of such delay. Sampling is to select a 903 particular portion of singleton values of the given parameters. Like 904 in [RFC2330], we use Poisson sampling as an example. 906 10.1. Metric Name 908 Type Data path delay sample, where X is either RRFD, RSRD, PRFD, 909 PSFD and PSRD. 911 10.2. Metric Parameters 913 o ID0, the ingress LSR ID 915 o ID1, the egress LSR ID 917 o T0, a time 919 o Tf, a time 921 o Lambda, a rate in the reciprocal seconds 923 o Th, LSP holding time 925 o Td, the maximum waiting time for successful LSP setup 927 o Ts, the maximum waiting time for error free signal 929 10.3. Metric Units 931 A sequence of pairs; the elements of each pair are: 933 o T, a time when setup is attempted 935 o dT, either a real number of milli-seconds or undefined 937 10.4. Definition 939 Given T0, Tf, and Lambda, compute a pseudo-random Poisson process 940 beginning at or before T0, with average arrival rate Lambda, and 941 ending at or after Tf. Those time values greater than or equal to T0 942 and less than or equal to Tf are then selected. At each of the times 943 in this process, we obtain the value of data path delay sample of 944 type at this time. The value of the sample is the sequence made 945 up of the resulting data path delay> pairs. If there 946 are no such pairs, the sequence is of length zero and the sample is 947 said to be empty. 949 10.5. Discussion 951 The following issues are likely to come up in practice: 953 o The parameters Lambda, Th and Td should be carefully chosen, as 954 explained in the discussions for LSP setup delay (see [RFC5814]). 956 o The parameter Ts should be carefully chosen and MUST be reported 957 along with the LSP forward/reverse data path delay sample. 959 10.6. Methodologies 961 Generally the methodology would proceed as follows: 963 o The selection of specific times, using the specified Poisson 964 arrival process, and 966 o Set up the LSP and obtain the value of type data path delay 968 o Release the LSP after Th, and wait for the next Poisson arrival 969 process 971 10.7. Typical testing cases 973 10.7.1. With No LSP in the Network 975 10.7.1.1. Motivation 977 Data path delay with no LSP in the network is important because this 978 reflects the inherent delay of a device implementation. The minimum 979 value provides an indication of the delay that will likely be 980 experienced when an LSP data path is configured under light traffic 981 load. 983 10.7.1.2. Methodologies 985 Make sure that there is no LSP in the network, and proceed with the 986 methodologies described in Section 10.6. 988 10.7.2. With a Number of LSPs in the Network 990 10.7.2.1. Motivation 992 Data path delay with a number of LSPs in the network is important 993 because it reflects the performance of an operational network with 994 considerable load. This delay may vary significantly as the number 995 of existing LSPs varies. It can be used as a scalability metric of a 996 device implementation. 998 10.7.2.2. Methodologies 1000 Setup the required number of LSPs, and wait until the network reaches 1001 a stable state, and then proceed with the methodologies described in 1002 Section 10.6. 1004 11. Some Statistics Definitions for Metrics to Report 1006 Given the samples of the performance metric, we now offer several 1007 statistics of these samples to report. From these statistics, we can 1008 draw some useful conclusions of a GMPLS network. The value of these 1009 metrics is either a real number, or an undefined number of 1010 milliseconds. In the following discussion, we only consider the 1011 finite values. 1013 11.1. The Minimum of Metric 1015 The minimum of metric is the minimum of all the dT values in the 1016 sample. In computing this, undefined values SHOULD be treated as 1017 infinitely large. Note that this means that the minimum could thus 1018 be undefined if all the dT values are undefined. In addition, the 1019 metric minimum SHOULD be set to undefined if the sample is empty. 1021 11.2. The Median of Metric 1023 Metric median is the median of the dT values in the given sample. In 1024 computing the median, the undefined values MUST NOT be counted in. 1025 The Median SHOULD be set to undefined if all the dT values are 1026 undefined, or if the sample is empty.When the number of defined 1027 values in the given sample is small, the metric median may not be 1028 typical and SHOULD be used carefully. 1030 11.3. The percentile of Metric 1032 The "empirical distribution function" (EDF) of a set of scalar 1033 measurements is a function F(x) which for any x gives the fractional 1034 proportion of the total measurements that were <= x. 1036 Given a percentage X, the X-th percentile of Metric means the 1037 smallest value of x for which F(x) >= X. In computing the percentile, 1038 undefined values MUST NOT be included. 1040 See [RFC2330] for further details. 1042 11.4. The Failure Probability 1044 Given the samples of the performance metric, we now offer two 1045 statistics of failure events of these samples to report. The two 1046 statistics can be applied to both forward data path and reverse data 1047 path. For example, when a sample of RRFD has been obtained the 1048 forward data path failure statistics can be obtained, while when a 1049 sample of RSRD can be used to calculate the reverse data path failure 1050 statistics. Detailed definitions of the Failure Count and Failure 1051 Ratio are given below. 1053 11.4.1. Failure Count 1055 Failure Count is defined as the number of the undefined value of the 1056 corresponding performance metric in a sample. The value of Failure 1057 Count is an integer. 1059 11.4.2. Failure Ratio 1061 Failure Ratio is the percentage of the number of failure events to 1062 the total number of requests in a sample. Here an failure event 1063 means that the signaling completes with no error, while no error free 1064 signal is observed. The calculation for Failure Ratio is defined as 1065 follows: 1067 Failure Ratio = Number of undefined value/(Number of valid metric 1068 values + Number of undefined value) * 100%. 1070 12. Security Considerations 1072 In the control plane, since the measurement endpoints must be 1073 conformant to signaling specifications and behave as normal signaling 1074 endpoints, it will not incur other security issues than normal LSP 1075 provisioning. However, the measurement parameters must be carefully 1076 selected so that the measurements inject trivial amounts of 1077 additional traffic into the networks they measure. If they inject 1078 "too much" traffic, they can skew the results of the measurement, and 1079 in extreme cases cause congestion and denial of service. 1081 In the data plane, the measurement endpoint MUST use a signal that is 1082 consistent with what is specified in the control plane. For example, 1083 in a packet switched case, the traffic injected into the data plane 1084 MUST NOT exceed the specified rate in the corresponding LSP setup 1085 request. In a wavelength switched case, the measurement endpoint 1086 MUST use the specified or negotiated lambda with appropriate power. 1088 The security considerations pertaining to the original RSVP protocol 1089 [RFC2205] and its TE extensions [RFC3209] also remain relevant. 1091 13. IANA Considerations 1093 This document makes no requests for IANA action. 1095 14. Acknowledgements 1097 We wish to thank Adrian Farrel, Lou Berger and Al Morton for their 1098 comments and help. We also wish to thank the reviews done by Klaas 1099 Wierenga and Alexey Melnikov. 1101 This document contains ideas as well as text that have appeared in 1102 existing IETF documents. The authors wish to thank G. Almes, S. 1103 Kalidindi and M. Zekauskas. 1105 We also wish to thank Weisheng Hu, Yaohui Jin and Wei Guo in the 1106 state key laboratory of advanced optical communication systems and 1107 networks for the valuable comments. We also wish to thank the 1108 support from NSFC and 863 program of China. 1110 15. References 1112 15.1. Normative References 1114 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1115 Requirement Levels", BCP 14, RFC 2119, March 1997. 1117 [RFC2205] Braden, B., Zhang, L., Berson, S., Herzog, S., and S. 1118 Jamin, "Resource ReSerVation Protocol (RSVP) -- Version 1 1119 Functional Specification", RFC 2205, September 1997. 1121 [RFC2679] Almes, G., Kalidindi, S., and M. Zekauskas, "A One-way 1122 Delay Metric for IPPM", RFC 2679, September 1999. 1124 [RFC2681] Almes, G., Kalidindi, S., and M. Zekauskas, "A Round-trip 1125 Delay Metric for IPPM", RFC 2681, September 1999. 1127 [RFC3209] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V., 1128 and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP 1129 Tunnels", RFC 3209, December 2001. 1131 15.2. Informative References 1133 [RFC2330] Paxson, V., Almes, G., Mahdavi, J., and M. Mathis, 1134 "Framework for IP Performance Metrics", RFC 2330, 1135 May 1998. 1137 [RFC4208] Swallow, G., Drake, J., Ishimatsu, H., and Y. Rekhter, 1138 "Generalized Multiprotocol Label Switching (GMPLS) User- 1139 Network Interface (UNI): Resource ReserVation Protocol- 1140 Traffic Engineering (RSVP-TE) Support for the Overlay 1141 Model", RFC 4208, October 2005. 1143 [RFC5814] Sun, W. and G. Zhang, "Label Switched Path (LSP) Dynamic 1144 Provisioning Performance Metrics in Generalized MPLS 1145 Networks", RFC 5814, March 2010. 1147 [RFC6383] Shiomoto, K. and A. Farrel, "Advice on When It Is Safe to 1148 Start Sending Data on Label Switched Paths Established 1149 Using RSVP-TE", RFC 6383, September 2011. 1151 Authors' Addresses 1153 Weiqiang Sun, Editor 1154 Shanghai Jiao Tong University 1155 800 Dongchuan Road 1156 Shanghai 200240 1157 China 1159 Phone: +86 21 3420 5359 1160 Email: sun.weiqiang@gmail.com 1162 Guoying Zhang, Editor 1163 China Academy of Telecommunication Research, MIIT, China. 1164 No.52 Hua Yuan Bei Lu,Haidian District 1165 Beijing 100083 1166 China 1168 Phone: +86 1062300103 1169 EMail: zhangguoying@catr.cn 1171 Jianhua Gao 1172 Huawei Technologies Co., LTD. 1173 China 1175 Phone: +86 755 28973237 1176 Email: gjhhit@huawei.com 1178 Guowu Xie 1179 University of California, Riverside 1180 900 University Ave. 1181 Riverside, CA 92521 1182 USA 1184 Phone: +1 951 237 8825 1185 Email: xieg@cs.ucr.edu 1187 Rajiv Papneja 1188 Huawei Technologies 1189 Santa Clara, CA 95050 1190 Reston, VA 20190 1191 USA 1193 Phone: +1 571 926 8593 1194 Email: rajiv.papneja@huawei.com 1196 Contributors 1198 Bin Gu 1199 IXIA 1200 Oriental Kenzo Plaza 8M, 48 Dongzhimen Wai Street, Dongcheng District 1201 Beijing 200240 1202 China 1204 Phone: +86 13611590766 1205 Email: BGu@ixiacom.com 1207 Xueqin Wei 1208 Fiberhome Telecommunication Technology Co., Ltd. 1209 Wuhan 1210 China 1212 Phone: +86 13871127882 1213 Email: xqwei@fiberhome.com.cn 1215 Tomohiro Otani 1216 KDDI R&D Laboratories, Inc. 1217 2-1-15 Ohara Kamifukuoka Saitama 1218 356-8502 1219 Japan 1221 Phone: +81-49-278-7357 1222 Email: tm-otani@kddi.com 1224 Ruiquan Jing 1225 China Telecom Beijing Research Institute 1226 118 Xizhimenwai Avenue 1227 Beijing 100035 1228 China 1230 Phone: +86-10-58552000 1231 Email: jingrq@ctbri.com.cn