IP Multicast and Your Network

IP multicast is a process that transmits information from a source to multiple destinations with one data stream, rather than with multiple streams. Multicast can greatly reduce the network traffic that bandwidth-hungry applications such as videoconferencing, software distribution, and Webcast create. Many Windows NT network administrators realized the power of IP multicast and the benefit of IP multicast applications in 1996, when Microsoft released NetShow 1.0, an IP multicast-enabled multimedia application. Microsoft also developed Active Channel Multicaster in Site Server 3.0 to multicast Web contents to browsers, and the company implements Internet Group Management Protocol (IGMP) version 2, an enhanced IP multicast function, in its Windows OSs. Other pioneering multicast-application companies have delivered commercial IP multicast applications—Cisco Systems' IP/TV and StarBurst's Multicast File Transfer Protocol (MFTP) are two examples.

Network vendors widely support IP multicast in their routers. Internet Service Providers (ISPs) have started to offer multicast service in their backbones (e.g., UUNet's UUCast service). IP multicast and its applications have come out of test labs and Multicast Backbone (MBone), an Internet test bed, to find homes in corporate and ISP production networks. For example, Toys R Us uses MFTP to distribute software updates to its more than 800 stores, paring the time required to make a 1MB file transfer to those stores from 1 day to 4 minutes. Many other companies are using or starting to use IP multicast. The sidebar "A Case in Point: Microsoft's Multicast Network," page 110, reveals how Microsoft uses real-world IP multicast in its company network.

Before you can implement an efficient multicast network, you need to understand IP multicast technologies. I discussed IP multicast basics, network checkpoints, and NetShow Live in the May 1997 article "Be Prepared for IP Multicasting Applications." In this article, I further explore IP multicast technologies and their enhancements, and I describe how you will use them in your multicast network.

What Is an IP Multicast Network?
The purpose of IP multicast is to deliver a data stream from a source to a group of receivers. Receivers interested in a particular multicast application join the application's multicast group. A multicast group is dynamic and transient—receivers can join and leave the group at will, and the group disappears when no receivers remain. Group members listen to and receive data that the source delivers to the group's IP multicast address. Individual Class D IP addresses in the range from 224.0.0.0 to 239.255.255.255 represent all multicast groups. The multicast's source doesn't need to join its group, nor does the source know who and where its receivers are. The source simply transmits multicast streams to the IP multicast address of its multicast group, then lets the network handle multicast data delivery. An IP multicast-enabled network can efficiently forward and route multicast data to receivers. Three key techniques manage multicast network delivery: scoping, group management, and distribution trees.

Multicast scoping determines how far a multicast stream can travel from its source. Limiting the range of a multicast can prevent business data from reaching outside a network, thereby providing security. In multicast group management, multicast-enabled routers keep track of multicast group membership through subnets the routers directly attach to. The multicast-enabled routers forward multicast data only to the subnets that have group members, thereby saving network bandwidth. Multicast distribution trees define data delivery from a source to a multicast group, then build an optimized distribution tree that contains a set of routers and links to let group members receive data from the source. Let's take a close look at each of these network delivery technologies.

Multicast Scoping
Traditionally, IP multicast uses a Time to Live (TTL) parameter in an IP multicast application and multicast routers to control the multicast distribution. When you define the TTL value in an IP multicast application, contents don't transmit beyond the TTL value. For example, if you set Site Server's Active Channel Multicaster TTL value to 16, you ensure that Site Server's Web contents don't multicast beyond 16 router hops. Each multicast packet carries a TTL value in its IP header. Just as in unicast, every time a multicast router forwards a multicast packet, the router decreases the packet's TTL by 1. By default, a router won't forward packets with a value of TTL=1. You can modify the default TTL threshold to another value on each interface in a multicast router. For example, if you set the TTL threshold to 10 on a router interface, only packets with a TTL value that is greater than 10 can pass that router interface.

TTL-based multicast scoping has a couple of shortcomings. First, defining a proper TTL value in a multicast application can be difficult. If the value is too large, your multicast data might go out of your network. If the TTL value is too small, your multicast data might not reach interested receivers beyond the multicast scope. Second, if someone sets custom TTL thresholds in certain router interfaces, your multicast range can be unpredictable. For example, you wouldn't be able to divide your network into multicast regions to limit multicast applications to those regions, because if one router has an interface TTL threshold that is lower than a packet's TTL value, the router will forward the packet.

To overcome these limitations, the Internet Engineering Task Force (IETF) proposed Administratively Scoped IP Multicast as an Internet standard in its Request for Comments (RFC) 2365 in July 1998. Administrative scoping lets you scope a multicast to a certain network boundary (e.g., within your organization) by using an administratively scoped address. IETF has designated IP multicast addresses between 239.0.0.0 and 239.255.255.255 as administratively scoped addresses for local use in intranets. You can configure routers that support administratively scoped addressing on the border of your network to confine your private multicast region. You can also define multiple isolated multicast regions in your network so that sensitive multicast data will travel only within a designated area. Figure 1 shows a network with three multicast regions: Region 239.253.1.0 in Data Center 1, region 239.253.2.0 in Data Center 2, and region 239.253.3.0 in Data Center 3. When multicast data traverses Data Center 1, Router 1—which the boundary 239.253.1.0 defines—blocks any multicast packets with administratively scoped addresses of 239.253.1.x from transmitting to other data centers.

Multicast Group Management
A multicast network forwards multicast data only to network subnets that have receivers in the corresponding multicast group in a scoped multicast region. (Selective forwarding is the biggest difference between multicast and broadcast. Broadcast floods data to all subnets.) To forward multicast data to receivers in a scoped multicast region, routers need information about group membership on their local subnets. One router on each subnet periodically multicasts membership query messages to all computers on the local subnet. Computers on the local subnet who are group members respond to the router's query message with a membership report about the group they belong to. The router keeps this membership information in its group database. The local subnet computers also multicast membership reports to the groups they belong to. When other group members receive a member computer's report, the group members postpone their membership reports and wait for a variable period of time. This waiting period reduces membership report traffic and router processing time. As long as a router knows one group member on the local subnet, the router forwards multicast data to that subnet, and other group members will receive the multicast data. When a new member joins a group, the member doesn't need to wait for the next membership query from the router. Instead, the new member immediately sends a membership report as if in response to a membership query. When the router receives this report, it immediately forwards multicast data to the subnet on which the new member resides if the new member is the first member of that subnet's multicast group.

IGMP. Routers and computers use IGMP to exchange membership information. IGMP is an integral part of IP. The two standard versions of IGMP are IGMPv1 (RFC 1112) and IGMPv2 (RFC 2236). IETF released IGMPv2 as an enhanced version of IGMPv1 in November 1997. Today, many routers and OSs support IGMPv2. Microsoft implements IGMPv2 in Windows 2000 (Win2K), in NT with Service Pack 4 (SP4), in Windows 98, and in Win95 with Winsock 2.

IGMPv2's biggest enhancement is a group notification feature. In IGMPv1, a receiver that leaves a multicast group doesn't automatically notify the router. Rather, the router assumes no group member is on the local subnet if the router doesn't receive a membership report after several queries and waiting intervals. Several minutes or more can then pass before the router stops forwarding data to that subnet. In IGMPv2, receivers leaving a group directly inform the router. The router then queries the subnet to see whether any other group members remain. If the router doesn't receive a response, it assumes that no other group members exist on that subnet and stops multicast forwarding to that subnet.

IETF is working on IGMPv3 to further improve IGMPv2. IGMPv3 will include several new features. One such feature will let a computer specify which sources in a specific group the computer will receive data from.

Multicast Distribution Trees
Using routers' IGMP group membership information, a multicast routing protocol builds an optimized distribution tree to deliver multicast data from a source to the multicast group. Two kinds of distribution tree exist—source-based and shared.