rfc9951xml2.original.xml   rfc9951.xml 
<?xml version="1.0" encoding="UTF-8"?> <?xml version='1.0' encoding='utf-8'?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd">
<?rfc toc="yes"?> <!DOCTYPE rfc [
<?rfc tocompact="yes"?> <!ENTITY nbsp "&#160;">
<?rfc tocdepth="3"?> <!ENTITY zwsp "&#8203;">
<?rfc tocindent="yes"?> <!ENTITY nbhy "&#8209;">
<?rfc symrefs="yes"?> <!ENTITY wj "&#8288;">
<?rfc sortrefs="yes"?> ]>
<?rfc comments="yes"?>
<?rfc inline="yes"?> <rfc xmlns:xi="http://www.w3.org/2001/XInclude" category="std" docName="draft-ie
<?rfc compact="yes"?> tf-opsawg-ipfix-on-path-telemetry-23" number="9951" ipr="trust200902" consensus=
<?rfc subcompact="no"?> "true" obsoletes="" updates="" submissionType="IETF" xml:lang="en" tocInclude="t
<rfc category="std" rue" tocDepth="3" symRefs="true" sortRefs="true" version="3">
docName="draft-ietf-opsawg-ipfix-on-path-telemetry-23"
ipr="trust200902" consensus="true">
<front> <front>
<title abbrev="Delay Performance Metrics for IPFIX">Export of Delay <title abbrev="Delay Performance Metrics for IPFIX">Export of Delay
Performance Metrics in IP Flow Information eXport (IPFIX)</title> Performance Metrics in IP Flow Information Export (IPFIX)</title>
<seriesInfo name="RFC" value="9951"/>
<author fullname="Thomas Graf" initials="T" surname="Graf"> <author fullname="Thomas Graf" initials="T" surname="Graf">
<organization>Swisscom</organization> <organization>Swisscom</organization>
<address> <address>
<postal> <postal>
<street>Binzring 17</street> <street>Binzring 17</street>
<city>Zurich</city> <city>Zurich</city>
<code>8045</code> <code>8045</code>
<country>Switzerland</country> <country>Switzerland</country>
</postal> </postal>
<email>thomas.graf@swisscom.com</email> <email>thomas.graf@swisscom.com</email>
</address> </address>
</author> </author>
<author fullname="Benoit Claise" initials="B" surname="Claise"> <author fullname="Benoit Claise" initials="B" surname="Claise">
<organization>Huawei</organization> <organization>Huawei</organization>
<address> <address>
<email>benoit@everything-ops.net</email> <email>benoit@everything-ops.net</email>
</address> </address>
</author> </author>
<author fullname="Alex Huang-Feng" initials="A" surname="Huang-Feng">
<author fullname="Alex Huang-Feng" initials="A"
surname="Huang-Feng">
<organization>INSA-Lyon</organization> <organization>INSA-Lyon</organization>
<address> <address>
<postal> <postal>
<street/>
<city>Lyon</city> <city>Lyon</city>
<region/>
<code/>
<country>France</country> <country>France</country>
</postal> </postal>
<phone/>
<facsimile/>
<email>alex.huang-feng@insa-lyon.fr</email> <email>alex.huang-feng@insa-lyon.fr</email>
<uri/>
</address> </address>
</author> </author>
<date month="March" year="2026"/>
<area>OPS</area>
<workgroup>opsawg</workgroup>
<date day="01" month="October" year="2025"/> <!-- [rfced] Please insert any keywords (beyond those that appear in
the title) for use on https://www.rfc-editor.org/search. -->
<keyword>example</keyword>
<abstract> <abstract>
<t>This document specifies new IP Flow Information Export (IPFIX) <t>This document specifies new IP Flow Information Export (IPFIX)
Information Elements to export the On-Path delay at each OAM Information Elements to export the On-Path delay at each Operations,
transit and decapsulating nodes. The On-Path delay is def Administration, and Maintenance (OAM) transit and decapsulating
ined as nodes. The On-Path delay is defined as the delay between the OAM header
the delay between the OAM header encapsulating node and e encapsulating node and each OAM header transit and OAM header
ach decapsulating nodes. This delay measurement is computed by an On-Path
OAM header transit and OAM header decapsulating nodes. Th Telemetry protocol and is exported by the IPFIX process.
is delay </t>
measurement is computed by an On-Path Telemetry protocol
and is
exported by the IPFIX process.
</t>
</abstract> </abstract>
</front> </front>
<middle> <middle>
<section anchor="Introduction" title="Introduction"> <section anchor="Introduction" numbered="true" toc="default">
<name>Introduction</name>
<t>Network operators usually maintain statistical views of delay <t>Network operators usually maintain statistical views of delay
accross their networks to support diagnostics and perform ance across their networks to support diagnostics and performa nce
analysis. These views assist in identifying the location, extent, analysis. These views assist in identifying the location, extent,
and potential causes of abnormal delay affecting specific customer and potential causes of abnormal delay affecting specific customer
traffic or services. To achieve this, delay-related metri cs need traffic or services. To achieve this, delay-related metri cs need
to be reported from devices covering both data and contro l planes. to be reported from devices covering both data and contro l planes.
Further, in order to understand which customers are affec ted, Further, in order to understand which customers are affec ted,
delay-related metrics need to be reported in the context of the delay-related metrics need to be reported in the context of the
customer data-plane. This correlation enables the detecti on of customer data plane. This correlation enables the detecti on of
changes in forwarding paths, such as updated intermediate hops or changes in forwarding paths, such as updated intermediate hops or
interfaces, and the resulting impact on delay experienced by interfaces, and the resulting impact on delay experienced by
customer traffic.</t> customer traffic.</t>
<!--[rfced] Please clarify this sentence. Is the intended meaning
(i) "This correlation enables the detection of changes and of the impact."
or
(ii) "This correlation enables the detection and the impact."?
Original:
This correlation enables the detection of changes in
forwarding paths, such as updated intermediate hops or interfaces,
and the resulting impact on delay experienced by customer traffic.
Perhaps (assuming (i), adding a second "of"):
This correlation enables the detection of changes in
forwarding paths, such as updated intermediate hops or interfaces,
and of the resulting impact on delay experienced by customer traffic.
Or (assuming (i), for more precision):
This correlation enables the detection of (a) changes in
forwarding paths, such as updated intermediate hops or interfaces,
and (b) the resulting impact on delay experienced by customer traffic.
-->
<t>Delay measurements in the network are computed using an On-Path <t>Delay measurements in the network are computed using an On-Path
Telemetry protocol, which inserts metadata into the data-plane Telemetry protocol, which inserts metadata into the data-plane
packet when entering the monitored domain <xref packet when entering the monitored domain <xref target="RFC9232" format="d
target="RFC9232"/>. To compute delay measurements, the On-Path efault"/>. To compute delay measurements, the On-Path
Telemetry protocol inserts a timestamp reference when entering the Telemetry protocol inserts a timestamp reference when entering the
OAM encapsulating node. Implementations examples are In Situ OAM encapsulating node. Implementation examples are In situ
Operations, Administration, and Maintenance (IOAM) <xref Operations, Administration, and Maintenance (IOAM) <xref
target="RFC9197"/> or Enhanced Alternate Marking target="RFC9197" format="default"/> or Enhanced Alternate Marking
<xref target="I-D.zhou-ippm-enhanced-alternate-marking"/>.</t> <xref target="I-D.zhou-ippm-enhanced-alternate-marking" format="default"/>
.</t>
<t>Two modes of On-Path Telemetry are generally recognized: <t>Two modes of On-Path Telemetry are generally recognized:
passport mode, in which only the OAM header decapsulating node of the OAM passport mode, in which only the OAM header decapsulating node of the OAM
domain reports metrics; and postcard mode, in which OAM h eader domain reports metrics; and postcard mode, in which OAM h eader
transit nodes also export On-Path Telemetry data. Both mo des transit nodes also export On-Path Telemetry data. Both mo des
enable exposure of per-hop performance metrics, including delay enable exposure of per-hop performance metrics, including delay
accumulation. The approach defined in this document is pr imarily accumulation. The approach defined in this document is pr imarily
applicable to postcard mode. applicable to postcard mode.
</t> </t>
<t>To enable the export of the delay-related metrics via IPFIX <t>To enable the export of the delay-related metrics via IPFIX
<xref target="RFC7011"/>, this document defines four new IPFIX <xref target="RFC7011" format="default"/>, this document defines four new IPFIX
Information Elements (IEs), exposing the On-Path delay on OAM Information Elements (IEs), exposing the On-Path delay on OAM
header transit and decapsulating nodes, following the pos header transit and decapsulating nodes, following the pri
tcard nciples of postcard
mode principles.</t> mode.</t>
<t>This enables the computation of delay metrics (minimum, <t>This enables the computation of delay metrics (minimum,
maximum, and mean) directly on the OAM header transit and maximum, and mean) directly on the OAM header transit and
decapsulating node, allowing aggregation within the Flow Record. decapsulating node, allowing aggregation within the Flow Record.
</t> </t>
<t>As these IEs represent performance metrics, they are also
<t>As these IEs represent performance metrics, they are a registered in the <xref target="IANA-PERF-METRIC" format=
lso "default">
registered in the <xref target="IANA-PERF-METRIC"> IANA "Performance Metrics Registry"</xref> in accordance with
IANA "Performance Metrics" registry</xref> in accordance with <xref target="RFC8911" format="default"/>.</t>
<xref target="RFC8911"/>.</t>
</section> </section>
<section anchor="notation" numbered="true" toc="default">
<section anchor="notation" title="Terminology"> <name>Terminology</name>
<t>The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL <t>
NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMME The key words "<bcp14>MUST</bcp14>", "<bcp14>MUST NOT</bcp14>", "<bcp14>REQU
NDED", IRED</bcp14>", "<bcp14>SHALL</bcp14>", "<bcp14>SHALL
"MAY", and "OPTIONAL" in this document are to be interpre NOT</bcp14>", "<bcp14>SHOULD</bcp14>", "<bcp14>SHOULD NOT</bcp14>", "<bcp14>
ted as RECOMMENDED</bcp14>", "<bcp14>NOT RECOMMENDED</bcp14>",
described in BCP 14 <xref target="RFC2119"/> <xref "<bcp14>MAY</bcp14>", and "<bcp14>OPTIONAL</bcp14>" in this document are to
target="RFC8174"/> when, and only when, they appear in al be interpreted as
l described in BCP&nbsp;14 <xref target="RFC2119"/> <xref target="RFC8174"/>
capitals, as shown here.</t> when, and only when, they appear in all capitals, as shown here.
</t>
<t>This document defines the following terms:</t> <t>This document defines the following terms:</t>
<dl spacing="normal" newline="true">
<t><list style="symbols"> <dt>OAM Header Encapsulating Node:</dt><dd>Receives the IP packets,
<t>OAM Header Encapsulating Node: Receives the IP packets, encapsulates the packets with an OAM header, and adds the timestamp
encapsulates the packets with an OAM head into the OAM header.</dd>
er and adds the <dt>OAM Header Transit Node:</dt><dd>Receives the IP packets, then measu
timestamp into the OAM header.</t> res
the delay between the timestamp in the packet and the timestamp when
<t>OAM Header Transit Node: Receives the IP packets, measures the the packet was received.</dd>
delay between the timestamp in the packet and the timestamp <dt>OAM Header Decapsulating Node:</dt><dd>Receives the IP packets,
when the packet was received.</t> computes the delay between the timestamp in the packet and the
timestamp when the packet was received, and removes the OAM header from
<t>OAM Header Decapsulating Node: Receives the IP packets, the packet.</dd>
computes the delay between the timestamp in the packet and the </dl>
timestamp when the packet was received and removes the OAM
header from the packet.</t>
</list></t>
<t>This document makes use of the terms defined in <xref <t>This document makes use of the terms defined in <xref
target="RFC7011"/>, <xref target="RFC8911"/> and target="RFC7011" format="default"/>, <xref target="RFC8911"
<xref target="RFC7799"/>.</t> format="default"/> and <xref target="RFC7799" format="default"/>.</t>
<t>The following terms are used as defined in <xref target="RFC7011" forma
<t>The following terms are used as defined in <xref t="default"/>:</t>
target="RFC7011"/>:</t> <ul spacing="normal">
<li>
<t><list style="symbols">
<t>Collector</t> <t>Collector</t>
</li>
<li>
<t>Exporter</t> <t>Exporter</t>
</li>
<li>
<t>Flow</t> <t>Flow</t>
</li>
<li>
<t>Flow Record</t> <t>Flow Record</t>
</li>
<li>
<t>IPFIX</t> <t>IPFIX</t>
</li>
<li>
<t>IPFIX Information Elements (IEs)</t> <t>IPFIX Information Elements (IEs)</t>
</li>
<li>
<t>Observation Point</t> <t>Observation Point</t>
</list></t> </li>
</ul>
<t>The following terms are used as defined in <xref <t>The following terms are used as defined in <xref target="RFC8911" forma
target="RFC8911"/>:</t> t="default"/>:</t>
<ul spacing="normal">
<t><list style="symbols"> <li>
<t>Performance Metric</t> <t>Performance Metric</t>
</li>
<li>
<t>Performance Metrics Registry</t> <t>Performance Metrics Registry</t>
</li>
<li>
<t>Registered Performance Metric</t> <t>Registered Performance Metric</t>
</list></t> </li>
</ul>
<t>The following term is used as defined in <xref section="3.8" <t>The following term is used as defined in <xref section="3.8" sectionFor
sectionFormat="of" target="RFC7799"/>:</t> mat="of" target="RFC7799" format="default"/>:</t>
<ul spacing="normal">
<t><list style="symbols"> <li>
<t>Hybrid Type I</t> <t>Hybrid Type I</t>
</list></t> </li>
</ul>
</section> </section>
<section anchor="Solution" numbered="true" toc="default">
<section anchor="Solution" title="Solution"> <name>Solution</name>
<t>In line with the guidelines for Registered Performance Metric <t>In line with the guidelines for Registered Performance Metric
Requesters and Reviewers <xref target="RFC8911"/>, each metric requesters and reviewers <xref target="RFC8911" format="default"/>, each m etric
is specified with its required characteristics (e.g., Identifier, is specified with its required characteristics (e.g., Identifier,
Name, URI, Status, Requester, Revision, Description) to e nsure Name, URI, Status, Requester, Revision, Description) to e nsure
comparability of measurement results across implementatio ns and comparability of measurement results across implementatio ns and
environments. These characteristics are registered in the <xref environments. These characteristics are registered in the <xref target="IA
target="IANA-PERF-METRIC">IANA "Performance Metrics" NA-PERF-METRIC" format="default">IANA "Performance Metrics
registry</xref>. Metric naming follows the Registry"</xref>. Metric naming follows the
"MetricType_Method_SubTypeMethod_... Spec_Units_Output" c onvention "MetricType_Method_SubTypeMethod_... Spec_Units_Output" c onvention
defined in <xref section="7.1.2" sectionFormat="of" defined in <xref section="7.1.2" sectionFormat="of" targe
target="RFC8911"/>.</t> t="RFC8911" format="default"/>.</t>
<t>This document defines the following performance metrics and <t>This document defines the following performance metrics and
IPFIX Information Elements:</t> IPFIX Information Elements:</t>
<figure> <table anchor="tab-1">
<artwork><![CDATA[ <name>Mapping Between IPFIX IEs and Performance Metrics</name>
+------------------------------------+-------------------------------+ <thead>
| Performance Metric | IPFIX Information Element | <tr>
+------------------------------------+-------------------------------+ <th>Performance Metric</th>
|OWDelay_HybridType1_I |pathDelayMeanDeltaMicroseconds | <th>IPFIX Information Element</th>
|P_RFC[RFC-to-be]_Seconds_Mean (TBD1)|(TBD5) | </tr>
+------------------------------------+-------------------------------+ </thead>
|OWDelay_HybridType1_I |pathDelayMinDeltaMicroseconds | <tbody>
|P_RFC[RFC-to-be]_Seconds_Min (TBD2) |(TBD6) | <tr>
+------------------------------------+-------------------------------+ <td>OWDelay_HybridType1_I P_RFC9951_Seconds_Mean (27)</td>
|OWDelay_HybridType1_I |pathDelayMaxDeltaMicroseconds | <td>pathDelayMeanDeltaMicroseconds (530)</td>
|P_RFC[RFC-to-be]_Seconds_Max (TBD3) |(TBD7) | </tr>
+------------------------------------+-------------------------------+ <tr>
|OWDelay_HybridType1_I |pathDelaySumDeltaMicroseconds | <td>OWDelay_HybridType1_I P_RFC9951_Seconds_Min (28)</td>
|P_RFC[RFC-to-be]_Seconds_Sum (TBD4) |(TBD8) | <td>pathDelayMinDeltaMicroseconds (531)</td>
+------------------------------------+-------------------------------+ </tr>
<tr>
Table 1: Mapping Between IPFIX IEs and Performance Metrics <td>OWDelay_HybridType1_I P_RFC9951_Seconds_Max (29)</td>
]]></artwork> <td>pathDelayMaxDeltaMicroseconds (532)</td>
</figure> </tr>
<tr>
<td>OWDelay_HybridType1_I P_RFC9951_Seconds_Sum (30)</td>
<td>pathDelaySumDeltaMicroseconds (533)</td>
</tr>
</tbody>
</table>
<t>Assuming time synchronization on devices, the delay is measured <t>Assuming time synchronization on devices, the delay is measured
by calculating the difference between the timestamp impos ed with by calculating the difference between the timestamp impos ed with
On-Path Telemetry in the packet at an OAM header encapsul ating On-Path Telemetry in the packet at an OAM header encapsul ating
node and the timestamp exported in the IPFIX flow record from the node and the timestamp exported in the IPFIX flow record from the
OAM header transit and OAM header decapsulating nodes. Th e lowest, OAM header transit and OAM header decapsulating nodes. Th e lowest,
highest, mean, and the sum of measured path delay can be exported, highest, mean, and the sum of measured path delay can be exported,
thanks to the different IPFIX IE specifications.</t> thanks to the different IPFIX IE specifications.</t>
<figure anchor="topology">
<figure anchor="topology" <name>Delay Use Case: Packets Flow from Host 1 to Host 2</name>
title="Delay use case. Packets flow from host 1 to host 2."> <artwork align="center" name="" type="" alt=""><![CDATA[
<artwork align="center"><![CDATA[
On-Path Telemetry Domain On-Path Telemetry Domain
......................................... .........................................
. . . .
. D1 . . D1 .
. x-------> . . x-------> .
. . . .
. D2 . . D2 .
. x--------------------> . . x--------------------> .
. . . .
. D3 . . D3 .
. x----------------------------------> . . x----------------------------------> .
. . . .
(H1) -----> (R0) ------> (R1) ------> (R2) -------> (R3) -----> (H2) (H1) -----> (R0) ------> (R1) ------> (R2) -------> (R3) -----> (H2)
Host 1 Encapsulating Transit Transit Decapsulating Host 2 Host 1 Encapsulating Transit Transit Decapsulating Host 2
Node Node 1 Node 2 Node Node Node 1 Node 2 Node
. . . .
. . . .
......................................... .........................................]]></artwork>
]]></artwork>
</figure> </figure>
<t>In the use case shown in <xref target="topology" format="default"/>, us
<t>In the use case shown in <xref target="topology"/> using ing
On-path Telemetry to export the delay metrics, the node R On-Path Telemetry to export the delay metrics, the node R
1 exports 1 exports
the delay D1, the node R2 exports the delay D2 and the OA the delay D1, the node R2 exports the delay D2, and the O
M header AM header
decapsulating node R3 exports the total delay D3 for the same flow decapsulating node R3 exports the total delay D3 for the same flow
using IPFIX.</t> using IPFIX.</t>
<t>This solution enables the computation of delay metrics (minimum, <t>This solution enables the computation of delay metrics (minimum,
maximum, and mean) directly on the OAM header transit and maximum, and mean) directly on the OAM header transit and
decapsulating node, allowing aggregation within the Flow Record. decapsulating node, allowing aggregation within the Flow Record.
This reduces both export bandwidth and processing require ments on This reduces both export bandwidth and processing require ments on
the Collector. To compute these metrics locally, the Expo rter's the Collector. To compute these metrics locally, the Expo rter's
Metering Process must perform per-packet caching and proc essing, Metering Process must perform per-packet caching and proc essing,
particularly when computing mean delay under Flow Aggrega tion particularly when computing mean delay under Flow Aggrega tion
<xref target="RFC7015"/>. A less computationally intensiv e <xref target="RFC7015" format="default"/>. A less computa tionally intensive
alternative is to export the sum of delays, allowing the Collector alternative is to export the sum of delays, allowing the Collector
to compute the mean via a simple division using the packe t count. to compute the mean via a simple division using the packe t count.
</t> </t>
<t>In contrast, if no delay processing occurs on the OAM header <t>In contrast, if no delay processing occurs on the OAM header
transit or decapsulating node, each packet must be export ed as an transit or decapsulating node, each packet must be export ed as an
individual Flow Record, including timestamp information, as individual Flow Record, including timestamp information, as
specified in <xref target="I-D.ietf-opsawg-ipfix-alt-mark "/>. The specified in <xref target="I-D.ietf-opsawg-ipfix-alt-mark " format="default"/>. The
Collector must then compute the delay metrics and reconst ruct the Collector must then compute the delay metrics and reconst ruct the
aggregated Flow Record accordingly.</t> aggregated Flow Record accordingly.</t>
</section> </section>
<section anchor="PM" numbered="true" toc="default">
<section anchor="PM" title="Performance Metrics"> <name>Performance Metrics</name>
<t>This section defines four new performance metrics following <t>This section defines four new performance metrics following
the template defined in <xref section="11" sectionFormat= the template defined in <xref section="11" sectionFormat=
"of" "of" target="RFC8911" format="default"/>.</t>
target="RFC8911"/>.</t>
<t>IANA Note (to be removed): RFC 8192 Section 4 was taken a
guiding example.</t>
<section anchor="ip-ow-delay-hybridtype1-reg-entries" <section anchor="ip-ow-delay-hybridtype1-reg-entries" numbered="true" toc=
title="IP One-Way Delay Hybrid Type I Performance Metrics"> "default">
<name>IP One-Way Delay Hybrid Type I Performance Metrics</name>
<t>This section specifies four performance metrics for the <t>This section specifies four performance metrics for the
Hybrid Type I assessment of IP One-Way Delay, to Hybrid Type I assessment of IP One-Way Delay; the
be y have been
registered in the <xref target="IANA-PERF-METRIC" registered in the <xref target="IANA-PERF-METRIC"
>IANA format="default">IANA
"Performance Metrics" registry</xref>.</t> "Performance Metrics Registry"</xref>.</t>
<t>All column entries besides the Identifier, Name, URI, <t>All column entries besides the Identifier, Name, URI,
Description, Reference Description (Output only) categories are Description, Reference Description (Output only) categories are
the same; thus, this section defines four closely related the same; thus, this section defines four closely related
performance metrics. As a result, IANA has assign ed performance metrics. As a result, IANA has assign ed
corresponding URIs to each of the four registered performance corresponding URIs to each of the four registered performance
metrics.</t> metrics.</t>
<section numbered="true" toc="default">
<name>Summary</name>
<!--[rfced] Should "element Identifier" be "Information Element identifier"?
The latter term is used in RFC 7011 (which you had mentioned in the intake form)
.
<section numbered="true" title="Summary"> Original:
This category includes multiple indexes of the registered performance
metrics: the element Identifier and Metric Name.
-->
<t>This category includes multiple indexes of the registered <t>This category includes multiple indexes of the registered
performance metrics: the element Identifier and Metric Name. performance metrics: the element Identifier and Metric Name.
</t> </t>
<section numbered="true" toc="default">
<section title="ID (Identifier)"> <name>ID (Identifier)</name>
<t>IANA has allocated the numeric Identifiers TBD1, TBD2, <t>IANA has allocated the numeric Identifiers 27, 28,
TBD3, and TBD4 for the four Named 29, and 30 for the four Named Met
Metric Entries in the ric Entries in the
following section.</t> following section.</t>
<t>RFC EDITOR NOTE: please replace TBD1, TBD2, TBD3, and
TBD4 with allocated IPFIX entity
numbers.</t>
</section> </section>
<section numbered="true" toc="default">
<name>Name</name>
<section title="Name"> <dl newline="false">
<t>TBD1: <dt>27:</dt>
OWDelay_HybridType1_IP_RFC[RFC-to-be]_Seconds_Mean</t> <dd>OWDelay_HybridType1_IP_RFC9951_Seconds_Mean</dd>
<dt>28:</dt>
<t>TBD2: <dd>OWDelay_HybridType1_IP_RFC9951_Seconds_Min</dd>
OWDelay_HybridType1_IP_RFC[RFC-to-be]_Seconds_Min</t> <dt>29:</dt>
<dd>OWDelay_HybridType1_IP_RFC9951_Seconds_Max</dd>
<t>TBD3: <dt>30:</dt>
OWDelay_HybridType1_IP_RFC[RFC-to-be]_Seconds_Max</t> <dd>OWDelay_HybridType1_IP_RFC9951_Seconds_Sum</dd>
</dl>
<t>TBD4:
OWDelay_HybridType1_IP_RFC[RFC-to-be]_Seconds_Sum</t>
<t>RFC EDITOR NOTE: please replace [RFC-to-be] with the
allocated RFC document number.</t
>
</section> </section>
<section numbered="true" toc="default">
<name>URI</name>
<section title="URI"> <dl newline="true">
<t>URI: <eref <dt>URI:</dt>
target="https://www.iana.org/assignments/performance-metrics/OWDelay <dd><eref target="https://www.iana.org/assignments/performance-metr
_HybridType1_IP_RFC[RFC-to-be]_Seconds_Mean"/></t> ics/OWDelay_HybridType1_IP_RFC9951_Seconds_Mean" brackets="angle"/></dd>
<dt>URI:</dt>
<t>URI: <eref <dd><eref target="https://www.iana.org/assignments/performance-metric
target="https://www.iana.org/assignments/performance-metrics/OWDelay s/OWDelay_HybridType1_IP_RFC9951_Seconds_Min" brackets="angle"/></dd>
_HybridType1_IP_RFC[RFC-to-be]_Seconds_Min"/></t> <dt>URI:</dt>
<dd><eref target="https://www.iana.org/assignments/performance-metric
<t>URI: <eref s/OWDelay_HybridType1_IP_RFC9951_Seconds_Max" brackets="angle"/></dd>
target="https://www.iana.org/assignments/performance-metrics/OWDelay <dt>URI:</dt>
_HybridType1_IP_RFC[RFC-to-be]_Seconds_Max"/></t> <dd><eref target="https://www.iana.org/assignments/performance-metric
s/OWDelay_HybridType1_IP_RFC9951_Seconds_Sum" brackets="angle"/></dd>
<t>URI: <eref </dl>
target="https://www.iana.org/assignments/performance-metrics/OWDelay
_HybridType1_IP_RFC[RFC-to-be]_Seconds_Sum"/></t>
<t>RFC EDITOR NOTE: please replace [RFC-to-be] with the
allocated RFC document number.</t
>
</section> </section>
</section> </section>
<section numbered="true" toc="default">
<name>Description</name>
<!--[rfced] FYI, we added "is" to make the 2nd sentence complete in each
definition below. Please let us know if a different meaning was intended.
For example:
<section title="Description"> Original:
<t><list style="symbols"> The measurement of one-way delay based on a single Observation Point
<t>OWDelay_HybridType1_IP_RFC[RFC-to-be]_Seconds_Mean: [RFC7011] somewhere in the network.
This metric assesses the mean of one-way delays of all
successfully forwarded IP packets constituting a single Flow.
The measurement of one-way delay based on
a single
Observation Point [RFC7011] somewhere in the network.</t>
<t>OWDelay_HybridType1_IP_RFC[RFC-to-be]_Seconds_Min:
This metric assesses the minimum of one-way delays of all
successfully forwarded IP packets constituting a single Flow.
The measurement of one-way delay based on
a single
Observation Point [RFC7011] somewhere in the network.</t>
<t>OWDelay_HybridType1_IP_RFC[RFC-to-be]_Seconds_Max:
This metric assesses the maximum of one-way delays of all
successfully forwarded IP packets constituting a single Flow.
The measurement of one-way delay based on
a single
Observation Point [RFC7011] somewhere in the network.</t>
<t>OWDelay_HybridType1_IP_RFC[RFC-to-be]_Seconds_Sum:
This metric assesses the sum of one-way delays of all
successfully forwarded IP packets constituting a single Flow.
The measurement of one-way delay based on
a single
Observation Point [RFC7011] somewhere in the network.</t>
</list></t>
<t>RFC EDITOR NOTE: please replace [RFC-to-be] with the
allocated RFC document number.</t
>
Current:
The measurement of one-way delay is based on a single Observation Point
[RFC7011] somewhere in the network.
-->
<dl spacing="normal" newline="true">
<dt>OWDelay_HybridType1_IP_RFC9951_Seconds_Mean:</dt>
<dd>This metric assesses the mean of one-way delays of all
successfully forwarded IP packets constituting a single Flow. The
measurement of one-way delay is based on a single Observation Point
<xref target="RFC7011"/> somewhere in the network.</dd>
<dt>OWDelay_HybridType1_IP_RFC9951_Seconds_Min:</dt>
<dd>This metric assesses the minimum of one-way delays of all
successfully forwarded IP packets constituting a single Flow. The
measurement of one-way delay is based on a single Observation Point
<xref target="RFC7011"/> somewhere in the network.</dd>
<dt>OWDelay_HybridType1_IP_RFC9951_Seconds_Max:</dt>
<dd>This metric assesses the maximum of one-way delays of all
successfully forwarded IP packets constituting a single Flow. The
measurement of one-way delay is based on a single Observation Point
<xref target="RFC7011"/> somewhere in the network.</dd>
<dt>OWDelay_HybridType1_IP_RFC9951_Seconds_Sum:</dt>
<dd>This metric assesses the sum of one-way delays of all
successfully forwarded IP packets constituting a single Flow. The
measurement of one-way delay is based on a single Observation Point
<xref target="RFC7011"/> somewhere in the network.</dd>
</dl>
</section> </section>
<section numbered="true" toc="default">
<section title="Reference"> <name>Reference</name>
<t>[RFC-to-be]</t> <t>RFC 9951</t>
<t>RFC EDITOR NOTE: please replace [RFC-to-be] with the
allocated RFC document number.</t
>
</section> </section>
<section numbered="true" toc="default">
<section title="Change Controller"> <name>Change Controller</name>
<t>IETF</t> <t>IETF</t>
</section> </section>
<section numbered="true" toc="default">
<section title="Version of Registry Format"> <name>Version of Registry Format</name>
<t>1.0</t> <t>1.0</t>
</section> </section>
</section> </section>
<section numbered="true" toc="default">
<section title="Metric Definition"> <name>Metric Definition</name>
<t>This category includes columns to prompt the entry of all <t>This category includes columns to prompt the entry of all
necessary details related to the metric definitio n, including necessary details related to the metric definitio n, including
the immutable document reference and values of in put factors, the immutable document reference and values of in put factors,
called "Fixed Parameters".</t> called "Fixed Parameters".</t>
<section numbered="true" toc="default">
<name>Reference Definition</name>
<t>See <xref target="RFC6049"/> and <xref target="RFC7679"/> in the
Normative References (<xref target="norm_ref"/>).</t>
<!-- [rfced] FYI, we corrected this section number as follows; please review.
Section 2 of [RFC2330] is the copyright statement; the terms mentioned
are defined in Section 11 of [RFC2330].
<section title="Reference Definition"> Original:
<t>Almes, G., Kalidindi, S., Zekauskas, M., and A. Morton, Note that terms such as "singleton" and "sample" are defined in
Ed., "A One-Way Delay Metric for IP Perfo Section 2 of [RFC2330].
rmance Metrics
(IPPM)", STD 81, RFC 7679, DOI 10.17487/R
FC7679, January 2016,
&lt;https://www.rfc-editor.org/info/rfc7679&gt;. <xref
target="RFC7679"/></t>
<t>Morton, A. and E. Stephan, "Spatial Composition of Metrics"
, RFC 6049, DOI 10.17487/RFC6049, January
2011,
&lt;https://www.rfc-editor.org/info/rfc6049&gt;. <xref
target="RFC6049"/></t>
<t><xref section="3.4" sectionFormat="of" target="RFC7679"/> Perhaps:
Note that terms such as "singleton" and "sample" are defined in
Section 11 of [RFC2330].
-->
<t><xref section="3.4" sectionFormat="of" target="RFC7679" format="def
ault"/>
provides the reference definition of the singleton (single provides the reference definition of the singleton (single
value) one-way delay metric. <xref sectio value) one-way delay metric. <xref sectio
n="4.4" n="4.4" sectionFormat="of" target="RFC7679" format="default"/> provides the refe
sectionFormat="of" target="RFC7679"/> pro rence
vides the reference
definition expanded to cover a multi-valu e sample. Note that definition expanded to cover a multi-valu e sample. Note that
terms such as "singleton" and "sample" ar terms such as "singleton" and "sample" ar
e defined in <xref e defined in <xref section="11" sectionFormat="of" target="RFC2330" format="defa
section="2" sectionFormat="of" target="RF ult"/>.</t>
C2330"/>.</t> <t>With the Observation Point <xref target="RFC7011" format="default"/
>
<t>With the Observation Point <xref target="RFC7011"/>
typically located between the hosts parti cipating in the IP typically located between the hosts parti cipating in the IP
Flow, the one-way delay metric requires o ne individual Flow, the one-way delay metric requires o ne individual
measurement between the Observation Point and sourcing host, measurement between the Observation Point and sourcing host,
such that the Spatial Composition <xref t arget="RFC6049"/> of such that the Spatial Composition <xref t arget="RFC6049" format="default"/> of
the measurements yields a one-way delay s ingleton.</t> the measurements yields a one-way delay s ingleton.</t>
<t>This document specifies how to export the performance <t>This document specifies how to export the performance
metric using IPFIX.</t> metric using IPFIX.</t>
</section> </section>
<section numbered="true" toc="default">
<section title="Fixed Parameters"> <name>Fixed Parameters</name>
<t>None</t> <t>None</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 <t>This category includes columns for references to relevant sections
sections of the RFC(s) and any supplemental infor of the RFC(s) and any supplemental information needed to ensure an
mation needed unambiguous method for implementations.</t>
to ensure an unambiguous method for implementatio <section numbered="true" toc="default">
ns.</t> <name>Reference Methods</name>
<t>The foundational methodology for this metric is defined in <xref
<section title="Reference Methods"> section="4" sectionFormat="of" target="RFC7323" format="default"/>
<t>The foundational methodology for this metric is defined in using the Timestamps option with modifications that allow
<xref section="4" sectionFormat="of" targ application at a mid-path Observation Point <xref target="RFC7011"
et="RFC7323"/> using format="default"/>.</t>
the Timestamps option with modifications
that allow
application at a mid-path Observation Poi
nt <xref
target="RFC7011"/>.</t>
</section> </section>
<section numbered="true" toc="default">
<section title="Packet Stream Generation"> <name>Packet Stream Generation</name>
<t>The time when the packet is being received at the OAM header <t>This is the time when the packet is being received at the OAM heade
r
encapsulating node. The timestamp format depends on the On-Path encapsulating node. The timestamp format depends on the On-Path
Telemetry implementation. For IOAM, <xref Telemetry implementation. For IOAM, <xref section="4.4.1"
section="4.4.1" sectionFormat="of" target="RFC9197" format="default"/> describes the
sectionFormat="of" target="RFC9197"/> des supported timestamps. Sections <xref target="RFC9197"
cribes the supported sectionFormat="bare" section="4.4.2.3"/> and <xref target="RFC9197"
timestamps. Sections 4.4.2.3 and 4.4.2.4 sectionFormat="bare" section="4.4.2.4"/> of <xref target="RFC9197"/>
describe describe where the timestamp is
where the timestamp is being inserted. Fo being inserted. For the Enhanced Alternate Marking Method, <xref
r the Enhanced section="2" sectionFormat="of"
Alternate Marking Method, <xref section=" target="I-D.zhou-ippm-enhanced-alternate-marking" format="default"/>
2" sectionFormat="of" and <xref section="3.2" sectionFormat="of"
target="I-D.zhou-ippm-enhanced-alternate-marking"/> and <xref target="RFC9947" format="default"/> define the
section="3.2" sectionFormat="of" supported timestamp encodings and granularity.</t>
target="I-D.fz-spring-srv6-alt-mark"/> de
fines the supported timestamp
encodings and granularity.</t>
</section> </section>
<section numbered="true" toc="default">
<section title="Traffic Filtering (Observation) Details"> <name>Traffic Filtering (Observation) Details</name>
<t>Runtime Parameters (in the following sections) may be used <t>Runtime Parameters (in the following sections) may be used
for Traffic Filtering.</t> for Traffic Filtering.</t>
</section> </section>
<section numbered="true" toc="default">
<section title="Sampling Distribution"> <name>Sampling Distribution</name>
<t>This metric requires a partial sample of all packets that <t>This metric requires a partial sample of all packets that
qualify according to the Traffic Filter c riteria.</t> qualify according to the Traffic Filter c riteria.</t>
</section> </section>
<section numbered="true" toc="default">
<section title="Runtime Parameters and Data Format"> <name>Runtime Parameters and Data Format</name>
<t>Runtime Parameters are input factors that must be <t>Runtime Parameters are input factors that must be
determined, configured into a measurement system, and reported determined, configured into a measurement system, and reported
with the results for the context to be co mplete.</t> with the results for the context to be co mplete.</t>
<t>The Hybrid Type I metering parameters must be reported to <t>The Hybrid Type I metering parameters must be reported to
provide the complete measurement context. As an example, if provide the complete measurement context. As an example, if
the IPFIX Metering Process is used, then the IPFIX Metering the IPFIX Metering Process is used, then the IPFIX Metering
Process parameters (IPFIX Template Record , potential traffic Process parameters (IPFIX Template Record , potential traffic
filters, and potential sampling method an d parameters) that filters, and potential sampling method an d parameters) that
generate the Flow Records must be reporte d to provide the generate the Flow Records must be reporte d to provide the
complete measurement context. At a minimu m, the following complete measurement context. At a minimu m, the following
fields are required:</t> fields are required:</t>
<dl newline="false" spacing="normal">
<dt>Src:</dt>
<!-- [rfced] RFC 6991 has been obsoleted by RFC 9911. We have replaced each cit
ation
of RFC 6991 with RFC 9911, as the section numbers seem to contain the data types
being
mentioned. Please review and let us know any further updates. For example:
<t><list style="hanging"> Original: or ipv6-address-no-zone value for IPv6; see Section 4 of [RFC6991]).
<t hangText="Src:">The IP address of the host in the host Current: or ipv6-address-no-zone value for IPv6; see Section 4 of [RFC9911]).
A Role (format ipv4&nbhy; -->
address-no-zone value for IPv4 or <dd>The IP address of the host in the host A Role (format ipv4-addre
ipv6-address-no-zone value for IPv6; see <xref section="4" ss-no-zone value for IPv4 or
sectionFormat="of" target="RFC6991"/>).</t> ipv6-address-no-zone value for IPv6; see <xref section="4" section
Format="of" target="RFC9911" format="default"/>).</dd>
<t hangText="Dst:">The IP address of the host in the host <dt>Dst:</dt>
B Role (format ipv4&nbhy; <dd>The IP address of the host in the host B Role (format ipv4-addre
address-no-zone value for IPv4 or ss-no-zone value for IPv4 or
ipv6-address-no-zone value for IPv6; see <xref section="4" ipv6-address-no-zone value for IPv6; see <xref section="4" section
sectionFormat="of" target="RFC6991"/>).</t> Format="of" target="RFC9911" format="default"/>).</dd>
<dt>T0:</dt>
<t hangText="T0:">T time, the start of a measurement <dd>T time, the start of a measurement
interval (format "date/ti interval (format "date/ti
me" as specified in <xref me" as specified in <xref section="5.6" sectionFormat="of" target="RFC3339" form
section="5.6" sectionForm at="default"/>; see
at="of" target="RFC3339"/>; see also "date-and-time" in <
also "date-and-time" in < xref section="3" sectionFormat="of" target="RFC9911" format="default"/>). The UT
xref section="3" C Time Zone
sectionFormat="of" target is required by <xref sect
="RFC6991"/>). The UTC Time Zone ion="6.1" sectionFormat="of" target="RFC2330" format="default"/>. When T0 is "al
is required by <xref sect l-zeros", a start time
ion="6.1" sectionFormat="of" is unspecified, and Tf is
target="RFC2330"/>. When to be interpreted as the duration
T0 is "all-zeros", a start time
is unspecified and Tf is
to be interpreted as the duration
of the measurement interv al. The start time is controlled of the measurement interv al. The start time is controlled
through other means.</t> through other means.</dd>
<dt>Tf:</dt>
<t hangText="Tf:">A time, the end of a measurement <dd>A time, the end of a measurement
interval (format "date/ti interval (format "date/ti
me" as specified in <xref me" as specified in <xref section="5.6" sectionFormat="of" target="RFC3339" form
section="5.6" sectionForm at="default"/>; see
at="of" target="RFC3339"/>; see also "date-and-time" in <
also "date-and-time" in < xref section="3" sectionFormat="of" target="RFC9911" format="default"/>). The UT
xref section="3" C Time Zone
sectionFormat="of" target is required by <xref sect
="RFC6991"/>). The UTC Time Zone ion="6.1" sectionFormat="of" target="RFC2330" format="default"/>. When T0 is "al
is required by <xref sect l-zeros", an ending time
ion="6.1" sectionFormat="of" and date are ignored, and
target="RFC2330"/>. When Tf is interpreted as the duration
T0 is "all-zeros", an ending time of the measurement interv
and date is ignored and T al.</dd>
f is interpreted as the duration </dl>
of the measurement interv
al.</t>
</list></t>
</section> </section>
<section numbered="true" toc="default">
<section title="Roles"> <name>Roles</name>
<t><list style="hanging"> <dl newline="false" spacing="normal">
<t hangText="host A:">Launches an IP packet to start the <dt>Host A:</dt>
Flow.</t> <dd>Launches an IP packet to start the
Flow.</dd>
<t hangText="host B:">Receives the IP packet to start the <dt>Host B:</dt>
Flow.</t> <dd>Receives the IP packet to start the
Flow.</dd>
<t hangText="OAM Header Encapsulating Node:"> Receives the <dt>OAM Header Encapsulating Node:</dt>
IP packets, encapsulates <dd> Receives the
the packets with the OAM header IP packets, encapsulates
and adds the timestamp in the packets with the OAM header,
to the OAM header.</t> and adds the timestamp in
to the OAM header.</dd>
<t hangText="OAM Header Transit Node:">Receives the IP <dt>OAM Header Transit Node:</dt>
<dd>Receives the IP
packets, measures the del ay between the timestamp in the packets, measures the del ay between the timestamp in the
packet and the timestamp packet and the timestamp
when the packet was received.</t> when the packet was received.</dd>
<dt>OAM Header Decapsulating Node:</dt>
<t hangText="OAM Header Decapsulating Node:">Receives the <dd>Receives the
IP packets, computes the delay between the timestamp in IP packets, computes the delay between the timestamp in
the packet and the timest the packet and the timest
amp when the packet was received amp when the packet was received,
and removes the OAM heade and removes the OAM heade
r from the packet.</t> r from the packet.</dd>
</list></t> </dl>
</section> </section>
</section> </section>
<section numbered="true" toc="default">
<section title="Output"> <name>Output</name>
<t>This category specifies all details of the output of <t>This category specifies all details of the output of
measurements using the metric.</t> measurements using the metric.</t>
<section numbered="true" toc="default">
<section title="Type"> <name>Type</name>
<t>OWDelay Types are discussed in the subsections below.</t> <t>OWDelay Types are discussed in the subsections below.</t>
</section> </section>
<section numbered="true" toc="default">
<section title="Reference Definition"> <name>Reference Definition</name>
<t>For all output types:</t> <t>For all output types:</t>
<dl newline="false" spacing="normal">
<t><list style="hanging"> <dt>OWDelay_HybridType1_IP:</dt>
<t hangText="OWDelay_HybridType1_IP:">The one-way <dd>The one-way
delay of one IP packet is delay of one IP packet is
a Singleton</t> a Singleton.</dd>
</list></t> </dl>
<t>For each &lt;statistic&gt; Singleton, one of the following
<t>For each &lt;statistic&gt; Singleton one of the following
subsections applies.</t> subsections applies.</t>
<section numbered="true" toc="default">
<section <name>OWDelay_HybridType1_IP_RFC9951_Seconds_Mean</name>
title="OWDelay_HybridType1_IP_RFC[RFC-to-be]_Seconds_Mean"> <t>Similar to <xref section="7.4.2.2" sectionFormat="of" target="RFC
<t>Similar to <xref section="7.4.2.2" sectionFormat="of" 8912" format="default"/>, the mean <bcp14>SHALL</bcp14> be calculated using the
target="RFC8912"/>, the mean SHALL be calculated using the
conditional distribution of all packets with a finite value conditional distribution of all packets with a finite value
of one-way delay (undefined delay s are excluded) -- a single of one-way delay (undefined delay s are excluded) -- a single
value, as follows:</t> value, as follows:</t>
<!--[rfced] We suggest changing "analysis choice" (4 instances) to
"analytic choice" or "analytical choice", because "analysis" is a noun.
We note the term "analysis choice" is only used RFC 8912. For example:
<t>See <xref section="4.1" sectionFormat="of" Original:
target="RFC3393"/> for details on see Section 5 of [RFC6703] for background on this analysis choice.
the conditional
Suggested:
see Section 5 of [RFC6703] for background on this analytic choice.
-->
<t>See <xref section="4.1" sectionFormat="of" target="RFC3393" forma
t="default"/> for details on the conditional
distribution to exclude undefined values of delay, and see distribution to exclude undefined values of delay, and see
<xref section="5" sectionFormat=" of" target="RFC6703"/> for <xref section="5" sectionFormat=" of" target="RFC6703" format="default"/> for
background on this analysis choic e.</t> background on this analysis choic e.</t>
<t>See <xref section="4.2.2" sectionFormat="of" target="RFC6049" for
<t>See <xref section="4.2.2" sectionFormat="of" mat="default"/> for details on calculating this
target="RFC6049"/> for details on statistic; see also <xref section
calculating this ="4.2.3" sectionFormat="of" target="RFC6049" format="default"/>.</t>
statistic; see also <xref section <dl newline="false" spacing="normal">
="4.2.3" sectionFormat="of" <dt>Mean:</dt>
target="RFC6049"/>.</t> <dd>The time value of the result is
<t><list style="hanging">
<t hangText="Mean:">The time value of the result is
expressed in unit s of microseconds, as a positive value expressed in unit s of microseconds, as a positive value
of type decimal64 with fraction digits = 9 (similar to of type decimal64 with fraction digits = 9 (similar to
the decimal64 in YANG, <xref section="9.3" decimal64 in YANG, <xref section="9.3" sectionFormat="of" target
sectionFormat="of ="RFC6020" format="default"/>) with a resolution
" target="RFC6020"/>) with a resolution of 0.001 microsec
of 0.001&nbsp;mic onds (1.0 ns), and with
roseconds (1.0 ns), and with
lossless conversi on to/from the 64-bit NTP timestamp as lossless conversi on to/from the 64-bit NTP timestamp as
per <xref section per <xref section
="6" sectionFormat="of" ="6" sectionFormat="of" target="RFC5905" format="default"/>.
target="RFC5905"/>. </dd>
</t> </dl>
</list></t>
</section> </section>
<section numbered="true" toc="default">
<section <name>OWDelay_HybridType1_IP_RFC9951_Seconds_Min</name>
title="OWDelay_HybridType1_IP_RFC[RFC-to-be]_Seconds_Min" <t>Similar to <xref section="7.4.2.3" sectionFormat="of" target="RFC
> 8912" format="default"/>, the minimum <bcp14>SHALL</bcp14> be calculated using
<t>Similar to <xref section="7.4.2.3" sectionFormat="of"
target="RFC8912"/>, the minimum SHALL be calculated using
the conditional distribution of a ll packets with a finite the conditional distribution of a ll packets with a finite
value of one-way delay (undefined delays are excluded) -- a value of one-way delay (undefined delays are excluded) -- a
single value, as follows:</t> single value, as follows:</t>
<t>See <xref section="4.1" sectionFormat="of" target="RFC3393" forma
<t>See <xref section="4.1" sectionFormat="of" t="default"/> for details on the conditional
target="RFC3393"/> for details on
the conditional
distribution to exclude undefined values of delay, and see distribution to exclude undefined values of delay, and see
<xref section="5" sectionFormat=" of" target="RFC6703"/> for <xref section="5" sectionFormat=" of" target="RFC6703" format="default"/> for
background on this analysis choic e.</t> background on this analysis choic e.</t>
<t>See <xref section="4.3.2" sectionFormat="of" target="RFC6049" for
<t>See <xref section="4.3.2" sectionFormat="of" mat="default"/> for details on calculating this
target="RFC6049"/> for details on statistic; see also <xref section
calculating this ="4.3.3" sectionFormat="of" target="RFC6049" format="default"/>.</t>
statistic; see also <xref section <dl newline="false" spacing="normal">
="4.3.3" sectionFormat="of" <dt>Min:</dt>
target="RFC6049"/>.</t> <dd>The time value of the result is
<t><list style="hanging">
<t hangText="Min:">The time value of the result is
expressed in unit s of microseconds, as a positive value expressed in unit s of microseconds, as a positive value
of type decimal64 with fraction digits = 9 (similar to of type decimal64 with fraction digits = 9 (similar to
the decimal64 in decimal64 in YANG
YANG, <xref section="9.3" , <xref section="9.3" sectionFormat="of" target="RFC6020" format="default"/>) wi
sectionFormat="of th a resolution
" target="RFC6020"/>) with a resolution of 0.001 microsec
of 0.001&nbsp;mic onds (1.0 ns), and with
roseconds (1.0 ns), and with
lossless conversi on to/from the 64-bit NTP timestamp as lossless conversi on to/from the 64-bit NTP timestamp as
per <xref section per <xref section
="6" sectionFormat="of" ="6" sectionFormat="of" target="RFC5905" format="default"/>.
target="RFC5905"/ </dd>
>. </dl>
</t>
</list></t>
</section> </section>
<section numbered="true" toc="default">
<section <name>OWDelay_HybridType1_IP_RFC9951_Seconds_Max</name>
title="OWDelay_HybridType1_IP_RFC[RFC-to-be]_Seconds_Max" <t>Similar to <xref section="7.4.2.4" sectionFormat="of" target="RFC
> 8912" format="default"/>, the maximum <bcp14>SHALL</bcp14> be calculated using
<t>Similar to <xref section="7.4.2.4" sectionFormat="of"
target="RFC8912"/>, the maximum SHALL be calculated using
the conditional distribution of a ll packets with a finite the conditional distribution of a ll packets with a finite
value of one-way delay (undefined delays are excluded) -- a value of one-way delay (undefined delays are excluded) -- a
single value, as follows:</t> single value, as follows:</t>
<t>See <xref section="4.1" sectionFormat="of" target="RFC3393" forma
<t>See <xref section="4.1" sectionFormat="of" t="default"/> for details on the conditional
target="RFC3393"/> for details on
the conditional
distribution to exclude undefined values of delay, and see distribution to exclude undefined values of delay, and see
<xref section="5" sectionFormat=" of" target="RFC6703"/> for <xref section="5" sectionFormat=" of" target="RFC6703" format="default"/> for
background on this analysis choic e.</t> background on this analysis choic e.</t>
<t>See <xref section="4.3.2" sectionFormat="of" target="RFC6049" for
<t>See <xref section="4.3.2" sectionFormat="of" mat="default"/> for a closely related method for
target="RFC6049"/> for a closely calculating this statistic; see a
related method for lso <xref section="4.3.3" sectionFormat="of" target="RFC6049" format="default"/>
calculating this statistic; see a . The formula is as
lso <xref section="4.3.3"
sectionFormat="of" target="RFC604
9"/>. The formula is as
follows:</t> follows:</t>
<artwork name="" type="" align="left" alt=""><![CDATA[
<t><figure>
<artwork><![CDATA[
Max = (FiniteDelay[j]) Max = (FiniteDelay[j])
such that for some index, j, where 1 <= j <= N such that for some index, j, where 1 <= j <= N
FiniteDelay[j] >= FiniteDelay[n] for all n FiniteDelay[j] >= FiniteDelay[n] for all n
]]></artwork> ]]></artwork>
</figure></t>
<t>where all packets n = 1 through N have finite singleton <t>where all packets n = 1 through N have finite singleton
delays.</t> delays.</t>
<dl newline="false" spacing="normal">
<t><list style="hanging"> <dt>Max:</dt>
<t hangText="Max:">The time value of the result is <dd>The time value of the result is
expressed in unit s of microseconds, as a positive value expressed in unit s of microseconds, as a positive value
of type decimal64 with fraction digits = 9 (similar to of type decimal64 with fraction digits = 9 (similar to
the decimal64 in decimal64 in YANG
YANG, <xref section="9.3" , <xref section="9.3" sectionFormat="of" target="RFC6020" format="default"/>) wi
sectionFormat="of th a resolution
" target="RFC6020"/>) with a resolution of 0.001 microsec
of 0.001&nbsp;mic onds (1.0 ns), and with
roseconds (1.0 ns), and with
lossless conversi on to/from the 64-bit NTP timestamp as lossless conversi on to/from the 64-bit NTP timestamp as
per <xref section per <xref section
="6" sectionFormat="of" ="6" sectionFormat="of" target="RFC5905" format="default"/>.
target="RFC5905"/ </dd>
>. </dl>
</t>
</list></t>
</section> </section>
<section numbered="true" toc="default">
<section <name>OWDelay_HybridType1_IP_RFC9951_Seconds_Sum</name>
title="OWDelay_HybridType1_IP_RFC[RFC-to-be]_Seconds_Sum" <t>The sum <bcp14>SHALL</bcp14> be calculated using the conditional
>
<t>The sum SHALL be calculated using the conditional
distribution of all packets with a finite value of one-way distribution of all packets with a finite value of one-way
delay (undefined delays are exclu ded) -- a single value, as delay (undefined delays are exclu ded) -- a single value, as
follows:</t> follows:</t>
<t>See <xref section="4.1" sectionFormat="of" target="RFC3393" forma
<t>See <xref section="4.1" sectionFormat="of" t="default"/> for details on the conditional
target="RFC3393"/> for details on
the conditional
distribution to exclude undefined values of delay, and see distribution to exclude undefined values of delay, and see
<xref section="5" sectionFormat=" of" target="RFC6703"/> for <xref section="5" sectionFormat=" of" target="RFC6703" format="default"/> for
background on this analysis choic e.</t> background on this analysis choic e.</t>
<t>See <xref section="4.3.5" sectionFormat="of" target="RFC6049" for
<t>See <xref section="4.3.5" sectionFormat="of" mat="default"/> for details on calculating this
target="RFC6049"/> for details on statistic; however, in this case,
calculating this FiniteDelay or MaxDelay <bcp14>MAY</bcp14>
statistic, however in this case F
initeDelay or MaxDelay MAY
be used.</t> be used.</t>
<dl newline="false" spacing="normal">
<t><list style="hanging"> <dt>Sum:</dt>
<t hangText="Sum:">The time value of the result is <dd>The time value of the result is
expressed in unit s of microseconds, as a positive value expressed in unit s of microseconds, as a positive value
of type decimal64 with fraction digits = 9 (similar to of type decimal64 with fraction digits = 9 (similar to
the decimal64 in decimal64 in YANG
YANG, <xref section="9.3" , <xref section="9.3" sectionFormat="of" target="RFC6020" format="default"/>) wi
sectionFormat="of th a resolution
" target="RFC6020"/>) with a resolution of 0.001 microsec
of 0.001&nbsp;mic onds (1.0 ns), and with
roseconds (1.0 ns), and with
lossless conversi on to/from the 64-bit NTP timestamp as lossless conversi on to/from the 64-bit NTP timestamp as
per <xref section per <xref section
="6" sectionFormat="of" ="6" sectionFormat="of" target="RFC5905" format="default"/>.
target="RFC5905"/ </dd>
>. </dl>
</t>
</list></t>
</section> </section>
<section numbered="true" toc="default">
<section title="Metric Units"> <name>Metric Units</name>
<t><list style="symbols"> <ul spacing="normal">
<li>
<t>Mean</t> <t>Mean</t>
</li>
<li>
<t>Min</t> <t>Min</t>
</li>
<li>
<t>Max</t> <t>Max</t>
</li>
<li>
<t>Sum</t> <t>Sum</t>
</list></t> </li>
</ul>
<t>The one-way delay of the IP Flow singleton is expressed <t>The one-way delay of the IP Flow singleton is expressed
in microseconds.</t> in microseconds.</t>
</section> </section>
<section numbered="true" toc="default">
<section title="Calibration"> <name>Calibration</name>
<t>A clock synchronization between the nodes of the <t>A clock synchronization between the nodes of the monitored OAM
monitored OAM domain is needed to domain is needed to compute representative delay measurements at
compute representative the OAM header transit and decapsulating nodes. NTP, as defined in
delay measurements at the OAM hea <xref target="RFC5905" format="default"/>, can be used for
der transit and synchronizing the clocks of the monitored nodes.</t>
decapsulating nodes. NTP, as defi
ned in <xref
target="RFC5905"/>, can be used f
or synchronizing the clocks
of the monitored nodes.</t>
</section> </section>
</section> </section>
<section numbered="true" toc="default">
<section title="Administrative Items"> <name>Administrative Items</name>
<section title="Status"> <section numbered="true" toc="default">
<name>Status</name>
<t>Current</t> <t>Current</t>
</section> </section>
<section numbered="true" toc="default">
<section title="Requester"> <name>Requester</name>
<t>RFC[RFC-to-be]</t> <t>RFC 9951</t>
<t>RFC EDITOR NOTE: please replace [RFC-to-be] with the
allocated RFC document number and
[RFC-date] with the
date when the RFC has been publis
hed.</t>
</section> </section>
<section numbered="true" toc="default">
<section title="Revision"> <name>Revision</name>
<t>1.0</t> <t>1.0</t>
</section> </section>
<section numbered="true" toc="default">
<section title="Revision Date"> <!--[rfced] FYI, Revision Date will be updated before publication.-->
<t>RFC[RFC-date]</t> <name>Revision Date</name>
<t>2026-MM-DD</t>
</section> </section>
</section> </section>
<section numbered="true" toc="default">
<section title="Comments and Remarks"> <name>Comments and Remarks</name>
<t>none</t> <t>None</t>
</section> </section>
</section> </section>
</section> </section>
<section anchor="Use-Cases" numbered="true" toc="default">
<name>Use Cases</name>
<!--[rfced] Please clarify "as defined to the following [...] dimensions";
should it be "as defined across the following [...] dimensions"?
<section anchor="Use-Cases" title="Use Cases"> Original:
<t>The measured On-Path delay can be aggregated with Flow The measured On-Path delay can be aggregated with Flow Aggregation as
Aggregation as defined in <xref target="RFC7015"/> to the defined in [RFC7015] to the following device and control-plane
following device and control-plane dimensions <xref dimensions [IANA-IPFIX] to determine:
target="IANA-IPFIX"/> to determine:</t>
<t><list style="symbols"> Perhaps:
The measured On-Path delay can be aggregated with Flow Aggregation as
defined in [RFC7015] across the following device and control-plane
dimensions [IANA-IPFIX] to determine:
-->
<t>The measured On-Path delay can be aggregated with Flow
Aggregation as defined in <xref target="RFC7015" format="
default"/> to the
following device and control-plane dimensions <xref targe
t="IANA-IPFIX" format="default"/> to determine:</t>
<ul spacing="normal">
<li>
<t>With node id and egressInterface(14), on which node which <t>With node id and egressInterface(14), on which node which
logical egress interfaces have been contr ibuting to how much logical egress interfaces have been contr ibuting to how much
delay.</t> delay.</t>
</li>
<li>
<t>With node id and egressPhysicalInterface(253), on which <t>With node id and egressPhysicalInterface(253), on which
node which physical egress interfaces hav e been contributing node which physical egress interfaces hav e been contributing
to how much delay.</t> to how much delay.</t>
</li>
<li>
<t>With ipNextHopIPv4Address(15) or ipNextHopIPv6Address(62), <t>With ipNextHopIPv4Address(15) or ipNextHopIPv6Address(62),
the forwarding path to which next-hop IP contributed to how the forwarding path to which next-hop IP contributed to how
much delay.</t> much delay.</t>
</li>
<li>
<t>With mplsTopLabelIPv4Address(47) or destinationIPv6Address <t>With mplsTopLabelIPv4Address(47) or destinationIPv6Address
and srhActiveSegmentIPv6(495), the forwar ding path to which and srhActiveSegmentIPv6(495), the forwar ding path to which
MPLS top label IPv4 address or IPv6 desti MPLS top-label IPv4 address or IPv6 desti
nation address and nation address and
SRv6 active segment contributed to how mu Segment Routing over IPv6 (SRv6) active s
ch delay.</t> egment contributed to how much delay.</t>
</li>
<t>BGP communities <xref target="RFC1997"/> are often used for <li>
<t>BGP communities <xref target="RFC1997" format="default"/> are often
used for
setting a path priority or service selection. With setting a path priority or service selection. With
bgpDestinationExtendedCommunityList(488) or bgpDestinationExtendedCommunityList(488) or
bgpDestinationCommunityList(485) or bgpDestinationCommunityList(485) or
bgpDestinationLargeCommunityList(491) which group of prefixes bgpDestinationLargeCommunityList(491), which group of prefixes
accumulated at which node how much delay.</t> accumulated at which node how much delay.</t>
</li>
<t>With destinationIPv4Address(13), <li>
destinationTransportPort(11), protocolIde <t>With destinationIPv4Address(13), destinationTransportPort(11),
ntifier (4) and protocolIdentifier(4), and sourceIPv4Address(8), or equivalent IPFIX
sourceIPv4Address(8), or equivalent IPFIX IEs for IPv6, the forwarding path delay on each node from each IPv4
IEs for IPv6, the
forwarding path delay on each node from e
ach IPv4
source address to a specific application in the network.</t> source address to a specific application in the network.</t>
</list></t> </li>
</ul>
<!-- [rfced] FYI, we simplified this sentence as follows; please review.
<t>Let us consider the example depicted in Figure 1 from Section 1 Original:
as topology example. Below example table shows the aggreg Let us consider the example depicted in Figure 1 from Section 1 as
ated topology example.
delay per each node, ingressInterface,(10) egressInterfac
e(14),
destinationIPv6Address(28) and srhActiveSegmentIPv6(495) measured
at ingress.</t>
<t><figure> Current:
<artwork><![CDATA[ Let us consider Figure 1 as a topology example.
+-----------+-----------+------+-------------+-------------+-----------+ -->
| ingress | egress | Node | destination | srhActive | Path | <t>Let us consider <xref target="topology"/> as a topology
| Interface | Interface | | IPv6Address | SegmentIPv6 | Delay | example. <xref target="tab-2"/> shows the aggregated delay per each
+-----------+-----------+------+-------------+-------------+-----------+ node, ingressInterface(10), egressInterface(14),
| 271 | 276 | R0 | | | 0 µs | destinationIPv6Address(28), and srhActiveSegmentIPv6(495) measured at
+-----------+-----------+------+-------------+-------------+-----------+ ingress.</t>
| 301 | 312 | R1 | 2001:db8::1 | 2001:db8::3 | 22 µs | <table anchor="tab-2">
+-----------+-----------+------+-------------+-------------+-----------+ <name>Example Table of Measured Delay at Ingress, Ascending by Delay</name>
| 22 | 27 | R2 | 2001:db8::2 | 2001:db8::3 | 42 µs | <thead>
+-----------+-----------+------+-------------+-------------+-----------+ <tr>
| 852 | 854 | R3 | 2001:db8::3 | 2001:db8::3 | 122 µs | <th>ingress Interface</th>
+-----------+-----------+------+-------------+-------------+-----------+ <th>egress Interface</th>
<th>Node</th>
<th>destination IPv6Address</th>
<th>srhActive SegmentIPv6</th>
<th>Path Delay</th>
</tr>
</thead>
<tbody>
<tr>
<td>271</td>
<td>276</td>
<td>R0</td>
<td></td>
<td></td>
<td>0 µs</td>
</tr>
<tr>
<td>301</td>
<td>312</td>
<td>R1</td>
<td>2001:db8::1</td>
<td>2001:db8::3</td>
<td>22 µs</td>
</tr>
<tr>
<td>22</td>
<td>27</td>
<td>R2</td>
<td>2001:db8::2</td>
<td>2001:db8::3</td>
<td>42 µs</td>
</tr>
<tr>
<td>852</td>
<td>854</td>
<td>R3</td>
<td>2001:db8::3</td>
<td>2001:db8::3</td>
<td>122 µs</td>
</tr>
</tbody>
</table>
Table 2: Example table of measured delay at ingress. Ascending by delay.
]]></artwork>
</figure></t>
</section> </section>
<section anchor="IANA" numbered="true" toc="default">
<section anchor="IANA" title="IANA Considerations"> <name>IANA Considerations</name>
<section anchor="PM-IANA" title="Performance Metrics"> <section anchor="PM-IANA" numbered="true" toc="default">
<t>This document requests IANA to add four new performance <name>Performance Metrics</name>
metrics under the "Performance Metrics" registry <t>IANA has add four new performance metrics
<xref in the "Performance Metrics Registry" <xref target="RFC8911"
target="RFC8911"/> with the four templates define format="default"/> with the four templates defined in <xref target="Solu
d in Section 3. tion"/>.
</t> </t>
</section> </section>
<section anchor="IE-IANA" numbered="true" toc="default">
<name>IPFIX Entities</name>
<t>IANA has registered new IPFIX IEs (see <xref target="tab-3"/>)
in the "IPFIX Information Elements" registry in the "IP Flow
Information Export (IPFIX) Entities" registry group <xref
target="IANA-IPFIX" format="default"/> and assigned the following
code points.</t>
<table anchor="tab-3">
<name>New IPFIX IEs in the "IPFIX Information Elements" Registry</name>
<thead>
<tr>
<th>ElementID</th>
<th>Name</th>
</tr>
</thead>
<tbody>
<tr>
<td>530</td>
<td>pathDelayMeanDeltaMicroseconds</td>
</tr>
<tr>
<td>531</td>
<td>pathDelayMinDeltaMicroseconds</td>
</tr>
<tr>
<td>532</td>
<td>pathDelayMaxDeltaMicroseconds</td>
</tr>
<tr>
<td>533</td>
<td>pathDelaySumDeltaMicroseconds</td>
</tr>
</tbody>
</table>
<section anchor="IE-IANA" title="IPFIX Entities"> <section anchor="IANApathDelayMeanDeltaMicroseconds" numbered="true" toc
<t>This document requests IANA to register new IPFIX IEs (see ="default">
table 3) under the "IPFIX Information Elements" r <name>pathDelayMeanDeltaMicroseconds</name>
egistry under
the "IP Flow Information Export (IPFIX) Entities" registry group
<xref target="IANA-IPFIX"/> and assign the follow
ing initial
code points.</t>
<t><figure>
<artwork><![CDATA[
+-------+--------------------------------+
|Element| Name |
| ID | |
+-------+--------------------------------+
| TBD5 | pathDelayMeanDeltaMicroseconds |
| | |
+-------+--------------------------------+
| TBD6 | pathDelayMinDeltaMicroseconds |
| | |
+-------+--------------------------------+
| TBD7 | pathDelayMaxDeltaMicroseconds |
| | |
+-------+--------------------------------+
| TBD8 | pathDelaySumDeltaMicroseconds |
| | |
+-------+--------------------------------+
Table 3: New IPFIX IEs in the "IPFIX Information Elements" Registry
]]></artwork>
</figure></t>
<t>Note to the RFC-Editor:</t>
<t><list style="symbols">
<t>Please replace TBD5 - TBD8 with the values allocated by
IANA</t>
<t>Please replace all instances of [RFC-to-be] in this
section with the RFC number assig
ned to this document</t>
</list></t>
<section anchor="IANApathDelayMeanDeltaMicroseconds"
title="pathDelayMeanDeltaMicroseconds">
<dl> <dl>
<dt>Name:</dt> <dt>Name:</dt>
<dd>pathDelayMeanDeltaMicroseconds</dd> <dd>pathDelayMeanDeltaMicroseconds</dd>
</dl> </dl>
<dl> <dl>
<dt>ElementID:</dt> <dt>ElementID:</dt>
<dd>530</dd>
<dd>TBD5</dd>
</dl> </dl>
<dl> <dl>
<dt>Description:</dt> <dt>Description:</dt>
<dd>This Information Element identifies the mean path delay of all
<dd>This Information Element identifies the mean path delay packets in the Flow, in microseconds, between an OAM header
of all packets in the Flow, in mi encapsulating node and the local node with the OAM domain (either
croseconds, between an OAM an OAM header transit node or an OAM header decapsulating node),
header encapsulating node and the local node with the OAM according to OWDelay_HybridType1_IP_RFC9951_Seconds_Mean in the
domain (either an OAM header tran IANA "Performance Metrics Registry".</dd>
sit node or an OAM header
decapsulating node), according to
OWDelay_HybridType1_IP_RFC[RFC-to
-be]_Seconds_Mean
in the IANA Performance Metric Re
gistry.</dd>
</dl> </dl>
<dl> <dl>
<dt>Abstract Data Type:</dt> <dt>Abstract Data Type:</dt>
<dd>unsigned32</dd> <dd>unsigned32</dd>
</dl> </dl>
<dl> <dl>
<dt>Data Type Semantics:</dt> <dt>Data Type Semantics:</dt>
<dd>deltaCounter</dd> <dd>deltaCounter</dd>
</dl> </dl>
<dl> <dl>
<dt>Reference:</dt> <dt>Reference:</dt>
<dd>RFC 9951</dd>
<dd>[RFC-to-be]</dd>
</dl> </dl>
<dl> <dl>
<dt>Additional Information:</dt> <dt>Additional Information:</dt>
<dd>OWDelay_HybridType1_IP_RFC9951_Seconds_Mean in the IANA
<dd>OWDelay_HybridType1_IP_RFC[RFC-to-be]_Seconds_Mean "Performance Metrics Registry".</dd>
in the IANA Performance Metric Registry
.</dd>
</dl> </dl>
</section> </section>
<section anchor="IANApathDelayMinDeltaMicroseconds" numbered="true" toc=
<section anchor="IANApathDelayMinDeltaMicroseconds" "default">
title="pathDelayMinDeltaMicroseconds"> <name>pathDelayMinDeltaMicroseconds</name>
<dl> <dl>
<dt>Name:</dt> <dt>Name:</dt>
<dd>pathDelayMinDeltaMicroseconds</dd> <dd>pathDelayMinDeltaMicroseconds</dd>
</dl> </dl>
<dl> <dl>
<dt>ElementID:</dt> <dt>ElementID:</dt>
<dd>531</dd>
<dd>TBD6</dd>
</dl> </dl>
<dl> <dl>
<dt>Description:</dt> <dt>Description:</dt>
<dd>This Information Element identifies the lowest path delay of
<dd>This Information Element identifies the lowest path all packets in the Flow, in microseconds, between an OAM header
delay of all packets in the Flow, encapsulating node and the local node with the OAM domain (either
in microseconds, between an OAM header transit node or an OAM header decapsulating node),
an OAM header encapsulating node according to the OWDelay_HybridType1_IP_RFC9951_Seconds_Min in the
and the local node with the IANA "Performance Metrics Registry".</dd>
OAM domain (either an OAM header
transit node or an OAM
header decapsulating node), accor
ding to the
OWDelay_HybridType1_IP_RFC[RFC-to
-be]_Seconds_Min in
the IANA Performance Metric Registry.</dd>
</dl> </dl>
<dl> <dl>
<dt>Abstract Data Type:</dt> <dt>Abstract Data Type:</dt>
<dd>unsigned32</dd> <dd>unsigned32</dd>
</dl> </dl>
<dl> <dl>
<dt>Data Type Semantics:</dt> <dt>Data Type Semantics:</dt>
<dd>deltaCounter</dd> <dd>deltaCounter</dd>
</dl> </dl>
<dl> <dl>
<dt>Reference:</dt> <dt>Reference:</dt>
<dd>RFC 9951</dd>
<dd>[RFC-to-be]</dd>
</dl> </dl>
<dl> <dl>
<dt>Additional Information:</dt> <dt>Additional Information:</dt>
<dd>OWDelay_HybridType1_IP_RFC9951_Seconds_Min
<dd>OWDelay_HybridType1_IP_RFC[RFC-to-be]_Seconds_Min in the IANA "Performance Metrics Regist
in the IANA Performance Metric Registry ry".</dd>
.</dd>
</dl> </dl>
</section> </section>
<section anchor="IANApathDelayMaxDeltaMicroseconds" numbered="true" toc=
<section anchor="IANApathDelayMaxDeltaMicroseconds" "default">
title="pathDelayMaxDeltaMicroseconds"> <name>pathDelayMaxDeltaMicroseconds</name>
<dl> <dl>
<dt>Name:</dt> <dt>Name:</dt>
<dd>pathDelayMaxDeltaMicroseconds</dd> <dd>pathDelayMaxDeltaMicroseconds</dd>
</dl> </dl>
<dl> <dl>
<dt>ElementID:</dt> <dt>ElementID:</dt>
<dd>532</dd>
<dd>TBD7</dd>
</dl> </dl>
<dl> <dl>
<dt>Description:</dt> <dt>Description:</dt>
<dd>This Information Element identifies the highest path delay of
<dd>This Information Element identifies the highest path all packets in the Flow, in microseconds, between an OAM header
delay of all packets in the Flow, encapsulating node and the local node with the OAM domain (either
in microseconds, between an OAM header transit node or an OAM header decapsulating node),
an OAM header encapsulating node according to OWDelay_HybridType1_IP_RFC9951_Seconds_Max in the
and the local node with the IANA "Performance Metrics Registry".</dd>
OAM domain (either an OAM header
transit node or an OAM
header decapsulating node), accor
ding to
OWDelay_HybridType1_IP_RFC[RFC-to
-be]_Seconds_Max in
the IANA Performance Metric Regis
try.</dd>
</dl> </dl>
<dl> <dl>
<dt>Abstract Data Type:</dt> <dt>Abstract Data Type:</dt>
<dd>unsigned32</dd> <dd>unsigned32</dd>
</dl> </dl>
<dl> <dl>
<dt>Data Type Semantics:</dt> <dt>Data Type Semantics:</dt>
<dd>deltaCounter</dd> <dd>deltaCounter</dd>
</dl> </dl>
<dl> <dl>
<dt>Reference:</dt> <dt>Reference:</dt>
<dd>RFC 9951</dd>
<dd>[RFC-to-be]</dd>
</dl> </dl>
<dl> <dl>
<dt>Additional Information:</dt> <dt>Additional Information:</dt>
<dd>OWDelay_HybridType1_IP_RFC9951_Seconds_Max in the IANA
<dd>OWDelay_HybridType1_IP_RFC[RFC-to-be]_Seconds_Max "Performance Metrics Registry".</dd>
in the IANA Performance Metric Registry
.</dd>
</dl> </dl>
</section> </section>
<section anchor="IANApathDelaySumDeltaMicroseconds" numbered="true" toc=
<section anchor="IANApathDelaySumDeltaMicroseconds" "default">
title="pathDelaySumDeltaMicroseconds"> <name>pathDelaySumDeltaMicroseconds</name>
<dl> <dl>
<dt>Name:</dt> <dt>Name:</dt>
<dd>pathDelaySumDeltaMicroseconds</dd> <dd>pathDelaySumDeltaMicroseconds</dd>
</dl> </dl>
<dl> <dl>
<dt>ElementID:</dt> <dt>ElementID:</dt>
<dd>533</dd>
<dd>TBD8</dd>
</dl> </dl>
<dl> <dl>
<dt>Description:</dt> <dt>Description:</dt>
<dd>This Information Element identifies the sum of the path delay
<dd>This Information Element identifies the sum of the path of all packets in the Flow, in microseconds, between an OAM header
delay of all packets in the Flow, encapsulating node and the local node with the OAM domain (either
in microseconds, between an OAM header transit node or an OAM header decapsulating node),
an OAM header encapsulating node according to OWDelay_HybridType1_IP_RFC9951_Seconds_Sum in the
and the local node with the IANA "Performance Metrics Registry".</dd>
OAM domain (either an OAM header
transit node or an OAM
header decapsulating node), accor
ding to
OWDelay_HybridType1_IP_RFC[RFC-to-be]_Seconds_Sum in
the IANA Performance Metric Regis
try.</dd>
</dl> </dl>
<dl> <dl>
<dt>Abstract Data Type:</dt> <dt>Abstract Data Type:</dt>
<dd>unsigned64</dd> <dd>unsigned64</dd>
</dl> </dl>
<dl> <dl>
<dt>Data Type Semantics:</dt> <dt>Data Type Semantics:</dt>
<dd>deltaCounter</dd> <dd>deltaCounter</dd>
</dl> </dl>
<dl> <dl>
<dt>Reference:</dt> <dt>Reference:</dt>
<dd>RFC 9951</dd>
<dd>[RFC-to-be]</dd>
</dl> </dl>
<dl> <dl>
<dt>Additional Information:</dt> <dt>Additional Information:</dt>
<dd>OWDelay_HybridType1_IP_RFC9951_Seconds_Sum in the IANA
<dd>OWDelay_HybridType1_IP_RFC[RFC-to-be]_Seconds_Sum "Performance Metrics Registry".</dd>
in the IANA Performance Metric Registry
.</dd>
</dl> </dl>
</section> </section>
</section> </section>
</section> </section>
<section anchor="Operational" numbered="true" toc="default">
<section anchor="Operational" title="Operational Considerations"> <name>Operational Considerations</name>
<section anchor="OpsTimeAccuracy" title="Time Accuracy"> <section anchor="OpsTimeAccuracy" numbered="true" toc="default">
<t>The same recommendation as defined in <xref section="4.5" <name>Time Accuracy</name>
sectionFormat="of" target="RFC5153"/> for IPFIX applies in terms <t>In terms of clock precision, the same recommendation as defined in <x
of clock precision to this document as well.</t> ref section="4.5" sectionFormat="of" target="RFC5153" format="default"/> for IPF
IX applies
to this document as well.</t>
</section> </section>
<section anchor="OpsMeanDelay" numbered="true" toc="default">
<name>Mean Delay</name>
<!--[rfced] How may this be rephrased to avoid the odd phrase
"offload the IPFIX Exporter from calculating the mean"?
Specifically, rather than "offload X from doing a task", we can
offload the task - or we can offload X by doing the task elsewhere.
Original:
The mean (average) path delay can be calculated by dividing the
pathDelaySumDeltaMicroseconds(533) by the packetDeltaCount(2) at the
IPFIX data collection in order to offload the IPFIX Exporter from
calculating the mean for every Flow at export time.
Perhaps ("offload" changed to "prevent"):
The mean (average) path delay can be calculated by dividing the
pathDelaySumDeltaMicroseconds(533) by the packetDeltaCount(2) at the
IPFIX data collection in order to prevent the IPFIX Exporter from
calculating the mean for every Flow at export time.
-->
<section anchor="OpsMeanDelay" title="Mean Delay">
<t>The mean (average) path delay can be calculated by dividing <t>The mean (average) path delay can be calculated by dividing
the pathDelaySumDeltaMicroseconds(TBD8) by the the pathDelaySumDeltaMicroseconds(533) by the
packetDeltaCount(2) at the IPFIX data collection in order to packetDeltaCount(2) at the IPFIX data collection in order to
offload the IPFIX Exporter from calculating the m ean for every offload the IPFIX Exporter from calculating the m ean for every
Flow at export time.</t> Flow at export time.</t>
</section> </section>
<section anchor="OpsReducedSizeEncoding" numbered="true" toc="default">
<name>Reduced-Size Encoding</name>
<!--[rfced] We suggest changing "being accounted" to "being counted" here.
Please review the intended meaning.
<section anchor="OpsReducedSizeEncoding" title="Reduced-size Original:
encoding"> Unsigned64 has been chosen as type for pathDelaySumDeltaMicroseconds
<t>Unsigned64 has been chosen as type for to support cases with large delay numbers and where many packets are
being accounted.
Perhaps:
Unsigned64 has been chosen as type for pathDelaySumDeltaMicroseconds
to support cases with large delay numbers and where many packets are
being counted.
-->
<t>Unsigned64 has been chosen as the type for
pathDelaySumDeltaMicroseconds to support cases with large delay pathDelaySumDeltaMicroseconds to support cases with large delay
numbers and where many packets are being accounted. As an numbers and where many packets are being accounted. As an
example, a specific Flow Record with path delay o f 100 example, a specific Flow Record with path delay o f 100
milliseconds cannot observe more than 42949 packe ts without milliseconds cannot observe more than 42949 packe ts without
overflowing the unsigned32 counter. The procedure described in overflowing the unsigned32 counter. The procedure described in
<xref section="6.2" sectionFormat="of" target="RF C7011"/> may be <xref section="6.2" sectionFormat="of" target="RF C7011" format="default"/> may be
applied to reduce network bandwidth between the I PFIX Exporter applied to reduce network bandwidth between the I PFIX Exporter
and Collector if unsigned32 would be large enough without and Collector if unsigned32 would be large enough without
wrapping around.</t> wrapping around.</t>
</section> </section>
<section anchor="MeasurementInterval" numbered="true" toc="default">
<section anchor="MeasurementInterval" <name>Measurement Interval</name>
title="Measurement Interval"> <t>The delay metrics are computed for the Flow Record lifetime
<t>The delay metrics are computed for the Flow Record life time
by comparing the OAM timestamps in each received packet with by comparing the OAM timestamps in each received packet with
the timestamp when they were received. For long- running Flow, the timestamp when they were received. For a lon g-running Flow,
the IPFIX Metering Process might miss the tempor al distribution the IPFIX Metering Process might miss the tempor al distribution
of the delay (for example, a longer delay only a t the beginning of the delay (for example, a longer delay only a t the beginning
of Flow). If this is an operational problem, the IPFIX Metering of the Flow). If this is an operational problem, the IPFIX Metering
Process might be configured with a smaller expir ation timeout Process might be configured with a smaller expir ation timeout
(see Section 5.1.1. Flow Expiration <xref target (see "Flow Expiration", <xref section="5.1.1" se
="RFC5470"/>). ctionFormat="of" target="RFC5470"/>).
</t> </t>
</section> </section>
<section anchor="OpsIoamApplication" numbered="true" toc="default">
<section anchor="OpsIoamApplication" title="In-Packet <name>In-Packet OAM Application</name>
OAM Application">
<t>Multiple methods can be used to compute the delay performance <t>Multiple methods can be used to compute the delay performance
metrics defined in this document. Some examples of such methods metrics defined in this document. Some examples of such methods
are IOAM <xref target="RFC9197"/> and Enhanced Al are IOAM <xref target="RFC9197" format="default"/
ternate Marking > and Enhanced Alternate Marking
<xref target="I-D.zhou-ippm-enhanced-alternate-ma <xref target="I-D.zhou-ippm-enhanced-alternate-ma
rking"/>.</t> rking" format="default"/>.</t>
<t>For IOAM, these performance metrics can be computed using the <t>For IOAM, these performance metrics can be computed using the
Edge-to-Edge and the Direct Exporting Option-Type.</t> Edge-to-Edge and the Direct Exporting Option-Type.</t>
<t>IOAM Edge-to-Edge Option-Type, as described in <xref section="4.6" se
<t>IOAM Edge-to-Edge Option-Type, as described in <xref ctionFormat="of" target="RFC9197" format="default"/>, can use
section="4.6" sectionFormat="of" target="RFC9197"
/>, can use
bits 2 and 3. In this case, timestamps are encode d as defined in bits 2 and 3. In this case, timestamps are encode d as defined in
Sections 4.4.2.3 and 4.4.2.4 of <xref target="RFC 9197"/>. This Sections <xref target="RFC9197" sectionFormat="ba re" section="4.4.2.3"/> and <xref target="RFC9197" sectionFormat="bare" section= "4.4.2.4"/> of <xref target="RFC9197" format="default"/>. This
timestamp can be used to compute the delay betwee n an timestamp can be used to compute the delay betwee n an
OAM header encapsulating node and the decapsulati ng node.</t> OAM header encapsulating node and the decapsulati ng node.</t>
<t>The IOAM Direct Exporting Option-Type, as described in <xref target="
<t>IOAM Direct Exporting Option-Type, as described in <xref RFC9326" format="default"/>, can use the Extension-Flag defined in <xref target=
target="RFC9326"/>, can use the Extension-Flag defined in <xref "I-D.ahuang-ippm-dex-timestamp-ext" format="default"/> to insert a
target="I-D.ahuang-ippm-dex-timestamp-ext"/> to insert a
timestamp in the OAM header encapsulating node. T he timestamp is timestamp in the OAM header encapsulating node. T he timestamp is
encoded as defined in Sections 4.4.2.3 and 4.4.2. encoded as defined in Sections <xref target="RFC9
4 of <xref 197" sectionFormat="bare" section="4.4.2.3"/> and <xref target="RFC9197" section
target="RFC9197"/>. This timestamp can be used to Format="bare" section="4.4.2.4"/> of <xref target="RFC9197" format="default"/>.
compute the This timestamp can be used to compute the
delay between the inserted timestamp and the OAM header transit delay between the inserted timestamp and the OAM header transit
and decapsulating node.</t> and decapsulating node.</t>
<!--[rfced] Should "node" be plural "nodes"? In other words, is this about
both an intermediate node and decapsulating node?
Also, is it accurate that "on-path delay" should be "On-Path delay" as it is
elsewhere in this document?
<t>For the Enhanced Alternate Marking Method, <xref section="2" Original:
sectionFormat="of" [...] and be read at the OAM header intermediate and decapsulating
target="I-D.zhou-ippm-enhanced-alternate-marking" node to calculate the on-path delay.
/> and <xref
section="3.2" sectionFormat="of" Perhaps:
target="I-D.fz-spring-srv6-alt-mark"/> defines th [...] and be read at the OAM header intermediate and decapsulating
at, within the nodes to calculate the On-Path delay.
-->
<t>For the Enhanced Alternate Marking Method, <xref section="2" sectionF
ormat="of" target="I-D.zhou-ippm-enhanced-alternate-marking" format="default"/>
and <xref section="3.2" sectionFormat="of" target="RFC9947"/> define that, withi
n the
metaInfo, a nanosecond timestamp can be encoded i n an metaInfo, a nanosecond timestamp can be encoded i n an
OAM header encapsulating node and be read at the OAM header OAM header encapsulating node and be read at the OAM header
intermediate and decapsulating node to calculate the on-path intermediate and decapsulating node to calculate the on-path
delay. <xref target="RFC9343"/> defines how this delay. <xref target="RFC9343" format="default"/>
can be applied defines how this can be applied
to the IPv6 extensions header and <xref to the IPv6 extensions header, and <xref target="
target="I-D.fz-spring-srv6-alt-mark"/> defines ho RFC9947" format="default"/> defines how this can be
w this can be applied to the SRv6 Segment Routing Header <xref
applied to the SRv6 Segment Routing Header <xref target="RFC8754" format="default"/>.</t>
target="RFC8754"/>.</t>
<t>Given that the delay measurements are computed with the <t>Given that the delay measurements are computed with the
timestamp introduced on the OAM header encapsulat ing node, timestamp introduced on the OAM header encapsulat ing node,
regardless of the approach, implementations shoul d document at regardless of the approach, implementations shoul d document at
which point of the forwarding plane this timestam p is introduced which point of the forwarding plane this timestam p is introduced
(e.g. the time at which the packet was received b y the node, the (e.g., the time at which the packet was received by the node, the
time at which the packet was transmitted by the n ode, etc.). time at which the packet was transmitted by the n ode, etc.).
Based on this information, different actions can be taken. Based on this information, different actions can be taken.
</t> </t>
</section> </section>
</section> </section>
<section anchor="Security" numbered="true" toc="default">
<section anchor="Security" title="Security Considerations"> <name>Security Considerations</name>
<t>The IPFIX Information Elements introduced in this document do <t>The IPFIX Information Elements introduced in this document do
not directly introduce security issues. Rather, they defi ne a set not directly introduce security issues. Rather, they defi ne a set
of performance metrics that may, for privacy or business issues, of performance metrics that may, for privacy or business issues,
be considered sensitive information.</t> be considered sensitive information.</t>
<!--[rfced] Is the intended meaning that attacks by the receiver
may be possible? If so, we suggest changing "for" to "by" or
rephrasing otherwise.
Original:
For example, exporting delay metrics may make attacks possible for
the receiver of this information; ...
Perhaps:
For example, exporting delay metrics may make attacks possible by
the receiver of this information; ...
-->
<t>For example, exporting delay metrics may make attacks possible <t>For example, exporting delay metrics may make attacks possible
for the receiver of this information; this would otherwis e only be for the receiver of this information; otherwise, this wou ld only be
possible for direct observers of the reported Flows along the data possible for direct observers of the reported Flows along the data
path.</t> path.</t>
<t>IPFIX collectors <bcp14>MUST</bcp14> ensure that IPFIX data originates
<t>IPFIX collectors MUST ensure that IPFIX data originates from from
trusted sources. Accepting IPFIX data from unauthenticate d sources trusted sources. Accepting IPFIX data from unauthenticate d sources
could lead to data spoofing, policy misapplication, or de nial of could lead to data spoofing, policy misapplication, or de nial of
service.</t> service.</t>
<t>Therefore, the underlying protocol used to exchange the information
<t>The underlying protocol used to exchange the information described here must apply appropriate procedures to
described here must therefore apply appropriate procedure
s to
guarantee the integrity and confidentiality of the export ed guarantee the integrity and confidentiality of the export ed
information. These protocols are defined in separate docu information. These protocols are defined in separate docu
ments, ments;
specifically the IPFIX security considerations <xref sect specifically, see the IPFIX security considerations in <x
ion="11" ref section="11" sectionFormat="of" target="RFC7011" format="default"/>. Impleme
sectionFormat="of" target="RFC7011"/>. Implementations SH ntations <bcp14>SHOULD</bcp14> also
OULD also refer to <xref target="BCP195" format="default"/> for add
refer to <xref target="BCP195"/> for additional details.< itional details.</t>
/t>
</section>
<section anchor="Implementation" title="Implementation Status">
<t>Note to the RFC-Editor: Please remove this section before
publishing.</t>
<section anchor="VPP" title="FD.io VPP">
<t>INSA Lyon implemented the following IEs as part of a
prototype in the FD.io VPP (Vector Packet Process
ing) platform:
</t>
<t><list style="symbols">
<t>pathDelayMeanDeltaMicroseconds</t>
<t>pathDelayMaxDeltaMicroseconds</t>
<t>pathDelayMinDeltaMicroseconds</t>
<t>pathDelaySumDeltaMicroseconds</t>
</list></t>
<t>The open source code can be obtained here: <xref
target="INSA-Lyon-VPP"/> and was validated at the IETF 116
hackathon.</t>
</section>
<section anchor="Huawei" title="Huawei VRP">
<t>Huawei implemented the following IEs as part of a production
implementation in the VRP platform:</t>
<t><list style="symbols">
<t>pathDelayMeanDeltaMicroseconds</t>
<t>pathDelayMaxDeltaMicroseconds</t>
<t>pathDelayMinDeltaMicroseconds</t>
<t>pathDelaySumDeltaMicroseconds</t>
</list></t>
<t>The implementation was validated at the IETF 116 hackathon.
</t>
</section>
<section anchor="Fluvia" title="Fluvia">
<t>NTT Com implemented the following IEs in the Fluvia Exporter:
</t>
<t><list style="symbols">
<t>pathDelayMeanDeltaMicroseconds</t>
<t>pathDelayMaxDeltaMicroseconds</t>
<t>pathDelayMinDeltaMicroseconds</t>
<t>pathDelaySumDeltaMicroseconds</t>
</list></t>
<t>The open source code can be obtained here: <xref
target="NTT-Fluvia"/> and was validated at the IETF 118
hackathon.</t>
</section>
<section anchor="pmacct" title="Pmacct Data Collection">
<t>Paolo Lucente implemented the IE
pathDelayMeanDeltaMicroseconds by dividing IE
pathDelaySumDeltaMicroseconds by IE packetDeltaCo
unt in the open
source Network Telemetry data collection project
pmacct.</t>
<t>The source code can be obtained here: <xref
target="Paolo-Lucente-Pmacct"/> and was validated at the IETF
116 hackathon.</t>
</section>
</section> </section>
<section anchor="Acknowledgements" title="Acknowledgements">
<t>The authors would like to thank Al Morton (Rest in Peace, Al),
Justin Iurman, Giuseppe Fioccola, Yannick Buchs, Menachem
Dodge
Martin Duke, Behcet Sarikaya, Mahesh Jethanandani, Linda
Dunbar,
Deb Cooley, Mike Bishop, Tim Wicinski, Gunter Van de Veld
e and
Éric Vyncke's for their review and valuable comments. Special
thanks to Paul Aitken (as IPFIX Designated Expert), Greg Mirsky
(as IP Performance Metrics Designated Expert), and to Med Boucadair
for their very detailed feedback.</t>
</section>
</middle> </middle>
<back> <back>
<references title="Normative References"> <displayreference target="I-D.zhou-ippm-enhanced-alternate-marking" to="ENH-
<?rfc include='https://xml.resource.org/public/rfc/bibxml/reference.RFC.21 ALT-MARKING"/>
19.xml'?> <displayreference target="I-D.ahuang-ippm-dex-timestamp-ext" to="IOAM-DEX"/>
<displayreference target="I-D.ietf-opsawg-ipfix-alt-mark" to="IPFIX-ALT-MARK
<?rfc include='https://xml.resource.org/public/rfc/bibxml/reference.RFC.33 "/>
39.xml'?> <references>
<name>References</name>
<?rfc include='https://xml.resource.org/public/rfc/bibxml/reference.RFC.59 <references anchor="norm_ref">
05.xml'?> <name>Normative References</name>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.2
<?rfc include='https://xml.resource.org/public/rfc/bibxml/reference.RFC.60 119.xml"/>
49.xml'?> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.3
339.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.5
905.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.6
049.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.7
011.xml"/>
<!-- [rfced] [RFC7012] is not cited in the text. Please let us know
where it should be cited; otherwise it will be deleted from the
references section.
<?rfc include='https://xml.resource.org/public/rfc/bibxml/reference.RFC.70 [RFC7012] Claise, B., Ed. and B. Trammell, Ed., "Information Model for
11.xml'?> IP Flow Information Export (IPFIX)", RFC 7012, DOI 10.17487/RFC7012,
September 2013, <https://www.rfc-editor.org/info/rfc7012>.
-->
<?rfc include='https://xml.resource.org/public/rfc/bibxml/reference.RFC.70 <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.7
12.xml'?> 012.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.7
323.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.7
679.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8
174.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8
911.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8
912.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml9/reference.BCP.
195.xml"/>
</references>
<references>
<name>Informative References</name>
<reference anchor="IANA-PERF-METRIC" target="https://www.iana.org/assign
ments/performance-metrics">
<front>
<title>Performance Metrics</title>
<author>
<organization>IANA</organization>
</author>
<date/>
</front>
</reference>
<reference anchor="IANA-IPFIX" target="https://www.iana.org/assignments/
ipfix">
<front>
<title>IP Flow Information Export (IPFIX) Entities</title>
<author>
<organization>IANA</organization>
</author>
<date/>
</front>
</reference>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.1
997.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.2
330.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.3
393.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.5
153.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.5
470.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.6
020.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.6
703.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.7
015.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.7
799.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8
754.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9
197.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9
232.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9
326.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9
343.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9
911.xml"/>
<?rfc include='https://xml.resource.org/public/rfc/bibxml/reference.RFC.73 <!-- [I-D.ietf-opsawg-ipfix-alt-mark]
23.xml'?> draft-ietf-opsawg-ipfix-alt-mark-04
IESG State: I-D Exists as of 3/30/26
-->
<xi:include href="https://bib.ietf.org/public/rfc/bibxml3/reference.I-D.
ietf-opsawg-ipfix-alt-mark.xml"/>
<?rfc include='https://xml.resource.org/public/rfc/bibxml/reference.RFC.76 <!-- [I-D.zhou-ippm-enhanced-alternate-marking]
79.xml'?> draft-zhou-ippm-enhanced-alternate-marking-18
IESG State: I-D Exists as of 3/30/26
-->
<reference anchor="I-D.zhou-ippm-enhanced-alternate-marking" target="https://dat
atracker.ietf.org/doc/html/draft-zhou-ippm-enhanced-alternate-marking-18">
<front>
<title>Enhanced Alternate Marking Method</title>
<author initials="T." surname="Zhou" fullname="Tianran Zhou" role="editor"
>
<organization>Huawei</organization>
</author>
<author initials="G." surname="Fioccola" fullname="Giuseppe Fioccola">
<organization>Huawei</organization>
</author>
<author initials="Y." surname="Liu" fullname="Yisong Liu">
<organization>China Mobile</organization>
</author>
<author initials="M." surname="Cociglio" fullname="Mauro Cociglio">
<organization>Telecom Italia</organization>
</author>
<author initials="R." surname="Pang" fullname="Ran Pang">
<organization>China Unicom</organization>
</author>
<author initials="L." surname="Xiong" fullname="Lixia Xiong">
<organization>CITC</organization>
</author>
<author initials="S." surname="Lee" fullname="Shinyoung Lee">
</author>
<author initials="W." surname="Li" fullname="Weidong Li">
<organization>Huawei</organization>
</author>
<date month="December" day="5" year="2025" />
</front>
<seriesInfo name="Internet-Draft" value="draft-zhou-ippm-enhanced-alternate-m
arking-18" />
<?rfc include='https://xml.resource.org/public/rfc/bibxml/reference.RFC.81 74.xml'?> </reference>
<?rfc include='https://xml.resource.org/public/rfc/bibxml/reference.RFC.89 <!--draft-fz-spring-srv6-alt-mark in AUTH48-DONE as 9947 as of 3/30/26 -->
11.xml'?> <reference anchor="RFC9947" target="https://www.rfc-editor.org/info/rfc9947">
<front>
<title>Application of the Alternate-Marking Method to the Segment Routing
Header</title>
<author initials="G." surname="Fioccola" fullname="Giuseppe Fioccola">
<organization>Huawei</organization>
</author>
<author initials="T." surname="Zhou" fullname="Tianran Zhou">
<organization>Huawei</organization>
</author>
<author initials="G." surname="Mishra" fullname="Gyan Mishra">
<organization>Verizon Inc.</organization>
</author>
<author initials="X." surname="Wang" fullname="Xuewei Wang">
<organization>Ruijie</organization>
</author>
<author initials="G." surname="Zhang" fullname="Geng Zhang">
<organization>China Mobile</organization>
</author>
<author initials="M." surname="Cociglio" fullname="Mauro Cociglio">
</author>
<date month="March" year="2026" />
</front>
<seriesInfo name="RFC" value="9947" />
</reference>
<?rfc include='https://xml.resource.org/public/rfc/bibxml/reference.RFC.89 <!-- draft-ahuang-ippm-dex-timestamp-ext-00
12.xml'?> IESG State: Expired
inserted full reference in order to fix author name (A. Huang-Feng)
-->
<reference anchor="I-D.ahuang-ippm-dex-timestamp-ext" target="https://datatracke
r.ietf.org/doc/html/draft-ahuang-ippm-dex-timestamp-ext-00">
<front>
<title>Timestamp extension for In Situ Operations, Administration, and Maint
enance (IOAM) Direct Export</title>
<author fullname="Alex Huang Feng" initials="A." surname="Huang Feng">
<organization>INSA-Lyon</organization>
</author>
<author fullname="Pierre Francois" initials="P." surname="Francois">
<organization>INSA-Lyon</organization>
</author>
<author fullname="Benoît Claise" initials="B." surname="Claise">
<organization>Huawei</organization>
</author>
<author fullname="Thomas Graf" initials="T." surname="Graf">
<organization>Swisscom</organization>
</author>
<date day="15" month="February" year="2023"/>
<abstract>
<t>This document extends the In Situ Operations, Administration, and Maint
enance (IOAM) Direct Export option type to support timestamping by adding and de
fining two optional timestamp fields and corresponding flags.</t>
</abstract>
</front>
<seriesInfo name="Internet-Draft" value="draft-ahuang-ippm-dex-timestamp-ext-0
0"/>
</reference>
<?rfc include="https://bib.ietf.org/public/rfc/bibxml9/reference.BCP.0195. xml"?> </references>
</references> </references>
<section anchor="Encoding-Example" numbered="true" toc="default">
<name>IPFIX Encoding Examples</name>
<!-- [rfced] FYI, this sentence has been updated to remove the pointer
to Section 1. Rationale: Figure 1 is specific enough for the reader to
find the information. And it's in Section 3, not Section 1.
<references title="Informative References"> Original:
<reference anchor="IANA-PERF-METRIC" Taking Figure 1 from Section 1 as topology example.
target="https://www.iana.org/assignments/performance-metrics/pe
rformance-metrics.xhtml">
<front>
<title>IANA Performance Metric Registry</title>
<author/>
<date/>
</front>
</reference>
<reference anchor="IANA-IPFIX"
target="https://www.iana.org/assignments/ipfix/ipfix.xhtml">
<front>
<title>IANA IP Flow Information Export (IPFIX) Entities
Registry</title>
<author/>
<date/>
</front>
</reference>
<?rfc include='https://xml.resource.org/public/rfc/bibxml/reference.RFC.19
97.xml'?>
<?rfc include='https://xml.resource.org/public/rfc/bibxml/reference.RFC.23
30.xml'?>
<?rfc include='https://xml.resource.org/public/rfc/bibxml/reference.RFC.33
93.xml'?>
<?rfc include='https://xml.resource.org/public/rfc/bibxml/reference.RFC.51
53.xml'?>
<?rfc include='https://xml.resource.org/public/rfc/bibxml/reference.RFC.54
70.xml'?>
<?rfc include='https://xml.resource.org/public/rfc/bibxml/reference.RFC.60
20.xml'?>
<?rfc include='https://xml.resource.org/public/rfc/bibxml/reference.RFC.67
03.xml'?>
<?rfc include='https://xml.resource.org/public/rfc/bibxml/reference.RFC.69
91.xml'?>
<?rfc include='https://xml.resource.org/public/rfc/bibxml/reference.RFC.70
15.xml'?>
<?rfc include='https://xml.resource.org/public/rfc/bibxml/reference.RFC.77
99.xml'?>
<?rfc include='https://xml.resource.org/public/rfc/bibxml/reference.RFC.87
54.xml'?>
<?rfc include='https://xml.resource.org/public/rfc/bibxml/reference.RFC.91
97.xml'?>
<?rfc include='https://xml.resource.org/public/rfc/bibxml/reference.RFC.92
32.xml'?>
<?rfc include='https://xml.resource.org/public/rfc/bibxml/reference.RFC.93
26.xml'?>
<?rfc include='https://xml.resource.org/public/rfc/bibxml/reference.RFC.93
43.xml'?>
<?rfc include='https://bib.ietf.org/public/rfc/bibxml-ids/reference.I-D.ie
tf-opsawg-ipfix-alt-mark.xml'?>
<?rfc include='https://bib.ietf.org/public/rfc/bibxml-ids/reference.I-D.zh
ou-ippm-enhanced-alternate-marking.xml'?>
<?rfc include='https://bib.ietf.org/public/rfc/bibxml-ids/reference.I-D.fz
-spring-srv6-alt-mark.xml'?>
<?rfc include='https://bib.ietf.org/public/rfc/bibxml-ids/reference.I-D.ah
uang-ippm-dex-timestamp-ext.xml'?>
<reference anchor="INSA-Lyon-VPP"
target="https://github.com/network-analytics/vpp-srh-onpath-tel
emetry">
<front>
<title>INSA Lyon, FD.io VPP implementation</title>
<author/>
<date/>
</front>
</reference>
<reference anchor="NTT-Fluvia"
target="https://github.com/nttcom/fluvia/">
<front>
<title>NTT Com, Fluvia Exporter</title>
<author/>
<date/>
</front>
</reference>
<reference anchor="Paolo-Lucente-Pmacct"
target="https://github.com/pmacct/pmacct">
<front>
<title>Paolo Lucente, Pmacct open source Network Telemetry
Data Collection</title>
<author/>
<date/>
</front>
</reference>
</references>
<section anchor="Encoding-Example" title="IPFIX Encoding Examples"> Current:
Let's take Figure 1 as a topology example.
-->
<t>This appendix represents two different encodings for the newly <t>This appendix represents two different encodings for the newly
introduced IEs. Taking Figure 1 from Section 1 as topology example. introduced IEs. Let's take <xref target="topology"/> as a topology example
Below example Table 4 shows the aggregated delay with ingressInterface, .
egressInterface, destinationIPv6Address and srhActiveSegmentIPv6.</t> <xref target="tab-4"/> shows the aggregated delay with ingressInterface,
egressInterface, destinationIPv6Address, and srhActiveSegmentIPv6.</t>
<t><figure> <!--[rfced] For Table 4, is it correct that the column headers
<artwork><![CDATA[ are intended as the names of the IEs? If so, we recommend
+------ +------+-----------+-----------+------+-------+-------+-------+ rotating the table (so the column headers become the first column) as shown
|ingress|egress|destination|srhActive |packet|path |path |path | in the edited document. Please review and let us know any updates,
|Inter |Inter |IPv6Address|SegmentIPv6|Delta |Delay |Delay |Delay | or if you want to revert to the previous format. (We note that Table 2
|face |face | | |Count |Mean |Min |Max | also adds spaces into IE names, perhaps in order get line breaks within
| | | | | |Delta |Delta |Delta | the cell; please let us know if you'd like to make any updates to Table 2.)
| | | | | |Micro..|Micro..|Micro..|
+-------+------+-----------+-----------+------+-------+-------+-------+
| 271 | 276 |2001:db8::3|2001:db8::2| 5 | 36 µs | 22 µs | 74 µs |
+-------+------+-----------+-----------+------+-------+-------+-------+
Table 4: Aggregated delay with egressInterface and srhActiveSegmentIPv6 Original (column headers):
]]></artwork> path Delay Mean Delta Micro..
</figure></t> path Delay Min Delta Micro..
path Delay Max Delta Micro..
<section anchor="Aggregated-OnPath-Delay-Examples" Perhaps intended as the IE names:
title="Aggregated On-Path Delay Examples"> pathDelayMeanDeltaMicroseconds
<section anchor="Template-Record-and-Data-Set-with-MeanDelta" pathDelayMinDeltaMicroseconds
title="Template Record and Data Set with Mean Delta"> pathDelayMaxDeltaMicroseconds
<t>With encoding in Figure 2, the mean (average) path delay is -->
calculated on the exporting node.</t> <table anchor="tab-4">
<name>Aggregated Delay with egressInterface and srhActiveSegmentIPv6</name>
<tbody>
<tr>
<td>ingressInterface</td>
<td>271</td>
</tr>
<tr>
<td>egressInterface</td>
<td>276</td>
</tr>
<tr>
<td>destinationIPv6Address</td>
<td>2001:db8::3</td>
</tr>
<tr>
<td>srhActiveSegmentIPv6</td>
<td>2001:db8::2</td>
</tr>
<tr>
<td>packetDeltaCount</td>
<td>5</td>
</tr>
<tr>
<td>pathDelayMeanDeltaMicroseconds</td>
<td>36 µs</td>
</tr>
<tr>
<td>pathDelayMinDeltaMicroseconds</td>
<td>22 µs</td>
</tr>
<tr>
<td>pathDelayMaxDeltaMicroseconds</td>
<td>74 µs</td>
</tr>
</tbody>
</table>
<t><list style="symbols"> <section anchor="Aggregated-OnPath-Delay-Examples" numbered="true" toc="de
fault">
<name>Aggregated On-Path Delay Examples</name>
<section anchor="Template-Record-and-Data-Set-with-MeanDelta" numbered="
true" toc="default">
<name>Template Record and Data Set with Mean Delta</name>
<t>With encoding in <xref target="fig-2"/>, the mean (average) path de
lay is
calculated on the exporting node.</t>
<ul spacing="normal">
<li>
<t>Ingress interface =&gt; ingressInterface</t> <t>Ingress interface =&gt; ingressInterface</t>
</li>
<li>
<t>Egress interface =&gt; egressInterface</t> <t>Egress interface =&gt; egressInterface</t>
</li>
<li>
<t>IPv6 destination address =&gt; destinationIPv6Address <t>IPv6 destination address =&gt; destinationIPv6Address
</t> </t>
</li>
<li>
<t>Active SRv6 Segment =&gt; srhActiveSegmentIPv6</t> <t>Active SRv6 Segment =&gt; srhActiveSegmentIPv6</t>
</li>
<li>
<t>Packet Delta Count =&gt; packetDeltaCount</t> <t>Packet Delta Count =&gt; packetDeltaCount</t>
</li>
<li>
<t>Minimum One-Way Delay =&gt; <t>Minimum One-Way Delay =&gt;
pathDelayMinDeltaMicrosec pathDelayMinDeltaMicrosec
onds (TBD6)</t> onds (531)</t>
</li>
<li>
<t>Maximum One-Way Delay =&gt; <t>Maximum One-Way Delay =&gt;
pathDelayMaxDeltaMicrosec pathDelayMaxDeltaMicrosec
onds (TBD7)</t> onds (532)</t>
</li>
<li>
<t>Mean One-Way Delay =&gt; pathDelayMeanDeltaMicroseconds <t>Mean One-Way Delay =&gt; pathDelayMeanDeltaMicroseconds
(TBD5)</t> (530)</t>
</list></t> </li>
</ul>
<figure title="Template Record for pathDelayMeanDeltaMicroseconds."> <figure anchor="fig-2">
<artwork><![CDATA[ <name>Template Record for pathDelayMeanDeltaMicroseconds</name>
0 1 2 3 <artwork name="" type="" align="left" alt=""><![CDATA[
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
| SET ID = 2 | Length = 40 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | SET ID = 2 | Length = 40 |
| Template ID = 256 | Field Count = 8 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Template ID = 256 | Field Count = 8 |
|0| ingressInterface = 10 | Field Length = 4 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |0| ingressInterface = 10 | Field Length = 4 |
|0| egressInterface = 14 | Field Length = 4 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |0| egressInterface = 14 | Field Length = 4 |
|0| destinationIPv6Address = 28 | Field Length = 16 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |0| destinationIPv6Address = 28 | Field Length = 16 |
|0| srhActiveSegmentIPv6 = 495 | Field Length = 16 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |0| srhActiveSegmentIPv6 = 495 | Field Length = 16 |
|0| packetDeltaCount = 5 | Field Length = 4 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |0| packetDeltaCount = 5 | Field Length = 4 |
|0| pathDelayMeanDelta.. = TBD5 | Field Length = 4 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |0| pathDelayMeanDelta.. = 530 | Field Length = 4 |
|0| pathDelayMinDelta.. = TBD6 | Field Length = 4 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |0| pathDelayMinDelta.. = 531 | Field Length = 4 |
|0| pathDelayMaxDelta.. = TBD7 | Field Length = 4 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |0| pathDelayMaxDelta.. = 532 | Field Length = 4 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
]]></artwork> ]]></artwork>
</figure> -+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
</figure>
<t>The data set is represented as follows:</t> <t>The data set is represented as follows:</t>
<figure anchor="fig-3">
<figure title="Data Set Encoding for pathDelayMeanDeltaMicroseconds."> <name>Data Set Encoding for pathDelayMeanDeltaMicroseconds</name>
<artwork><![CDATA[ <artwork name="" type="" align="left" alt=""><![CDATA[
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SET ID = 256 | Length = 60 | | SET ID = 256 | Length = 60 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ingressInterface = 271 | | ingressInterface = 271 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| egressInterface = 276 | | egressInterface = 276 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| destinationIPv6Address = | | destinationIPv6Address = |
| ... | | ... |
| ... | | ... |
| 2001:db8::2 | | 2001:db8::2 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| srhActiveSegmentIPv6 = ... | | srhActiveSegmentIPv6 = ... |
| ... | | ... |
| ... | | ... |
| 2001:db8::3 | | 2001:db8::3 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| packetDeltaCount = 5 | | packetDeltaCount = 5 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| pathDelayMeanDeltaMicroseconds = 36 | | pathDelayMeanDeltaMicroseconds = 36 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| pathDelayMinDeltaMicroseconds = 22 | | pathDelayMinDeltaMicroseconds = 22 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| pathDelayMaxDeltaMicroseconds = 74 | | pathDelayMaxDeltaMicroseconds = 74 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
]]></artwork> ]]></artwork>
</figure> </figure>
</section> </section>
<section anchor="Template-Record-and-Data-Set-with-SumDelta" numbered="t
<section anchor="Template-Record-and-Data-Set-with-SumDelta" rue" toc="default">
title="Template Record and Data Set with Sum Delta"> <name>Template Record and Data Set with Sum Delta</name>
<t>With encoding in <xref target="template-sum"/>, the mean (average) <t>With encoding in <xref target="template-sum" format="default"/>, th
path delay is e mean (average) path delay is
calculated on the IPFIX data collection.</t> calculated on the IPFIX data collection.</t>
<ul spacing="normal">
<t><list style="symbols"> <li>
<t>Ingress interface =&gt; ingressInterface</t> <t>Ingress interface =&gt; ingressInterface</t>
</li>
<li>
<t>Egress interface =&gt; egressInterface</t> <t>Egress interface =&gt; egressInterface</t>
</li>
<li>
<t>IPv6 destination address =&gt; destinationIPv6Address <t>IPv6 destination address =&gt; destinationIPv6Address
</t> </t>
</li>
<li>
<t>Active SRv6 Segment =&gt; srhActiveSegmentIPv6</t> <t>Active SRv6 Segment =&gt; srhActiveSegmentIPv6</t>
</li>
<li>
<t>Packet Delta Count =&gt; packetDeltaCount</t> <t>Packet Delta Count =&gt; packetDeltaCount</t>
</li>
<li>
<t>Minimum One-Way Delay =&gt; <t>Minimum One-Way Delay =&gt;
pathDelayMinDeltaMicrosec pathDelayMinDeltaMicrosec
onds (TBD6)</t> onds (531)</t>
</li>
<li>
<t>Maximum One-Way Delay =&gt; <t>Maximum One-Way Delay =&gt;
pathDelayMaxDeltaMicrosec pathDelayMaxDeltaMicrosec
onds (TBD7)</t> onds (532)</t>
</li>
<li>
<t>Sum of One-Way Delay =&gt; <t>Sum of One-Way Delay =&gt;
pathDelaySumDeltaMicrosec pathDelaySumDeltaMicrosec
onds (TBD8)</t> onds (533)</t>
</list></t> </li>
</ul>
<figure anchor="template-sum" title="Template Record for pathDelaySumD <figure anchor="template-sum">
eltaMicroseconds."> <name>Template Record for pathDelaySumDeltaMicroseconds.</name>
<artwork><![CDATA[ <artwork name="" type="" align="left" alt=""><![CDATA[
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SET ID = 2 | Length = 40 | | SET ID = 2 | Length = 40 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Template ID = 257 | Field Count = 8 | | Template ID = 257 | Field Count = 8 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0| ingressInterface = 10 | Field Length = 4 | |0| ingressInterface = 10 | Field Length = 4 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0| egressInterface = 14 | Field Length = 4 | |0| egressInterface = 14 | Field Length = 4 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0| destinationIPv6Address = 28 | Field Length = 16 | |0| destinationIPv6Address = 28 | Field Length = 16 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0| srhActiveSegmentIPv6 = 495 | Field Length = 16 | |0| srhActiveSegmentIPv6 = 495 | Field Length = 16 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0| packetDeltaCount = 5 | Field Length = 4 | |0| packetDeltaCount = 5 | Field Length = 4 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0| pathDelayMinDelta.. = TBD6 | Field Length = 4 | |0| pathDelayMinDelta.. = 531 | Field Length = 4 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0| pathDelayMaxDelta.. = TBD7 | Field Length = 4 | |0| pathDelayMaxDelta.. = 532 | Field Length = 4 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0| pathDelaySumDelta.. = TBD8 | Field Length = 8 | |0| pathDelaySumDelta.. = 533 | Field Length = 8 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
]]></artwork> ]]></artwork>
</figure> </figure>
<t>The data set is represented as follows:</t> <t>The data set is represented as follows:</t>
<figure>
<figure title="Data Set Encoding for pathDelaySumDeltaMicroseconds"> <name>Data Set Encoding for pathDelaySumDeltaMicroseconds</name>
<artwork><![CDATA[ <artwork name="" type="" align="left" alt=""><![CDATA[
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SET ID = 257 | Length = 64 | | SET ID = 257 | Length = 64 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ingressInterface = 271 | | ingressInterface = 271 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| egressInterface = 276 | | egressInterface = 276 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| destinationIPv6Address = | | destinationIPv6Address = |
skipping to change at line 1639 skipping to change at line 1640
| pathDelayMaxDeltaMicroseconds = 74 | | pathDelayMaxDeltaMicroseconds = 74 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| pathDelaySumDeltaMicroseconds = 180 | | pathDelaySumDeltaMicroseconds = 180 |
| ... | | ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
]]></artwork> ]]></artwork>
</figure> </figure>
</section> </section>
</section> </section>
</section> </section>
<section anchor="Acknowledgements" numbered="false" toc="default">
<name>Acknowledgements</name>
<t>The authors would like to thank <contact fullname="Al Morton"/> (Rest
in Peace, Al), <contact fullname="Justin Iurman"/>, <contact
fullname="Giuseppe Fioccola"/>, <contact fullname="Yannick Buchs"/>,
<contact fullname="Menachem Dodge"/>, <contact fullname="Martin Duke"/>,
<contact fullname="Behcet Sarikaya"/>, <contact fullname="Mahesh
Jethanandani"/>, <contact fullname="Linda Dunbar"/>, <contact
fullname="Deb Cooley"/>, <contact fullname="Mike Bishop"/>, <contact
fullname="Tim Wicinski"/>, <contact fullname="Gunter Van de Velde"/>,
and <contact fullname="Éric Vyncke"/> for their review and valuable
comments. Special thanks to <contact fullname="Paul Aitken"/> (as IPFIX
Designated Expert), <contact fullname="Greg Mirsky"/> (as IP Performance
Metrics Designated Expert), and to <contact fullname="Med Boucadair"/>
for their very detailed feedback.</t>
</section>
<!--[rfced] Terminology: Please let us know if you would like this term
to appear consistently within this document; usage is currently mixed.
Flow Record (8 instances) vs. flow record (1 instance)
Singleton (2 instances) vs. singleton (5 instances)
-->
<!-- [rfced] Please review the "Inclusive Language" portion of the online
Style Guide <https://www.rfc-editor.org/styleguide/part2/#inclusive_language>
and let us know if any changes are needed. Updates of this nature typically
result in more precise language, which is helpful for readers.
Note that our script did not flag any words in particular, but this should
still be reviewed as a best practice.
-->
</back> </back>
</rfc> </rfc>
 End of changes. 284 change blocks. 
1293 lines changed or deleted 1304 lines changed or added

This html diff was produced by rfcdiff 1.48.