BUM (broadcast, unknown, multicast)

BUM is the acronym for Broadcast, Unknown, Multicast in layer 2 frames. I know you all know about them very well, and in fact BUM is something that network engineers don't deal with on a daily basis. In traditional networking, BUM is the pure job of switch silicon.

But in an SDN world, BUM is a key element for system robustness, a very important factor. Let's look at why we need to deal with BUM carefully.

In traditional networking, a very basic layer 2 switch, regardless of its speed of 10 Mbps to 100 Gbps, has the basic capability to switch the traffic based on layer 2 information of a frame (frame is a layer 2 message, which holds the layer 3 packet encapsulated inside the frame's payload). When a layer 2 switch receives a frame, it builds a simple table mapping between the source MAC address and the port the frame has arrived.

The preceding table is called a TCAM or MAC address table, or other names (by different vendors).

If a switch receives a frame destined for a MAC address that doesn't exist in its MAC address table, or it is a broadcast frame (that is ARP, destined for FF;FF:FF:FF:FF:FF), or a multicast frame, the layer 2 switch by default copies the frame over all of its ports, except the port the frame has arrived.

This is the way a basic layer 2 switch deals with BUM in the background where the network engineer doesn't notice.

In the SDN world, as I explained previously, we are living in a world where a single controller knows the whole network and hosts. The switches are not intelligent enough to deal with a frame that they don't know where to send it to. What will happen to a frame that enters an SDN switch with broadcast MAC or a destination MAC address unknown to the switch (not listed in its flow table)?

The SDN switch needs to send this frame to the SDN controller and ask the controller where to send this frame. This also can be a packet. SDN switch uses the southbound protocol to request the controller about how to deal with this packet or frame.

SDN controller receives the frame from the SDN switch and it needs to react and tell the switch what needs to be done for the frame. This is a very important process and if the SDN controller fails to respond to the switch within a specific time, the frames will not pass and the source will keep waiting.

An ideal SDN controller should be very proactive by filling the flow tables of the switches in such a way that the number of requests from the switch to the SDN controller for BUM is reduced.