The Concept of Multicasting

The basic concept of multicasting is simple enough: Reduce the total amount of bandwidth you consume by forwarding a single stream of IP packets to multiple recipients simultaneously. That was easy enough to say, but several assumptions and concepts that require further scrutiny are submerged in that definition.

The first assumption is that multicasting implies a type of communication in which two or more recipients want to receive the same data at the same time. You might wonder why you would want to send the same stream of packets to more than one destination. What practical purpose could that serve? From the perspective of the nontechnical end user, it can be difficult to imagine a scenario in which you would benefit from sending the same stuff to multiple recipients. These are all fair questions, and we'll make sense of all of them.

Another issue with multicasting is how you address an IP packet that is to be simultaneously delivered to multiple, specific destinations. Each IP packet has room for only one destination IP address in its header, so it is safe to assume that you need some mechanism in the IP address system that can accommodate this type of requirement.

This section examines some basic communications paradigms, including some examples of when each would be appropriate. This will help you better appreciate the niche that multicasting fills in an IP network.

Different Communications Paradigms

The Internet and other IP-based networks feature any-to-any communications. With the exception of local permissions, which may be configured by network administrators, this means that any system can communicate with any other system, provided that they are interconnected either directly or indirectly.

Perhaps the best way to demonstrate multicasting is to show you what it is not. There are three distinct paradigms for networked communications:

• Unicasting

• Broadcasting

• Multicasting

By examining them in the proper sequence, you can develop a better appreciation of multicasting. After a little thought, you should be able to quickly recognize which types of applications or network functions are good candidates for multicasting and which are not. Besides, as you'll see later in this chapter, broadcasting can be a very effective multicast mechanism if used properly.

Unicasting

Unicasting is a fancy way of saying one-to-one communication. This is how most Internet users communicate and interact with other users, systems, and applications. At its simplest, a single user communicates across a network or internetwork with another, singular system. That destination system could be someone's personal computer or a content-bearing server.

Many types of communications feature this type of one-to-one correlation between source and destination machines. Here are some quick examples of one-to-one communication:

• Sending a print request to a networked printer

• Sharing MP3 files with a friend across the Internet

• Using an IP-based e-mail system

• Pulling down stock quotes from the web

None of these are good candidates for multicasting, because a single, specific host is communicating with a single, specific destination. More subtly, communications must flow in both directions for each of these types of sessions to be successful. Any networked application that requires either reliable delivery of information or bidirectional communication is not a good candidate for multicasting.

Figure 9-1 illustrates unicasting between two specific end systems across the Internet.

Figure 9-1. Unicast Datagrams in an IP Network

Broadcasting

The next type of communication is known as broadcasting. Broadcasting features one-to-all communication. In an internetwork the size and scale of the Internet, one-to-all communication doesn't make much sense. But on a more localized level, such a communication mechanism is ideal for many network-based functions.

Figure 9-2 illustrates the one-to-all form of communication that is broadcasting. The heavy dotted lines indicate the flow of broadcast datagrams. As evidenced in the figure, the router does not forward LAN broadcasts. The router's LAN interface is a part of the LAN community, and it must accept LAN broadcasts just like any other device in that LAN. Those broadcasts, however, are not forwarded.

Figure 9-2. Broadcast Datagrams in an IP Network

Broadcasting by its very nature isn't the type of communication that typifies end-user communication across a network. Few, if any, end users need to communicate with every other known endpoint connected to their network. Instead, broadcasting has become extraordinarily valuable as a supporting mechanism for many vital network functions, including routing table updates, and networked devices using address resolution protocol (ARP) to build a table that correlates known MAC addresses (Layer 2) with their IP addresses (Layer 3).

If nothing else, these two examples should demonstrate that broadcasting is a phenomenon of networking and not a feature of any particular protocol or technology. It is used in both LANs and WANs. There might be many different ways to implement and use broadcasting, but the fundamental paradigm of one-to-all communication remains constant.

Multicasting

This is another type of communication that can best be described as a one-to-many paradigm. With multicasting, a single specific host initiates a communication session. Each IP packet within that session is sent simultaneously to multiple recipients. The catch is that those recipients are quite specific; you don't just dump packets at random. For example, some online games need to work this way. The game server transmits the same packetized data to all active players. Obviously, this means that the players are participating in the same game. Otherwise, different data streams would be required!

In the absence of multicasting capabilities, this type of communication session would require the originating machine to generate a separate stream of packets for each machine it needed to communicate with. This isn't a very scalable approach in terms of either the bandwidth required or the resources required within the originating machine. From the perspective of the gamer, excessive loads on either the game server or the Internet are unacceptable.

Although this might seem like a trivial example, it is a real one. Internet-based games have become quite popular. Although many continue to feature unicasting, this genre of applications appears uniquely positioned to benefit from multicasting technology. In Figure 9-3, the communication stream is delivered very particularly to specific destinations, rather than being flooded to all systems within the targeted network.

Figure 9-3. Multicast Datagrams in an IP Network

That ability to target specific destinations is the very heart of multicasting. The key to achieving this selective delivery lies in being able to keep track of your intended destination machines and correlate that list with a single IP address that is placed by the originating machine into the IP packet's header. Each router would have to be configured to support multicasting.

Figures 9-1 through 9-3 all assume communication between end systems. Although they adequately demonstrate the distinctions between unicasting, multicasting, and broadcasting, they were designed solely to whet your appetite for multicasting. Multicasting can be, and is, supported in a variety of configurations, including communication between end systems and communication between routers. These are best thought of as different multicasting applications, because they both use the same set of multicast mechanisms.

It is important to note that multicasting uses only User Datagram Protocol (UDP) as opposed to Transmission Control Protocol (TCP). Both are protocol suites that complement IP, but they function very differently. TCP is reliable in that it keeps track of individual packets sent and received (it must receive an acknowledgment of each packet received) and automatically puts received data back in its original sequence if it was received out of order. TCP can also determine if a segment of data is missing and can automatically retransmit it. UDP is a much less complex protocol. It offers a best-effort, unreliable transmission. If the data arrives at its destination, great. If not, live without it. Don't get the impression that TCP is better than UDP. They are different tools intended for different purposes. Knowing that multicasting uses UDP should tell you something about the intended field of use. Multicasting is a niche capability. It is invaluable for satisfying certain unique network requirements, but it is not a capability that can be used for every need. For example, if you needed to set up a streaming video session to transmit your company president's speech, you would find multicasting perfect. Streaming video is highly time-sensitive, so the additional overheads of TCP's reliable delivery mechanisms are not only unnecessary but antithetical to your needs. If a packet gets delivered late, just get rid of it. UDP's frugal overheads are ideal for supporting this type of application.

The next section thoroughly examines the multicast addressing mechanisms of the IPv4 protocol suite.