Internet-Draft BIER Extension Headers February 2024
Zhang, et al. Expires 28 August 2024 [Page]
Workgroup:
bier
Internet-Draft:
draft-zzhang-bier-extension-headers-03
Published:
Intended Status:
Standards Track
Expires:
Authors:
Z. Zhang
Juniper Networks
X. Min
ZTE
Y. Liu
China Mobile
H. Bidgoli
Nokia

BIER Extension Headers

Abstract

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.

Status of This Memo

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.

Table of Contents

1. 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.

2. Specifications

2.1. 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.

2.2. 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.

2.3. 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.

3. Security Considerations

To be provided.

4. IANA Considerations

The following IANA actions are requested.

5. References

5.1. Normative References

[RFC8296]
Wijnands, IJ., Ed., Rosen, E., Ed., Dolganow, A., Tantsura, J., Aldrin, S., and I. Meilik, "Encapsulation for Bit Index Explicit Replication (BIER) in MPLS and Non-MPLS Networks", RFC 8296, DOI 10.17487/RFC8296, , <https://www.rfc-editor.org/info/rfc8296>.

5.2. Informative References

[I-D.jags-mpls-ps-mna-hdr]
Rajamanickam, J., Gandhi, R., Zigler, R., Li, T., and J. Dong, "Post-Stack MPLS Network Action (MNA) Solution", Work in Progress, Internet-Draft, draft-jags-mpls-ps-mna-hdr-01, , <https://datatracker.ietf.org/doc/html/draft-jags-mpls-ps-mna-hdr-01>.
[I-D.song-mpls-extension-header]
Song, H., Zhou, T., Andersson, L., Zhang, Z. J., and R. Gandhi, "MPLS Network Actions using Post-Stack Extension Headers", Work in Progress, Internet-Draft, draft-song-mpls-extension-header-13, , <https://datatracker.ietf.org/doc/html/draft-song-mpls-extension-header-13>.
[I-D.xzlnp-bier-ioam]
Min, X., Zhang, Z., Liu, Y., Nainar, N. K., and C. Pignataro, "BIER Encapsulation for IOAM Data", Work in Progress, Internet-Draft, draft-xzlnp-bier-ioam-07, , <https://datatracker.ietf.org/doc/html/draft-xzlnp-bier-ioam-07>.
[I-D.zzhang-intarea-generic-delivery-functions]
Zhang, Z. J., Bonica, R., Kompella, K., and G. Mirsky, "Generic Delivery Functions", Work in Progress, Internet-Draft, draft-zzhang-intarea-generic-delivery-functions-03, , <https://datatracker.ietf.org/doc/html/draft-zzhang-intarea-generic-delivery-functions-03>.

Authors' Addresses

Zhaohui Zhang
Juniper Networks
Xiao Min
ZTE
Yisong Liu
China Mobile
Hooman Bidgoli
Nokia