RFC 9951

Export of Delay Performance Metrics in IP Flow Information Export (IPFIX)

📅 published April 2026, from ietf

RFC 9951: Export of Delay Performance Metrics in IP Flow Information Export (IPFIX) 🦋

Part 1 of 6 💖

  • Number: RFC 9951 (Request for Comments: 9951), from the Internet Engineering Task Force (IETF) 🌸
  • Authors: T. Graf (Swisscom), B. Claise (Huawei), and A. Huang-Feng (INSA-Lyon) 👑
  • Category: Standards Track, ISSN 2070-1721 ✨
  • Date: April 2026 📅
  • Obsoletes / Updates: the title block doesn't list anything this one obsoletes or updates 🧚

Abstract

okay so this doc specs out some brand-new IP Flow Information Export (IPFIX) Information Elements 💅 They let you export the On-Path delay at every Operations, Administration, and Maintenance (OAM) transit and decapsulating node 🔥 The On-Path delay is the delay between the OAM header encapsulating node and each of those OAM header transit and decapsulating nodes 🦋 An On-Path Telemetry protocol does the delay measurement, and the IPFIX process is what exports it 💜

Status of This Memo

this is an Internet Standards Track document ✨

it's a product of the Internet Engineering Task Force (IETF) and it represents the consensus of the IETF community 🫶 It got public review and was approved for publication by the Internet Engineering Steering Group (IESG) 👑 If you want more on Internet Standards, check out Section 2 of RFC 7841 📚

for the current status, any errata, and how to give feedback, go to https://www.rfc-editor.org/info/rfc9951 🌈

Copyright (c) 2026 IETF Trust and the persons identified as the document authors. All rights reserved. 💖

this document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) as they're in effect on the date of publication 📜 Please read these carefully, bestie, because they spell out your rights and restrictions for this document 🙈 Code Components pulled out of this document must include Revised BSD License text as described in Section 4.e of the Trust Legal Provisions, and they come without warranty, as the Revised BSD License describes 💅

Table of Contents 🎀

1.  Introduction
2.  Terminology
3.  Solution
4.  Performance Metrics
  4.1.  IP One-Way Delay Hybrid Type I Performance Metrics
    4.1.1.  Summary
    4.1.2.  Description
    4.1.3.  Reference
    4.1.4.  Change Controller
    4.1.5.  Version of Registry Format
  4.2.  Metric Definition
    4.2.1.  Reference Definition
    4.2.2.  Fixed Parameters
  4.3.  Method of Measurement
    4.3.1.  Reference Methods
    4.3.2.  Packet Stream Generation
    4.3.3.  Traffic Filtering (Observation) Details
    4.3.4.  Sampling Distribution
    4.3.5.  Runtime Parameters and Data Format
    4.3.6.  Roles
  4.4.  Output
    4.4.1.  Type
    4.4.2.  Reference Definition
    4.4.3.  Administrative Items
    4.4.4.  Comments and Remarks
5.  Use Cases
6.  IANA Considerations
  6.1.  Performance Metrics
  6.2.  IPFIX Entities
    6.2.1.  pathDelayMeanDeltaMicroseconds
    6.2.2.  pathDelayMinDeltaMicroseconds
    6.2.3.  pathDelayMaxDeltaMicroseconds
    6.2.4.  pathDelaySumDeltaMicroseconds
7.  Operational Considerations
  7.1.  Time Accuracy
  7.2.  Mean Delay
  7.3.  Reduced-Size Encoding
  7.4.  Measurement Interval
  7.5.  In-Packet OAM Application
8.  Security Considerations
9.  References
  9.1.  Normative References
  9.2.  Informative References
Appendix A.  IPFIX Encoding Examples
  A.1.  Aggregated On-Path Delay Examples
    A.1.1.  Template Record and Data Set with Mean Delta
    A.1.2.  Template Record and Data Set with Sum Delta
Acknowledgements
Authors' Addresses

1. Introduction 🌸

network operators usually keep statistical views of delay across their networks, and these help with diagnostics and performance analysis 📊 Those views show where abnormal delay is, how far it reaches, and what might be causing it, especially when it's hitting specific customer traffic or services 👀 To pull that off, delay-related metrics need to be reported from devices covering both the data and control planes 🔥 And to figure out which customers are affected, those metrics also need to be reported in the context of the customer data plane 💅 That correlation is what lets you spot changes in forwarding paths, like updated intermediate hops or interfaces, and the impact on the delay customer traffic actually feels ✨

delay measurements in the network are computed using an On-Path Telemetry protocol, which inserts metadata into the data-plane packet when it enters the monitored domain [RFC9232] 🦋 To compute those measurements, the On-Path Telemetry protocol inserts a timestamp reference when the packet enters the OAM encapsulating node 🕐 Implementation examples are In situ Operations, Administration, and Maintenance (IOAM) [RFC9197] or Enhanced Alternate Marking [ENH-ALT-MARKING] 🧚

there are two modes of On-Path Telemetry that are generally recognized 💜 The first is passport mode, where only the OAM header decapsulating node of the OAM domain reports metrics 🛂 The second is postcard mode, where OAM header transit nodes also export On-Path Telemetry data 📮 Both modes expose per-hop performance metrics, including delay accumulation 📈 The approach defined in this document is mainly applicable to postcard mode 💖

