idnits 2.17.1 draft-claise-ippm-perf-metric-registry-01.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 (October 04, 2013) is 3858 days in the past. Is this intentional? Checking references for intended status: Best Current Practice ---------------------------------------------------------------------------- (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 5481 ** Obsolete normative reference: RFC 5226 (Obsoleted by RFC 8126) -- Obsolete informational reference (is this intentional?): RFC 2679 (Obsoleted by RFC 7679) -- Obsolete informational reference (is this intentional?): RFC 2680 (Obsoleted by RFC 7680) -- Obsolete informational reference (is this intentional?): RFC 4148 (Obsoleted by RFC 6248) -- Obsolete informational reference (is this intentional?): RFC 6204 (Obsoleted by RFC 7084) Summary: 2 errors (**), 0 flaws (~~), 1 warning (==), 5 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 IPPM Working Group B. Claise 3 Internet-Draft A. Akhter 4 Intended status: Best Current Practice Cisco Systems, Inc. 5 Expires: April 07, 2014 October 04, 2013 7 Performance Metrics Registry 8 draft-claise-ippm-perf-metric-registry-01.txt 10 Abstract 12 This document specifies an IANA registry for Performance Metrics, for 13 both active monitoring and passive monitoring, along with the initial 14 content. This document also gives a set of guidelines for 15 Performance Metrics requesters and reviewers. 17 Status of This Memo 19 This Internet-Draft is submitted in full conformance with the 20 provisions of BCP 78 and BCP 79. 22 Internet-Drafts are working documents of the Internet Engineering 23 Task Force (IETF). Note that other groups may also distribute 24 working documents as Internet-Drafts. The list of current Internet- 25 Drafts is at http://datatracker.ietf.org/drafts/current/. 27 Internet-Drafts are draft documents valid for a maximum of six months 28 and may be updated, replaced, or obsoleted by other documents at any 29 time. It is inappropriate to use Internet-Drafts as reference 30 material or to cite them other than as "work in progress." 32 This Internet-Draft will expire on April 07, 2014. 34 Copyright Notice 36 Copyright (c) 2013 IETF Trust and the persons identified as the 37 document authors. All rights reserved. 39 This document is subject to BCP 78 and the IETF Trust's Legal 40 Provisions Relating to IETF Documents 41 (http://trustee.ietf.org/license-info) in effect on the date of 42 publication of this document. Please review these documents 43 carefully, as they describe your rights and restrictions with respect 44 to this document. Code Components extracted from this document must 45 include Simplified BSD License text as described in Section 4.e of 46 the Trust Legal Provisions and are provided without warranty as 47 described in the Simplified BSD License. 49 Table of Contents 51 1. Open Issues . . . . . . . . . . . . . . . . . . . . . . . . . 2 52 2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 53 2.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 4 54 3. Guidelines for Performance Metric Requesters and Reviewers . 5 55 3.1. Performance Metrics Template . . . . . . . . . . . . . . 5 56 3.2. Other Guidelines . . . . . . . . . . . . . . . . . . . . 6 57 4. Initial Set of Performance Metrics . . . . . . . . . . . . . 6 58 4.1. Existing Performetrics Metrics, Based on the RFC6390 59 Template . . . . . . . . . . . . . . . . . . . . . . . . 6 60 4.2. Mapping Some IPPM Performance Metrics in the Registry . . 8 61 4.2.1. IPPM Performance Metric Mapping Experiment . . . . . 9 62 4.2.2. Which IPPM Performance Metrics? . . . . . . . . . . . 12 63 5. Performance Metrics in the IPFIX Registry . . . . . . . . . . 12 64 6. Security Considerations . . . . . . . . . . . . . . . . . . . 13 65 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13 66 8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 13 67 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 13 68 9.1. Normative References . . . . . . . . . . . . . . . . . . 13 69 9.2. Informative References . . . . . . . . . . . . . . . . . 14 70 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 16 72 1. Open Issues 74 1. Check whether the "Initial Set of Performance Metrics" is up to 75 date with the latest Performance Metrics published in XRBLOCK. 77 2. Do we want to organize the Performance Metrics list into 78 different layers? IP, transport layer stats, application stats, 79 etc? 81 3. "IPPM Performance Metric Mapping Experiment" for IPDV must be 82 validated. 84 4. The community will have to agree on which Performance Metrics 85 (along with the specific values of the measurements parameters) 86 are operationally relevant 88 5. Define "Measurement Parameter" 90 2. Introduction 92 The IETF specifies and uses Performance Metrics of protocols and 93 applications transported over its protocols. Performance metrics are 94 such an important part of the operations of IETF protocols that 95 [RFC6390] specifies guidelines for their development. 97 The definition and use of performance metrics in the IETF happens in 98 various working groups (WG), most notably: 100 The "IP Performance Metris" (IPPM) WG [IPPM] is the WG primarily 101 focusing on Peformance Metrics definition at the IETF. 103 The "Metric Blocks for use with RTCP's Extended Report Framework" 104 WG [XRBLOCK] recently specified many Peformance Metrics related to 105 "RTP Control Protocol Extended Reports (RTCP XR)" [RFC3611], which 106 establishes a framework to allow new information to be conveyed in 107 RTCP, supplementing the original report blocks defined in "RTP: A 108 Transport Protocol for Real-Time Applications", [RFC3550]. 110 The "Benchmarking Methodology" WG [BMWG] proposed some Peformance 111 Metrics part of the benchmarking methodology. 113 The "IP Flow Information eXport" (IPFIX) WG [IPFIX] Information 114 elements related to performance metrics are currently proposed. 116 The "Performance Metrics for Other Layers" (PMOL) concluded WG 117 [PMOL], defined some Peformance Metrics related to Session 118 Initiation Protocol (SIP) voice quality [RFC6035]. 120 It is expected that more and more Performance Metrics will be defined 121 in the future, not only IP based metrics, but also protocol-specific 122 and application-specific ones. 124 However, despite the abundance and importance of performance metrics, 125 there are still some problems for the industry: first, how to 126 discover which Performance Metrics have already specified, and 127 second, how to avoid Performance Metrics redefinition. Only someone 128 with a broad IETF knowledge would be able to find its way among all 129 the different Performance Metrics specified in the different WGs. 130 The way in which IETF manages namespaces is with IANA registries, and 131 there is currently no Peformance Metrics Registry in IANA. 133 This document specifies an IANA registry for Performance Metrics, 134 along with the initial content, taken from the Performance Metrics 135 already specified at the IETF. Firstly, from the Performance Metrics 136 already specified by the RFC630 template (mentioned later on in the 137 document), and secondly from the existing set of IPPM Performance 138 Metrics. This second category requires a mapping to the RFC6390 139 template. This Performance Metric Registry is applicable to 140 Performance Metrics issued from active monitoring, passive 141 monitoring, or from the end point calculation. Therefore, it must 142 relevant to work developed in the following WGs: IPPM, LMAP, XRBLOCK, 143 BMWG, and IPFIX. Finally, this document gives a set of guidelines 144 for Performance Metrics requesters and reviewers. 146 Based on [RFC5226] Section 4.3, this document is processed as Best 147 Current Practice (BCP) [RFC2026]. 149 The IPPM Metrics Registry [RFC4148] was an attempt to create such a 150 Performance Metrics registry. However, that registry was 151 reclassified as obsolete with [RFC6248], "RFC 4148 and the IP 152 Performance Metrics (IPPM) Registry of Metrics Are Obsolete", and 153 consequently withdrawn. 155 A couple of interesting quotes from RFC 6248 might help understand 156 the issues related to that registry. 158 1. "It is not believed to be feasible or even useful to register 159 every possible combination of Type P, metric parameters, and 160 Stream parameters using the current structure of the IPPM Metrics 161 Registry." 163 2. "The registry structure has been found to be insufficiently 164 detailed to uniquely identify IPPM metrics." 166 3. "Despite apparent efforts to find current or even future users, 167 no one responded to the call for interest in the RFC 4148 168 registry during the second half of 2010." 170 2.1. Terminology 172 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 173 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 174 "OPTIONAL" in this document are to be interpreted as described in 175 [RFC2119]. 177 The terms Performance Metric and Performance Metrics Directorate are 178 direct quotes from [RFC6390], and copied over in this document for 179 the readers convenience. 181 Performance Metric: A Performance Metric is a quantitative measure 182 of performance, specific to an IETF-specified protocol or specific 183 to an application transported over an IETF-specified protocol. 184 Examples of Performance Metrics are the FTP response time for a 185 complete file download, the DNS response time to resolve the IP 186 address, a database logging time, etc. 188 Performance Metrics Directorate: The Performance Metrics Directorate 189 is a directorate that provides guidance for Performance Metrics 190 development in the IETF. The Performance Metrics Directorate 191 should be composed of experts in the performance community, 192 potentially selected from the IP Performance Metrics (IPPM), 193 Benchmarking Methodology (BMWG), and Performance Metrics for Other 194 Layers (PMOL) WGs. 196 Performance Metrics Registry: The IANA registry containing the 197 Performance Metrics. This registry is initially populated from 198 this document. 200 Measurement Parameter: NOT SURE HOW TO DEFINE THIS 202 3. Guidelines for Performance Metric Requesters and Reviewers 204 3.1. Performance Metrics Template 206 "Guidelines for Considering New Performance Metric Development", 207 [RFC6390] defines a framework and a process for developing 208 Performance Metrics for protocols above and below the IP layer (such 209 as IP-based applications that operate over reliable or datagram 210 transport protocols). These metrics can be used to characterize 211 traffic on live networks and services. As such, RFC 6390 does not 212 define any Performance Metrics. 214 RFC 6390 scope covers guidelines for the Performance Metrics 215 directorate members for considering new Performance Metrics and 216 suggests how the Performance Metrics Directorate will interact with 217 the rest of the IETF. Its mission is mentioned at 218 [performance-metrics-directorate]. In practice, a weekly cron job 219 discovers all the IETF drafts that refers to RFC 6390, or that 220 contains the keyword "performance metric". Once discovered, the 221 different drafts are assigned a Performance Metric Directorate 222 reviewer. One of the primary task is to ensure that the RFC 6390 223 template is correctly applied, making sure that the Performance 224 Metric semantic is correctly specified. 226 RFC 6390, specified in Section 5.4, proposes a template for 227 Performance Metrics specifications: 229 Normative 231 o Metric Name 233 o Metric Description 235 o Method of Measurement or Calculation 236 o Units of Measurement 238 o Measurement Point(s) with potential Measurement Domain 240 o Measurement Timing 242 Informative 244 o Implementation 246 o Verification 248 o Use and Applications 250 o Reporting Model 252 The template specified in Section 5.4 of "Guidelines for Considering 253 New Performance Metric Development", [RFC6390] MUST be used as a 254 basis for the Performance Metrics Registry Definition. 256 3.2. Other Guidelines 258 RFC 6390 lacks a naming convention for Performance Metrics, but 259 specifies that "Performance Metric names are RECOMMENDED to be unique 260 within the set of metrics being defined for the protocol layer and 261 context.". Imposing an unique Performane Metric name, while ideal, 262 is not practicable in real live. Indeed, some metrics have already 263 been specified, and the name clashes appeared already. Therefore, 264 all Performance Metrics specified in the registry MUST have an unique 265 performance metric Id. Regarding naming convention, the Performance 266 Metric Names SHOULD be meaningfull and easily searchable in the 267 registry. 269 The group of experts (the reviewers) MUST check the requested 270 Peformance Metric for completeness, accuracy of the template 271 description, and for correct naming according to [RFC6390]. 273 Requests for Performance Metric that duplicate the functionality of 274 existing Performance Metris SHOULD be declined. 276 4. Initial Set of Performance Metrics 278 4.1. Existing Performetrics Metrics, Based on the RFC6390 Template 280 This section contains a list of Performance Metrics specified 281 according to [RFC6390], either in RFCs, or IETF drafts currently in 282 the RFC editor queue. This list should serve as initial content for 283 the Performance Metrics Registry. 285 +-------------------+---------------------------+-------------------+ 286 | Performance | Performance Metric | Reference | 287 | Metric Id | | | 288 +-------------------+---------------------------+-------------------+ 289 | 1 | Threshold in RTP | [RFC6958], | 290 | | | appendix A | 291 | 2 | Sum of Burst Durations in | [RFC6958], | 292 | | RTP | appendix A | 293 | 3 | RTP Packets lost in | [RFC6958], | 294 | | bursts | appendix A | 295 | 4 | Total RTP packets | [RFC6958], | 296 | | expected in bursts | appendix A | 297 | 5 | Number of bursts in RTP | [RFC6958], | 298 | | | appendix A | 299 | 6 | Sum of Squares of Burst | [RFC6958], | 300 | | Durations in RTP | appendix A | 301 | 7 | Number of RTP packets | [RFC7002], | 302 | | discarded Metric | appendix A | 303 | 8 | Threshold in RTP | [RFC7003], | 304 | | | appendix A | 305 | 9 | RTP Packets discarded in | [RFC7003], | 306 | | bursts | appendix A | 307 | 10 | Total RTP packets | [RFC7003], | 308 | | expected in bursts | appendix A | 309 | 11 | RTP Burst Loss Rate | [RFC7004], | 310 | | | appendix A | 311 | 12 | RTP Gap Loss Rate | [RFC7004], | 312 | | | appendix A | 313 | 13 | RTP Burst Duration Mean | [RFC7004], | 314 | | | appendix A | 315 | 14 | RTP Burst duration | [RFC7004], | 316 | | variance | appendix A | 317 | 15 | RTP Burst Discard Rate | [RFC7004], | 318 | | | appendix A | 319 | 16 | RTP Gap Discard Rate | [RFC7004], | 320 | | | appendix A | 321 | 17 | Number of discarded | [RFC7004], | 322 | | frames in RTP | appendix A | 323 | 18 | Number of duplicate | [RFC7004], | 324 | | frames in RTP | appendix A | 325 | 19 | Number of full lost | [RFC7004], | 326 | | frames in RTP | appendix A | 327 | 20 | Number of partial lost | [RFC7004], | 328 | | frames in RTP | appendix A | 329 | 21 | De-jitter buffer nominal | [RFC7005], | 330 | | delay in RTP | appendix A | 331 | 22 | De-jitter buffer maximum | [RFC7005], | 332 | | delay in RTP | appendix A | 333 | 23 | De-jitter buffer high | [RFC7005], | 334 | | water mark in RTP | appendix A | 335 | 24 | De-jitter buffer low | [RFC7005], | 336 | | water mark in RTP: | appendix A | 337 +-------------------+---------------------------+-------------------+ 339 Table 1: List of Existing Performance Metrics Specified at the IETF 341 4.2. Mapping Some IPPM Performance Metrics in the Registry 343 The IPPM WG [IPPM] specified some Measurement Parameters (or 344 measurement characteristics), for example Type-P [RFC2330], packet 345 distribution, etc. 347 The IPPM WG also specified Performance Metrics. For example: 349 A One-way Delay Metric for IPPM [RFC2679] 351 A One-way Packet Loss Metric for IPPM [RFC2680] 353 A Round-trip Delay Metric for IPPM [RFC2681] 355 Those Performance Metrics are based on specific values for the 356 Measurement Parameters. For example: the mean packet loss at IP 357 layer, based on a periodic packet distribution, represented with 358 percentile 95th. 360 The Performance Metrics Registry should contain the IPPM-specified 361 Performance Metrics that are operationally relevant, as oppposed to 362 all Performance Metrics, resulting of all the potential combination 363 of Measurement Parameters. 365 In a typical Large-Scale Measurement of Broadband Performance (LMAP) 366 environment, some information can complement the test to be run: 368 Measurement Parameters configured part of the test definition 370 run-time parameters observed during the test 372 If a test definition requests the round-trip delay metric to a DNS 373 server to be metered "now", the DNS server is a Measurement Parameter 374 configured part of the test definition. Some run-time parameters 375 observed during the test complement the test report: the IP address 376 of the DNS server, the measurement start time, the measurement end 377 time, the DSCP, the TTL, etc. 379 Those run-time parameters are not part of the Performance Metric 380 definition, while the specific values for the Measurement Parameters 381 are part of it. 383 4.2.1. IPPM Performance Metric Mapping Experiment 385 This section is an illustration on how the IP Packet Delay Variation 386 (IPDV) Performance Metric [RFC3393] maps to the RFC 6390 template. 387 Note that the delay variation is sometimes called "jitter", as 388 mentioned in the section 1.1 of [RFC3393], and in section 1 of 389 [RFC5481]. 391 Normative Reference 393 Performance Metric Element ID 395 TBD1: The next available Performance Metric Element ID in 396 the Performance Metric Registry. 398 Metric Name 400 Packet Delay Variation for UDP Packet with Periodic 401 Distribution reported as 95th percentile 403 Metric Description 405 The difference between the one-way-delay of the selected 406 packets, reported as the positive 95th percentile. 408 The default measurement parameters are 410 o L, a packet length in bits, in case of active probing. L 411 = 200 bits. 413 o Tmax, a maximum waiting time for packets to arrive at Dst, 414 set sufficiently long to disambiguate packets with long 415 delays from packets that are discarded (lost). Tmax = 3 416 seconds. 418 o Inter packets time of 20 msec 419 o etc. (I have not reviewed all the parameters of [RFC3393] 421 If any of those measurement parameters is not the default 422 value, its value must be stored with the performance metric 423 value, as context information. THIS IS UP TO DISCUSSION. 425 Method of Measurement or Calculation 427 As documented in Section 4.1 of [RFC5481]: If we have 428 packets in a stream consecutively numbered i = 1,2,3,... 429 falling within the test interval, then IPDV(i) = D(i)-D(i-1) 430 where D(i) denotes the one-way delay of the ith packet of a 431 stream. 433 One-way delays are the difference between timestamps applied 434 at the ends of the path, or the receiver time minus the 435 transmission time. 437 So D(2) = R2-T2. With this timestamp notation, it can be 438 shown that IPDV also represents the change in inter-packet 439 spacing between transmission and reception: 441 IPDV(2) = D(2) - D(1) = (R2-T2) - (R1-T1) = (R2-R1) - 442 (T2-T1) 444 Units of Measurement 446 As documented in Section 8.3 of [RFC5481]: With IPDV, it is 447 interesting to report on a positive percentile, and an 448 inter-quantile range is appropriate to reflect both positive 449 and negative tails (e.g., 5% to 95%). If the IPDV 450 distribution is symmetric around a mean of zero, then it is 451 sufficient to report on the positive side of the 452 distribution. 454 The unit of measurement is percentile 95th. 456 Measurement Point(s) with potential Measurement Domain 458 As documented in Section 4.1 of [RFC5481]: Both IPDV and PDV 459 are derived from the one-way-delay metric. One-way delay 460 requires knowledge of time at two points, e.g., the source 461 and destination of an IP network path in end-to-end 462 measurement. Therefore, both IPDV and PDV can be 463 categorized as 2-point metrics because they are derived from 464 one-way delay. Specific methods of measurement may make 465 assumptions or have a priori knowledge about one of the 466 measurement points, but the metric definitions themselves 467 are based on information collected at two measurement 468 points. 470 Measurement Timing 472 As documented in Section 4.1 of [RFC5481]: The mean of all 473 IPDV(i) for a stream is usually zero. However, a slow delay 474 change over the life of the stream, or a frequency error 475 between the measurement system clocks, can result in a non- 476 zero mean. 478 See also http://tools.ietf.org/html/rfc5481#section-6.3 for 479 "clock stability and error" considerations. 481 See also http://tools.ietf.org/html/rfc5481#section-8.5 for 482 "clock Sync Options" considerations. 484 Informative Reference 486 Implementation 488 As documented in Section 4.1 of [RFC5481]: Note that IPDV 489 can take on positive and negative values (and zero). One 490 way to analyze the IPDV results is to concentrate on the 491 positive excursions. However, this approach has limitations 492 that are discussed in more detail below (see Section 5.3 of 493 [RFC5481]). 495 Verification 497 Not Applicable 499 Use and Applications 500 See section 7 " Applicability of the Delay Variation Forms 501 and Recommendations" of [RFC5481]: 503 Reporting Model 505 As mentioned previously: If any of those measurement 506 parameters is not the default, its value must be stored with 507 the performance metric value, as context information. 509 4.2.2. Which IPPM Performance Metrics? 511 Not all possible combinations of Measurement Parameters for all IPPM 512 Performance Metrics will populate the Performance Metrics Registry. 513 The criteria for selecting the Performance Metrics are (based on 514 discussion with Brian Trammell): 516 (1) interpretable by the user 518 (2) implementable by the software designer 520 (3) deployable by network operators, without major impact on the 521 networks 523 (4) accurate, for interoperability and deployment across vendors 525 Which IPPM Performance Metrics will be selected for the Performance 526 Registry is out of the scope of this document, for now. What is 527 envisioned is a RFC similar to "Basic Requirements for IPv6 Customer 528 Edge Routers", [RFC6204], but for Performance Metrics: "Basic 529 Performance Metrics Requirements for IP Packet SLA Monitoring with 530 Active Probing", or something similar. This document would explain 531 the list of Performance Metrics (from the Performance Metrics 532 Registry, so with fixed Measurement Parameters), along with some 533 proposed run time parameters, depending on the deployment scenario. 535 5. Performance Metrics in the IPFIX Registry 537 There are multiple proposals to add performance metrics Information 538 Elements in the IPFIX IANA registry [iana-ipfix-assignments], to be 539 used with the IPFIX protocol [RFC7011]. This is perfectly legal 540 according the "Information Model for IPFIX" [RFC7012] and "Guidelines 541 for Authors and Reviewers of IPFIX Information Elements" [RFC7013]. 543 Simply adding some text in the Information Element Description field 544 might be a solution if this description is compliant with the RFC6390 545 template definition. However, this is not an ideal solution. On the 546 top of having potentially long descriptions, this imposes a specific 547 formatting for the description field of the performance metrics- 548 related Information Elements, while none is imposed for the non 549 performance metrics-related ones. 551 The preferred approach is for the Performance Metrics to be self- 552 described in their own registry. When the Performance Metrics needs 553 to be defined in the IPFIX IANA registry, the new Information Element 554 can simply refer to the specific entry in the Performance Metrics 555 registry. 557 6. Security Considerations 559 This draft doesn't introduce any security considerations. However, 560 the definition of Performance Metrics may introduce some security 561 concerns, and should be reviewed with security in mind. 563 7. IANA Considerations 565 This document refers to an initial set of Performance Metrics. The 566 list of these Information Elements is given in the "Initial Set of 567 Performance Metrics" Section. The Internet Assigned Numbers 568 Authority (IANA) has created a new registry for Performance Metrics 569 called "Performance Metrics", and filled it with the initial list in 570 Section 4. 572 New assignments for Peformance Metric will be administered by IANA 573 through Expert Review [RFC5226], i.e., review by one of a group of 574 experts appointed by the IESG upon recommendation of the Ops Area 575 Directors. The experts will initially be drawn from the Working 576 Group Chairs and document editors of the Performance Metrics 577 directorate [performance-metrics-directorate]. 579 8. Acknowledgments 581 Thanks to Carlos Pignataro for improving the text of version 00. 583 9. References 585 9.1. Normative References 587 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 588 Requirement Levels", BCP 14, RFC 2119, March 1997. 590 [RFC2026] Bradner, S., "The Internet Standards Process -- Revision 591 3", BCP 9, RFC 2026, October 1996. 593 [RFC3393] Demichelis, C. and P. Chimento, "IP Packet Delay Variation 594 Metric for IP Performance Metrics (IPPM)", RFC 3393, 595 November 2002. 597 [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an 598 IANA Considerations Section in RFCs", BCP 26, RFC 5226, 599 May 2008. 601 [RFC5481] Morton, A. and B. Claise, "Packet Delay Variation 602 Applicability Statement", RFC 5481, March 2009. 604 [RFC6390] Clark, A. and B. Claise, "Guidelines for Considering New 605 Performance Metric Development", BCP 170, RFC 6390, 606 October 2011. 608 [RFC6958] Clark, A., Zhang, S., Zhao, J., and Q. Wu, "RTP Control 609 Protocol (RTCP) Extended Report (XR) Block for Burst/Gap 610 Loss Metric Reporting", RFC 6958, May 2013. 612 [RFC7002] Clark, A., Zorn, G., and Q. Wu, "RTP Control Protocol 613 (RTCP) Extended Report (XR) Block for Discard Count Metric 614 Reporting", RFC 7002, September 2013. 616 [RFC7003] Clark, A., Huang, R., and Q. Wu, "RTP Control Protocol 617 (RTCP) Extended Report (XR) Block for Burst/Gap Discard 618 Metric Reporting", RFC 7003, September 2013. 620 [RFC7004] Zorn, G., Schott, R., Wu, Q., and R. Huang, "RTP Control 621 Protocol (RTCP) Extended Report (XR) Blocks for Summary 622 Statistics Metrics Reporting", RFC 7004, September 2013. 624 [RFC7005] Clark, A., Singh, V., and Q. Wu, "RTP Control Protocol 625 (RTCP) Extended Report (XR) Block for De-Jitter Buffer 626 Metric Reporting", RFC 7005, September 2013. 628 9.2. Informative References 630 [RFC2330] Paxson, V., Almes, G., Mahdavi, J., and M. Mathis, 631 "Framework for IP Performance Metrics", RFC 2330, May 632 1998. 634 [RFC2679] Almes, G., Kalidindi, S., and M. Zekauskas, "A One-way 635 Delay Metric for IPPM", RFC 2679, September 1999. 637 [RFC2680] Almes, G., Kalidindi, S., and M. Zekauskas, "A One-way 638 Packet Loss Metric for IPPM", RFC 2680, September 1999. 640 [RFC2681] Almes, G., Kalidindi, S., and M. Zekauskas, "A Round-trip 641 Delay Metric for IPPM", RFC 2681, September 1999. 643 [RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V. 644 Jacobson, "RTP: A Transport Protocol for Real-Time 645 Applications", STD 64, RFC 3550, July 2003. 647 [RFC3611] Friedman, T., Caceres, R., and A. Clark, "RTP Control 648 Protocol Extended Reports (RTCP XR)", RFC 3611, November 649 2003. 651 [RFC4148] Stephan, E., "IP Performance Metrics (IPPM) Metrics 652 Registry", BCP 108, RFC 4148, August 2005. 654 [RFC6035] Pendleton, A., Clark, A., Johnston, A., and H. Sinnreich, 655 "Session Initiation Protocol Event Package for Voice 656 Quality Reporting", RFC 6035, November 2010. 658 [RFC6204] Singh, H., Beebee, W., Donley, C., Stark, B., and O. 659 Troan, "Basic Requirements for IPv6 Customer Edge 660 Routers", RFC 6204, April 2011. 662 [RFC6248] Morton, A., "RFC 4148 and the IP Performance Metrics 663 (IPPM) Registry of Metrics Are Obsolete", RFC 6248, April 664 2011. 666 [RFC7011] Claise, B., Trammell, B., and P. Aitken, "Specification of 667 the IP Flow Information Export (IPFIX) Protocol for the 668 Exchange of Flow Information", STD 77, RFC 7011, September 669 2013. 671 [RFC7012] Claise, B. and B. Trammell, "Information Model for IP Flow 672 Information Export (IPFIX)", RFC 7012, September 2013. 674 [RFC7013] Trammell, B. and B. Claise, "Guidelines for Authors and 675 Reviewers of IP Flow Information Export (IPFIX) 676 Information Elements", BCP 184, RFC 7013, September 2013. 678 [iana-ipfix-assignments] 679 Internet Assigned Numbers Authority, ., "IP Flow 680 Information Export Information Elements 681 (http://www.iana.org/assignments/ipfix/)", . 683 [performance-metrics-directorate] 684 IETF, ., "Performance Metrics Directorate (http:// 685 www.ietf.org/iesg/directorate/performance-metrics.html)", 686 . 688 [BMWG] IETF, ., "Benchmarking Methodology (BMWG) Working Group, 689 http://datatracker.ietf.org/wg/bmwg/charter/", . 691 [IPFIX] IETF, ., "IP Flow Information eXport (IPFIX) Working 692 Group, http://datatracker.ietf.org/wg/ipfix/charter/", . 694 [IPPM] IETF, ., "IP Performance Metrics (IPPM) Working Group, 695 http://datatracker.ietf.org/wg/ippm/charter/", . 697 [PMOL] IETF, ., "IPerformance Metrics for Other Layers (PMOL) 698 Working Group, 699 http://datatracker.ietf.org/wg/pmol/charter/", . 701 [XRBLOCK] IETF, ., "Metric Blocks for use with RTCP's Extended 702 Report Framework (XRBLOCK), 703 http://datatracker.ietf.org/wg/xrblock/charter/", . 705 Authors' Addresses 707 Benoit Claise 708 Cisco Systems, Inc. 709 De Kleetlaan 6a b1 710 1831 Diegem 711 Belgium 713 Phone: +32 2 704 5622 714 Email: bclaise@cisco.com 716 Aamer Akhter 717 Cisco Systems, Inc. 718 7025 Kit Creek Road 719 RTP, NC 27709 720 USA 722 Email: aakhter@cisco.com