RFC 8296

Encapsulation for Bit Index Explicit Replication (BIER) in MPLS and Non-MPLS Networks

📅 published January 2018, from ietf

RFC 8296 💖

Encapsulation for Bit Index Explicit Replication (BIER) in MPLS and Non-MPLS Networks ✨

Okay bestie, this one is the IETF's Experimental spec (category: Experimental 🧪) and it's written up as RFC 8296 in January 2018 📅. The ISSN is 2070-1721. It's from the IETF, and the editors are IJ. Wijnands (Cisco Systems, Inc.), E. Rosen (Juniper Networks, Inc.), A. Dolganow (Nokia), J. Tantsura (Individual), S. Aldrin (Google, Inc.), and I. Meilik (Broadcom) 👯‍♀️. Wijnands and Rosen are the editors, so they get the "Ed." tag. The header doesn't list any Obsoletes or Updates entries, so this one isn't replacing or changing anything listed there 🙌.

Abstract 🌸

Okay, so BIER is an architecture that gets multicast forwarding done in an optimal way across a "multicast domain" 🦋. The big flex is that the middle routers don't need to keep any per-flow state, and they don't have to run an explicit tree-building protocol either 💅. When a multicast packet enters the domain, the ingress router figures out which egress routers need it, then wraps the packet in a BIER header 🎀. That header holds a bit string where each bit stands for exactly one egress router in the domain. To send the packet to a set of egress routers, you just set the bits for those routers 🍓. How the encapsulation looks depends on what kind of network the multicast domain runs on. This doc specifies a BIER encapsulation that works in an MPLS network, or in a non-MPLS network with a few slight differences 🧚.

Status of This Memo 💜

Not gonna lie, this doc is not an Internet Standards Track spec ❌. It's published so people can examine it, try it out in experimental implementations, and evaluate it 🔬.

It defines an Experimental Protocol for the Internet community 🌈. It's a product of the IETF and it represents the consensus of the IETF community ✅. It got public review and the IESG approved it for publication 👑. Not every IESG-approved doc qualifies for any level of Internet Standard, though. For more on that, check Section 2 of RFC 7841 🤓.

Info about the current status of this doc, any errata, and how to send feedback lives at https://www.rfc-editor.org/info/rfc8296 🔗.

Copyright (c) 2018 IETF Trust and the persons identified as the document authors. All rights reserved ©️.

This doc is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) as they stand on the date of publication. Please read these carefully, because they spell out your rights and restrictions for this doc 📜. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions, and they come without warranty as described in the Simplified BSD License ⚖️.

Table of Contents 📚

   1. Introduction ....................................................3
   2. BIER Header .....................................................5
      2.1. In MPLS Networks ...........................................5
           2.1.1. Encapsulation Initial Four Octets ...................5
                  2.1.1.1. The BIER-MPLS Label ........................5
                  2.1.1.2. Other Fields of the Initial Four Octets ....8
           2.1.2. Remainder of Encapsulation ..........................9
           2.1.3. Further Encapsulating a BIER Packet ................12
      2.2. In Non-MPLS Networks ......................................13
           2.2.1. Encapsulation Initial Four Octets ..................13
                  2.2.1.1. The BIFT-id ...............................13
                  2.2.1.2. Other Fields of the Initial Four Octets ...13
           2.2.2. Remainder of Encapsulation .........................14
           2.2.3. Further Encapsulating a BIER Packet ................15
   3. Imposing and Processing the BIER Encapsulation .................16
   4. IANA Considerations ............................................18
   5. IEEE Considerations ............................................18
   6. Security Considerations ........................................19
   7. References .....................................................20
      7.1. Normative References ......................................20
      7.2. Informative References ....................................21
   Acknowledgements ..................................................22
   Contributors ......................................................22
   Authors' Addresses ................................................24

1. Introduction 🦋

Okay, so [RFC8279] is the doc that lays out this new architecture for forwarding multicast data packets 🌟. It's called "Bit Index Explicit Replication" (BIER), and it gives you optimal forwarding of multicast data packets through a "multicast domain" 💅. The best part is that it skips any explicit tree-building protocol and doesn't make the intermediate nodes keep any per-flow state 🙌.

This document will use terminology defined in [RFC8279] 📖.

A router that supports BIER is called a "Bit-Forwarding Router" (BFR) 🧚. A "BIER domain" is a connected set of BFRs, and each one has been given a BFR-prefix. A BFR-prefix is a routable IP address of a BFR, and BIER uses it to identify that BFR 🎯. A packet enters a BIER domain at a Bit-Forwarding Ingress Router (BFIR) and leaves at one or more Bit-Forwarding Egress Routers (BFERs) 🚪. As [RFC8279] specifies, each BFR in a given BIER domain is provisioned to be in one or more "sub-domains" (SDs) 🍰. Within a given SD, every BFIR and BFER needs a BFR-id that's unique inside that SD. A BFR-id is just a number in the range [1,65535] that identifies a BFR uniquely relative to a BIER SD 🔢.

