4. Performance Metrics
This section preserves the RFC text for IPFIX delay performance metric export, including On-Path Telemetry, OAM nodes, Flow Records, performance metric IDs 27-30, IPFIX Information Elements 530-533, IANA registrations, operational guidance, and encoding examples.
Original RFC Text
4. Performance Metrics
This section defines four new performance metrics following the
template defined in 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 have been registered in the IANA
"Performance Metrics Registry" [IANA-PERF-METRIC].
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.
4.1.1. Summary
This category includes multiple indexes of the registered performance
metrics: the Identifier and Metric Name.
4.1.1.1. ID (Identifier)
IANA has allocated the numeric Identifiers 27, 28, 29, and 30 for the
four Named Metric Entries in the following 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:
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] somewhere in the network.
OWDelay_HybridType1_IP_RFC9951_Seconds_Min:
This metric assesses the minimum of one-way delays of all
successfully forwarded IP packets constituting a single Flow. The
measurement of one-way delay is based on a single Observation
Point [RFC7011] somewhere in the network.
OWDelay_HybridType1_IP_RFC9951_Seconds_Max:
This metric assesses the maximum of one-way delays of all
successfully forwarded IP packets constituting a single Flow. The
measurement of one-way delay is based on a single Observation
Point [RFC7011] somewhere in the network.
OWDelay_HybridType1_IP_RFC9951_Seconds_Sum:
This metric assesses the sum of one-way delays of all successfully
forwarded IP packets constituting a single Flow. The measurement
of one-way delay 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 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".
4.2.1. Reference Definition
See [RFC6049] and [RFC7679] in the Normative References
(Section 9.1).
Section 3.4 of [RFC7679] provides the reference definition of the
singleton (single value) one-way delay metric. Section 4.4 of
[RFC7679] provides the reference definition expanded to cover a
multi-value sample. Note that terms such as "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 requires
one individual measurement between the Observation Point and sourcing
host, such that the Spatial Composition [RFC6049] of the measurements
yields 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 includes columns for references to relevant sections of
the RFC(s) and any supplemental information needed to ensure 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 application at a mid-path Observation Point [RFC7011].
4.3.2. Packet Stream Generation
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, Section 4.4.1 of [RFC9197]
describes the supported timestamps. Sections 4.4.2.3 and 4.4.2.4 of
[RFC9197] describe where the timestamp is being 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
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.
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:
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