Introduction

The Internet was originally designed to carry two types of traffic, unicast and broadcast. Unicast traffic is sent from a single sender to a single host (or receiver), providing one-to-one delivery. Broadcast traffic goes from a single sender to all hosts, providing one-to-all delivery. Multicast traffic offers a third model, sending traffic from a single sender to many hosts (one-to-many delivery) and from many senders to many receivers (many-to-many delivery). Applicationssuch as streaming audio and video, collaborative groupware, teleconferencing, distributed online games, and "push" technology that sends periodic data delivery, such as stock quotes and sports scoresare well-suited for multicast because from a single source of data, they want to reach a specific, limited audience scattered across the Internet. If these applications use a unicast model, they must set up a session with each individual viewer. This places a heavy overhead burden on the source, which must replicate the video or audio stream for each customer. If these applications instead broadcast a single stream, the burden shifts to devices all across the network, which must replicate the stream regardless of whether there are downstream receivers interested in the video or audio stream. Multicast provides a way for these applications to deliver a single stream to all interested listeners.

Multicast networks consist of servers, which are the sources of a stream of multicast traffic, and clients, who are the receivers (or listeners) of the stream. A multicast stream is a flow of IP packets whose destination address is in the multicast address range of 224.0.0.0 through 239.255.255.255. (In classful routing, this is the Class D address space.) Each multicast address is the address of a multicast group. Routers use a combination of the sources unicast IP address and the multicast group to track multicast forwarding state. The notation used to represent this is (S,G), which is pronounced "ess comma gee." A common variant of this is (*,G), pronounced "star comma gee," where the asterisk is a wildcard that applies to any source sending to the group.

Multicast senders and receivers are generally PCs or hosts connected to a multicast enabled router, which is the DR for the sender or receiver. Receivers use a group membership protocol to tell their DRs which multicast streams they want to receive and to dynamically join and leave multicast groups. Routers run a multicast routing protocol to direct the streams from the sources to the correct receiving networks. Using this protocol, the routers build a delivery tree, called a distribution tree, between the sender (or senders) and receivers of a multicast group. Multicast data follows the path of the distribution tree. Data flows downstream on an outgoing interface toward the receiver and upstream on an incoming interface toward the source.

Hosts use the Internet Group Membership Protocol (IGMP) to inform routers about which multicast groups they want to join, and routers use IGMP to verify that a host is still interested in listening to a group. There are three versions of IGMP, all supported by JUNOS software. Version 1 ( RFC 1112) runs on Windows 95 computers, and Version 2 ( RFC 2236) runs on most Unix hosts, including Mac OS X, and on Windows 98, Windows 2000, and Windows NT systems. IGMPv2 adds explicit leave functionality so hosts can report to the router when they are no longer interested in a group. (In IGMPv1, the host simply stops sending report messages, and after some time, the router assumes the host is no longer interested in the group and stops forwarding traffic for that group.) IGMPv3 ( RFC 3376), supported by Windows XP systems, adds source filtering so the host can include and exclude specific sources when requesting multicast packets. Source filtering is required for SSM.

Perhaps the biggest difference between unicast and multicast is that unicast routing is concerned about where a packet is going and multicast routing is concerned about where a packet comes from. Unicast routing looks up a packets destination address in the routing table to determine which interface leads toward the destination. The result is that unicast routing forwards packets from their source to (or toward) a destination. Multicast routing uses RPF to set up forwarding state from the receiver to the source (or root) of the distribution tree. RPF checks the routing table to determine the interface that is closest to the root of the tree, and this RPF interface becomes the incoming interface for the multicast group.

Multicast uses two methods to build distribution trees. With shortest path tree ( SPT), the root of the tree is the multicast source. When a router learns that it has a directly connected listener for a group, it tries to join the tree for that group, building an SPT for that group. The router sends a Join message (specifically, an (S,G) Join message) out the upstream router for that group to let the upstream router know it wants to receive packets for the group. The upstream routers repeat this process until the Join message either reaches the DR for the multicast source or reaches a router that already has multicast forwarding state for the (S,G) pair. This process creates a branch from the receiver to the source.

The second way to build distribution tress is with a shared tree, in which the root of the distribution tree is not the source but rather is a router somewhere in the network. In Protocol-Independent Multicast Sparse Mode ( PIM-SM), this router is called the rendezvous point (RP). With this model, the listeners DR router does not know the sources address but knows how to reach another router in the network (the RP) that does know the address.

There are two broad types of multicast routing protocols. Dense protocols use a push model, flooding traffic throughout a network and pruning back its distribution trees when the traffic is not wanted, a behavior called flood and prune. The Distance-Vector Multicast Routing Protocol (DVMRP) and Protocol-Independent Multicast-Dense Mode (PIM-DM) are examples of dense protocols. DVMRP was the first of the multicast routing protocols. It was developed in the early 1990s and was the first multicast protocol to run on the Internet Multicast Backbone ( MBONE), starting in 1992. (The MBONE now uses PIM-SM.) DVMRP uses a simple distance-vector routing protocol similar to RIP to create its own routing table for forwarding and loop detection. PIM-DM also uses the flood-and-prune mechanism, but consults the unicast routing table populated to perform RPF checks, a property that gives PIM-DM (and PIM-SM) its protocol independence.

Dense protocols work well in domains that have a dense population of receivers, so most or all subnetworks are interested in receiving traffic from most or all active multicast groups. However, the flood-and-prune model does not scale for the Internet, where receivers are sparsely scattered throughout the network. For this reason, and because the flood-and-prune model uses a lot of network bandwidth and requires all routers to store all group state information, DVMRP and PIM-DM are rarely used. Also, DVMRPs underlying RIP-like distance-vector protocol does not scale across the Internet.

Sparse protocols use a pull model, waiting for explicit join requests from receivers and sending traffic only to where it is requested. Sparse protocols are a good choice when groups of multicast receivers are sparsely distributed across the network and network bandwidth is limited. Waiting to receive explicit join requests from receivers before forwarding multicast traffic is more scalable across the Internet and other large networks. PIM-SM is an example of a sparse protocol. PIM-SM was developed in the mid-1990s. As mentioned above, PIM uses the information in the standard unicast routing table, inet.0, when making RPF decisions. This routing-table information is learned from whatever unicast protocols are running on the router, and it is this property that makes PIM independent of any specific protocol.

In place of the DVMRP flood-and-prune model, PIM-SM uses RPs, which are routers that learn about all multicast sources and multicast receivers within their administrative domain. Multicast DRs send PIM Register messages to announce their existence, and they send PIM Join/Prune messages to announce their interest in a group. As the shared root, the RP is the matchmaker for the sources and the receivers.

You administratively configure the RPs in your domain, and one RP is active at a time. (Specifically, one RP per multicast group is active at one time in the case that some RPs do not service all groups.)

DVMRP and PIM are both multicast routing protocols, using RPF to forward multicast traffic. A number of other protocols support functions required by DVMRP and PIM, but they are not routing protocols because they do not handle forwarding state information. The Multicast Source Discover Protocol ( MSDP) expands PIM-SM to allow RPs in different autonomous systems to learn about active multicast sources in other ASs. Effectively, MSDP makes it possible for multicast applications to run across the global Internet. Also, BGP has been extended with Multiprotocol BGP ( MBGP; see RFC 2858) so that BGP carries NLRIs that can be used by other protocols, including multicast. MBGP allows a multicast router to create two separate routing tables, one that is used to make unicast routing decisions and a second to make RPF decisions.

For more information about multicast, see Interdomain Multicast Routers: Practical Juniper Networks and Cisco Systems Solutions (Addison-Wesley).