In November I participated in the IETF meeting in Honolulu Hawaii. There are many reasons to attend the IETF but on a personal level I love going to the meetings because of the learning experience they provide. There are the working groups I always attend based on my areas of expertise: IDR (BGP), OSPF, PIM, ISIS, etc but then I find there are always the times during the IETF you look down at your schedule and aren’t quite sure what to go to. This is what I love the most because it causes you to go into unknown exciting areas, because let’s be honest, while nice, adding TLVs extensions to OSPF isn’t the most exciting! This year there was one such meeting, a BOF to be exact, that I found especially exciting called BIER or Bit Indexed Explicit Replication.
To be fair I had seen this first, I believe, on the PIM mailing list which caused me to briefly skim some of the architecture related documents. So what is BIER? Well first, if you have worked with PIM you will know what I mean when I say its a complicated technology. As one of my colleagues so eloquently put it, you know a multicast engineer versus a unicast engineer simply by how the multicast engineer refers to their code with personal pronouns and more like a mythical beast they must tame rather than an inanimate object. BIER is a multicast routing protocol which may tame the mythical beast of multicast.
The basic idea behind BIER is each edge router is assigned an offset into a bit array. These assignments are flooded to everyone in the domain through use of an IGP. On ingress into the BIER domain a multicast packet is assigned to a tuple. The packet being ingressed is encapsulated with a MPLS label which can be indexed to return this tuple. Following this MPLS label is a BIER header which contains some meta data and a bit array which is some multiple of 32 bits.
The routers in the BIER domain use their IGP databases to calculate the shortest path to each edge router. For each neighbor you OR the bit masks for each edge router in the domain whose shortest path travels through this neighbor. This creates a bit mask and next-hop table called the Bit Forwarding Table.
Upon reception of a frame with this header you AND the frame’s bit array with each entry in the Bit Forwarding Table. If your result is non-zero you replicate the frame for this neighbor setting the bit array to be this AND’ed value. (Please take a look at the IETF presentations and drafts on this for diagrams and more detail).
Since the number of edge routers in any domain is evidently limited by the size of the bit array they introduce BIER sets. Each frame with a BIER header is assigned to a set based on the MPLS label. Each set indexes into a separate Bit Forwarding Table. For each set which contains a desired egress node the ingress node makes a duplicate of the frame leading to N copies of the frame where the shortest paths converge in the multicast distribution tree originating at the ingress node. This use of sets allows for many more egress nodes than limited by the bit array length, of course, it still faces scalability issues which realistically limits the number of egress nodes. There are some other optimization such as the use of the Bit Index Routing/Forwarding Tables but I will leave that up to the reader to research. Much of what has been said here is highly tentative and will almost certainly change many times before anything gets standardized.
So to me I love this proposal because of its simplicity. It obviously has issues in where it can be deployed (for instance if you have millions of edge routers this might not be optimal for you) but for many cases it seems great. Unlike PIM it requires no per multicast flow state and it inherits features from unicast routing like FRR and unicast’s convergence time. I have heard talks about deploying it as a hybrid model with say PIM as a backbone and BIER running near the customer edge thus segmenting and simplifying the multicast domain and PIM.
Another item some people point out as a drawback is the current hardware isn’t optimized for this type of forwarding. Coming from a software point of view this doesn’t phase me in the least. Expensive hardware is good for some things but just like mainframes decline of the past commodity, multipurpose hardware is the future in networking, special purpose, expensive hardware is not.
And as always folks, the postings on this site are my own and don’t necessarily represent Brocade’s positions, strategies or opinions.