Internet-Draft On-Path delay for IOAM March 2023
Huang Feng, et al. Expires 4 September 2023 [Page]
Workgroup:
Network Working Group
Internet-Draft:
draft-ahuang-ioam-on-path-delay-00
Published:
Intended Status:
Standards Track
Expires:
Authors:
A. Huang Feng
INSA-Lyon
P. Francois
INSA-Lyon
B. Claise
Huawei
T. Graf
Swisscom

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

Abstract

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.

Requirements Language

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.

Status of This Memo

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.

Table of Contents

1. Introduction

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

Section 3 describes the suggested solution and Section 4 describes the proposed IOAM data field.

2. Terminology

This document makes use of the following terms as defined in [RFC9197].

3. Solution overview

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:

                              IOAM Domain
              .........................................
              .                                       .
              .    D1                                 .
              . <------>                              .
              .                                       .
              .          D2                           .
              . <-------------------->                .
              .                                       .
              .                  D3                   .
              . <-----------------------------------> .
              .                                       .
(H1) ------ (R1) ------- (R2) ------- (R3) -------- (R4) ------ (H2)
Host 1  Encapsulation   Transit      Transit   Decapsulation  Host 2
            Node         Node 1       Node 2        Node
              .                                       .
              .                                       .
              .........................................

Figure 1: On-path delay use case. Packets flow from host 1 to host 2.

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

Section 3.1 describes how the delay is computed using the existing Trace-Type data fields and Section 3.2 describes how the delay can be calculated using a timestamp extension.

3.1. Using IOAM Trace-Option

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.

To export the On-path delay, a new bit in the IOAM Trace-Type bit field is required. Section 4 defines the data field.

Section 3.3 describes how the On-path delay metrics can be exported.

3.2. Using IOAM DEX Option

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.

Section 3.3 describes how the On-path delay metrics can be exported.

3.3. Export of On-path delay

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.

4. On-Path delay Data-field

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.

TBD
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                        On-Path Delay                          |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 2: On-Path delay Data-field Format

The Data-Field is allocated by IANA, as defined in Section 6.

5. Security Considerations

The security considerations for the IOAM Trace-Type and IOAM DEX Option-type are defined in [RFC9197] and in [RFC9326]. This document adds no additional security considerations.

6. IANA Considerations

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]

7. Acknowledgements

The authors would like to thank xxx for their review and valuable comments.

8. References

8.1. Normative References

[I-D.ahuang-ippm-dex-timestamp-ext]
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>.
[RFC2119]
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>.
[RFC8174]
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>.
[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, , <https://www.rfc-editor.org/info/rfc9197>.
[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, , <https://www.rfc-editor.org/info/rfc9326>.

8.2. Informative References

[I-D.ietf-opsawg-ipfix-on-path-telemetry]
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>.
[I-D.spiegel-ippm-ioam-rawexport]
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>.

Authors' Addresses

Alex Huang Feng
INSA-Lyon
Lyon
France
Pierre Francois
INSA-Lyon
Lyon
France
Benoit Claise
Huawei
Thomas Graf
Swisscom
Binzring 17
CH-8045 Zurich
Switzerland