As [RFC8279] explains, BIER needs multicast data packets to be encapsulated with a header that carries the info needed for the BIER forwarding procedures 📦. That info includes the SD the packet was assigned to, a Set Identifier (SI), a BitString, and a BitStringLength (BSL). Together these values identify the set of BFERs the packet has to reach 🎯.

This doc defines an encapsulation that works in either MPLS networks or non-MPLS networks 🌈. The construction and processing of the BIER header is a little different in MPLS networks than in non-MPLS networks, though. Specifically:

  • The handling of certain fields in the encapsulation header (the "BIER header") depends on whether the underlying network is an MPLS network or not 💖.
  • In an MPLS network, the first four octets of a BIER header are also the bottom entry (the last four octets) of an MPLS label stack 🥞.

The MPLS-based encapsulation gets the full treatment in Section 2.1 ✨. The differences between the MPLS-based and non-MPLS encapsulations are covered in Section 2.2 💅.

After the BIER header comes the "payload" 🎁. The payload may be an IPv4 packet, an IPv6 packet, an Ethernet frame, an MPLS packet, or an Operations, Administration, and Maintenance (OAM) packet. (BIER can also carry other payload types, but this doc doesn't go into them.) The BIER header has info (the Next Protocol field) that says what type of payload it is 🏷️.

If the payload is an MPLS packet, an MPLS label stack sits right after the BIER header 🥞. The top label of that stack can be either a downstream-assigned label [RFC3031] or an upstream-assigned label [RFC5331] 🔝.

Now the magic words. The BCP 14 key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" are how this doc says what's required, and they only count when they're written in ALL CAPS, exactly as shown. They're interpreted as described in BCP 14 [RFC2119] [RFC8174] 🤓⚠️.

2. BIER Header 🎀

The BIER header is shown in Figure 1 👀.

      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)                      |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                           Figure 1: BIER Header

The BIFT-id stands for a particular Bit Index Forwarding Table (BIFT). Check out Section 6.4 of [RFC8279] 📋. As explained in [RFC8279], each BIFT lines up with one specific combo of SD, BSL, and SI 🧩.

Section 2.1 walks through how the encapsulation fields get used in MPLS networks 🥞. For fields that get used differently in non-MPLS networks, Section 2.2 spells out the differences 🌈.

The default BitStringLength value for the encapsulations in this doc is 256 💯. See Section 3 of [RFC8279] for the discussion of the default BitStringLength value 📖.

2.1. In MPLS Networks 🧚

2.1.1. Encapsulation Initial Four Octets ✨

2.1.1.1. The BIER-MPLS Label

okay so, bestie, this is where the BIER-MPLS label comes in 🎀 As [RFC8279] spells out, when a BIER domain is also an IGP domain, each BFR can use IGP extensions to advertise its BFR-id and BFR-prefix 🌸 The OSPF extensions are in [OSPF_BIER_EXTENSIONS] and the IS-IS ones are in [ISIS_BIER_EXTENSIONS] 💅

When a particular BIER domain is both an IGP domain AND an MPLS network, we assume each BFR will also use IGP extensions to advertise a set of one or more "BIER-MPLS" labels ✨ If the domain has a single SD, a given BFR needs to advertise one such label for each combination of SI and BSL. If the domain has multiple SDs, a BFR needs to advertise one label per SI per BSL for each SD 🧚

In some environments the only routing protocol in a BIER domain might be BGP 🦋 In that case, the BGP extensions in [BGP_BIER_EXTENSIONS] can be used to advertise the necessary set of BIER-MPLS labels.

The BIER-MPLS labels are locally significant (i.e., unique only to the BFR that advertises them) downstream-assigned MPLS labels 💜 Penultimate hop popping [RFC3031] MUST NOT be applied to a BIER-MPLS label. No exceptions, no cap 🙅‍♀️

Suppose, for example, that there is a single SD (the default SD), that the network is using a BSL of 256, and that all BFERs in the SD have BFR-ids in the range [1,512]. Since each BIER BitString is 256 bits long, this needs two SIs: SI=0 and SI=1 🍓 So each BFR will advertise, via IGP extensions, two MPLS labels for BIER: one for SI=0 and one for SI=1. Advertising these labels also binds each label to the default SD and to BSL 256 🌈

As another example, suppose a BIER domain has two SDs (SD 0 and SD 1), supports two BSLs (256 and 512), and contains 1024 BFRs. A BFR that is provisioned for both SDs and supports both BSLs would have to advertise this set of BIER-MPLS labels 👑

L1:   corresponding to SD 0, BSL 256, SI 0.

L2:   corresponding to SD 0, BSL 256, SI 1.