to export the delay-related metrics via IPFIX [RFC7011], this document defines four new IPFIX Information Elements (IEs) 🎀 They expose the On-Path delay on OAM header transit and decapsulating nodes, following the principles of postcard mode 🌈

this makes it possible to compute delay metrics (minimum, maximum, and mean) directly on the OAM header transit and decapsulating node, so you can aggregate them within the Flow Record 🫶

and because these IEs represent performance metrics, they're also registered in the IANA "Performance Metrics Registry" [IANA-PERF-METRIC] in accordance with [RFC8911] 🏆

2. Terminology 💅

the key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here 🔥

this document defines the following terms ✨

OAM Header Encapsulating Node: this node receives the IP packets, wraps them in an OAM header, and adds the timestamp into that OAM header 🎁

OAM Header Transit Node: this node receives the IP packets, then measures the delay between the timestamp in the packet and the timestamp for when the packet was received ⏱️

OAM Header Decapsulating Node: this node receives the IP packets, computes the delay between the timestamp in the packet and the timestamp for when the packet was received, and then removes the OAM header from the packet 🧹

this document makes use of the terms defined in [RFC7011], [RFC8911] and [RFC7799] 🧠

the following terms are used as defined in [RFC7011]:

  • Collector
  • Exporter
  • Flow
  • Flow Record
  • IPFIX
  • IPFIX Information Elements (IEs)
  • Observation Point

the following terms are used as defined in [RFC8911]:

  • Performance Metric
  • Performance Metrics Registry
  • Registered Performance Metric

the following term is used as defined in Section 3.8 of [RFC7799]:

  • Hybrid Type I

3. Solution ✨

Okay so [RFC8911] has guidelines for Registered Performance Metric requesters and reviewers, and they're giving "every metric gets fully described so results actually compare across implementations and environments" 💅. Each metric gets its required characteristics (Identifier, Name, URI, Status, Requester, Revision, Description) 🎀. Those get registered in the IANA "Performance Metrics Registry" [IANA-PERF-METRIC]. The naming follows the MetricType_Method_SubTypeMethod_... Spec_Units_Output pattern from Section 7.1.2 of [RFC8911] 🦋.

This document defines the following performance metrics and IPFIX Information Elements 🌸:

  +=============================+================================+
  | Performance Metric          | IPFIX Information Element      |
  +=============================+================================+
  | OWDelay_HybridType1_I       | pathDelayMeanDeltaMicroseconds |
  | P_RFC9951_Seconds_Mean (27) | (530)                          |
  +-----------------------------+--------------------------------+
  | OWDelay_HybridType1_I       | pathDelayMinDeltaMicroseconds  |
  | P_RFC9951_Seconds_Min (28)  | (531)                          |
  +-----------------------------+--------------------------------+
  | OWDelay_HybridType1_I       | pathDelayMaxDeltaMicroseconds  |
  | P_RFC9951_Seconds_Max (29)  | (532)                          |
  +-----------------------------+--------------------------------+
  | OWDelay_HybridType1_I       | pathDelaySumDeltaMicroseconds  |
  | P_RFC9951_Seconds_Sum (30)  | (533)                          |
  +-----------------------------+--------------------------------+

     Table 1: Mapping Between IPFIX IEs and Performance Metrics

So assuming the devices have time synchronization 🕰️, the delay gets measured by taking the difference between the timestamp stamped 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 sum of the measured path delay can all be exported, thanks to the different IPFIX IE specifications 👑.

                       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
              .                                       .
              .                                       .
              .........................................

     Figure 1: Delay Use Case: Packets Flow from Host 1 to Host 2

In the use case shown in Figure 1 🔥, On-Path Telemetry is used to export the delay metrics. Node R1 exports the delay D1, node R2 exports the delay D2, and the OAM header decapsulating node R3 exports the total delay D3 for the same flow using IPFIX 💜.

This solution lets you compute the delay metrics (minimum, maximum, and mean) directly on the OAM header transit and decapsulating node, so they can be aggregated within the Flow Record 🧚. That cuts down both export bandwidth and the processing work on the Collector 🙌. To compute these metrics locally, the Exporter's Metering Process must perform per-packet caching and processing, especially when computing mean delay under Flow Aggregation [RFC7015]. A less computationally intensive option is to export the sum of delays, so the Collector can get the mean with a simple division using the packet count 🍓.

On the flip side, if no delay processing happens on the OAM header transit or decapsulating node, each packet has to be exported as its own individual Flow Record, including timestamp information, as specified in [IPFIX-ALT-MARK] 😭. The Collector must then compute the delay metrics and rebuild the aggregated Flow Record itself 💀.

4. Performance Metrics ✨

This section defines four new performance metrics using the template from Section 11 of [RFC8911] 🎀.

4.1. IP One-Way Delay Hybrid Type I Performance Metrics

This section specifies four performance metrics for the Hybrid Type I assessment of IP One-Way Delay. They've been registered in the IANA "Performance Metrics Registry" [IANA-PERF-METRIC] 🌈.

All the column entries except Identifier, Name, URI, Description, and Reference Description (Output only) are the same, so this section is basically defining four closely related performance metrics 👯. Because of that, IANA assigned a corresponding URI to each of the four registered performance metrics 🦋.

