| Internet-Draft | BIER Encap for IOAM Data | January 2021 |
| Min, et al. | Expires 12 July 2021 | [Page] |
In-situ Operations, Administration, and Maintenance (IOAM) collects operational and telemetry information while the packet traverses a particular network domain. Bit Index Explicit Replication (BIER) 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 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 fields are encapsulated in BIER header.¶
This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.¶
Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet-Drafts is at https://datatracker.ietf.org/drafts/current/.¶
Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress."¶
This Internet-Draft will expire on 12 July 2021.¶
Copyright (c) 2021 IETF Trust and the persons identified as the document authors. All rights reserved.¶
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.¶
In-situ Operations, Administration, and Maintenance (IOAM) collects operational and telemetry information while the packet traverses a particular network domain. [I-D.ietf-ippm-ioam-data] defines different IOAM data fields used to record various telemetry data from the transit nodes. The term "in-situ" refers to the fact that the IOAM data fields are added to the data packets rather than being sent within packets specifically dedicated to OAM.¶
Bit Index Explicit Replication (BIER), as defined in [RFC8279], 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 [RFC8296], 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 fields are encapsulated in BIER header.¶
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 [RFC2119] [RFC8174] 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¶
GRE: Generic Routing Encapsulation¶
IOAM: In-situ Operations, Administration, and Maintenance¶
OAM: Operations, Administration, and Maintenance¶
[I-D.ietf-bier-use-cases] 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 packet. Performance measurement function defined in [I-D.ietf-bier-pmmm-oam] can be used for measuring packet loss and delay. This document attempts to provide a way to collect on-path operational and telemetry information through in-situ OAM.¶
The BIER header is defined in [RFC8279]. The BIER OAM header that follows BIER header is defined in [I-D.ietf-bier-ping]. 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 the different IOAM-Data-Fields defined in [I-D.ietf-ippm-ioam-data].¶
In an administrative domain where IOAM is used, insertion of the IOAM header in BIER is enabled at the BFIRs, which also serve as IOAM encapsulating nodes by means of configuration, deletion of the IOAM header in BIER is enabled at the BFERs, which also serve as IOAM decapsulating nodes by means of configuration.¶
The Encapsulation format for IOAM over BIER is defined as follows:¶
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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+<-+ | BIFT-id | TC |S| TTL | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |Nibble | Ver | BSL | Entropy | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ B |OAM|Rsv| DSCP |Proto = TBD| BFIR-id | I +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ E | BitString (first 32 bits) ~ R +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ~ ~ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ~ BitString (last 32 bits) | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+<-+ | IOAM-Type | IOAM HDR Len | Reserved | Next Proto| | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ I | | O | | A ~ IOAM Option and Data Space ~ M | | | | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+<-+ | | | | | Payload + Padding (L2/L3/...) | | | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The BIER header and fields are defined in [RFC8296]. 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 TBD when the IOAM header is present.¶
The IOAM related fields in BIER are defined as follows:¶
Multiple IOAM-Option-Types MAY be included within the BIER encapsulation. For example, if a BIER encapsulation contains two IOAM-Option-Types preceding a data payload, the Next Proto field of the first IOAM option will contain the value of TBD, while the Next Proto field of the second IOAM option will contain the "BIER Next Protocol" number indicating the type of the data payload. Each IOAM Option-Type MUST occur at most once within the same BIER encapsulation header.¶
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 options described in section 4 are supposed to be feasible, nevertheless this document needs to select one as standardized encapsulation for IOAM over BIER. Considering the fact that the encapsulation format 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 option 2 is selected as the standardized one.¶
[RFC8296] defines a two-bits long field, referred to as OAM. [I-D.ietf-bier-pmmm-oam] describes how to use the two-bits OAM field for alternate marking performance measurement method, and this document would not change the semantics of the two-bits OAM field. The BIER IOAM header and the BIER two-bits OAM field are orthogonal and can co-exist in the same packet header, i.e. a BIER packet with IOAM data can set the OAM field or not, and a BIER packet with OAM field set can also carry IOAM data or not.¶
This document does not raise any additional security issues beyond those of the specifications referred to in the list of normative references.¶
In the "BIER Next Protocol Identifiers" registry defined in [RFC8296], a new Next Protocol Value for IOAM is requested from IANA as follows:¶
| BIER Next Protocol Identifier | Description | Semantics Definition | Reference |
|---|---|---|---|
| TBD | In-situ OAM (IOAM) | Section 4 | This Document |
The authors would like to acknowledge Greg Mirsky for his thorough review and very helpful comments.¶