L3:   corresponding to SD 0, BSL 256, SI 2.

L4:   corresponding to SD 0, BSL 256, SI 3.

L5:   corresponding to SD 0, BSL 512, SI 0.

L6:   corresponding to SD 0, BSL 512, SI 1.

L7:   corresponding to SD 1, BSL 256, SI 0.

L8:   corresponding to SD 1, BSL 256, SI 1.

L9:   corresponding to SD 1, BSL 256, SI 2.

L10:  corresponding to SD 1, BSL 256, SI 3.

L11:  corresponding to SD 1, BSL 512, SI 0.

L12:  corresponding to SD 1, BSL 512, SI 1.

Okay, but don't panic 😭 The example above should NOT be read as meaning BFRs need to advertise 12 individual labels! For instance, instead of advertising a label for <SD 1, BSL 512, SI 0> and a label for <SD 1, BSL 512, SI 1>, a BFR could advertise a contiguous range of labels (in this case, a range of exactly two labels) corresponding to <SD 1, BSL 512>. The first label in the range could correspond to SI 0, and the second to SI 1 ✨ The precise mechanism for generating and forming the advertisements is outside the scope of this document; see [OSPF_BIER_EXTENSIONS] and [ISIS_BIER_EXTENSIONS].

Here's the main idea 🧠 The BIER-MPLS label for a particular combination of SD, SI, and BSL is interpreted as representing the BIFT for that same combination of SD, SI, and BSL. In other words, the BIER-MPLS label does the job of a BIFT-id. This label value is carried in the BIFT-id field of the BIER encapsulation 🎀

It is crucial to understand that in an MPLS network, the first four octets of the BIER encapsulation header are ALSO the last four octets of the MPLS header 😱 Therefore, any prior MPLS label stack entries MUST have the S bit (see [RFC3032]) clear (i.e., the S bit must be 0).

When a BFR receives an MPLS packet and the next label to be processed is one of its BIER-MPLS labels, it will assume that the remainder of the BIER header (see Section 2.1.2) immediately follows the stack 🦋

Note that in practice, labels only have to be assigned if they are going to be used 🌸 If a BIER domain supports BSLs 256 and 512, but some SD, say SD 1, only uses BSL 256, then there's no need to assign labels for the combination of SD 1 and BSL 512 💅

2.1.1.2. Other Fields of the Initial Four Octets

TC:

The "Traffic Class" field [RFC5462] has its usual meaning in an MPLS label stack entry 💖

S bit:

When a BIER packet is traveling through an MPLS network, the high-order 20 bits of the initial four octets of the BIER encapsulation contain an MPLS label in the BIFT-id field 🧚 These four octets are treated as the final entry in the packet's MPLS label stack. Hence, the S bit (see [RFC3032]) MUST be set to 1. If there are any MPLS label stack entries immediately preceding the BIER encapsulation, the S bit of those label stack entries MUST be set to 0. Bestie, it's giving "bottom of stack" energy 👑

TTL:

This is the usual MPLS "Time to Live" field [RFC3032] ⏳ When a BIER packet is received, its "incoming TTL" (see below) is taken from this TTL field.

When a BIER packet is forwarded to one or more BFR adjacencies, the BIER-MPLS label carried by the forwarded packet MUST have a TTL field whose value is one less than that of the packet's incoming TTL. 🙈

If a BIER packet's incoming TTL is 1 or greater and one of the bits in its BitString identifies the current BFR, then the current BFR is a BFER for the packet. Therefore, the current BFR MUST process the packet as a BFER, e.g., by removing the BIER encapsulation and processing the payload based on the contents of the Proto (Next Protocol) field 🎉

If the incoming TTL is 0, the packet is considered to be "expired". If the incoming TTL is 1 and the BitString has a bit set that does not identify the current BFR, the packet is also considered to be expired. Expired packets SHOULD be passed to an error-handling procedure. (Optional implementation-specific rate limiting may be applied to control the rate at which packets are passed to the error-handling procedure.) Specification of the error-handling procedure is outside the scope of this document 🥲

Note that if a received BIER packet has an incoming TTL of 1 and its BitString has a bit set identifying the current BFR, then the payload MUST be processed by the current BFR, but the packet MUST NOT be forwarded further, and the packet SHOULD also be passed to the error-handling procedures for expired packets (subject to any implementation-specific rate limiting). Lowkey the most dramatic TTL situation ever 💀

2.1.2. Remainder of Encapsulation

Nibble:

This field is set to the binary value 0101. This ensures that the MPLS ECMP logic will not confuse the remainder of the BIER header with an IP header or with the header of a pseudowire packet 🧩 In an MPLS network, if a BFR receives a BIER packet with any other value in the first nibble after the label stack, it SHOULD discard the packet and log an error.

Ver:

