Internet DRAFT - draft-claise-ippm-perf-metric-registry
draft-claise-ippm-perf-metric-registry
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]
