Multicast On-Path Telemetry Using In Situ Operations, Administration, and Maintenance (IOAM)
Extracted elements (21)
At a branch fork node in the per-section postcard solution, only common data shared by all replicated packets (e.g., ingress interface and ingress timestamp) can be exported in the postcard, because branch-specific data (egress timestamp, egress interface, node delay) differs per copy.
In the per-section postcard solution, each branch fork node exports accumulated trace data in a postcard before replicating the packet, then clears the IOAM node data list and resets RemainingLen. This avoids redundancy while preserving per-branch telemetry, with no modification needed to the IOAM trace option header format.
IOAM trace option applied to multicast causes data redundancy because each replicated packet carries a complete trace at tree leaves. Most trace data (except the final leaf branch) appears in multiple copies, wasting bandwidth and complicating processing; the problem scales with tree size and path length.
Postcard-based solutions like IOAM DEX eliminate data redundancy for multicast but cannot accurately track tree branches because they lack a branch identifier. Without branching information, it is impossible to determine from postcards alone whether a downstream node is the next hop of one branch or another.
The Multicast Branch ID is composed of Branching Node ID plus an Interface Index to achieve global uniqueness. A branch fork node assigns one identifier per outgoing branch (e.g., [B,0] for branch to C, [B,1] for branch to D), which remains unchanged until the next branch fork node.
Two Extension-Flag bits (N and I) are required to signal the Multicast Branch ID field rather than one, because RFC 9326 specifies that each extension flag indicates the presence of only a 4-octet optional data field, whereas the Multicast Branch ID requires 8 octets.
For IPv6 multicast packets, IOAM telemetry instruction headers and metadata can be encapsulated using IPv6 options as described in RFC 9486. The telemetry solution must work within the IPv4 multicast range 224.0.0.0–239.255.255.255 and IPv6 ff00::/8.
IOAM and the recommendations of this document are equally applicable to multicast MPLS forwarded packets in MVPN environments using mLDP, P2MP RSVP-TE, Ingress Replication, or PIM MDT SAFI with GRE. The telemetry instruction header and data should be encapsulated into MPLS packets on P2MP and MP2MP paths.
Mtrace2 (RFC 8487) does not integrate with IOAM directly, but network management systems may use Mtrace2 to discover routers of interest for configuring IOAM-based telemetry. The two mechanisms are complementary rather than interoperable at the protocol level.
Each node that receives IOAM DEX header with a branch identifier MUST export that branch identifier in the postcards it sends, so the original multicast tree can be correctly reconstructed.
Once a node obtains branch ID information from the upstream node, it MUST carry this information in its telemetry data export postcards so the original multicast tree can be correctly reconstructed.
The three unused octets in the Multicast Branch ID MUST be set to 0; if they are not, the header is considered malformed and the packet MUST be dropped.
The two Extension-Flag bits N and I for the Multicast Branch ID MUST be both set or both cleared; if they differ, the header is considered malformed and the packet MUST be dropped.
Multicast telemetry requirements addressed by this document include: reconstructing and visualizing the multicast tree via data-plane monitoring, gathering per-path packet delay and jitter, and finding packet-drop location and reason. Conventional OAM mechanisms (multicast ping, Mtrace2, RTCP) are insufficient to meet all three requirements.
The Per-Hop Postcard solution extends IOAM DEX with a Multicast Branch ID field so that each node on the multicast tree exports a postcard containing only its local data plus the branch identifier, enabling the data collector to reconstruct multicast tree topology from the postcards.
The Per-Section Postcard solution combines IOAM trace option with postcard-based telemetry. Branch fork nodes and leaf nodes export postcards containing the accumulated trace section, then refresh the IOAM header (clear node data list, reset RemainingLen) before the packet continues, eliminating redundant data without modifying the trace option header format.
IANA registered two new bits in the 'IOAM DEX Extension-Flags' registry: bit 2 for 'Multicast Branching Node ID' and bit 3 for 'Multicast Branching Interface Index', both referencing RFC 9630.
The DEX-based multicast telemetry scheme carries greater amplification risk than unicast because multicast has a built-in packet amplification nature. Stricter protection mechanisms are required, including selective packet sampling, export traffic rate limiting, and optionally restricting DEX processing to a subset of nodes such as only branching nodes.
The schemes in this document inherit all security considerations from the IOAM trace option (RFC 9197) and the IOAM DEX option (RFC 9326), including concerns about unauthorized data insertion, traffic observation, and export channel security.
The Multicast Branch ID field is 8 octets: a 3-octet Branching Node ID (unsigned integer per RFC 9197 node ID spec), 1 unused octet, a 2-octet Interface Index (unsigned integer), and 2 unused octets. Unused octets MUST be set to 0.
The Multicast Branch ID is carried as an optional field after the Flow ID and Sequence Number fields in the IOAM DEX Option-Type header. Its presence is indicated by two new Extension-Flag bits: bit 2 (N, Branching Node ID) and bit 3 (I, Interface Index), which MUST both be set or both be cleared.