This 4-bit field identifies the version of the BIER header 🔢 This document specifies version 0 of the BIER header. If a packet is received by a particular BFR and that BFR does not support the specified version of the BIER header, the BFR MUST discard the packet and log an error.

The value 0xF is reserved for experimental use; that value MUST NOT be assigned by any future IETF document or by IANA. Hands off, it's not yours 🚫💅

BSL:

This 4-bit field encodes the length in bits of the BitString 📏

Note: When parsing the BIER header, a BFR MUST infer the length of the BitString from the BIFT-id and MUST NOT infer it from the value of this field. This field is present only to enable offline tools (such as LAN analyzers) to parse the BIER header 🔍

If k is the length of the BitString, the value of this field is log2(k)-5. However, only certain values are supported:

   1: 64 bits

   2: 128 bits

   3: 256 bits

   4: 512 bits

   5: 1024 bits

   6: 2048 bits

   7: 4096 bits

The value of this field MUST NOT be set to any value other than those listed above. A received packet containing another value in this field SHOULD be discarded and an error logged. If the value in this field is other than what is expected based on the BIER-MPLS label, the packet SHOULD be discarded and an error logged 🚨

Entropy:

This 20-bit field specifies an "entropy" value that can be used for load-balancing purposes ⚖️ The BIER forwarding process may do equal-cost load balancing, in which case the load-balancing procedure MUST choose the same path for any two packets that have the same entropy value and the same BitString. Please see Section 6.7 ("Equal-Cost Multipath Forwarding") of [RFC8279] for a more detailed discussion of BIER load-balancing procedures 🦋

If a BFIR is encapsulating (as the payload) MPLS packets that have entropy labels, the BFIR MUST ensure that if two such packets have the same MPLS entropy label, they also have the same value of the BIER entropy field. 💜

OAM:

By default, these two bits are set to 0 by the BFIR and are not modified by other BFRs. These two bits have no effect on the path taken by a BIER packet and have no effect on the quality of service applied to a BIER packet 🌷

The use of these bits in other than the default manner is OPTIONAL. Specification of the non-default use or uses of these bits is outside the scope of this document; see [BIER-PMM] for an example of such a specification 🎀

Rsv:

These two bits are currently unused. They SHOULD be set to 0 upon transmission and MUST be ignored upon reception. 🫶

DSCP:

By default, this 6-bit field is not used in MPLS networks. The default behavior is that all six bits SHOULD be set to 0 upon transmission and MUST be ignored upon reception.

Non-default use of this field in MPLS networks is outside the scope of this document 🌈

Proto:

This 6-bit "Next Protocol" field identifies the type of the payload. (The "payload" is the packet or frame immediately following the BIER header.) IANA has created a registry called "BIER Next Protocol Identifiers". This field is to be populated with the appropriate entry from that registry 📋

If a BFER receives a BIER packet but does not recognize (or does not support) the value of the Next Protocol field, the BFER SHOULD discard the packet and log an error. 🙃

BFIR-id:

By default, this is the BFR-id of the BFIR, in the SD to which the packet has been assigned 🧚‍♀️ The BFR-id is encoded in the 16-bit field as an unsigned integer in the range [1,65535].

Certain applications may require that the BFIR-id field contain the BFR-id of a BFR other than the BFIR. However, that usage of the BFIR-id field is outside the scope of this document 🤷‍♀️

BitString:

This field holds the BitString that, together with the packet's SI and SD, identifies the destination BFERs for this packet 🎯 Note that the SI and SD for the packet are not carried explicitly in the BIER header, because a particular BIFT-id always corresponds to a particular SI and SD ✨

2.1.3. Further Encapsulating a BIER Packet

okay so sometimes a BIER packet needs its own outfit on top 💅 Sending it from one BFR to the next might mean wrapping it in an Ethernet frame, or tucking it inside a UDP packet 🎀. Either way, the BIER packet is just the payload of an "outer" encapsulation. It's giving russian doll energy 🪆 no cap.

Here we're assuming the frame or packet carrying the BIER packet is a unicast one. Even though the BIER packet itself is multicast, the outer frame goes unicast from one BFR to the next ✨ bestie, that's the whole trick.

Outer encapsulations usually have a codepoint for the "next protocol". For MPLS, the "next protocol" codepoint MUST be used. If an outer encapsulation has one codepoint for "MPLS with downstream-assigned label" and another for "MPLS with upstream-assigned label", the "MPLS with downstream-assigned label" codepoint MUST be used 🌸.

For example, if a BIER packet goes inside an Ethernet frame, the Ethertype MUST be 0x8847 [RFC5332]. That's the Ethertype for a unicast Ethernet frame carrying an MPLS packet whose label stack starts with a downstream-assigned label. iconic 👑

When the outer encapsulation is MPLS, there's no "next protocol" codepoint at all. To wrap the BIER packet, you just push more MPLS label stack entries (with the S bit clear) onto the BIER packet's label stack. So easy 🧚

