On-Path delay Data Field for In Situ Operations, Administration, and Maintenance (IOAM)

Network operators want to measure the On-Path delay of the customers packets across their networks to determine where how much delay has been accumulated for a given application to optimize and maintain their networks. This document proposes an IOAM Trace-Type data field and its associated bit field to export delay measurements. The delay measurements is obtained in passport-based IOAM based on the "timestamp seconds" and "timestamp fractions" Trace-Type data fields defined in . In postcard-based IOAM the delay is obtained using the timestamp extensions defined in . describes the suggested solution and describes the proposed IOAM data field.

The On-path delay is computed between the encapsulation node and the transit or decapsulation node of the IOAM-domain as shown in . The calculated delays in are computed as following: D1: delay between the encapsulation node R1 and the transit node R2. D2: delay between the encapsulation node R1 and the transit node R3. D3: delay between the encapsulation node R1 and the decapsulation node R4.

. . . . D2 . . <--------------------> . . . . D3 . . <-----------------------------------> . . . (H1) ------ (R1) ------- (R2) ------- (R3) -------- (R4) ------ (H2) Host 1 Encapsulation Transit Transit Decapsulation Host 2 Node Node 1 Node 2 Node . . . . ......................................... ]]> In passport-based IOAM this delay is exported using Pre-allocated Trace-Option and Incremental Trace-Option as defined in and in postcard-based IOAM, the delay is computed using IOAM DEX Option as defined in . describes how the delay is computed using the existing Trace-Type data fields and describes how the delay can be calculated using a timestamp extension.

In passport-based IOAM, telemetry data is added to the data-plane packet at each node of the IOAM-domain and all collected metrics are exported by the decapsulation node. Pre-allocated Trace Option-type and Incremental Trace Option-type, as defined in Section 4.4 of , is used to transport the different metrics. The exported metrics are defined by the bit field in IOAM Trace-Type as defined in Section 4.4.1 of . To compute the delay at the transit and decapsulation node, a timestamp reference from the encapsulation node is added. Bit 2 (timestamp seconds) and bit 3 (timestamp fraction) from the IOAM Trace-type field is used for this purpose and at each node, the On-path delay is computed using the delay from the encapsulation and the current node. To export the On-path delay, a new bit in the IOAM Trace-Type bit field is required. defines the data field. describes how the On-path delay metrics can be exported.

In postcard-based IOAM, telemetry data is exported at the transit nodes and decapsulation node of the IOAM domain. The telemetry data is aggregated at each node before being exported to a collector. DEX Option-type, as defined in , is used for this purpose. The exported telemetry data is defined in IOAM Trace-Type bit field. The export of the On-path delay is based on the On-Path Delay field defined in . The timestamp reference needs to be added to the IOAM DEX Option-type header. defines an extension to allow the timestamp being added in the encapsulation node. Bit 2 (timestamp seconds) and bit 3 (timestamp fraction) from the IOAM DEX Extension-Flags, defined in , are used to add this time reference. At each transit and decapsulation node, the difference between the timestamp in the header and the current timestamp is computed. describes how the On-path delay metrics can be exported.

The export of the On-path delay is out of scope of this document. proposes a way to export the raw IOAM header for both passport-mode and postcard-mode and proposes IPFIX Information Elements to allow aggregation before the export.