ISIS Extensions for BIER in Non-MPLS Networks

Bit Index Explicit Replication (BIER) is an architecture that provides multicast forwarding through a "BIER domain" without requiring intermediate routers to maintain multicast related per-flow state. BIER can be supported in MPLS and non-MPLS networks. The common BIER header format and encapsulation for MPLS and non-MPLS networks is specified in . As stated in , the encapsulation of Initial Four Octets in BIER header for MPLS and non-MPLS networks are different. In particular, the first 20-bits of the BIER header (referred as BIFT-id) is a "MPLS Label" in case of MPLS networks and is a "domain-wide-unique-value" representing the combination of SD-BSL-SI in case of non-MPLS networks. BIER in Ethernet encapsulation is an example of BIER encapsulation in non-MPLS networks. BIER in Ethernet encapsulation(BIER-ETH): Ethernet header is immediately followed by the BIER header. In this type of encapsulation, the EtherType field in the Ethernet header is set to 0xAB37 which is assigned by IEEE for non-MPLS BIER packets as stated in . Processing and forwarding of multicast packets using the BIER-ETH encapsulation requires special software and hardware capabilities. The BFRs supporting this encapsulation type MUST advertise this capability (along with the other required parameters specific to the encapsulation) to the other routers in BIER domain. This advertisement, for example, will enable the other BFRs in the BIER domain in deciding, whether to include or exclude the advertising router from the BAR and/or IPA algorithm while computing the multicast path for a specific encapsulation type. specifies the required extensions to the IS-IS protocol for the distribution of BIER sub-domain information including the Sub-sub-TLVs required to support BIER in MPLS encapsulation for MPLS networks. This document specifies the required extensions to the IS-IS protocol for supporting BIER in non-MPLS networks using BIER in Ethernet encapsulation. Support for other encapsulation types are outside the scope of this document. In case of multiple encapsulation types supported by a BFR in a BIER sub-domain, the selection of a encapsulation type to be used for a BIER sub-domain is outside the scope of this document.

Some of the terminology specified in is replicated here and extended by necessary definitions: Bit Index Explicit Replication (The overall architecture of forwarding multicast using a Bit Position). BIER in MPLS encapsulation. (Encapsulation of BIER header inside MPLS header in MPLS networks). BIER in Ethernet encapsulation. (Encapsulation of BIER header inside Ethernet header (EtherType=0xAB37) in non-MPLS networks). Bit Forwarding Router (A router that participates in Bit Index Multipoint Forwarding). A BFR is identified by a unique BFR- prefix in a BIER domain. Bit Index Forwarding Table used to forward the BIER packets in a domain. BIER Algorithm. Used to calculate underlay nexthops as defined by the BAR value. IGP Algorithm. May be used to modify, enhance or replace the calculation of underlay paths as defined by the BAR value

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.

BIER Info sub-TLV defined in is used to advertise the sub-domain id, and other associated parameters of the sub-domain like BFR-id, MT, BAR, IPA. This document introduces new sub-sub-TLVs under BIER Info sub-TLV to advertise the encapsulation capability and other associated parameters of the encapsulation. A BIER sub-domain MAY support multiple BIER encapsulation types like BIER-MPLS, BIER-ETH. Within a BIER sub-domain, it is very well possible and allowable to share the same BFR-id for a BFR across different encapsulation types. If the operator wishes to use different BFR-id for different encapsulation types, then he MUST provision different BIER sub-domain for each encapsulation type. The selection of encapsulation type to be used by a BFIR or BFR for a sub-domain could be a matter of local policy and is outside the scope of this document. As described in Section 2.2.1.1 of , In non-MPLS networks, a BIFT-id MUST be assigned for every combination of <SD, SI, BSL> that is to be used in that network. Two possible means by which the BIFT-ids are assigned for a <SD, SI, BSL> are described in . As an example, suppose a particular BIER domain contains a SD (SD 0), supports two BSLs (256 and 512), and contains 1024 BFRs. A BFR that is provisioned for above SD, and that supports both BSLs, would have to advertise the following set of BIFT-id's: BIFT-id 1: corresponding to SD 0, BSL 256, SI 0. BIFT-id 2: corresponding to SD 0, BSL 256, SI 1. BIFT-id 3: corresponding to SD 0, BSL 256, SI 2. BIFT-id 4: corresponding to SD 0, BSL 256, SI 3. BIFT-id 5: corresponding to SD 0, BSL 512, SI 0. BIFT-id 6: corresponding to SD 0, BSL 512, SI 1. In such case, a BFR MUST assign a contiguous range of BIFT-ids as, BIFT-id range [1 to 4] correspond to <SD 0, BSL 256>. The first BIFT-id in the range correspond to SI=0, the second correspond to SI=1, and so on. BIFT-id range [5 to 6] correspond to <SD 0, BSL 512>. The first BIFT-id in the range correspond to SI=0, the second correspond to SI=1.

This sub-sub-TLV carries the information for the BIER Ethernet encapsulation including the BitString length supported for a certain <MT,SD> pair. It is advertised within the BIER Info sub-TLV defined in which in-turn is carried within the TLVs 235, 237 or TLVs 135 , or TLV 236 . This sub-sub-TLV MAY appear multiple times within a single BIER Info sub-TLV. If the same BitString length is repeated in multiple BIER Ethernet encapsulation sub-sub-TLVs inside the same BIER Info sub-TLV, the BIER Info sub-TLV MUST be ignored.

2 (suggested value - To be assigned by IANA). 4 1 octet. Maximum Set Identifier (Section 1 of [RFC8279]) used in the encapsulation for this BIER subdomain for this BitString length. The first BIFT-id is for SI=0, the second BIFT-id is for SI=1, etc. If the BIFT-id associated with the Maximum Set Identifier exceeds the 20-bit range, the sub-sub-TLV MUST be ignored.. 4 bits. Encoded bitstring length as per . 20 bits. First BIFT-id of the BIFT-id range. The "BIFT-id range" is the set of 20-bit values beginning with the BIFT-id and ending with (BIFT-id + (Max SI)). A unique BIFT-id range is allocated for each BitString length and sub-domain-id. These BIFT-id's are used for BIER forwarding as described in and . The size of the BIFT-id range is determined by the number of SI's (Section 1 of ) that are used in the network. Each SI maps to a single BIFT-id in the BIFT-id range: the first BIFT-id is for SI=0, the second BIFT-id is for SI=1, etc. If the BIFT-id associated with the Maximum Set Identifier exceeds the 20-bit range, the BIER Ethernet Encapsulation Sub-sub-TLV containing the error MUST be ignored.

Security concerns for IS-IS are addressed in and and the security concerns for IS-IS extensions for BIER are addressed in . This document introduces new sub-sub-TLV for the already existing IS-IS TLVs defined for distributing the BIER sub-domain information in . It does not introduce any new security risks to IS-IS.

The document requests new allocations from the IS-IS registries as follows

BIER Ethernet Encapsulation sub-sub-TLV: 2 (suggested)

The author wants to thank Jeffrey (Zhaohui) Zhang and Antonie Przygienda for their comments and suggestions.