Now, if two BIER packets have the same value in the entropy field of their BIER headers, and both get placed in an outer encapsulation, it's desirable for that outer encapsulation to keep the fact that they share the same entropy 🦋. If the outer encapsulation is MPLS and the MPLS entropy label [RFC6790] is in use in a given deployment, one way to do this is to copy the value of the BIER header entropy field into an MPLS entropy label. main character energy 💜

2.2. In Non-MPLS Networks

2.2.1. Encapsulation Initial Four Octets

2.2.1.1. The BIFT-id

In non-MPLS networks, a BIFT-id MUST be assigned for every combination of <SD, SI, BSL> that's going to be used in that network. The match between a BIFT-id and a particular <SD, SI, BSL> triple is unique across the whole BIER domain, and every BFR in the BIER domain knows about it 🌈.

How the BIFT-ids get assigned, and how those assignments get shared with the BFRs, is outside the scope of this document. That's a different story, bestie 🙈

In an MPLS network, the BIFT-id is an MPLS label, so its value can change as a BIER packet hops from BFR to BFR. In a non-MPLS network, the BIFT-id is unique across the domain, so it isn't expected to change as the packet travels. Lowkey the most stable thing ever 💅

2.2.1.2. Other Fields of the Initial Four Octets

TC:

By default, the TC field has no significance in a non-MPLS network. The default behavior is that this field SHOULD be set to the binary value 000 upon transmission and MUST be ignored upon reception ✨

Non-default use of this field in non-MPLS networks is outside the scope of this document. 🙈

S bit:

The S bit has no significance in a non-MPLS network. It SHOULD be set to 1 upon transmission, but it MUST be ignored upon reception 💖

TTL:

This is the BIER "Time to Live" field 🍓. Its purpose is to stop BIER packets from looping forever if the control plane misbehaves. When a BIER packet is received, its "incoming TTL" (see below) is taken from this TTL field.

The effect of this field on how a BIER packet gets processed is described in Section 2.1.1.2. Go check it out 🫶

2.2.2. Remainder of Encapsulation

Nibble:

This field SHOULD be set to 0000 upon transmission but MUST be ignored upon reception 🌸

Ver:

See Section 2.1.2.

BSL:

See Section 2.1.2.

Entropy:

See Section 2.1.2.

OAM:

See Section 2.1.2.

Rsv:

See Section 2.1.2.

DSCP:

This 6-bit field MAY be used to hold a Differentiated Services Codepoint [RFC2474]. What it means is outside the scope of this document, so that's a vibe for another day 🎀

Proto:

See Section 2.1.2.

BFIR-id:

See Section 2.1.2.

BitString:

See Section 2.1.2.

2.2.3. Further Encapsulating a BIER Packet

Sometimes a BIER packet needs another layer on top too. Sending it from one BFR to another might mean putting it in an Ethernet frame, or in a UDP packet 🦋. Either way, the BIER packet becomes the payload of an "outer" encapsulation.

Same deal as before: we assume the frame or packet carrying the BIER packet is unicast, even though the BIER packet itself is multicast. It's unicast from one BFR to the next 💜

Generally, the outer encapsulation has a "next protocol" codepoint. That codepoint MUST be set to a value that means "non-MPLS BIER". In particular, a codepoint that means "MPLS" (with either upstream-assigned or downstream-assigned labels) MUST NOT be used. not me using MPLS where it doesn't belong 💀

By requiring a distinct codepoint for "non-MPLS BIER", we make room for deployments where non-MPLS BIER and non-BIER MPLS coexist. The BIFT-id values used by the former won't collide with the MPLS label values used by the latter. Clean separation, no drama 👑

So if a non-MPLS BIER packet is encapsulated in an Ethernet header, the Ethertype MUST NOT be 0x8847 or 0x8848 [RFC5332]. IEEE has assigned Ethertype 0xAB37 for non-MPLS BIER packets 🧚

In the special case where the outer encapsulation is MPLS, there's no "next protocol" codepoint. If you do need MPLS as an outer encapsulation for BIER packets, it is RECOMMENDED to use the MPLS encapsulation for BIER. How to encapsulate a non-MPLS BIER packet in MPLS is outside the scope of this document 🌈

Last but not least: if two BIER packets have the same value in the entropy field of their respective BIER headers, and both are placed in an outer encapsulation, it's desirable for that outer encapsulation to preserve the fact that they have the same entropy ✨

3. Imposing and Processing the BIER Encapsulation ✨

Okay bestie, every BFIR is expected to know the Maximum Transmission Unit (MTU) of the BIER domain 🫶 That can come from provisioning or from some other method that's outside the scope of this doc. Each BFIR also knows how big the BIER encapsulation is, so it can work out the biggest payload it can stuff inside a BIER packet. We call that payload size the BIER-MTU 💖