4.1.1. Summary

This category has multiple indexes for the registered performance metrics: the Identifier and the Metric Name 📇.

4.1.1.1. ID (Identifier)

IANA allocated the numeric Identifiers 27, 28, 29, and 30 for the four Named Metric Entries in the next section 🔢.

4.1.1.2. Name

27:  OWDelay_HybridType1_IP_RFC9951_Seconds_Mean

28:  OWDelay_HybridType1_IP_RFC9951_Seconds_Min

29:  OWDelay_HybridType1_IP_RFC9951_Seconds_Max

30:  OWDelay_HybridType1_IP_RFC9951_Seconds_Sum

4.1.1.3. URI

URI:
   <https://www.iana.org/assignments/performance-metrics/
   OWDelay_HybridType1_IP_RFC9951_Seconds_Mean>

URI:
   <https://www.iana.org/assignments/performance-metrics/
   OWDelay_HybridType1_IP_RFC9951_Seconds_Min>

URI:
   <https://www.iana.org/assignments/performance-metrics/
   OWDelay_HybridType1_IP_RFC9951_Seconds_Max>

URI:
   <https://www.iana.org/assignments/performance-metrics/
   OWDelay_HybridType1_IP_RFC9951_Seconds_Sum>

4.1.2. Description

OWDelay_HybridType1_IP_RFC9951_Seconds_Mean 💖 assesses the mean of the one-way delays of all successfully forwarded IP packets that make up a single Flow. The one-way delay measurement is based on a single Observation Point [RFC7011] somewhere in the network.

OWDelay_HybridType1_IP_RFC9951_Seconds_Min 💙 assesses the minimum of the one-way delays of all successfully forwarded IP packets that make up a single Flow. The one-way delay measurement is based on a single Observation Point [RFC7011] somewhere in the network.

OWDelay_HybridType1_IP_RFC9951_Seconds_Max ❤️ assesses the maximum of the one-way delays of all successfully forwarded IP packets that make up a single Flow. The one-way delay measurement is based on a single Observation Point [RFC7011] somewhere in the network.

OWDelay_HybridType1_IP_RFC9951_Seconds_Sum 💜 assesses the sum of the one-way delays of all successfully forwarded IP packets that make up a single Flow. The one-way delay measurement is based on a single Observation Point [RFC7011] somewhere in the network.

4.1.3. Reference

RFC 9951 📖

4.1.4. Change Controller

IETF 🏛️

4.1.5. Version of Registry Format

1.0 🧾

4.2. Metric Definition

This category has columns for all the details needed to define the metric, including the immutable document reference and the values of the input factors, called "Fixed Parameters" 🧩.

4.2.1. Reference Definition

See [RFC6049] and [RFC7679] in the Normative References (Section 9.1) 📚.

Section 3.4 of [RFC7679] gives the reference definition of the singleton (single value) one-way delay metric ☝️. Section 4.4 of [RFC7679] gives the reference definition expanded to cover a multi-value sample 🌷. Heads up that terms like "singleton" and "sample" are defined in Section 11 of [RFC2330] 🤓.

With the Observation Point [RFC7011] typically located between the hosts participating in the IP Flow, the one-way delay metric needs one individual measurement between the Observation Point and the sourcing host. That way, the Spatial Composition [RFC6049] of the measurements gives you a one-way delay singleton 🎯.

This document specifies how to export the performance metric using IPFIX 📤.

4.2.2. Fixed Parameters

None 🫧

4.3. Method of Measurement

This category has columns for references to the relevant sections of the RFC(s) and any supplemental information needed for an unambiguous method for implementations 🔍.

4.3.1. Reference Methods

The foundational methodology for this metric is defined in Section 4 of [RFC7323], using the Timestamps option with modifications that allow it to be applied at a mid-path Observation Point [RFC7011] 🛠️.

4.3.2. Packet Stream Generation

This is the time when the packet is received at the OAM header encapsulating node ⏰. The timestamp format depends on the On-Path Telemetry implementation. For IOAM, Section 4.4.1 of [RFC9197] describes the supported timestamps, and Sections 4.4.2.3 and 4.4.2.4 of [RFC9197] describe where the timestamp gets inserted 🧷. For the Enhanced Alternate Marking Method, Section 2 of [ENH-ALT-MARKING] and Section 3.2 of [RFC9947] define the supported timestamp encodings and granularity 🌟.

4.3.3. Traffic Filtering (Observation) Details

Runtime Parameters (in the following sections) may be used for Traffic Filtering 🎛️.

4.3.4. Sampling Distribution

This metric requires a partial sample of all packets that qualify according to the Traffic Filter criteria 🎲.

4.3.5. Runtime Parameters and Data Format 📝

Okay so Runtime Parameters are the input factors you need to figure out, set up in your measurement system, and report alongside the results so the context is complete 💅.

