IPPM Working Group B. Claise Internet-Draft A. Akhter Intended status: Best Current Practice Cisco Systems, Inc. Expires: April 07, 2014 October 04, 2013 Performance Metrics Registry draft-claise-ippm-perf-metric-registry-01.txt Abstract This document specifies an IANA registry for Performance Metrics, for both active monitoring and passive monitoring, along with the initial content. This document also gives a set of guidelines for Performance Metrics requesters and reviewers. Status of This Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at http://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." This Internet-Draft will expire on April 07, 2014. Copyright Notice Copyright (c) 2013 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Claise & Akhter Expires April 07, 2014 [Page 1] Internet-Draft PERF-METRIC REGISTRY October 2013 Table of Contents 1. Open Issues . . . . . . . . . . . . . . . . . . . . . . . . . 2 2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 2.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 4 3. Guidelines for Performance Metric Requesters and Reviewers . 5 3.1. Performance Metrics Template . . . . . . . . . . . . . . 5 3.2. Other Guidelines . . . . . . . . . . . . . . . . . . . . 6 4. Initial Set of Performance Metrics . . . . . . . . . . . . . 6 4.1. Existing Performetrics Metrics, Based on the RFC6390 Template . . . . . . . . . . . . . . . . . . . . . . . . 6 4.2. Mapping Some IPPM Performance Metrics in the Registry . . 8 4.2.1. IPPM Performance Metric Mapping Experiment . . . . . 9 4.2.2. Which IPPM Performance Metrics? . . . . . . . . . . . 12 5. Performance Metrics in the IPFIX Registry . . . . . . . . . . 12 6. Security Considerations . . . . . . . . . . . . . . . . . . . 13 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13 8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 13 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 13 9.1. Normative References . . . . . . . . . . . . . . . . . . 13 9.2. Informative References . . . . . . . . . . . . . . . . . 14 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 16 1. Open Issues 1. Check whether the "Initial Set of Performance Metrics" is up to date with the latest Performance Metrics published in XRBLOCK. 2. Do we want to organize the Performance Metrics list into different layers? IP, transport layer stats, application stats, etc? 3. "IPPM Performance Metric Mapping Experiment" for IPDV must be validated. 4. The community will have to agree on which Performance Metrics (along with the specific values of the measurements parameters) are operationally relevant 5. Define "Measurement Parameter" 2. Introduction The IETF specifies and uses Performance Metrics of protocols and applications transported over its protocols. Performance metrics are such an important part of the operations of IETF protocols that [RFC6390] specifies guidelines for their development. Claise & Akhter Expires April 07, 2014 [Page 2] Internet-Draft PERF-METRIC REGISTRY October 2013 The definition and use of performance metrics in the IETF happens in various working groups (WG), most notably: The "IP Performance Metris" (IPPM) WG [IPPM] is the WG primarily focusing on Peformance Metrics definition at the IETF. The "Metric Blocks for use with RTCP's Extended Report Framework" WG [XRBLOCK] recently specified many Peformance Metrics related to "RTP Control Protocol Extended Reports (RTCP XR)" [RFC3611], which establishes a framework to allow new information to be conveyed in RTCP, supplementing the original report blocks defined in "RTP: A Transport Protocol for Real-Time Applications", [RFC3550]. The "Benchmarking Methodology" WG [BMWG] proposed some Peformance Metrics part of the benchmarking methodology. The "IP Flow Information eXport" (IPFIX) WG [IPFIX] Information elements related to performance metrics are currently proposed. The "Performance Metrics for Other Layers" (PMOL) concluded WG [PMOL], defined some Peformance Metrics related to Session Initiation Protocol (SIP) voice quality [RFC6035]. It is expected that more and more Performance Metrics will be defined in the future, not only IP based metrics, but also protocol-specific and application-specific ones. However, despite the abundance and importance of performance metrics, there are still some problems for the industry: first, how to discover which Performance Metrics have already specified, and second, how to avoid Performance Metrics redefinition. Only someone with a broad IETF knowledge would be able to find its way among all the different Performance Metrics specified in the different WGs. The way in which IETF manages namespaces is with IANA registries, and there is currently no Peformance Metrics Registry in IANA. This document specifies an IANA registry for Performance Metrics, along with the initial content, taken from the Performance Metrics already specified at the IETF. Firstly, from the Performance Metrics already specified by the RFC630 template (mentioned later on in the document), and secondly from the existing set of IPPM Performance Metrics. This second category requires a mapping to the RFC6390 template. This Performance Metric Registry is applicable to Performance Metrics issued from active monitoring, passive monitoring, or from the end point calculation. Therefore, it must relevant to work developed in the following WGs: IPPM, LMAP, XRBLOCK, BMWG, and IPFIX. Finally, this document gives a set of guidelines for Performance Metrics requesters and reviewers. Claise & Akhter Expires April 07, 2014 [Page 3] Internet-Draft PERF-METRIC REGISTRY October 2013 Based on [RFC5226] Section 4.3, this document is processed as Best Current Practice (BCP) [RFC2026]. The IPPM Metrics Registry [RFC4148] was an attempt to create such a Performance Metrics registry. However, that registry was reclassified as obsolete with [RFC6248], "RFC 4148 and the IP Performance Metrics (IPPM) Registry of Metrics Are Obsolete", and consequently withdrawn. A couple of interesting quotes from RFC 6248 might help understand the issues related to that registry. 1. "It is not believed to be feasible or even useful to register every possible combination of Type P, metric parameters, and Stream parameters using the current structure of the IPPM Metrics Registry." 2. "The registry structure has been found to be insufficiently detailed to uniquely identify IPPM metrics." 3. "Despite apparent efforts to find current or even future users, no one responded to the call for interest in the RFC 4148 registry during the second half of 2010." 2.1. Terminology The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119]. The terms Performance Metric and Performance Metrics Directorate are direct quotes from [RFC6390], and copied over in this document for the readers convenience. Performance Metric: A Performance Metric is a quantitative measure of performance, specific to an IETF-specified protocol or specific to an application transported over an IETF-specified protocol. Examples of Performance Metrics are the FTP response time for a complete file download, the DNS response time to resolve the IP address, a database logging time, etc. Claise & Akhter Expires April 07, 2014 [Page 4] Internet-Draft PERF-METRIC REGISTRY October 2013 Performance Metrics Directorate: The Performance Metrics Directorate is a directorate that provides guidance for Performance Metrics development in the IETF. The Performance Metrics Directorate should be composed of experts in the performance community, potentially selected from the IP Performance Metrics (IPPM), Benchmarking Methodology (BMWG), and Performance Metrics for Other Layers (PMOL) WGs. Performance Metrics Registry: The IANA registry containing the Performance Metrics. This registry is initially populated from this document. Measurement Parameter: NOT SURE HOW TO DEFINE THIS 3. Guidelines for Performance Metric Requesters and Reviewers 3.1. Performance Metrics Template "Guidelines for Considering New Performance Metric Development", [RFC6390] defines a framework and a process for developing Performance Metrics for protocols above and below the IP layer (such as IP-based applications that operate over reliable or datagram transport protocols). These metrics can be used to characterize traffic on live networks and services. As such, RFC 6390 does not define any Performance Metrics. RFC 6390 scope covers guidelines for the Performance Metrics directorate members for considering new Performance Metrics and suggests how the Performance Metrics Directorate will interact with the rest of the IETF. Its mission is mentioned at [performance-metrics-directorate]. In practice, a weekly cron job discovers all the IETF drafts that refers to RFC 6390, or that contains the keyword "performance metric". Once discovered, the different drafts are assigned a Performance Metric Directorate reviewer. One of the primary task is to ensure that the RFC 6390 template is correctly applied, making sure that the Performance Metric semantic is correctly specified. RFC 6390, specified in Section 5.4, proposes a template for Performance Metrics specifications: Normative o Metric Name o Metric Description o Method of Measurement or Calculation Claise & Akhter Expires April 07, 2014 [Page 5] Internet-Draft PERF-METRIC REGISTRY October 2013 o Units of Measurement o Measurement Point(s) with potential Measurement Domain o Measurement Timing Informative o Implementation o Verification o Use and Applications o Reporting Model The template specified in Section 5.4 of "Guidelines for Considering New Performance Metric Development", [RFC6390] MUST be used as a basis for the Performance Metrics Registry Definition. 3.2. Other Guidelines RFC 6390 lacks a naming convention for Performance Metrics, but specifies that "Performance Metric names are RECOMMENDED to be unique within the set of metrics being defined for the protocol layer and context.". Imposing an unique Performane Metric name, while ideal, is not practicable in real live. Indeed, some metrics have already been specified, and the name clashes appeared already. Therefore, all Performance Metrics specified in the registry MUST have an unique performance metric Id. Regarding naming convention, the Performance Metric Names SHOULD be meaningfull and easily searchable in the registry. The group of experts (the reviewers) MUST check the requested Peformance Metric for completeness, accuracy of the template description, and for correct naming according to [RFC6390]. Requests for Performance Metric that duplicate the functionality of existing Performance Metris SHOULD be declined. 4. Initial Set of Performance Metrics 4.1. Existing Performetrics Metrics, Based on the RFC6390 Template This section contains a list of Performance Metrics specified according to [RFC6390], either in RFCs, or IETF drafts currently in the RFC editor queue. This list should serve as initial content for the Performance Metrics Registry. Claise & Akhter Expires April 07, 2014 [Page 6] Internet-Draft PERF-METRIC REGISTRY October 2013 +-------------------+---------------------------+-------------------+ | Performance | Performance Metric | Reference | | Metric Id | | | +-------------------+---------------------------+-------------------+ | 1 | Threshold in RTP | [RFC6958], | | | | appendix A | | 2 | Sum of Burst Durations in | [RFC6958], | | | RTP | appendix A | | 3 | RTP Packets lost in | [RFC6958], | | | bursts | appendix A | | 4 | Total RTP packets | [RFC6958], | | | expected in bursts | appendix A | | 5 | Number of bursts in RTP | [RFC6958], | | | | appendix A | | 6 | Sum of Squares of Burst | [RFC6958], | | | Durations in RTP | appendix A | | 7 | Number of RTP packets | [RFC7002], | | | discarded Metric | appendix A | | 8 | Threshold in RTP | [RFC7003], | | | | appendix A | | 9 | RTP Packets discarded in | [RFC7003], | | | bursts | appendix A | | 10 | Total RTP packets | [RFC7003], | | | expected in bursts | appendix A | | 11 | RTP Burst Loss Rate | [RFC7004], | | | | appendix A | | 12 | RTP Gap Loss Rate | [RFC7004], | | | | appendix A | | 13 | RTP Burst Duration Mean | [RFC7004], | | | | appendix A | | 14 | RTP Burst duration | [RFC7004], | | | variance | appendix A | | 15 | RTP Burst Discard Rate | [RFC7004], | | | | appendix A | | 16 | RTP Gap Discard Rate | [RFC7004], | | | | appendix A | | 17 | Number of discarded | [RFC7004], | | | frames in RTP | appendix A | | 18 | Number of duplicate | [RFC7004], | | | frames in RTP | appendix A | | 19 | Number of full lost | [RFC7004], | | | frames in RTP | appendix A | | 20 | Number of partial lost | [RFC7004], | | | frames in RTP | appendix A | | 21 | De-jitter buffer nominal | [RFC7005], | | | delay in RTP | appendix A | | 22 | De-jitter buffer maximum | [RFC7005], | | | delay in RTP | appendix A | Claise & Akhter Expires April 07, 2014 [Page 7] Internet-Draft PERF-METRIC REGISTRY October 2013 | 23 | De-jitter buffer high | [RFC7005], | | | water mark in RTP | appendix A | | 24 | De-jitter buffer low | [RFC7005], | | | water mark in RTP: | appendix A | +-------------------+---------------------------+-------------------+ Table 1: List of Existing Performance Metrics Specified at the IETF 4.2. Mapping Some IPPM Performance Metrics in the Registry The IPPM WG [IPPM] specified some Measurement Parameters (or measurement characteristics), for example Type-P [RFC2330], packet distribution, etc. The IPPM WG also specified Performance Metrics. For example: A One-way Delay Metric for IPPM [RFC2679] A One-way Packet Loss Metric for IPPM [RFC2680] A Round-trip Delay Metric for IPPM [RFC2681] Those Performance Metrics are based on specific values for the Measurement Parameters. For example: the mean packet loss at IP layer, based on a periodic packet distribution, represented with percentile 95th. The Performance Metrics Registry should contain the IPPM-specified Performance Metrics that are operationally relevant, as oppposed to all Performance Metrics, resulting of all the potential combination of Measurement Parameters. In a typical Large-Scale Measurement of Broadband Performance (LMAP) environment, some information can complement the test to be run: Measurement Parameters configured part of the test definition run-time parameters observed during the test If a test definition requests the round-trip delay metric to a DNS server to be metered "now", the DNS server is a Measurement Parameter configured part of the test definition. Some run-time parameters observed during the test complement the test report: the IP address of the DNS server, the measurement start time, the measurement end time, the DSCP, the TTL, etc. Claise & Akhter Expires April 07, 2014 [Page 8] Internet-Draft PERF-METRIC REGISTRY October 2013 Those run-time parameters are not part of the Performance Metric definition, while the specific values for the Measurement Parameters are part of it. 4.2.1. IPPM Performance Metric Mapping Experiment This section is an illustration on how the IP Packet Delay Variation (IPDV) Performance Metric [RFC3393] maps to the RFC 6390 template. Note that the delay variation is sometimes called "jitter", as mentioned in the section 1.1 of [RFC3393], and in section 1 of [RFC5481]. Normative Reference Performance Metric Element ID TBD1: The next available Performance Metric Element ID in the Performance Metric Registry. Metric Name Packet Delay Variation for UDP Packet with Periodic Distribution reported as 95th percentile Metric Description The difference between the one-way-delay of the selected packets, reported as the positive 95th percentile. The default measurement parameters are o L, a packet length in bits, in case of active probing. L = 200 bits. o Tmax, a maximum waiting time for packets to arrive at Dst, set sufficiently long to disambiguate packets with long delays from packets that are discarded (lost). Tmax = 3 seconds. o Inter packets time of 20 msec Claise & Akhter Expires April 07, 2014 [Page 9] Internet-Draft PERF-METRIC REGISTRY October 2013 o etc. (I have not reviewed all the parameters of [RFC3393] If any of those measurement parameters is not the default value, its value must be stored with the performance metric value, as context information. THIS IS UP TO DISCUSSION. Method of Measurement or Calculation As documented in Section 4.1 of [RFC5481]: If we have packets in a stream consecutively numbered i = 1,2,3,... falling within the test interval, then IPDV(i) = D(i)-D(i-1) where D(i) denotes the one-way delay of the ith packet of a stream. One-way delays are the difference between timestamps applied at the ends of the path, or the receiver time minus the transmission time. So D(2) = R2-T2. With this timestamp notation, it can be shown that IPDV also represents the change in inter-packet spacing between transmission and reception: IPDV(2) = D(2) - D(1) = (R2-T2) - (R1-T1) = (R2-R1) - (T2-T1) Units of Measurement As documented in Section 8.3 of [RFC5481]: With IPDV, it is interesting to report on a positive percentile, and an inter-quantile range is appropriate to reflect both positive and negative tails (e.g., 5% to 95%). If the IPDV distribution is symmetric around a mean of zero, then it is sufficient to report on the positive side of the distribution. The unit of measurement is percentile 95th. Measurement Point(s) with potential Measurement Domain As documented in Section 4.1 of [RFC5481]: Both IPDV and PDV are derived from the one-way-delay metric. One-way delay requires knowledge of time at two points, e.g., the source Claise & Akhter Expires April 07, 2014 [Page 10] Internet-Draft PERF-METRIC REGISTRY October 2013 and destination of an IP network path in end-to-end measurement. Therefore, both IPDV and PDV can be categorized as 2-point metrics because they are derived from one-way delay. Specific methods of measurement may make assumptions or have a priori knowledge about one of the measurement points, but the metric definitions themselves are based on information collected at two measurement points. Measurement Timing As documented in Section 4.1 of [RFC5481]: The mean of all IPDV(i) for a stream is usually zero. However, a slow delay change over the life of the stream, or a frequency error between the measurement system clocks, can result in a non- zero mean. See also http://tools.ietf.org/html/rfc5481#section-6.3 for "clock stability and error" considerations. See also http://tools.ietf.org/html/rfc5481#section-8.5 for "clock Sync Options" considerations. Informative Reference Implementation As documented in Section 4.1 of [RFC5481]: Note that IPDV can take on positive and negative values (and zero). One way to analyze the IPDV results is to concentrate on the positive excursions. However, this approach has limitations that are discussed in more detail below (see Section 5.3 of [RFC5481]). Verification Not Applicable Use and Applications Claise & Akhter Expires April 07, 2014 [Page 11] Internet-Draft PERF-METRIC REGISTRY October 2013 See section 7 " Applicability of the Delay Variation Forms and Recommendations" of [RFC5481]: Reporting Model As mentioned previously: If any of those measurement parameters is not the default, its value must be stored with the performance metric value, as context information. 4.2.2. Which IPPM Performance Metrics? Not all possible combinations of Measurement Parameters for all IPPM Performance Metrics will populate the Performance Metrics Registry. The criteria for selecting the Performance Metrics are (based on discussion with Brian Trammell): (1) interpretable by the user (2) implementable by the software designer (3) deployable by network operators, without major impact on the networks (4) accurate, for interoperability and deployment across vendors Which IPPM Performance Metrics will be selected for the Performance Registry is out of the scope of this document, for now. What is envisioned is a RFC similar to "Basic Requirements for IPv6 Customer Edge Routers", [RFC6204], but for Performance Metrics: "Basic Performance Metrics Requirements for IP Packet SLA Monitoring with Active Probing", or something similar. This document would explain the list of Performance Metrics (from the Performance Metrics Registry, so with fixed Measurement Parameters), along with some proposed run time parameters, depending on the deployment scenario. 5. Performance Metrics in the IPFIX Registry There are multiple proposals to add performance metrics Information Elements in the IPFIX IANA registry [iana-ipfix-assignments], to be used with the IPFIX protocol [RFC7011]. This is perfectly legal according the "Information Model for IPFIX" [RFC7012] and "Guidelines for Authors and Reviewers of IPFIX Information Elements" [RFC7013]. Simply adding some text in the Information Element Description field might be a solution if this description is compliant with the RFC6390 template definition. However, this is not an ideal solution. On the Claise & Akhter Expires April 07, 2014 [Page 12] Internet-Draft PERF-METRIC REGISTRY October 2013 top of having potentially long descriptions, this imposes a specific formatting for the description field of the performance metrics- related Information Elements, while none is imposed for the non performance metrics-related ones. The preferred approach is for the Performance Metrics to be self- described in their own registry. When the Performance Metrics needs to be defined in the IPFIX IANA registry, the new Information Element can simply refer to the specific entry in the Performance Metrics registry. 6. Security Considerations This draft doesn't introduce any security considerations. However, the definition of Performance Metrics may introduce some security concerns, and should be reviewed with security in mind. 7. IANA Considerations This document refers to an initial set of Performance Metrics. The list of these Information Elements is given in the "Initial Set of Performance Metrics" Section. The Internet Assigned Numbers Authority (IANA) has created a new registry for Performance Metrics called "Performance Metrics", and filled it with the initial list in Section 4. New assignments for Peformance Metric will be administered by IANA through Expert Review [RFC5226], i.e., review by one of a group of experts appointed by the IESG upon recommendation of the Ops Area Directors. The experts will initially be drawn from the Working Group Chairs and document editors of the Performance Metrics directorate [performance-metrics-directorate]. 8. Acknowledgments Thanks to Carlos Pignataro for improving the text of version 00. 9. References 9.1. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC2026] Bradner, S., "The Internet Standards Process -- Revision 3", BCP 9, RFC 2026, October 1996. Claise & Akhter Expires April 07, 2014 [Page 13] Internet-Draft PERF-METRIC REGISTRY October 2013 [RFC3393] Demichelis, C. and P. Chimento, "IP Packet Delay Variation Metric for IP Performance Metrics (IPPM)", RFC 3393, November 2002. [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 5226, May 2008. [RFC5481] Morton, A. and B. Claise, "Packet Delay Variation Applicability Statement", RFC 5481, March 2009. [RFC6390] Clark, A. and B. Claise, "Guidelines for Considering New Performance Metric Development", BCP 170, RFC 6390, October 2011. [RFC6958] Clark, A., Zhang, S., Zhao, J., and Q. Wu, "RTP Control Protocol (RTCP) Extended Report (XR) Block for Burst/Gap Loss Metric Reporting", RFC 6958, May 2013. [RFC7002] Clark, A., Zorn, G., and Q. Wu, "RTP Control Protocol (RTCP) Extended Report (XR) Block for Discard Count Metric Reporting", RFC 7002, September 2013. [RFC7003] Clark, A., Huang, R., and Q. Wu, "RTP Control Protocol (RTCP) Extended Report (XR) Block for Burst/Gap Discard Metric Reporting", RFC 7003, September 2013. [RFC7004] Zorn, G., Schott, R., Wu, Q., and R. Huang, "RTP Control Protocol (RTCP) Extended Report (XR) Blocks for Summary Statistics Metrics Reporting", RFC 7004, September 2013. [RFC7005] Clark, A., Singh, V., and Q. Wu, "RTP Control Protocol (RTCP) Extended Report (XR) Block for De-Jitter Buffer Metric Reporting", RFC 7005, September 2013. 9.2. Informative References [RFC2330] Paxson, V., Almes, G., Mahdavi, J., and M. Mathis, "Framework for IP Performance Metrics", RFC 2330, May 1998. [RFC2679] Almes, G., Kalidindi, S., and M. Zekauskas, "A One-way Delay Metric for IPPM", RFC 2679, September 1999. [RFC2680] Almes, G., Kalidindi, S., and M. Zekauskas, "A One-way Packet Loss Metric for IPPM", RFC 2680, September 1999. Claise & Akhter Expires April 07, 2014 [Page 14] Internet-Draft PERF-METRIC REGISTRY October 2013 [RFC2681] Almes, G., Kalidindi, S., and M. Zekauskas, "A Round-trip Delay Metric for IPPM", RFC 2681, September 1999. [RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V. Jacobson, "RTP: A Transport Protocol for Real-Time Applications", STD 64, RFC 3550, July 2003. [RFC3611] Friedman, T., Caceres, R., and A. Clark, "RTP Control Protocol Extended Reports (RTCP XR)", RFC 3611, November 2003. [RFC4148] Stephan, E., "IP Performance Metrics (IPPM) Metrics Registry", BCP 108, RFC 4148, August 2005. [RFC6035] Pendleton, A., Clark, A., Johnston, A., and H. Sinnreich, "Session Initiation Protocol Event Package for Voice Quality Reporting", RFC 6035, November 2010. [RFC6204] Singh, H., Beebee, W., Donley, C., Stark, B., and O. Troan, "Basic Requirements for IPv6 Customer Edge Routers", RFC 6204, April 2011. [RFC6248] Morton, A., "RFC 4148 and the IP Performance Metrics (IPPM) Registry of Metrics Are Obsolete", RFC 6248, April 2011. [RFC7011] Claise, B., Trammell, B., and P. Aitken, "Specification of the IP Flow Information Export (IPFIX) Protocol for the Exchange of Flow Information", STD 77, RFC 7011, September 2013. [RFC7012] Claise, B. and B. Trammell, "Information Model for IP Flow Information Export (IPFIX)", RFC 7012, September 2013. [RFC7013] Trammell, B. and B. Claise, "Guidelines for Authors and Reviewers of IP Flow Information Export (IPFIX) Information Elements", BCP 184, RFC 7013, September 2013. [iana-ipfix-assignments] Internet Assigned Numbers Authority, ., "IP Flow Information Export Information Elements (http://www.iana.org/assignments/ipfix/)", . [performance-metrics-directorate] IETF, ., "Performance Metrics Directorate (http:// www.ietf.org/iesg/directorate/performance-metrics.html)", . Claise & Akhter Expires April 07, 2014 [Page 15] Internet-Draft PERF-METRIC REGISTRY October 2013 [BMWG] IETF, ., "Benchmarking Methodology (BMWG) Working Group, http://datatracker.ietf.org/wg/bmwg/charter/", . [IPFIX] IETF, ., "IP Flow Information eXport (IPFIX) Working Group, http://datatracker.ietf.org/wg/ipfix/charter/", . [IPPM] IETF, ., "IP Performance Metrics (IPPM) Working Group, http://datatracker.ietf.org/wg/ippm/charter/", . [PMOL] IETF, ., "IPerformance Metrics for Other Layers (PMOL) Working Group, http://datatracker.ietf.org/wg/pmol/charter/", . [XRBLOCK] IETF, ., "Metric Blocks for use with RTCP's Extended Report Framework (XRBLOCK), http://datatracker.ietf.org/wg/xrblock/charter/", . Authors' Addresses Benoit Claise Cisco Systems, Inc. De Kleetlaan 6a b1 1831 Diegem Belgium Phone: +32 2 704 5622 Email: bclaise@cisco.com Aamer Akhter Cisco Systems, Inc. 7025 Kit Creek Road RTP, NC 27709 USA Email: aakhter@cisco.com Claise & Akhter Expires April 07, 2014 [Page 16]