rfc9951v1.txt		rfc9951.txt
	Internet Engineering Task Force (IETF) T. Graf		Internet Engineering Task Force (IETF) T. Graf
	Request for Comments: 9951 Swisscom		Request for Comments: 9951 Swisscom
	Category: Standards Track B. Claise		Category: Standards Track B. Claise
	ISSN: 2070-1721 Huawei		ISSN: 2070-1721 Huawei
	A. Huang-Feng		A. Huang-Feng
	INSA-Lyon		INSA-Lyon
	March 2026		April 2026
	Export of Delay Performance Metrics in IP Flow Information Export		Export of Delay Performance Metrics in IP Flow Information Export
	(IPFIX)		(IPFIX)
	Abstract		Abstract
	This document specifies new IP Flow Information Export (IPFIX)		This document specifies new IP Flow Information Export (IPFIX)
	Information Elements to export the On-Path delay at each Operations,		Information Elements to export the On-Path delay at each Operations,
	Administration, and Maintenance (OAM) transit and decapsulating		Administration, and Maintenance (OAM) transit and decapsulating
	nodes. The On-Path delay is defined as the delay between the OAM		nodes. The On-Path delay is defined as the delay between the OAM
	skipping to change at line 116 ¶		skipping to change at line 116 ¶
	Network operators usually maintain statistical views of delay across		Network operators usually maintain statistical views of delay across
	their networks to support diagnostics and performance analysis.		their networks to support diagnostics and performance analysis.
	These views assist in identifying the location, extent, and potential		These views assist in identifying the location, extent, and potential
	causes of abnormal delay affecting specific customer traffic or		causes of abnormal delay affecting specific customer traffic or
	services. To achieve this, delay-related metrics need to be reported		services. To achieve this, delay-related metrics need to be reported
	from devices covering both data and control planes. Further, in		from devices covering both data and control planes. Further, in
	order to understand which customers are affected, delay-related		order to understand which customers are affected, delay-related
	metrics need to be reported in the context of the customer data		metrics need to be reported in the context of the customer data
	plane. This correlation enables the detection of changes in		plane. This correlation enables the detection of changes in
	forwarding paths, such as updated intermediate hops or interfaces,		forwarding paths, such as updated intermediate hops or interfaces,
	and the resulting impact on delay experienced by customer traffic.		and of the resulting impact on delay experienced by customer traffic.
	Delay measurements in the network are computed using an On-Path		Delay measurements in the network are computed using an On-Path
	Telemetry protocol, which inserts metadata into the data-plane packet		Telemetry protocol, which inserts metadata into the data-plane packet
	when entering the monitored domain [RFC9232]. To compute delay		when entering the monitored domain [RFC9232]. To compute delay
	measurements, the On-Path Telemetry protocol inserts a timestamp		measurements, the On-Path Telemetry protocol inserts a timestamp
	reference when entering the OAM encapsulating node. Implementation		reference when entering the OAM encapsulating node. Implementation
	examples are In situ Operations, Administration, and Maintenance		examples are In situ Operations, Administration, and Maintenance
	(IOAM) [RFC9197] or Enhanced Alternate Marking [ENH-ALT-MARKING].		(IOAM) [RFC9197] or Enhanced Alternate Marking [ENH-ALT-MARKING].
	Two modes of On-Path Telemetry are generally recognized: passport		Two modes of On-Path Telemetry are generally recognized: passport
	skipping to change at line 238 ¶		skipping to change at line 238 ¶
	+-----------------------------+--------------------------------+		+-----------------------------+--------------------------------+
	| OWDelay_HybridType1_I | pathDelaySumDeltaMicroseconds |		| OWDelay_HybridType1_I | pathDelaySumDeltaMicroseconds |
	| P_RFC9951_Seconds_Sum (30) | (533) |		| P_RFC9951_Seconds_Sum (30) | (533) |
	+-----------------------------+--------------------------------+		+-----------------------------+--------------------------------+
	Table 1: Mapping Between IPFIX IEs and Performance Metrics		Table 1: Mapping Between IPFIX IEs and Performance Metrics
	Assuming time synchronization on devices, the delay is measured by		Assuming time synchronization on devices, the delay is measured by
	calculating the difference between the timestamp imposed with On-Path		calculating the difference between the timestamp imposed with On-Path
	Telemetry in the packet at an OAM header encapsulating node and the		Telemetry in the packet at an OAM header encapsulating node and the
	timestamp exported in the IPFIX flow record from the OAM header		timestamp exported in the IPFIX Flow Record from the OAM header
	transit and OAM header decapsulating nodes. The lowest, highest,		transit and OAM header decapsulating nodes. The lowest, highest,
	mean, and the sum of measured path delay can be exported, thanks to		mean, and the sum of measured path delay can be exported, thanks to
	the different IPFIX IE specifications.		the different IPFIX IE specifications.
	On-Path Telemetry Domain		On-Path Telemetry Domain
	.........................................		.........................................
	. .		. .
	. D1 .		. D1 .
	. x-------> .		. x-------> .
	. .		. .
	skipping to change at line 306 ¶		skipping to change at line 306 ¶
	All column entries besides the Identifier, Name, URI, Description,		All column entries besides the Identifier, Name, URI, Description,
	Reference Description (Output only) categories are the same; thus,		Reference Description (Output only) categories are the same; thus,
	this section defines four closely related performance metrics. As a		this section defines four closely related performance metrics. As a
	result, IANA has assigned corresponding URIs to each of the four		result, IANA has assigned corresponding URIs to each of the four
	registered performance metrics.		registered performance metrics.
	4.1.1. Summary		4.1.1. Summary
	This category includes multiple indexes of the registered performance		This category includes multiple indexes of the registered performance
	metrics: the element Identifier and Metric Name.		metrics: the Identifier and Metric Name.
	4.1.1.1. ID (Identifier)		4.1.1.1. ID (Identifier)
	IANA has allocated the numeric Identifiers 27, 28, 29, and 30 for the		IANA has allocated the numeric Identifiers 27, 28, 29, and 30 for the
	four Named Metric Entries in the following section.		four Named Metric Entries in the following section.
	4.1.1.2. Name		4.1.1.2. Name
	27: OWDelay_HybridType1_IP_RFC9951_Seconds_Mean		27: OWDelay_HybridType1_IP_RFC9951_Seconds_Mean
	skipping to change at line 513 ¶		skipping to change at line 513 ¶
	4.4.1. Type		4.4.1. Type
	OWDelay Types are discussed in the subsections below.		OWDelay Types are discussed in the subsections below.
	4.4.2. Reference Definition		4.4.2. Reference Definition
	For all output types:		For all output types:
	OWDelay_HybridType1_IP: The one-way delay of one IP packet is a		OWDelay_HybridType1_IP: The one-way delay of one IP packet is a
	Singleton.		singleton.
	For each <statistic> Singleton, one of the following subsections		For each <statistic> singleton, one of the following subsections
	applies.		applies.
	4.4.2.1. OWDelay_HybridType1_IP_RFC9951_Seconds_Mean		4.4.2.1. OWDelay_HybridType1_IP_RFC9951_Seconds_Mean
	Similar to Section 7.4.2.2 of [RFC8912], the mean SHALL be calculated		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		using the conditional distribution of all packets with a finite value
	of one-way delay (undefined delays are excluded) -- a single value,		of one-way delay (undefined delays are excluded) -- a single value,
	as follows:		as follows:
	See Section 4.1 of [RFC3393] for details on the conditional		See Section 4.1 of [RFC3393] for details on the conditional
	skipping to change at line 836 ¶		skipping to change at line 836 ¶
	7.1. Time Accuracy		7.1. Time Accuracy
	In terms of clock precision, the same recommendation as defined in		In terms of clock precision, the same recommendation as defined in
	Section 4.5 of [RFC5153] for IPFIX applies to this document as well.		Section 4.5 of [RFC5153] for IPFIX applies to this document as well.
	7.2. Mean Delay		7.2. Mean Delay
	The mean (average) path delay can be calculated by dividing the		The mean (average) path delay can be calculated by dividing the
	pathDelaySumDeltaMicroseconds(533) by the packetDeltaCount(2) at the		pathDelaySumDeltaMicroseconds(533) by the packetDeltaCount(2) at the
	IPFIX data collection in order to offload the IPFIX Exporter from		IPFIX data collection at the collection time instead of the IPFIX
	calculating the mean for every Flow at export time.		Exporter at the export time.
	7.3. Reduced-Size Encoding		7.3. Reduced-Size Encoding
	Unsigned64 has been chosen as the type for		Unsigned64 has been chosen as the type for
	pathDelaySumDeltaMicroseconds to support cases with large delay		pathDelaySumDeltaMicroseconds to support cases with large delay
	numbers and where many packets are being accounted. As an example, a		numbers and where many packets are being accounted. As an example, a
	specific Flow Record with path delay of 100 milliseconds cannot		specific Flow Record with path delay of 100 milliseconds cannot
	observe more than 42949 packets without overflowing the unsigned32		observe more than 42949 packets without overflowing the unsigned32
	counter. The procedure described in Section 6.2 of [RFC7011] may be		counter. The procedure described in Section 6.2 of [RFC7011] may be
	applied to reduce network bandwidth between the IPFIX Exporter and		applied to reduce network bandwidth between the IPFIX Exporter and
End of changes. 7 change blocks.
	8 lines changed or deleted		8 lines changed or added
This html diff was produced by rfcdiff 1.48.