Preparing Your Network for IP Multicasting

When people hear the term IPmulticasting, they usually equate it with multimedia--Internet-based audio and video feeds on their corporate networks. But IP multicasting also is useful with a variety of corporate-class networking services, including the Network Time Protocol, Router Discovery and Microsoft Corp.'s WINS (Windows Internet Name Service). Proposals are on the table for multicast DNS, which will let clients query the network instead of specific DNS servers for information, and a multicast version of DHCP which would let queries propagate throughout a multicast-aware network without relying on BOOTP forwarders in the routers.

Such examples demonstrate how and why IP multicasting can build better, more flexible corporate networks without involving multimedia. Of course, multicasting also provides benefits to multimedia: It enables a one-to-many distribution of training videos, corporate presentations and other services to geographically dispersed users simultaneously, which just isn't possible with unicasts or broadcasts (see "Casting Off Old Myths with IP Multicast"). Allowing and encouraging the use of multicast traffic (with basic networking services) offers more flexibility and less overhead.

Multicasting, already a core part of the IP protocol, is a free service that ships with almost every OS. You don't have to enable it, and you don't have to rebuild your network to support it. However, to leverage its benefits to the fullest, you must understand how multicast works; this will enable you to tweak your network for optimal usage with existing applications and prepare for the onslaught of multicast-based applications.

Principles of Multicast Addressing

Today, most packets are sent as unicasts or broadcasts. Unicasts have a destination IP address pointing to a single recipient, while broadcasts have a destination address for all hosts on a specific subnet. The IP packets do not necessarily have to be different, but the destination address must correlate the packet with a specific host or with all the hosts on a specific network.

Multicast datagrams also must fit this model. The primary difference between a multicast packet and a unicast (or broadcast) packet is that the destination IP address refers to a group of hosts rather than to a specific host or network. When an application sends multicast traffic, you must examine the destination IP address--the only way to distinguish that traffic--which identifies the specific multicast group for which the datagram was meant.

In the IP world, multicast group addresses are known as "Class D" addresses and include all IP addresses in the range of 224.0.0.0 through 239.255.255.255. A few of these addresses refer to specific, well-known applications (some are shown in the table at left). For a detailed list of all the registered multicast groups, see the Internet Assigned Numbers Authority's online registry at www.isi.edu/in-notes/iana/assignments/multicast-addresses.

Figure 1

If a system wants to send data to a group of hosts, it only has to send the packets to the Class D address associated with that particular group. Any hosts listening for traffic destined for that IP address would then pick up the packets and process the contents, while other hosts would simply ignore the packets (if they actually saw them).

MAC-Layer Multicasts

If a host wishes to listen for traffic sent to a particular multicast address, it simply instructs the local IP stack and network adapter to begin monitoring for traffic destined for that particular group address. Two key elements to this process are the IP stack, which must know the Class D addresses to monitor (typically provided by the requesting application) and the network adapter, which needs to know the MAC (Media Access Control) layer addresses for monitoring.

The latter item is the most prickly: IP packets are processed and delivered according to the local system's Layer 2 topology addressing and framing services. In addition, a network adapter will process only the MAC-layer frames that contain either the local system's hardware address or the network's broadcast address (written as "FF:FF:FF:FF:FF:FF" on Ethernet).

With multicasts, neither of these methods will work because the datagrams are neither unicasts nor broadcasts, and will not have either of those addresses in the MAC-layer frame. Instead, since a multicast datagram is destined for many devices on one shared network, the Layer 2 frames require a neutral address to allow devices to read them.

Some network topologies provide unique multicast addresses at the MAC layer. These Layer 2 addresses can be mapped to Class D IP addresses. For instance, Ethernet offers a variety of multicast group addresses ranging from "01:00:5e:00:00:00" to "01:00:5e:7f:ff: ff." These addresses can be mapped to the Class D addresses, so that any traffic for "01:00:5e:00:00:01" is destined for the Class D address of "224.0.0.1."

The range of available Ethernet addresses only provides 23 bits for multicasting, while the Class D IP addresses use 26 bits. For mapping IP multicast addresses to Ethernet MAC addresses, some conversion is required, only using the last 23 bits from the IP multicast address. This method creates some overlap, with a few multicast groups sharing an Ethernet address. In this case, the IP software on the destination systems must perform some additional filtering, discarding any undesirable IP packets with a Class D address.

The Need for IGMP

Although this approach presents a challenge forEthernet, other topologies exhibit even more overlap, requiring tremendous filtering. For example, token-ring networks have a very limited number of group addresses, so all token-ring multicast frames must share the same group address of "c0:00:00:04:00:00."

Some networks don't provide any form of group addressing at all. Point-to-point networks don't even have MAC addresses, but instead only have send and receive wires. On such networks, a bridge or router must monitor the LAN side of the network for multicast packets on behalf of the downstream devices and then forward any matching frames to the remote devices.

Figure 2

However, in order for this to work, the end-point system has to inform the gateway device of the groups that it wants to monitor, so that the gateway will know for which multicast addresses it should be watching. This function is served by IGMP (Internet Group Management Protocol) version 2, which provides a set of simple "join" and "leave" messages. Whenever an end system wants to begin watching for specific multicast traffic, it will issue an IGMP join message, which the upstream device will see. Similarly, when the system wants to stop receiving traffic for a specific multicast group address, it can issue a leave message and the gateway will stop forwarding that traffic. This is important for dial-up links that want to end a video feed.

In addition, multicast routers will periodically issue surveys for active group memberships. If no hosts respond to the membership query, the multicast router can assume that no end stations on that particular network want that traffic, preserving even more bandwidth. For example, the screen at left shows a multicast router on Krill, running DVMRP (Distance Vector Multicast Routing Protocol), issuing a membership query for the local network, as well as the NTP server on Arachnid responding with a membership report.

Written by Eric A. Hall.
Copyright © 1999 CMP Media, Inc. Used with permission.