The Hybrid Type I metering parameters need to be reported so everyone has the full measurement context 🧩. For example, if the IPFIX Metering Process is used, then its parameters (the IPFIX Template Record, any potential traffic filters, and any potential sampling method and parameters) that generate the Flow Records need to be reported too. At a minimum, these fields are required:

  • Src: The IP address of the host in the host A Role (format ipv4-address-no-zone value for IPv4 or ipv6-address-no-zone value for IPv6; see Section 4 of [RFC9911]).
  • Dst: The IP address of the host in the host B Role (format ipv4-address-no-zone value for IPv4 or ipv6-address-no-zone value for IPv6; see Section 4 of [RFC9911]).
  • T0: T time, the start of a measurement interval (format "date/time" as specified in Section 5.6 of [RFC3339]; see also "date-and-time" in Section 3 of [RFC9911]). The UTC Time Zone is required by Section 6.1 of [RFC2330]. When T0 is all-zeros, a start time is unspecified, and Tf is to be interpreted as the duration of the measurement interval. The start time is controlled through other means. ⏰
  • Tf: A time, the end of a measurement interval (format "date/time" as specified in Section 5.6 of [RFC3339]; see also "date-and-time" in Section 3 of [RFC9911]). The UTC Time Zone is required by Section 6.1 of [RFC2330]. When T0 is all-zeros, an ending time and date are ignored, and Tf is interpreted as the duration of the measurement interval. 🏁

4.3.6. Roles 🎭

  • Host A: Launches an IP packet to start the Flow. 🚀
  • Host B: Receives the IP packet to start the Flow. 🎯
  • OAM Header Encapsulating Node: Receives the IP packets, encapsulates the packets with the OAM header, and adds the timestamp into the OAM header.
  • OAM Header Transit Node: Receives the IP packets, measures the delay between the timestamp in the packet and the timestamp when the packet was received.
  • OAM Header Decapsulating Node: Receives the IP packets, computes the delay between the timestamp in the packet and the timestamp when the packet was received, and removes the OAM header from the packet.

4.4. Output 🎀

This category specifies all details of the output of measurements using the metric.

4.4.1. Type

OWDelay Types are discussed in the subsections below.

4.4.2. Reference Definition

For all output types:

  • OWDelay_HybridType1_IP: The one-way delay of one IP packet is a singleton.

For each <statistic> singleton, one of the following subsections applies.

4.4.2.1. OWDelay_HybridType1_IP_RFC9951_Seconds_Mean

Similar to Section 7.4.2.2 of [RFC8912], the mean SHALL 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:

See Section 4.1 of [RFC3393] for details on the conditional distribution to exclude undefined values of delay, and see Section 5 of [RFC6703] for background on this analytic choice.

See Section 4.2.2 of [RFC6049] for details on calculating this statistic; see also Section 4.2.3 of [RFC6049].

  • Mean: The time value of the result is expressed in units of microseconds, as a positive value of type decimal64 with fraction digits = 9 (similar to decimal64 in YANG, Section 9.3 of [RFC6020]) with a resolution of 0.001 microseconds (1.0 ns), and with lossless conversion to/from the 64-bit NTP timestamp as per Section 6 of [RFC5905]. ⏱️

4.4.2.2. OWDelay_HybridType1_IP_RFC9951_Seconds_Min

Similar to Section 7.4.2.3 of [RFC8912], the minimum SHALL 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:

See Section 4.1 of [RFC3393] for details on the conditional distribution to exclude undefined values of delay, and see Section 5 of [RFC6703] for background on this analytic choice.

See Section 4.3.2 of [RFC6049] for details on calculating this statistic; see also Section 4.3.3 of [RFC6049].

  • Min: The time value of the result is expressed in units of microseconds, as a positive value of type decimal64 with fraction digits = 9 (similar to decimal64 in YANG, Section 9.3 of [RFC6020]) with a resolution of 0.001 microseconds (1.0 ns), and with lossless conversion to/from the 64-bit NTP timestamp as per Section 6 of [RFC5905]. 📉

4.4.2.3. OWDelay_HybridType1_IP_RFC9951_Seconds_Max

Similar to Section 7.4.2.4 of [RFC8912], the maximum SHALL 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:

See Section 4.1 of [RFC3393] for details on the conditional distribution to exclude undefined values of delay, and see Section 5 of [RFC6703] for background on this analytic choice.

See Section 4.3.2 of [RFC6049] for a closely related method for calculating this statistic; see also Section 4.3.3 of [RFC6049]. The formula is as follows:

 Max = (FiniteDelay[j])
 such that for some index, j, where 1 <= j <= N
 FiniteDelay[j] >= FiniteDelay[n] for all n

where all packets n = 1 through N have finite singleton delays.

  • Max: The time value of the result is expressed in units of microseconds, as a positive value of type decimal64 with fraction digits = 9 (similar to decimal64 in YANG, Section 9.3 of [RFC6020]) with a resolution of 0.001 microseconds (1.0 ns), and with lossless conversion to/from the 64-bit NTP timestamp as per Section 6 of [RFC5905]. 🔝

4.4.2.4. OWDelay_HybridType1_IP_RFC9951_Seconds_Sum

The sum SHALL 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:

See Section 4.1 of [RFC3393] for details on the conditional distribution to exclude undefined values of delay, and see Section 5 of [RFC6703] for background on this analytic choice.

See Section 4.3.5 of [RFC6049] for details on calculating this statistic; however, in this case, FiniteDelay or MaxDelay MAY be used.

  • Sum: The time value of the result is expressed in units of microseconds, as a positive value of type decimal64 with fraction digits = 9 (similar to decimal64 in YANG, Section 9.3 of [RFC6020]) with a resolution of 0.001 microseconds (1.0 ns), and with lossless conversion to/from the 64-bit NTP timestamp as per Section 6 of [RFC5905]. ➕

