As the number of receivers increases, the number of packets that needs to be sent increases linearly. In other words, for n receivers, the host would need to send n copies of each packet. If the host is sending a real-time audio or video presentation, this solution may be workable for very few receivers, but as the number of receivers increases, the load of replicating packets on the host would be such that the delay between distinct packets would be unacceptable. Also, the links on the source router, router E in Figure 1-6, would have the bandwidth severely depleted. Another major problem with this scheme is the host not knowing where the receivers are. If the receivers that require the traffic don’t change, then they could be entered, but this would be extremely restrictive because new receivers could not dynamically join or leave the group. And what about the broadcast model? Certainly every host on the local subnet would receive the traffic and each packet would only have to be sent once. So what’s the problem? Two come to mind. The first is that only receivers on the same subnet receive the traffic, while receivers on other subnets cannot receive it because the router blocks broadcasts. This is probably a good thing because we don’t want a broadcast to be delivered to the whole world. Yes, some people would like to do this, but in general it is not a good idea.
The second problem with using a broadcast is that every host is required to process the ethernet broadcast in order to determine if the traffic is intended for the host. The IP packet would have to be extracted from the ethernet frame and, because the destination IP address is also a broadcast address, the UDP or TCP portion of the packet would need to be extracted and passed up the protocol stack. If there is a process expecting the data, it would be passed to the application layer. If there is not a process expecting the data, then the data would be discarded. For those hosts not expecting the data, this would be a waste of valuable processing time and a source of many user complaints. Looks like we need another model.
For the multicast communication model, we will need two new types of addresses, an IP multicast address and an ethernet multicast address. An IP multicast address identifies a group of receivers that want to receive traffic destined for the group. Because all IP packets are encapsulated in ethernet frames, a multicast ethernet address is also required. For the multicast model to function correctly, hosts should be able to receive both unicast and multicast traffic, which mandates that hosts need multiple IP and ethernet addresses. A unicast IP and ethernet address are used for unicast traffic and zero or more IP, and ethernet multicast addresses are used for multicast traffic. Zero multicast addresses are needed if the host will not be receiving multicast traffic. A pair of multicast addresses, IP and ethernet, are required for each multicast group that the receiver wishes to join. A major difference between the unicast and multicast addresses is that unicast addresses are unique on each host, while multicast addresses are not. If five hosts wish to receive multicast traffic destined for group A, for example, then the hosts would all listen for traffic destined for the same multicast address, both IP and ethernet. The amount of traffic from the unicast case would be greatly reduced, as shown in Figure 1-7.
