| Internet-Draft | BIER Extension Headers | February 2024 |
| Zhang, et al. | Expires 28 August 2024 | [Page] |
Bit Index Explicit Replication (BIER) is a multicast technology with a new encapsulation and forwarding paradigm. BIER encapsulation is specified in RFC8296, and this document specifies extension headers used with BIER encapsulation 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 28 August 2024.¶
Copyright (c) 2024 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 Revised BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Revised BSD License.¶
[RFC8296] specifies BIER encapsulation header as following:¶
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 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |OAM|Rsv| DSCP | Proto | BFIR-id | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | BitString (first 32 bits) ~ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ~ ~ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ~ BitString (last 32 bits) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+¶
The header is fixed format, making it difficult to extend for additional functionalities.¶
[I-D.xzlnp-bier-ioam] describes In-situ Operations, Administration, and Maintenance (IOAM) functionality for BIER, and proposes a way to extend the BIER header to encode IOAM data as well as other potential extension headers.¶
[I-D.zzhang-intarea-generic-delivery-functions] considers Generic Delivery Functions (GDFs, e.g., fragmentation, security, IOAM) that can be applied to various layers (e.g., MPLS, IPv6, BIER) and proposes a slightly different extension header mechanism that is aligned with [I-D.song-mpls-extension-header] and work for both MPLS, BIER, and potentially other layers.¶
[I-D.song-mpls-extension-header] is not adopted in the MPLS WG. [I-D.jags-mpls-ps-mna-hdr] is the candidate solution, and the main difference is that the "next header" concept is no longer used, which means that IPv6 extension headers for GDFs can not be used as is. However, other than that it takes a different way to get to the ancillary data used for the functions, the data itself and the handling can still be generic.¶
To align BIER and MPLS for a generic solution, this document now takes the approach in [I-D.jags-mpls-ps-mna-hdr] for discussions and progressing in the BIER WG.¶
The following figure illustrates a BIER header with extension headers.¶
A TBD value for the "proto" field in the BIER header indicates that some BIER Extension Headers follow the BIER header and precede the BIER payload. An extension header could be an IPv6 one for a GDF like IOAM, even though this is not an IPv6 protocol layer.¶
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 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |OAM|R|H| DSCP | Proto=TBD | BFIR-id | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | BitString (first 32 bits) ~ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ~ ~ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ~ BitString (last 32 bits) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Extension Top Header | +---------------------------------------------------------------+ ~ Extension Header (EH) 1 ~ +---------------------------------------------------------------+ ~ ... ~ +---------------------------------------------------------------+ ~ Extension Header (EH) N ~ +---------------------------------------------------------------+ ~ Upper Layer Headers/Payload ~ +---------------------------------------------------------------+¶
R: The "R" flag bit is reserved. It MUST be set to 0 on transmission and ignored on reception.¶
H: If the "H" flag bit is set, it indicates the presence of at least one extension header that needs to be processed hop by hop even before a BFER is reached.¶
The Extension Top Header (ETH) encoding is as following:¶
0 1 2 3
0123456789012345 67890123 45678901
+--------------+-+--------+--------+
| Reserved |P| EHTL | NH |
+--------------+-+--------+--------+
Reserved: Reserved field.
P: 1-bit flag indicating the type of the NH field.
EHTL: 8-bit unsigned integer for the Extension Header Total Length
in 4-octet units. This field keeps the total length of the
extension headers in this packet, not including the ETH itself.
NH: 8-bit selector for the Next Header. This field identifies the
type of the header following the final extension header.
If the P-flag is set, the value is from the Internet Protocol
Numbers registry. If the P-flag is not set, the value is from
BIER's own protocol registry number registry, which is now
extended from the original 6-bit to 8-bit. Note that only
the first 64 values from the original registry can be used
in the Proto field in the base BIER header. If a larger value
is needed, the ETH MUST be used (with or without some Extension
Headers).
¶
A BIER capable router is smart enough to interpret the data afer the base BIER header only according to the Proto field, so there is no need to reserve a nibble at the begining of ETH to distinguish from an IP header.¶
The format of a BIER Extension Header (EH) mimics the MPLS Post-Stack Network Action Header [I-D.jags-mpls-ps-mna-hdr]:¶
0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | EH-OP |R|R| EH-Len | EH-DATA ~ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+¶
EH-OP: 7-bit OP Code for the extension. RR: 2-bit reserved field.¶
EH-LEN: 7-bit unsigned integer for the Extension Header Length in 4-octet units, not including the first four octets.¶
EH-Data:Data for the extension header. The first two octets are not counted in the EH-Len.¶
To be provided.¶
The following IANA actions are requested.¶