Supporting IOAM in IPv6

In-situ OAM (IOAM) defines two trace options, the pre-allocated trace option and the incremental trace option, which record hop-by-hop data along a packet's forwarding path. describes a method to encapsulate IOAM pre-allocated trace option data fields in IPv6. Because the trace options require per-hop processing, such options can only be encapsulated in the IPv6 Hop-by-Hop (HbH) Options header. mandates that the HbH Options header, if present, must be the first extension header following the IPv6 header. However, the IOAM trace data can be large, amounting to tens or hundreds of bytes, which makes it difficult or even impossible for some routers to access the headers that follow it. There are practical limitations on how far forwarding hardware can reach into a packet. The IOAM trace option cannot be applied if it makes other extension headers inaccessible. Even if the other headers can be reached, the deeper they are, the higher the cost to access and process them, and the lower the forwarding performance. Note that does not support the incremental trace option, because it would expand the HbH header at each hop and push back all the headers that follow it. The changing location of the later extension headers could further complicate the hardware implementation and degrade forwarding performance. The issue becomes more severe when SRv6 and IOAM coexist. The Segment Routing Extension Header (SRH) is encapsulated in a routing header, which follows the HbH Options header. The SRH itself can be large, and it requires read and write operations at each SRv6 segment endpoint node. If it is deeply embedded in a packet and its location keeps shifting, either it is beyond the reach of the hardware or the forwarding performance degrades. We can avoid the problem by not using both at the same time, but this is not ideal, because IOAM is an important OAM tool and it is even more desirable when SRv6 introduces additional operational complexity into IPv6 networks. A second recourse is to limit IOAM to SRv6 nodes only. That is, to consider SRv6 as an overlay tunnel over IPv6 and apply the IOAM pipe mode as discussed in , which only collects data at each SRv6 segment endpoint node. To realize this, describes an approach that encapsulates the IOAM option data fields in an SRH TLV, and describes another approach that enables postcard-based telemetry for SRv6 without needing IOAM option encapsulation. In either case, the SRH is close to the front of the packet and its location is fixed. While these approaches are useful for use cases that only need to monitor the segment endpoints, they fail to cover all the IPv6 nodes on the packet forwarding path in an IOAM domain. The proposition of this draft is as follows: if we need to apply IOAM on all nodes in an SRv6 network, how can we amend the approach in or use alternative approaches to circumvent the aforementioned issues? In this draft, we propose two viable approaches: (1) separating the IOAM trace data from the instruction header into a different extension header option placed after the routing header (if one exists), and (2) applying the segment IOAM trace export scheme. We discuss the pros and cons of each approach.

The IOAM trace-type data fields contain two parts: the instruction and the trace data. Although by convention the trace data part immediately follows the instruction part, there is no fundamental reason why these two parts must be kept together. This observation provides an optimization opportunity to amend the original proposal in . We separate the IOAM trace-type data fields into the instruction part and the trace data part. We encapsulate only the instruction part in the HbH Options header, and encapsulate the trace data part in another extension header option placed after all the IPv6 extension headers that need to be examined and processed on the packet forwarding path (e.g., a routing header). This arrangement allows us to use the incremental trace option efficiently. Even if the trace data increases in size at each node, all IPv6 extension headers before it remain a fixed size, and new data is guaranteed to be inserted at a fixed location. Figure 1 shows the HbH option format for the IOAM incremental trace type instruction. The field specification is identical to that in and .

Figure 2 shows the TLV option format for the IOAM trace type data. The IOAM trace type data format is compliant with .

There are basically two methods to encapsulate the IOAM incremental trace data. First, we can define a new IPv6 extension header dedicated to metadata. Once standardized, this extension header could also be used to host potential metadata from other applications, such as NSH for SFC . Second, this option can be carried as a TLV option in an existing extension header, such as the Destination Options header (DOH). The only requirement is that this extension header be the last one in the extension header chain. The first method is cleaner, but it requires standardizing a new extension header type; the second method is simpler, but it needs to overcome the access constraints imposed by .

If the overhead of the IOAM trace-type data fields is under control, we may still manage to encapsulate both the instruction and the data in the HbH Options header as described in . To this end, we introduce two sub-approaches.

proposes an enhancement to the IOAM trace type that can configure the allowable overhead of the IOAM trace-type data fields. Once the trace data size reaches the limit at a network node (i.e., a segment, or a fixed number of network nodes, has been traversed), the trace data is stripped and exported so that room is made to accommodate new trace data from nodes in the next segment of the forwarding path. This approach requires some moderate updates to the IOAM trace-type data fields, as described in . Figure 3 shows the format of the HbH Option header containing segment IOAM trace-type data fields. A flag bit (#23) in the Flags field is used to indicate that the current header is a segment IOAM header. In this context, the last octet in the IOAM header is partitioned into two 4-bit nibbles. The first nibble (SSize) is used to save the segment size, and the second nibble (RHop) is used to save the remaining hops. This limits the maximum segment size to 15.

At the beginning of each segment, the segment size (SSize) and the remaining hops (RHop) are initialized: RHop is set equal to SSize. At each hop, if RHop is not zero, the node data is added to the node data list and then RHop is decremented by 1. If RHop is equal to 0 when the packet is received, the node needs to remove (in the incremental trace option) or clear (in the pre-allocated trace option) the IOAM node data list and reset RHop to SSize. In this case, if we use the IOAM pre-allocated trace type, the size and location of each IPv6 extension header are fixed and predictable, and the hardware capability and performance can be guaranteed.

Whenever a packet with the IOAM option reaches an SRv6 segment endpoint node that needs to access the SRH, we can configure the node to immediately export the IOAM trace data accumulated so far. In this case, at each SRv6 segment endpoint node, after the trace data export, the HbH header size is fixed and the header contains an IOAM option with only the instruction part. After the SRH processing, this node can add local IOAM trace data to the HbH option header before forwarding the packet. The incremental trace type is more appropriate than the pre-allocated trace type in this approach, due to the uncertainty in the number of hops between two segment endpoints. In an extreme case where every node is also an SRv6 node, this approach regresses to a per-hop postcard-based telemetry approach such as IOAM DEX, as described in .

It is worth noting that, instead of using the IOAM trace options, the IOAM Direct Export (DEX) option type can be used for fixed and small packet overhead, since it only needs to encapsulate a fixed-size instruction header in the HbH Options header. This scheme is covered in .

The following table compares the existing approach (RFC 9486) with the alternative approaches discussed in this draft.

The IOAM trace option is easy to implement and extensible in its data types. Complementary to , the scalable solutions for using it in IPv6 networks discussed in this document can fully realize the benefits of the IOAM trace option while avoiding the potential issues associated with variable and high header overhead.

No new security issue is identified other than those for the IOAM trace option , IOAM DEX , and IPv6 extension headers .

This document requires no IANA actions.