How does SPB support Multicast?

Let’s start with a question that may seem a little bit odd, but… do we really need multicast? Well, the number of services that are using a multicast scheme to deliver services to the subscribing users and/or devices has definitely grown over the last years. However, many network engineers have a hard time deploying multicast. One problem stems from the fact that multicast was not natively part of IP, so additional (and often complex) protocols like PIM or DVMRP needed to be added in order to support it. To make matters even more complicated, PIM itself, being the most widely used protocol, depends on an Interior Gateway Protocol like OSPF to build the network topology and provide routing information.

And of course, as we add more and more layers of protocols, not only do we add complexity; Time to converge rises, making our network more difficult to troubleshoot and scale.

So, if you need to support any type of multicast traffic, let’s say for the video distribution, and you’ve been having a difficult time with PIM or any other complicated multicast protocol, you can rest easy – with Extreme Fabric Connect, not only can you reap the rewards of SPB that we’ve discussed in previous articles, but you also get the most powerful multicast solution out there! Without exaggeration, not only does it scale beyond any other multicast solution on the market; it also re-converges a lot faster and is far easier to implement than any solution on the market.

Let me introduce two acronyms to make it easier for me to write, and for you to read:

So, for the rest of this article (and the subsequent parts of our 'SPB for Beginners’ series), I will mostly use the acronyms L2VSN and L3VSN.

Turning on IP multicast support in an SPB network is very easy. Let’s have a closer look at how this works. First of all, we need to establish that there are two “types” of multicast:

Understanding how the first “type” works will help us understand how the second “type” works.

As stated previously, the SPB data plane is based on Ethernet and works like Ethernet, with some exceptions: there is no broadcast and no flooding nor learning. As all network engineers know, within a broadcast domain we depend on broadcasting some traffic in order to make things work; e.g. we need to support mechanisms like ARP.

As each L2VSN we create in an SPB network is a broadcast domain, we need to support broadcast within each L2VSN. So naturally, you would think: “Since the SPB data plane does not support broadcast, how is broadcast traffic ‘broadcasted’ in those L2VSNs?” The answer is multicast. Broadcast can be viewed as a special case of multicast, where everyone is a receiver of the multicast. So if the answer is multicast, then… how does it work? Well, it’s a bit convoluted, but the mechanism looks basically like this:

For every I-SID (which identifies a virtual layer network), there is a shortest path tree computed from every BEB node (edge node) to every BEB node that is part of this specific virtual network. Nothing new here, but what’s important to understand is that for every I-SID there can be many shortest path trees; one rooted at each BEB node that has this I-SID configured.

Let’s consider a network depicted in the figure 1 below. We’re looking at a L2VSN with an I-SID number of 200 which is terminated on BEB1, BEB2, BEB3, and BEB4. It means that there will be four shortest path trees: one rooted in BEB1 (figure 2), one rooted in BEB2 (figure 3) and so on.

Each BEB node will create a (48-bit) group MAC address (which we often call ‘multicast MAC address’) for the tree rooted on it. The group MAC address is created using the following simple algorithm:

3 ‘plus’ SPSourceID ‘plus’ I-SID number, which will look like this:

Now, this may require some more explanation:

Every node has a unique SPSourceID provided by configuration. (Note: In IETF RFC6329/Extreme Networks terminology, we call it ‘Nickname’ instead of ‘SPSourceID’). The SPSourceID is 20-bit and goes as follows: x:xx:xx (hex), e.g. 0:40:01.

We start out with putting 3 (binary 11) in bit 0 and 1 of octet 0. We set bit 2 and 3 to 00 so that this is a source-rooted shortest path tree. (Remember: bit 0 = 1 means this is a group MAC address, bit 1 = 1 means this is a locally administered address).

Then we “add” the SPSourceID, which will fill the second nibble of the octet 0, and the next two bytes (octet 1 and 2).

Then we put the (24-bit) I-SID number of this specific L2VSN in octet 3, 4 and 5.

Still confused? Maybe an example will help. Referring back to figure 1 and 4:

Let’s assume that we have decided to give BEB1 an SPSourceID = 0.40.01, BEB2 an SPSourceID = 0.40.02, BEB3 an SPSourceID = 0.40.03, and finally BEB4 an SPSourceID = 0.40.04.

So for the L2VSN with the I-SID number 200 (knowing that decimal 200 is hex C8), BEB1 will create the following multicast MAC address:

Which is read like this in hex:

03:40:01:00:00:C8

So far so good. But how does this give us the multicast capabilities? Well, here’s how it works:

All SPB nodes have learned the SPSourceID of all the other SPB nodes in the network. This means that all the nodes that are on the shortest path tree for a given I-SID also know the SPSourceID of the root node of this tree. Having both the SPSourceID and the I-SID value, they can construct the group address.

So for the shortest path tree rooted on BEB1, the following nodes will construct a group MAC address = 03:40:01:00:00:C8 and store it in their multicast forwarding database: BCB1, BCB3, BCB4, BEB1, BEB2, BEB3, and BEB4.

Similarly, BEB2 will construct a group MAC address equal to 03:40:02:00:00:C8. And so will BCB1, BCB2, BEB1, BEB3, and BEB4.

The same applies to BEB3 and BEB4.

Note: the nodes will do the same for all L2VSN (=I-SID) that they are part of. So if BEB1 also had an L2VSN with an I-SID = 10010 terminated on it, it would create the following group MAC address for this particular L2VSN:

03:40:01:00:27:1A

(and so would all the nodes that are part of I-SID = 10010)

So eventually, when (for instance) BEB1 receives an ARP request on a UNI interface that is mapped to I-SID 200, it will encapsulate this in a new Ethernet frame, set the destination MAC address equal to its multicast MAC address (=03:40:01:00:00:C8), and forward it out on NNI interfaces that are on the shortest path tree for I-SID 200. The next nodes that receive this frame will inspect the destination MAC address; and since it is a multicast MAC address, they will forward it on all the NNI ports that are part (branches) of the shortest path tree. And so, the frame will be replicated and distributed until it is eventually received by BEB2, BEB3 and BEB4. Being BEB nodes, they will strip the outer/SPB Ethernet header and forward the original Ethernet frame (which happens to be an ARP request broadcast frame) on all the UNI ports that are associated with the L2VSN identified by I-SID = 200.

Supporting IP (S,G) multicast is almost identical. What the ‘almost’ part means, is that:

As mentioned earlier, support of IP multicast is not part of the Shortest Path Bridging standard. In order to harvest the ‘built-in’ multicast capabilities to support IP multicast, Extreme has defined three (TLV) extensions to IS-IS. These TLVs are used to announce the presence of senders. So yes, this is a proprietary mechanism, but only the edge nodes (BEBs) need to support this. For the core nodes (BCBs) it is just normal forwarding.

There is an additional proprietary mechanism used for IP multicast and I will get back to it a little bit later.

As a refresh: to enable multicast, you have to use the following set of commands on the BEB nodes where you have senders and receivers:

For a L2VSN you use the following commands to enable multicast on e.g. VLAN 10 and 20:

For a L3VSN you would use the following commands to enable multicast on the subnets/VLANS where you have senders and receivers; e.g. subnet/VLAN 100 and 200

But how does this work? Starting on the multicast sender’s side (assuming that you have enabled multicast using the commands shown above):

When a BEB node receives a multicast stream (for a given Source IP and Group IP address) on a UNI interface, it will allocate an I-SID in the range of 16 000 001 and higher (this is what I referred to earlier, as the additional proprietary mechanism). This new I-SID can be viewed as parallel to the I-SID used for standard data traffic and is used purely to stream IP multicast traffic.

The BEB node will also create a new multicast MAC address according to what has been described above, using its SPSourceID and the allocated multicast I-SID. So if we are assuming BEB1 with a SPSourceID = 0.40.01, and also assuming that this is the first IP multicast stream it receives, it will allocate I-SID 16 000 001 for the stream and create the following multicast MAC address:

03:40:01:f4:24:01

The BEB will use IS-IS updates to tell its neighbors about the Source IP and Group IP, and the I-SID used for this multicast stream. It will also include a Tx (transmit) flag, signaling that it will be the sender.

For those really interested: the BEB will, in fact, use a standard TLV (TLV 144) to signal the allocated I-SID and the Tx bit. It will also use an Extreme-defined TLV to announce the Source IP and Group IP address and again set the Tx flag to signal that it will be the source of the multicast stream.

The information will be then propagated to all the SPB nodes in the network. Eventually, all the BEB nodes will know the availability of the multicast stream (the Source and Group IP) and I-SID to use to transmit this multicast stream. This information is stored in the ISIS LSDB, which is the same across every node in the SPB Fabric.

If the same BEB node receives another multicast stream (a different S,G pair), it will allocate the next available I-SID in the range of 16 000 001 and above. So, assuming that it receives multicast stream number two, it will allocate I-SID 16 000 002 and the multicast MAC address for this stream will be:

03:40:01:f4:24:02

And finally: how the subscribers are identified and how is the multicast actually distributed to them? This is done with IGMP (Internet Group Management Protocol) and IS-IS.

When we enable IP multicast on a BEB node for a specific network (let’s say, on the VLAN that is mapped to I-SID 200), we also make the BEB an IGMP Querier for this specific VLAN. It will send out IGMP Queries at regular intervals. Host on this network that wants to subscribe to a stream will send an IGMP Host report to join.

Upon receiving a join request, the BEB will check the IS-IS LSDB database to see if the S,G pair exists. If that’s not the case, it will just ignore the join request. Otherwise, it will send an IS-IS update containing the I-SID used for this multicast stream and the Rx (receive) bit set. This will propagate through the network and eventually reach the BEB node where the sender is connected. When this BEB receives update about the first subscriber, it will start to forward the multicast traffic on the I-SID (tree) that is assigned to this specific multicast stream. Nodes that are on the shortest path to the receiver will forward the multicast frames (they have already installed the multicast MAC address in their forwarding database).

If this is the first subscriber, the multicast forwarding tree may be just a subset of the full unicast tree. The figure 5 below shows the multicast tree with subscribers on BEB3 and BEB4. If there are subscribers on all BEB nodes, then the multicast tree will be identical to the unicast tree. But it’s very important to note that the multicast paths will always be congruent to the unicast paths.

If/when the BEB receives an IGMP Leave message, it will reset the Rx flag and issue an IS-IS update so that the stream is pruned.

The mechanism above describes the IP multicast distribution in a L2VSN. The mechanism for IP multicast in a virtual layer 3 network is identical.

I should also point out that the multicast stream is contained within the virtual network from which it originates. However, Extreme has also created a PIM gateway function so that SPB multicast domains can integrate with PIM multicast domains.

I hope that this (somewhat lengthy description) gave you a fairly good understanding of how multicast works in a Shortest Path Bridging network, and why we can support multicast without the added complexity of PIM (or other multicast protocols)!

In the next part of the ‘Shortest Path Bridging for Beginners’