rfc8911xml2.original.xml   rfc8911.xml 
<?xml version="1.0" encoding="US-ASCII"?> <?xml version='1.0' encoding='utf-8'?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd"> <!DOCTYPE rfc [
<?xml-stylesheet type='text/xsl' href='rfc2629.xslt' ?> <!ENTITY nbsp "&#160;">
<?rfc toc="yes" ?> <!ENTITY zwsp "&#8203;">
<?rfc symrefs="yes" ?> <!ENTITY nbhy "&#8209;">
<?rfc strict="no" ?> <!ENTITY wj "&#8288;">
<?rfc strict="no" ?> ]>
<rfc category="std" docName="draft-ietf-ippm-metric-registry-24" <rfc xmlns:xi="http://www.w3.org/2001/XInclude" category="std"
ipr="trust200902" obsoletes="" updates=""> docName="draft-ietf-ippm-metric-registry-24" number="8911"
ipr="trust200902" obsoletes="" updates="" submissionType="IETF"
consensus="true" xml:lang="en" tocInclude="true" symRefs="true"
sortRefs="true" version="3">
<!-- xml2rfc v2v3 conversion 2.42.0 -->
<front> <front>
<title abbrev="Registry for Performance Metrics">Registry for Performance <title abbrev="Registry for Performance Metrics">Registry for Performance
Metrics</title> Metrics</title>
<seriesInfo name="RFC" value="8911"/>
<author fullname="Marcelo Bagnulo" initials="M." surname="Bagnulo"> <author fullname="Marcelo Bagnulo" initials="M." surname="Bagnulo">
<organization abbrev="UC3M">Universidad Carlos III de <organization abbrev="UC3M">Universidad Carlos III de
Madrid</organization> Madrid</organization>
<address> <address>
<postal> <postal>
<street>Av. Universidad 30</street> <street>Av. Universidad 30</street>
<city>Leganes</city> <city>Leganes</city>
<region>Madrid</region> <region>Madrid</region>
<code>28911</code> <code>28911</code>
<country>Spain</country>
<country>SPAIN</country>
</postal> </postal>
<phone>34 91 6249500</phone> <phone>34 91 6249500</phone>
<email>marcelo@it.uc3m.es</email> <email>marcelo@it.uc3m.es</email>
<uri>http://www.it.uc3m.es</uri> <uri>http://www.it.uc3m.es</uri>
</address> </address>
</author> </author>
<author fullname="Benoit Claise" initials="B." surname="Claise"> <author fullname="Benoit Claise" initials="B." surname="Claise">
<organization abbrev="Cisco Systems, Inc.">Cisco Systems, <organization>Huawei</organization>
Inc.</organization>
<address> <address>
<postal> <postal/>
<street>De Kleetlaan 6a b1</street> <email>benoit.claise@huawei.com</email>
<city>1831 Diegem</city>
<country>Belgium</country>
</postal>
<email>bclaise@cisco.com</email>
</address> </address>
</author> </author>
<author fullname="Philip Eardley" initials="P." surname="Eardley"> <author fullname="Philip Eardley" initials="P." surname="Eardley">
<organization abbrev="BT">BT</organization> <organization abbrev="BT">BT</organization>
<address> <address>
<postal> <postal>
<street>Adastral Park, Martlesham Heath</street> <street>Adastral Park, Martlesham Heath</street>
<city>Ipswich</city> <city>Ipswich</city>
<country>United Kingdom</country>
<country>ENGLAND</country>
</postal> </postal>
<email>philip.eardley@bt.com</email> <email>philip.eardley@bt.com</email>
</address> </address>
</author> </author>
<author fullname="Al Morton" initials="A." surname="Morton"> <author fullname="Al Morton" initials="A." surname="Morton">
<organization abbrev="AT&amp;T Labs">AT&amp;T Labs</organization> <organization abbrev="AT&amp;T Labs">AT&amp;T Labs</organization>
<address> <address>
<postal> <postal>
<street>200 Laurel Avenue South</street> <street>200 Laurel Avenue South</street>
<city>Middletown</city>
<city>Middletown, NJ</city> <region>NJ</region>
<code>07748</code>
<country>USA</country> <country>United States of America</country>
</postal> </postal>
<email>acmorton@att.com</email> <email>acmorton@att.com</email>
</address> </address>
</author> </author>
<author fullname="Aamer Akhter" initials="A." surname="Akhter"> <author fullname="Aamer Akhter" initials="A." surname="Akhter">
<organization abbrev="Consultant">Consultant</organization> <organization abbrev="Consultant">Consultant</organization>
<address> <address>
<postal> <postal>
<street>118 Timber Hitch</street> <street>118 Timber Hitch</street>
<city>Cary</city> <city>Cary</city>
<region>NC</region> <region>NC</region>
<code/> <code/>
<country>United States of America</country>
<country>USA</country>
</postal> </postal>
<email>aakhter@gmail.com</email> <email>aakhter@gmail.com</email>
</address> </address>
</author> </author>
<date month="November" year="2021"/>
<date day="9" month="March" year="2020"/> <keyword>IPPM</keyword>
<keyword>Loss</keyword>
<keyword>Delay</keyword>
<abstract> <abstract>
<t>This document defines the format for the IANA Performance Metrics <t>This document defines the format for the IANA Registry of Performance M
Registry. This document also gives a set of guidelines for Registered etrics.
This document also gives a set of guidelines for Registered
Performance Metric requesters and reviewers.</t> Performance Metric requesters and reviewers.</t>
</abstract> </abstract>
</front> </front>
<middle> <middle>
<section title="Introduction"> <section numbered="true" toc="default">
<name>Introduction</name>
<t>The IETF specifies and uses Performance Metrics of protocols and <t>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
important part of network operations using IETF protocols, and <xref an important part of network operations using IETF protocols, and <xref ta
target="RFC6390"/> specifies guidelines for their development.</t> rget="RFC6390" format="default"/> specifies guidelines for their development.</t
>
<t>The definition and use of Performance Metrics in the IETF has been <t>The definition and use of Performance Metrics in the IETF have been
fostered in various working groups (WG), most notably: <list> fostered in various working groups (WGs). Most notably: </t>
<t>The "IP Performance Metrics" (IPPM) WG is the WG primarily <ul empty="false" spacing="normal">
focusing on Performance Metrics definition at the IETF.</t> <li>The "IP Performance Metrics" (IPPM) WG is the WG primarily
focusing on Performance Metrics definition at the IETF.</li>
<t>The "Benchmarking Methodology" WG (BMWG) defines many Performance <li>The "Benchmarking Methodology" WG (BMWG) defines many Performance
Metrics for use in laboratory benchmarking of inter-networking Metrics for use in laboratory benchmarking of internetworking
technologies.</t> technologies.</li>
<li>The "Metric Blocks for use with RTCP's Extended Report Framework"
<t>The "Metric Blocks for use with RTCP's Extended Report Framework"
(XRBLOCK) WG (concluded) specified many Performance Metrics related (XRBLOCK) WG (concluded) specified many Performance Metrics related
to "RTP Control Protocol Extended Reports (RTCP XR)" <xref to "RTP Control Protocol Extended Reports (RTCP XR)" <xref target="RFC
target="RFC3611"/>, which establishes a framework to allow new 3611" format="default"/>, which establishes a framework to allow new
information to be conveyed in RTCP, supplementing the original information to be conveyed in RTCP, supplementing the original
report blocks defined in "RTP: A Transport Protocol for Real-Time report blocks defined in "RTP: A Transport Protocol for Real-Time
Applications", <xref target="RFC3550"/>.</t> Applications" <xref target="RFC3550" format="default"/>.</li>
<li>The "IP Flow Information eXport" (IPFIX) WG (concluded) specified
<t>The "IP Flow Information eXport" (IPFIX) concluded WG specified an Internet Assigned Numbers Authority (IANA) process for new
an IANA process for new Information Elements. Some Performance Information Elements. Some Information Elements related to Performance
Metrics related Information Elements are proposed on regular Metrics are proposed on a regular basis.</li>
basis.</t> <li>The "Performance Metrics for Other Layers" (PMOL) WG (concluded)
<t>The "Performance Metrics for Other Layers" (PMOL) a concluded WG
defined some Performance Metrics related to Session Initiation defined some Performance Metrics related to Session Initiation
Protocol (SIP) voice quality <xref target="RFC6035"/>.</t> Protocol (SIP) voice quality <xref target="RFC6035" format="default"/>
</list></t> .</li>
</ul>
<t>It is expected that more Performance Metrics will be defined in the <t>It is expected that more Performance Metrics will be defined in the
future, not only IP-based metrics, but also metrics which are future -- not only IP-based metrics but also metrics that are
protocol-specific and application-specific.</t> protocol specific and application specific.</t>
<t>Despite the importance of Performance Metrics, there are two related <t>Despite the importance of Performance Metrics, there are two related
problems for the industry. First, ensuring that when one party requests problems for the industry:</t>
another party to measure (or report or in some way act on) a particular
Performance Metric, then both parties have exactly the same <ul empty="false" spacing="normal">
understanding of what Performance Metric is being referred to. Second, <li>First, ensuring that when one party requests that
another party measure (or report or in some way act on) a particular
Performance Metric, both parties have exactly the same
understanding of what Performance Metric is being referred to.</li>
<li>Second,
discovering which Performance Metrics have been specified, to avoid discovering which Performance Metrics have been specified, to avoid
developing a new Performance Metric that is very similar, but not quite developing a new Performance Metric that is very similar but not quite
inter-operable. These problems can be addressed by creating a registry interoperable.</li>
of performance metrics. The usual way in which the IETF organizes </ul>
registries is with Internet Assigned Numbers Authority (IANA), and there
is currently no Performance Metrics Registry maintained by the IANA.</t>
<t>This document requests that IANA create and maintain a Performance <t>These problems can be addressed by creating a Registry
for Performance Metrics with the Internet Assigned Numbers Authority
(IANA). As such, this document defines the new IANA Registry for Perform
ance
Metrics.</t>
<t>Per this document, IANA has created and now maintains the Performance
Metrics Registry, according to the maintenance procedures and the Metrics Registry, according to the maintenance procedures and the
Performance Metrics Registry format defined in this memo. The resulting format defined in the sections below. The resulting
Performance Metrics Registry is for use by the IETF and others. Although Performance Metrics Registry is for use by the IETF and others. Although
the Registry formatting specifications herein are primarily for registry the Registry formatting specifications herein are primarily for Registry
creation by IANA, any other organization that wishes to create a creation by IANA, any other organization that wishes to create a
performance metrics registry may use the same formatting specifications Performance Metrics Registry may use the same formatting specifications
for their purposes. The authors make no guarantee of the registry for their purposes. The authors make no guarantee of the Registry
format's applicability to any possible set of Performance Metrics format's applicability to any possible set of Performance Metrics
envisaged by other organizations, but encourage others to apply it. In envisaged by other organizations, but we encourage others to apply it. In
the remainder of this document, unless we explicitly say otherwise, we the remainder of this document, unless we explicitly say otherwise, we
will refer to the IANA-maintained Performance Metrics Registry as simply will refer to the IANA-maintained Performance Metrics Registry as simply
the Performance Metrics Registry.</t> the Performance Metrics Registry.</t>
</section> </section>
<section numbered="true" toc="default">
<name>Terminology</name>
<t>The key words "<bcp14>MUST</bcp14>", "<bcp14>MUST NOT</bcp14>",
"<bcp14>REQUIRED</bcp14>", "<bcp14>SHALL</bcp14>",
"<bcp14>SHALL NOT</bcp14>", "<bcp14>SHOULD</bcp14>",
"<bcp14>SHOULD NOT</bcp14>",
"<bcp14>RECOMMENDED</bcp14>", "<bcp14>NOT RECOMMENDED</bcp14>",
"<bcp14>MAY</bcp14>", and "<bcp14>OPTIONAL</bcp14>" in this document
are to be interpreted as described in BCP&nbsp;14
<xref target="RFC2119"/> <xref target="RFC8174"/> when, and only
when, they appear in all capitals, as shown here.</t>
<section title="Terminology"> <dl newline="false" spacing="normal">
<t>The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", <dt>Performance Metric:</dt>
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and <dd>A quantitative measure of performance, targeted to an IETF-specified
"OPTIONAL" in this document are to be interpreted as described in BCP 14
<xref target="RFC2119"/> <xref target="RFC8174"/> when, and only when,
they appear in all capitals, as shown here.</t>
<!-- <t>The terms Performance Metric is
defined in <xref target="RFC6390"/>, and copied over in this document
for the readers convenience.</t>
<t><list style="hanging">
<t hangText="Performance Metric:">A Performance Metric is a
quantitative measure of performance, targeted to an IETF-specified
protocol or targeted to an application transported over an protocol or targeted to an application transported over an
IETF-specified protocol. Examples of Performance Metrics are the FTP IETF-specified protocol. Examples of Performance Metrics are the FTP
response time for a complete file download, the DNS response time to response time for a complete file download, the DNS Response time to
resolve the IP address(es), a database logging time, etc. This resolve the IP address(es), a database logging time, etc. This
definition is consistent with the definition of metric in <xref definition is consistent with the definition of a metric in <xref
target="RFC2330"/> and broader than the definition of performance target="RFC2330" format="default"/> and broader than the definition
metric in <xref target="RFC6390"/>.</t> of a Performance Metric in <xref target="RFC6390" format="default"/>.<
/dd>
<t hangText="Registered Performance Metric:">A Registered <dt>Registered Performance Metric:</dt>
Performance Metric is a Performance Metric expressed as an entry in <dd>A Performance Metric expressed as an entry in
the Performance Metrics Registry, administered by IANA. Such a the Performance Metrics Registry, administered by IANA. Such a
performance metric has met all the registry review criteria defined Performance Metric has met all of the Registry review criteria defined
in this document in order to be included in the registry.</t> in this document in order to be included in the Registry.</dd>
<dt>Performance Metrics Registry:</dt>
<t hangText="Performance Metrics Registry:">The IANA registry <dd>The IANA Registry
containing Registered Performance Metrics.</t> containing Registered Performance Metrics.</dd>
<dt>Proprietary Registry:</dt>
<t hangText="Proprietary Registry:">A set of metrics that are <dd>A set of metrics that are
registered in a proprietary registry, as opposed to Performance registered in a proprietary Registry, as opposed to the Performance
Metrics Registry.</t> Metrics Registry.</dd>
<dt>Performance Metrics Experts:</dt>
<t hangText="Performance Metrics Experts:">The Performance Metrics <dd>A group of designated experts <xref target="RFC8126" format="default
Experts is a group of designated experts <xref target="RFC8126"/> "/>
selected by the IESG to validate the Performance Metrics before selected by the IESG to validate the Performance Metrics before
updating the Performance Metrics Registry. The Performance Metrics updating the Performance Metrics Registry. The Performance Metrics
Experts work closely with IANA.</t> Experts work closely with IANA.</dd>
<dt>Parameter:</dt>
<!-- <t hangText="Performance Metrics Directorate:">The Perfo <dd>An input factor defined as a
rmance
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.</t>
<t hangText="Parameter:">A Parameter is an input factor defined as a
variable in the definition of a Performance Metric. A Parameter is a variable in the definition of a Performance Metric. A Parameter is a
numerical or other specified factor forming one of a set that numerical or other specified factor forming one of a set that
defines a metric or sets the conditions of its operation. All defines a metric or sets the conditions of its operation. All
Parameters must be known in order to make a measurement using a Parameters must be known in order to make a measurement using a
metric and interpret the results. There are two types of Parameters: metric and interpret the results. There are two types of Parameters:
Fixed and Run-time parameters. For the Fixed Parameters, the value Fixed and Runtime. For the Fixed Parameters, the value
of the variable is specified in the Performance Metrics Registry of the variable is specified in the Performance Metrics Registry
entry and different Fixed Parameter values results in different Entry and different Fixed Parameter values results in different
Registered Performance Metrics. For the Run-time Parameters, the Registered Performance Metrics. For the Runtime Parameters, the
value of the variable is defined when the metric measurement method value of the variable is defined when the Metric Measurement Method
is executed and a given Registered Performance Metric supports is executed and a given Registered Performance Metric supports
multiple values for the parameter. Although Run-time Parameters do multiple values for the Parameter. Although Runtime Parameters do
not change the fundamental nature of the Performance Metric's not change the fundamental nature of the Performance Metric's
definition, some have substantial influence on the network property definition, some have substantial influence on the network property
being assessed and interpretation of the results. <list> being assessed and interpretation of the results.</dd>
<t>Note: Consider the case of packet loss in the following two </dl>
<aside><t>Note: Consider the case of packet loss in the following two
Active Measurement Method cases. The first case is packet loss Active Measurement Method cases. The first case is packet loss
as background loss where the Run-time Parameter set includes a as background loss where the Runtime Parameter set includes a
very sparse Poisson stream, and only characterizes the times very sparse Poisson stream and only characterizes the times
when packets were lost. Actual user streams likely see much when packets were lost. Actual user streams likely see much
higher loss at these times, due to tail drop or radio errors. higher loss at these times, due to tail drop or radio errors.
The second case is packet loss as inverse of throughput where The second case is packet loss ratio as the complimentary
the Run-time Parameter set includes a very dense, bursty stream, probability of delivery ratio where
the Runtime Parameter set includes a very dense, bursty stream,
and characterizes the loss experienced by a stream that and characterizes the loss experienced by a stream that
approximates a user stream. These are both "loss metrics", but approximates a user stream. These are both "Loss metrics", but
the difference in interpretation of the results is highly the difference in interpretation of the results is highly
dependent on the Run-time Parameters (at least), to the extreme dependent on the Runtime Parameters (at least), to the extreme
where we are actually using loss to infer its compliment: where we are actually using loss ratio to infer its complimentary
delivered throughput.</t> probability: delivery ratio.</t></aside>
</list></t>
<t hangText="Active Measurement Method:">Methods of Measurement <dl newline="false" spacing="normal">
conducted on traffic which serves only the purpose of measurement <dt>Active Measurement Methods:</dt>
<dd>Methods of Measurement
conducted on traffic that serves only the purpose of measurement
and is generated for that reason alone, and whose traffic and is generated for that reason alone, and whose traffic
characteristics are known a priori. The complete definition of characteristics are known a priori. The complete definition of
Active Methods is specified in section 3.4 of<xref Active Methods is specified in <xref target="RFC7799" sectionFormat="o
target="RFC7799"/>. Examples of Active Measurement Methods are the f" section="3.4"/>. Examples of Active Measurement Methods are the
measurement methods for the One way delay metric defined in <xref Measurement Methods for the one-way delay metric defined in <xref
target="RFC7679"/> and the one for round trip delay defined in <xref target="RFC7679" format="default"/> and the round-trip delay metric de
target="RFC2681"/>.</t> fined in <xref target="RFC2681" format="default"/>.</dd>
<dt>Passive Measurement Methods:</dt>
<t hangText="Passive Measurement Method:">Methods of Measurement <dd>Methods of Measurement
conducted on network traffic, generated either from the end users or conducted on network traffic, generated by either (1)&nbsp;the end
from network elements that would exist regardless whether the users or (2)&nbsp;network elements that would exist regardless of whet
her the
measurement was being conducted or not. The complete definition of measurement was being conducted or not. The complete definition of
Passive Methods is specified in section 3.6 of <xref Passive Methods is specified in <xref target="RFC7799" sectionFormat="
target="RFC7799"/>. One characteristic of Passive Measurement of" section="3.6"/>. One characteristic of Passive Measurement
Methods is that sensitive information may be observed, and as a Methods is that sensitive information may be observed and, as a
consequence, stored in the measurement system.</t> consequence, stored in the measurement system.</dd>
<dt>Hybrid Measurement Methods:</dt>
<t hangText="Hybrid Measurement Method:">Hybrid Methods are Methods <dd>Methods of Measurement that use a combination of Active Methods and
of Measurement that use a combination of Active Methods and Passive Passive
Methods, to assess Active Metrics, Passive Metrics, or new metrics Methods, to assess Active Metrics, Passive Metrics, or new metrics
derived from the a priori knowledge and observations of the stream derived from the a&nbsp;priori knowledge and observations of the strea m
of interest. The complete definition of Hybrid Methods is specified of interest. The complete definition of Hybrid Methods is specified
in section 3.8 of <xref target="RFC7799"/>.<!-- Some ex in <xref target="RFC7799" sectionFormat="of" section="3.8"/>.
amples include IPFIX <xref target="RFC4656"/>, PSAMP. [RFC 5470], [RFC 5476]-->< </dd>
/t> </dl>
</list></t>
</section> </section>
<section numbered="true" toc="default">
<section title="Scope"> <name>Scope</name>
<t>This document is intended for two different audiences:</t> <t>This document is intended for two different audiences:</t>
<ol spacing="normal" type="1">
<t><list style="numbers"> <li>For those preparing a candidate Performance Metric, it provides
<t>For those defining new Registered Performance Metrics, it criteria that the proposal <bcp14>SHOULD</bcp14> meet (see <xref
provides specifications and best practices to be used in deciding target="metrics-criteria"/>). It also provides instructions for
which Registered Performance Metrics are useful for a measurement writing the text for each column of the candidate Performance Metric
study, instructions for writing the text for each column of the and the references required for the new Performance Metrics Registry
Registered Performance Metrics, and information on the supporting Entry (up to and including the publication of one or more immutable
documentation required for the new Performance Metrics Registry documents such as an RFC) (see <xref target="columns"/>).</li>
entry (up to and including the publication of one or more immutable <li>For the appointed Performance Metrics Experts and for IANA
documents such as an RFC).</t> personnel administering the new IANA Performance Metrics Registry, it
defines a set of acceptance criteria against which a candidate
<t>For the appointed Performance Metrics Experts and for IANA Registered Performance Metric should be evaluated, and requirements
personnel administering the new IANA Performance Metrics Registry, for the composition of a candidate Performance Metric Registry Entry.</l
it defines a set of acceptance criteria against which these proposed i>
Registered Performance Metrics should be evaluated.</t> </ol>
</list></t> <t>Other organizations that standardize performance metrics are
encouraged to use the process defined in this memo to propose a
<t>In addition, this document may be useful for other organizations who candidate Registered Performance Metric. In addition, this document may
are defining a Performance Metric registry of their own, and may re-use be useful for other organizations who are defining a Performance Metrics
the features of the Performance Metrics Registry defined in this Registry of their own and may reuse the features of the Performance
document.</t> Metrics Registry defined in this document.</t>
<t>This Performance Metrics Registry is applicable to Performance <t>This Performance Metrics Registry is applicable to Performance
Metrics issued from Active Measurement, Passive Measurement, and any Metrics derived from Active Measurement, Passive Measurement, and any
other form of Performance Metric. This registry is designed to encompass other form of Performance Metric. This Registry is designed to encompass
Performance Metrics developed throughout the IETF and especially for the Performance Metrics developed throughout the IETF and especially for the
technologies specified in the following working groups: IPPM, XRBLOCK, technologies specified in the following working groups: IPPM, XRBLOCK,
IPFIX, and BMWG. This document analyzes a prior attempt to set up a IPFIX, and BMWG. This document analyzes a prior attempt to set up a
Performance Metrics Registry, and the reasons why this design was Performance Metrics Registry and the reasons why this design was
inadequate <xref target="RFC6248"/>. Finally, this document gives a set inadequate <xref target="RFC6248" format="default"/>. </t>
of guidelines for requesters and expert reviewers of candidate
Registered Performance Metrics.</t>
<t>This document makes no attempt to populate the Performance Metrics <t><xref target="RFC8912" format="default"/> populates the new Registry
Registry with initial entries; the related memo <xref with the initial set of entries.</t>
target="I-D.ietf-ippm-initial-registry"/> proposes the initial set of
regsitry entries.</t>
</section> </section>
<section title="Motivation for a Performance Metrics Registry"> <section numbered="true" toc="default">
<name>Motivations for the Performance Metrics Registry</name>
<t>In this section, we detail several motivations for the Performance <t>In this section, we detail several motivations for the Performance
Metrics Registry.</t> Metrics Registry.</t>
<section numbered="true" toc="default">
<section title="Interoperability"> <name>Interoperability</name>
<t>As with any IETF registry, the primary intention is to manage <t>As with any IETF Registry, the primary intention is to manage the
registration of identifiers for use within one or more protocols. In registration of Identifiers for use within one or more protocols. In
the particular case of the Performance Metrics Registry, there are two the particular case of the Performance Metrics Registry, there are two
types of protocols that will use the Performance Metrics in the types of protocols that will use the Performance Metrics in the
Performance Metrics Registry during their operation (by referring to Performance Metrics Registry during their operation (by referring to
the Index values): <list style="symbols"> the index values): </t>
<t>Control protocol: This type of protocol used to allow one
entity to request another entity to perform a measurement using a <dl newline="false" spacing="normal">
<dt>Control Protocol:</dt><dd>This type of protocol is used to allow
one
entity to request that another entity perform a measurement using a
specific metric defined by the Performance Metrics Registry. One specific metric defined by the Performance Metrics Registry. One
particular example is the LMAP framework <xref target="RFC7594"/>. particular example is the Large-scale Measurement of Broadband
Performance (LMAP) framework <xref target="RFC7594" format="default"
/>.
Using the LMAP terminology, the Performance Metrics Registry is Using the LMAP terminology, the Performance Metrics Registry is
used in the LMAP Control protocol to allow a Controller to used in the LMAP Control Protocol to allow a Controller to
schedule a measurement task for one or more Measurement Agents. In schedule a Measurement Task for one or more Measurement Agents. In
order to enable this use case, the entries of the Performance order to enable this use case, the entries in the Performance
Metrics Registry must be sufficiently defined to allow a Metrics Registry must be sufficiently defined to allow a
Measurement Agent implementation to trigger a specific measurement Measurement Agent implementation to trigger a specific Measurement
task upon the reception of a control protocol message. This Task upon the reception of a Control Protocol message. This
requirement heavily constrains the type of entries that are requirement heavily constrains the types of entries that are
acceptable for the Performance Metrics Registry. <!--Further conside acceptable for the Performance Metrics Registry.</dd>
rations about <dt>Report Protocol:</dt><dd>This type of protocol is used to allow an
this are captured in the Guidelines for metric registry entity to report Measurement Results to another entity. By referencing to a sp
allocations (cross reference to another section of this document ecific Registered Performance Metric, it is
or to a different document).--></t> possible to properly characterize the Measurement Result data
<t>Report protocol: This type of protocol is used to allow an
entity to report measurement results to another entity. By
referencing to a specific Performance Metrics Registry, it is
possible to properly characterize the measurement result data
being reported. Using the LMAP terminology, the Performance being reported. Using the LMAP terminology, the Performance
Metrics Registry is used in the Report protocol to allow a Metrics Registry is used in the LMAP Report Protocol to allow a
Measurement Agent to report measurement results to a Measurement Agent to report Measurement Results to a
Collector.</t> Collector.</dd>
</list> It should be noted that the LMAP framework explicitly allows </dl>
<t> It should be noted that the LMAP framework explicitly allows
for using not only the IANA-maintained Performance Metrics Registry for using not only the IANA-maintained Performance Metrics Registry
but also other registries containing Performance Metrics, either but also other registries containing Performance Metrics, i.e.,
defined by other organizations or private ones. However, others who either (1)&nbsp;registries defined by other organizations or (2)&nbsp;pr
are creating Registries to be used in the context of an LMAP framework ivate registries. However, others who
are creating registries to be used in the context of an LMAP framework
are encouraged to use the Registry format defined in this document, are encouraged to use the Registry format defined in this document,
because this makes it easier for developers of LMAP Measurement Agents because this makes it easier for developers of LMAP Measurement Agents
(MAs) to programmatically use information found in those other to programmatically use information found in those other
Registries' entries.</t> registries' entries.</t>
</section> </section>
<section numbered="true" toc="default">
<section title="Single point of reference for Performance Metrics"> <name>Single Point of Reference for Performance Metrics</name>
<t>A Performance Metrics Registry serves as a single point of <t>A Performance Metrics Registry serves as a single point of
reference for Performance Metrics defined in different working groups reference for Performance Metrics defined in different working groups
in the IETF. As we mentioned earlier, there are several WGs that in the IETF. As we mentioned earlier, there are several working groups t
define Performance Metrics in the IETF and it is hard to keep track of hat
all them. This results in multiple definitions of similar Performance define Performance Metrics in the IETF, and it is hard to keep track of
all of them. This results in multiple definitions of similar Performance
Metrics that attempt to measure the same phenomena but in slightly Metrics that attempt to measure the same phenomena but in slightly
different (and incompatible) ways. Having a registry would allow the different (and incompatible) ways. Having a Registry would allow the
IETF community and others to have a single list of relevant IETF community and others to have a single list of relevant
Performance Metrics defined by the IETF (and others, where Performance Metrics defined by the IETF (and others, where
appropriate). The single list is also an essential aspect of appropriate). The single list is also an essential aspect of
communication about Performance Metrics, where different entities that communication about Performance Metrics, where different entities that
request measurements, execute measurements, and report the results can request measurements, execute measurements, and report the results can
benefit from a common understanding of the referenced Performance benefit from a common understanding of the referenced Performance
Metric.</t> Metric.</t>
</section> </section>
<section numbered="true" toc="default">
<section title="Side benefits"> <name>Side Benefits</name>
<t>There are a couple of side benefits of having such a registry. <t>There are a couple of side benefits of having such a Registry.
First, the Performance Metrics Registry could serve as an inventory of First, the Performance Metrics Registry could serve as an inventory of
useful and used Performance Metrics, that are normally supported by useful and used Performance Metrics that are normally supported by
different implementations of measurement agents. Second, the results different implementations of Measurement Agents. Second, the results
of measurements using the Performance Metrics should be comparable of measurements using the Performance Metrics should be comparable
even if they are performed by different implementations and in even if they are performed by different implementations and in
different networks, as the Performance Metric is properly defined. BCP different networks, as the Performance Metric is properly defined.
176 <xref target="RFC6576"/> examines whether the results produced by BCP 176 <xref target="RFC6576" format="default"/> examines whether the
independent implementations are equivalent in the context of results produced by independent implementations are equivalent in the
evaluating the completeness and clarity of metric specifications. This context of evaluating the completeness and clarity of metric
BCP defines the standards track advancement testing for (active) IPPM specifications. <xref target="RFC6576"/> is a BCP <xref
metrics, and the same process will likely suffice to determine whether target="RFC2026"/> that defines the Standards Track advancement
Registered Performance Metrics are sufficiently well specified to testing for (Active) IPPM Metrics, and the same process will likely
result in comparable (or equivalent) results. Registered Performance suffice to determine whether Registered Performance Metrics are
Metrics which have undergone such testing SHOULD be noted, with a sufficiently well specified to result in comparable (or equivalent)
reference to the test results.</t> results. If a Registered Performance Metric has undergone such
testing, this <bcp14>SHOULD</bcp14> be noted in "Comments and Remarks"
(see <xref target="remarks"/>), with a reference to the test
results.</t>
</section> </section>
</section> </section>
<section anchor="metrics-criteria" numbered="true" toc="default">
<section title="Criteria for Performance Metrics Registration"> <name>Criteria for Performance Metrics Registration</name>
<t>It is neither possible nor desirable to populate the Performance <t>It is neither possible nor desirable to populate the Performance
Metrics Registry with all combinations of Parameters of all Performance Metrics Registry with all combinations of Parameters of all Performance
Metrics. The Registered Performance Metrics SHOULD be: <list Metrics. A Registered Performance Metric <bcp14>SHOULD</bcp14> be: </t>
style="numbers"> <ol spacing="normal" type="1">
<t>interpretable by the user.</t> <li>Interpretable by the human user.</li>
<li>Implementable by the software or hardware designer.</li>
<t>implementable by the software or hardware designer,</t> <li>Deployable by network operators.</li>
<li>Accurate in terms of producing equivalent results, and for
<t>deployable by network operators,</t> interoperability and deployment across vendors.</li>
<li>Operationally useful, so that it has significant industry
<t>accurate in terms of producing equivalent results, and for interest and/or has seen deployment.</li>
interoperability and deployment across vendors,</t> <li>Sufficiently tightly defined, so that different values for the
Runtime Parameters do not change the fundamental nature of the
<t>Operationally useful, so that it has significant industry measurement or change the practicality of its implementation.</li>
interest and/or has seen deployment,</t> </ol>
<t>In essence, there needs to be evidence that (1)&nbsp;a candidate
<t>Sufficiently tightly defined, so that different values for the Registered Performance Metric has significant industry interest or has
Run-time Parameters does not change the fundamental nature of the seen deployment and (2)&nbsp;there is agreement that the candidate Registe
measurement, nor change the practicality of its implementation.</t> red
</list>In essence, there needs to be evidence that a candidate
Registered Performance Metric has significant industry interest, or has
seen deployment, and there is agreement that the candidate Registered
Performance Metric serves its intended purpose.</t> Performance Metric serves its intended purpose.</t>
</section> </section>
<!-- start here -->
<section title="Performance Metric Registry: Prior attempt"> <section numbered="true" toc="default">
<t>There was a previous attempt to define a metric registry <xref <name>Performance Metrics Registry: Prior Attempt</name>
target="RFC4148">RFC 4148</xref>. However, it was obsoleted by <xref <t>There was a previous attempt to define a Metrics Registry <xref
target="RFC6248">RFC 6248</xref> because it was "found to be target="RFC4148" format="default"></xref>. However, it was
obsoleted by <xref target="RFC6248" format="default"></xref>
because it was
<!-- Begin DNE -->
"found to be
insufficiently detailed to uniquely identify IPPM metrics... [there was insufficiently detailed to uniquely identify IPPM metrics... [there was
too much] variability possible when characterizing a metric exactly" too much] variability possible when characterizing a metric exactly",
which led to the RFC4148 registry having "very few users, if any".</t> <!-- End DNE -->
which led to the IPPM Metrics Registry defined in <xref target="RFC4148"/>
<t>A couple of interesting additional quotes from <xref having
target="RFC6248">RFC 6248</xref> might help to understand the issues <!-- Begin DNE --> "very few users, if any." <!-- End DNE --></t>
related to that registry. <list style="numbers"> <t>Three interesting additional quotes from <xref target="RFC6248" format=
<t>"It is not believed to be feasible or even useful to register "default"></xref> might help to understand the issues
related to that registry. </t>
<!-- Begin DNE. Had to fix second item (and AQed it, since it's a repeat
of text in the first paragraph of this section). -->
<ol spacing="normal" type="1">
<li>"It is not believed to be feasible or even useful to register
every possible combination of Type P, metric parameters, and Stream every possible combination of Type P, metric parameters, and Stream
parameters using the current structure of the IPPM Metrics parameters using the current structure of the IPPM Metrics
Registry."</t> Registry."</li>
<li>"The current registry structure has been found to be insufficiently
<t>"The registry structure has been found to be insufficiently detailed to uniquely identify IPPM metrics."</li>
detailed to uniquely identify IPPM metrics."</t> <li>"Despite apparent efforts to find current or even future users,
<t>"Despite apparent efforts to find current or even future users,
no one responded to the call for interest in the RFC 4148 registry no one responded to the call for interest in the RFC 4148 registry
during the second half of 2010."</t> during the second half of 2010."</li>
</list></t> <!-- End DNE -->
</ol>
<t>The current approach learns from this by tightly defining each <t>The current approach learns from this by tightly defining each
Registered Performance Metric with only a few variable (Run-time) Registered Performance Metric with only a few variable (Runtime)
Parameters to be specified by the measurement designer, if any. The idea Parameters to be specified by the measurement designer, if any. The idea
is that entries in the Performance Metrics Registry stem from different is that entries in the Performance Metrics Registry stem from different
measurement methods which require input (Run-time) parameters to set Measurement Methods that require input (Runtime) Parameters to set
factors like source and destination addresses (which do not change the factors like Source and Destination addresses (which do not change the
fundamental nature of the measurement). The downside of this approach is fundamental nature of the measurement). The downside of this approach is
that it could result in a large number of entries in the Performance that it could result in a large number of entries in the Performance
Metrics Registry. There is agreement that less is more in this context - Metrics Registry. There is agreement that less is more in this context --
it is better to have a reduced set of useful metrics rather than a large it is better to have a reduced set of useful metrics rather than a large
set of metrics, some with with questionable usefulness.</t> set of metrics, some with questionable usefulness.</t>
<section numbered="true" toc="default">
<section title="Why this Attempt Should Succeed"> <name>Why This Attempt Should Succeed</name>
<t>As mentioned in the previous section, one of the main issues with <t>As mentioned in the previous section, one of the main issues with
the previous registry was that the metrics contained in the registry the previous Registry was that the metrics contained in the Registry
were too generic to be useful. This document specifies stricter were too generic to be useful. This document specifies stricter
criteria for performance metric registration (see section 5), and criteria for Performance Metric registration (see <xref
target="metrics-criteria"/>) and
imposes a group of Performance Metrics Experts that will provide imposes a group of Performance Metrics Experts that will provide
guidelines to assess if a Performance Metric is properly guidelines to assess if a Performance Metric is properly
specified.</t> specified.</t>
<t>Another key difference between this attempt and the previous one is <t>Another key difference between this attempt and the previous one is
that in this case there is at least one clear user for the Performance that in this case there is at least one clear user for the Performance
Metrics Registry: the LMAP framework and protocol. Because the LMAP Metrics Registry: the LMAP framework and protocol. Because the LMAP
protocol will use the Performance Metrics Registry values in its protocol will use the Performance Metrics Registry values in its
operation, this actually helps to determine if a metric is properly operation, this actually helps to determine if a metric is properly
defined. <!--The following sentence seems very awkward to me.-->In defined -- in particular, since we expect that the LMAP Control Protocol
particular, since we expect that the LMAP control protocol will enable will enable
a controller to request a measurement agent to perform a measurement a Controller to request that a Measurement Agent perform a measurement
using a given metric by embedding the Performance Metrics Registry using a given metric by embedding the Performance Metrics Registry
identifier in the protocol. Such a metric and method are properly Identifier in the protocol. Such a metric and method are properly
specified if they are defined well-enough so that it is possible (and specified if they are defined well enough so that it is possible (and
practical) to implement them in the measurement agent. This was the practical) to implement them in the Measurement Agent. This was the fail
failure of the previous attempt: a registry entry with an undefined ure of the previous attempt: a Registry Entry with an undefined Type-P (<xref ta
Type-P (section 13 of <xref target="RFC2330">RFC 2330</xref>) allows rget="RFC2330" sectionFormat="of" section="13"/>) allows measurement results to
implementation to be ambiguous.</t> vary significantly.</t>
</section> </section>
</section> </section>
<section anchor="columns" numbered="true" toc="default">
<section anchor="columns" <name>Definition of the Performance Metrics Registry</name>
title="Definition of the Performance Metric Registry">
<t>This Performance Metrics Registry is applicable to Performance <t>This Performance Metrics Registry is applicable to Performance
Metrics used for Active Measurement, Passive Measurement, and any other Metrics used for Active Measurement, Passive Measurement, and any other
form of Performance Measurement. Each category of measurement has unique form of Performance Measurement. Each category of measurement has unique
properties, so some of the columns defined below are not applicable for properties, so some of the columns defined below are not applicable for
a given metric category. In this case, the column(s) SHOULD be populated a given metric category. In this case, the column(s) <bcp14>SHOULD</bcp14>
with the "NA" value (Non Applicable). However, the "NA" value MUST NOT be populated
with the "N/A" value (Not Applicable). However, the "N/A" value <bcp14>MUS
T NOT</bcp14>
be used by any metric in the following columns: Identifier, Name, URI, be used by any metric in the following columns: Identifier, Name, URI,
Status, Requester, Revision, Revision Date, Description. In the future, Status, Requester, Revision, Revision Date, Description. In the future,
a new category of metrics could require additional columns, and adding a new category of metrics could require additional columns, and adding
new columns is a recognized form of registry extension. The new columns is a recognized form of Registry extension. The
specification defining the new column(s) MUST give general guidelines specification defining the new column(s) <bcp14>MUST</bcp14> give general
guidelines
for populating the new column(s) for existing entries.</t> for populating the new column(s) for existing entries.</t>
<t>The columns of the Performance Metrics Registry are defined below. <t>The columns of the Performance Metrics Registry are defined below.
The columns are grouped into "Categories" to facilitate the use of the The columns are grouped into "Categories" to facilitate the use of the
registry. Categories are described at the 7.x heading level, and columns Registry. Categories are described at the "Section 7.x" heading level, and
are at the 7.x.y heading level. The Figure below illustrates this columns
are described at the "Section 7.x.y" heading level. The figure below illus
trates this
organization. An entry (row) therefore gives a complete description of a organization. An entry (row) therefore gives a complete description of a
Registered Performance Metric.</t> Registered Performance Metric.</t>
<t>Each column serves as a checklist item and helps to avoid omissions
<t>Each column serves as a check-list item and helps to avoid omissions during registration and Expert Review <xref target="RFC8126"/>. </t>
during registration and expert review. <figure> <t>Registry Categories and Columns are shown below in this format:</t>
<artwork><![CDATA[==================================================== <artwork name="" type="" align="left" alt=""><![CDATA[
===================
Legend:
Registry Categories and Columns are shown below as:
Category Category
------------------... ------------------...
Column | Column |... Column | Column |...
======================================================================= ]]></artwork>
<artwork name="" type="" align="left" alt=""><![CDATA[
Summary Summary
Identifier | Name | URI | Desc. | Reference | Change Controller | Ver | ----------------------------------------------------------------
Identifier | Name | URI | Desc. | Reference | Change | Ver |
| | | | | Controller |
Metric Definition Metric Definition
----------------------------------------- -----------------------------------------
Reference Definition | Fixed Parameters | Reference Definition | Fixed Parameters |
Method of Measurement Method of Measurement
--------------------------------------------------------------------- ---------------------------------------------------------------------
Reference | Packet | Traffic | Sampling | Run-time | Role | Reference | Packet | Traffic | Sampling | Runtime | Role |
Method | Stream | Filter | Distribution | Parameters | | Method | Stream | Filter | Distribution | Parameters | |
| Generation | | Generation |
Output Output
----------------------------------------- -----------------------------------------
Type | Reference | Units | Calibration | Type | Reference | Units | Calibration |
| Definition | | | | Definition | | |
Administrative Information Administrative Information
Status |Requester | Rev | Rev.Date | -------------------------------------
Status |Requester | Rev | Rev. Date |
Comments and Remarks Comments and Remarks
--------------------]]></artwork>
]]></artwork>
</figure></t>
<t>There is a blank template of the Registry template provided in <t>There is a blank template of the Registry template provided in
Section 11 of this memo.</t> <xref target="blank-reg-template"/> of this memo.</t>
<section numbered="true" toc="default">
<section title="Summary Category"> <name>Summary Category</name>
<section title="Identifier"> <section numbered="true" toc="default">
<t>A numeric identifier for the Registered Performance Metric. This <name>Identifier</name>
identifier MUST be unique within the Performance Metrics <t>This column provides a numeric Identifier for the Registered Perfor
Registry.</t> mance Metric. The Identifier of each Registered Performance Metric <bcp14>MUST</
bcp14> be unique. Note that revising a Metric according to the process in <xref
<t>The Registered Performance Metric unique identifier is an target="revise-reg-perf-metrics"/> creates a new entry in the Performance Metric
s Registry with the same identifier.</t>
<t>The Registered Performance Metric unique Identifier is an
unbounded integer (range 0 to infinity).</t> unbounded integer (range 0 to infinity).</t>
<t>The Identifier 0 should be Reserved. The Identifier values from <t>The Identifier 0 should be Reserved. The Identifier values from
64512 to 65536 are reserved for private or experimental use, and the 64512 to 65535 are reserved for private or experimental use, and the
user may encounter overlapping uses.</t> user may encounter overlapping uses.</t>
<t>When adding new Registered Performance Metrics to the
<t>When adding newly Registered Performance Metrics to the Performance Metrics Registry, IANA <bcp14>SHOULD</bcp14> assign the lo
Performance Metrics Registry, IANA SHOULD assign the lowest west
available identifier to the new Registered Performance Metric.</t> available Identifier to the new Registered Performance Metric.</t>
<t>If a Performance Metrics Expert providing review determines that <t>If a Performance Metrics Expert providing review determines that
there is a reason to assign a specific numeric identifier, possibly there is a reason to assign a specific numeric Identifier, possibly
leaving a temporary gap in the numbering, then the Performance leaving a temporary gap in the numbering, then the Performance Metrics
Expert SHALL inform IANA of this decision.</t> Expert <bcp14>SHALL</bcp14> inform IANA of this decision.</t>
</section> </section>
<section anchor="name-sec7-1-2" numbered="true" toc="default">
<section title="Name"> <name>Name</name>
<t>As the name of a Registered Performance Metric is the first thing <t>As the Name of a Registered Performance Metric is the first thing
a potential human implementor will use when determining whether it a potential human implementer will use when determining whether it
is suitable for their measurement study, it is important to be as is suitable for their measurement study, it is important to be as
precise and descriptive as possible. In future, users will review precise and descriptive as possible. In the future, users will review
the names to determine if the metric they want to measure has the Names to determine if the metric they want to measure has
already been registered, or if a similar entry is available as a already been registered, or if a similar entry is available, as a
basis for creating a new entry.</t> basis for creating a new entry.</t>
<t>Names are composed of the following elements, separated by an <t>Names are composed of the following elements, separated by an
underscore character "_":</t> underscore character "_":</t>
<ul empty="true" spacing="normal">
<li>MetricType_Method_SubTypeMethod_... Spec_Units_Output</li>
</ul>
<t>MetricType_Method_SubTypeMethod_... Spec_Units_Output</t> <dl newline="false" spacing="normal">
<dt>MetricType:</dt><dd>A combination of the directional propertie
<t><list style="symbols"> s and
<t>MetricType: a combination of the directional properties and the metric measured, such as and not limited to:</dd>
the metric measured, such as and not limited to:<list </dl>
style="empty">
<t>RTDelay (Round Trip Delay)</t>
<t>RTDNS (Response Time Domain Name Service)</t>
<t>RLDNS (Response Loss Domain Name Service)</t>
<t>OWDelay (One Way Delay)</t>
<t>RTLoss (Round Trip Loss)</t>
<t>OWLoss (One Way Loss)</t>
<t>OWPDV (One Way Packet Delay Variation)</t>
<t>OWIPDV (One Way Inter-Packet Delay Variation)</t>
<t>OWReorder (One Way Packet Reordering)</t>
<t>OWDuplic (One Way Packet Duplication)</t>
<t>OWBTC (One Way Bulk Transport Capacity)</t>
<t>OWMBM (One Way Model Based Metric)</t>
<t>SPMonitor (Single Point Monitor)</t>
<t>MPMonitor (Multi-Point Monitor)</t>
</list></t>
<t>Method: One of the methods defined in <xref
target="RFC7799"/>, such as and not limited to:<list
style="empty">
<t>Active (depends on a dedicated measurement packet stream
and observations of the stream)</t>
<t>Passive (depends *solely* on observation of one or more
existing packet streams)</t>
<t>HybridType1 (observations on one stream that combine both
active and passive methods)</t>
<t>HybridType2 (observations on two or more streams that
combine both active and passive methods)</t>
<t>Spatial (Spatial Metric of RFC5644)</t>
</list></t>
<t>SubTypeMethod: One or more sub-types to further describe the
features of the entry, such as and not limited to:<list
style="empty">
<t>ICMP (Internet Control Message Protocol)</t>
<t>IP (Internet Protocol)</t>
<t>DSCPxx (where xx is replaced by a Diffserv code
point)</t>
<t>UDP (User Datagram Protocol)</t>
<t>TCP (Transport Control Protocol)</t>
<t>QUIC (QUIC transport protocol)</t>
<t>HS (Hand-Shake, such as TCP's 3-way HS)</t>
<t>Poisson (Packet generation using Poisson
distribution)</t>
<t>Periodic (Periodic packet generation)</t>
<t>SendOnRcv (Sender keeps one packet in-transit by sending <table anchor="metric-type">
when previous packet arrives)</t> <tbody>
<tr>
<td>RTDelay</td>
<td>Round-Trip Delay</td>
</tr>
<tr>
<td>RTDNS</td>
<td>Response Time Domain Name Service</td>
</tr>
<tr>
<td>RLDNS</td>
<td>Response Loss Domain Name Service</td>
</tr>
<tr>
<td>OWDelay</td>
<td>One-Way Delay</td>
</tr>
<tr>
<td>RTLoss</td>
<td>Round-Trip Loss</td>
</tr>
<tr>
<td>OWLoss</td>
<td>One-Way Loss</td>
</tr>
<tr>
<td>OWPDV</td>
<td>One-Way Packet Delay Variation</td>
</tr>
<tr>
<td>OWIPDV</td>
<td>One-Way Inter-Packet Delay Variation</td>
</tr>
<tr>
<td>OWReorder</td>
<td>One-Way Packet Reordering</td>
</tr>
<tr>
<td>OWDuplic</td>
<td>One-Way Packet Duplication</td>
</tr>
<tr>
<td>OWBTC</td>
<td>One-Way Bulk Transport Capacity</td>
</tr>
<tr>
<td>OWMBM</td>
<td>One-Way Model-Based Metric</td>
</tr>
<tr>
<td>SPMonitor</td>
<td>Single-Point Monitor</td>
</tr>
<tr>
<td>MPMonitor</td>
<td>Multi-Point Monitor</td>
</tr>
</tbody>
</table>
<dl newline="false" spacing="normal">
<dt>Method:</dt><dd>One of the methods defined in <xref
target="RFC7799" format="default"/>, such as and not limited
to:</dd>
</dl>
<t>PayloadxxxxB (where xxxx is replaced by an integer, the <table anchor="methods">
number of octets in the Payload))</t> <tbody>
<tr>
<td>Active</td>
<td>depends on a dedicated measurement packet stream and observations of
the stream as described in <xref target="RFC7799"/></td>
</tr>
<tr>
<td>Passive</td>
<td>depends *solely* on observation of one or more existing packet streams
as described in <xref target="RFC7799"/></td>
</tr>
<tr>
<td>HybridType1</td>
<td>Hybrid Type I observations on one stream that combine both Active
Methods and Passive Methods as described in <xref target="RFC7799"/></td>
</tr>
<tr>
<td>HybridType2</td>
<td>Hybrid Type II observations on two or more streams that combine both
Active Methods and Passive Methods as described in <xref target="RFC7799"/
></td>
</tr>
<tr>
<td>Spatial</td>
<td>spatial metric as described in <xref target="RFC5644"/></td>
</tr>
</tbody>
</table>
<t>SustainedBurst (Capacity test, worst case)</t> <dl newline="false" spacing="normal">
<dt>SubTypeMethod:</dt><dd>One or more subtypes to further describ
e the
features of the entry, such as and not limited to:</dd>
</dl>
<t>StandingQueue (test of bottleneck queue behavior)</t> <!-- Reviewer: Instances of "xxxx" and "RFCXXXX" are DNE. -->
<table anchor="SubTypeMethod">
<tbody>
<tr>
<td>ICMP</td>
<td>Internet Control Message Protocol</td>
</tr>
<tr>
<td>IP</td>
<td>Internet Protocol</td>
</tr>
<tr>
<td>DSCPxx</td>
<td>where xx is replaced by a Diffserv code point</td>
</tr>
<tr>
<td>UDP</td>
<td>User Datagram Protocol</td>
</tr>
<tr>
<td>TCP</td>
<td>Transport Control Protocol</td>
</tr>
<tr>
<td>QUIC</td>
<td>QUIC transport protocol</td>
</tr>
<tr>
<td>HS</td>
<td>Hand-Shake, such as TCP's 3-way HS</td>
</tr>
<tr>
<td>Poisson</td>
<td>packet generation using Poisson distribution</td>
</tr>
<tr>
<td>Periodic</td>
<td>periodic packet generation</td>
</tr>
<tr>
<td>SendOnRcv</td>
<td>sender keeps one packet in transit by sending when previous packet arr
ives</td>
</tr>
<tr>
<td>PayloadxxxxB</td>
<td>where xxxx is replaced by an integer, the number of octets or 8-bit
Bytes in the Payload</td>
</tr>
<tr>
<td>SustainedBurst</td>
<td>capacity test, worst case</td>
</tr>
<tr>
<td>StandingQueue</td>
<td>test of bottleneck queue behavior</td>
</tr>
</tbody>
</table>
<t/> <t indent="3">SubTypeMethod values are separated by a hyphen "-"
</list>SubTypeMethod values are separated by a hyphen "-" character, which indicates that they belong to this element and
character, which indicates that they belong to this element, and that their order is unimportant when considering Name
that their order is unimportant when considering name
uniqueness.</t> uniqueness.</t>
<t>Spec: An immutable document identifier combined with a <dl newline="false" spacing="normal">
document section identifier. For RFCs, this consists of the RFC <dt>Spec:</dt><dd>An immutable document Identifier combined with a
document section Identifier. For RFCs, this consists of the RFC
number and major section number that specifies this Registry number and major section number that specifies this Registry
entry in the form RFCXXXXsecY, such as RFC7799sec3. Note: the Entry in the form "RFCXXXXsecY", e.g., RFC7799sec3. Note: The
RFC number is not the Primary Reference specification for the RFC number is not the primary reference specification for the
metric definition, such as <xref target="RFC7679"/> for One-way metric definition (e.g., <xref target="RFC7679"
Delay; it will contain the placeholder "RFCXXXXsecY" until the format="default"/> as the primary reference specification for
RFC number is assigned to the specifying document, and would one-way delay metrics); it will contain the placeholder
remain blank in private registry entries without a corresponding "RFCXXXXsecY" until the
RFC number is assigned to the specifying document and would
remain blank in Private Registry Entries without a corresponding
RFC. Anticipating the "RFC10K" problem, the number of the RFC RFC. Anticipating the "RFC10K" problem, the number of the RFC
continues to replace RFCXXXX regardless of the number of digits continues to replace "RFCXXXX", regardless of the number of digits
in the RFC number. Anticipating Registry Entries from other in the RFC number. Anticipating Registry Entries from other
standards bodies, the form of this Name Element MUST be proposed standards bodies, the form of this Name Element <bcp14>MUST</bcp14 > be proposed
and reviewed for consistency and uniqueness by the Expert and reviewed for consistency and uniqueness by the Expert
Reviewer.</t> Reviewer.</dd>
<t>Units: The units of measurement for the output, such as and
not limited to:<list style="empty">
<t>Seconds</t>
<t>Ratio (unitless)</t>
<t>Percent (value multiplied by 100%)</t>
<t>Logical (1 or 0)</t>
<t>Packets</t>
<t>BPS (Bits per Second)</t>
<t>PPS (Packets per Second)</t>
<t>EventTotal (for unit-less counts)</t>
<t>Multiple (more than one type of unit)</t>
<t>Enumerated (a list of outcomes)</t>
<t>Unitless</t>
</list></t>
<t>Output: The type of output resulting from measurement, such
as and not limited to:<list style="empty">
<t>Singleton</t>
<t>Raw (multiple Singletons)</t>
<t>Count</t>
<t>Minimum</t>
<t>Maximum</t>
<t>Median</t>
<t>Mean</t>
<t>95Percentile (95th Percentile)</t>
<t>99Percentile (99th Percentile)</t>
<t>StdDev (Standard Deviation)</t>
<t>Variance</t> <dt>Units:</dt><dd><t>The units of measurement for the output, suc
h as and
not limited to:</t></dd>
</dl>
<t>PFI (Pass, Fail, Inconclusive)</t> <table anchor="units">
<tbody>
<tr>
<td>Seconds</td>
<td></td>
</tr>
<tr>
<td>Ratio</td>
<td>unitless</td>
</tr>
<tr>
<td>Percent</td>
<td>value multiplied by 100%</td>
</tr>
<tr>
<td>Logical</td>
<td>1 or 0</td>
</tr>
<tr>
<td>Packets</td>
<td></td>
</tr>
<tr>
<td>BPS</td>
<td>bits per second</td>
</tr>
<tr>
<td>PPS</td>
<td>packets per second</td>
</tr>
<tr>
<td>EventTotal</td>
<td>for unitless counts</td>
</tr>
<tr>
<td>Multiple</td>
<td>more than one type of unit</td>
</tr>
<tr>
<td>Enumerated</td>
<td>a list of outcomes</td>
</tr>
<tr>
<td>Unitless</td>
<td></td>
</tr>
</tbody>
</table>
<t>FlowRecords (descriptions of flows observed)</t> <dl newline="false" spacing="normal">
<dt>Output:</dt><dd>The type of output resulting from measurement,
such
as and not limited to:</dd>
</dl>
<t>LossRatio (lost packets to total packets, &lt;=1)</t> <table anchor="output">
</list></t> <tbody>
</list>An example is:</t> <tr>
<td>Singleton</td>
<td></td>
</tr>
<tr>
<td>Raw</td>
<td>multiple singletons</td>
</tr>
<tr>
<td>Count</td>
<td></td>
</tr>
<tr>
<td>Minimum</td>
<td></td>
</tr>
<tr>
<td>Maximum</td>
<td></td>
</tr>
<tr>
<td>Median</td>
<td></td>
</tr>
<tr>
<td>Mean</td>
<td></td>
</tr>
<tr>
<td>95Percentile</td>
<td>95th percentile</td>
</tr>
<tr>
<td>99Percentile</td>
<td>99th percentile</td>
</tr>
<tr>
<td>StdDev</td>
<td>standard deviation</td>
</tr>
<tr>
<td>Variance</td>
<td></td>
</tr>
<tr>
<td>PFI</td>
<td>pass, fail, inconclusive</td>
</tr>
<tr>
<td>FlowRecords</td>
<td>descriptions of flows observed</td>
</tr>
<tr>
<td>LossRatio</td>
<td>lost packets to total packets, &lt;=1</td>
</tr>
</tbody>
</table>
<t>RTDelay_Active_IP-UDP-Periodic_RFCXXXXsecY_Seconds_95Percentile</t> <t>An example, as described in <xref target="RFC8912"
sectionFormat="of" section="4"/>, is</t>
<t>as described in section 4 of <xref <ul empty="true" spacing="normal">
target="I-D.ietf-ippm-initial-registry"/>.</t> <li>RTDelay_Active_IP-UDP-Periodic_RFC8912sec4_Seconds_95Percentile</l
i>
</ul>
<t>Note that private registries following the format described here <t>Note that private registries following the format described here
SHOULD use the prefix "Priv_" on any name to avoid unintended <bcp14>SHOULD</bcp14> use the prefix "Priv_" on any Name to avoid unin
conflicts (further considerations are described in section 10). tended
Private registry entries usually have no specifying RFC, thus the conflicts (further considerations are described in <xref target="iana-
cons"/>).
Private Registry Entries usually have no specifying RFC; thus, the
Spec: element has no clear interpretation.</t> Spec: element has no clear interpretation.</t>
</section> </section>
<section title="URI"> <section numbered="true" toc="default">
<t>The URIs column MUST contain a URL <xref target="RFC3986"/> that <name>URI</name>
uniquely identifies and locates the metric entry so it is accessible
through the Internet. The URL points to a file containing all the <t>The URI column <bcp14>MUST</bcp14> contain a URL <xref target="RFC3
human-readable information for one registry entry. The URL SHALL 986" format="default"/> that
uniquely identifies and locates the Metric Entry so it is accessible
through the Internet. The URL points to a file containing all of the
human-readable information for one Registry Entry. The URL <bcp14>SHAL
L</bcp14>
reference a target file that is preferably HTML-formatted and reference a target file that is preferably HTML-formatted and
contains URLs to referenced sections of HTML-ized RFCs, or other contains URLs to referenced sections of HTMLized RFCs, or other
reference specifications. These target files for different entries reference specifications. These target files for different entries
can be more easily edited and re-used when preparing new entries. can be more easily edited and reused when preparing new entries.
The exact form of the URL for each target file, and the target file The exact form of the URL for each target file, and the target file
itself, will be determined by IANA and reside on "iana.org". The itself, will be determined by IANA and reside on
major sections of <xref target="I-D.ietf-ippm-initial-registry"/> <eref target="https://www.iana.org/" brackets="angle"/>.
provide an example of a target file in HTML form (sections 4 and <xref target="RFC8912" sectionFormat="of" section="4"/>, as well as
higher).</t> subsequent major sections of that document, provide an example of a ta
rget file in HTML form.</t>
</section> </section>
<section numbered="true" toc="default">
<section title="Description"> <name>Description</name>
<t>A Registered Performance Metric description is a written <t>A Registered Performance Metric description is a written
representation of a particular Performance Metrics Registry entry. representation of a particular Performance Metrics Registry Entry.
It supplements the Registered Performance Metric name to help It supplements the Registered Performance Metric Name to help
Performance Metrics Registry users select relevant Registered Performance Metrics Registry users select relevant Registered
Performance Metrics.</t> Performance Metrics.</t>
</section> </section>
<section numbered="true" toc="default">
<name>Reference</name>
<section title="Reference">
<t>This entry gives the specification containing the candidate <t>This entry gives the specification containing the candidate
registry entry which was reviewed and agreed, if such an RFC or Registry Entry that was reviewed and agreed upon, if such an RFC or
other specification exists.</t> other specification exists.</t>
</section> </section>
<section numbered="true" toc="default">
<section title="Change Controller"> <name>Change Controller</name>
<t>This entry names the entity responsible for approving revisions <t>This entry names the entity responsible for approving revisions
to the registry entry, and SHALL provide contact information (for an to the Registry Entry and <bcp14>SHALL</bcp14> provide contact informa tion (for an
individual, where appropriate).</t> individual, where appropriate).</t>
</section> </section>
<section numbered="true" toc="default">
<section title="Version (of Registry Format)"> <name>Version (of Registry Format)</name>
<t>This entry gives the version number for the registry format used. <t>This column gives the version number for the Registry format used, at the tim
Formats complying with this memo MUST use 1.0. The version number e the Performance Metric is registered. The format complying with this memo MUST
SHALL NOT change unless a new RFC is published that changes the use 1.0. A new RFC that changes the Registry format will designate a new versio
registry format. The version number of registry entries SHALL NOT n number corresponding to that format. The version number of Registry Entries SH
change unless the registry entry is updated (following procedures in ALL NOT change unless the Registry Entry is updated to reflect the Registry form
section 8).</t> at (following the procedures in <xref target="managing-perf-metric-grp"/>).</t>
</section> </section>
<!-- <section title="Reference Specification(s)">
<t>Registered Performance Metrics that follow the common columns must pr
ovide the
reference specification(s) on which the Registered Performance Metric
is based.</t>
</section>-->
</section> </section>
<section title="Metric Definition Category"> <section numbered="true" toc="default">
<name>Metric Definition Category</name>
<t>This category includes columns to prompt all necessary details <t>This category includes columns to prompt all necessary details
related to the metric definition, including the immutable document related to the metric definition, including the immutable document
reference and values of input factors, called fixed parameters, which reference and values of input factors, called "Fixed Parameters", which
are left open in the immutable document, but have a particular value are left open in the immutable document but have a particular value
defined by the performance metric.</t> defined by the Performance Metric.</t>
<section numbered="true" toc="default">
<section title="Reference Definition"> <name>Reference Definition</name>
<t>This entry provides a reference (or references) to the relevant <t>This entry provides a reference (or references) to the relevant
section(s) of the document(s) that define the metric, as well as any sections of the document or documents that define the metric, as well as any
supplemental information needed to ensure an unambiguous definition supplemental information needed to ensure an unambiguous definition
for implementations. The reference needs to be an immutable for implementations. A given reference needs to be an immutable
document, such as an RFC; for other standards bodies, it is likely document, such as an RFC; for other standards bodies, it is likely
to be necessary to reference a specific, dated version of a to be necessary to reference a specific, dated version of a
specification.</t> specification.</t>
</section> </section>
<section numbered="true" toc="default">
<section title="Fixed Parameters"> <name>Fixed Parameters</name>
<t>Fixed Parameters are Parameters whose value must be specified in <t>Fixed Parameters are Parameters whose values must be specified in
the Performance Metrics Registry. The measurement system uses these the Performance Metrics Registry. The measurement system uses these
values.</t> values.</t>
<t>Where referenced metrics supply a list of Parameters as part of <t>Where referenced metrics supply a list of Parameters as part of
their descriptive template, a sub-set of the Parameters will be their descriptive template, a subset of the Parameters will be
designated as Fixed Parameters. As an example for active metrics, designated as Fixed Parameters. As an example for Active Metrics,
Fixed Parameters determine most or all of the IPPM Framework Fixed Parameters determine most or all of the IPPM framework
convention "packets of Type-P" as described in <xref convention "packets of Type-P" as described in <xref
target="RFC2330"/>, such as transport protocol, payload length, TTL, target="RFC2330" format="default"/>, such as transport protocol,
etc. An example for passive metrics is for RTP packet loss payload length, TTL, etc. An example for Passive Metrics is for an RTP
calculation that relies on the validation of a packet as RTP which packet loss
is a multi-packet validation controlled by MIN_SEQUENTIAL as defined calculation that relies on the validation of a packet as RTP, which
by <xref target="RFC3550"/>. Varying MIN_SEQUENTIAL values can alter is a multi-packet validation controlled by the MIN_SEQUENTIAL variable
the loss report and this value could be set as a Fixed as defined
by <xref target="RFC3550" format="default"/>. Varying MIN_SEQUENTIAL v
alues can alter
the loss report, and this variable could be set as a Fixed
Parameter.</t> Parameter.</t>
<t>Parameters <bcp14>MUST</bcp14> have well-defined names. For human r
<t>Parameters MUST have well-defined names. For human readers, the eaders, the
hanging indent style is preferred, and any Parameter names and hanging-indent style is preferred, and any Parameter names and
definitions that do not appear in the Reference Method Specification definitions that do not appear in the Reference Method Specification
MUST appear in this column (or Run-time Parameters column).</t> <bcp14>MUST</bcp14> appear in this column (or the Runtime Parameters c
olumn).</t>
<t>Parameters MUST have a well-specified data format.</t> <t>Parameters <bcp14>MUST</bcp14> have a well-specified data format.</
t>
<t>A Parameter which is a Fixed Parameter for one Performance <t>A Parameter that is a Fixed Parameter for one Performance
Metrics Registry entry may be designated as a Run-time Parameter for Metrics Registry Entry may be designated as a Runtime Parameter for
another Performance Metrics Registry entry.</t> another Performance Metrics Registry Entry.</t>
</section> </section>
</section> </section>
<section numbered="true" toc="default">
<section title="Method of Measurement Category"> <name>Method of Measurement Category</name>
<t>This category includes columns for references to relevant sections <t>This category includes columns for references to relevant sections
of the immutable document(s) and any supplemental information needed of the immutable document(s) and any supplemental information needed
to ensure an unambiguous method for implementations.</t> to ensure an unambiguous method for implementations.</t>
<section numbered="true" toc="default">
<section title="Reference Method"> <name>Reference Method</name>
<t>This entry provides references to relevant sections of immutable <t>This entry provides references to relevant sections of immutable
documents, such as RFC(s) (for other standards bodies, it is likely documents, such as RFC(s) (for other standards bodies, it is likely
to be necessary to reference a specific, dated version of a to be necessary to reference a specific, dated version of a
specification) describing the method of measurement, as well as any specification) describing the Method of Measurement, as well as any
supplemental information needed to ensure unambiguous interpretation supplemental information needed to ensure unambiguous interpretation
for implementations referring to the immutable document text.</t> for implementations referring to the immutable document text.</t>
<t>Specifically, this section should include pointers to pseudocode <t>Specifically, this section should include pointers to pseudocode
or actual code that could be used for an unambiguous or actual code that could be used for an unambiguous
implementation.</t> implementation.</t>
</section> </section>
<section numbered="true" toc="default">
<section title="Packet Stream Generation"> <name>Packet Stream Generation</name>
<t>This column applies to Performance Metrics that generate traffic <t>This column applies to Performance Metrics that generate traffic
as part of their Measurement Method, including but not necessarily as part of their Measurement Method, including, but not necessarily
limited to Active metrics. The generated traffic is referred as a limited to, Active Metrics. The generated traffic is referred to as a
stream and this column describes its characteristics.</t> "stream", and this column describes its characteristics.</t>
<!-- <t>Some metrics, such as those intended for passive moni
toring or
RTCP and RTCP-XR metrics, will not specify an entry for this
column.</t> -->
<t>Each entry for this column contains the following information: <t>Each entry for this column contains the following information:
<list style="symbols"> </t>
<t>Value: The name of the packet stream scheduling <dl newline="false" spacing="normal">
discipline</t> <dt>Value:</dt><dd>The name of the packet stream scheduling
discipline</dd>
<t>Reference: the specification where the parameters of the <dt>Reference:</dt><dd>The specification where the Parameters of the
stream are defined</t> stream are defined</dd>
</list></t> </dl>
<t>The packet generation stream may require Parameters such as the
<t>The packet generation stream may require parameters such as the
average packet rate and distribution truncation value for streams average packet rate and distribution truncation value for streams
with Poisson-distributed inter-packet sending times. In case such with Poisson-distributed inter-packet sending times. If such
parameters are needed, they should be included either in the Fixed Parameters are needed, they should be included in either the Fixed
parameter column or in the run time parameter column, depending on Parameters column or the Runtime Parameters column, depending on
whether they will be fixed or will be an input for the metric.</t> whether they will be fixed or will be an input for the metric.</t>
<t>The simplest example of stream specification is singleton
<t>The simplest example of stream specification is Singleton scheduling (see <xref target="RFC2330" format="default"/>), where a
scheduling (see <xref target="RFC2330"/>), where a single atomic single atomic measurement is conducted. Each atomic measurement
measurement is conducted. Each atomic measurement could consist of could consist of sending a single packet (such as a DNS request) or
sending a single packet (such as a DNS request) or sending several sending several packets (for example, to request a web page). Other
packets (for example, to request a webpage). Other streams support a streams support a series of atomic measurements using pairs of
series of atomic measurements in a "sample", with a schedule packets, where the packet stream follows a schedule defining the
defining the timing between each transmitted packet and subsequent timing between transmitted packets, and an atomic measurement
measurement. Principally, two different streams are used in IPPM assesses the reception time between successive packets (e.g., a
metrics, Poisson distributed as described in <xref measurement of Inter-Packet Delay Variation). More complex streams
target="RFC2330"/> and Periodic as described in <xref and measurement relationships are possible. Principally, two
target="RFC3432"/>. Both Poisson and Periodic have their own unique different streams are used in IPPM Metrics: (1)&nbsp;Poisson,
parameters, and the relevant set of parameters names and values distributed as described in <xref target="RFC2330"
should be included either in the Fixed Parameters column or in the format="default"/> and (2)&nbsp;periodic, as described in <xref
Run-time parameter column.</t> target="RFC3432" format="default"/>. Both Poisson and periodic have
their own unique Parameters, and the relevant set of Parameter names
and values should be included in either the Fixed Parameters column
or the Runtime Parameters column.</t>
</section> </section>
<section numbered="true" toc="default">
<section title="Traffic Filter"> <name>Traffic Filter</name>
<t>This column applies to Performance Metrics that observe packets <t>This column applies to Performance Metrics that observe packets
flowing through (the device with) the measurement agent i.e. that is flowing through (the device with) the Measurement Agent, i.e.,
not necessarily addressed to the measurement agent. This includes packets that are not necessarily addressed to the Measurement Agent.
but is not limited to Passive Metrics. The filter specifies the This includes, but is not limited to, Passive Metrics. The filter
traffic that is measured. This includes protocol field specifies the traffic that is measured. This includes protocol field
values/ranges, such as address ranges, and flow or session values/ranges, such as address ranges, and flow or session
identifiers.</t> Identifiers.</t>
<t>The Traffic Filter itself depends on the needs of the metric itself
<t>The traffic filter itself depends on needs of the metric itself
and a balance of an operator's measurement needs and a user's need and a balance of an operator's measurement needs and a user's need
for privacy. Mechanics for conveying the filter criteria might be for privacy. Mechanics for conveying the filter criteria might be
the BPF (Berkley Packet Filter) or PSAMP <xref target="RFC5475"/> the BPF (Berkeley Packet Filter) or PSAMP (Packet Sampling) <xref targ
Property Match Filtering which reuses IPFIX <xref et="RFC5475" format="default"/>
target="RFC7012"/>. An example BPF string for matching TCP/80 Property Match Filtering, which reuses IPFIX <xref target="RFC7012" fo
traffic to remote destination net 192.0.2.0/24 would be "dst net rmat="default"/>. An example BPF string for matching TCP/80
192.0.2.0/24 and tcp dst port 80". More complex filter engines might traffic to remote Destination net 192.0.2.0/24 would be "dst net
be supported by the implementation that might allow for matching 192.0.2.0/24 and tcp dst port 80". More complex filter engines may all
using Deep Packet Inspection (DPI) technology.</t> ow for matching using Deep Packet Inspection (DPI) technology.</t>
<t>The Traffic Filter includes the following information: </t>
<t>The traffic filter includes the following information: <list> <dl newline="false" spacing="normal">
<t>Type: the type of traffic filter used, e.g. BPF, PSAMP, <dt>Type:</dt><dd>The type of Traffic Filter used, e.g., BPF, PSAMP,
OpenFlow rule, etc. as defined by a normative reference</t> OpenFlow rule, etc., as defined by a normative reference</dd>
<dt>Value:</dt><dd>The actual set of rules expressed</dd>
<t>Value: the actual set of rules expressed</t> </dl>
</list></t>
</section> </section>
<section numbered="true" toc="default">
<section title="Sampling Distribution"> <name>Sampling Distribution</name>
<t><!--This sentence seems awkward to me.-->The sampling <t>The sampling distribution defines, out of all of the packets that
distribution defines out of all the packets that match the traffic match the Traffic Filter, which one or more of those packets are
filter, which one of those are actually used for the measurement. actually used for the measurement. One possibility is "all", which
One possibility is "all" which implies that all packets matching the implies that all packets matching the Traffic Filter are considered,
Traffic filter are considered, but there may be other sampling but there may be other sampling strategies. It includes the following
strategies. It includes the following information: <list> information: </t>
<t>Value: the name of the sampling distribution</t> <dl newline="false" spacing="normal">
<dt>Value:</dt><dd>The name of the sampling distribution</dd>
<t>Reference definition: pointer to the specification where the <dt>Reference definition:</dt><dd>Pointer to the specification where
sampling distribution is properly defined.</t> the
</list></t> sampling distribution is properly defined</dd>
</dl>
<t>The sampling distribution may require parameters. In case such <t>The sampling distribution may require Parameters. If such
parameters are needed, they should be included either in the Fixed Parameters are needed, they should be included in either the Fixed
parameter column or in the run time parameter column, depending on Parameters column or the Runtime Parameters column, depending on
whether they will be fixed or will be an input for the metric.</t> whether they will be fixed or will be an input for the metric.</t>
<t>PSAMP is documented in "Sampling and Filtering Techniques for IP Pa
<t>Sampling and Filtering Techniques for IP Packet Selection are cket Selection" <xref target="RFC5475" format="default"/>,
documented in the PSAMP (Packet Sampling) <xref target="RFC5475"/>, while "A Framework for Packet Selection and Reporting" <xref target="R
while the Framework for Packet Selection and Reporting, <xref FC5474" format="default"/> provides more background information. The
target="RFC5474"/> provides more background information. The sampling distribution Parameters might be expressed in terms of
sampling distribution parameters might be expressed in terms of the the model described in "Information Model for Packet Sampling
Information Model for Packet Sampling Exports, <xref Exports" <xref target="RFC5477" format="default"/> and the process
target="RFC5477"/>, and the Flow Selection Techniques, <xref provided in "Flow Selection Techniques" <xref target="RFC7014" format=
target="RFC7014"/>.</t> "default"/>.</t>
</section> </section>
<section numbered="true" toc="default">
<section title="Run-time Parameters"> <name>Runtime Parameters</name>
<t>Run-Time Parameters are Parameters that must be determined, <t>In contrast to the Fixed Parameters, Runtime Parameters are Paramet
configured into the measurement system, and reported with the ers that do not change the fundamental nature of the measurement and their value
results for the context to be complete. However, the values of these s are not specified in the Performance Metrics Registry. They are left as variab
parameters is not specified in the Performance Metrics Registry les in the Registry, as an aid to the measurement system implementer or user. Th
(like the Fixed Parameters), rather these parameters are listed as eir values are supplied on execution, configured into the measurement system, an
an aid to the measurement system implementer or user (they must be d reported with the Measurement Results (so that the context is complete).</t>
left as variables, and supplied on execution).</t>
<t>Where metrics supply a list of Parameters as part of their <t>Where metrics supply a list of Parameters as part of their
descriptive template, a sub-set of the Parameters will be designated descriptive template, a subset of the Parameters will be designated
as Run-Time Parameters.</t> as Runtime Parameters.</t>
<t>Parameters <bcp14>MUST</bcp14> have well-defined names. For human r
<t>Parameters MUST have well defined names. For human readers, the eaders, the
hanging indent style is preferred, and the names and definitions hanging-indent style is preferred, and the names and definitions
that do not appear in the Reference Method Specification MUST appear that do not appear in the Reference Method Specification <bcp14>MUST</
bcp14> appear
in this column.</t> in this column.</t>
<t>A data format for each Runtime Parameter <bcp14>MUST</bcp14> be spe
<t>A Data Format for each Run-time Parameter MUST be specified in cified in
this column, to simplify the control and implementation of this column, to simplify the control and implementation of
measurement devices. For example, parameters that include an IPv4 measurement devices. For example, Parameters that include an IPv4
address can be encoded as a 32 bit integer (i.e. binary base64 address can be encoded as a 32-bit integer (i.e., a binary
encoded value) or ip-address as defined in <xref target="RFC6991"/>. base64-encoded value) or "ip&nbhy;address" as defined in <xref target=
"RFC6991" format="default"/>.
The actual encoding(s) used must be explicitly defined for each The actual encoding(s) used must be explicitly defined for each
Run-time parameter. IPv6 addresses and options MUST be accommodated, Runtime Parameter. IPv6 addresses and options <bcp14>MUST</bcp14> be a
allowing Registered Metrics to be used in that address family. Other ccommodated,
address families are permissable.</t> allowing Registered Performance Metrics to be used in that address fam
ily. Other
<t>Examples of Run-time Parameters include IP addresses, measurement address families are permissible.</t>
<t>Examples of Runtime Parameters include IP addresses, measurement
point designations, start times and end times for measurement, and point designations, start times and end times for measurement, and
other information essential to the method of measurement.</t> other information essential to the Method of Measurement.</t>
</section> </section>
<section numbered="true" toc="default">
<section title="Role"> <name>Role</name>
<t>In some methods of measurement, there may be several roles <t>In some Methods of Measurement, there may be several Roles
defined, e.g., for a one-way packet delay active measurement there defined, e.g., for a one-way packet delay Active Measurement, there
is one measurement agent that generates the packets and another is one Measurement Agent that generates the packets and another
agent that receives the packets. This column contains the name of Agent that receives the packets. This column contains the name of
the Role(s) for this particular entry. In the one-way delay example the Role(s) for this particular entry. In the one-way delay example
above, there should be two entries in the Role registry column, one above, there should be two entries in the Registry's Role column, one
for each Role (Source and Destination). When a measurement agent is for each Role (Source and Destination). When a Measurement Agent is
instructed to perform the "Source" Role for one-way delay metric, instructed to perform the "Source" Role for the one-way delay metric,
the agent knows that it is required to generate packets. The values the Agent knows that it is required to generate packets. The values
for this field are defined in the reference method of measurement for this field are defined in the Reference Method of Measurement
(and this frequently results in abbreviated role names such as (and this frequently results in abbreviated Role names such as
"Src").</t> "Src").</t>
<t>When the Role column of a Registry Entry defines more than one
<t>When the Role column of a registry entry defines more than one Role, the Role <bcp14>SHALL</bcp14> be treated as a Runtime Parameter
Role, then the Role SHALL be treated as a Run-time Parameter and and
supplied for execution. It should be noted that the LMAP framework supplied for execution. It should be noted that the LMAP framework
<xref target="RFC7594"/> distinguishes the Role from other Run-time <xref target="RFC7594" format="default"/> distinguishes the Role from
Parameters, and defines a special parameter "Roles" inside the other Runtime
registry-grouping function list in the LMAP YANG model<xref Parameters.</t>
target="RFC8194"/>.</t>
</section> </section>
</section> </section>
<section numbered="true" toc="default">
<section title="Output Category"> <name>Output Category</name>
<t>For entries which involve a stream and many singleton measurements, <t>For entries that involve a stream and many singleton measurements,
a statistic may be specified in this column to summarize the results a statistic may be specified in this column to summarize the results
to a single value. If the complete set of measured singletons is to a single value. If the complete set of measured singletons is
output, this will be specified here.</t> output, this will be specified here.</t>
<t>Some metrics embed one specific statistic in the reference metric <t>Some metrics embed one specific statistic in the reference metric
definition, while others allow several output types or statistics.</t> definition, while others allow several output types or statistics.</t>
<section numbered="true" toc="default">
<section title="Type"> <name>Type</name>
<t>This column contains the name of the output type. The output type <t>This column contains the name of the output type. The output type
defines a single type of result that the metric produces. It can be defines a single type of result that the metric produces. It can be
the raw results (packet send times and singleton metrics), or it can the raw results (packet send times and singleton metrics), or it can
be a summary statistic. The specification of the output type MUST be a summary statistic. The specification of the output type <bcp14>MU ST</bcp14>
define the format of the output. In some systems, format define the format of the output. In some systems, format
specifications will simplify both measurement implementation and specifications will simplify both measurement implementation and
collection/storage tasks. Note that if two different statistics are collection/storage tasks. Note that if two different statistics are
required from a single measurement (for example, both "Xth required from a single measurement (for example, both "Xth
percentile mean" and "Raw"), then a new output type must be defined percentile mean" and "Raw"), then a new output type must be defined
("Xth percentile mean AND Raw"). See the Naming section above for a ("Xth percentile mean AND Raw"). See <xref target="name-sec7-1-2"/>
list of Output Types.</t> above for a list of output types.</t>
</section> </section>
<section numbered="true" toc="default">
<!-- <name>Reference Definition</name>
<section title="Data Format">
<t>This column provides the data format for the output. I
t is provided to simplify the communication with
collection systems and implementation of measurement
devices.</t>
</section>
<section title="Reference Definition">
<t>This column contains a pointer to the specification(s) where the <t>This column contains a pointer to the specification(s) where the
output type and format are defined.</t> output type and format are defined.</t>
</section> </section>
<section numbered="true" toc="default">
<section title="Metric Units"> <name>Metric Units</name>
<t>The measured results must be expressed using some standard <t>The measured results must be expressed using some standard
dimension or units of measure. This column provides the units.</t> dimension or units of measure. This column provides the units.</t>
<t>When a sample of singletons (see <xref target="RFC2330"
<t>When a sample of singletons (see Section 11 of<xref sectionFormat="of" section="11"/> for definitions of these terms) is c
target="RFC2330"/> for definitions of these terms) is collected, ollected,
this entry will specify the units for each measured value.</t> this entry will specify the units for each measured value.</t>
</section> </section>
<section numbered="true" toc="default">
<section title="Calibration"> <name>Calibration</name>
<t>Some specifications for Methods of Measurement include the <t>Some specifications for Methods of Measurement include the
possibility to perform an error calibration. Section 3.7.3 of <xref ability to perform an error calibration. <xref target="RFC7679" sectio
target="RFC7679"/> is one example. In the registry entry, this field nFormat="of" section="3.7.3"/> is one example. In the Registry Entry, this field
will identify a method of calibration for the metric, and when will identify a method of calibration for the metric, and, when
available, the measurement system SHOULD perform the calibration available, the measurement system <bcp14>SHOULD</bcp14> perform the ca
libration
when requested and produce the output with an indication that it is when requested and produce the output with an indication that it is
the result of a calibration method. In-situ calibration could be the result of a calibration method. In-situ calibration could be
enabled with an internal loopback that includes as much of the enabled with an internal loopback that includes as much of the
measurement system as possible, performs address manipulation as measurement system as possible, performs address manipulation as
needed, and provides some form of isolation (e.g., deterministic needed, and provides some form of isolation (e.g., deterministic
delay) to avoid send-receive interface contention. Some portion of delay) to avoid send-receive interface contention. Some portion of
the random and systematic error can be characterized this way.</t> the random and systematic error can be characterized in this way.</t>
<t>For one-way delay measurements, the error calibration must <t>For one-way delay measurements, the error calibration must
include an assessment of the internal clock synchronization with its include an assessment of the internal clock synchronization with its
external reference (this internal clock is supplying timestamps for external reference (this internal clock is supplying timestamps for
measurement). In practice, the time offsets of clocks at both the measurement). In practice, the time offsets of clocks at both the
source and destination are needed to estimate the systematic error Source and Destination are needed to estimate the systematic error
due to imperfect clock synchronization (the time offsets are due to imperfect clock synchronization (the time offsets are
smoothed, thus the random variation is not usually represented in smoothed; thus, the random variation is not usually represented in
the results).</t> the results).</t>
<t>Both internal loopback calibration and clock synchronization can <t>Both internal loopback calibration and clock synchronization can
be used to estimate the *available accuracy* of the Output Metric be used to estimate the *available accuracy* of the Output Metric
Units. For example, repeated loopback delay measurements will reveal Units. For example, repeated loopback delay measurements will reveal
the portion of the Output result resolution which is the result of the portion of the output result resolution that is the result of
system noise, and thus inaccurate.</t> system noise and is thus inaccurate.</t>
</section> </section>
</section> </section>
<section numbered="true" toc="default">
<section title="Administrative information"> <name>Administrative Information</name>
<section title="Status"> <section numbered="true" toc="default">
<t>The status of the specification of this Registered Performance <name>Status</name>
Metric. Allowed values are 'current' and 'deprecated'. All newly <t>This entry indicates the status of the specification of this
defined Information Elements have 'current' status.</t> Registered Performance Metric. Allowed values are 'Current',
'Deprecated', and ‘Obsolete’. All newly defined Registered
Performance Metrics have 'Current' Status.</t>
</section> </section>
<section numbered="true" toc="default">
<section title="Requester"> <name>Requester</name>
<t>The requester for the Registered Performance Metric. The <t>This entry indicates the requester for the Registered Performance M
requester MAY be a document, such as RFC, or person.</t> etric. The
requester <bcp14>MAY</bcp14> be a document (such as an RFC) or a perso
n.</t>
</section> </section>
<section numbered="true" toc="default">
<section title="Revision"> <name>Revision</name>
<t>The revision number of a Registered Performance Metric, starting <t>This entry indicates the revision number of a Registered Performanc
at 0 for Registered Performance Metrics at time of definition and e Metric, starting at 0 for Registered Performance Metrics at the time of defini
incremented by one for each revision.</t> tion and incremented by one for each revision. However, in the case of a non-bac
kward-compatible revision, see <xref target="deprecating-metrics"/>.</t>
</section> </section>
<section numbered="true" toc="default">
<section title="Revision Date"> <name>Revision Date</name>
<t>The date of acceptance or the most recent revision for the <t>This entry indicates the date of acceptance of the most recent revi
Registered Performance Metric. The date SHALL be determined by IANA sion for the
Registered Performance Metric. The date <bcp14>SHALL</bcp14> be determ
ined by IANA
and the reviewing Performance Metrics Expert.</t> and the reviewing Performance Metrics Expert.</t>
</section> </section>
</section> </section>
<section anchor="remarks" numbered="true" toc="default">
<section title="Comments and Remarks"> <name>Comments and Remarks</name>
<t>Besides providing additional details which do not appear in other <t>Besides providing additional details that do not appear in other
categories, this open Category (single column) allows for unforeseen categories, this open category (single column) allows unforeseen
issues to be addressed by simply updating this informational issues to be addressed by simply updating this informational
entry.</t> entry.</t>
</section> </section>
</section> </section>
<section anchor="managing-perf-metric-grp" numbered="true" toc="default">
<section title="Processes for Managing the Performance Metric Registry Group <name>Processes for Managing the Performance Metrics Registry Group</name>
">
<t>Once a Performance Metric or set of Performance Metrics has been <t>Once a Performance Metric or set of Performance Metrics has been
identified for a given application, candidate Performance Metrics identified for a given application, candidate Performance Metrics
Registry entry specifications prepared in accordance with <xref Registry Entry specifications prepared in accordance with <xref target="co
target="columns"/> should be submitted to IANA to follow the process for lumns" format="default"/> should be submitted to IANA to follow the process for
review by the Performance Metric Experts, as defined below. This process review by the Performance Metrics Experts, as defined below. This process
is also used for other changes to the Performance Metrics Registry, such is also used for other changes to a Performance Metrics Registry Entry, su
ch
as deprecation or revision, as described later in this section.</t> as deprecation or revision, as described later in this section.</t>
<t>It is desirable that the author(s) of a candidate Performance Metrics <t>It is desirable that the author(s) of a candidate Performance Metrics
Registry entry seek review in the relevant IETF working group, or offer Registry Entry seek review in the relevant IETF working group or offer
the opportunity for review on the working group mailing list.</t> the opportunity for review on the working group mailing list.</t>
<section anchor="add-new-perf-metrics" numbered="true" toc="default">
<section title="Adding new Performance Metrics to the Performance Metrics <name>Adding New Performance Metrics to the Performance Metrics Registry
Registry"> </name>
<t>Requests to add Registered Performance Metrics in the Performance <t>Requests to add Registered Performance Metrics in the Performance
Metrics Registry SHALL be submitted to IANA, which forwards the Metrics Registry <bcp14>SHALL</bcp14> be submitted to IANA, which forwar
request to a designated group of experts (Performance Metric Experts) ds the
request to a designated group of experts (Performance Metrics Experts)
appointed by the IESG; these are the reviewers called for by the appointed by the IESG; these are the reviewers called for by the
Specification Required <xref target="RFC8126"/> policy defined for the Specification Required policy <xref target="RFC8126" format="default"/>
Performance Metrics Registry. The Performance Metric Experts review defined for the
Performance Metrics Registry. The Performance Metrics Experts review
the request for such things as compliance with this document, the request for such things as compliance with this document,
compliance with other applicable Performance Metric-related RFCs, and compliance with other applicable Performance Metrics-related RFCs, and
consistency with the currently defined set of Registered Performance consistency with the currently defined set of Registered Performance
Metrics. The most efficient path for submission begins with Metrics. The most efficient path for submission begins with
preparation of an Internet Draft containing the proposed Performance preparation of an Internet-Draft containing the proposed Performance
Metrics Registry entry using the template in Section 11, so that the Metrics Registry Entry using the template in <xref target="blank-reg-tem
submission formatting will benefit from the normal IETF Internet Draft plate"/>, so that the
submission processing (including HTML-ization).</t> submission formatting will benefit from the normal IETF Internet-Draft
submission processing (including HTMLization).</t>
<t>Submission to IANA may be during IESG review (leading to IETF <t>Submission to IANA may be during IESG review (leading to IETF
Standards Action), where an Internet Draft proposes one or more Standards Action), where an Internet-Draft proposes one or more
Registered Performance Metrics to be added to the Performance Metrics Registered Performance Metrics to be added to the Performance Metrics
Registry, including the text of the proposed Registered Performance Registry, including the text of the proposed Registered Performance
Metric(s).</t> Metric&wj;(s).</t>
<t>If an RFC-to-be includes a Performance Metric and a proposed <t>If an RFC-to-be includes a Performance Metric and a proposed
Performance Metrics Registry entry, but the Performance Metric Expert Performance Metrics Registry Entry but the Performance Metrics Expert's
review determines that one or more of the Section 5 criteria have not review determines that one or more of the criteria listed in <xref targe
been met, then the proposed Performance Metrics Registry entry MUST be t="metrics-criteria"/> have not
been met, then the proposed Performance Metrics Registry Entry <bcp14>MU
ST</bcp14> be
removed from the text. Once evidence exists that the Performance removed from the text. Once evidence exists that the Performance
Metric meets the criteria in section 5, the proposed Performance Metric meets the criteria in <xref target="metrics-criteria"/>, the prop
Metrics Registry entry SHOULD be submitted to IANA to be evaluated in osed Performance
consultation with the Performance Metric Experts for registration at Metrics Registry Entry <bcp14>SHOULD</bcp14> be submitted to IANA to be
evaluated in
consultation with the Performance Metrics Experts for registration at
that time.</t> that time.</t>
<t>Authors of proposed Registered Performance Metrics <bcp14>SHOULD</bcp
<t>Authors of proposed Registered Performance Metrics SHOULD review 14> review
compliance with the specifications in this document to check their compliance with the specifications in this document to check their
submissions before sending them to IANA.</t> submissions before sending them to IANA.</t>
<t>At least one Performance Metrics Expert should endeavor to complete
<t>At least one Performance Metric Expert should endeavor to complete
referred reviews in a timely manner. If the request is acceptable, the referred reviews in a timely manner. If the request is acceptable, the
Performance Metric Experts signify their approval to IANA, and IANA Performance Metrics Experts signify their approval to IANA, and IANA
updates the Performance Metrics Registry. If the request is not updates the Performance Metrics Registry. If the request is not
acceptable, the Performance Metric Experts MAY coordinate with the acceptable, the Performance Metrics Experts <bcp14>MAY</bcp14>
requester to change the request to be compliant, otherwise IANA SHALL coordinate with the requester to change the request so that it is
coordinate resolution of issues on behalf of the expert. The compliant; otherwise, IANA <bcp14>SHALL</bcp14> coordinate resolution
Performance Metric Experts MAY choose to reject clearly frivolous or of issues on behalf of the expert. The Performance Metrics Experts
inappropriate change requests outright, but such exceptional <bcp14>MAY</bcp14> choose to reject clearly frivolous or inappropriate
circumstances should be rare.</t> change requests outright, but such exceptional circumstances should be
rare.</t>
<t>This process should not in any way be construed as allowing the <t>If the proposed Metric is unique in a significant way, in order to
Performance Metric Experts to overrule IETF consensus. Specifically, properly describe the Metric, it may be necessary to propose a new Name
any Registered Performance Metrics that were added to the Performance Element Registry, or (more likely) a new Entry in an existing Name
Metrics Registry with IETF consensus require IETF consensus for Element Registry. This proposal is part of the request for the new
revision or deprecation.</t> Metric, so that it undergoes the same IANA review and approval
process.
<t>Decisions by the Performance Metric Experts may be appealed as in </t>
Section 7 of <xref target="RFC8126"/>.</t> <t>Decisions by the Performance Metrics Experts may be appealed per
<xref target="RFC8126" sectionFormat="of" section="10"/>.</t>
</section> </section>
<section anchor="revise-reg-perf-metrics" numbered="true" toc="default">
<section title="Revising Registered Performance Metrics"> <name>Backward-Compatible Revision of Registered Performance Metrics</na
<!-- <t>Requests to revise the Performance Metrics Registry or a me>
linked <t>A request for revision is only permitted when the requested changes
sub-registry are submitted to IANA, which forwards the request to a maintain backward compatibility with implementations of the prior
designated group of experts (Performance Metric Experts) appointed by Performance Metrics Registry Entry describing a Registered Performance
the IESG; these are the reviewers called for by the Expert Review Metric (entries with lower revision numbers but having the same Identifi
[RFC5226] policy defined for the Performance Metrics Registry. The er
Performance Metric Experts review the request for such things as
compliance with this document, compliance with other applicable
Performance Metric-related RFCs, and consistency with the currently
defined set of Registered Performance Metrics.</t>
<t>A request for Revision is only permitted when the requested changes
maintain backward-compatibility with implementations of the prior
Performance Metrics Registry entry describing a Registered Performance
Metric (entries with lower revision numbers, but the same Identifier
and Name).</t> and Name).</t>
<t>The purpose of the Status field in the Performance Metrics Registry i
<t>The purpose of the Status field in the Performance Metrics Registry s to indicate whether the entry for a Registered Performance Metric is 'Current'
is to indicate whether the entry for a Registered Performance Metric , 'Deprecated', or 'Obsolete'. The term 'deprecated' is used when an entry is re
is 'current' or 'deprecated'.</t> placed, either with a backwards-compatible revision (this sub-section) or with a
non-backwards-compatible revision (in <xref target="deprecating-metrics"/>).</t
>
<t>In addition, no policy is defined for revising the Performance <t>In addition, no policy is defined for revising the Performance
Metric entries in the IANA Registry or addressing errors therein. To Metric Entries in the IANA Registry or addressing errors therein. To
be clear, changes and deprecations within the Performance Metrics be clear, changes and deprecations within the Performance Metrics
Registry are not encouraged, and should be avoided to the extent Registry are not encouraged and should be avoided to the extent
possible. However, in recognition that change is inevitable, the possible. However, in recognition that change is inevitable, the
provisions of this section address the need for revisions.</t> provisions of this section address the need for revisions.</t>
<t>Revisions are initiated by sending a candidate Registered <t>Revisions are initiated by sending a candidate Registered
Performance Metric definition to IANA, as in Section 8.1, identifying Performance Metric definition to IANA, per <xref target="add-new-perf-me
the existing Performance Metrics Registry entry, and explaining how trics"/>, identifying
the existing Performance Metrics Registry Entry, and explaining how
and why the existing entry should be revised.</t> and why the existing entry should be revised.</t>
<t>The primary requirement in the definition of procedures for <t>The primary requirement in the definition of procedures for
managing changes to existing Registered Performance Metrics is managing changes to existing Registered Performance Metrics is
avoidance of measurement interoperability problems; the Performance avoidance of measurement interoperability problems; the Performance
Metric Experts must work to maintain interoperability above all else. Metrics Experts must work to maintain interoperability above all else.
Changes to Registered Performance Metrics may only be done in an Changes to Registered Performance Metrics may only be done in an
interoperable way; necessary changes that cannot be done in a way to interoperable way; necessary changes that cannot be done in a way that
allow interoperability with unchanged implementations MUST result in allows interoperability with unchanged implementations <bcp14>MUST</bcp1
4> result in
the creation of a new Registered Performance Metric (with a new Name, the creation of a new Registered Performance Metric (with a new Name,
replacing the RFCXXXXsecY portion of the name) and possibly the replacing the RFCXXXXsecY portion of the Name) and possibly the
deprecation of the earlier metric.</t> deprecation of the earlier metric.</t>
<t>A change to a Registered Performance Metric <bcp14>SHALL</bcp14> be d
<t>A change to a Registered Performance Metric SHALL be determined to etermined to
be backward-compatible when: <list style="numbers"> be backward compatible when: </t>
<t>it involves the correction of an error that is obviously only <ol spacing="normal" type="1">
editorial; or</t> <li>it involves the correction of an error that is obviously only
editorial, or</li>
<t>it corrects an ambiguity in the Registered Performance Metric's <li>it corrects an ambiguity in the Registered Performance Metric's
definition, which itself leads to issues severe enough to prevent definition, which itself leads to issues severe enough to prevent
the Registered Performance Metric's usage as originally defined; the Registered Performance Metric's usage as originally defined,
or</t> or</li>
<li>it corrects missing information in the metric definition
<t>it corrects missing information in the metric definition
without changing its meaning (e.g., the explicit definition of without changing its meaning (e.g., the explicit definition of
'quantity' semantics for numeric fields without a Data Type 'quantity' semantics for numeric fields without a Data Type
Semantics value); or</t> Semantics value), or</li>
<li>it harmonizes with an external reference that was itself
<t>it harmonizes with an external reference that was itself corrected, or</li>
corrected.</t> <li>if the current Registry format has been revised by adding a new
column that is not relevant to an existing Registered Performance
<!-- <t>"BENOIT: NOTE THAT THERE ARE MORE RULES IN RFC 70 Metric (i.e., the new column can be safely filled in with “Not
13 SECTION 5 Applicable”).</li>
BUT THEY WOULD ONLY APPLY TO THE ACTIVE/PASSIVE DRAFTS. TO BE </ol>
DISCUSSED."</t> -->
</list></t>
<t>If a Performance Metric revision is deemed permissible and <t>If a Performance Metric revision is deemed permissible and
backward-compatible by the Performance Metric Experts, according to backward compatible by the Performance Metrics Experts, according to
the rules in this document, IANA SHOULD execute the change(s) in the the rules in this document, IANA <bcp14>SHOULD</bcp14> execute the chang
e(s) in the
Performance Metrics Registry. The requester of the change is appended Performance Metrics Registry. The requester of the change is appended
to the original requester in the Performance Metrics Registry. The to the original requester in the Performance Metrics Registry. The
Name of the revised Registered Performance Metric, including the Name of the revised Registered Performance Metric, including the
RFCXXXXsecY portion of the name, SHALL remain unchanged (even when the RFCXXXXsecY portion of the Name, <bcp14>SHALL</bcp14> remain unchanged e
change is the result of IETF Standards Action; the revised registry ven when the
entry SHOULD reference the new immutable document, such as an RFC or change is the result of IETF Standards Action. The revised Registry
for other standards bodies, it is likely to be necessary to reference Entry <bcp14>SHOULD</bcp14> reference the new immutable document, such a
s an RFC. For other standards bodies, it is likely to be necessary to reference
a specific, dated version of a specification, in an appropriate a specific, dated version of a specification, in an appropriate
category and column).</t> category and column.</t>
<t>Each Registered Performance Metric in the Performance Metrics <t>Each Registered Performance Metric in the Performance Metrics
Registry has a revision number, starting at zero. Each change to a Registry has a revision number, starting at zero. Each change to a
Registered Performance Metric following this process increments the Registered Performance Metric following this process increments the
revision number by one.</t> revision number by one.</t>
<t>When a revised Registered Performance Metric is accepted into the <t>When a revised Registered Performance Metric is accepted into the
Performance Metrics Registry, the date of acceptance of the most Performance Metrics Registry, the date of acceptance of the most
recent revision is placed into the revision Date column of the recent revision is placed into the Revision Date column of the
registry for that Registered Performance Metric.</t> Registry for that Registered Performance Metric.</t>
<t>Where applicable, additions to Registered Performance Metrics in <t>Where applicable, additions to Registered Performance Metrics in
the form of text Comments or Remarks should include the date, but such the form of text in the Comments or Remarks column should include the da te, but such
additions may not constitute a revision according to this process.</t> additions may not constitute a revision according to this process.</t>
<t>Older versions of the updated Metric Entries are kept in the
<t>Older version(s) of the updated metric entries are kept in the Registry for archival purposes. The older entries are kept with all
registry for archival purposes. The older entries are kept with all fields unmodified (including Revision Date) except for the Status field,
fields unmodified (version, revision date) except for the status field which <bcp14>SHALL</bcp14> be changed to 'Deprecated'.</t>
that SHALL be changed to "Deprecated".</t> <t>This process should not in any way be construed as allowing the
Performance Metrics Experts to overrule IETF consensus.
Specifically, any Registered Performance Metrics that were added to
the Performance Metrics Registry with IETF consensus require IETF
consensus for revision or deprecation.</t>
</section> </section>
<section title="Deprecating Registered Performance Metrics"> <section anchor="deprecating-metrics" numbered="true" toc="default">
<t>Changes that are not permissible by the above criteria for <name>Non-Backward-Compatible Deprecation of Registered Performance Metr
Registered Performance Metric's revision may only be handled by ics</name>
deprecation. A Registered Performance Metric MAY be deprecated and <t>This section describes how to make a non-backward-compatible update
replaced when: <list style="numbers"> to a Registered Performance Metric. A Registered Performance Metric
<t>the Registered Performance Metric definition has an error or <bcp14>MAY</bcp14> be deprecated and replaced when:</t>
shortcoming that cannot be permissibly changed as in Section 8.2 <ol spacing="normal" type="1">
Revising Registered Performance Metrics; or</t> <li>the Registered Performance Metric definition has an error or
shortcoming that cannot be permissibly changed per <xref target="rev
<t>the deprecation harmonizes with an external reference that was ise-reg-perf-metrics"/>
("Revising Registered Performance Metrics"), or</li>
<li>the deprecation harmonizes with an external reference that was
itself deprecated through that reference's accepted deprecation itself deprecated through that reference's accepted deprecation
method.</t> method.</li>
</list></t> </ol>
<t>A request for deprecation is sent to IANA, which passes it to the <t>A request for deprecation is sent to IANA, which passes it to the
Performance Metric Experts for review. When deprecating an Performance Performance Metrics Experts for review. When deprecating a Performance
Metric, the Performance Metric description in the Performance Metrics Metric, the Performance Metric Description in the Performance Metrics
Registry must be updated to explain the deprecation, as well as to Registry <bcp14>MUST</bcp14> be updated to explain the deprecation, as w
refer to any new Performance Metrics created to replace the deprecated ell as to
refer to the new Performance Metric created to replace the deprecated
Performance Metric.</t> Performance Metric.</t>
<t>When a new, non-backward-compatible Performance Metric replaces a
<t>The revision number of a Registered Performance Metric is (now) deprecated metric, the revision number of the new Registered
incremented upon deprecation, and the revision Date updated, as with Performance Metric is incremented over the value in the deprecated
any revision.</t> version, and the current date is entered as the Revision Date of the
new Registered Performance Metric.</t>
<t>The intentional use of deprecated Registered Performance Metrics <t>The intentional use of deprecated Registered Performance Metrics
should result in a log entry or human-readable warning by the should result in a log entry or human-readable warning by the
respective application.</t> respective application.</t>
<t>Names and Metric IDs of deprecated Registered Performance Metrics <t>Names and Metric IDs of deprecated Registered Performance Metrics
must not be reused.</t> must not be reused.</t>
<t>The deprecated entries are kept with all Administrative columns
<t>The deprecated entries are kept with all fields unmodified, except unmodified, except the Status field (which is changed to
the version, revision date, and the status field (changed to 'Deprecated').</t>
"Deprecated").</t>
</section> </section>
</section> <section numbered="true" toc="default">
<name>Obsolete Registry Entries</name>
<t>Existing Registry Entries may become obsolete over time due to:</t>
<ol>
<li>the Registered Performance Metric is found to contain considerable
errors (and no one sees the value in the effort to fix it), or</li>
<li>one or more critical References (or sections thereof) have been
designated obsolete by the SDO, or</li>
<li>other reasons brought to the attention of IANA and the Registry
Experts.</li>
</ol>
<t>When a Performance Metric Registry Entry is declared obsolete, the
Performance Metric Description in the Performance Metrics Registry is
updated to explain the reasons the Entry is now obsolete and has not
been replaced (Deprecation always involves replacement).</t>
<t> Obsolete entries are kept with all Administrative columns
unmodified, except the Status field (which is changed to
'Obsolete'). </t>
</section>
<section numbered="true" toc="default">
<name>Registry Format Version and Future Changes/Extensions</name>
<t>The Registry Format Version defined in this memo is 1.0, and candidate
Registry Entries complying with this memo <bcp14>MUST</bcp14> use 1.0.</t>
<!-- <section title="Performance Metrics Registry and other Registries"> <t>The Registry Format can only be updated by publishing a new RFC with
<t>BENOIT: TBD.</t> the new format (Standards Action).</t>
<t>THE BASIC IDEA IS THAT PEOPLE COULD DIRECTLY DEFINE PERF. METRICS IN <t>When a Registered Performance Metric is created or revised, then it
OTHER EXISTING REGISTRIES, FOR SPECIFIC PROTOCOL/ENCODING. EXAMPLE: uses the most recent Registry Format Version.</t>
IPFIX. IDEALLY, ALL PERF. METRICS SHOULD BE DEFINED IN THIS REGISTRY AND
REFERS TO FROM OTHER REGISTRIES.</t> <t>Only one form of Registry extension is envisaged:</t>
<t indent="3">Adding columns, or both categories and columns, to accommodate
unanticipated aspects of new measurements and metric categories.</t>
<t>If the Performance Metrics Registry is extended in this way, the
version number of future entries complying with the extension <bcp14>SHALL</b
cp14>
be incremented (in either the unit or the tenths digit, depending
on the degree of extension).</t>
</section>
</section> </section>
<section title="Security considerations"> <section numbered="true" toc="default">
<t>This draft defines a registry structure, and does not itself <name>Security Considerations</name>
<t>This document defines a Registry structure and does not itself
introduce any new security considerations for the Internet. The introduce any new security considerations for the Internet. The
definition of Performance Metrics for this registry may introduce some definition of Performance Metrics for this Registry may introduce some
security concerns, but the mandatory references should have their own security concerns, but the mandatory references should have their own
considerations for security, and such definitions should be reviewed considerations for security, and such definitions should be reviewed
with security in mind if the security considerations are not covered by with security in mind if the security considerations are not covered by
one or more reference standards.</t> one or more reference standards.</t>
<t>The aggregated results of the Performance Metrics described in this
<t>The aggregated results of the performance metrics described in this Registry might reveal network topology information that may be
registry might reveal network topology information that may be
considered sensitive. If such cases are found, then access control considered sensitive. If such cases are found, then access control
mechanisms should be applied.</t> mechanisms should be applied.</t>
</section> </section>
<section anchor="iana-cons" numbered="true" toc="default">
<name>IANA Considerations</name>
<t>With the background and processes described in earlier sections, IANA
has taken the actions described below.</t>
<section title="IANA Considerations"> <section numbered="true" toc="default">
<t>With the background and processes described in earlier sections, this <name>Registry Group</name>
document requests the following IANA Actions.</t> <t>The new Registry group is named Performance Metrics. This document
refers to it as the “Performance Metrics Group” or “Registry Group",
meaning all registrations appearing on <eref target="https://www.iana.or
g/assignments/performance-metrics">&lt;https://www.iana.org/assignments/performa
nce-metrics&gt;</eref>.</t>
<t>Editor's Note: Mock-ups of the implementation of this set of requests <t>For clarity, note that this document and <xref target="RFC8912"/>
have been prepared with IANA's help during development of this memo, and use the following conventions to refer to the various IANA registries
have been captured in the Proceedings of IPPM working group sessions. related to Performance Metrics.</t>
IANA is currently preparing a mock-up. A recent version is available
here: http://encrypted.net/IETFMetricsRegistry-106.html</t>
<section title="Registry Group"> <table anchor="IANAterms-map">
<t>The new registry group SHALL be named, "PERFORMANCE METRICS <thead>
Group".</t> <tr>
<th></th>
<th>RFC 8911 and RFC 8912</th>
<th>IANA Web page</th>
</tr>
</thead>
<tbody>
<tr>
<td>Page Title</td>
<td>Performance Metrics Group</td>
<td>Performance Metrics</td>
</tr>
<tr>
<td>Main Registry</td>
<td>Performance Metrics Registry</td>
<td>Performance Metrics Registry</td>
</tr>
<tr>
<td>Registry Row</td>
<td>Performance Metrics Registry Entry</td>
<td>registration (also template)</td>
</tr>
</tbody>
</table>
<t>Registration Procedure: Specification Required</t> <t>Registration Procedure: Specification Required</t>
<t>Reference: RFC 8911</t>
<t>Reference: &lt;This RFC&gt;</t>
<t>Experts: Performance Metrics Experts</t> <t>Experts: Performance Metrics Experts</t>
<!-- <t>Note: TBD</t> -->
<t>Note: TBD</t>
</section> </section>
<section numbered="true" toc="default">
<section title="Performance Metric Name Elements"> <name>Performance Metrics Name Elements</name>
<t>This document specifies the procedure for Performance Metrics Name <t>This memo specifies and populates the Registries for the
Element Registry setup. IANA is requested to create a new set of Performance Metric Name Elements. The Name assigned to a Performance
registries for Performance Metric Name Elements called "Registered Metric Registry Entry consists of multiple Elements separated by an
Performance Metric Name Elements". Each Registry, whose names are "_" (underscore), in the order defined in <xref
listed below:</t> target="name-sec7-1-2"/>. IANA has created the following registries,
which contain the current set of possibilities for each Element in the
<t><list style="empty"> Performance Metric Name.</t>
<t>MetricType:</t> <ul empty="true" spacing="normal">
<li>MetricType</li>
<t>Method:</t> <li>Method</li>
<li>SubTypeMethod</li>
<t>SubTypeMethod:</t> <li>Spec</li>
<li>Units</li>
<t>Spec:</t> <li>Output</li>
</ul>
<t>Units:</t> <t>At creation, IANA has populated the Registered Performance Metrics Na
me Elements
<t>Output:</t> using the lists of values for each Name
</list></t> Element listed in <xref target="name-sec7-1-2"/>. The Name Elements in e
ach Registry
<t>will contain the current set of possibilities for Performance are case sensitive.</t>
Metrics Registry Entry Names.</t> <t>When preparing a Metric Entry for registration, the developer
<bcp14>SHOULD</bcp14> choose Name Elements from among the registered ele
<t>To populate the Registered Performance Metric Name Elements at ments.
creation, the IANA is asked to use the lists of values for each name
element listed in Section 7.1.2. The Name Elements in each registry
are case-sensitive.</t>
<t>When preparing a Metric entry for Registration, the developer
SHOULD choose Name elements from among the registered elements.
However, if the proposed metric is unique in a significant way, it may However, if the proposed metric is unique in a significant way, it may
be necessary to propose a new Name element to properly describe the be necessary to propose a new Name Element to properly describe the
metric, as described below.</t> metric, as described below.</t>
<t>A candidate Metric Entry RFC or immutable document for IANA and <t>A candidate Metric Entry proposes a set of values for its Name
Expert Review would propose one or more new element values required to Elements. These are reviewed by IANA and an Expert Reviewer. It is
describe the unique entry, and the new name element(s) would be possible that a candidate Metric Entry proposes a new value for a Name
reviewed along with the metric entry. New assignments for Registered Element (that is, one that is not in the existing list of
Performance Metric Name Elements will be administered by IANA through possibilities), or even that it proposes a new Name Element. Such new
Specification Required policy (which includes Expert Review) <xref assignments are administered by IANA through the Specification
target="RFC8126"/>, i.e., review by one of a group of experts, the Required policy <xref target="RFC8126" format="default"/>, which include
Performance Metric Experts, who are appointed by the IESG upon s Expert Review (i.e., review
recommendation of the Transport Area Directors.</t> by one of a group of Performance Metrics Experts, who are appointed by
the IESG upon recommendation of the Transport Area Directors).</t>
</section> </section>
<section numbered="true" toc="default">
<section title="New Performance Metrics Registry"> <name>New Performance Metrics Registry</name>
<t>This document specifies the procedure for Performance Metrics <t>This document specifies the Performance Metrics Registry.
Registry setup. IANA is requested to create a new registry for The Registry contains the following columns in the Summary category:</t>
Performance Metrics called "Performance Metrics Registry". This <ul empty="true" spacing="normal">
Registry will contain the following Summary columns:</t> <li>Identifier</li>
<li>Name</li>
<t><list style="empty"> <li>URI</li>
<t>Identifier:</t> <li>Description</li>
<li>Reference</li>
<t>Name:</t> <li>Change Controller</li>
<li>Version</li>
<t>URI:</t> </ul>
<t>Descriptions of these columns and additional information
<t>Description:</t> found in the template for Registry Entries (categories and columns)
are further defined in <xref target="columns" format="default"/>.</t>
<t>Reference:</t>
<t>Change Controller:</t>
<t>Version:</t>
</list>Descriptions of these columns and additional information
found in the template for registry entries (categories and columns)
are further defined in section <xref target="columns"/>.</t>
<t>The Identifier 0 should be Reserved. The Registered Performance <t>The Identifier 0 should be Reserved. The Registered Performance
Metric unique identifier is an unbounded integer (range 0 to Metric unique Identifier is an unbounded integer (range 0 to
infinity). The Identifier values from 64512 to 65536 are reserved for infinity). The Identifier values from 64512 to 65535 are reserved for
private or experimental use, and the user may encounter overlapping private or experimental use, and the user may encounter overlapping
uses. When adding newly Registered Performance Metrics to the uses. When adding new Registered Performance Metrics to the
Performance Metrics Registry, IANA SHOULD assign the lowest available Performance Metrics Registry, IANA <bcp14>SHOULD</bcp14> assign the lowe
identifier to the new Registered Performance Metric. If a Performance st available
Identifier to the new Registered Performance Metric. If a Performance
Metrics Expert providing review determines that there is a reason to Metrics Expert providing review determines that there is a reason to
assign a specific numeric identifier, possibly leaving a temporary gap assign a specific numeric Identifier, possibly leaving a temporary gap
in the numbering, then the Performance Expert SHALL inform IANA of in the numbering, then the Performance Metrics Expert <bcp14>SHALL</bcp1
4> inform IANA of
this decision.</t> this decision.</t>
<t>Names starting with the prefix "Priv_" are reserved for private use
<t>Names starting with the prefix Priv_ are reserved for private use, and are not considered for registration. The Name column entries are
and are not considered for registration. The "Name" column entries are further defined in <xref target="columns" format="default"/>.</t>
further defined in section <xref target="columns"/>.</t> <t>The URI column will have a URL to each completed
Registry Entry. The Registry Entry text <bcp14>SHALL</bcp14> be HTMLized
<t>The "URI" column will have a URL to the full template of each to aid the
registry entry. The Registry Entry text SHALL be HTML-ized to aid the reader (similar to the way that Internet-Drafts are HTMLized, the same t
reader, with links to reference RFCs (similar to the way that Internet ool can perform the function), with links to referenced section(s) of an RFC or
Drafts are HTML-ized, the same tool can perform the function) or another
immutable document.</t>
<t>The Reference column will include an RFC number, an approved
specification designator from another standards body, or some other
immutable document.</t> immutable document.</t>
<t>The &ldquo;Reference&rdquo; column will include an RFC number, an <t>New assignments for the Performance Metrics Registry will be
approved specification designator from another standards body, or administered by IANA through the Specification Required policy
other immutable document.</t> <xref target="RFC8126" format="default"/> (which includes Expert Review, i.e.
, review by one of a
<t>New assignments for Performance Metrics Registry will be group of experts -- in the case of this document, the Performance
administered by IANA through Specification Required policty (which Metrics Experts, who are appointed by the IESG upon recommendation of
includes Expert Review) <xref target="RFC8126"/>, i.e., review by one the Transport Area Directors) or by Standards Action. The experts can be ini
of a group of experts, the Performance Metric Experts, who are tially drawn
appointed by the IESG upon recommendation of the Transport Area
Directors, or by Standards Action. The experts can be initially drawn
from the Working Group Chairs, document editors, and members of the from the Working Group Chairs, document editors, and members of the
Performance Metrics Directorate, among other sources of experts.</t> Performance Metrics Directorate, among other sources of experts.</t>
<t>Extensions to the Performance Metrics Registry require IETF
<t>Extensions of the Performance Metrics Registry require IETF Standards Action. Only one form of Registry extension is
Standards Action. Only one form of registry extension is
envisaged:</t> envisaged:</t>
<ul empty="false" spacing="normal">
<t><list style="numbers"> <li>Adding columns, or both categories and columns, to accommodate
<t>Adding columns, or both categories and columns, to accommodate
unanticipated aspects of new measurements and metric unanticipated aspects of new measurements and metric
categories.</t> categories.</li>
</list>If the Performance Metrics Registry is extended in this way, </ul>
the Version number of future entries complying with the extension <t>If the Performance Metrics Registry is extended in this way,
SHALL be incremented (either in the unit or tenths digit, depending on the version number of future entries complying with the extension
the degree of extension.</t> <bcp14>SHALL</bcp14> be incremented (in either the unit or the tenths di
git, depending on
the degree of extension).</t>
</section> </section>
</section> </section>
<section anchor="blank-reg-template" numbered="true" toc="default">
<section title="Blank Registry Template"> <name>Blank Registry Template</name>
<t>This section provides a blank template to help IANA and registry <t>This section provides a blank template to help IANA and Registry
entry writers.</t> Entry writers.</t>
<section numbered="true" toc="default">
<section title="Summary"> <name>Summary</name>
<t>This category includes multiple indexes to the registry entry: the <t>This category includes multiple indexes to the Registry Entry: the
element ID and metric name.</t> element ID and Metric Name.</t>
<section numbered="true" toc="default">
<section title="ID (Identifier)"> <name>ID (Identifier)</name>
<t>&lt;insert a numeric identifier, an integer, TBD&gt;</t> <t>&lt;insert a numeric Identifier, an integer, TBD&gt;</t>
</section> </section>
<section numbered="true" toc="default">
<section title="Name"> <name>Name</name>
<t>&lt;insert name according to metric naming convention&gt;</t> <t>&lt;insert the Name, according to the metric naming convention&gt;<
/t>
</section> </section>
<section numbered="true" toc="default">
<section title="URI"> <name>URI</name>
<t>URL: https://www.iana.org/ ... &lt;name&gt;</t> <t>URL: <eref target="https://www.iana.org/performance-metrics/"/>
... &lt;Name&gt;</t>
</section> </section>
<section numbered="true" toc="default">
<section title="Description"> <name>Description</name>
<t>&lt;provide a description&gt;</t> <t>&lt;provide a description&gt;</t>
</section> </section>
<section numbered="true" toc="default">
<section title="Change Controller"> <name>Reference</name> <t>&lt;provide the RFC or other specification
<t/> that contains the approved candidate Registry Entry&gt;</t>
</section> </section>
<section numbered="true" toc="default">
<section title="Version (of Registry Format)"> <name>Change Controller</name>
<t/> <t>&lt;provide information regarding the entity responsible for
approving revisions to the Registry Entry (including contact informati
on for an individual, where appropriate)&gt;</t>
</section>
<section numbered="true" toc="default">
<name>Version (of Registry Format)</name>
</section> </section>
</section> </section>
<section title="Metric Definition"> <section numbered="true" toc="default">
<name>Metric Definition</name>
<t>This category includes columns to prompt the entry of all necessary <t>This category includes columns to prompt the entry of all necessary
details related to the metric definition, including the immutable details related to the metric definition, including the immutable
document reference and values of input factors, called fixed document reference and values of input factors, called "Fixed
parameters.</t> Parameters".</t>
<section numbered="true" toc="default">
<section title="Reference Definition"> <name>Reference Definition</name>
<t>&lt;Full bibliographic reference to an immutable doc.&gt;</t> <t>&lt;provide a full bibliographic reference to an immutable document
&gt;</t>
<t>&lt;specific section reference and additional clarifications, if <t>&lt;provide a specific section reference and additional clarificati
ons, if
needed&gt;</t> needed&gt;</t>
<t/>
</section> </section>
<section numbered="true" toc="default">
<section title="Fixed Parameters"> <name>Fixed Parameters</name>
<t>&lt;list and specify Fixed Parameters, input factors that must be <t>&lt;list and specify Fixed Parameters, input factors that must be
determined and embedded in the measurement system for use when determined and embedded in the measurement system for use when
needed&gt;</t> needed&gt;</t>
</section> </section>
</section> </section>
<section numbered="true" toc="default">
<section title="Method of Measurement"> <name>Method of Measurement</name>
<t>This category includes columns for references to relevant sections <t>This category includes columns for references to relevant sections
of the immutable documents(s) and any supplemental information needed of the immutable document&wj;(s) and any supplemental information needed
to ensure an unambiguous methods for implementations.</t> to ensure an unambiguous method for implementations.</t>
<section numbered="true" toc="default">
<section title="Reference Method"> <name>Reference Method</name>
<t>&lt;for metric, insert relevant section references and <t>&lt;for the metric, insert relevant section references and
supplemental info&gt;</t> supplemental info&gt;</t>
</section> </section>
<section numbered="true" toc="default">
<section title="Packet Stream Generation"> <name>Packet Stream Generation</name>
<t>&lt;list of generation parameters and section/spec references if <t>&lt;provide a list of generation Parameters and section/spec refere
nces if
needed&gt;</t> needed&gt;</t>
</section> </section>
<section title="Traffic Filtering (observation) Details"> <section numbered="true" toc="default">
<t>The measured results based on a filtered version of the packets <name>Traffic Filtering (Observation) Details</name>
observed, and this section provides the filter details (when <t>This category provides the filter details (when present), which
present).</t> qualify the set of packets that contribute to the measured results
from among all packets observed.</t>
<t>&lt;section reference&gt;.</t> <t>&lt;provide a section reference&gt;</t>
<t/>
</section> </section>
<section numbered="true" toc="default">
<section title="Sampling Distribution"> <name>Sampling Distribution</name>
<t>&lt;insert time distribution details, or how this is diff from <t>&lt;insert time distribution details, or how this is different from
the filter&gt;</t> the filter&gt;</t>
<t/>
</section> </section>
<section numbered="true" toc="default">
<section title="Run-time Parameters and Data Format"> <name>Runtime Parameters and Data Format</name>
<t>Run-time Parameters are input factors that must be determined, <t>Runtime Parameters are input factors that must be determined,
configured into the measurement system, and reported with the configured into the measurement system, and reported with the
results for the context to be complete.</t> results for the context to be complete.</t>
<t>&lt;provide a list of Runtime Parameters and their data formats&gt;
<t>&lt;list of run-time parameters, and their data formats&gt;</t> </t>
<t/>
</section> </section>
<section title="Roles"> <section numbered="true" toc="default">
<t>&lt;lists the names of the different roles from the measurement <name>Roles</name>
method&gt;</t> <t>&lt;list the names of the different Roles from the Measurement
Method&gt;</t>
<t/>
</section> </section>
</section> </section>
<section title="Output"> <section numbered="true" toc="default">
<t>This category specifies all details of the Output of measurements <name>Output</name>
<t>This category specifies all details of the output of measurements
using the metric.</t> using the metric.</t>
<section title="Type"> <section numbered="true" toc="default">
<t>&lt;insert name of the output type, raw or a selected summary <name>Type</name>
<t>&lt;insert the name of the output type -- raw results or a selected
summary
statistic&gt;</t> statistic&gt;</t>
</section> </section>
<section title="Reference Definition"> <section numbered="true" toc="default">
<name>Reference Definition</name>
<t>&lt;describe the reference data format for each type of <t>&lt;describe the reference data format for each type of
result&gt;</t> result&gt;</t>
</section> </section>
<section title="Metric Units"> <section numbered="true" toc="default">
<t>&lt;insert units for the measured results, and the reference <name>Metric Units</name>
specification&gt;.</t> <t>&lt;insert units for the measured results, and provide the referenc
e
specification&gt;</t>
</section> </section>
<section title="Calibration"> <section numbered="true" toc="default">
<name>Calibration</name>
<t>&lt;insert information on calibration&gt;</t> <t>&lt;insert information on calibration&gt;</t>
</section> </section>
</section> </section>
<section title="Administrative items"> <section numbered="true" toc="default">
<t/> <name>Administrative Items</name>
<t>This category provides administrative information.</t>
<section title="Status"> <section numbered="true" toc="default">
<t>&lt;current or deprecated&gt;</t> <name>Status</name>
<t>&lt;provide status: 'Current' or 'Deprecated'&gt;</t>
</section> </section>
<section title="Requester"> <section numbered="true" toc="default">
<t>&lt;name or RFC, etc.&gt;</t> <name>Requester</name>
<t>&lt;provide a person's name, an RFC number, etc.&gt;</t>
</section> </section>
<section title="Revision"> <section numbered="true" toc="default">
<t>&lt;1.0&gt;</t> <name>Revision</name>
<t>&lt;provide the revision number: starts at 0&gt;</t>
</section> </section>
<section title="Revision Date"> <section numbered="true" toc="default">
<t>&lt;format YYYY-MM-DD&gt;</t> <name>Revision Date</name>
<t>&lt;provide the date, in YYYY-MM-DD format&gt;</t>
</section> </section>
</section> </section>
<section title="Comments and Remarks"> <section numbered="true" toc="default">
<t>&lt;Additional (Informational) details for this entry&gt;</t> <name>Comments and Remarks</name>
<t>&lt;list any additional (informational) details for this entry&gt;</t
>
</section> </section>
</section> </section>
<section title="Acknowledgments">
<t>Thanks to Brian Trammell and Bill Cerveny, IPPM chairs, for leading
some brainstorming sessions on this topic. Thanks to Barbara Stark and
Juergen Schoenwaelder for the detailed feedback and suggestions. Thanks
to Andrew McGregor for suggestions on metric naming. Thanks to Michelle
Cotton for her early IANA review, and to Amanda Barber for answering
questions related to the presentation of the registry and accessibility
of the complete template via URL. Thanks to Roni Even for his review and
suggestions to generalize the procedures. Thanks to ~all the Area
Directors for their reviews.</t>
</section>
<!--
<section title="Appendix: Examples">
<section title="Example IPPM Active Registry Entry">
<t>This section is Informational.</t>
<t>This section gives an example registry entry for the active metr
ic
described in <xref target="RFC3393"/>, on Packet Delay Variation.</
t>
<section title="Registry Indexes">
<t>This category includes multiple indexes to the Registered Perf
ormance Metrics,
the element ID and metric name.</t>
<section title="Identifier">
<t>An integer having enough digits to uniquely identify each en
try
in the Registry.</t>
</section>
<section title="Name">
<t>A metric naming convention is TBD.</t>
<t>One possibility based on IPPM's framework is:</t>
<t>Act_IP_UDP_One-way-pdv_95th-percentile_Poisson</t>
</section>
<section title="URI">
<t>Prefix urn:ietf:params:performance:metric</t>
</section>
<section title="Status">
<t>current</t>
</section>
<section title="Requestor">
<t>Alcelip Mornuley</t>
</section>
<section title="Revision">
<t>1.0</t>
</section>
<section title="Revision Date">
<t>2014-07-04</t>
</section>
<section title="Description">
<t>An assessment of packet delay variation with respect to the
minimum delay observed on the stream.</t>
</section>
<section title="Reference Specification(s)">
<t><xref target="RFC2330"/><xref target="RFC3393"/><xref
target="RFC5481"/><xref target="RFC5905"/></t>
</section>
</section>
<section title="Metric Definition">
<t>This category includes columns to prompt the entry of all nece
ssary
details related to the metric definition, including the RFC refer
ence
and values of input factors, called fixed parameters.</t>
<section title="Reference Definition">
<t>See sections 2.4 and 3.4 of <xref target="RFC3393"/>. Single
ton
delay differences measured are referred to by the variable name
"ddT".</t>
</section>
<section title="Fixed Parameters">
<t>Since the metric's reference supplies a list of Parameters a
s
part of its descriptive template, a sub-set of the Parameters h
ave
been designated as designated as Fixed Parameters for this
entry.</t>
<t><list style="symbols">
<t>F, a selection function defining unambiguously the packe
ts
from the stream selected for the metric. See section 4.2 of
<xref target="RFC5481"/> for the PDV form.</t>
<t>L, a packet length in bits. L = 200 bits.</t>
<t>Tmax, a maximum waiting time for packets to arrive at Ds
t,
set sufficiently long to disambiguate packets with long del
ays
from packets that are discarded (lost). Tmax = 3 seconds.</
t>
<t>Type-P, as defined in <xref target="RFC2330"/>, which
includes any field that may affect a packet's treatment as
it
traverses the network. The packets are IP/UDP, with DSCP =
0
(BE).</t>
</list></t>
</section>
</section>
<section title="Method of Measurement">
<t>This category includes columns for references to relevant sect
ions
of the RFC(s) and any supplemental information needed to ensure a
n
unambiguous methods for implementations.</t>
<section title="Reference Method">
<t>See section 2.6 and 3.6 of <xref target="RFC3393"/> for sing
leton
elements.</t>
</section>
<section title="Stream Type and Stream Parameters">
<t>Poisson distributed as described in <xref target="RFC2330"/>
,
with the following Parameters.</t>
<t><list style="symbols">
<t>lambda, a rate in reciprocal seconds (for Poisson Stream
s).
lambda = 1 packet per second</t>
<t>Upper limit on Poisson distribution (values above this l
imit
will be clipped and set to the limit value). Upper limit =
30
seconds.</t>
</list></t>
</section>
<section title="Traffic Filter">
<t>NA</t>
</section>
<section title="Measurement Timing">
<t>NA</t>
</section>
<section title="Output Type and Data Format">
<t>See section 4.3 of <xref target="RFC3393"/> for details on t
he
percentile statistic.</t>
<t>The percentile = 95.</t>
<t>Data format is a 32-bit unsigned floating point value.</t>
<t>Individual results (singletons) should be represented by the
following triple</t>
<t><list style="symbols">
<t>T1 and T2, times as described below in the Run-time
parameters section.</t>
<t>ddT as defined in section 2.4 of <xref target="RFC3393"/
></t>
</list>if needed. The result format for ddT is *similar to* t
he
short format in <xref target="RFC5905"/> (32 bits) and is as
follows: the first 16 bits represent the *signed* integer numbe
r of
seconds; the next 16 bits represent the fractional part of a
second.</t>
</section>
<section title="Metric Units">
<t>See section 3.3 of <xref target="RFC3393"/> for singleton
elements.</t>
<t><xref target="RFC2330"/> recommends that when a time is give
n, it
will be expressed in UTC.</t>
<t>The timestamp format (for T, Tf, etc.) is the same as in <xr
ef
target="RFC5905"/> (64 bits) and is as follows: the first 32 bi
ts
represent the unsigned integer number of seconds elapsed since
0h on
1 January 1900; the next 32 bits represent the fractional part
of a
second that has elapsed since then.</t>
</section>
<section title="Run-time Parameters and Data Format">
<t>Since the metric's reference supplies a list of Parameters a
s
part of its descriptive template, a sub-set of the Parameters h
ave
been designated as Run-Time Parameters for this entry. In relat
ed
Registered Performance Metrics, some of the parameters below ma
y be designated as
Fixed Parameters instead.</t>
<t><list style="symbols">
<t>Src, the IP address of a host (32-bit value for IPv4, 12
8-bit
value for IPv6)</t>
<t>Dst, the IP address of a host (32-bit value for IPv4, 12
8-bit
value for IPv6)</t>
<t>T, a time (start of test interval, 128-bit NTP Date Form
at,
see section 6 of <xref target="RFC5905"/>)</t>
<t>Tf, a time (end of test interval, 128-bit NTP Date Forma
t,
see section 6 of <xref target="RFC5905"/>)</t>
<t>T1, the wire time of the first packet in a pair, measure
d at
MP(Src) as it leaves for Dst (64-bit NTP Timestamp Format,
see
section 6 of <xref target="RFC5905"/>).</t>
<t>T2, the wire time of the second packet in a pair, measur
ed at
MP(Src) as it leaves for Dst (64-bit NTP Timestamp Format,
see
section 6 of <xref target="RFC5905"/>).</t>
<t>I(i),I(i+1), i &gt;=0, pairs of times which mark the
beginning and ending of the intervals in which the packet s
tream
from which the measurement is taken occurs. Here, I(0) = T0
and
assuming that n is the largest index, I(n) = Tf (pairs of 6
4-bit
NTP Timestamp Format, see section 6 of <xref target="RFC590
5"/>).</t>
</list></t>
</section>
</section>
<section title="Comments and Remarks">
<t>Lost packets represent a challenge for delay variation metrics
. See
section 4.1 of <xref target="RFC3393"/> and the delay variation
applicability statement<xref target="RFC5481"/> for extensive ana
lysis
and comparison of PDV and an alternate metric, IPDV.</t>
</section>
</section>
<section title="Example RTCP-XR Registry Entry">
<t>This section is Informational.</t>
<t>This section gives an example registry entry for the end-point m
etric
described in <xref target="RFC7003"/>, for RTCP-XR Burst/Gap
Discard Metric reporting.</t>
<section title="Registry Indexes">
<t>This category includes multiple indexes to the Registered Perf
ormance Metrics,
the element ID and metric name.</t>
<section title="Identifier">
<t>An integer having enough digits to uniquely identify each en
try
in the Registry.</t>
</section>
<section title="Name">
<t>A metric naming convention is TBD.</t>
</section>
<section title="URI">
<t>Prefix urn:ietf:params:performance:metric</t>
</section>
<section title="Status">
<t>current</t>
</section>
<section title="Requestor">
<t>Alcelip Mornuley</t>
</section>
<section title="Revision">
<t>1.0</t>
</section>
<section title="Revision Date">
<t>2014-07-04</t>
</section>
<section title="Description">
<t>TBD.</t>
</section>
<section title="Reference Specification(s)">
<t><xref target="RFC3611"/><xref target="RFC4566"/>
<xref target="RFC6776"/><xref target="RFC6792"/>
<xref target="RFC7003"/></t>
</section>
</section>
<section title="Metric Definition">
<t>This category includes columns to prompt the entry of all nece
ssary
details related to the metric definition, including the RFC refer
ence
and values of input factors, called fixed parameters. Section 3.2
of
<xref target="RFC7003"/> provides the reference information for t
his
category.</t>
<section title="Reference Definition">
<t>Packets Discarded in Bursts:</t>
<t>The total number of packets discarded during discard bursts.
The
measured value is unsigned value. If the measured value exceeds
0xFFFFFD, the value 0xFFFFFE MUST be reported to indicate an
over-range measurement. If the measurement is unavailable, the
value
0xFFFFFF MUST be reported.</t>
</section>
<section title="Fixed Parameters">
<t>Fixed Parameters are input factors that must be determined a
nd
embedded in the measurement system for use when needed. The val
ues
of these parameters is specified in the Registry.</t>
<t>Threshold: 8 bits, set to value = 3 packets.</t>
<t>The Threshold is equivalent to Gmin in [RFC3611], i.e., the
number of successive packets that must not be discarded prior t
o and
following a discard packet in order for this discarded packet t
o be
regarded as part of a gap. Note that the Threshold is set in
accordance with the Gmin calculation defined in Section 4.7.2 o
f
[RFC3611].</t>
<t>Interval Metric flag: 2 bits, set to value 11=Cumulative
Duration</t>
<t>This field is used to indicate whether the burst/gap discard
metrics are Sampled, Interval, or Cumulative metrics <xref targ
et="RFC6792"/>:</t>
<t>I=10: Interval Duration - the reported value applies to the
most
recent measurement interval duration between successive metrics
reports.</t>
<t>I=11: Cumulative Duration - the reported value applies to th
e
accumulation period characteristic of cumulative measurements.<
/t>
<t>Senders MUST NOT use the values I=00 or I=01.</t>
</section>
</section>
<section title="Method of Measurement">
<t>This category includes columns for references to relevant sect
ions
of the RFC(s) and any supplemental information needed to ensure a
n
unambiguous methods for implementations. For the Burst/Gap Discar
d
Metric, it appears that the only guidance on methods of measureme
nt is
in Section 3.0 of <xref target="RFC7003"/> and its supporting
references. Relevant information is repeated below, although ther
e
appears to be no section titled "Method of Measurement" in <xref
target="RFC7003"/>.</t>
<section title="Reference Method">
<t>Metrics in this block report on burst/gap discard in the str
eam
arriving at the RTP system. Measurements of these metrics are m
ade
at the receiving end of the RTP stream. Instances of this metri
cs
block use the synchronization source (SSRC) to refer to the sep
arate
auxiliary Measurement Information Block <xref target="RFC6776"/
>, which
describes measurement periods in use (see <xref target="RFC6776"/>
,
Section 4.2).</t>
<t>This metrics block relies on the measurement period in the
Measurement Information Block indicating the span of the report
.
Senders MUST send this block in the same compound RTCP packet a
s the
Measurement Information Block. Receivers MUST verify that the
measurement period is received in the same compound RTCP packet
as
this metrics block. If not, this metrics block MUST be
discarded.</t>
</section>
<section title="Stream Type and Stream Parameters">
<t>Since RTCP-XR Measurements are conducted on live RTP traffic
, the
complete description of the stream is contained in SDP messages
that
proceed the establishment of a compatible stream between two or
more
communicating hosts. See Run-time Parameters, below.</t>
</section>
<section title="Traffic Filter">
<t>NA</t>
</section>
<section title="Measurement Timing">
<t>NA</t>
</section>
<section title="Output Type and Data Format">
<t>The output type defines the type of result that the metric
produces.</t>
<t><list style="symbols">
<t>Value: Packets Discarded in Bursts</t>
<t>Data Format: 24 bits</t>
<t>Reference: Section 3.2 of <xref target="RFC7003"/></t>
</list></t>
</section>
<section title="Metric Units">
<t>The measured results are apparently expressed in packets,
although there is no section of <xref target="RFC7003"/> titled
"Metric Units".</t>
</section>
<section title="Run-time Parameters and Data Format">
<t>Run-Time Parameters are input factors that must be determine
d,
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 param
eters
are listed as an aid to the measurement system implementor or u
ser
(they must be left as variables, and supplied on execution).</t
>
<t>The Data Format of each Run-time Parameter SHALL be specifie
d in
this column, to simplify the control and implementation of
measurement devices.</t>
<t>SSRC of Source: 32 bits As defined in Section 4.1 of
[RFC3611].</t>
<t>SDP Parameters: As defined in <xref target="RFC4566"/></t>
<t>Session description v= (protocol version number, currently o
nly
0)</t>
<t>o= (originator and session identifier : username, id, versio
n
number, network address)</t>
<t>s= (session name : mandatory with at least one UTF-8-encoded
character)</t>
<t>i=* (session title or short information) u=* (URI of
description)</t>
<t>e=* (zero or more email address with optional name of
contacts)</t>
<t>p=* (zero or more phone number with optional name of
contacts)</t>
<t>c=* (connection information&mdash;not required if included i
n all
media)</t>
<t>b=* (zero or more bandwidth information lines) One or more T
ime
descriptions ("t=" and "r=" lines; see below)</t>
<t>z=* (time zone adjustments)</t>
<t>k=* (encryption key)</t>
<t>a=* (zero or more session attribute lines)</t>
<t>Zero or more Media descriptions (each one starting by an "m=
"
line; see below)</t>
<t>m= (media name and transport address)</t>
<t>i=* (media title or information field)</t>
<t>c=* (connection information &mdash; optional if included at
session level)</t>
<t>b=* (zero or more bandwidth information lines)</t>
<t>k=* (encryption key)</t>
<t>a=* (zero or more media attribute lines &mdash; overriding t
he
Session attribute lines)</t>
<t>An example Run-time SDP description follows:</t>
<t>v=0</t>
<t>o=jdoe 2890844526 2890842807 IN IP4 192.0.2.5</t>
<t>s=SDP Seminar i=A Seminar on the session description protoco
l</t>
<t>u=http://www.example.com/seminars/sdp.pdf e=j.doe@example.co
m
(Jane Doe)</t>
<t>c=IN IP4 233.252.0.12/127</t>
<t>t=2873397496 2873404696</t>
<t>a=recvonly</t>
<t>m=audio 49170 RTP/AVP 0</t>
<t>m=video 51372 RTP/AVP 99</t>
<t>a=rtpmap:99 h263-1998/90000</t>
</section>
</section>
<section title="Comments and Remarks">
<t>TBD.</t>
</section>
</section>
<section title="Example Generalized Passive Octet Count Entry">
<t>This section gives an example registry entry for a gen
eralized the passive metric
octetDeltaCount described in the IPFIX registry"/
>.</t>
<section title="Registry Indexes">
<t>This category includes multiple indexes to the
Registered Performance Metrics,
the element ID and metric name.</t>
<section title="Element Identifier">
<t>An integer having enough digits to uni
quely identify each entry
in the Registry.</t>
<t>TBD by IANA.</t>
</section>
<section title="Metric Name">
<t>A metric naming convention is TBD.</t>
<t>Pas_IP_Octet-Delta-General</t>
</section>
<section title="URI">
<t>urn:ietf:params:performance:metric-som
ething</t>
</section>
<section title="Status">
<t>Current</t>
</section>
<section title="Requester">
<t>TBD</t>
</section>
<section title="Revision">
<t>0</t>
</section>
<section title="Revision Date">
<t>TBD</t>
</section>
<section title="Metric Description">
<t>A delta count of the number of octets
observed.
</t>
</section>
<section title="Reference Specification(s)">
<t>octetDeltaCount described in the IPFIX
registry.</t>
</section>
</section>
<section title="Metric Definition">
<t>This category includes columns to prompt the e
ntry of all necessary
details related to the metric definition,
including the RFC reference
and values of input factors, called fixed
parameters.</t>
<section title="Reference Definition">
<t>octetDeltaCount described in the IPFIX
registry.</t>
</section>
<section title="Fixed Parameters">
<t> As this is the generalised version of
the IP delta count
metric, there are no fixed parame
ters.</t>
</section>
</section>
<section title="Method of Measurement">
<section title="Reference Implementation">
<t>For &lt;metric&gt;.</t>
<t>&lt;section reference&gt;</t>
<t/>
</section>
<section title="Stream Type and Stream Parameters
">
<t>NA</t>
</section>
<section title="Traffic Filter Criteria">
<t>
This measurement only covers IP p
ackets and the IP
payload (including the IP header)
of these packets.
Non-IP packets (BPDUs, ISIS) will
not be accounted.
Layer 2 overhead (Ethernet header
s, MPLS, QinQ, etc.) will
also not be represented in the me
asurement.
</t>
</section>
<section title="Measurement Timing">
<t>
This is a continous measurement o
f the IP octets
seen in the traffic selection sco
pe (run-time parameter).
</t>
<t>The measurement interval is a run time
parameter.
</t>
<t>There is no sampling.</t>
</section>
<section title="Output Type(s) and Data Format">
<t>It is possible that multiple observati
on intervals are reported
in a single report. In such a cas
e concatination of the interval reports
(deltaOctetCount, start-time, end
-time) is allowed. </t>
<t>The delta octet count metric reports a
observation
start time and end time. </t>
<t><list style="symbols">
<t>Value: observation-sta
rt-time and observation-end-time</t>
<t>Data Format: 64-bit NT
P Time-stamp Format</t>
<t>Reference: section 6 o
f
<xref target="RFC
5905"/></t>
</list></t>
</section>
<section title="Metric Units">
<t>The measured results are expressed in
octets with
a data format of unsigned64 as de
scribed in the IPFIX registry.</t>
</section>
<section title="Run-time Parameters and Data Form
at">
<t>Run-time Parameters are input factors
that must be determined,
configured into the measurement s
ystem, and reported with the
results for the context to be com
plete.</t>
<t><list style="symbols">
<t>samplingTimeInterval,
length of time a single report covers. unsigned32 microseconds <xref target="RFC
5477"/> </t>
<t>observationInterface,
ifindex of interface to monitor. -1 represents all interfaces. -2 representing W
AN facing and -3 represents LAN facing. unsigned32.</t>
<t>observation direction,
unsigned8 where 0 represents incoming traffic on interface, 1 outgoing and 2 re
presents both incoming and outgoing. </t>
</list></t>
</section>
</section>
<section title="Comments and Remarks">
<t>Additional (Informational) details for this en
try</t>
</section>
</section>
<section title="Example 5min Passive Egress IP Destination Octet
Count Entry on WAN Interface">
<t>tbd</t>
<t>This section is Informational.</t>
<t>This section gives an example registry entry for the p
assive accounting of byte counts and
destination address on outgoing WAN IP. The byte
count and IP address is based on octetDeltaCount
and destinationIPv4Address, as described in the I
PFIX registry.</t>
<section title="Registry Indexes">
<t>This category includes multiple indexes to the
Registered Performance Metrics,
the element ID and metric name.</t>
<section title="Element Identifier">
<t>An integer having enough digits to uni
quely identify each entry
in the Registry.</t>
<t>TBD by IANA.</t>
</section>
<section title="Metric Name">
<t>A metric naming convention is TBD.</t>
<t>Pas_IPDst-Octet-Delta-WAN-egress</t>
</section>
<section title="URI">
<t>urn:ietf:params:performance:Pas_IPDst-
Octet-Delta-WAN-egress</t>
</section>
<section title="Status">
<t>Current</t>
</section>
<section title="Requester">
<t>The IPPM working group</t>
</section>
<section title="Revision">
<t>0</t>
</section>
<section title="Revision Date">
<t>Today</t>
</section>
<section title="Metric Description">
<t>This example passive measurement regis
try entry measures per-destination IP bytes sent.
The byte count and IP address are based o
n octetDeltaCount and destinationIPv4Address, as
described in IPFIX Registry. This metric
can be used to understand outgoing
top destinations per agent, saturation of
link utilization towards a single destination and
other bandwidth utilization uses.</t>
</section>
<section title="Reference Specification(s)">
<t>octetDeltaCount described in IPFIX reg
istry</t>
</section>
<section title="Fixed Parameters">
<t>Measurement Interval = 300 sec</t>
<t>IPFIX Template = KEY:destinationIPv4Ad
dress,egressInterface=WAN Value:octetDeltaCount </t>
</section>
<section title="Traffic Filter">
<t>PSAMP: "ipVersion == 4 AND egressInter
face==WAN"</t>
</section>
<section title="Sampling Distribution">
<t>No sampling</t>
</section>
<section title="Run-time Parameters">
<t>None</t>
</section>
</section>
<section title="Example 5min Passive Egress Octet Count E
ntry on WAN Interface">
<t>tbd</t>
<t>This section is Informational.</t>
<t>This section gives an example registry entry for accou
nting of outgoing WAN IP
traffic the passive metric in terms of octetDelta
Count, as described in the IPFIX registry.</t>
<section title="Registry Indexes">
<t>This category includes multiple indexes to the
Registered Performance Metrics,
the element ID and metric name.</t>
<section title="Element Identifier">
<t>An integer having enough digits to uni
quely identify each entry
in the Registry.</t>
<t>TBD by IANA.</t>
</section>
<section title="Metric Name">
<t>A metric naming convention is TBD.</t>
<t>Pas_IP-Octet-Delta-WAN-egress</t>
</section>
<section title="URI">
<t>urn:ietf:params:performance:metric-som
ething</t>
</section>
<section title="Status">
<t>Current</t>
</section>
<section title="Requester">
<t>TBD</t>
</section>
<section title="Revision">
<t>0</t>
</section>
<section title="Revision Date">
<t>TBD</t>
</section>
<section title="Metric Description">
<t>A delta count of the number of octets
observed outgoing on WAN interface.
</t>
</section>
<section title="Reference Specification(s)">
<t>octetDeltaCount described in the IPFIX
registry</t>
</section>
</section>
<section title="Metric Definition">
<t>This category includes columns to prompt the e
ntry of all necessary
details related to the metric definition,
including the RFC reference
and values of input factors, called fixed
parameters.</t>
<section title="Reference Definition">
<t>octetDeltaCount described in the IPFIX
registry"/></t>
</section>
<section title="Fixed Parameters">
<t> As this is a specific version of Pas_
IP-Octet-Delta-General that
performs metering of all outgoing
WAN traffic.</t>
<t><list style="symbols">
<t>samplingTimeInterval=
300000000, length of time a single report covers. unsigned32 microseconds <xref
target="RFC5477"/> </t>
<t>observationInterface=
-2, ifindex of interface to monitor. -1 represents all interfaces. -2 representi
ngs WAN facing and -3 represnets LAN facing. unsigned32.</t>
<t>observation direction=
1, unsigned8 where 0 represents incoming traffic on interface, 1 outgoing and 2
represents both incoming and outgoing. </t>
</list></t>
</section>
</section>
<section title="Method of Measurement">
<section title="Reference Implementation">
<t>For &lt;metric&gt;.</t>
<t>&lt;section reference&gt;</t>
<t/>
</section>
<section title="Stream Type and Stream Parameters
">
<t>NA</t>
</section>
<section title="Traffic Filter Criteria">
<t>
This measurement only covers IP p
ackets observed in the
WAN outgoing direction. The bytes
counted are the IP
payload (including the IP header)
of these packets.
Non-IP packets (BPDUs, ISIS) will
not be accounted.
Layer 2 overhead (Ethernet header
s, MPLS, QinQ, etc.) will
also not be represented in the me
asurement.
</t>
</section>
<section title="Measurement Timing">
<t>
This is a continous measurement o
f the IP octets
seen in the traffic selection sco
pe (run-time parameter),
each of a 5 minute duration.
</t>
<t>There is no sampling.</t>
</section>
<section title="Output Type(s) and Data Format">
<t>It is possible that multiple observati
on intervals are reported
in a single report. In such a cas
e concatination of the interval reports
(deltaOctetCount, start-time, end
-time) is allowed. </t>
<t>The delta octet count metric reports a
observation
start time and end time. </t>
<t><list style="symbols">
<t>Value: observation-sta
rt-time and observation-end-time</t>
<t>Data Format: 64-bit NT
P Time-stamp Format</t>
<t>Reference: section 6 o
f
<xref target="RFC
5905"/></t>
</list></t>
</section>
<section title="Metric Units">
<t>The measured results are expressed in
octets with
a data format of unsigned64 as de
scribed in the IPFIX registry</t>
</section>
<section title="Run-time Parameters and Data Form
at">
<t>There are no run-time parameters for t
his registry entry.</t>
</section>
</section>
<section title="Comments and Remarks">
<t>Additional (Informational) details for this en
try</t>
</section>
</section>
<section title="Example Passive RTP Lost Packet Count">
<t>tbd</t>
</section>
<section title="Example BLANK Registry Entry">
<t>This section is Informational. (?)</t>
<t>This section gives an example registry entry for the &lt;type of
metric and specification reference&gt; .</t>
<section title="Registry Indexes">
<t>This category includes multiple indexes to the Registered Perf
ormance Metrics,
the element ID and metric name.</t>
<section title="Identifier">
<t>An integer.</t>
</section>
<section title="Name">
<t>A metric naming convention is TBD.</t>
</section>
<section title="URI">
<t>Prefix urn:ietf:params:performance:metric</t>
</section>
<section title="Status">
<t>current</t>
</section>
<section title="Requestor">
<t>name or RFC, etc.</t>
</section>
<section title="Revision">
<t>1.0</t>
</section>
<section title="Revision Date">
<t>YYYY-MM-DD</t>
</section>
<section title="Description">
<t>TBD.</t>
</section>
<section title="Reference Specification(s)">
<t>RFC...</t>
</section>
</section>
<section title="Metric Definition">
<t>This category includes columns to prompt the entry of all nece
ssary
details related to the metric definition, including the RFC refer
ence
and values of input factors, called fixed parameters.</t>
<t>&lt;possible section reference&gt;.</t>
<section title="Reference Definition">
<t/>
<t/>
</section>
<section title="Fixed Parameters">
<t>Fixed Parameters are input factors that must be determined a
nd
embedded in the measurement system for use when needed. The val
ues
of these parameters is specified in the Registry.</t>
<t>&lt;list fixed parameters&gt;</t>
</section>
</section>
<section title="Method of Measurement">
<t>This category includes columns for references to relevant sect
ions
of the RFC(s) and any supplemental information needed to ensure a
n
unambiguous methods for implementations.</t>
<section title="Reference Method">
<t>For &lt;metric&gt;.</t>
<t>&lt;section reference&gt;</t>
<t/>
</section>
<section title="Stream Type and Stream Parameters">
<t>&lt;list of stream parameters&gt;.</t>
<t>&lt;references&gt;</t>
<t/>
</section>
<section title="Traffic Filter Criteria">
<t>
&lt;list filter criteria limitations and
allowances &gt;
</t>
</section>
<section title="Measurement Timing">
<t>
&lt; list timing requirements and limitat
ions &gt;
</t>
</section>
<section title="Output Type and Data Format">
<t>The output type defines the type of result that the metric
produces.</t>
<t><list style="symbols">
<t>Value:</t>
<t>Data Format: (There may be some precedent to follow here
, but
otherwise use 64-bit NTP Timestamp Format, see section 6 of
<xref target="RFC5905"/>).</t>
<t>Reference: &lt;section reference&gt;</t>
</list></t>
</section>
<section title="Metric Units">
<t>The measured results are expressed in &lt;units&gt;,</t>
<t>&lt;section reference&gt;.</t>
</section>
<section title="Run-time Parameters and Data Format">
<t>Run-time Parameters are input factors that must be determine
d,
configured into the measurement system, and reported with the
results for the context to be complete.</t>
<t>&lt;list of run-time parameters&gt;</t>
<t>&lt;reference(s)&gt;.</t>
</section>
</section>
<section title="Comments and Remarks">
<t>Additional (Informational) details for this entry</t>
</section>
</section>
</section>
</middle> </middle>
<back> <back>
<references title="Normative References"> <references>
<?rfc include="reference.RFC.2026"?> <name>References</name>
<references>
<?rfc include="reference.RFC.2119"?> <name>Normative References</name>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.2026.
<?rfc ?> xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.2119.
<?rfc include='reference.RFC.2330'?> xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.2330.
<?rfc include='reference.RFC.3986'?> xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.3986.
<?rfc ?> xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8126.
<?rfc include="reference.RFC.8126"?> xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.6390.
<?rfc ?> xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.6576.
<?rfc include="reference.RFC.6390"?> xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.7799.
<?rfc include='reference.RFC.6576'?> xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8174.
<?rfc include='reference.RFC.7799'?> xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.5644.
<?rfc include='reference.RFC.8174'?> xml"/>
</references> </references>
<references>
<references title="Informative References"> <name>Informative References</name>
<?rfc ?> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.7679.
xml"/>
<?rfc include='reference.RFC.7679'?> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.2681.
xml"/>
<?rfc include="reference.RFC.2681"?> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.3432.
xml"/>
<?rfc ?> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.3550.
xml"/>
<?rfc include="reference.RFC.3432"?> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.3611.
xml"/>
<?rfc include="reference.RFC.3550"?> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.4148.
xml"/>
<?rfc include="reference.RFC.3611"?> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.5474.
xml"/>
<?rfc include="reference.RFC.4148"?> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.5475.
xml"/>
<?rfc include="reference.RFC.5474"?> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.5477.
xml"/>
<?rfc include="reference.RFC.5475"?> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.6035.
xml"/>
<?rfc include="reference.RFC.5477"?> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.6248.
xml"/>
<?rfc ?> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.7012.
xml"/>
<?rfc ?> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.7014.
xml"/>
<?rfc include="reference.RFC.6035"?> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.7594.
xml"/>
<?rfc include="reference.RFC.6248"?>
<?rfc ?>
<?rfc ?>
<?rfc include="reference.RFC.7012"?>
<?rfc include="reference.RFC.7014"?>
<?rfc include='reference.RFC.7594'?>
<?rfc include='reference.RFC.8194'?>
<?rfc ?>
<?rfc include='reference.I-D.ietf-ippm-initial-registry'?> <!-- draft-ietf-ippm-initial-registry (RFC 8912) -->
<reference anchor="RFC8912" target="https://www.rfc-editor.org/info/rfc8
912">
<front>
<title>Initial Performance Metrics Registry Entries</title>
<author initials="A" surname="Morton" fullname="Alfred Morton">
<organization/>
</author>
<author initials="M" surname="Bagnulo" fullname="Marcelo Bagnulo">
<organization/>
</author>
<author initials="P" surname="Eardley" fullname="Philip Eardley">
<organization/>
</author>
<author initials="K" surname="D'Souza" fullname="Kevin D'Souza">
<organization/>
</author>
<date month="November" year="2021"/>
</front>
<seriesInfo name="RFC" value="8912"/>
<seriesInfo name="DOI" value="10.17487/RFC8912"/>
</reference>
<?rfc include='reference.RFC.6991'?> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.6991.
xml"/>
</references>
</references> </references>
<section numbered="false" toc="default">
<name>Acknowledgments</name>
<t>Thanks to <contact fullname="Brian Trammell"/> and <contact
fullname="Bill Cerveny"/>, IPPM co-chairs during the development of this
memo, for leading several brainstorming sessions on this topic. Thanks
to <contact fullname="Barbara Stark"/> and <contact fullname="Juergen
Schoenwaelder"/> for the detailed feedback and suggestions. Thanks to
<contact fullname="Andrew McGregor"/> for suggestions on metric
naming. Thanks to <contact fullname="Michelle Cotton"/> for her early
IANA review, and to <contact fullname="Amanda Baber"/> for answering
questions related to the presentation of the Registry and accessibility
of the complete template via URL. Thanks to <contact fullname="Roni
Even"/> for his review and suggestions to generalize the
procedures. Thanks to all of the Area Directors for their reviews.</t>
</section>
</back> </back>
</rfc> </rfc>
 End of changes. 311 change blocks. 
2465 lines changed or deleted 1469 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/