Inband OAM (IOAM) is an implementation study to record operational information in the packet while the packet traverses a path between two points in the network.

Overview of IOAM can be found in IOAM-Devnet page. The following IETF drafts detail the motivation and mechanism for recording operational information:

IOAM-ietf-requirements - Describes motivation and usecases for IOAM
IOAM-ietf-data - Describes data records that can be collected using IOAM
IOAM-ietf-transport - Lists out the transport protocols and mechanism to carry IOAM data records
IOAM-ietf-proof-of-transit - Describes the idea of Proof of Transit (POT) and mechanisms to operationalize the idea

Terminology

IOAM is expected to be deployed in a specific domain rather than on the overall Internet. The part of the network which employs IOAM is referred to as **"IOAM-domain"**.

IOAM data is added to a packet on entering the IOAM-domain and is removed from the packet when exiting the domain. Within the IOAM-domain, network nodes that the packet traverses may update the IOAM data records.

The node which adds IOAM data to the packet is called the **"IOAM encapsulating node"**.
The node which removes the IOAM data is referred to as the **"IOAM decapsulating node"**.
Nodes within the domain which are aware of IOAM data and read and/or write or process the IOAM data are called **"IOAM transit nodes"**.

Features supported in the current release

VPP can function as IOAM encapsulating, transit and decapsulating node and collect:
- IOAM Tracing information at each hop the packet traverses
- Sequence number using IOAM Edge-to-Edge option to detect packet loss, duplicate, reordering
- Proof of transit - to prove packet flow through a set of checkpoint nodes in the IOAM domain
VPP can transport IOAM metadata for native IPv6 and VXLAN-GPE encapsulated packets
At the IOAM decapsulating node the data captured can be exported as IPFIX records
At the IOAM decapsulation node the data collected can be analysed and summary reported via IPFIX

Using the above IOAM features in VPP following solutions are available:

IOAM based UDP pinger detailed description of this can be found UDP-Pinger for IPv6 with IOAM
IOAM IPFIX Analyser detailed description of this can be found IOAM Analyser for IPv6
M-Anycast server using IOAM and SRv6 detailed description of this can be found IOAM and SRv6 for M-Anycast service selection

The following IOAM options are supported:

IOAM Tracing : IOAM supports multiple data records to be recorded in the packet as the packet traverses the network. These data records offer insights into the operational behavior of the network. The following information can be collected in the tracing data from the nodes a packet traverses:
- Node ID
- Ingress interface ID
- Egress interface ID
- Timestamp
- Pre-configured application data
IOAM Proof of Transit (POT): Proof of transit IOAM data is added to every packet for verifying that a packet traverses a specific set of nodes. IOAM data is updated at every node that is enabled with IOAM proof of transit and is used to verify whether a packet traversed all the specified nodes. When the verifier receives each packet, it can validate whether the packet traversed the specified nodes.
IOAM sequence number: IOAM defined Edge-to-Edge(E2E) Option is to carry data that is added by the IOAM encapsulating node and interpreted by IOAM decapsulating node. Currently only sequence numbers use the IOAM Edge-to-Edge option. In order to detect packet loss, packet reordering, or packet duplication in an IOAM-domain, sequence numbers can be added to packets

Configuration for deploying IOAM for IPv6 is explained in IOAM for IPv6 Configuration for deploying IOAM for VXLAN-GPE is explained in IOAM over VxLAN-GPE