The DEX Option-Type is used as a trigger for collecting IOAM data locally or exporting it to a receiving entity (or entities). Specifically, the DEX Option-Type can be used as a trigger for collecting IOAM data by an IOAM node and locally aggregating it; thus, this aggregated data can be periodically pushed to a receiving entity or pulled by a receiving entity on-demand.
This Option-Type is incorporated into data packets by an IOAM encapsulating node and removed by an IOAM decapsulating node, as illustrated in Figure 1
. The Option-Type can be read, but not modified, by transit nodes. Note that the terms "IOAM encapsulating node", "IOAM decapsulating node", and "IOAM transit node" are as defined in [RFC 9197
|Exported IOAM data
| | | |
| | | |
User +---+----+ +---+----+ +---+----+ +---+----+
packets |Encapsu-| | Transit| | Transit| |Decapsu-|
--------->|lating |====>| Node |====>| Node |====>|lating |---->
|Node | | A | | B | |Node |
+--------+ +--------+ +--------+ +--------+
Insert DEX Export Export Remove DEX
option and IOAM data IOAM data option and
export data export data
The DEX Option-Type is used as a trigger to collect and/or export IOAM data. The trigger applies to transit nodes, the decapsulating node, and the encapsulating node:
An IOAM encapsulating node configured to incorporate the DEX Option-Type encapsulates the packets (or possibly a subset of the packets) it forwards with the DEX Option-Type and MAY export and/or collect the requested IOAM data immediately. Only IOAM encapsulating nodes are allowed to add the DEX Option-Type to a packet. An IOAM encapsulating node can generate probe packets that incorporate the DEX Option-Type. These probe packets can be generated periodically or on-demand (for example, triggered by the management plane). The specification of such probe packets is outside the scope of this document.
A transit node that processes a packet with the DEX Option-Type MAY export and/or collect the requested IOAM data.
An IOAM decapsulating node that processes a packet with the DEX Option-Type MAY export and/or collect the requested IOAM data and MUST decapsulate the IOAM header.
As in [RFC 9197
], the DEX Option-Type can be incorporated into all or a subset of the traffic that is forwarded by the encapsulating node, as further discussed in Section 3.1.1
. Moreover, IOAM nodes respond to the DEX trigger by exporting and/or collecting IOAM data either for all traversing packets that carry the DEX Option-Type or selectively only for a subset of these packets, as further discussed in Section 3.1.2
If an IOAM encapsulating node incorporates the DEX Option-Type into all the traffic it forwards, it may lead to an excessive amount of exported data, which may overload the network and the receiving entity. Therefore, an IOAM encapsulating node that supports the DEX Option-Type MUST
support the ability to incorporate the DEX Option-Type selectively into a subset of the packets that are forwarded by the IOAM encapsulating node.
Various methods of packet selection and sampling have been previously defined, such as [RFC 7014
] and [RFC 5475
]. Similar techniques can be applied by an IOAM encapsulating node to apply DEX to a subset of the forwarded traffic.
The subset of traffic that is forwarded or transmitted with a DEX Option-Type SHOULD NOT
exceed 1/N of the interface capacity on any of the IOAM encapsulating node's interfaces. It is noted that this requirement applies to the total traffic that incorporates a DEX Option-Type, including traffic that is forwarded by the IOAM encapsulating node and probe packets that are generated by the IOAM encapsulating node. In this context, N is a parameter that can be configurable by network operators. If there is an upper bound, M, on the number of IOAM transit nodes in any path in the network, then it is RECOMMENDED
to use an N such that N >> M (i.e., N is much greater than M). The rationale is that a packet that includes a DEX Option-Type may trigger an exported packet from each IOAM transit node along the path for a total of M exported packets. Thus, if N >> M, then the number of exported packets is significantly lower than the number of data packets forwarded by the IOAM encapsulating node. If there is no prior knowledge about the network topology or size, it is RECOMMENDED
to use N>100.
The DEX Option-Type specifies which IOAM-Data-Fields should be exported and/or collected, as specified in Section 3.2
. As mentioned above, the data can be locally collected, aggregated, and/or exported to a receiving entity proactively or on-demand. If IOAM data is exported, the format and encapsulation of the packet that contains the exported data is not within the scope of the current document. For example, the export format can be based on [IOAM-RAWEXPORT
An IOAM node that performs DEX-triggered exporting MUST
support the ability to limit the rate of the exported packets. The rate of exported packets SHOULD
be limited so that the number of exported packets is significantly lower than the number of packets that are forwarded by the device. The exported data rate SHOULD NOT
exceed 1/N of the interface capacity on any of the IOAM node's interfaces. It is RECOMMENDED
to use N>100. Depending on the IOAM node's architecture considerations, the export rate may be limited to a lower number in order to avoid loading the IOAM node. An IOAM node MAY
maintain a counter or a set of counters that count the events in which the IOAM node receives a packet with the DEX Option-Type and does not collect and/or export data due to the rate limits.
IOAM nodes SHOULD NOT
be configured to export packets over a path or a tunnel that is subject to IOAM direct exporting. Furthermore, IOAM encapsulating nodes that can identify a packet as an IOAM exported packet MUST NOT
push a DEX Option-Type into such a packet. This requirement is intended to prevent nested exporting and/or exporting loops.
A transit or decapsulating IOAM node that receives an unknown IOAM-Option-Type ignores it (as defined in [RFC 9197
]); specifically, nodes that do not support the DEX Option-Type ignore it. As per [RFC 9197
], note that a decapsulating node removes the IOAM encapsulation and all its IOAM-Option-Types. Specifically, this applies to the case where one of these options is a (possibly unknown) DEX Option-Type. The ability to skip over a (possibly unknown) DEX Option-Type in the parsing or in the decapsulation procedure is dependent on the specific encapsulation, which is outside the scope of this document. For example, when IOAM is encapsulated in IPv6 [IOAM-IPV6-OPTIONS
], the DEX Option-Type is incorporated either in a Hop-by-Hop options header or in a Destination options header; thus, it can be skipped using the length field in the options header.
The format of the DEX Option-Type is depicted in Figure 2
. The length of the DEX Option-Type is at least 8 octets. The DEX Option-Type MAY
include one or more optional fields. The existence of the optional fields is indicated by the corresponding flags in the Extension-Flags field. Two optional fields are defined in this document: the Flow ID and Sequence Number fields. Every optional field MUST
be exactly 4 octets long. Thus, the Extension-Flags field explicitly indicates the length of the DEX Option-Type. Defining a new optional field requires an allocation of a corresponding flag in the Extension-Flags field, as specified in Section 4.2
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
| Namespace-ID | Flags |Extension-Flags|
| IOAM-Trace-Type | Reserved |
| Flow ID (Optional) |
| Sequence Number (Optional) |
A 16-bit identifier of the IOAM namespace, as defined in [RFC 9197].
An 8-bit field, comprised of 8 1-bit subfields. Flags are allocated by IANA, as defined in Section 4.2.
An 8-bit field, comprised of 8 1-bit subfields. Extension-Flags are allocated by IANA, as defined in Section 4.3. Every bit in the Extension-Flag field that is set to 1 indicates the existence of a corresponding optional 4-octet field. An IOAM node that receives a DEX Option-Type with an unknown flag set to 1 MUST ignore the corresponding optional field.
A 24-bit identifier that specifies which IOAM-Data-Fields should be exported. The format of this field is as defined in [RFC 9197]. Specifically, the bit that corresponds to the Checksum Complement IOAM-Data-Field SHOULD be assigned to be zero by the IOAM encapsulating node and ignored by transit and decapsulating nodes. The reason for this is that the Checksum Complement is intended for in-flight packet modifications and is not relevant for direct exporting.
This field MUST be ignored by the receiver.
The optional fields, if present, reside after the Reserved field. The order of the optional fields is according to the order of the respective bits, starting from the most significant bit, that are enabled in the Extension-Flags field. Each optional field is 4 octets long.
An optional 32-bit field representing the flow identifier. If the actual Flow ID is shorter than 32 bits, it is zero padded in its most significant bits. The field is set at the encapsulating node. The Flow ID can be used to correlate the exported data of the same flow from multiple nodes and from multiple packets. Flow ID values are expected to be allocated in a way that avoids collisions. For example, random assignment of Flow ID values can be subject to collisions, while centralized allocation can avoid this problem. The specification of the Flow ID allocation method is not within the scope of this document.
An optional 32-bit sequence number starting from 0 and incremented by 1 for each packet from the same flow at the encapsulating node that includes the DEX option. The Sequence Number, when combined with the Flow ID, provides a convenient approach to correlate the exported data from the same user packet.