Registry for Performance Metrics
Extracted elements (25)
The design consciously favors a small set of well-defined, useful metrics over a large set with questionable usefulness ('less is more'). Each Registry Entry has only a few variable Runtime Parameters; the acknowledged downside is potentially many entries, but each must be actionable by a Measurement Agent.
The LMAP framework is cited as the primary driver for the new registry's success: the LMAP Control Protocol will embed Performance Metrics Registry Identifiers in protocol messages, requiring metrics to be precisely enough defined for a Measurement Agent to implement them. This operational constraint prevents the vagueness that doomed RFC 4148's undefined Type-P.
The prior IPPM Metrics Registry (RFC 4148) was obsoleted because it was insufficiently detailed to uniquely identify metrics — too much variability was possible in characterizing a metric exactly — and had very few users. The new registry imposes stricter registration criteria and a group of Performance Metrics Experts to prevent the same outcome.
A revision to a Registered Performance Metric is backward compatible if it corrects only editorial errors, resolves usage-blocking ambiguities, adds missing information without changing meaning, harmonizes with a corrected external reference, or fills in a new non-applicable column. The Name's RFCXXXXsecY portion SHALL remain unchanged for backward-compatible revisions.
The LMAP framework allows use of not only the IANA Performance Metrics Registry but also other registries from other organizations or private registries. Organizations creating such registries for LMAP contexts are encouraged to use the Registry format defined in this document to simplify Measurement Agent implementations that programmatically consume registry entries.
A data format for each Runtime Parameter MUST be specified in the Runtime Parameters column. IPv6 addresses and options MUST be accommodated in all Registered Performance Metrics, allowing use in that address family; other address families are permissible.
A Registered Performance Metric SHOULD be interpretable by users, implementable by designers, deployable by operators, accurate across vendors, operationally useful with significant industry interest or deployment, and sufficiently tightly defined so that Runtime Parameter variations do not change the fundamental nature of the measurement.
Changes to Registered Performance Metrics may only be made in an interoperable way; changes that cannot maintain interoperability with unchanged implementations MUST result in creation of a new Registered Performance Metric with a new Name (replacing the RFCXXXXsecY portion) and possibly deprecation of the earlier metric.
Parameters MUST have well-defined names and a well-specified data format. Any Parameter names and definitions that do not appear in the Reference Method Specification MUST appear in the Fixed Parameters or Runtime Parameters column of the Registry Entry.
Requests to add Registered Performance Metrics SHALL be submitted to IANA and forwarded to Performance Metrics Experts under the Specification Required policy. If registration criteria in Section 5 have not been met, the proposed Registry Entry MUST be removed from the submitting RFC's text until criteria are satisfied.
The Identifier of each Registered Performance Metric MUST be unique. IANA SHOULD assign the lowest available Identifier to new entries; Identifier 0 is Reserved, and values 64512–65535 are reserved for private or experimental use where overlapping use may occur.
The 'N/A' (Not Applicable) value MUST NOT be used in the Identifier, Name, URI, Status, Requester, Revision, Revision Date, or Description columns; columns in other categories that are inapplicable to a given metric category SHOULD be populated with 'N/A'.
The Registry Format Version defined in this memo is 1.0, and candidate Registry Entries complying with this memo MUST use 1.0. The Registry Format can only be updated by publishing a new RFC via Standards Action; extensions are limited to adding new columns or categories.
The URI column MUST contain a URL that uniquely identifies and locates the Metric Entry so it is accessible through the Internet; the URL SHALL reference a target file that is preferably HTML-formatted with links to referenced RFC sections.
When deprecating a Performance Metric, the Description in the Registry MUST be updated to explain the deprecation and refer to the new replacement metric. Names and Metric IDs of deprecated Registered Performance Metrics must not be reused.
Each Performance Metrics Registry Entry is organized into six categories: Summary, Metric Definition, Method of Measurement, Output, Administrative Information, and Comments and Remarks. Each category contains specific columns that together provide a complete, unambiguous description of a Registered Performance Metric.
Fixed Parameters have values specified in the Registry Entry and different values yield different Registered Performance Metrics. Runtime Parameters are not specified in the Registry, are supplied at execution time, and must be reported with Measurement Results so that full context is preserved.
Performance Metric Names follow the structured convention MetricType_Method_SubTypeMethod_Spec_Units_Output, with elements separated by underscores and SubTypeMethod sub-elements separated by hyphens. Names starting with 'Priv_' are reserved for private use and are not accepted for IANA registration.
The Calibration column identifies a method of error calibration for the metric, including in-situ internal loopback calibration and, for one-way delay measurements, mandatory assessment of internal clock synchronization with its external reference.
The Role column names Measurement Agent roles (e.g., Source and Destination for one-way delay Active Measurement). When a Registry Entry defines more than one Role, the Role SHALL be treated as a Runtime Parameter and supplied for execution.
The Status field allows three values: 'Current' (all newly defined metrics), 'Deprecated' (replaced by a backward- or non-backward-compatible revision), and 'Obsolete' (contains errors or has critical references designated obsolete, with no replacement). Deprecated entries are retained with all Administrative columns unmodified except Status.
The Traffic Filter column specifies which packets are observed for Passive Metrics, using Type (e.g., BPF, PSAMP, OpenFlow) and Value (actual filter rules). The filter balances the operator's measurement needs against the user's need for privacy.
IANA has created and maintains the Performance Metrics Registry Group at https://www.iana.org/assignments/performance-metrics. New assignments use the Specification Required policy with review by Performance Metrics Experts appointed by the IESG upon recommendation of the Transport Area Directors.
IANA has created registries for each Performance Metric Name Element: MetricType, Method, SubTypeMethod, Spec, Units, and Output. Name Elements are case sensitive and managed under the Specification Required policy; new values require Expert Review.
The Registry structure itself does not introduce new security considerations for the Internet. However, aggregated results of Performance Metrics described in this Registry might reveal network topology information considered sensitive; access control mechanisms should be applied in such cases.