|Internet-Draft||On-Path delay for IOAM||March 2023|
|Huang Feng, et al.||Expires 4 September 2023||[Page]|
- Network Working Group
- Intended Status:
- Standards Track
On-Path delay Data Field for In Situ Operations, Administration, and Maintenance (IOAM)
This document defines a Data Field In Situ Operations, Administration, and Maintenance (IOAM) architecture for on-path delay information. This data field is registered as a new entry in the "IOAM Trace-Type" registry.¶
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 Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.¶
Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet-Drafts is at https://datatracker.ietf.org/drafts/current/.¶
Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress."¶
This Internet-Draft will expire on 4 September 2023.¶
Copyright (c) 2023 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) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Revised BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Revised BSD License.¶
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 [RFC9197]. In postcard-based IOAM the delay is obtained using the timestamp extensions defined in [I-D.ahuang-ippm-dex-timestamp-ext].¶
The On-path delay is computed between the encapsulation node and the transit or decapsulation node of the IOAM-domain as shown in Figure 1. The calculated delays in Figure 1 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.¶
In passport-based IOAM this delay is exported using Pre-allocated Trace-Option and Incremental Trace-Option as defined in [RFC9197] and in postcard-based IOAM, the delay is computed using IOAM DEX Option as defined in [RFC9326].¶
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 [RFC9197], 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 [RFC9197].¶
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 [RFC9197] 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.¶
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 [RFC9326], 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 Section 4.¶
The timestamp reference needs to be added to the IOAM DEX Option-type header. [I-D.ahuang-ippm-dex-timestamp-ext] 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 [I-D.ahuang-ippm-dex-timestamp-ext], 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.¶
The export of the On-path delay is out of scope of this document. [I-D.spiegel-ippm-ioam-rawexport] proposes a way to export the raw IOAM header for both passport-mode and postcard-mode and [I-D.ietf-opsawg-ipfix-on-path-telemetry] proposes IPFIX Information Elements to allow aggregation before the export.¶
The "On-Path Delay" field type is a 4-octet unsigned integer. This field indicates the On-path delay between the encapsulation node and the transit or decapsulation node measured in microseconds.¶
This document requests IANA to add the following bit in the "IOAM Trace-Type" Registry.¶
Bit: [TBD] Description: On-path delay between the encapsulated node and the transit or decapsulation node measured in microseconds. Reference: [This-RFC-to-be]¶
- Huang Feng, A., Francois, P., Claise, B., and T. Graf, "Timestamp extension IOAM DEX", Work in Progress, Internet-Draft, draft-ahuang-ippm-dex-timestamp-ext-00, , <https://datatracker.ietf.org/doc/html/draft-ahuang-ippm-dex-timestamp-ext-00>.
- Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, , <https://www.rfc-editor.org/info/rfc2119>.
- Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, , <https://www.rfc-editor.org/info/rfc8174>.
- 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, , <https://www.rfc-editor.org/info/rfc9197>.
- 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, , <https://www.rfc-editor.org/info/rfc9326>.
- Graf, T., Claise, B., and A. H. Feng, "Export of On-Path Delay in IPFIX", Work in Progress, Internet-Draft, draft-ietf-opsawg-ipfix-on-path-telemetry-01, , <https://datatracker.ietf.org/doc/html/draft-ietf-opsawg-ipfix-on-path-telemetry-01>.
- Spiegel, M., Brockners, F., Bhandari, S., and R. Sivakolundu, "In-situ OAM raw data export with IPFIX", Work in Progress, Internet-Draft, draft-spiegel-ippm-ioam-rawexport-06, , <https://datatracker.ietf.org/doc/html/draft-spiegel-ippm-ioam-rawexport-06>.