4.4.2.5. Metric Units

  • Mean
  • Min
  • Max
  • Sum

The one-way delay of the IP Flow singleton is expressed in microseconds. 🔢

4.4.2.6. Calibration

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 [RFC5905], can be used for synchronizing the clocks of the monitored nodes. ⌚🫶

4.4.3. Administrative Items

4.4.3.1. Status

Current

4.4.3.2. Requester

RFC 9951

4.4.3.3. Revision

1.0

4.4.3.4. Revision Date

2026-04-02

4.4.4. Comments and Remarks

None

5. Use Cases 🌈

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:

  • With node id and egressInterface(14), on which node which logical egress interfaces have been contributing to how much delay. 🛣️
  • With node id and egressPhysicalInterface(253), on which node which physical egress interfaces have been contributing to how much delay. 🔌
  • With ipNextHopIPv4Address(15) or ipNextHopIPv6Address(62), the forwarding path to which next-hop IP contributed to how much delay. 🧭
  • With mplsTopLabelIPv4Address(47) or destinationIPv6Address and srhActiveSegmentIPv6(495), the forwarding path to which MPLS top-label IPv4 address or IPv6 destination address and Segment Routing over IPv6 (SRv6) active segment contributed to how much delay. 🏷️
  • BGP communities [RFC1997] are often used for setting a path priority or service selection. With bgpDestinationExtendedCommunityList(488) or bgpDestinationCommunityList(485) or bgpDestinationLargeCommunityList(491), which group of prefixes accumulated at which node how much delay. 👑
  • With destinationIPv4Address(13), destinationTransportPort(11), 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. 💻

Let us consider Figure 1 as a topology example. Table 2 shows the aggregated delay per each node, ingressInterface(10), egressInterface(14), destinationIPv6Address(28), and srhActiveSegmentIPv6(495) measured at ingress. 📊

+===========+===========+======+=============+=============+=======+
| 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 2: Example Table of Measured Delay at Ingress, Ascending
                            by Delay

6. IANA Considerations 📋

6.1. Performance Metrics

IANA has added four new performance metrics in the "Performance Metrics Registry" [RFC8911] with the four templates defined in Section 3. 🎉

6.2. IPFIX Entities

IANA has registered new IPFIX IEs (see Table 3) in the "IPFIX Information Elements" registry in the "IP Flow Information Export (IPFIX) Entities" registry group [IANA-IPFIX] and assigned the following code points. 🧾

+===========+================================+
| ElementID | Name                           |
+===========+================================+
| 530       | pathDelayMeanDeltaMicroseconds |
+-----------+--------------------------------+
| 531       | pathDelayMinDeltaMicroseconds  |
+-----------+--------------------------------+
| 532       | pathDelayMaxDeltaMicroseconds  |
+-----------+--------------------------------+
| 533       | pathDelaySumDeltaMicroseconds  |
+-----------+--------------------------------+

     Table 3: New IPFIX IEs in the "IPFIX
        Information Elements" Registry

6.2.1. pathDelayMeanDeltaMicroseconds 💖

  • Name: pathDelayMeanDeltaMicroseconds
  • ElementID: 530

okay so this IE tells you the mean path delay of all the packets in a Flow, in microseconds 🧚 It measures the time between an OAM header encapsulating node and the local node inside the OAM domain (so either an OAM header transit node or an OAM header decapsulating node). The number comes from OWDelay_HybridType1_IP_RFC9951_Seconds_Mean in the IANA "Performance Metrics Registry" ✨

  • Abstract Data Type: unsigned32
  • Data Type Semantics: deltaCounter
  • Reference: RFC 9951
  • Additional Information: OWDelay_HybridType1_IP_RFC9951_Seconds_Mean in the IANA "Performance Metrics Registry".

6.2.2. pathDelayMinDeltaMicroseconds 🦋

  • Name: pathDelayMinDeltaMicroseconds
  • ElementID: 531

this one is giving "lowest of the lowest" 📉 It's the lowest path delay across all the packets in the Flow, in microseconds, between an OAM header encapsulating node and the local node in the OAM domain (again, either an OAM header transit node or an OAM header decapsulating node). It's based on OWDelay_HybridType1_IP_RFC9951_Seconds_Min in the IANA "Performance Metrics Registry" 🌸

  • Abstract Data Type: unsigned32
  • Data Type Semantics: deltaCounter
  • Reference: RFC 9951
  • Additional Information: OWDelay_HybridType1_IP_RFC9951_Seconds_Min in the IANA "Performance Metrics Registry".

6.2.3. pathDelayMaxDeltaMicroseconds 🌈

  • Name: pathDelayMaxDeltaMicroseconds
  • ElementID: 532

the opposite energy 💀 This is the highest path delay across all the packets in the Flow, in microseconds, measured between an OAM header encapsulating node and the local node in the OAM domain (so, OAM header transit node or OAM header decapsulating node). It's according to OWDelay_HybridType1_IP_RFC9951_Seconds_Max in the IANA "Performance Metrics Registry" 👑

  • Abstract Data Type: unsigned32
  • Data Type Semantics: deltaCounter
  • Reference: RFC 9951
  • Additional Information: OWDelay_HybridType1_IP_RFC9951_Seconds_Max in the IANA "Performance Metrics Registry".