If a BFIR gets a multicast packet from outside the BIER domain and that packet is bigger than the BIER-MTU, the BFIR does whatever is appropriate for a multicast packet that's too big to forward to all its next hops 😭 If the right move is to drop the packet and advertise an MTU to the source, the BFIR drops it and advertises the BIER-MTU. If the right move is to fragment, then the procedures in this section get applied, in order, to each fragment 🧚

When a BFIR processes a multicast packet (or a fragment of one) from outside the BIER domain, it runs through this procedure:

  1. By consulting the "multicast flow overlay" [RFC8279], it determines the value of the Proto field.
  2. By consulting the multicast flow overlay, it determines the set of BFERs that must receive the packet.
  3. If more than one SD is supported, the BFIR assigns the packet to a particular SD. Procedures for figuring out which SD a particular packet should be assigned to are outside the scope of this document.
  4. The BFIR looks up the BFR-id, in the given SD, of each of the BFERs.
  5. The BFIR converts each such BFR-id into "SI:BitString" format, as described in [RFC8279].
  6. All the BFR-ids that have the same SI can be encoded into the same BitString. Details of this encoding can be found in [RFC8279]. For each distinct SI that shows up in the list of the packet's destination BFERs:
    • a. The BFIR makes a copy of the multicast data packet and encapsulates the copy in a BIER header (see Section 2). The BIER header contains the BitString that represents all the destination BFERs whose BFR-ids (in the given SD) correspond to the given SI. It also contains the BFIR's BFR-id in the SD to which the packet has been assigned.

Note well that for certain applications it may be necessary for the BFIR-id field to contain the BFR-id of a BFR other than the BFIR that is creating the header. Such uses are outside the scope of this document.

  • b. The BFIR then applies the forwarding procedure of [RFC8279] to that copy. This may result in one or more copies of the packet (possibly with a modified BitString) being transmitted to a neighboring BFR.
  • c. If the non-MPLS BIER encapsulation is being used, the BIFT-id field is set to the BIFT-id that corresponds to the packet's <SD, SI, BSL>. The TTL is set according to policy.

If the MPLS BIER encapsulation is being used, the BFIR finds the BIER-MPLS label that was advertised by the neighbor as corresponding to the given <SD, SI, BSL>. An MPLS label stack is then prepended to the packet. This label stack [RFC3032] will contain one label, which is the aforementioned BIER-MPLS label. The S bit MUST be set, indicating the end of the MPLS label stack. The TTL field of this label stack entry is set according to policy.

  • d. The packet may then be transmitted to the neighboring BFR. (In an MPLS network, this may result in additional MPLS labels being pushed on the stack. For example, if an RSVP-TE tunnel is used to transmit packets to the neighbor, a label representing that tunnel would be pushed onto the stack.)

When an intermediate BFR is processing a received MPLS packet and one of the BFR's own BIER-MPLS labels rises to the top of the label stack, the BFR infers the BSL from the label. The SI and SD are also implicitly identified by the label. The BFR then follows the forwarding procedures of [RFC8279]. If it forwards a copy of the packet to a neighboring BFR, it first swaps the label at the top of the label stack with the BIER-MPLS label, advertised by that neighbor, that corresponds to the same <SD, SI, BSL>. Note that when this swap operation is done, the TTL field of the BIER-MPLS label of the outgoing packet MUST be one less than the "incoming TTL" of the packet, as defined in Section 2.1.1.2.

When an intermediate BFR is processing a received non-MPLS BIER packet, the BFR infers the BSL from the BIFT-id. The SI and SD are also implicitly identified by the BIFT-id. The BFR then follows the forwarding procedures of [RFC8279].

If the BIER payload is an MPLS packet, the BIER header is followed by an MPLS label stack. This stack is separate from any MPLS stack that may precede the BIER header. For an example of an application where it's useful to carry an MPLS packet as the BIER payload, see [BIER_MVPN]. If the BIER encapsulation's Proto field indicates that the payload is an MPLS packet with an upstream-assigned label at the top of the stack, the upstream-assigned label is interpreted in the context of <BFIR-id, sub-domain-id>. Note that the sub-domain-id must be inferred from the BIFT-id.

4. IANA Considerations 🎀

IANA has set up a registry called "BIER Next Protocol Identifiers" 📋 The registration policy for this registry is "IETF Review" [RFC8126] [RFC7120].

The initial values in the "BIER Next Protocol Identifiers" registry are:

0: Reserved

1: MPLS packet with downstream-assigned label at top of stack

2: MPLS packet with upstream-assigned label at top of stack

3: Ethernet frame

4: IPv4 packet

5: OAM packet (Reference: [BIER_PING])

6: IPv6 packet

63:  Reserved

5. IEEE Considerations 🌈

IEEE has assigned Ethertype 0xAB37 for non-MPLS BIER packets ✨

