<?xmlversion="1.0" encoding="UTF-8"?>version='1.0' encoding='utf-8'?> <!DOCTYPE rfcSYSTEM "rfc2629.dtd"> <?rfc toc="yes"?> <?rfc tocompact="yes"?> <?rfc tocdepth="3"?> <?rfc tocindent="yes"?> <?rfc symrefs="yes"?> <?rfc sortrefs="yes"?> <?rfc comments="yes"?> <?rfc inline="yes"?> <?rfc compact="yes"?> <?rfc subcompact="no"?>[ <!ENTITY nbsp " "> <!ENTITY zwsp "​"> <!ENTITY nbhy "‑"> <!ENTITY wj "⁠"> ]> <rfc xmlns:xi="http://www.w3.org/2001/XInclude" category="std" docName="draft-ietf-opsawg-ipfix-on-path-telemetry-23" number="9951" ipr="trust200902"consensus="true">consensus="true" obsoletes="" updates="" submissionType="IETF" xml:lang="en" tocInclude="true" tocDepth="3" symRefs="true" sortRefs="true" version="3"> <front> <title abbrev="Delay Performance Metrics for IPFIX">Export of Delay Performance Metrics in IP Flow InformationeXportExport (IPFIX)</title> <seriesInfo name="RFC" value="9951"/> <author fullname="Thomas Graf" initials="T" surname="Graf"> <organization>Swisscom</organization> <address> <postal> <street>Binzring 17</street> <city>Zurich</city> <code>8045</code> <country>Switzerland</country> </postal> <email>thomas.graf@swisscom.com</email> </address> </author> <author fullname="Benoit Claise" initials="B" surname="Claise"> <organization>Huawei</organization> <address> <email>benoit@everything-ops.net</email> </address> </author> <author fullname="Alex Huang-Feng" initials="A" surname="Huang-Feng"> <organization>INSA-Lyon</organization> <address> <postal><street/><city>Lyon</city><region/> <code/><country>France</country> </postal><phone/> <facsimile/><email>alex.huang-feng@insa-lyon.fr</email><uri/></address> </author> <dateday="01" month="October" year="2025"/>month="March" year="2026"/> <area>OPS</area> <workgroup>opsawg</workgroup> <!-- [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> <t>This document specifies new IP Flow Information Export (IPFIX) Information Elements to export the On-Path delay at eachOAMOperations, Administration, and Maintenance (OAM) transit and decapsulating nodes. The On-Path delay is defined as the delay between the OAM header encapsulating node and each OAM header transit and OAM header decapsulating nodes. This delay measurement is computed by an On-Path Telemetry protocol and is exported by the IPFIX process. </t> </abstract> </front> <middle> <section anchor="Introduction"title="Introduction">numbered="true" toc="default"> <name>Introduction</name> <t>Network operators usually maintain statistical views of delayaccrossacross their networks to support diagnostics and performance analysis. These views assist in identifying the location, extent, and potential causes of abnormal delay affecting specific customer traffic or services. To achieve this, delay-related metrics need to be reported from devices covering both data and control planes. Further, in order to understand which customers are affected, delay-related metrics need to be reported in the context of the customerdata-plane.data plane. 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.</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 Telemetry protocol, which inserts metadata into the data-plane packet when entering the monitored domain <xreftarget="RFC9232"/>.target="RFC9232" format="default"/>. To compute delay measurements, the On-Path Telemetry protocol inserts a timestamp reference when entering the OAM encapsulating node.ImplementationsImplementation examples are InSitusitu Operations, Administration, and Maintenance (IOAM) <xreftarget="RFC9197"/>target="RFC9197" format="default"/> or Enhanced Alternate Marking <xreftarget="I-D.zhou-ippm-enhanced-alternate-marking"/>.</t>target="I-D.zhou-ippm-enhanced-alternate-marking" format="default"/>.</t> <t>Two modes of On-Path Telemetry are generally recognized: passport mode, in which only the OAM header decapsulating node of the OAM domain reports metrics; and postcard mode, in which OAM header transit nodes also export On-Path Telemetry data. Both modes enable exposure of per-hop performance metrics, including delay accumulation. The approach defined in this document is primarily applicable to postcard mode. </t> <t>To enable the export of the delay-related metrics via IPFIX <xreftarget="RFC7011"/>,target="RFC7011" format="default"/>, this document defines four new IPFIX Information Elements (IEs), exposing the On-Path delay on OAM header transit and decapsulating nodes, following the principles of postcardmode principles.</t>mode.</t> <t>This enables the computation of delay metrics (minimum, maximum, and mean) directly on the OAM header transit and decapsulating node, allowing aggregation within the Flow Record. </t> <t>As these IEs represent performance metrics, they are also registered in the <xreftarget="IANA-PERF-METRIC">target="IANA-PERF-METRIC" format="default"> IANA "PerformanceMetrics" registry</xref>Metrics Registry"</xref> in accordance with <xreftarget="RFC8911"/>.</t>target="RFC8911" format="default"/>.</t> </section> <section anchor="notation"title="Terminology"> <t>Thenumbered="true" toc="default"> <name>Terminology</name> <t> The key words"MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY","<bcp14>MUST</bcp14>", "<bcp14>MUST NOT</bcp14>", "<bcp14>REQUIRED</bcp14>", "<bcp14>SHALL</bcp14>", "<bcp14>SHALL NOT</bcp14>", "<bcp14>SHOULD</bcp14>", "<bcp14>SHOULD NOT</bcp14>", "<bcp14>RECOMMENDED</bcp14>", "<bcp14>NOT RECOMMENDED</bcp14>", "<bcp14>MAY</bcp14>", and"OPTIONAL""<bcp14>OPTIONAL</bcp14>" in this document are to be interpreted as described inBCP 14BCP 14 <xref target="RFC2119"/> <xref target="RFC8174"/> when, and only when, they appear in all capitals, as shownhere.</t>here. </t> <t>This document defines the following terms:</t><t><list style="symbols"> <t>OAM<dl spacing="normal" newline="true"> <dt>OAM Header EncapsulatingNode: ReceivesNode:</dt><dd>Receives the IP packets, encapsulates the packets with an OAMheaderheader, and adds the timestamp into the OAMheader.</t> <t>OAMheader.</dd> <dt>OAM Header TransitNode: ReceivesNode:</dt><dd>Receives the IP packets, then measures the delay between the timestamp in the packet and the timestamp when the packet wasreceived.</t> <t>OAMreceived.</dd> <dt>OAM Header DecapsulatingNode: ReceivesNode:</dt><dd>Receives the IP packets, computes the delay between the timestamp in the packet and the timestamp when the packet wasreceivedreceived, and removes the OAM header from thepacket.</t> </list></t>packet.</dd> </dl> <t>This document makes use of the terms defined in <xreftarget="RFC7011"/>,target="RFC7011" format="default"/>, <xreftarget="RFC8911"/>target="RFC8911" format="default"/> and <xreftarget="RFC7799"/>.</t>target="RFC7799" format="default"/>.</t> <t>The following terms are used as defined in <xreftarget="RFC7011"/>:</t> <t><list style="symbols">target="RFC7011" format="default"/>:</t> <ul spacing="normal"> <li> <t>Collector</t> </li> <li> <t>Exporter</t> </li> <li> <t>Flow</t> </li> <li> <t>Flow Record</t> </li> <li> <t>IPFIX</t> </li> <li> <t>IPFIX Information Elements (IEs)</t> </li> <li> <t>Observation Point</t></list></t></li> </ul> <t>The following terms are used as defined in <xreftarget="RFC8911"/>:</t> <t><list style="symbols">target="RFC8911" format="default"/>:</t> <ul spacing="normal"> <li> <t>Performance Metric</t> </li> <li> <t>Performance Metrics Registry</t> </li> <li> <t>Registered Performance Metric</t></list></t></li> </ul> <t>The following term is used as defined in <xref section="3.8" sectionFormat="of"target="RFC7799"/>:</t> <t><list style="symbols">target="RFC7799" format="default"/>:</t> <ul spacing="normal"> <li> <t>Hybrid Type I</t></list></t></li> </ul> </section> <section anchor="Solution"title="Solution">numbered="true" toc="default"> <name>Solution</name> <t>In line with the guidelines for Registered Performance MetricRequestersrequesters andReviewersreviewers <xreftarget="RFC8911"/>,target="RFC8911" format="default"/>, each metric is specified with its required characteristics (e.g., Identifier, Name, URI, Status, Requester, Revision, Description) to ensure comparability of measurement results across implementations and environments. These characteristics are registered in the <xreftarget="IANA-PERF-METRIC">IANAtarget="IANA-PERF-METRIC" format="default">IANA "PerformanceMetrics" registry</xref>.Metrics Registry"</xref>. Metric naming follows the "MetricType_Method_SubTypeMethod_... Spec_Units_Output" convention defined in <xref section="7.1.2" sectionFormat="of"target="RFC8911"/>.</t>target="RFC8911" format="default"/>.</t> <t>This document defines the following performance metrics and IPFIX Information Elements:</t><figure> <artwork><![CDATA[ +------------------------------------+-------------------------------+ | Performance Metric | IPFIX Information Element | +------------------------------------+-------------------------------+ |OWDelay_HybridType1_I |pathDelayMeanDeltaMicroseconds | |P_RFC[RFC-to-be]_Seconds_Mean (TBD1)|(TBD5) | +------------------------------------+-------------------------------+ |OWDelay_HybridType1_I |pathDelayMinDeltaMicroseconds | |P_RFC[RFC-to-be]_Seconds_Min (TBD2) |(TBD6) | +------------------------------------+-------------------------------+ |OWDelay_HybridType1_I |pathDelayMaxDeltaMicroseconds | |P_RFC[RFC-to-be]_Seconds_Max (TBD3) |(TBD7) | +------------------------------------+-------------------------------+ |OWDelay_HybridType1_I |pathDelaySumDeltaMicroseconds | |P_RFC[RFC-to-be]_Seconds_Sum (TBD4) |(TBD8) | +------------------------------------+-------------------------------+ Table 1: Mapping<table anchor="tab-1"> <name>Mapping Between IPFIX IEs and PerformanceMetrics ]]></artwork> </figure>Metrics</name> <thead> <tr> <th>Performance Metric</th> <th>IPFIX Information Element</th> </tr> </thead> <tbody> <tr> <td>OWDelay_HybridType1_I P_RFC9951_Seconds_Mean (27)</td> <td>pathDelayMeanDeltaMicroseconds (530)</td> </tr> <tr> <td>OWDelay_HybridType1_I P_RFC9951_Seconds_Min (28)</td> <td>pathDelayMinDeltaMicroseconds (531)</td> </tr> <tr> <td>OWDelay_HybridType1_I P_RFC9951_Seconds_Max (29)</td> <td>pathDelayMaxDeltaMicroseconds (532)</td> </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 by calculating the difference between the timestamp imposed with On-Path Telemetry in the packet at an OAM header encapsulating node and the timestamp exported in the IPFIX flow record from the OAM header transit and OAM header decapsulating nodes. The lowest, highest, mean, and the sum of measured path delay can be exported, thanks to the different IPFIX IE specifications.</t> <figureanchor="topology" title="Delay use case.anchor="topology"> <name>Delay Use Case: PacketsflowFlow fromhostHost 1 tohost 2.">Host 2</name> <artworkalign="center"><![CDATA[align="center" name="" type="" alt=""><![CDATA[ On-Path Telemetry Domain ......................................... . . . D1 . . x-------> . . . . D2 . . x--------------------> . . . . D3 . . x----------------------------------> . . . (H1) -----> (R0) ------> (R1) ------> (R2) -------> (R3) -----> (H2) Host 1 Encapsulating Transit Transit Decapsulating Host 2 Node Node 1 Node 2 Node . . . .......................................... ]]></artwork>.........................................]]></artwork> </figure> <t>In the use case shown in <xreftarget="topology"/>target="topology" format="default"/>, usingOn-pathOn-Path Telemetry to export the delay metrics, the node R1 exports the delay D1, the node R2 exports the delayD2D2, and the OAM header decapsulating node R3 exports the total delay D3 for the same flow using IPFIX.</t> <t>This solution enables the computation of delay metrics (minimum, maximum, and mean) directly on the OAM header transit and decapsulating node, allowing aggregation within the Flow Record. This reduces both export bandwidth and processing requirements on the Collector. To compute these metrics locally, the Exporter's Metering Process must perform per-packet caching and processing, particularly when computing mean delay under Flow Aggregation <xreftarget="RFC7015"/>.target="RFC7015" format="default"/>. A less computationally intensive alternative is to export the sum of delays, allowing the Collector to compute the mean via a simple division using the packet count. </t> <t>In contrast, if no delay processing occurs on the OAM header transit or decapsulating node, each packet must be exported as an individual Flow Record, including timestamp information, as specified in <xreftarget="I-D.ietf-opsawg-ipfix-alt-mark"/>.target="I-D.ietf-opsawg-ipfix-alt-mark" format="default"/>. The Collector must then compute the delay metrics and reconstruct the aggregated Flow Record accordingly.</t> </section> <section anchor="PM"title="Performance Metrics">numbered="true" toc="default"> <name>Performance Metrics</name> <t>This section defines four new performance metrics following the template defined in <xref section="11" sectionFormat="of"target="RFC8911"/>.</t> <t>IANA Note (to be removed): RFC 8192 Section 4 was taken a guiding example.</t>target="RFC8911" format="default"/>.</t> <section anchor="ip-ow-delay-hybridtype1-reg-entries"title="IPnumbered="true" toc="default"> <name>IP One-Way Delay Hybrid Type I PerformanceMetrics">Metrics</name> <t>This section specifies four performance metrics for the Hybrid Type I assessment of IP One-WayDelay, to beDelay; they have been registered in the <xreftarget="IANA-PERF-METRIC">IANAtarget="IANA-PERF-METRIC" format="default">IANA "PerformanceMetrics" registry</xref>.</t>Metrics Registry"</xref>.</t> <t>All column entries besides the Identifier, Name, URI, Description, Reference Description (Output only) categories are the same; thus, this section defines four closely related performance metrics. As a result, IANA has assigned corresponding URIs to each of the four registered performance metrics.</t> <section numbered="true"title="Summary">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). 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 performance metrics: the element Identifier and Metric Name. </t> <sectiontitle="ID (Identifier)">numbered="true" toc="default"> <name>ID (Identifier)</name> <t>IANA has allocated the numeric IdentifiersTBD1, TBD2, TBD3,27, 28, 29, andTBD430 for the four Named Metric Entries in the following section.</t><t>RFC EDITOR NOTE: please replace TBD1, TBD2, TBD3, and TBD4 with allocated IPFIX entity numbers.</t></section> <sectiontitle="Name"> <t>TBD1: OWDelay_HybridType1_IP_RFC[RFC-to-be]_Seconds_Mean</t> <t>TBD2: OWDelay_HybridType1_IP_RFC[RFC-to-be]_Seconds_Min</t> <t>TBD3: OWDelay_HybridType1_IP_RFC[RFC-to-be]_Seconds_Max</t> <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>numbered="true" toc="default"> <name>Name</name> <dl newline="false"> <dt>27:</dt> <dd>OWDelay_HybridType1_IP_RFC9951_Seconds_Mean</dd> <dt>28:</dt> <dd>OWDelay_HybridType1_IP_RFC9951_Seconds_Min</dd> <dt>29:</dt> <dd>OWDelay_HybridType1_IP_RFC9951_Seconds_Max</dd> <dt>30:</dt> <dd>OWDelay_HybridType1_IP_RFC9951_Seconds_Sum</dd> </dl> </section> <sectiontitle="URI"> <t>URI: <eref target="https://www.iana.org/assignments/performance-metrics/OWDelay_HybridType1_IP_RFC[RFC-to-be]_Seconds_Mean"/></t> <t>URI: <eref target="https://www.iana.org/assignments/performance-metrics/OWDelay_HybridType1_IP_RFC[RFC-to-be]_Seconds_Min"/></t> <t>URI: <eref target="https://www.iana.org/assignments/performance-metrics/OWDelay_HybridType1_IP_RFC[RFC-to-be]_Seconds_Max"/></t> <t>URI: <eref 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>numbered="true" toc="default"> <name>URI</name> <dl newline="true"> <dt>URI:</dt> <dd><eref target="https://www.iana.org/assignments/performance-metrics/OWDelay_HybridType1_IP_RFC9951_Seconds_Mean" brackets="angle"/></dd> <dt>URI:</dt> <dd><eref target="https://www.iana.org/assignments/performance-metrics/OWDelay_HybridType1_IP_RFC9951_Seconds_Min" brackets="angle"/></dd> <dt>URI:</dt> <dd><eref target="https://www.iana.org/assignments/performance-metrics/OWDelay_HybridType1_IP_RFC9951_Seconds_Max" brackets="angle"/></dd> <dt>URI:</dt> <dd><eref target="https://www.iana.org/assignments/performance-metrics/OWDelay_HybridType1_IP_RFC9951_Seconds_Sum" brackets="angle"/></dd> </dl> </section> </section> <sectiontitle="Description"> <t><list style="symbols"> <t>OWDelay_HybridType1_IP_RFC[RFC-to-be]_Seconds_Mean: Thisnumbered="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: Original: The measurement of one-way delay based on a single Observation Point [RFC7011] somewhere in the network. 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[RFC7011]<xref target="RFC7011"/> somewhere in thenetwork.</t> <t>OWDelay_HybridType1_IP_RFC[RFC-to-be]_Seconds_Min: Thisnetwork.</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[RFC7011]<xref target="RFC7011"/> somewhere in thenetwork.</t> <t>OWDelay_HybridType1_IP_RFC[RFC-to-be]_Seconds_Max: Thisnetwork.</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[RFC7011]<xref target="RFC7011"/> somewhere in thenetwork.</t> <t>OWDelay_HybridType1_IP_RFC[RFC-to-be]_Seconds_Sum: Thisnetwork.</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[RFC7011]<xref target="RFC7011"/> somewhere in thenetwork.</t> </list></t> <t>RFC EDITOR NOTE: please replace [RFC-to-be] with the allocated RFC document number.</t>network.</dd> </dl> </section> <sectiontitle="Reference"> <t>[RFC-to-be]</t>numbered="true" toc="default"> <name>Reference</name> <t>RFCEDITOR NOTE: please replace [RFC-to-be] with the allocated RFC document number.</t>9951</t> </section> <sectiontitle="Change Controller">numbered="true" toc="default"> <name>Change Controller</name> <t>IETF</t> </section> <sectiontitle="Versionnumbered="true" toc="default"> <name>Version of RegistryFormat">Format</name> <t>1.0</t> </section> </section> <sectiontitle="Metric Definition">numbered="true" toc="default"> <name>Metric Definition</name> <t>This category includes columns to prompt the entry of all necessary details related to the metric definition, including the immutable document reference and values of input factors, called "Fixed Parameters".</t> <sectiontitle="Reference Definition"> <t>Almes, G., Kalidindi, S., Zekauskas, M.,numbered="true" toc="default"> <name>Reference Definition</name> <t>See <xref target="RFC6049"/> andA. Morton, Ed., "A One-Way Delay Metric for IP Performance Metrics (IPPM)", STD 81, RFC 7679, DOI 10.17487/RFC7679, January 2016, <https://www.rfc-editor.org/info/rfc7679>. <xref target="RFC7679"/></t> <t>Morton, A. and E. Stephan, "Spatial Composition of Metrics" , RFC 6049, DOI 10.17487/RFC6049, January 2011, <https://www.rfc-editor.org/info/rfc6049>.<xreftarget="RFC6049"/></t>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]. Original: Note that terms such as "singleton" and "sample" are defined in Section 2 of [RFC2330]. 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"/>target="RFC7679" format="default"/> provides the reference definition of the singleton (single value) one-way delay metric. <xref section="4.4" sectionFormat="of"target="RFC7679"/>target="RFC7679" format="default"/> provides the reference definition expanded to cover a multi-value sample. Note that terms such as "singleton" and "sample" are defined in <xrefsection="2"section="11" sectionFormat="of"target="RFC2330"/>.</t>target="RFC2330" format="default"/>.</t> <t>With the Observation Point <xreftarget="RFC7011"/>target="RFC7011" format="default"/> typically located between the hosts participating in the IP Flow, the one-way delay metric requires one individual measurement between the Observation Point and sourcing host, such that the Spatial Composition <xreftarget="RFC6049"/>target="RFC6049" format="default"/> of the measurements yields a one-way delay singleton.</t> <t>This document specifies how to export the performance metric using IPFIX.</t> </section> <sectiontitle="Fixed Parameters">numbered="true" toc="default"> <name>Fixed Parameters</name> <t>None</t> </section> </section> <sectiontitle="Methodnumbered="true" toc="default"> <name>Method ofMeasurement">Measurement</name> <t>This category includes columns for references to relevant sections of the RFC(s) and any supplemental information needed to ensure an unambiguous method for implementations.</t> <sectiontitle="Reference Methods">numbered="true" toc="default"> <name>Reference Methods</name> <t>The foundational methodology for this metric is defined in <xref section="4" sectionFormat="of"target="RFC7323"/>target="RFC7323" format="default"/> using the Timestamps option with modifications that allow application at a mid-path Observation Point <xreftarget="RFC7011"/>.</t>target="RFC7011" format="default"/>.</t> </section> <sectiontitle="Packetnumbered="true" toc="default"> <name>Packet StreamGeneration"> <t>TheGeneration</name> <t>This is the time when the packet is being received at the OAM header encapsulating node. The timestamp format depends on the On-Path Telemetry implementation. For IOAM, <xref section="4.4.1" sectionFormat="of"target="RFC9197"/>target="RFC9197" format="default"/> describes the supported timestamps. Sections4.4.2.3<xref target="RFC9197" sectionFormat="bare" section="4.4.2.3"/> and4.4.2.4<xref target="RFC9197" sectionFormat="bare" section="4.4.2.4"/> of <xref target="RFC9197"/> describe where the timestamp is being inserted. For the Enhanced Alternate Marking Method, <xref section="2" sectionFormat="of"target="I-D.zhou-ippm-enhanced-alternate-marking"/>target="I-D.zhou-ippm-enhanced-alternate-marking" format="default"/> and <xref section="3.2" sectionFormat="of"target="I-D.fz-spring-srv6-alt-mark"/> definestarget="RFC9947" format="default"/> define the supported timestamp encodings and granularity.</t> </section> <sectiontitle="Trafficnumbered="true" toc="default"> <name>Traffic Filtering (Observation)Details">Details</name> <t>Runtime Parameters (in the following sections) may be used for Traffic Filtering.</t> </section> <sectiontitle="Sampling Distribution">numbered="true" toc="default"> <name>Sampling Distribution</name> <t>This metric requires a partial sample of all packets that qualify according to the Traffic Filter criteria.</t> </section> <sectiontitle="Runtimenumbered="true" toc="default"> <name>Runtime Parameters and DataFormat">Format</name> <t>Runtime Parameters are input factors that must be determined, configured into a measurement system, and reported with the results for the context to be complete.</t> <t>The Hybrid Type I metering parameters must be reported to provide the complete measurement context. As an example, if the IPFIX Metering Process is used, then the IPFIX Metering Process parameters (IPFIX Template Record, potential traffic filters, and potential sampling method and parameters) that generate the Flow Records must be reported to provide the complete measurement context. At a minimum, the following fields are required:</t><t><list style="hanging"> <t hangText="Src:">The<dl newline="false" spacing="normal"> <dt>Src:</dt> <!-- [rfced] RFC 6991 has been obsoleted by RFC 9911. We have replaced each citation 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: Original: or ipv6-address-no-zone value for IPv6; see Section 4 of [RFC6991]). Current: or ipv6-address-no-zone value for IPv6; see Section 4 of [RFC9911]). --> <dd>The IP address of the host in the host A Role (formatipv4&nbhy;address-no-zoneipv4-address-no-zone value for IPv4 or ipv6-address-no-zone value for IPv6; see <xref section="4" sectionFormat="of"target="RFC6991"/>).</t> <t hangText="Dst:">Thetarget="RFC9911" format="default"/>).</dd> <dt>Dst:</dt> <dd>The IP address of the host in the host B Role (formatipv4&nbhy;address-no-zoneipv4-address-no-zone value for IPv4 or ipv6-address-no-zone value for IPv6; see <xref section="4" sectionFormat="of"target="RFC6991"/>).</t> <t hangText="T0:">Ttarget="RFC9911" format="default"/>).</dd> <dt>T0:</dt> <dd>T time, the start of a measurement interval (format "date/time" as specified in <xref section="5.6" sectionFormat="of"target="RFC3339"/>;target="RFC3339" format="default"/>; see also "date-and-time" in <xref section="3" sectionFormat="of"target="RFC6991"/>).target="RFC9911" format="default"/>). The UTC Time Zone is required by <xref section="6.1" sectionFormat="of"target="RFC2330"/>.target="RFC2330" format="default"/>. When T0 is "all-zeros", a start time isunspecifiedunspecified, and Tf is to be interpreted as the duration of the measurement interval. The start time is controlled through othermeans.</t> <t hangText="Tf:">Ameans.</dd> <dt>Tf:</dt> <dd>A time, the end of a measurement interval (format "date/time" as specified in <xref section="5.6" sectionFormat="of"target="RFC3339"/>;target="RFC3339" format="default"/>; see also "date-and-time" in <xref section="3" sectionFormat="of"target="RFC6991"/>).target="RFC9911" format="default"/>). The UTC Time Zone is required by <xref section="6.1" sectionFormat="of"target="RFC2330"/>.target="RFC2330" format="default"/>. When T0 is "all-zeros", an ending time and dateis ignoredare ignored, and Tf is interpreted as the duration of the measurementinterval.</t> </list></t>interval.</dd> </dl> </section> <sectiontitle="Roles"> <t><list style="hanging"> <t hangText="host A:">Launchesnumbered="true" toc="default"> <name>Roles</name> <dl newline="false" spacing="normal"> <dt>Host A:</dt> <dd>Launches an IP packet to start theFlow.</t> <t hangText="host B:">ReceivesFlow.</dd> <dt>Host B:</dt> <dd>Receives the IP packet to start theFlow.</t> <t hangText="OAMFlow.</dd> <dt>OAM Header EncapsulatingNode:">Node:</dt> <dd> Receives the IP packets, encapsulates the packets with the OAMheaderheader, and adds the timestamp into the OAMheader.</t> <t hangText="OAMheader.</dd> <dt>OAM Header TransitNode:">ReceivesNode:</dt> <dd>Receives the IP packets, measures the delay between the timestamp in the packet and the timestamp when the packet wasreceived.</t> <t hangText="OAMreceived.</dd> <dt>OAM Header DecapsulatingNode:">ReceivesNode:</dt> <dd>Receives the IP packets, computes the delay between the timestamp in the packet and the timestamp when the packet wasreceivedreceived, and removes the OAM header from thepacket.</t> </list></t>packet.</dd> </dl> </section> </section> <sectiontitle="Output">numbered="true" toc="default"> <name>Output</name> <t>This category specifies all details of the output of measurements using the metric.</t> <sectiontitle="Type">numbered="true" toc="default"> <name>Type</name> <t>OWDelay Types are discussed in the subsections below.</t> </section> <sectiontitle="Reference Definition">numbered="true" toc="default"> <name>Reference Definition</name> <t>For all output types:</t><t><list style="hanging"> <t hangText="OWDelay_HybridType1_IP:">The<dl newline="false" spacing="normal"> <dt>OWDelay_HybridType1_IP:</dt> <dd>The one-way delay of one IP packet is aSingleton</t> </list></t>Singleton.</dd> </dl> <t>For each <statistic>SingletonSingleton, one of the following subsections applies.</t> <sectiontitle="OWDelay_HybridType1_IP_RFC[RFC-to-be]_Seconds_Mean">numbered="true" toc="default"> <name>OWDelay_HybridType1_IP_RFC9951_Seconds_Mean</name> <t>Similar to <xref section="7.4.2.2" sectionFormat="of"target="RFC8912"/>,target="RFC8912" format="default"/>, the meanSHALL<bcp14>SHALL</bcp14> be calculated using the conditional distribution of all packets with a finite value of one-way delay (undefined delays are excluded) -- a single 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: Original: see Section 5 of [RFC6703] for background on this analysis choice. Suggested: see Section 5 of [RFC6703] for background on this analytic choice. --> <t>See <xref section="4.1" sectionFormat="of"target="RFC3393"/>target="RFC3393" format="default"/> for details on the conditional distribution to exclude undefined values of delay, and see <xref section="5" sectionFormat="of"target="RFC6703"/>target="RFC6703" format="default"/> for background on this analysis choice.</t> <t>See <xref section="4.2.2" sectionFormat="of"target="RFC6049"/>target="RFC6049" format="default"/> for details on calculating this statistic; see also <xref section="4.2.3" sectionFormat="of"target="RFC6049"/>.</t> <t><list style="hanging"> <t hangText="Mean:">Thetarget="RFC6049" format="default"/>.</t> <dl newline="false" spacing="normal"> <dt>Mean:</dt> <dd>The time value of the result is expressed in units of microseconds, as a positive value of type decimal64 with fraction digits = 9 (similar tothedecimal64 in YANG, <xref section="9.3" sectionFormat="of"target="RFC6020"/>)target="RFC6020" format="default"/>) with a resolution of0.001 microseconds0.001 microseconds (1.0 ns), and with lossless conversion to/from the 64-bit NTP timestamp as per <xref section="6" sectionFormat="of"target="RFC5905"/>. </t> </list></t>target="RFC5905" format="default"/>. </dd> </dl> </section> <sectiontitle="OWDelay_HybridType1_IP_RFC[RFC-to-be]_Seconds_Min">numbered="true" toc="default"> <name>OWDelay_HybridType1_IP_RFC9951_Seconds_Min</name> <t>Similar to <xref section="7.4.2.3" sectionFormat="of"target="RFC8912"/>,target="RFC8912" format="default"/>, the minimumSHALL<bcp14>SHALL</bcp14> be calculated using the conditional distribution of all packets with a finite value of one-way delay (undefined delays are excluded) -- a single value, as follows:</t> <t>See <xref section="4.1" sectionFormat="of"target="RFC3393"/>target="RFC3393" format="default"/> for details on the conditional distribution to exclude undefined values of delay, and see <xref section="5" sectionFormat="of"target="RFC6703"/>target="RFC6703" format="default"/> for background on this analysis choice.</t> <t>See <xref section="4.3.2" sectionFormat="of"target="RFC6049"/>target="RFC6049" format="default"/> for details on calculating this statistic; see also <xref section="4.3.3" sectionFormat="of"target="RFC6049"/>.</t> <t><list style="hanging"> <t hangText="Min:">Thetarget="RFC6049" format="default"/>.</t> <dl newline="false" spacing="normal"> <dt>Min:</dt> <dd>The time value of the result is expressed in units of microseconds, as a positive value of type decimal64 with fraction digits = 9 (similar tothedecimal64 in YANG, <xref section="9.3" sectionFormat="of"target="RFC6020"/>)target="RFC6020" format="default"/>) with a resolution of0.001 microseconds0.001 microseconds (1.0 ns), and with lossless conversion to/from the 64-bit NTP timestamp as per <xref section="6" sectionFormat="of"target="RFC5905"/>. </t> </list></t>target="RFC5905" format="default"/>. </dd> </dl> </section> <sectiontitle="OWDelay_HybridType1_IP_RFC[RFC-to-be]_Seconds_Max">numbered="true" toc="default"> <name>OWDelay_HybridType1_IP_RFC9951_Seconds_Max</name> <t>Similar to <xref section="7.4.2.4" sectionFormat="of"target="RFC8912"/>,target="RFC8912" format="default"/>, the maximumSHALL<bcp14>SHALL</bcp14> be calculated using the conditional distribution of all packets with a finite value of one-way delay (undefined delays are excluded) -- a single value, as follows:</t> <t>See <xref section="4.1" sectionFormat="of"target="RFC3393"/>target="RFC3393" format="default"/> for details on the conditional distribution to exclude undefined values of delay, and see <xref section="5" sectionFormat="of"target="RFC6703"/>target="RFC6703" format="default"/> for background on this analysis choice.</t> <t>See <xref section="4.3.2" sectionFormat="of"target="RFC6049"/>target="RFC6049" format="default"/> for a closely related method for calculating this statistic; see also <xref section="4.3.3" sectionFormat="of"target="RFC6049"/>.target="RFC6049" format="default"/>. The formula is as follows:</t><t><figure> <artwork><![CDATA[<artwork name="" type="" align="left" alt=""><![CDATA[ Max = (FiniteDelay[j]) such that for some index, j, where 1 <= j <= N FiniteDelay[j] >= FiniteDelay[n] for all n ]]></artwork></figure></t><t>where all packets n = 1 through N have finite singleton delays.</t><t><list style="hanging"> <t hangText="Max:">The<dl newline="false" spacing="normal"> <dt>Max:</dt> <dd>The time value of the result is expressed in units of microseconds, as a positive value of type decimal64 with fraction digits = 9 (similar tothedecimal64 in YANG, <xref section="9.3" sectionFormat="of"target="RFC6020"/>)target="RFC6020" format="default"/>) with a resolution of0.001 microseconds0.001 microseconds (1.0 ns), and with lossless conversion to/from the 64-bit NTP timestamp as per <xref section="6" sectionFormat="of"target="RFC5905"/>. </t> </list></t>target="RFC5905" format="default"/>. </dd> </dl> </section> <sectiontitle="OWDelay_HybridType1_IP_RFC[RFC-to-be]_Seconds_Sum">numbered="true" toc="default"> <name>OWDelay_HybridType1_IP_RFC9951_Seconds_Sum</name> <t>The sumSHALL<bcp14>SHALL</bcp14> be calculated using the conditional distribution of all packets with a finite value of one-way delay (undefined delays are excluded) -- a single value, as follows:</t> <t>See <xref section="4.1" sectionFormat="of"target="RFC3393"/>target="RFC3393" format="default"/> for details on the conditional distribution to exclude undefined values of delay, and see <xref section="5" sectionFormat="of"target="RFC6703"/>target="RFC6703" format="default"/> for background on this analysis choice.</t> <t>See <xref section="4.3.5" sectionFormat="of"target="RFC6049"/>target="RFC6049" format="default"/> for details on calculating thisstatistic, howeverstatistic; however, in thiscasecase, FiniteDelay or MaxDelayMAY<bcp14>MAY</bcp14> be used.</t><t><list style="hanging"> <t hangText="Sum:">The<dl newline="false" spacing="normal"> <dt>Sum:</dt> <dd>The time value of the result is expressed in units of microseconds, as a positive value of type decimal64 with fraction digits = 9 (similar tothedecimal64 in YANG, <xref section="9.3" sectionFormat="of"target="RFC6020"/>)target="RFC6020" format="default"/>) with a resolution of0.001 microseconds0.001 microseconds (1.0 ns), and with lossless conversion to/from the 64-bit NTP timestamp as per <xref section="6" sectionFormat="of"target="RFC5905"/>. </t> </list></t>target="RFC5905" format="default"/>. </dd> </dl> </section> <sectiontitle="Metric Units"> <t><list style="symbols">numbered="true" toc="default"> <name>Metric Units</name> <ul spacing="normal"> <li> <t>Mean</t> </li> <li> <t>Min</t> </li> <li> <t>Max</t> </li> <li> <t>Sum</t></list></t></li> </ul> <t>The one-way delay of the IP Flow singleton is expressed in microseconds.</t> </section> <sectiontitle="Calibration">numbered="true" toc="default"> <name>Calibration</name> <t>A clock synchronization between the nodes of the monitored OAM domain is needed to compute representative delay measurements at the OAM header transit and decapsulating nodes. NTP, as defined in <xreftarget="RFC5905"/>,target="RFC5905" format="default"/>, can be used for synchronizing the clocks of the monitored nodes.</t> </section> </section> <sectiontitle="Administrative Items">numbered="true" toc="default"> <name>Administrative Items</name> <sectiontitle="Status">numbered="true" toc="default"> <name>Status</name> <t>Current</t> </section> <sectiontitle="Requester"> <t>RFC[RFC-to-be]</t>numbered="true" toc="default"> <name>Requester</name> <t>RFCEDITOR NOTE: please replace [RFC-to-be] with the allocated RFC document number and [RFC-date] with the date when the RFC has been published.</t>9951</t> </section> <sectiontitle="Revision">numbered="true" toc="default"> <name>Revision</name> <t>1.0</t> </section> <sectiontitle="Revision Date"> <t>RFC[RFC-date]</t>numbered="true" toc="default"> <!--[rfced] FYI, Revision Date will be updated before publication.--> <name>Revision Date</name> <t>2026-MM-DD</t> </section> </section> <sectiontitle="Commentsnumbered="true" toc="default"> <name>Comments andRemarks"> <t>none</t>Remarks</name> <t>None</t> </section> </section> </section> <section anchor="Use-Cases"title="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"? Original: The measured On-Path delay can be aggregated with Flow Aggregation as defined in [RFC7015] to the following device and control-plane dimensions [IANA-IPFIX] to determine: 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 <xreftarget="RFC7015"/>target="RFC7015" format="default"/> to the following device and control-plane dimensions <xreftarget="IANA-IPFIX"/>target="IANA-IPFIX" format="default"/> to determine:</t><t><list style="symbols"><ul spacing="normal"> <li> <t>With node id and egressInterface(14), on which node which logical egress interfaces have been contributing to how much delay.</t> </li> <li> <t>With node id and egressPhysicalInterface(253), on which node which physical egress interfaces have been contributing to how much delay.</t> </li> <li> <t>With ipNextHopIPv4Address(15) or ipNextHopIPv6Address(62), the forwarding path to which next-hop IP contributed to how much delay.</t> </li> <li> <t>With mplsTopLabelIPv4Address(47) or destinationIPv6Address and srhActiveSegmentIPv6(495), the forwarding path to which MPLStop labeltop-label IPv4 address or IPv6 destination address andSRv6Segment Routing over IPv6 (SRv6) active segment contributed to how much delay.</t> </li> <li> <t>BGP communities <xreftarget="RFC1997"/>target="RFC1997" format="default"/> are often used for setting a path priority or service selection. With bgpDestinationExtendedCommunityList(488) or bgpDestinationCommunityList(485) orbgpDestinationLargeCommunityList(491)bgpDestinationLargeCommunityList(491), which group of prefixes accumulated at which node how much delay.</t> </li> <li> <t>With destinationIPv4Address(13), destinationTransportPort(11),protocolIdentifier (4)protocolIdentifier(4), and sourceIPv4Address(8), or equivalent IPFIX IEs for IPv6, the forwarding path delay on each node from each IPv4 source address to a specific application in the network.</t></list></t> <t>Let</li> </ul> <!-- [rfced] FYI, we simplified this sentence as follows; please review. Original: Let us consider the example depicted in Figure 1 from Section 1 as topology example.Below example tableCurrent: Let us consider Figure 1 as a topology example. --> <t>Let us consider <xref target="topology"/> as a topology example. <xref target="tab-2"/> shows the aggregated delay per each node,ingressInterface,(10)ingressInterface(10), egressInterface(14),destinationIPv6Address(28)destinationIPv6Address(28), and srhActiveSegmentIPv6(495) measured at ingress.</t><t><figure> <artwork><![CDATA[ +-----------+-----------+------+-------------+-------------+-----------+ | ingress | egress | Node | destination | srhActive | Path | | Interface | Interface | | IPv6Address | SegmentIPv6 | Delay | +-----------+-----------+------+-------------+-------------+-----------+ | 271 | 276 | R0 | | | 0 µs | +-----------+-----------+------+-------------+-------------+-----------+ | 301 | 312 | R1 | 2001:db8::1 | 2001:db8::3 | 22 µs | +-----------+-----------+------+-------------+-------------+-----------+ | 22 | 27 | R2 | 2001:db8::2 | 2001:db8::3 | 42 µs | +-----------+-----------+------+-------------+-------------+-----------+ | 852 | 854 | R3 | 2001:db8::3 | 2001:db8::3 | 122 µs | +-----------+-----------+------+-------------+-------------+-----------+<table anchor="tab-2"> <name>Example Table2: Example tableofmeasured delayMeasured Delay atingress.Ingress, Ascending bydelay. ]]></artwork> </figure></t>Delay</name> <thead> <tr> <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> </section> <section anchor="IANA"title="IANA Considerations">numbered="true" toc="default"> <name>IANA Considerations</name> <section anchor="PM-IANA"title="Performance Metrics"> <t>This document requests IANA tonumbered="true" toc="default"> <name>Performance Metrics</name> <t>IANA has add four new performance metricsunderin the "PerformanceMetrics" registryMetrics Registry" <xreftarget="RFC8911"/>target="RFC8911" format="default"/> with the four templates defined inSection 3.<xref target="Solution"/>. </t> </section> <section anchor="IE-IANA"title="IPFIX Entities"> <t>This document requests IANA to registernumbered="true" toc="default"> <name>IPFIX Entities</name> <t>IANA has registered new IPFIX IEs (seetable 3) under<xref target="tab-3"/>) in the "IPFIX Information Elements" registryunderin the "IP Flow Information Export (IPFIX) Entities" registry group <xreftarget="IANA-IPFIX"/>target="IANA-IPFIX" format="default"/> andassignassigned the followinginitialcode points.</t><t><figure> <artwork><![CDATA[ +-------+--------------------------------+ |Element| Name | | ID | | +-------+--------------------------------+ | TBD5 | pathDelayMeanDeltaMicroseconds | | | | +-------+--------------------------------+ | TBD6 | pathDelayMinDeltaMicroseconds | | | | +-------+--------------------------------+ | TBD7 | pathDelayMaxDeltaMicroseconds | | | | +-------+--------------------------------+ | TBD8 | pathDelaySumDeltaMicroseconds | | | | +-------+--------------------------------+ Table 3: New<table anchor="tab-3"> <name>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 assigned to this document</t> </list></t>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="IANApathDelayMeanDeltaMicroseconds"title="pathDelayMeanDeltaMicroseconds">numbered="true" toc="default"> <name>pathDelayMeanDeltaMicroseconds</name> <dl> <dt>Name:</dt> <dd>pathDelayMeanDeltaMicroseconds</dd> </dl> <dl> <dt>ElementID:</dt><dd>TBD5</dd><dd>530</dd> </dl> <dl> <dt>Description:</dt> <dd>This Information Element identifies the mean path delay of all packets in the Flow, in microseconds, between an OAM header encapsulating node and the local node with the OAM domain (either an OAM header transit node or an OAM header decapsulating node), according toOWDelay_HybridType1_IP_RFC[RFC-to-be]_Seconds_MeanOWDelay_HybridType1_IP_RFC9951_Seconds_Mean in the IANAPerformance Metric Registry.</dd>"Performance Metrics Registry".</dd> </dl> <dl> <dt>Abstract Data Type:</dt> <dd>unsigned32</dd> </dl> <dl> <dt>Data Type Semantics:</dt> <dd>deltaCounter</dd> </dl> <dl> <dt>Reference:</dt><dd>[RFC-to-be]</dd><dd>RFC 9951</dd> </dl> <dl> <dt>Additional Information:</dt><dd>OWDelay_HybridType1_IP_RFC[RFC-to-be]_Seconds_Mean<dd>OWDelay_HybridType1_IP_RFC9951_Seconds_Mean in the IANAPerformance Metric Registry.</dd>"Performance Metrics Registry".</dd> </dl> </section> <section anchor="IANApathDelayMinDeltaMicroseconds"title="pathDelayMinDeltaMicroseconds">numbered="true" toc="default"> <name>pathDelayMinDeltaMicroseconds</name> <dl> <dt>Name:</dt> <dd>pathDelayMinDeltaMicroseconds</dd> </dl> <dl> <dt>ElementID:</dt><dd>TBD6</dd><dd>531</dd> </dl> <dl> <dt>Description:</dt> <dd>This Information Element identifies the lowest path delay of all packets in the Flow, in microseconds, between an OAM header encapsulating node and the local node with the OAM domain (either an OAM header transit node or an OAM header decapsulating node), according to theOWDelay_HybridType1_IP_RFC[RFC-to-be]_Seconds_MinOWDelay_HybridType1_IP_RFC9951_Seconds_Min in the IANAPerformance Metric Registry.</dd>"Performance Metrics Registry".</dd> </dl> <dl> <dt>Abstract Data Type:</dt> <dd>unsigned32</dd> </dl> <dl> <dt>Data Type Semantics:</dt> <dd>deltaCounter</dd> </dl> <dl> <dt>Reference:</dt><dd>[RFC-to-be]</dd><dd>RFC 9951</dd> </dl> <dl> <dt>Additional Information:</dt><dd>OWDelay_HybridType1_IP_RFC[RFC-to-be]_Seconds_Min<dd>OWDelay_HybridType1_IP_RFC9951_Seconds_Min in the IANAPerformance Metric Registry.</dd>"Performance Metrics Registry".</dd> </dl> </section> <section anchor="IANApathDelayMaxDeltaMicroseconds"title="pathDelayMaxDeltaMicroseconds">numbered="true" toc="default"> <name>pathDelayMaxDeltaMicroseconds</name> <dl> <dt>Name:</dt> <dd>pathDelayMaxDeltaMicroseconds</dd> </dl> <dl> <dt>ElementID:</dt><dd>TBD7</dd><dd>532</dd> </dl> <dl> <dt>Description:</dt> <dd>This Information Element identifies the highest path delay of all packets in the Flow, in microseconds, between an OAM header encapsulating node and the local node with the OAM domain (either an OAM header transit node or an OAM header decapsulating node), according toOWDelay_HybridType1_IP_RFC[RFC-to-be]_Seconds_MaxOWDelay_HybridType1_IP_RFC9951_Seconds_Max in the IANAPerformance Metric Registry.</dd>"Performance Metrics Registry".</dd> </dl> <dl> <dt>Abstract Data Type:</dt> <dd>unsigned32</dd> </dl> <dl> <dt>Data Type Semantics:</dt> <dd>deltaCounter</dd> </dl> <dl> <dt>Reference:</dt><dd>[RFC-to-be]</dd><dd>RFC 9951</dd> </dl> <dl> <dt>Additional Information:</dt><dd>OWDelay_HybridType1_IP_RFC[RFC-to-be]_Seconds_Max<dd>OWDelay_HybridType1_IP_RFC9951_Seconds_Max in the IANAPerformance Metric Registry.</dd>"Performance Metrics Registry".</dd> </dl> </section> <section anchor="IANApathDelaySumDeltaMicroseconds"title="pathDelaySumDeltaMicroseconds">numbered="true" toc="default"> <name>pathDelaySumDeltaMicroseconds</name> <dl> <dt>Name:</dt> <dd>pathDelaySumDeltaMicroseconds</dd> </dl> <dl> <dt>ElementID:</dt><dd>TBD8</dd><dd>533</dd> </dl> <dl> <dt>Description:</dt> <dd>This Information Element identifies the sum of the path delay of all packets in the Flow, in microseconds, between an OAM header encapsulating node and the local node with the OAM domain (either an OAM header transit node or an OAM header decapsulating node), according toOWDelay_HybridType1_IP_RFC[RFC-to-be]_Seconds_SumOWDelay_HybridType1_IP_RFC9951_Seconds_Sum in the IANAPerformance Metric Registry.</dd>"Performance Metrics Registry".</dd> </dl> <dl> <dt>Abstract Data Type:</dt> <dd>unsigned64</dd> </dl> <dl> <dt>Data Type Semantics:</dt> <dd>deltaCounter</dd> </dl> <dl> <dt>Reference:</dt><dd>[RFC-to-be]</dd><dd>RFC 9951</dd> </dl> <dl> <dt>Additional Information:</dt><dd>OWDelay_HybridType1_IP_RFC[RFC-to-be]_Seconds_Sum<dd>OWDelay_HybridType1_IP_RFC9951_Seconds_Sum in the IANAPerformance Metric Registry.</dd>"Performance Metrics Registry".</dd> </dl> </section> </section> </section> <section anchor="Operational"title="Operational Considerations">numbered="true" toc="default"> <name>Operational Considerations</name> <section anchor="OpsTimeAccuracy"title="Time Accuracy"> <t>Thenumbered="true" toc="default"> <name>Time Accuracy</name> <t>In terms of clock precision, the same recommendation as defined in <xref section="4.5" sectionFormat="of"target="RFC5153"/>target="RFC5153" format="default"/> for IPFIX appliesin terms of clock precisionto this document as well.</t> </section> <section anchor="OpsMeanDelay"title="Mean Delay">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. --> <t>The mean (average) path delay can be calculated by dividing thepathDelaySumDeltaMicroseconds(TBD8)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.</t> </section> <section anchor="OpsReducedSizeEncoding"title="Reduced-size encoding">numbered="true" toc="default"> <name>Reduced-Size Encoding</name> <!--[rfced] We suggest changing "being accounted" to "being counted" here. Please review the intended meaning. Original: Unsigned64 has been chosen as type for pathDelaySumDeltaMicroseconds 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 numbers and where many packets are being accounted. As an example, a specific Flow Record with path delay of 100 milliseconds cannot observe more than 42949 packets without overflowing the unsigned32 counter. The procedure described in <xref section="6.2" sectionFormat="of"target="RFC7011"/>target="RFC7011" format="default"/> may be applied to reduce network bandwidth between the IPFIX Exporter and Collector if unsigned32 would be large enough without wrapping around.</t> </section> <section anchor="MeasurementInterval"title="Measurement Interval">numbered="true" toc="default"> <name>Measurement Interval</name> <t>The delay metrics are computed for the Flow Recordlife timelifetime by comparing the OAM timestamps in each received packet with the timestamp when they were received. For a long-running Flow, the IPFIX Metering Process might miss the temporal distribution of the delay (for example, a longer delay only at the beginning of the Flow). If this is an operational problem, the IPFIX Metering Process might be configured with a smaller expiration timeout (seeSection 5.1.1. Flow Expiration"Flow Expiration", <xref section="5.1.1" sectionFormat="of" target="RFC5470"/>). </t> </section> <section anchor="OpsIoamApplication"title="In-Packetnumbered="true" toc="default"> <name>In-Packet OAMApplication">Application</name> <t>Multiple methods can be used to compute the delay performance metrics defined in this document. Some examples of such methods are IOAM <xreftarget="RFC9197"/>target="RFC9197" format="default"/> and Enhanced Alternate Marking <xreftarget="I-D.zhou-ippm-enhanced-alternate-marking"/>.</t>target="I-D.zhou-ippm-enhanced-alternate-marking" format="default"/>.</t> <t>For IOAM, these performance metrics can be computed using the Edge-to-Edge and the Direct Exporting Option-Type.</t> <t>IOAM Edge-to-Edge Option-Type, as described in <xref section="4.6" sectionFormat="of"target="RFC9197"/>,target="RFC9197" format="default"/>, can use bits 2 and 3. In this case, timestamps are encoded as defined in Sections4.4.2.3<xref target="RFC9197" sectionFormat="bare" section="4.4.2.3"/> and4.4.2.4<xref target="RFC9197" sectionFormat="bare" section="4.4.2.4"/> of <xreftarget="RFC9197"/>.target="RFC9197" format="default"/>. This timestamp can be used to compute the delay between an OAM header encapsulating node and the decapsulating node.</t><t>IOAM<t>The IOAM Direct Exporting Option-Type, as described in <xreftarget="RFC9326"/>,target="RFC9326" format="default"/>, can use the Extension-Flag defined in <xreftarget="I-D.ahuang-ippm-dex-timestamp-ext"/>target="I-D.ahuang-ippm-dex-timestamp-ext" format="default"/> to insert a timestamp in the OAM header encapsulating node. The timestamp is encoded as defined in Sections4.4.2.3<xref target="RFC9197" sectionFormat="bare" section="4.4.2.3"/> and4.4.2.4<xref target="RFC9197" sectionFormat="bare" section="4.4.2.4"/> of <xreftarget="RFC9197"/>.target="RFC9197" format="default"/>. This timestamp can be used to compute the delay between the inserted timestamp and the OAM header transit 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? Original: [...] and be read at the OAM header intermediate and decapsulating node to calculate the on-path delay. Perhaps: [...] and be read at the OAM header intermediate and decapsulating nodes to calculate the On-Path delay. --> <t>For the Enhanced Alternate Marking Method, <xref section="2" sectionFormat="of"target="I-D.zhou-ippm-enhanced-alternate-marking"/>target="I-D.zhou-ippm-enhanced-alternate-marking" format="default"/> and <xref section="3.2" sectionFormat="of"target="I-D.fz-spring-srv6-alt-mark"/> definestarget="RFC9947"/> define that, within the metaInfo, a nanosecond timestamp can be encoded in an OAM header encapsulating node and be read at the OAM header intermediate and decapsulating node to calculate the on-path delay. <xreftarget="RFC9343"/>target="RFC9343" format="default"/> defines how this can be applied to the IPv6 extensionsheaderheader, and <xreftarget="I-D.fz-spring-srv6-alt-mark"/>target="RFC9947" format="default"/> defines how this can be applied to the SRv6 Segment Routing Header <xreftarget="RFC8754"/>.</t>target="RFC8754" format="default"/>.</t> <t>Given that the delay measurements are computed with the timestamp introduced on the OAM header encapsulating node, regardless of the approach, implementations should document at which point of the forwarding plane this timestamp is introduced(e.g.(e.g., the time at which the packet was received by the node, the time at which the packet was transmitted by the node, etc.). Based on this information, different actions can be taken. </t> </section> </section> <section anchor="Security"title="Security Considerations">numbered="true" toc="default"> <name>Security Considerations</name> <t>The IPFIX Information Elements introduced in this document do not directly introduce security issues. Rather, they define a set of performance metrics that may, for privacy or business issues, 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 for the receiver of this information; otherwise, this wouldotherwiseonly be possible for direct observers of the reported Flows along the data path.</t> <t>IPFIX collectorsMUST<bcp14>MUST</bcp14> ensure that IPFIX data originates from trusted sources. Accepting IPFIX data from unauthenticated sources could lead to data spoofing, policy misapplication, or denial of service.</t><t>The<t>Therefore, the underlying protocol used to exchange the information described here mustthereforeapply appropriate procedures to guarantee the integrity and confidentiality of the exported information. These protocols are defined in separatedocuments, specificallydocuments; specifically, see the IPFIX security considerations in <xref section="11" sectionFormat="of"target="RFC7011"/>.target="RFC7011" format="default"/>. ImplementationsSHOULD<bcp14>SHOULD</bcp14> also refer to <xreftarget="BCP195"/>target="BCP195" format="default"/> for additional details.</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 Processing) 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</middle> <back> <displayreference target="I-D.zhou-ippm-enhanced-alternate-marking" to="ENH-ALT-MARKING"/> <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"/> <references> <name>References</name> <references anchor="norm_ref"> <name>Normative References</name> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.2119.xml"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.3339.xml"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.5905.xml"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.6049.xml"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.7011.xml"/> <!-- [rfced] [RFC7012] is not cited in theFluvia 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 cantext. Please let us know where it should beobtained 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 packetDeltaCount in the open source Network Telemetry data collection project pmacct.</t> <t>The source code cancited; otherwise it will beobtained here: <xref target="Paolo-Lucente-Pmacct"/> and was validated atdeleted from theIETF 116 hackathon.</t> </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 Veldereferences section. [RFC7012] Claise, B., Ed. andÉric Vyncke'sB. Trammell, Ed., "Information Model fortheir review and valuable comments. Special thanks to Paul Aitken (as IPFIX Designated Expert), Greg Mirsky (asIPPerformance Metrics Designated Expert), and to Med Boucadair for their very detailed feedback.</t> </section> </middle> <back> <references title="Normative References"> <?rfc include='https://xml.resource.org/public/rfc/bibxml/reference.RFC.2119.xml'?> <?rfc include='https://xml.resource.org/public/rfc/bibxml/reference.RFC.3339.xml'?> <?rfc include='https://xml.resource.org/public/rfc/bibxml/reference.RFC.5905.xml'?> <?rfc include='https://xml.resource.org/public/rfc/bibxml/reference.RFC.6049.xml'?> <?rfc include='https://xml.resource.org/public/rfc/bibxml/reference.RFC.7011.xml'?> <?rfc include='https://xml.resource.org/public/rfc/bibxml/reference.RFC.7012.xml'?> <?rfc include='https://xml.resource.org/public/rfc/bibxml/reference.RFC.7323.xml'?> <?rfc include='https://xml.resource.org/public/rfc/bibxml/reference.RFC.7679.xml'?> <?rfc include='https://xml.resource.org/public/rfc/bibxml/reference.RFC.8174.xml'?> <?rfc include='https://xml.resource.org/public/rfc/bibxml/reference.RFC.8911.xml'?> <?rfc include='https://xml.resource.org/public/rfc/bibxml/reference.RFC.8912.xml'?> <?rfc include="https://bib.ietf.org/public/rfc/bibxml9/reference.BCP.0195.xml"?>Flow Information Export (IPFIX)", RFC 7012, DOI 10.17487/RFC7012, September 2013, <https://www.rfc-editor.org/info/rfc7012>. --> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.7012.xml"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.7323.xml"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.7679.xml"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8174.xml"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8911.xml"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8912.xml"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml9/reference.BCP.195.xml"/> </references><references title="Informative References"><references> <name>Informative References</name> <reference anchor="IANA-PERF-METRIC"target="https://www.iana.org/assignments/performance-metrics/performance-metrics.xhtml">target="https://www.iana.org/assignments/performance-metrics"> <front><title>IANA Performance Metric Registry</title> <author/><title>Performance Metrics</title> <author> <organization>IANA</organization> </author> <date/> </front> </reference> <reference anchor="IANA-IPFIX"target="https://www.iana.org/assignments/ipfix/ipfix.xhtml">target="https://www.iana.org/assignments/ipfix"> <front><title>IANA IP<title>IP Flow Information Export (IPFIX)Entities Registry</title> <author/>Entities</title> <author> <organization>IANA</organization> </author> <date/> </front> </reference><?rfc include='https://xml.resource.org/public/rfc/bibxml/reference.RFC.1997.xml'?> <?rfc include='https://xml.resource.org/public/rfc/bibxml/reference.RFC.2330.xml'?> <?rfc include='https://xml.resource.org/public/rfc/bibxml/reference.RFC.3393.xml'?> <?rfc include='https://xml.resource.org/public/rfc/bibxml/reference.RFC.5153.xml'?> <?rfc include='https://xml.resource.org/public/rfc/bibxml/reference.RFC.5470.xml'?> <?rfc include='https://xml.resource.org/public/rfc/bibxml/reference.RFC.6020.xml'?> <?rfc include='https://xml.resource.org/public/rfc/bibxml/reference.RFC.6703.xml'?> <?rfc include='https://xml.resource.org/public/rfc/bibxml/reference.RFC.6991.xml'?> <?rfc include='https://xml.resource.org/public/rfc/bibxml/reference.RFC.7015.xml'?> <?rfc include='https://xml.resource.org/public/rfc/bibxml/reference.RFC.7799.xml'?> <?rfc include='https://xml.resource.org/public/rfc/bibxml/reference.RFC.8754.xml'?> <?rfc include='https://xml.resource.org/public/rfc/bibxml/reference.RFC.9197.xml'?> <?rfc include='https://xml.resource.org/public/rfc/bibxml/reference.RFC.9232.xml'?> <?rfc include='https://xml.resource.org/public/rfc/bibxml/reference.RFC.9326.xml'?> <?rfc include='https://xml.resource.org/public/rfc/bibxml/reference.RFC.9343.xml'?> <?rfc include='https://bib.ietf.org/public/rfc/bibxml-ids/reference.I-D.ietf-opsawg-ipfix-alt-mark.xml'?> <?rfc include='https://bib.ietf.org/public/rfc/bibxml-ids/reference.I-D.zhou-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.ahuang-ippm-dex-timestamp-ext.xml'?><xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.1997.xml"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.2330.xml"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.3393.xml"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.5153.xml"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.5470.xml"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.6020.xml"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.6703.xml"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.7015.xml"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.7799.xml"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8754.xml"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9197.xml"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9232.xml"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9326.xml"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9343.xml"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9911.xml"/> <!-- [I-D.ietf-opsawg-ipfix-alt-mark] 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"/> <!-- [I-D.zhou-ippm-enhanced-alternate-marking] draft-zhou-ippm-enhanced-alternate-marking-18 IESG State: I-D Exists as of 3/30/26 --> <referenceanchor="INSA-Lyon-VPP" target="https://github.com/network-analytics/vpp-srh-onpath-telemetry">anchor="I-D.zhou-ippm-enhanced-alternate-marking" target="https://datatracker.ietf.org/doc/html/draft-zhou-ippm-enhanced-alternate-marking-18"> <front><title>INSA Lyon, FD.io VPP implementation</title> <author/> <date/><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-marking-18" /> </reference> <!--draft-fz-spring-srv6-alt-mark in AUTH48-DONE as 9947 as of 3/30/26 --> <referenceanchor="NTT-Fluvia" target="https://github.com/nttcom/fluvia/">anchor="RFC9947" target="https://www.rfc-editor.org/info/rfc9947"> <front><title>NTT Com, Fluvia Exporter</title> <author/> <date/><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> <!-- draft-ahuang-ippm-dex-timestamp-ext-00 IESG State: Expired inserted full reference in order to fix author name (A. Huang-Feng) --> <referenceanchor="Paolo-Lucente-Pmacct" target="https://github.com/pmacct/pmacct">anchor="I-D.ahuang-ippm-dex-timestamp-ext" target="https://datatracker.ietf.org/doc/html/draft-ahuang-ippm-dex-timestamp-ext-00"> <front><title>Paolo Lucente, Pmacct open source Network Telemetry Data Collection</title> <author/> <date/><title>Timestamp extension for In Situ Operations, Administration, and Maintenance (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 Maintenance (IOAM) Direct Export option type to support timestamping by adding and defining two optional timestamp fields and corresponding flags.</t> </abstract> </front> <seriesInfo name="Internet-Draft" value="draft-ahuang-ippm-dex-timestamp-ext-00"/> </reference> </references> </references> <section anchor="Encoding-Example"title="IPFIXnumbered="true" toc="default"> <name>IPFIX EncodingExamples">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. Original: Taking Figure 1 from Section 1 as topology example. Current: Let's take Figure 1 as a topology example. --> <t>This appendix represents two different encodings for the newly introduced IEs.Taking Figure 1 from Section 1Let's take <xref target="topology"/> as a topology example.Below example Table 4<xref target="tab-4"/> shows the aggregated delay with ingressInterface, egressInterface,destinationIPv6AddressdestinationIPv6Address, and srhActiveSegmentIPv6.</t><t><figure> <artwork><![CDATA[ +------ +------+-----------+-----------+------+-------+-------+-------+ |ingress|egress|destination|srhActive |packet|path |path |path | |Inter |Inter |IPv6Address|SegmentIPv6|Delta |Delay |Delay |Delay | |face |face | | |Count |Mean |Min |Max | | | | | | |Delta |Delta |Delta | | | | | | |Micro..|Micro..|Micro..| +-------+------+-----------+-----------+------+-------+-------+-------+ | 271 | 276 |2001:db8::3|2001:db8::2| 5 | 36 µs | 22 µs | 74 µs | +-------+------+-----------+-----------+------+-------+-------+-------+<!--[rfced] For Table4: Aggregated delay4, is it correct that the column headers 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 in the edited document. Please review and let us know any updates, or if you want to revert to the previous format. (We note that Table 2 also adds spaces into IE names, perhaps in order get line breaks within the cell; please let us know if you'd like to make any updates to Table 2.) Original (column headers): path Delay Mean Delta Micro.. path Delay Min Delta Micro.. path Delay Max Delta Micro.. Perhaps intended as the IE names: pathDelayMeanDeltaMicroseconds pathDelayMinDeltaMicroseconds pathDelayMaxDeltaMicroseconds --> <table anchor="tab-4"> <name>Aggregated Delay with egressInterface andsrhActiveSegmentIPv6 ]]></artwork> </figure></t>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> <section anchor="Aggregated-OnPath-Delay-Examples"title="Aggregatednumbered="true" toc="default"> <name>Aggregated On-Path DelayExamples">Examples</name> <section anchor="Template-Record-and-Data-Set-with-MeanDelta"title="Templatenumbered="true" toc="default"> <name>Template Record and Data Set with MeanDelta">Delta</name> <t>With encoding inFigure 2,<xref target="fig-2"/>, the mean (average) path delay is calculated on the exporting node.</t><t><list style="symbols"><ul spacing="normal"> <li> <t>Ingress interface => ingressInterface</t> </li> <li> <t>Egress interface => egressInterface</t> </li> <li> <t>IPv6 destination address => destinationIPv6Address </t> </li> <li> <t>Active SRv6 Segment => srhActiveSegmentIPv6</t> </li> <li> <t>Packet Delta Count => packetDeltaCount</t> </li> <li> <t>Minimum One-Way Delay => pathDelayMinDeltaMicroseconds(TBD6)</t>(531)</t> </li> <li> <t>Maximum One-Way Delay => pathDelayMaxDeltaMicroseconds(TBD7)</t>(532)</t> </li> <li> <t>Mean One-Way Delay => pathDelayMeanDeltaMicroseconds(TBD5)</t> </list></t>(530)</t> </li> </ul> <figuretitle="Templateanchor="fig-2"> <name>Template Record forpathDelayMeanDeltaMicroseconds."> <artwork><![CDATA[pathDelayMeanDeltaMicroseconds</name> <artwork name="" type="" align="left" alt=""><![CDATA[ 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 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Template ID = 256 | Field Count = 8 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |0| ingressInterface = 10 | Field Length = 4 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |0| egressInterface = 14 | Field Length = 4 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |0| destinationIPv6Address = 28 | Field Length = 16 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |0| srhActiveSegmentIPv6 = 495 | Field Length = 16 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |0| packetDeltaCount = 5 | Field Length = 4 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |0| pathDelayMeanDelta.. =TBD5530 | Field Length = 4 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |0| pathDelayMinDelta.. =TBD6531 | Field Length = 4 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |0| pathDelayMaxDelta.. =TBD7532 | Field Length = 4 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ]]></artwork> </figure> <t>The data set is represented as follows:</t> <figuretitle="Dataanchor="fig-3"> <name>Data Set Encoding forpathDelayMeanDeltaMicroseconds."> <artwork><![CDATA[pathDelayMeanDeltaMicroseconds</name> <artwork name="" type="" align="left" alt=""><![CDATA[ 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 = 256 | Length = 60 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ingressInterface = 271 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | egressInterface = 276 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | destinationIPv6Address = | | ... | | ... | | 2001:db8::2 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | srhActiveSegmentIPv6 = ... | | ... | | ... | | 2001:db8::3 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | packetDeltaCount = 5 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | pathDelayMeanDeltaMicroseconds = 36 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | pathDelayMinDeltaMicroseconds = 22 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | pathDelayMaxDeltaMicroseconds = 74 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ]]></artwork> </figure> </section> <section anchor="Template-Record-and-Data-Set-with-SumDelta"title="Templatenumbered="true" toc="default"> <name>Template Record and Data Set with SumDelta">Delta</name> <t>With encoding in <xreftarget="template-sum"/>,target="template-sum" format="default"/>, the mean (average) path delay is calculated on the IPFIX data collection.</t><t><list style="symbols"><ul spacing="normal"> <li> <t>Ingress interface => ingressInterface</t> </li> <li> <t>Egress interface => egressInterface</t> </li> <li> <t>IPv6 destination address => destinationIPv6Address </t> </li> <li> <t>Active SRv6 Segment => srhActiveSegmentIPv6</t> </li> <li> <t>Packet Delta Count => packetDeltaCount</t> </li> <li> <t>Minimum One-Way Delay => pathDelayMinDeltaMicroseconds(TBD6)</t>(531)</t> </li> <li> <t>Maximum One-Way Delay => pathDelayMaxDeltaMicroseconds(TBD7)</t>(532)</t> </li> <li> <t>Sum of One-Way Delay => pathDelaySumDeltaMicroseconds(TBD8)</t> </list></t>(533)</t> </li> </ul> <figureanchor="template-sum" title="Templateanchor="template-sum"> <name>Template Record forpathDelaySumDeltaMicroseconds."> <artwork><![CDATA[pathDelaySumDeltaMicroseconds.</name> <artwork name="" type="" align="left" alt=""><![CDATA[ 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 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Template ID = 257 | Field Count = 8 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |0| ingressInterface = 10 | Field Length = 4 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |0| egressInterface = 14 | Field Length = 4 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |0| destinationIPv6Address = 28 | Field Length = 16 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |0| srhActiveSegmentIPv6 = 495 | Field Length = 16 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |0| packetDeltaCount = 5 | Field Length = 4 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |0| pathDelayMinDelta.. =TBD6531 | Field Length = 4 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |0| pathDelayMaxDelta.. =TBD7532 | Field Length = 4 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |0| pathDelaySumDelta.. =TBD8533 | Field Length = 8 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ]]></artwork> </figure> <t>The data set is represented as follows:</t><figure title="Data<figure> <name>Data Set Encoding forpathDelaySumDeltaMicroseconds"> <artwork><![CDATA[pathDelaySumDeltaMicroseconds</name> <artwork name="" type="" align="left" alt=""><![CDATA[ 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 = 257 | Length = 64 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ingressInterface = 271 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | egressInterface = 276 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | destinationIPv6Address = | | ... | | ... | | 2001:db8::2 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | srhActiveSegmentIPv6 = ... | | ... | | ... | | 2001:db8::3 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | packetDeltaCount = 5 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | pathDelayMinDeltaMicroseconds = 22 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | pathDelayMaxDeltaMicroseconds = 74 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | pathDelaySumDeltaMicroseconds = 180 | | ... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ]]></artwork> </figure> </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> </rfc>