Unmasked BIER Mode

BIER technology in its standard form may suffer from a degradation towards ingress replication in a scenario where the total number of involved BFRs is very large but most packets address varying combination of relatively few receivers spread across different sets. More explicitly, BIER carries in its standard form a bitmask of successive BFR receivers represented as bits in a set and thus on large numbers of involved BFRs and few receivers w/o customized allocation of BFR IDs or application awareness of the address locality each receiver on a packet may be found in a different set in most extreme cases. Obviously, when receivers are in different sets, multiple packets must be sent, one per involved set. Such a scenario can become common in large distributed computation environments based on consensus building algorithms (or building closures by successive folding of results), e.g. multi-CPU HPC or data centers and RAID storage where storing data while addressing large number of always changing stripes can lead to this kind of anomaly.

To deal with the problem of small number of receivers spread across many sets we introduce into BIER a special interpretation of the bitmask field called unmasked BIER or U-BIER for brevity's sake. U-BIER bitmask is interpreted as sequence of BFR-IDs that can belong to different sets and be interspersed with "holes" consisting of illegal BFR-IDs to increase hardware processing efficiency. Support for processing of unmasked BIER is indicated by signalling special label or its equivalent analogous to BIER Encapsulation signalling. Based on this info the upstream node can decide on a hop-by-hop basis whether it compresses the same BIER frames it received for different sets (how the recognition of same frames is performed is outside the scope of this document) into a single U-BIER frame or propagates a U-BIER frame with according changes, i.e. only providing the BFR-IDs for which the receiver is responsible. The removal of BFR IDs from the packet before forwarding it is completely analogous to the normal bitmask processing in a sense but here spanning possibly many sets in the lookup engine. In case the downstream receiver does not support U-BIER the frame needs to be replicated into according standard BIER frames with usual bitmask interpretation.

The bitmask field MUST be interpreted in U-BIER mode as sequence of BFR-IDs (as an example, within 256 bits maximum 16 receivers can be encoded) whereas illegal BFR-IDs are allowed in any position and MUST be ignored. Duplicates are also allowed and MUST be treated as a single occurrence. No guarantees are provided in terms of sorting of the BFR-IDs in U-BIER.

The signalling follows the BIER MPLS Encapsulation Sub-sub-TLV, i.e. it is <MT,SD,BML> specific but obviously does not include the concept of a set.

Type: TBD1 Length: 4 * of U-Mode BitString Length specific labels. Reserved: MUST be 0 on send and ignored on reception. Label: Frames received on this label interpret the BitMask as U-BIER. In case multiple values are advertised for same bitstring length, the sub-sub-TLV MUST be ignored. In case same label value is advertised for different bitstring lengths, the sub-sub-TLV MUST be ignored. Label values MUST NOT match any of the reserved values defined in .

U-BIER can be deployed within existing BIER node by node, either as addition or the only mode supported. Observe that in an environment where only some nodes support U-BIER those may have to disaggregate U-BIER into normal BIER and hence fall back to average replication. In a network where some nodes support only U-BIER normal BIER nodes may consider them not supporting BIER at all or may perform translation from normal BIER into U-BIER frames, however, it must be expected that they will use a single frame and basically send U-BIER with the BFR IDs of a single set only, not rendering any gains unless a mechanism is in place the same frame is detected sent on multiple sets and coalesced into a single U-BIER frame. This can be achieved by many mechanisms out the scope of this draft, amongst them a shim after the BIER encapsulation in way similar to inband telemetry or fragmentation support. Mixing U-BIER and normal BIER within a subdomain can lead to difficulties of decoding the according packets in the middle in terms of destinations targeted if the involved parties in the middle do not possess the correct binding information. An obvious method to deal with this problem is to deploy U-BIER specifically in its own sub-domain where the interpretation of the bitmask is unambiguous.

TBD

Michael Menth and Toerless Eckert mentioned the problem and approaches to address it in open forums for the first time.