BIER Encapsulation for IOAM Data

In-situ Operations, Administration, and Maintenance (IOAM) collects operational and telemetry information in the packet while the packet traverses a path between two points in the network. defines four IOAM option types with different IOAM data fields used to record OAM information within the packet. defines IOAM Direct Export (DEX) option type, which indicates OAM information to be collected without being embedded in the data packets. The term "in-situ" refers to the fact that the OAM data is added to the data packets rather than being sent within packets specifically dedicated to OAM. Bit Index Explicit Replication (BIER), as defined in , is an architecture that provides optimal multicast forwarding through a "multicast domain", without requiring intermediate routers to maintain any per-flow state or to engage in an explicit tree-building protocol. The BIER header, as defined in , contains a bit-string in which each bit represents exactly one egress router to forward the packet to. This document outlines the requirements to carry IOAM data in BIER header and specifies how IOAM data is encapsulated.

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 when, and only when, they appear in all capitals, as shown here.

Abbreviations used in this document: BFER: Bit Forwarding Egress Router BFIR: Bit Forwarding Ingress Router BIER: Bit Index Explicit Replication DEX: Direct Export GRE: Generic Routing Encapsulation IOAM: In-situ Operations, Administration, and Maintenance OAM: Operations, Administration, and Maintenance

lists many use cases for BIER. Usually there are many multicast flows within one network domain, and some of the multicast flows, such as live video and real-time meeting, are sensitive to packet loss, delay and other factors. The network operator wants to know the real-time statistics for these flows, such as delay, sequence, the ingress/egress interface, and the usage of buffer. So methods are needed for measuring the real-time transportation guarantee of BIER packets. This document attempts to provide a way to carry IOAM data in the BIER packets.

The BIER header is defined in . The BIER OAM header that follows BIER header is defined in . IOAM-Data-Fields can either be carried in BIER using a new type of OAM message which follows the BIER OAM header (referred to as option 1), or be carried in BIER using a new next protocol header which immediately follows the BIER header (referred to as option 2). In this document, option 2 is selected and the reason is discussed in Section 5.1. An IOAM header is added containing different IOAM-Data-Fields defined in and . [Editor's Note: Except for aforementioned option 1 and 2, IOAM-Data-Fields can also be carried in BIER extension header , which is referred to as option 3. Once there is WG consensus to adopt BIER extension header, the selected BIER IOAM Encapsulation would be changed from option 2 to option 3.] In a BIER domain where IOAM is applied, inserting the IOAM header into the BIER packets is enabled at the BFIRs, which also serve as the IOAM encapsulating nodes by means of configuration. Deleting the IOAM header from the BIER packets is enabled at the BFERs, which also serve as the IOAM decapsulating nodes by means of configuration. The Encapsulation format for IOAM over BIER is defined as follows:

The BIER header and fields are defined in . Within the BIER header, a 6-bit field as "Proto" (Next Protocol) is used to identify the type of the payload immediately following the BIER header, The "Proto" value is set to TBA1 when the IOAM header is present. The IOAM related fields in BIER are defined as follows: IOAM-Type: An 8-bit field defining the IOAM option type, as defined in Section 7.1 of and Section 4.1 of . IOAM HDR Len: An 8-bit unsigned integer. Length of the IOAM header in 4-octet units. Reserved: A 10-bit reserved field MUST be set to zero upon transmission and ignored upon receipt. Next Proto: A 6-bit unsigned integer that identifies the type of payload immediately following this IOAM option. The semantics of this field are identical to the "Proto" field in . IOAM Option and Optional Data Space: IOAM option header and data as specified by the IOAM-Type field. They're defined in Section 4 of and Section 3 of . Multiple IOAM options MAY be included within a BIER encapsulation. For example, if a BIER encapsulation contains two IOAM options preceding a data payload, the "Next Proto" field of the first IOAM option would be set to the value of TBA1 that indicates a second IOAM option follows, while the "Next Proto" field of the second IOAM option would be set to the value of "BIER Next Protocol" indicating the type of the data payload. Each type of IOAM option MUST occur at most once within a BIER encapsulation. Note that in a BIER multicast network, if the IOAM Trace option is carried in the BIER packets, when the BIER packets are replicated at the branch nodes, the IOAM Trace option would be replicated too. In a case it's a concern to the network operator, the IOAM DEX option may be used as a substitution, or other methods beyond the scope of this document can be applied.

This section summarizes a set of considerations on the overall approach taken for IOAM data encapsulation in BIER, as well as deployment considerations.

Both the encapsulation options for IOAM over BIER described in Section 4 are supposed to be feasible, nevertheless this document needs to select one as the standardized encapsulation. Considering the fact that the encapsulation format of option 2 using a new next protocol header is more concise than option 1 using a new type of OAM message, and many other transport protocols, e.g., GRE, use a new next protocol header to encapsulate IOAM data, the encapsulation format of option 2 is selected as the standardized one.

defines a two-bit field, referred to as OAM. describes how to use the two-bit OAM field for alternate-marking performance measurement method. This document would not change the semantics of the two-bit OAM field. The BIER IOAM header and the BIER OAM field are orthogonal and they can co-exist in one packet, i.e., a BIER packet with IOAM data can set the OAM field and a BIER packet with OAM field set can carry IOAM data.

This document describes the encapsulation of IOAM data in BIER. Security considerations of the specific IOAM data are described in and . IOAM is considered a "per domain" feature, where one or several operators decide on configuring IOAM according to their needs. IOAM is expected to be deployed in a limited domain . As such, it assumes that a node involved in IOAM operation has previously verified the integrity of the path. Still, the operators need to properly secure the IOAM domain to avoid malicious configuration and use, which could include injecting malicious IOAM packets into the domain. As this document describes new protocol fields within the existing BIER encapsulation, these are similar to the security considerations of .

In the "BIER Next Protocol Identifiers" registry created for , a new Next Protocol Value for IOAM is requested from IANA as follows: BIER Next Protocol Identifier Description Semantics Definition Reference TBA1 In-situ OAM (IOAM) Section 4 This Document

The authors would like to acknowledge Greg Mirsky for his thorough review and very helpful comments.