Multicasting

Most traditional IP applications, such as Web browsing and e-mail, employ unicasting, in which a separate connection is set up between a server and each of its clients . In cases where every client has unique needs-looking at a different Web site, reading a particular message- unicasting makes sense. There is no wasteful duplication of data.

But consider cases in which multiple clients all want the same data at the same time. Here, a server once again is connected to each of its clients, but this time it sends an identical data stream to each client. This is a waste of both server and network capacity. For example, suppose that a server is offering a live video stream that requires 1Mbit/sec for each client. With a 100Mbit/sec NIC on the server, its interface would be completely saturated after 90 or so clients had connected.

Worse, replicated unicast transmissions are extremely wasteful of network capacity. Figure 1 demonstrates this graphically, suggesting how wide the data pipe must be to get 90 copies of the same information from the server to all of its clients. With 90 clients separated from the server by two router hops and two switch hops, as shown in the figure, a 1Mbit/sec unicast channel winds up consuming a total of 180Mbits/sec of router bandwidth and 180Mbits/sec of switch bandwidth.

Figure 1: With Unicast Propagation Of A Stream, Data Must Be Wastefully Replicated.

This is where multicasting comes in. It permits our server to get away with transmitting only a single stream, regardless of how many clients have requested it. Whenever this stream traverses a multicast-enabled switch or router, it is simply copied -but only to branches of the tree where clients that requested the stream are located. As Figure 2 illustrates, this makes a dramatic difference to overall bandwidth consumption.

Figure 2: With Multicasting, Data Is Simply Copied At Every Branch Of A Spanning Tree.

What Multicasting Is Good For

It is important to concede that multicasting can work its magic only when all clients want the identical data simultaneously . It is ideal for live audio or video streams or for applications such as near-real-time stock tickers. Multicasting has also become popular for distributing software updates.

Unfortunately, multicasts are not practical on the Internet because, as we shall see, they cannot work unless every router or switch between the receiver and the sender is multicast-enabled. Most ISPs have not modified their networks to support multicasting because (among other reasons) there has been relatively little public demand for it-a classic chicken-and-egg problem.

Multicasting is being promoted by the IP Multicast Initiative (IPMI), an industry consortium of more than 100 companies, including Cisco Systems, 3Com, Lucent Technologies, and Stardust Technologies (Campbell, CA).

Meanwhile, numerous multicast-enabled subsets of the Internet already exist. To list them all would be beyond the scope of this tutorial, but I must briefly mention the Multicasting Backbone (MBone). The first part of the MBone was created as long ago as the summer of 1988, when a multicast tunnel was established between Stanford University and Bolt, Beranek, and Newman (Cambridge, MA). For more information on the history of multicasting, see "IP Multicast Streams to Life," Network Magazine , October 1997.

What You Need To Use It

Multicasting is easiest to implement over a single LAN, as Ethernet readily supports unicasting, broadcasting, and multicasting at the Data-link layer. To expand multicast traffic to a WAN, however, the Network layer must be involved.

The first issue to be dealt with at layer 3 is addressing. When a sender initiates an IP multicast, it assigns to it an IP address defined by RFC 1112, called "Host Extensions for IP Multicasting." This Class D address, falling within the space from 224.0.0.0 to 239.255.255.255, specifies a multicast host group . A host group has a dynamic membership, as end users (hosts) can tune in or out at any time. In fact, a host group's IP address is much like a radio station's frequency, with the exception that hosts are able to be members of multiple groups simultaneously (few of us voluntarily listen to two radio stations at the same time!)

The second issue is registration, a method for letting the WAN know that any given host wants to be part of a group. Registration is accomplished via the Internet Group Management Protocol (IGMP), which was also defined by RFC 1112. A user 's host application, such as the Windows Media Player or other multicast-enabled client, sends an IGMP report-encapsulated in an IP datagram-to the LAN router. From there, the report traverses other routers, if necessary, until it reaches the sender.

Periodically, each multicast-enabled router must send an IGMP query to all the hosts on its subnet. Each host must then respond with a further report or reports -one for each of the host groups it wants to continue being a member of. (A host does not need to send a report for a given host group if it has already seen a report for that group on its subnet. This helps eliminate network congestion locally.)

Pruning The Tree

If no IGMP reports are received from a given subnet, then no multicast traffic needs to be sent to that subnet. A simplistic method for shutting off transmissions where they are not required would be for the sender to maintain a table identifying all participating subnets, and then to send a copy of its data to each. However, that would negate some of the advantages of multicasting, since many of the data streams would follow the same path throughout most of the network.

