IP Multicast and Your Network

A multicast routing protocol constructs a source-based tree with data that a source sends. When the local router connecting to the source receives the source's first multicast packet, the router broadcasts the packet to the edge of the network to search for receivers. If a router on the edge of the network doesn't find any receivers on its local subnets after checking its IGMP group database, the edge router sends a prune message to its nearest parent router on the path (or branch) from the source. The prune message removes the edge router from the branch. This pruning process proceeds, router by router, backward along the branch toward the source until coming to a router that leads to group members (i.e., an active branch). Through this broadcast-and-prune procedure, the multicast routing protocol forms a distribution tree that contains only active branches. The routing protocol repeats the broadcast-and-prune procedure periodically during multicast to update the distribution tree and reflect group membership changes.

Figure 2 illustrates the broadcast-and-prune procedure. In Figure 2, when the first multicast data reaches router R5, R5 sends a prune message to router R3 and removes itself from the tree because it doesn't have local group members. R3 is on an active branch, because its child router, R4, has local group members. The pruning process on R5's branch stops at R3. Routers R6 and R7 also prune themselves from the tree. The final distribution tree contains only two branches: one branch from the source to router R2, and the other branch from the source to R4.

A multicast routing protocol that uses the broadcast-and-prune procedure to set up a source-based tree is a broadcast-and-prune protocol. Because broadcast-and-prune protocols make periodic broadcasts, these protocols are suitable for use only in LAN environments with substantial bandwidth and densely populated receivers. The term for such an environment is dense mode. Another disadvantage of using broadcast-and-prune protocols is that if two different sources send data to the same multicast group, the protocol must create a source-based distribution tree for each source.

In contrast to the source-based tree, a shared tree, which the shared-tree multicast protocol builds, can support multiple sources to multicast data to the same multicast group using the same distribution tree. Shared tree fits into sparse mode when receivers are sparsely distributed on a low-bandwidth WAN.

A shared-tree protocol either automatically chooses or lets a network administrator manually define the root of a shared tree in a network. The root, which is a router, is known as a core or rendezvous point (RP). Roots are often the center of multicast groups. When a source's local router receives multicast data, the router forwards the data to the core of the multicast group. The core further multicasts the data to all receivers in the group. The shared-tree setup doesn't use broadcast-and-prune to find group members but requires all members to join the tree. When a router finds a local group member by checking its received IGMP group membership report, the router sends a join request to the core. The core or an intermediate router that is already in the tree responds to the request with a join acknowledgment, sending the acknowledgment to the requesting router. Figure 3 illustrates the join-and-acknowledgment process. When router R3 has a new local group member, R3 sends a join request to and receives an acknowledgment from the core of the group through the intermediate router R2. When router R5 sends a join request to the core via router R4, R4 returns the join acknowledgment to R5 because R4 was already in the tree for its existing local group members.

Because of the join function, shared-tree protocols require all routers in a multicast region to know the region's multicast group and core mapping information. A bootstrap router in the network collects the mapping information that cores advertise and distributes the information to other routers.

Multicast Routing Protocols
Five multicast routing protocols currently exist, and you can classify each into either the source-based tree (dense mode) or shared-tree (sparse mode) protocols. The three dense-mode protocols are Distance Vector Multicast Routing Protocol (DVMRP), Multicast Open Shortest Path First (MOSPF), and Protocol Independent Multicast-Dense Mode (PIM-DM). The two sparse-mode protocols are Protocol Independent Multicast-Sparse Mode (PIM-SM) and Core Based Trees (CBT).

DVMRP (RFC 1075) is the first multicast routing protocol researchers developed to implement MBone in the Internet, and DVMRP is still prevalent in MBone. DVMRP builds a source-based distribution tree based on broadcast-and-prune. The DVMRP tree includes a dedicated Routing Information Protocol (RIP)-like unicast routing protocol and depends on this protocol to determine the shortest path from the source to the multicast group when setting up the distribution tree. UNIX machines were among the first to implement DVMRP. DVMRP support is ubiquitous in almost all vendors' routers.

MOSPF (RFC 1584) is simply an extension of Open Shortest Path First (OSPF), a well-known unicast routing protocol in IP networks. OSPF divides a network into one or more OSPF areas and uses link-state information (i.e., information about router interfaces and network wires) to set up and maintain a unicast routing table. (To learn more about OSPF, see "Steelhead's OSPF Routing," August 1997.) MOSPF uses OSPF as the native protocol to advertise IGMP group membership in each router as part of the link-state information within an OSPF area. MOSPF can easily construct a source-based distribution tree by using the link-state database in a router instead of the usual broadcast-and-prune procedure. MOSPF supports multicast between multiple OSPF areas and uses border routers that link OSPF areas to forward IGMP group membership information and multicast data between OSPF areas. MOSPF is a native choice if your network uses OSPF as its unicast routing protocol. 3Com and Nortel support MOSPF in their routers.

