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

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

Copyright Notice

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

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

• IOAM-domain¶
• IOAM encapsulation node¶
• IOAM transit node¶
• IOAM decapsulation node¶

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:¶

• 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.¶

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

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

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                          |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

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

Authors' Addresses