6.2.4. pathDelaySumDeltaMicroseconds 🎀

  • Name: pathDelaySumDeltaMicroseconds
  • ElementID: 533

this is the running total 🧮 It's the sum of the path delay of all the packets in the Flow, in microseconds, between an OAM header encapsulating node and the local node in the OAM domain (OAM header transit node or OAM header decapsulating node, you know the drill). It's based on OWDelay_HybridType1_IP_RFC9951_Seconds_Sum in the IANA "Performance Metrics Registry" 💜 Because it's a running total, it's an unsigned64 and not an unsigned32 (more on why in Section 7.3 🫶)

  • Abstract Data Type: unsigned64
  • Data Type Semantics: deltaCounter
  • Reference: RFC 9951
  • Additional Information: OWDelay_HybridType1_IP_RFC9951_Seconds_Sum in the IANA "Performance Metrics Registry".

7. Operational Considerations ✨

7.1. Time Accuracy 🕰️

okay clock precision matters, bestie ⏰ The same recommendation from Section 4.5 of [RFC5153] for IPFIX applies to this document too, so you don't get to skip it 💅

7.2. Mean Delay 🧁

so you want the average? 🍰 Divide pathDelaySumDeltaMicroseconds(533) by packetDeltaCount(2) to get the mean path delay. Do that math at the IPFIX data collection, at the collection time, and not at the IPFIX Exporter at the export time 💖

7.3. Reduced-Size Encoding 🦋

unsigned64 was chosen for pathDelaySumDeltaMicroseconds so it can handle big delay numbers and flows where lots and lots of packets are counted 📦 For example, a specific Flow Record with a path delay of 100 milliseconds can't observe more than 42949 packets without overflowing the unsigned32 counter 😭

If unsigned32 would still be big enough without wrapping around, the procedure in Section 6.2 of [RFC7011] may be applied to cut down on network bandwidth between the IPFIX Exporter and Collector. Smart and efficient, iconic 🌸

7.4. Measurement Interval ⏳

the delay metrics are computed for the whole lifetime of the Flow Record by comparing the OAM timestamps in each received packet with the timestamp from when that packet was received 🕐

For a long-running Flow, the IPFIX Metering Process might miss the temporal distribution of the delay. For example, a longer delay that only happens at the beginning of the Flow could get lost 🙈

If that's an operational problem for you, the IPFIX Metering Process might be configured with a smaller expiration timeout (see "Flow Expiration", Section 5.1.1 of [RFC5470]) 🧚

7.5. In-Packet OAM Application 📡

there are multiple methods you can use to compute the delay performance metrics defined in this document 🌈 Some examples are IOAM [RFC9197] and Enhanced Alternate Marking [ENH-ALT-MARKING].

For IOAM, these performance metrics can be computed using the Edge-to-Edge and the Direct Exporting Option-Type. 💜

The IOAM Edge-to-Edge Option-Type, as described in Section 4.6 of [RFC9197], can use bits 2 and 3. In this case, timestamps are encoded as defined in Sections 4.4.2.3 and 4.4.2.4 of [RFC9197]. That timestamp can be used to compute the delay between an OAM header encapsulating node and the decapsulating node 🦋

The IOAM Direct Exporting Option-Type, as described in [RFC9326], can use the Extension-Flag defined in [IOAM-DEX] to insert a timestamp in the OAM header encapsulating node. The timestamp is encoded as defined in Sections 4.4.2.3 and 4.4.2.4 of [RFC9197]. That timestamp can be used to compute the delay between the inserted timestamp and the OAM header transit and decapsulating node 🫶

For the Enhanced Alternate Marking Method, Section 2 of [ENH-ALT-MARKING] and Section 3.2 of [RFC9947] define that, within the metaInfo, a nanosecond timestamp can be encoded in an OAM header encapsulating node and read at the OAM header intermediate and decapsulating nodes to calculate the On-path delay 🧮 [RFC9343] defines how this can be applied to the IPv6 extensions header, and [RFC9947] defines how this can be applied to the SRv6 Segment Routing Header [RFC8754] 🌸

Since the delay measurements are computed with the timestamp introduced on the OAM header encapsulating node, no matter which approach you pick, implementations should document at which point of the forwarding plane this timestamp is introduced (for example, the time at which the packet was received by the node, or the time at which the packet was transmitted by the node). Based on that info, different actions can be taken 👑

8. Security Considerations 🔐

the IPFIX Information Elements introduced in this document don't directly introduce security issues on their own 🫶 Instead, they define a set of performance metrics that may, for privacy or business reasons, be considered sensitive information 🙈

For example, exporting delay metrics may make attacks possible by the receiver of this information. Otherwise, that would only be possible for direct observers of the reported Flows along the data path 😳

IPFIX collectors MUST 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. This is serious, bestie, do not skip it 💀

So the underlying protocol used to exchange the information described here must apply appropriate procedures to guarantee the integrity and confidentiality of the exported information. These protocols are defined in separate documents. Specifically, see the IPFIX security considerations in Section 11 of [RFC7011]. Implementations SHOULD also refer to [BCP195] for additional details 🔥

