| Internet-Draft | Transit Measurement | June 2024 |
| Mizrahi, et al. | Expires 5 December 2024 | [Page] |
This document specifies an IPv6 option that contains a compact set of fields which can be used for transit delay measurement and congestion detection. This option can be incorporated into data packets and updated by transit nodes along the path, enabling lightweight measurement and monitoring using constant-length data that does not depend on the number of hops in the network.¶
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 5 December 2024.¶
Copyright (c) 2024 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.¶
This document introduces an IPv6 option that includes a compact set of performance-related fields. This option can be incorporated into data packets and updated by transit nodes along the path.¶
There is a number of in-progress documents in the IETF that define IPv6 options that can be used for tracing a path and its performance, including for example, [RFC9486], [I-D.filsfils-ippm-path-tracing], [I-D.ali-spring-ioam-srv6], [I-D.kumar-ippm-ifa], [I-D.zhou-ippm-enhanced-alternate-marking]. Some of these extensions use per-hop fields which are updated by intermediate nodes, collecting information about the performance along the path. While these extension provide detailed and fine-grained information, they incur high per-packet bandwidth and processing overhead.¶
The Transit Measurement option, which is defined in this document, provides coarse-grained performance information using a set of fields that have a constant length that does not depend on the number of hops along the path. These fields are defined as a new IPv6 option type, referred to as the Transit Measurement option.¶
The Transit Measurement option includes two main fields: Accumulated Delay and Status Bitmap. The Accumulated Delay field is used for measuring the one-way delay along the path. Each transit node incrementally adds its internal transit delay to the Accumulated Delay field, and thus at the end of the path this field includes the sum of the transit delay values of the nodes along the path. The Status Bitmap field includes a per-hop bit that indicates its congestion status. Each node along the path updates its corresponding status bit, indicating whether the node is congested. The criterion for deciding whether a node is congested is similar to the "Congestion Experienced" trigger in ECN [RFC3168].¶
The Transit Measurement option can be incorporated into all or a subset of the traffic that is forwarded by the source node. Notably, the Transit Measurement option adds a fixed and low overhead to data packets, which remains constant along the path.¶
There are several potential use cases for the Transit Measurement option, including:¶
Performance Monitoring: the Transit Measurement option can be used for continuously tracking the network and for detecting a potentially problematic state that requires further analysis. In case a potential problem is detected by the destination node, the node may take further steps to report and to analyze the problem. For example, the node can export the packet, along with additional telemetry data to a collector, or it may log the problem locally. Upon detecting such a problem, a centralized collector/analyzer may trigger a more fine-grained measurement, e.g., an IOAM trace option [RFC9197] can be enabled in order to obtain detailed information about the performance along the path and to pinpoint the potential problem. It should be noted that logging, exporting, and further analysis by the central entity are not within the scope of the current document.¶
Path Selection: in a network that uses segment routing a source can choose which of the available paths to use to each destination. By using the Transit Measurement option the source can probe each of the available paths to a given destination, and choose the path with the best performance. If there is a performance issue along one of the paths, the fine-grained status bitmap enables the source to pinpoint the location of the issue, and to try to pick an alternative path that avoids this point. Alternatively, a path can be selected by the combination of the measured delay along the path and the status bitmap; for example, the path with less bits set in the status bitmap can be the preferred path, and the measured delay can be used as a tiebreaker.¶
Congestion control: existing congestion control algorithms periodically measure the round-trip time (RTT), and can optionally use ECN indications as a criterion for determining the congestion window. It has been shown [SIGCOMM-HPCC] that congestion control can benefit from using fine-grained information about the congestion state of the routers along the path that is sent back to the source over acknowledgment packets. The Transit Measurement option provides fine-grained measurement information that has a lightweight cost in comparison to alternative per-hop measurement protocols.¶
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.¶
Abbreviations used in this document:¶
This document defines a new IPv6 Option type, the Transit Measurement type, which can be included either in the Hop-by-Hop Options header or in the Destination Options header. Figure 1 presents the format of the Transit Measurement option type.¶
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Option Type | Opt Data Len |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Accumulated Delay |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Hop Count | Status Bitmap |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
A node that complies to this draft MUST support the following fields, as depicted in Figure 1:¶
indicates the devices along the path that have experienced congestion.¶
The Transit Option, and specifically the Accumulated Delay field, which is defined in this document, may be used for reconnaissance, which in turn can facilitate other types of attacks. As in other types of Operations, Administration and Maintenance (OAM) protocols, a malicious attacker can manipulate the Accumulated Delay value in order to create a false illusion of nonexistent network issues or prevent the detection of actual ones.¶