< draft-ietf-ippm-metric-registry-00.txt   draft-ietf-ippm-metric-registry-01.txt >
Network Working Group M. Bagnulo Network Working Group M. Bagnulo
Internet-Draft UC3M Internet-Draft UC3M
Intended status: Best Current Practice B. Claise Intended status: Best Current Practice B. Claise
Expires: January 4, 2015 Cisco Systems, Inc. Expires: March 14, 2015 Cisco Systems, Inc.
P. Eardley P. Eardley
BT BT
A. Morton A. Morton
AT&T Labs AT&T Labs
July 3, 2014 A. Akhter
Cisco Systems, Inc.
September 10, 2014
Registry for Performance Metrics Registry for Performance Metrics
draft-ietf-ippm-metric-registry-00 draft-ietf-ippm-metric-registry-01
Abstract Abstract
This document specifies the common aspects of the IANA Registry for This document defines the IANA Registry for Performance Metrics.
Performance Metrics, both active and passive categories. This This document also gives a set of guidelines for Registered
document also gives a set of guidelines for Registered Performance Performance Metric requesters and reviewers.
Metric requesters and reviewers.
Status of This Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on January 4, 2015. This Internet-Draft will expire on March 14, 2015.
Copyright Notice Copyright Notice
Copyright (c) 2014 IETF Trust and the persons identified as the Copyright (c) 2014 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Open Issues . . . . . . . . . . . . . . . . . . . . . . . . . 2 1. Open Issues . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 4
3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5 3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5
4. Scope . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6 4. Scope . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
5. Design Considerations for the Registry and Registered Metrics 7 5. Design Considerations for the Registry and Registered Metrics 7
5.1. Interoperability . . . . . . . . . . . . . . . . . . . . 8 5.1. Interoperability . . . . . . . . . . . . . . . . . . . . 7
5.2. Criteria for Registered Performance Metrics . . . . . . . 8 5.2. Criteria for Registered Performance Metrics . . . . . . . 8
5.3. Single point of reference for Performance metrics . . . . 9 5.3. Single point of reference for Performance metrics . . . . 8
5.4. Side benefits . . . . . . . . . . . . . . . . . . . . . . 9 5.4. Side benefits . . . . . . . . . . . . . . . . . . . . . . 9
6. Performance Metric Registry: Prior attempt . . . . . . . . . 9 6. Performance Metric Registry: Prior attempt . . . . . . . . . 9
6.1. Why this Attempt Will Succeed? . . . . . . . . . . . . . 10 6.1. Why this Attempt Will Succeed? . . . . . . . . . . . . . 10
7. Common Columns of the Performance Metric Registry . . . . . . 11 7. Defintion of the Performance Metric Registry . . . . . . . . 10
7.1. Identifier . . . . . . . . . . . . . . . . . . . . . . . 11 7.1. Summary Category . . . . . . . . . . . . . . . . . . . . 12
7.2. Name . . . . . . . . . . . . . . . . . . . . . . . . . . 11 7.1.1. Identifier . . . . . . . . . . . . . . . . . . . . . 12
7.3. URI . . . . . . . . . . . . . . . . . . . . . . . . . . . 12 7.1.2. Name . . . . . . . . . . . . . . . . . . . . . . . . 13
7.4. Status . . . . . . . . . . . . . . . . . . . . . . . . . 12 7.1.3. URI . . . . . . . . . . . . . . . . . . . . . . . . . 13
7.5. Requester . . . . . . . . . . . . . . . . . . . . . . . . 13 7.1.4. Description . . . . . . . . . . . . . . . . . . . . . 14
7.6. Revision . . . . . . . . . . . . . . . . . . . . . . . . 13 7.2. Metric Definition Category . . . . . . . . . . . . . . . 14
7.7. Revision Date . . . . . . . . . . . . . . . . . . . . . . 13 7.2.1. Reference Definition . . . . . . . . . . . . . . . . 14
7.8. Description . . . . . . . . . . . . . . . . . . . . . . . 13 7.2.2. Fixed Parameters . . . . . . . . . . . . . . . . . . 14
7.9. Reference Specification(s) . . . . . . . . . . . . . . . 13 7.3. Method of Measurement Category . . . . . . . . . . . . . 15
8. The Life-Cycle of Registered Metrics . . . . . . . . . . . . 13 7.3.1. Reference Method . . . . . . . . . . . . . . . . . . 15
8.1. The Process for Review by the Performance Metric Experts 13 7.3.2. Packet Generation Stream . . . . . . . . . . . . . . 15
8.2. Revising Registered Performance Metrics . . . . . . . . . 14 7.3.3. Traffic Filter . . . . . . . . . . . . . . . . . . . 16
8.3. Deprecating Registered Performance Metrics . . . . . . . 16 7.3.4. Sampling distribution . . . . . . . . . . . . . . . . 16
9. Performance Metric Registry and other Registries . . . . . . 16 7.3.5. Run-time Parameters . . . . . . . . . . . . . . . . . 16
10. Security considerations . . . . . . . . . . . . . . . . . . . 17 7.3.6. Role . . . . . . . . . . . . . . . . . . . . . . . . 17
11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 17 7.4. Output Category . . . . . . . . . . . . . . . . . . . . . 17
12. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 17 7.4.1. Value . . . . . . . . . . . . . . . . . . . . . . . . 17
13. References . . . . . . . . . . . . . . . . . . . . . . . . . 17 7.4.2. Data Format . . . . . . . . . . . . . . . . . . . . . 17
13.1. Normative References . . . . . . . . . . . . . . . . . . 17 7.4.3. Reference . . . . . . . . . . . . . . . . . . . . . . 18
13.2. Informative References . . . . . . . . . . . . . . . . . 18 7.4.4. Metric Units . . . . . . . . . . . . . . . . . . . . 18
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 19 7.5. Admisnitratvie information . . . . . . . . . . . . . . . 18
7.5.1. Status . . . . . . . . . . . . . . . . . . . . . . . 18
7.5.2. Requester . . . . . . . . . . . . . . . . . . . . . . 18
7.5.3. Revision . . . . . . . . . . . . . . . . . . . . . . 18
7.5.4. Revision Date . . . . . . . . . . . . . . . . . . . . 18
7.6. Comments and Remarks . . . . . . . . . . . . . . . . . . 18
8. The Life-Cycle of Registered Metrics . . . . . . . . . . . . 19
8.1. Adding new Performance Metrics to the Registry . . . . . 19
8.2. Revising Registered Performance Metrics . . . . . . . . . 20
8.3. Deprecating Registered Performance Metrics . . . . . . . 21
9. Performance Metric Registry and other Registries . . . . . . 22
10. Security considerations . . . . . . . . . . . . . . . . . . . 22
11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 22
12. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 23
13. References . . . . . . . . . . . . . . . . . . . . . . . . . 23
13.1. Normative References . . . . . . . . . . . . . . . . . . 23
13.2. Informative References . . . . . . . . . . . . . . . . . 24
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 25
1. Open Issues 1. Open Issues
1. Many aspects of the Naming convention are TBD, and need 1. Many aspects of the Naming convention are TBD, and need
discussion. For example, we have distinguished RTCP-XR metrics discussion. For example, we have distinguished RTCP-XR metrics
as End-Point (neither active nor passive in the traditional as End-Point (neither active nor passive in the traditional
sense, so not Act_ or Pas_). Even though we may not cast all sense, so not Act_ or Pas_). Even though we may not cast all
naming conventions in stone at the start, it will be helpful to naming conventions in stone at the start, it will be helpful to
look at several examples of passive metric names now. look at several examples of passive metric names now.
2. We should expand on the different roles and responsibilities of
the Performance Metrics Experts versus the Performance Metric
Directorate. At least, the Performance Metric Directorate one
should be expanded. --- (v7) If these are different entities,
our only concern is the role of the "PM Experts".
3. RTCP-XR metrics are currently referred to as "end-point", and 2. We should expand on the different roles and responsibilities of
have aspects that are similar to active (the measured stream the Performance Metrics Experts versus the Performance Metric
characteristics are known a priori and measurement commonly Directorate. At least, the Performance Metric Directorate one
takes place at the end-points of the path) and passive (there is should be expanded. --- (v7) If these are different entities, our
no additional traffic dedicated to measurement, with the only concern is the role of the "PM Experts".
exception of the RTCP report packets themselves). We have one
example expressing an end-point metric in the active sub-
registry memo.
4. Revised Registry Entries: Keep for history (deprecated) or 3. Revised Registry Entries: Keep for history (deprecated) or
Delete? Delete?
5. Need to include an example for a name for a passive metric 4. Need to include an example for a name for a passive metric
6. Definition of Parameter needs more work? 5. Definition of Parameter needs more work?
7. Whether the name of the metric should contain the version of the 6. Whether the name of the metric should contain the version of the
metric metric
8. Suppression Flag for the metrics, does it belong to the 7. reserve some values for examples and private use?
registry? If yes, is ti part of the core or the active one?
9. Endpoint metric: I think we need either to remove it from the 8. should we define a "type" column with the possible values
draft or to properly define it. Currently in the draft we have "active" "passive" "hybrid" "endpoint"? if we go for all 4 of
it as a equal to passive and active but it is not defined, which them, we should define the corresponding prefixes for the metric
seems incoherent. name (at this point only the pas and act are defined)
10. URL: should we include a URL link in each registry entry with a 9. URL: should we include a URL link in each registry entry with a
URL specific to the entry that links to a different text page URL specific to the entry that links to a different text page
that contains all the details of the registry entry as in that contains all the details of the registry entry as in
http://www.iana.org/assignments/xml-registry/xml- http://www.iana.org/assignments/xml-registry/xml-
registry.xhtml#ns registry.xhtml#ns
2. Introduction 2. Introduction
The IETF specifies and uses Performance Metrics of protocols and The IETF specifies and uses Performance Metrics of protocols and
applications transported over its protocols. Performance metrics are applications transported over its protocols. Performance metrics are
such an important part of the operations of IETF protocols that such an important part of the operations of IETF protocols that
[RFC6390] specifies guidelines for their development. [RFC6390] specifies guidelines for their development.
The definition and use of Performance Metrics in the IETF happens in The definition and use of Performance Metrics in the IETF happens in
various working groups (WG), most notably: various working groups (WG), most notably:
skipping to change at page 4, line 47 skipping to change at page 5, line 5
act on) a particular Performance Metric, then both parties have act on) a particular Performance Metric, then both parties have
exactly the same understanding of what Performance Metric is being exactly the same understanding of what Performance Metric is being
referred to. Second, how to discover which Performance Metrics have referred to. Second, how to discover which Performance Metrics have
been specified, so as to avoid developing new Performance Metric that been specified, so as to avoid developing new Performance Metric that
is very similar. The problems can be addressed by creating a is very similar. The problems can be addressed by creating a
registry of performance metrics. The usual way in which IETF registry of performance metrics. The usual way in which IETF
organizes namespaces is with Internet Assigned Numbers Authority organizes namespaces is with Internet Assigned Numbers Authority
(IANA) registries, and there is currently no Performance Metrics (IANA) registries, and there is currently no Performance Metrics
Registry maintained by the IANA. Registry maintained by the IANA.
This document therefore proposes the creation of a Performance This document therefore creates a Performance Metrics Registry. It
Metrics Registry. It also provides best practices on how to define also provides best practices on how to define new or updated entries
new or updated entries in the Performance Metrics Registry. in the Performance Metrics Registry.
3. Terminology 3. Terminology
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described in "OPTIONAL" in this document are to be interpreted as described in
[RFC2119]. [RFC2119].
The terms Performance Metric and Performance Metrics Directorate are The terms Performance Metric and Performance Metrics Directorate are
defined in [RFC6390], and copied over in this document for the defined in [RFC6390], and copied over in this document for the
skipping to change at page 6, line 49 skipping to change at page 7, line 4
combination of Active Measurement and Passive Measurement methods. combination of Active Measurement and Passive Measurement methods.
4. Scope 4. Scope
The intended audience of this document includes those who prepare and The intended audience of this document includes those who prepare and
submit a request for a Registered Performance Metric, and for the submit a request for a Registered Performance Metric, and for the
Performance Metric Experts who review a request. Performance Metric Experts who review a request.
This document specifies a Performance Metrics Registry in IANA. This This document specifies a Performance Metrics Registry in IANA. This
Performance Metric Registry is applicable to Performance Metrics Performance Metric Registry is applicable to Performance Metrics
issued from Active Measurement, Passive Measurement, or from end- issued from Active Measurement, Passive Measurement, from end-point
point calculation. This registry is designed to encompass calculation or any other form of Performance Metric. This registry
performance metrics developed throughout the IETF and especially for is designed to encompass Performance Metrics developed throughout the
the following existing working groups: IPPM, XRBLOCK, IPFIX, and IETF and especially for the following existing working groups: IPPM,
BMWG. This document analyzes an prior attempt to set up a XRBLOCK, IPFIX, and BMWG. This document analyzes an prior attempt to
Performance Metric Registry, and the reasons why this design was set up a Performance Metric Registry, and the reasons why this design
inadequate [RFC6248]. Finally, this document gives a set of was inadequate [RFC6248]. Finally, this document gives a set of
guidelines for requesters and expert reviewers of candidate guidelines for requesters and expert reviewers of candidate
Registered Performance Metrics. Registered Performance Metrics.
This document serves as the foundation for further work. It
specifies the set of columns describing common aspects necessary for
all entries in the Performance Metrics Registry.
Two documents describing sub-registries will be developed separately:
one for Active Registered Metrics and another one for the Passive
Registered Metrics. Indeed, Active and Passive Performance Metrics
appear to have different characteristics that must be documented in
their respective sub-registies. For example, Active Performance
Methods must specify the packet stream characteristics they generate
and measure, so it is essential to include the stream specifications
in the Registry entry. In the case of Passive Performance Metrics,
there is a need to specify the sampling distribution in the Registry.
While it would be possible to force the definition of the Registry
field to include both types of distributions in the same Registry
column, we believe it is cleaner and clearer to have separated sub-
registries with different columns that have a narrow definition.
It is possible that future Performance Metrics use Hybrid Measurement
methods, and it may be possible to register hybrid metrics in one of
the two planned sub-registries (active or passive), or it may be
efficient to define a third sub-registry with unique columns. The
current design with sub-registries allows for growth, and this is a
recognized option for extension.
This document makes no attempt to populate the Registry with initial This document makes no attempt to populate the Registry with initial
entries. entries. It does provides a few examples that are merely
illustrations and should not be included in the registry at this
point in time.
Based on [RFC5226] Section 4.3, this document is processed as Best Based on [RFC5226] Section 4.3, this document is processed as Best
Current Practice (BCP) [RFC2026]. Current Practice (BCP) [RFC2026].
5. Design Considerations for the Registry and Registered Metrics 5. Design Considerations for the Registry and Registered Metrics
In this section, we detail several design considerations that are In this section, we detail several design considerations that are
relevant for understanding the motivations and expected use of the relevant for understanding the motivations and expected use of the
Performance Metric Registry. Performance Metric Registry.
skipping to change at page 11, line 4 skipping to change at page 10, line 27
identified in the previous attempt. As we mention in the previous identified in the previous attempt. As we mention in the previous
section, one of the main issues with the previous registry was that section, one of the main issues with the previous registry was that
the metrics contained in the registry were too generic to be useful. the metrics contained in the registry were too generic to be useful.
In this Registry, the Registry requests are evaluated by an expert In this Registry, the Registry requests are evaluated by an expert
group, the Performance Metrics Experts, who will make sure that the group, the Performance Metrics Experts, who will make sure that the
metric is properly defined. This document provides guidelines to metric is properly defined. This document provides guidelines to
assess if a metric is properly defined. assess if a metric is properly defined.
Another key difference between this attempt and the previous one is Another key difference between this attempt and the previous one is
that in this case there is at least one clear user for the Registry: that in this case there is at least one clear user for the Registry:
the LMAP framework and protocol. Because the LMAP protocol will use the LMAP framework and protocol. Because the LMAP protocol will use
the Registry values in its operation, this actually helps to the Registry values in its operation, this actually helps to
determine if a metric is properly defined. In particular, since we determine if a metric is properly defined. In particular, since we
expect that the LMAP control protocol will enable a controller to expect that the LMAP control protocol will enable a controller to
request a measurement agent to perform a measurement using a given request a measurement agent to perform a measurement using a given
metric by embedding the Performance Metric Registry value in the metric by embedding the Performance Metric Registry value in the
protocol, a metric is properly specified if it is defined well-enough protocol, a metric is properly specified if it is defined well-enough
so that it is possible (and practical) to implement the metric in the so that it is possible (and practical) to implement the metric in the
measurement agent. This was clearly not the case for the previous measurement agent. This was clearly not the case for the previous
attempt: defining a metric with an undefined P-Type makes its attempt: defining a metric with an undefined P-Type makes its
implementation unpractical. implementation unpractical.
7. Common Columns of the Performance Metric Registry 7. Defintion of the Performance Metric Registry
The Performance Metric Registry is composed of two sub-registries: In this section we define the columns of the Performance Metric
the registry for Active Performance Metrics and the registry for Registry. This registry will contain all Registered Performance
Passive Performance Metrics. The rationale for having two sub- Metrics including active, passive, hybrid, endpoint metrics and any
registries (as opposed to having a single registry for all metrics) other type of performance metric that can be envisioned. Because of
is because the set of registry columns must support unambiguous that, it may be the case that some of the columns defined are not
registry entries, and there are fundamental differences in the applicable for a given type of metric. If this is the case, the
methods to collect active and passive metrics and the required input column(s) SHOULD be populated with the "NA" value (Non Applicable).
parameters. Forcing them into a single, generalized registry would However, the "NA" value MUST NOT be used any any metric in the
result in a less meaningful structure for some entries in the following columns: Identifier, Name, URI, Status, Requester,
registry. Nevertheless, it is desirable that the two sub-registries Revision, Revision Date, Description and Reference Specification.
share the same structure as much as possible. In particular, both Moreover, In addition, it may be possible that in the future, a new
registries will share the following columns: the identifier and the type of metric requires additional columns. Should that be the case,
name, the requester, the revision, the revision date and the it is possible to add new columns to the registry. The specification
description. All these fields are described below. The design of defining the new column(s) MUST define how to populate the new
these two sub-registries is work-in-progress. column(s) for existing entries.
7.1. Identifier The columns of the Performance Metric Registry are defined next. The
columns are grouped into "Categories" to facilitate the use of the
registry. Categories are described at the 3.x heading level, and
columns are at the 3.x.y heading level. The Figure below illustrates
this organization. An entry (row) therefore gives a complete
description of a Registered Metric.
Each column serves as a check-list item and helps to avoid omissions
during registration and expert review. In some cases an entry (row)
may have some columns without specific entries, marked Not Applicable
(NA).
Registry Categories and Columns, shown as
Category
------------------
Column | Column |
Summary
-------------------------------
ID | Name | URI | Description |
Metric Definition
-----------------------------------------
Reference Definition | Fixed Parameters |
Method of Measurement
---------------------------------------------------------------------------------
Reference Method | Packet Generation | Traffic | Sampling | Run-time | Role |
| Stream | Filter | distribution | Param | |
Output
-----------------------------------------
| Type | Reference | Data | Units |
| | Definition | Format | |
Administrative information
----------------------------------
Status |Request | Rev | Rev.Date |
Comments and Remarks
--------------------
7.1. Summary Category
7.1.1. Identifier
A numeric identifier for the Registered Performance Metric. This A numeric identifier for the Registered Performance Metric. This
identifier MUST be unique within the Performance Metric Registry and identifier MUST be unique within the Performance Metric Registry.
sub-registries.
The Registered Performance Metric unique identifier is a 16-bit The Registered Performance Metric unique identifier is a 16-bit
integer (range 0 to 65535). When adding newly Registered Performance integer (range 0 to 65535). When adding newly Registered Performance
Metrics to the Performance Metric Registry, IANA SHOULD assign the Metrics to the Performance Metric Registry, IANA SHOULD assign the
lowest available identifier to the next active monitoring Registered lowest available identifier to the next Registered Performance
Performance Metric, and the highest available identifier to the next Metric.
passive monitoring Registered Performance Metric.
7.2. Name 7.1.2. Name
As the name of a Registered Performance Metric is the first thing a As the name of a Registered Performance Metric is the first thing a
potential implementor will use when determining whether it is potential implementor will use when determining whether it is
suitable for a given application, it is important to be as precise suitable for a given application, it is important to be as precise
and descriptive as possible. New names of Registered Performance and descriptive as possible. New names of Registered Performance
Metrics: Metrics:
1. "MUST be chosen carefully to describe the Registered Performance 1. "MUST be chosen carefully to describe the Registered Performance
Metric and the context in which it will be used." Metric and the context in which it will be used."
2. "MUST be unique within the Performance Metric Registry (including 2. "MUST be unique within the Performance Metric Registry."
sub-registries)."
3. "MUST use capital letters for the first letter of each component 3. "MUST use capital letters for the first letter of each component
. All other letters MUST be lowercase, even for acronyms. . All other letters MUST be lowercase, even for acronyms.
Exceptions are made for acronyms containing a mixture of Exceptions are made for acronyms containing a mixture of
lowercase and capital letters, such as 'IPv4' and 'IPv6'." lowercase and capital letters, such as 'IPv4' and 'IPv6'."
4. "MUST use '_' between each component composing the Registered 4. "MUST use '_' between each component composing the Registered
Performance Metric name." Performance Metric name."
5. "MUST start with prefix Act_ for active measurement Registered 5. "MUST start with prefix Act_ for active measurement Registered
Performance Metric." Performance Metric."
6. "MUST start with prefix Pass_ for passive monitoring Registered 6. "MUST start with prefix Pas_ for passive monitoring Registered
Performance Metric." AL COMMENTS: how about just 3 letters for Performance Metric."
consistency: "Pas_"
7. The remaining rules for naming are left to the Performance 7. Other types of metrics should define a proper prefix for
identifying the type.
8. The remaining rules for naming are left to the Performance
Experts to determine as they gather experience, so this is an Experts to determine as they gather experience, so this is an
area of planned update by a future RFC. area of planned update by a future RFC.
An example is "Act_UDP_Latency_Poisson_99mean" for a active An example is "Act_UDP_Latency_Poisson_99mean" for a active
monitoring UDP latency metric using a Poisson stream of packets and monitoring UDP latency metric using a Poisson stream of packets and
producing the 99th percentile mean as output. producing the 99th percentile mean as output.
>>>> NEED passive naming examples. 7.1.3. URI
7.3. URI
The URI column MUST contain a URI [RFC 3986] that uniquely identified The URI column MUST contain a URI [RFC 3986] that uniquely identified
the metric. The URI is a URN [RFC 2141]. The URI is automatically the metric. The URI is a URN [RFC 2141]. The URI is automatically
generated by prepending the prefix urn:ietf:params:ippm:metric: to generated by prepending the prefix urn:ietf:params:ippm:metric: to
the metric name. The resulting URI is globally unique. the metric name. The resulting URI is globally unique.
7.4. Status 7.1.4. Description
A Registered Performance Metric Description is a written
representation of a particular Registry entry. It supplements the
metric name to help Registry users select relevant Registered
Performance Metrics.
7.2. Metric Definition Category
This category includes columns to prompt all necessary details
related to the metric definition, including the RFC reference and
values of input factors, called fixed parameters, which are left open
in the RFC but have a particular value defined by the performance
metric.
7.2.1. Reference Definition
This entry provides a reference (or references) to the relevant
section(s) of the document(s) that define the metric, as well as any
supplemental information needed to ensure an unambiguous definition
for implementations. The reference needs to be an immutable
document, such as an RFC; for other standards bodies, it is likely to
be necessary to reference a specific, dated version of a
specification.
7.2.2. Fixed Parameters
Fixed Parameters are input factors whose value must be specified in
the Registry. The measurement system uses these values.
Where referenced metrics supply a list of Parameters as part of their
descriptive template, a sub-set of the Parameters will be designated
as Fixed Parameters. For example, for active metrics, Fixed
Parameters determine most or all of the IPPM Framework convention
"packets of Type-P" as described in [RFC2330], such as transport
protocol, payload length, TTL, etc. An example for passive metrics
is for RTP packet loss calculation that relies on the validation of a
packet as RTP which is a multi-packet validation controlled by
MIN_SEQUENTIAL as defined by [RFC3550]. Varying MIN_SEQUENTIAL
values can alter the loss report and this value could be set as a
fixed parameter
A Parameter which is Fixed for one Registry entry may be designated
as a Run-time Parameter for another Registry entry.
7.3. Method of Measurement Category
This category includes columns for references to relevant sections of
the RFC(s) and any supplemental information needed to ensure an
unambiguous method for implementations.
7.3.1. Reference Method
This entry provides references to relevant sections of the RFC(s)
describing the method of measurement, as well as any supplemental
information needed to ensure unambiguous interpretation for
implementations referring to the RFC text.
Specifically, this section should include pointers to pseudocode or
actual code that could be used for an unambigious implementation.
7.3.2. Packet Generation Stream
This column applies to metrics that generate traffic for measurement
purposes including but not necessarily limited to Active metrics.
The generated traffic is referred as stream and this columns describe
its characteristics. Principally, two different streams are used in
IPPM metrics, Poisson distributed as described in [RFC2330] and
Periodic as described in [RFC3432]. Both Poisson and Periodic have
their own unique parameters, and the relevant set of values is
specified in this column.
Each entry for this column contains the following information:
o Value: The name of the packet stream scheduling discipline
o Stream Parameters: The values and formats of input factors for
each type of stream. For example, the average packet rate and
distribution truncation value for streams with Poisson-distributed
inter-packet sending times.
o Reference: the specification where the stream is defined
The simplest example of stream specification is Singleton scheduling,
where a single atomic measurement is conducted. Each atomic
measurement could consist of sending a single packet (such as a DNS
request) or sending several packets (for example, to request a
webpage). Other streams support a series of atomic measurements in a
"sample", with a schedule defining the timing between each
transmitted packet and subsequent measurement.
7.3.3. Traffic Filter
This column applies to metrics that observe packets flowing in the
wire i.e. that is not specifically addressed to the measurement
agent. This includes but is not limited to Passive Metrics. The
filter specifies the traffic constraints that the passive measurement
method used is valid (or invalid) for. This includes valid packet
sampling ranges, width of valid traffic matches (eg. all traffic on
interface, UDP packets packets in a flow (eg. same RTP session).
It is possible that the measurement method may not have a specific
limitation. However, this specific registry entry with it's
combination of fixed parameters implies restrictions. These
restrictions would be listed in this field.
7.3.4. Sampling distribution
The sampling distribution defines out of all the packets that match
the traffic filter, which one of those are actually used for the
measurement. One possibility is "all" which implies that all packets
matching the Traffic filter are considered, but there may be other
sampling strategies. It includes the following information:
Value: the name of the sampling distribution
Parameters: if any.
Reference definition: pointer to the specification where the
sampling distribution is properly defined.
7.3.5. Run-time Parameters
Run-Time Parameters are input factors that must be determined,
configured into the measurement system, and reported with the results
for the context to be complete. However, the values of these
parameters is not specified in the Registry, rather these parameters
are listed as an aid to the measurement system implementor or user
(they must be left as variables, and supplied on execution).
Where metrics supply a list of Parameters as part of their
descriptive template, a sub-set of the Parameters will be designated
as Run-Time Parameters.
A Data Format of each Run-time Parameter SHALL be specified in this
column, to simplify the control and implementation of measurement
devices.
Examples of Run-time Parameters include IP addresses, measurement
point designations, start times and end times for measurement, and
other information essential to the method of measurement.
7.3.6. Role
In some method of measurements, there may be several roles defined
e.g. on a one-way packet delay active measurement, there is one
measurement agent that generates the packets and the other one that
receives the packets. This column contains the name of the role for
this particular entry. In the previous example, there should be two
entries int he registry, one for each role, so that when a
measurement agent is instructed to perform the one way delay source
metric know that it is supposed to generate packets. The values for
this field are defined in the reference method of measurement.
7.4. Output Category
For entries which involve a stream and many singleton measurements, a
statistic may be specified in this column to summarize the results to
a single value. If the complete set of measured singletons is
output, this will be specified here.
Some metrics embed one specific statistic in the reference metric
definition, while others allow several output types or statistics.
7.4.1. Value
This column contain the name of the output type. The output type
defines the type of result that the metric produces. It can be the
raw results or it can be some form of statistic. The specification
of the output type must define the format of the output. In some
systems, format specifications will simplify both measurement
implementation and collection/storage tasks. Note that if two
different statistics are required from a single measurement (for
example, both "Xth percentile mean" and "Raw"), then a new output
type must be defined ("Xth percentile mean AND Raw").
7.4.2. Data Format
This column provides the data format for the output. It is provided
to simplify the communication with collection systems and
implementation of measurement devices.
7.4.3. Reference
This column contains a pointer to the specification where the output
type is defined
7.4.4. Metric Units
The measured results must be expressed using some standard dimension
or units of measure. This column provides the units.
When a sample of singletons (see [RFC2330] for definitions of these
terms) is collected, this entry will specify the units for each
measured value.
7.5. Admisnitratvie information
7.5.1. Status
The status of the specification of this Registered Performance The status of the specification of this Registered Performance
Metric. Allowed values are 'current' and 'deprecated'. All newly Metric. Allowed values are 'current' and 'deprecated'. All newly
defined Information Elements have 'current' status. defined Information Elements have 'current' status.
7.5. Requester 7.5.2. Requester
The requester for the Registered Performance Metric. The requester The requester for the Registered Performance Metric. The requester
MAY be a document, such as RFC, or person. MAY be a document, such as RFC, or person.
7.6. Revision 7.5.3. Revision
The revision number of a Registered Performance Metric, starting at 0 The revision number of a Registered Performance Metric, starting at 0
for Registered Performance Metrics at time of definition and for Registered Performance Metrics at time of definition and
incremented by one for each revision. incremented by one for each revision.
7.7. Revision Date 7.5.4. Revision Date
The date of acceptance or the most recent revision for the Registered The date of acceptance or the most recent revision for the Registered
Performance Metric. Performance Metric.
7.8. Description 7.6. Comments and Remarks
A Registered Performance Metric Description is a written
representation of a particular Registry entry. It supplements the
metric name to help Registry users select relevant Registered
Performance Metrics.
7.9. Reference Specification(s)
Registry entries that follow the common columns must provide the Besides providing additional details which do not appear in other
reference specification(s) on which the Registered Performance Metric categories, this open Category (single column) allows for unforeseen
is based. issues to be addressed by simply updating this Informational entry.
8. The Life-Cycle of Registered Metrics 8. The Life-Cycle of Registered Metrics
Once a Performance Metric or set of Performance Metrics has been Once a Performance Metric or set of Performance Metrics has been
identified for a given application, candidate Registry entry identified for a given application, candidate Registry entry
specifications in accordance with Section X are submitted to IANA to specifications in accordance with Section 7 are submitted to IANA to
follow the process for review by the Performance Metric Experts, as follow the process for review by the Performance Metric Experts, as
defined below. This process is also used for other changes to the defined below. This process is also used for other changes to the
Performance Metric Registry, such as deprecation or revision, as Performance Metric Registry, such as deprecation or revision, as
described later in this section. described later in this section.
It is also desirable that the author(s) of a candidate Registry entry It is also desirable that the author(s) of a candidate Registry entry
seek review in the relevant IETF working group, or offer the seek review in the relevant IETF working group, or offer the
opportunity for review on the WG mailing list. opportunity for review on the WG mailing list.
8.1. The Process for Review by the Performance Metric Experts 8.1. Adding new Performance Metrics to the Registry
Requests to change Registered Metrics in the Performance Metric Requests to change Registered Metrics in the Performance Metric
Registry or a linked sub-registry are submitted to IANA, which Registry are submitted to IANA, which forwards the request to a
forwards the request to a designated group of experts (Performance designated group of experts (Performance Metric Experts) appointed by
Metric Experts) appointed by the IESG; these are the reviewers called the IESG; these are the reviewers called for by the Expert Review
for by the Expert Review RFC5226 policy defined for the Performance RFC5226 policy defined for the Performance Metric Registry. The
Metric Registry. The Performance Metric Experts review the request Performance Metric Experts review the request for such things as
for such things as compliance with this document, compliance with compliance with this document, compliance with other applicable
other applicable Performance Metric-related RFCs, and consistency Performance Metric-related RFCs, and consistency with the currently
with the currently defined set of Registered Performance Metrics. defined set of Registered Performance Metrics.
Authors are expected to review compliance with the specifications in Authors are expected to review compliance with the specifications in
this document to check their submissions before sending them to IANA. this document to check their submissions before sending them to IANA.
The Performance Metric Experts should endeavor to complete referred The Performance Metric Experts should endeavor to complete referred
reviews in a timely manner. If the request is acceptable, the reviews in a timely manner. If the request is acceptable, the
Performance Metric Experts signify their approval to IANA, which Performance Metric Experts signify their approval to IANA, which
changes the Performance Metric Registry. If the request is not changes the Performance Metric Registry. If the request is not
acceptable, the Performance Metric Experts can coordinate with the acceptable, the Performance Metric Experts can coordinate with the
requester to change the request to be compliant. The Performance requester to change the request to be compliant. The Performance
skipping to change at page 17, line 16 skipping to change at page 22, line 37
This draft doesn't introduce any new security considerations for the This draft doesn't introduce any new security considerations for the
Internet. However, the definition of Performance Metrics may Internet. However, the definition of Performance Metrics may
introduce some security concerns, and should be reviewed with introduce some security concerns, and should be reviewed with
security in mind. security in mind.
11. IANA Considerations 11. IANA Considerations
This document specifies the procedure for Performance Metrics This document specifies the procedure for Performance Metrics
Registry setup. IANA is requested to create a new Registry for Registry setup. IANA is requested to create a new Registry for
Performance Metrics called "Registered Performance Metrics". Performance Metrics called "Registered Performance Metrics" with the
columns defined in Section 7.
This Performance Metrics Registry contains two sub registries once
for active and another one for Passive Performance Metrics. These
sub registries are not defined in this document. However, these two
sub registries MUST contain the common columns defined in Section 7.
New assignments for Performance Metric Registry will be administered New assignments for Performance Metric Registry will be administered
by IANA through Expert Review [RFC5226], i.e., review by one of a by IANA through Expert Review [RFC5226], i.e., review by one of a
group of experts, the Performance Metric Experts, appointed by the group of experts, the Performance Metric Experts, appointed by the
IESG upon recommendation of the Transport Area Directors. The IESG upon recommendation of the Transport Area Directors. The
experts will initially be drawn from the Working Group Chairs and experts will initially be drawn from the Working Group Chairs and
document editors of the Performance Metrics Directorate [performance- document editors of the Performance Metrics Directorate [performance-
metrics-directorate]. metrics-directorate].
This document requests the allocation of the URI prefix This document requests the allocation of the URI prefix
skipping to change at page 18, line 48 skipping to change at page 24, line 23
Applications", STD 64, RFC 3550, July 2003. Applications", STD 64, RFC 3550, July 2003.
[RFC6035] Pendleton, A., Clark, A., Johnston, A., and H. Sinnreich, [RFC6035] Pendleton, A., Clark, A., Johnston, A., and H. Sinnreich,
"Session Initiation Protocol Event Package for Voice "Session Initiation Protocol Event Package for Voice
Quality Reporting", RFC 6035, November 2010. Quality Reporting", RFC 6035, November 2010.
[I-D.ietf-lmap-framework] [I-D.ietf-lmap-framework]
Eardley, P., Morton, A., Bagnulo, M., Burbridge, T., Eardley, P., Morton, A., Bagnulo, M., Burbridge, T.,
Aitken, P., and A. Akhter, "A framework for large-scale Aitken, P., and A. Akhter, "A framework for large-scale
measurement platforms (LMAP)", draft-ietf-lmap- measurement platforms (LMAP)", draft-ietf-lmap-
framework-07 (work in progress), June 2014. framework-08 (work in progress), August 2014.
[RFC5477] Dietz, T., Claise, B., Aitken, P., Dressler, F., and G.
Carle, "Information Model for Packet Sampling Exports",
RFC 5477, March 2009.
[RFC5102] Quittek, J., Bryant, S., Claise, B., Aitken, P., and J.
Meyer, "Information Model for IP Flow Information Export",
RFC 5102, January 2008.
[RFC6792] Wu, Q., Hunt, G., and P. Arden, "Guidelines for Use of the
RTP Monitoring Framework", RFC 6792, November 2012.
[RFC5905] Mills, D., Martin, J., Burbank, J., and W. Kasch, "Network
Time Protocol Version 4: Protocol and Algorithms
Specification", RFC 5905, June 2010.
[RFC3393] Demichelis, C. and P. Chimento, "IP Packet Delay Variation
Metric for IP Performance Metrics (IPPM)", RFC 3393,
November 2002.
[RFC6776] Clark, A. and Q. Wu, "Measurement Identity and Information
Reporting Using a Source Description (SDES) Item and an
RTCP Extended Report (XR) Block", RFC 6776, October 2012.
[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.
[RFC3432] Raisanen, V., Grotefeld, G., and A. Morton, "Network
performance measurement with periodic streams", RFC 3432,
November 2002.
[RFC4566] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session
Description Protocol", RFC 4566, July 2006.
[RFC5481] Morton, A. and B. Claise, "Packet Delay Variation
Applicability Statement", RFC 5481, March 2009.
Authors' Addresses Authors' Addresses
Marcelo Bagnulo Marcelo Bagnulo
Universidad Carlos III de Madrid Universidad Carlos III de Madrid
Av. Universidad 30 Av. Universidad 30
Leganes, Madrid 28911 Leganes, Madrid 28911
SPAIN SPAIN
Phone: 34 91 6249500 Phone: 34 91 6249500
skipping to change at page 19, line 26 skipping to change at page 25, line 36
Benoit Claise Benoit Claise
Cisco Systems, Inc. Cisco Systems, Inc.
De Kleetlaan 6a b1 De Kleetlaan 6a b1
1831 Diegem 1831 Diegem
Belgium Belgium
Email: bclaise@cisco.com Email: bclaise@cisco.com
Philip Eardley Philip Eardley
British Telecom BT
Adastral Park, Martlesham Heath Adastral Park, Martlesham Heath
Ipswich Ipswich
ENGLAND ENGLAND
Email: philip.eardley@bt.com Email: philip.eardley@bt.com
Al Morton Al Morton
AT&T Labs AT&T Labs
200 Laurel Avenue South 200 Laurel Avenue South
Middletown, NJ Middletown, NJ
USA USA
Email: acmorton@att.com Email: acmorton@att.com
Aamer Akhter
Cisco Systems, Inc.
7025 Kit Creek Road
RTP, NC 27709
USA
Email: aakhter@cisco.com
 End of changes. 46 change blocks. 
173 lines changed or deleted 422 lines changed or added

This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/