6. Security Considerations 🔥

Okay, this section is serious, so bestie, pay attention 🙈 Insofar as this document makes use of MPLS, it inherits any security considerations that apply to the use of the MPLS data plane.

If a BIER encapsulation header is modified in ways other than those specified in [RFC8279] and in this document, packets may be lost, stolen, or otherwise misdelivered. Those modifications are likely to go undetected, because the BIER encapsulation does not provide cryptographic integrity protection 💀

Layer 2 encryption can be used to make sure that a BIER-encapsulated packet isn't altered while it's in transit between adjacent BFRs 🔐 If a BFR itself is compromised, there's no way to stop that compromised BFR from making illegitimate changes to the BIER header, or from misforwarding or misdelivering the BIER-encapsulated packet 😱

If the routing underlay (see Section 4.1 of [RFC8279]) is based on a unicast routing protocol, BIER assumes that the routers participating in that unicast routing protocol have not been compromised. BIER has no procedures to make sure the unicast routing adjacencies haven't been compromised. That falls within the scope of whatever unicast routing protocols are being used 🛡️

BIER-encapsulated packets should generally not be accepted from untrusted interfaces or tunnels. For example, an operator may wish to have a policy of accepting BIER-encapsulated packets only from interfaces to trusted routers, and not from customer-facing interfaces 🚫

There may be applications that require a BFR to accept a BIER-encapsulated packet from an interface to a system that isn't controlled by the network operator. For instance, there may be an application in which a virtual machine in a data center submits BIER-encapsulated packets to a router. In a case like that, it's desirable to verify that the packet is from a legitimate source and that its BitString denotes only systems that source is allowed to send to. However, the BIER encapsulation itself doesn't provide a way to verify that the source is (1) legitimate, (2) really the system denoted by the BFIR-id, or (3) allowed to set any particular set of bits in the BitString 👀

Insofar as this document relies upon IGP extensions, it inherits any security considerations that apply to the IGP.

The security considerations of [RFC8279] also apply.

7. References 📚

7.1. Normative References

[RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
           Requirement Levels", BCP 14, RFC 2119,
           DOI 10.17487/RFC2119, March 1997,
           <https://www.rfc-editor.org/info/rfc2119>.

[RFC2474]  Nichols, K., Blake, S., Baker, F., and D. Black,
           "Definition of the Differentiated Services Field
           (DS Field) in the IPv4 and IPv6 Headers", RFC 2474,
           DOI 10.17487/RFC2474, December 1998,
           <https://www.rfc-editor.org/info/rfc2474>.

[RFC3031]  Rosen, E., Viswanathan, A., and R. Callon, "Multiprotocol
           Label Switching Architecture", RFC 3031,
           DOI 10.17487/RFC3031, January 2001,
           <https://www.rfc-editor.org/info/rfc3031>.

[RFC3032]  Rosen, E., Tappan, D., Fedorkow, G., Rekhter, Y.,
           Farinacci, D., Li, T., and A. Conta, "MPLS Label Stack
           Encoding", RFC 3032, DOI 10.17487/RFC3032, January 2001,
           <https://www.rfc-editor.org/info/rfc3032>.

[RFC5331]  Aggarwal, R., Rekhter, Y., and E. Rosen, "MPLS Upstream
           Label Assignment and Context-Specific Label Space",
           RFC 5331, DOI 10.17487/RFC5331, August 2008,
           <https://www.rfc-editor.org/info/rfc5331>.

[RFC5332]  Eckert, T., Rosen, E., Ed., Aggarwal, R., and Y. Rekhter,
           "MPLS Multicast Encapsulations", RFC 5332,
           DOI 10.17487/RFC5332, August 2008,
           <https://www.rfc-editor.org/info/rfc5332>.

[RFC5462]  Andersson, L. and R. Asati, "Multiprotocol Label Switching
           (MPLS) Label Stack Entry: "EXP" Field Renamed to "Traffic
           Class" Field", RFC 5462, DOI 10.17487/RFC5462,
           February 2009, <https://www.rfc-editor.org/info/rfc5462>.

[RFC7120]  Cotton, M., "Early IANA Allocation of Standards Track Code
           Points", BCP 100, RFC 7120, DOI 10.17487/RFC7120,
           January 2014, <https://www.rfc-editor.org/info/rfc7120>.

[RFC8126]  Cotton, M., Leiba, B., and T. Narten, "Guidelines for
           Writing an IANA Considerations Section in RFCs", BCP 26,
           RFC 8126, DOI 10.17487/RFC8126, June 2017,
           <https://www.rfc-editor.org/info/rfc8126>.

[RFC8174]  Leiba, B., "Ambiguity of Uppercase vs Lowercase in
           RFC 2119 Key Words", BCP 14, RFC 8174,
           DOI 10.17487/RFC8174, May 2017,
           <https://www.rfc-editor.org/info/rfc8174>.

[RFC8279]  Wijnands, IJ., Ed., Rosen, E., Ed., Dolganow, A.,
           Przygienda, T., and S. Aldrin, "Multicast Using Bit Index
           Explicit Replication (BIER)", RFC 8279,
           DOI 10.17487/RFC8279, November 2017,
           <https://www.rfc-editor.org/info/rfc8279>.

Okay bestie, let's finish this one! 🦋

7.2. Informative References

  • [BGP_BIER_EXTENSIONS]: Xu, X., Ed., Chen, M., Patel, K., Wijnands, IJ., and A. Przygienda, "BGP Extensions for BIER", Work in Progress, draft-ietf-bier-idr-extensions-04, January 2018. 🌸
  • [BIER-PMM]: Mirsky, G., Zheng, L., Chen, M., and G. Fioccola, "Performance Measurement (PM) with Marking Method in Bit Index Explicit Replication (BIER) Layer", Work in Progress, draft-ietf-bier-pmmm-oam-03, October 2017. 💅
  • [BIER_MVPN]: Rosen, E., Ed., Sivakumar, M., Aldrin, S., Dolganow, A., and T. Przygienda, "Multicast VPN Using BIER", Work in Progress, draft-ietf-bier-mvpn-09, November 2017. ✨
  • [BIER_PING]: Kumar, N., Pignataro, C., Akiya, N., Zheng, L., Chen, M., and G. Mirsky, "BIER Ping and Trace", Work in Progress, draft-ietf-bier-ping-02, July 2017. 🎀
  • [ISIS_BIER_EXTENSIONS]: Ginsberg, L., Ed., Przygienda, A., Aldrin, S., and J. Zhang, "BIER support via ISIS", Work in Progress, draft-ietf-bier-isis-extensions-06, October 2017. 🧚
  • [OSPF_BIER_EXTENSIONS]: Psenak, P., Ed., Kumar, N., Wijnands, IJ., Dolganow, A., Przygienda, T., Zhang, J., and S. Aldrin, "OSPF Extensions for BIER", Work in Progress, draft-ietf-bier-ospf-bier-extensions-10, December 2017. 🌈
  • [RFC6790]: Kompella, K., Drake, J., Amante, S., Henderickx, W., and L. Yong, "The Use of Entropy Labels in MPLS Forwarding", RFC 6790, DOI 10.17487/RFC6790, November 2012, <https://www.rfc-editor.org/info/rfc6790>. 🍓

Acknowledgements 🫶

The authors wanna thank Rajiv Asati, John Bettink, Nagendra Kumar, Christian Martin, Neale Ranns, Greg Shepherd, Ramji Vaithianathan, Xiaohu Xu, and Jeffrey Zhang for their ideas and contributions to this work. They're literally the reason this came together, so big thank-yous to all of them! 💖

Contributors 👑

The following people (listed in alphabetical order) contributed significantly to the content of this document and should be considered co-authors. Yes, co-authors. Iconic. 😭

Mach(Guoyi) Chen Huawei Email: mach.chen@huawei.com

Arkadiy Gulko Thomson Reuters 195 Broadway New York, NY 10007 United States of America Email: arkadiy.gulko@thomsonreuters.com

Wim Henderickx Nokia Copernicuslaan 50 Antwerp 2018 Belgium Email: wim.henderickx@nokia.com

Martin Horneffer Deutsche Telekom Hammer Str. 216-226 Muenster 48153 Germany Email: Martin.Horneffer@telekom.de

Uwe Joorde Deutsche Telekom Hammer Str. 216-226 Muenster D-48153 Germany Email: Uwe.Joorde@telekom.de

Tony Przygienda Juniper Networks, Inc. 1194 N. Mathilda Ave. Sunnyvale, California 94089 United States of America Email: prz@juniper.net

Authors' Addresses 🦋

IJsbrand Wijnands (editor) Cisco Systems, Inc. De Kleetlaan 6a Diegem 1831 Belgium Email: ice@cisco.com

Eric C. Rosen (editor) Juniper Networks, Inc. 10 Technology Park Drive Westford, Massachusetts 01886 United States of America Email: erosen@juniper.net

Andrew Dolganow Nokia 438B Alexandra Rd #08-07/10 Alexandra Technopark Singapore 119968 Singapore Email: andrew.dolganow@nokia.com

Jeff Tantsura Individual Email: jefftant.ietf@gmail.com

Sam K. Aldrin Google, Inc. 1600 Amphitheatre Parkway Mountain View, California 94043 United States of America Email: aldrin.ietf@gmail.com

Israel Meilik Broadcom Email: israel@broadcom.com

And that's a wrap, bestie!! 🌈✨ The whole BIER spec is served, no cap. 💅🎀

📦 where this page comes from