PIM-DM, an Internet draft, uses broadcast-and-prune to form a source-based tree, similarly to DVMRP. However, PIM-DM uses the existing unicast routing protocol in your network, such as RIP or OSPF, to determine the shortest path from the source to the multicast group. The use of existing protocols is the reason behind PIM's name (Protocol Independent Multicast).

PIM-SM (RFC 2362) is another PIM protocol, but PIM-SM is suitable for use in sparse mode. PIM-SM uses shared trees to deliver data and refers to the root of a shared tree as an RP. However, a shared tree might not reflect the shortest path from source to multicast group. Thus, PIM-SM can let routers optionally switch to a source-based tree to receive source data after initial data delivery in the shared tree and based on some triggered conditions (e.g., if the shared tree's data delivery rate is too low). Cisco is PIM's primary advocate and supports both PIM protocols in its routers.

CBT (RFC 2189) is similar to PIM-SM. However, CBT uses only shared trees for data delivery and can't switch from shared trees to source-based trees, as PIM-SM can. CBT calls the root of the shared tree a core. Vendors haven't widely implemented CBT; I haven't found support for CBT in 3Com, Cisco, or Nortel routers.

Multicast on the Internet
MBone is a set of multicast networks within the Internet. MBone serves as a test bed researchers use to develop IP multicast and its applications on the Internet. MBone also hosts audio and video multicasts for IETF and some government organizations. The most popular multicast applications in MBone include the visual audio tool (vat), videoconferencing tool (vic), and whiteboard tool (wb). These applications run on UNIX as well as on NT and Win95. MBone uses the session directory tool (sdr) to announce public multicast sessions (i.e., applications). MBone users can use sdr to find particular sessions. Sdr is itself a multicast application.

MBone has connected thousands of networks to its backbone since 1992. Each network in MBone is a separate multicast region. Although MBone runs DVMRP on its backbone, individual multicast regions can use any multicast routing protocols internally. A network connects to MBone by a DVMRP tunnel, as Figure 4 shows, which lets multicast traffic pass through nonmulticast-enabled routers in the Internet by encapsulating a multicast packet in a unicast packet. You connect your network to MBone through major ISPs, and you can use DVMRP to tunnel your network to MBone. Most router vendors today support PIM-to-DVMRP and MOSPF-to-DVMRP interoperability, so you can easily use a multicast routing protocol other than DVMRP inside your network.

MBone, however, isn't for commercial use. And the Internet doesn't support native multicast, because many routers on the Internet don't speak multicast routing protocols. Most important, none of the IP multicast routing protocols I've described scales enough to work on the Internet, which contains many more routers than MBone does. Although PIM-SM and CBT are suitable for use over a WAN, both of these protocols require that all routers know all multicast groups and their cores or RPs. This requirement makes implementation impossible on the Internet. 3Com, Lucent, and Sun Microsystems are working on a new protocol, Simple Multicast Protocol, to implement IP multicast on the Internet. Simple Multicast Protocol will simplify the method by which routers keep track of the source and receivers of a multicast stream. The protocol uses an eight-bit identifier that consists of the IP multicast address and the IP address of the multicast source or core. When a receiver joins the multicast group, the receiver sends this identifier to the local router, which can immediately identify the multicast source and group.

Researchers are working on other prospective multicast routing protocols for the Internet, including Multicast Border Gateway Protocol (M-BGP) and Border Gateway Multicast Protocol (BGMP). M-BGP is integrated with border gateway protocol (BGP), an exterior routing protocol that the Internet uses widely to link routing domains between ISPs and organizations. M-BGP can support multitiered multicast and routing policies among ISPs and organizations on the Internet. BGMP is based on PIM-SM and CBT. BGMP identifies a root domain, rather than a root router, in PIM-SM and CBT for a multicast group on the Internet. From the root of the domain, BGMP builds a tree of domains.

IETF is doing the important work of defining a standard architecture of global multicast address allocation for multicast applications on the Internet. Currently, two multicast applications can't use the same multicast address on the Internet at the same time, or both applications will fail. This limitation is similar to the limitation whereby two computers can't have the same IP unicast address in an IP network. The IETF's draft of the global Internet multicast address allocation architecture uses multicast extensions to Dynamic Host Configuration Protocol (DHCP), called MDHCP, to dynamically assign multicast addresses from a multicast address allocation server (MAAS) to applications in an allocation domain, such as an ISP network and intranets. However, no authority—such as the Internet Assigned Numbers Authority (IANA), which centrally manages and controls IP unicast addresses—currently exists to assign a block of IP multicast addresses to ISPs and organizations.

Ready for Your Intranet
Although IP multicast technology isn't quite ready to be widely deployed over the commercial Internet, the existing IP multicast routing protocols such as DVMRP, MOSPF, PIM-DM, and PIM-SM work well in intranet environments. When you take advantage of Microsoft's and other vendors' delivery of multicast applications, you can build a multicast NT network and deploy such multicast applications as videoconferencing, training, Webcasting, file replication, and software distribution on your intranet to save your network bandwidth and help your users. The sidebar "IP Multicast Resources" lists some references that can help you plan your IP multicast network.