9. References 📚

9.1. Normative References 💅

9.2. Informative References 📚

okay these are the extra-reading refs bestie 🧚 they're not the core must-reads, just the good stuff to look up if you're curious

[ENH-ALT-MARKING] Zhou, T., Ed., Fioccola, G., Liu, Y., Cociglio, M., Pang, R., Xiong, L., Lee, S., and W. Li, "Enhanced Alternate Marking Method", Work in Progress, Internet-Draft, draft-zhou-ippm-enhanced-alternate-marking-18, 5 December 2025, <https://datatracker.ietf.org/doc/html/draft-zhou-ippm-enhanced-alternate-marking-18>.

[IANA-IPFIX] IANA, "IP Flow Information Export (IPFIX) Entities", <https://www.iana.org/assignments/ipfix>.

[IANA-PERF-METRIC] IANA, "Performance Metrics", <https://www.iana.org/assignments/performance-metrics>.

[IOAM-DEX] Huang Feng, A., Francois, P., Claise, B., and T. Graf, "Timestamp extension for In Situ Operations, Administration, and Maintenance (IOAM) Direct Export", Work in Progress, Internet-Draft, draft-ahuang-ippm-dex-timestamp-ext-00, 15 February 2023, <https://datatracker.ietf.org/doc/html/draft-ahuang-ippm-dex-timestamp-ext-00>.

[IPFIX-ALT-MARK] Graf, T., Fioccola, G., Zhou, T., and Y. Zhu, "IP Flow Information Export (IPFIX) Alternate-Marking Information Elements", Work in Progress, Internet-Draft, draft-ietf-opsawg-ipfix-alt-mark-05, 27 February 2026, <https://datatracker.ietf.org/doc/html/draft-ietf-opsawg-ipfix-alt-mark-05>.

[RFC1997] Chandra, R., Traina, P., and T. Li, "BGP Communities Attribute", RFC 1997, DOI 10.17487/RFC1997, August 1996, <https://www.rfc-editor.org/info/rfc1997>.

[RFC2330] Paxson, V., Almes, G., Mahdavi, J., and M. Mathis, "Framework for IP Performance Metrics", RFC 2330, DOI 10.17487/RFC2330, May 1998, <https://www.rfc-editor.org/info/rfc2330>.

[RFC3393] Demichelis, C. and P. Chimento, "IP Packet Delay Variation Metric for IP Performance Metrics (IPPM)", RFC 3393, DOI 10.17487/RFC3393, November 2002, <https://www.rfc-editor.org/info/rfc3393>.

[RFC5153] Boschi, E., Mark, L., Quittek, J., Stiemerling, M., and P. Aitken, "IP Flow Information Export (IPFIX) Implementation Guidelines", RFC 5153, DOI 10.17487/RFC5153, April 2008, <https://www.rfc-editor.org/info/rfc5153>.

[RFC5470] Sadasivan, G., Brownlee, N., Claise, B., and J. Quittek, "Architecture for IP Flow Information Export", RFC 5470, DOI 10.17487/RFC5470, March 2009, <https://www.rfc-editor.org/info/rfc5470>.

[RFC6020] Bjorklund, M., Ed., "YANG - A Data Modeling Language for the Network Configuration Protocol (NETCONF)", RFC 6020, DOI 10.17487/RFC6020, October 2010, <https://www.rfc-editor.org/info/rfc6020>.

[RFC6703] Morton, A., Ramachandran, G., and G. Maguluri, "Reporting IP Network Performance Metrics: Different Points of View", RFC 6703, DOI 10.17487/RFC6703, August 2012, <https://www.rfc-editor.org/info/rfc6703>.

[RFC7015] Trammell, B., Wagner, A., and B. Claise, "Flow Aggregation for the IP Flow Information Export (IPFIX) Protocol", RFC 7015, DOI 10.17487/RFC7015, September 2013, <https://www.rfc-editor.org/info/rfc7015>.

[RFC7799] Morton, A., "Active and Passive Metrics and Methods (with Hybrid Types In-Between)", RFC 7799, DOI 10.17487/RFC7799, May 2016, <https://www.rfc-editor.org/info/rfc7799>.

[RFC8754] Filsfils, C., Ed., Dukes, D., Ed., Previdi, S., Leddy, J., Matsushima, S., and D. Voyer, "IPv6 Segment Routing Header (SRH)", RFC 8754, DOI 10.17487/RFC8754, March 2020, <https://www.rfc-editor.org/info/rfc8754>.

[RFC9197] Brockners, F., Ed., Bhandari, S., Ed., and T. Mizrahi, Ed., "Data Fields for In Situ Operations, Administration, and Maintenance (IOAM)", RFC 9197, DOI 10.17487/RFC9197, May 2022, <https://www.rfc-editor.org/info/rfc9197>.

[RFC9232] Song, H., Qin, F., Martinez-Julia, P., Ciavaglia, L., and A. Wang, "Network Telemetry Framework", RFC 9232, DOI 10.17487/RFC9232, May 2022, <https://www.rfc-editor.org/info/rfc9232>.

