To establish context for this lesson, let's quickly discuss the fundamental process of packet encapsulation.

Encapsulation refers to the process of adding headers around the data as it moves down the OSI model layers. Each layer performs a specific function and adds its own layer-specific header to the data before passing it down to the next layer. This process ensures the data is properly transmitted, routed, and received across the network. The following diagram shows a high-level overview of the process.

During transmission, the frame is sent over the physical medium. Upon reaching the destination, the reverse process, called decapsulation, occurs. Each layer removes its respective header and processes the encapsulated data until it reaches the application layer, where the original message is reconstructed and consumed by the end host.

Encapsulation in Unicast

Let's walk through the encapsulation process in unicast communications. 

Suppose PC1 opens an HTTP Web Page with IP address 1.2.3.4 located somewhere on the Internet. Before PC1 encapsulates the data, it first performs a simple check to understand whether the destination host is on the same subnet or not. PC1 checks the destination IP address (1.2.3.4) against the locally configured IP address and Subnet mask (10.1.1.1/24). Obviously, the destination IP is not on the local segment. Subsequently, PC1 checks the destination IP address against its routing table. In most cases, the destination IP matches the default route (0.0.0.0/0), which points to the subnet's default gateway (DGW). At this point, PC1 knows that it must send the traffic destined for the Web Page on the Internet to the default gateway router. However, before sending any traffic to the DGW, PC1 must know the gateway's MAC address, as shown in the following diagram.

At this point, PC1 must use the Address Resolution Protocol (ARP) to find the default gateway's MAC address. I know every engineer knows how the process goes, but let's quickly walk it through just for context.

ARP Request

PC1 sends an ARP Request on the LAN asking, "Who has 10.1.1.254?", as shown in the following diagram. The ARP Request is a broadcast message. Hence, the local LAN switches forward the ARP message to all switchports except the incoming one. Ultimately, the ARP request reaches all hosts on the local LAN.

The hosts on the local segment process the ARP request. However, only the default gateway router responds back because it has the requested IP address.

ARP Response

When the router answers back with an ARP Response, it sends it directly to PC1 using unicast, as shown in the diagram below.

Only at this point does PC1 have enough information to encapsulate the HTTP request to the remote web server and send it to the local LAN. All packets that PC1 sends to the remote Web server are encapsulated with SRC_PORT 34000, DST_PORT 80, SRC_IP 10.1.1.1, DST_IP 1.2.3.4, SRC_MAC 000a.000b.0001, and DST_MAC 000a.000b.aaaa. It is very important to understand that the information in the layer 3 header (SRC_IP and DST_IP) doesn't change along the way, while the information in the layer 2 header (SRC_MAC and DST_MAC) changes at every layer 3 hops.

Encapsulation in Multicast

Network engineers generally understand the unicast encapsulation process very well. At the end of the day, this is one of the fundamentals of Ethernet networks. However, let's try to apply the unicast logic to a multicast communication in the local LAN. 

Suppose PC1 is streaming 4k video to a multicast group address 239.1.1.1. One local host (PC2) is interested in receiving the stream. Several remote hosts (PC5 and others) also want the video stream. In the context of packet encapsulation, a very important question immediately arises: Which destination MAC address should PC1 insert into the frame before sending it out onto the LAN? Figure 5 below visualizes the question.

If PC1 uses the well-known broadcast MAC address 0xFFFF.FFFF.FFFF, all hosts on the local segment will receive the video stream even if they do not want it. For example, PC3 and PC4 do not want the video, but they will get it anyway if the broadcast MAC is used. This is very inefficient and also has security implications.

If PC1 uses an unicast MAC, only one local host will get the video stream (since unicast MAC must be unique and connected to a single switch interface). However, both PC2 and the default gateway router must receive the stream. Pc2 wants to consume the stream, while R1 must forward the stream to PC5 and toward the remote network segments.

The more you think about it, the more questions will arise. For example:

