Internet DRAFT - draft-ahuang-ioam-on-path-delay
draft-ahuang-ioam-on-path-delay
Network Working Group A. Huang Feng
Internet-Draft P. Francois
Intended status: Standards Track INSA-Lyon
Expires: 4 September 2023 B. Claise
Huawei
T. Graf
Swisscom
3 March 2023
On-Path delay Data Field for In Situ Operations, Administration, and
Maintenance (IOAM)
draft-ahuang-ioam-on-path-delay-00
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.
Huang Feng, et al. Expires 4 September 2023 [Page 1]
Internet-Draft On-Path delay for IOAM March 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 . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Solution overview . . . . . . . . . . . . . . . . . . . . . . 3
3.1. Using IOAM Trace-Option . . . . . . . . . . . . . . . . . 4
3.2. Using IOAM DEX Option . . . . . . . . . . . . . . . . . . 4
3.3. Export of On-path delay . . . . . . . . . . . . . . . . . 5
4. On-Path delay Data-field . . . . . . . . . . . . . . . . . . 5
5. Security Considerations . . . . . . . . . . . . . . . . . . . 5
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 5
7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 6
8. References . . . . . . . . . . . . . . . . . . . . . . . . . 6
8.1. Normative References . . . . . . . . . . . . . . . . . . 6
8.2. Informative References . . . . . . . . . . . . . . . . . 6
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 7
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.
Huang Feng, et al. Expires 4 September 2023 [Page 2]
Internet-Draft On-Path delay for IOAM March 2023
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
. .
. .
.........................................
Huang Feng, et al. Expires 4 September 2023 [Page 3]
Internet-Draft On-Path delay for IOAM March 2023
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.
Huang Feng, et al. Expires 4 September 2023 [Page 4]
Internet-Draft On-Path delay for IOAM March 2023
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.
Huang Feng, et al. Expires 4 September 2023 [Page 5]
Internet-Draft On-Path delay for IOAM March 2023
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,
February 2023, <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, March 1997,
<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,
May 2017, <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,
May 2022, <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, November 2022,
<https://www.rfc-editor.org/info/rfc9326>.
8.2. Informative References
Huang Feng, et al. Expires 4 September 2023 [Page 6]
Internet-Draft On-Path delay for IOAM March 2023
[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, 16 February 2023,
<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, 21 February 2022,
<https://datatracker.ietf.org/doc/html/draft-spiegel-ippm-
ioam-rawexport-06>.
Authors' Addresses
Alex Huang Feng
INSA-Lyon
Lyon
France
Email: alex.huang-feng@insa-lyon.fr
Pierre Francois
INSA-Lyon
Lyon
France
Email: pierre.francois@insa-lyon.fr
Benoit Claise
Huawei
Email: benoit.claise@huawei.com
Thomas Graf
Swisscom
Binzring 17
CH-8045 Zurich
Switzerland
Email: thomas.graf@swisscom.com
Huang Feng, et al. Expires 4 September 2023 [Page 7]
