Can Unicast and Broadcast be a subset of Multicast

Recently I was listening to a debate on the type of communications methods like Unicast, Multicast and Broadcast. Forum was arguing that Unicast and Broadcast can be attributed as a subset of Multicast. Supporting argument for this from many folks was, in unicast you sent the data to just one recipient and in broadcast you send it to everyone. Multicast lies in between, where you send the data to selected recipients.

Read further why this is true only at the conceptual level.

Whether it is unicast or multicast or even broadcast (directed), Routing information base (RIB) plays a key role in forwarding but?an Inherent DANGER or Complexity exists in multicast-forwarding that does not exist in unicast and broadcast packet-forwarding.

Before we talk about this danger, lets decode one important point with respect to unicast or broadcast forwarding.

When a network device receives and forward a unicast or a broadcast packet, only a single copy of that packet exists.

Wait!! You may argue how come Sunil!!, for unicast, we understand but for broadcast there are many intended recipients so how come just one single copy serve the purpose when packets needs to be sent to all. Single copy because it transits via Layer 3 interfaces and nodes.? Broadcasts may have many intended recipients,?but a Layer 3 interface does not make additional copies to send to host interfaces.?That is the job of the Layer 2 switch. Layer 2 switches copy each broadcast frame and flood the copies out each interface in the respective Layer 2 domain; this is known as?packet replication.

Now Lets come to original point - Multicast danger.

IP multicast packets come from a single source but are forwarded toward many Layer 3 destinations.?Remember, I said layer 3 destinations (receivers) and this is important to understand in contrast to above point. So a layer 3 node needs to make multiple copies of the multicast packet for forwarding.

!!!!!!!!!! !!!!!!!!!! First Difference !!!!!!!!!! !!!!!!!!!! Yay !!!!!!!!!! !!!!!!!!!

But here layer 3 device needs to make one important decision,? It must choose only downstream interfaces towards receivers to forward the copy of the packet without creating a Forwarding Loop.?

Now lets understand what pain a layer 3 device needs to go through so that this loop can be avoided.

!!!!!!!!!! !!!!!!!!!! Warning!!! Technical Jargon Ahead !!!!!!!!!! !!!!!!!!!

To ensure this loop avoidance while making and forwarding these additional copies, RPF ie reverse path check is performed. So before forwarding multicast packet, layer 3 node will perform a check against the source.? It will check the incoming interface where it has received the multicast traffic is SAME, via which it can reach the source.? Ok!!! What else ??

Take a intermediate transit (layer 3) node and lets list down what all things are checked before forwarding a Multicast packet:

1. In multicast we go backwards, ie from receivers towards source so transit layer 3 nodes must have a way to determine which network paths multicast sources are sending traffic.
2. Where in the network all interested receivers are located.
3. Finally, which are the interfaces in the path leading toward those receivers and any additional copies needs to be made.

This all information is needed for multicast forwarding.?

Wait!! All this is further complicated by the fact that multicast receivers subscribe only to specific groups. Layer 3 nodes must also have a way to learn and share information about the groups that have current receivers, specific groups they are signing up for, and the sources generating multicast packets for that group.

So you see neither unicast nor broadcast (directed) goes this extra mile to forward the packet. Multicast packets do give some hard time to our favourite layer 3 devices. In the second part, we will understand how RIB and Multicast routing protocol PIM helps layer 3 nodes here.

Wait!! Is PIM even a routing protocol ?

?

This and more in the second part. Stay tuned and Big Thanks for reading.

?

Happy Learning!!!

#networkengineer #learneveryday #multicast