• What MAC address to use? What MAC address must PC1 use so that the video stream goes only to interested receivers in the LAN, including the default gateway router?
• How does LAN switches know on which switchports to replicate the frame? For example, SW1 must send a copy of the multicast frame on port 0/1 and 0/4 but not on ports 0/2 and 0/3.
• How do LAN switches differentiate multicast streams? Presuming a layer 2 switch does not look at the layer 3 header information in packets, how would a layer 2 switch differentiate different multicast streams - for example, a video stream on 239.1.1.1 vs an audio stream on 239.15.10.102?
• Will an end host process the frame? If the destination MAC address is not its interface's physical address.

Multicast on the LAN

Multicast works differently on the Ethernet level than Unicast and Broadcast communications. The main difference is what destination MAC address hosts use when encapsulating the data before putting in on the LAN.

• Unicast: The destination MAC address is the physical interface MAC address of the destination host. Hosts discover the physical address of a remote host using the ARP protocol.
• Broadcast: The destination MAC address is the well-known broadcast MAC address 0xFFFF.FFFF.FFFF.
• Multicast: The destination MAC address is made up of the multicast IP address using a specific algorithm. There is no ARP.

The Multicast MAC address

IP multicast addresses are mapped to MAC addresses using a specific algorithm defined by IANA (Internet Assigned Numbers Authority). This mapping ensures that LAN switches deliver the multicast packets to the correct destinations on a local LAN.

IPv4 multicast addresses range from 224.0.0.0 to 239.255.255.255. These addresses are mapped to Ethernet MAC addresses that fall within the range of 0100.5E00.0000 to 0100:5E7F:FFFF. We are going to discuss the algorithm in great detail in the next lesson.

The following example shows how what MAC address PC1 uses when transmitting multicast to group 239.1.1.1.

This encapsulation process applies to the source of the multicast stream. It uses this logic when sending the traffic on the LAN. However, the hosts interested in receiving multicasts from a specific group use a group membership protocol to advertise their interest. Let's see how.

Control-Plane

LAN switches must be aware of which local hosts are interested in a multicast group and on which switchports those hosts are connected. Without this information, switches can only flood the multicast to all ports, negating the efficiency improvements of using IP multicast. 

Introducing IGMP and PIM

Hosts use the Internet Group Management Protocol (IGMP) protocol to inform the local multicast router that they want to receive traffic for a specific multicast group. For example, suppose PC7 wants to receive multicast from group 239.1.1.1. It sends an IGMP Membership message on the local LAN, as shown in the diagram below. LAN switches hear these IGMP messages between hosts and the local routers and build a multicast MAC-to-Swithports table.

PC4 also wants to receive multicast from group 239.1.1.1, so it also sends an IGMP membership message on the LAN. Now SW1 knows that when it receives frames destined to the multicast MAC address corresponding to multicast group 239.1.1.1, it must replicate the frames to ports 0/3 and 0/7 because it has interested receivers connected to those ports. Additionally, SW1 knows it must send the multicast to all multicast routers on the segment because remote hosts might also be interested in receiving this multicast.

Multicast-enabled routers use a control plane protocol called Protocol Independent Multicast (PIM) to exchange multicast group information and to build a multicast distribution tree. We are going to discuss PIM in great detail in the coming lessons. However, in the context of the local LAN, SW1 also hears the PIM HELLO messages that R1 is advertising. Hence, SW1 also knows that it must replicate all multicast frames to the multicast router on segment R1 so that the multicast can reach remote receivers.

Data-plane

Listening to IGMP and PIM messages, SW1 builds a table with the connected receivers for each multicast group. For example, SW1 knows that it must replicate the multicast frames with the destination MAC 0100.5E01.0101 (which corresponds to IP 239.1.1.1) to switch ports 0/3, 0/4, and 0/7, as shown in the diagram below. 

In the end, only the interested receiver on the local LAN receives the multicast that PC1 transmits, which is the main efficiency gain of Multicast.