[RFC9326] Song, H., Gafni, B., Brockners, F., Bhandari, S., and T. Mizrahi, "In Situ Operations, Administration, and Maintenance (IOAM) Direct Exporting", RFC 9326, DOI 10.17487/RFC9326, November 2022, <https://www.rfc-editor.org/info/rfc9326>.

[RFC9343] Fioccola, G., Zhou, T., Cociglio, M., Qin, F., and R. Pang, "IPv6 Application of the Alternate-Marking Method", RFC 9343, DOI 10.17487/RFC9343, December 2022, <https://www.rfc-editor.org/info/rfc9343>.

[RFC9911] Schönwälder, J., Ed., "Common YANG Data Types", RFC 9911, DOI 10.17487/RFC9911, December 2025, <https://www.rfc-editor.org/info/rfc9911>.

[RFC9947] Fioccola, G., Zhou, T., Mishra, G., Wang, X., Zhang, G., and M. Cociglio, "Application of the Alternate-Marking Method to the Segment Routing Header", RFC 9947, DOI 10.17487/RFC9947, March 2026, <https://www.rfc-editor.org/info/rfc9947>.

Appendix A. IPFIX Encoding Examples ✨

this appendix shows off two different ways to encode the newly introduced IEs 🎀 let's use Figure 1 as our topology example. Table 4 shows the aggregated delay with ingressInterface, egressInterface, destinationIPv6Address, and srhActiveSegmentIPv6 💅

          +--------------------------------+-------------+
          | ingressInterface               | 271         |
          +--------------------------------+-------------+
          | egressInterface                | 276         |
          +--------------------------------+-------------+
          | destinationIPv6Address         | 2001:db8::3 |
          +--------------------------------+-------------+
          | srhActiveSegmentIPv6           | 2001:db8::2 |
          +--------------------------------+-------------+
          | packetDeltaCount               | 5           |
          +--------------------------------+-------------+
          | pathDelayMeanDeltaMicroseconds | 36 µs       |
          +--------------------------------+-------------+
          | pathDelayMinDeltaMicroseconds  | 22 µs       |
          +--------------------------------+-------------+
          | pathDelayMaxDeltaMicroseconds  | 74 µs       |
          +--------------------------------+-------------+

                   Table 4: Aggregated Delay with
              egressInterface and srhActiveSegmentIPv6

A.1. Aggregated On-Path Delay Examples 🦋

A.1.1. Template Record and Data Set with Mean Delta 🌸

with the encoding in Figure 2, the mean (average) path delay is calculated on the exporting node 🧮

  • Ingress interface => ingressInterface
  • Egress interface => egressInterface
  • IPv6 destination address => destinationIPv6Address
  • Active SRv6 Segment => srhActiveSegmentIPv6
  • Packet Delta Count => packetDeltaCount
  • Minimum One-Way Delay => pathDelayMinDeltaMicroseconds (531)
  • Maximum One-Way Delay => pathDelayMaxDeltaMicroseconds (532)
  • Mean One-Way Delay => pathDelayMeanDeltaMicroseconds (530)
 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.. = 530  |      Field Length = 4         |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0| pathDelayMinDelta.. = 531   |      Field Length = 4         |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0| pathDelayMaxDelta.. = 532   |      Field Length = 4         |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

     Figure 2: Template Record for pathDelayMeanDeltaMicroseconds

the data set is represented as follows 🫶

 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                 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

    Figure 3: Data Set Encoding for pathDelayMeanDeltaMicroseconds

A.1.2. Template Record and Data Set with Sum Delta 🧚

Okay bestie, this one's the sum version. With the encoding in Figure 4, the mean (average) path delay is calculated on the IPFIX data collection. 📊

  • Ingress interface => ingressInterface
  • Egress interface => egressInterface
  • IPv6 destination address => destinationIPv6Address
  • Active SRv6 Segment => srhActiveSegmentIPv6
  • Packet Delta Count => packetDeltaCount
  • Minimum One-Way Delay => pathDelayMinDeltaMicroseconds (531)
  • Maximum One-Way Delay => pathDelayMaxDeltaMicroseconds (532)
  • Sum of One-Way Delay => pathDelaySumDeltaMicroseconds (533)
    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.. = 531   |      Field Length = 4         |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |0| pathDelayMaxDelta.. = 532   |      Field Length = 4         |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |0| pathDelaySumDelta.. = 533   |      Field Length = 8         |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Figure 4: Template Record for pathDelaySumDeltaMicroseconds.

The data set is represented as follows, and honestly it's giving very neat little boxes. 🎀

    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                |
   |                          ...                                  |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Figure 5: Data Set Encoding for pathDelaySumDeltaMicroseconds

Acknowledgements 💜

The authors want to give a huge shoutout to 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 Velde, and Éric Vyncke for reviewing the work and leaving valuable comments. 🫶

Special thanks go to Paul Aitken (as IPFIX Designated Expert), Greg Mirsky (as IP Performance Metrics Designated Expert), and Med Boucadair for their very detailed feedback. Honestly, they went above and beyond. 👑

Authors' Addresses 🦋

Thomas Graf Swisscom Binzring 17 CH-8045 Zurich Switzerland Email: thomas.graf@swisscom.com

Benoit Claise Huawei Email: benoit@everything-ops.net

Alex Huang-Feng INSA-Lyon Lyon France Email: alex.huang-feng@insa-lyon.fr

📦 where this page comes from