BIER Extension Headers
Zhaohui Zhang
Juniper Networks
zzhang@juniper.net
Xiao Min
ZTE
xiao.min2@zte.com.cn
Yisong Liu
China Mobile
liuyisong@chinamobile.com
Hooman Bidgoli
Nokia
hooman.bidgoli@nokia.com
25 February 2024
Routing
bier
extension header
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.
Background
[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.
Specifications
BIER Encapsulation with Extension Headers
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.
Extension Top Header
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.
Extension Header Format
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.
Security Considerations
To be provided.
IANA Considerations
The following IANA actions are requested.
- Assign a "BIER Extension Header" value from the "BIER Next Protocol Identifiers" registry for the "proto" field in a BIER header.
- Create a "BIER Extension Header OP Codes" registry for the "EH-OP" field in a BIER specific extension header.

Normative References

Informative References
[RFC8296]
[I-D.xzlnp-bier-ioam]
[I-D.zzhang-intarea-generic-delivery-functions]
[I-D.song-mpls-extension-header]
[I-D.jags-mpls-ps-mna-hdr]