So we now come to the third layer-3 issue-routing. IGMP specifies that routers interact with one another to exchange information about neighboring routers. A single router is selected as the Designated Router for each physical network; these routers then construct a spanning tree to connect members of any given IP multicast group.

Thanks to the spanning tree, there is just one path between every pair of routers. Multicast-enabled routers create new branches in the tree only when they need to, copying multicast datagrams to each as required. When a branch no longer leads to any hosts, it is pruned from the tree.

Many different IP multicast routing protocols and algorithms have been proposed. Dense-mode protocols are most appropriate to networks where bandwidth is relatively plentiful and there is at least one multicast group member in each subnet. They initially assume that all hosts are part of a multicast group, sending out traffic until they are informed otherwise (at which point the tree is pruned). Examples of dense-mode protocols include Distance Vector Multicast Routing Protocol (DVMRP), Multicast Open Shortest Path First (MOSPF), and Protocol Independent Multicast-Dense Mode (PIM-DM).

Sparse-mode protocols begin with the assumption that few routers in the network will be involved in any multicast. They minimize network traffic by adding branches to the tree only when explicitly requested to do so. As you can imagine, sparse-mode protocols, which include Core-Based Trees (CBT) and Protocol-Independent Multicast-Sparse Mode (PIM-SM), are better suited to WANs than are dense-mode protocols.

Transports Of Delight

Now that we have our multicast-enabled network, we still have to decide which protocol to use to give us adequate QoS at the Transport layer. Most of the Internet, of course, uses TCP, which establishes a feedback loop between the sender and the receiver. As mentioned in the Tutorial, "H.323", TCP is highly reliable, but it's also prone to delay and to sending data in a bursty manner.

Most multimedia applications therefore improve performance, even when unicasting, by switching to UDP and settling for its "best-effort" services. TCP would not be suitable for multicasting in any case, since any server would gag when faced with simultaneous acknowledgements from dozens or hundreds of clients.

Though many multicast applications feature loss-tolerant data such as audio or video, some kind of feedback mechanism is still desirable. Real-Time Transfer Protocol (RTP) and its feedback-loop companion Real-Time Transport Control Protocol (RTCP) provide one answer to this problem. RTP is both a proposed IETF standard (RFC 1889) and an ITU standard (H.225.0). It typically runs on top of UDP, adding to it the timing information necessary to synchronize and display audio and video data. RTCP works in conjunction with RTP, providing feedback from receivers about the QoS they are experiencing.

RTP and RTCP can keep feedback traffic to 5 percent or less of overall session traffic. When any receiver detects that it has failed to hear a sequenced packet, it waits for a random interval, after which it sends a report back to the sender and to all other receivers. If, while waiting to send a report, it hears one from another receiver, it will cancel its own report.

Another protocol relevant to multicasting is the Real Time Streaming Protocol (RTSP), first published as a proposed standard (RFC 2326) in April 1998 by the IETF. RTSP does not deliver data by itself, but instead uses RTP as a transport protocol. RTSP acts as a framework for controlling multiple data delivery sessions, helping switch between TCP, UDP, and RTP sessions as required. One significant aspect of RTSP is relevant only to unicasting: It can provide VCR-style controls such as pause, fast-forward, reverse, or seek a particular spot in a previously recorded stream.

However, RTSP also helps with firewall configuration, historically a problem in both multicasting and unicasting. Application-level proxies need to be aware of, and to translate, specific client and server ports; similarly, network address translators must remap specific client ports. If incoming protocols and ports are unrecognized, the traffic winds up getting rejected-to the frustration of would-be recipients. RTSP helps prevent this by including information about transport mechanisms and port numbers in an initial setup transaction.

In The Future

This tutorial has touched on just a few of the many protocols and technologies involved in multicasting. It is a technology that is rapidly evolving, both to enhance interoperability and to help scale performance for use on the Internet.

The main development that multicasting awaits, however, is simply public demand. This will materialize-perhaps sooner rather than later-as users migrate to high-speed Internet connections.

Resources

For a primer on IP multicasting, links to information about the Multicasting Backbone, and implementation notes, see www.cisco.com/warp/public/ 732/ multicast/.

For a list of current Internet drafts relevant to IP multicasting, see www.ipmulticast.com/techcentral/drafts.htm.

To learn more about Real Time Streaming Protocol (RTSP), see the RTSP FAQ at www.real.com/devzone/library/fireprot/rtsp/faq.html.

See also Dave Kosiur's book IP Multicasting: The Complete Guide to Interactive Corporate Networks (Wiley and Sons, 1998, ISBN 0471243590).

This tutorial, number 127, by Jonathan Angel, was originally published in the February 1999 issue of Network Magazine.