The Challenge Of Implementing IP Multicast.

IP Multicast has been hailed as the catalyst for ushering in a new generation of Internet-based services such as video on demand, broadcast video, and collaborative groupware applications. The promise of IP multicast is that it allows the simultaneous distribution of realtime voice, video, and data to large numbers of subscribers, while making relatively low demands on available bandwidth and server resources. However, as the level of noise surrounding IP Multicast continues to grow, it's important to examine several key factors which have emerged that may inhibit its widespread deployment. These issues include group management and scalability in the LAN, WAN, and Internet, as well as the challenge of providing reliable multicast transmissions.

Within the realm of IP, most communication between hosts utilizes one of two transmission types, broadcast and unicast. These are defined as follows:

* Unicast transmission is a one-to-one form of communication. Data is sent from one host directly to another host. All hosts listen for unicast traffic and process only those packets that are sent directly to them.

* Broadcast transmission is a one-to-all form of communication. Data is sent from one host to all other hosts on the network. Broadcast transmissions are sent to a special destination address that is read and processed by all hosts.

IP Multicast offers a third possibility, one-to-many communication. With IP Multicast, a host can transmit data to a large number of receivers that specifically request to receive that data. Using the analogy of a radio, IP Multicast allows the receiver to tune in a specific channel and listen to information that is being sent to that channel. The concepts of unicast, broadcast, and multicast are illustrated in the Fig.

To transmit data to a group of multicast subscribers, the transmitting host sends one data stream to its nearest multicast-enabled router. This router then replicates the packet to other multicast routers within the group. The distribution of multicast data resembles a tree with the originator of the transmission sitting at the top of the tree. Since the transmitting host only needs to send one stream of data to the network, there is a benefit of reduced performance requirements of that host as a reduced bandwidth requirement for large amounts of data distribution.

Hosts wishing to receive IP Multicast data subscribe to an "IP Multicast group" (similar to tuning to a station using our previous radio example). The originator of the IP Multicast data stream creates an IP Multicast group by using a special set of IP addresses specifically reserved for IP Multicast. These addresses make up the Class "D" address range (224.0.0.0 to 239.0.0.0). Within Ethernet LANs, a special MAC address prefix has been reserved that allows for the mapping of Class "D" addresses to LAN addresses. To subscribe to a multicast group, a host issues a message, using a "Group Management Protocol" message to its nearest multicast-aware router or switch. The router or switch keeps track of multicast group subscriptions and forwards multicast traffic received from other multicast switches and routers to the appropriate hosts.

Typical Requirements For Multicast

IP Multicast applications are generally broken up into three general categories. These are:

1. One-to-many. One-to-many applications are the most widely deployed types of IP Multicast applications. In one-to-many applications, an application server transmits data to a group of receivers. Examples of this type of application include live broadcasts of corporate events such as an all-hands meeting, corporate news tickers, and the distribution of software to a large number of hosts.

2. Many-to-one. Many-to-one applications are generally two-way request/response applications where either end may generate the request. An example of a many-to-one application is a network management server that uses IP multicast to pool a group of devices for management purposes.

3. Many-to-many. Of all the possible applications that can benefit from IP multicast, many-to-many applications are the most powerful. In many-to-many applications, hosts can both send to and receive from the multicast group. If you think of one-to-many applications using our radio example, then many-to-many applications would be the equivalent of a CB radio, where each end device can receive or transmit information to a channel. Examples of many-to-many applications include collaborative groupware, multimedia audio/video conferencing, chat groups, distributed simulations, and multi-player games.

Group Management In The LAN

Implementing IP Multicast provides little benefit without the right LAN architecture. For an organization to realize the greatest benefits associated with deploying IP Multicast, it must have already implemented LAN switching to the desktop or to small workgroups and the LAN switches must be capable of supporting a group messaging protocol such as IGMP. In shared environments or in environments without IGMP support in the LAN switch, multicast traffic is forwarded to all hosts in the LAN, regardless of whether or not they are subscribed to multicast groups. This results in a waste of bandwidth, transmitting data where it is not needed.

Even though IGMP is a Layer 3 function, more and more vendors are implementing IGMP functionality in Layer 2 switching products via "snooping." In this environment, the switches can switch multicast packets directly to the individual recipients so that devices that wish to receive IP Multicast packets see them only.

One important item to note in reference to multicast switching is how switches handle inter-switch multicast traffic. In early implementations of IGMP, switches would flood multicast traffic to all their peers, regardless of whether or not there were subscribers attached to those peers. As a result, IP Multicast traffic was flooded to switches that did not need to receive it. Newer management protocols such as Cisco's CGMP and the GARP Multicast Registration Protocol (GMRP, part of the 802.1p standard) tackle this problem by restricting the propagation of multicast traffic to only those switches that have multicast subscribers attached.

Group Management And Scalability In The WAN

The challenge of group management in the WAN is due to the very nature of multicast: that individual groups must be created for each multicast application or service. All multicast-enabled routers within a network must maintain information about each group, just as routers must maintain routing tables for each subnet. Many organizations are already finding their core routers over-burdened by the demands of maintaining large Internet routing tables--as well as processor intensive routing protocols such as OSPF--and the additional demands of having to maintain large tables of multicast groups and membership information may significantly impact router performance.

Also of concern in deploying IP Multicast applications are bandwidth requirements. While one-to-many applications usually require very little bandwidth, many-to-many applications may require substantial bandwidth for acceptable performance. These additional bandwidth requirements must be taken into account in order to ensure that the deployment of multicast applications can be supported by the current available bandwidth within the WAN.

For these reasons, as organizations look to deploy IP Multicast within their networks, they will need to pay special attention to network management to ensure that they are not significantly impacting current network operations. Fortunately, several network management tools specifically designed to monitor multicast traffic exist. These include such applications as Mrinfo, Mtrace, RTPmon, Mhealth, Multimon, and Mlisten. New modeling tools such as Ganymede's Chariot Tool Suite allow network managers to model the effects of deploying multicast to their networks before it is actually deployed. (A more detailed discussion of these tools is contained within the paper Managing IP Multicast Traffic, A First Look At The Issues, Tools And Challenges available at the IP Multicast Forum's Web site at www.ipmulticast.com).

Group Management And Scalability In The Internet

Currently, all multicast routers in the Internet-based Mbone share the same multicast routing table. While this strategy has been useful in demonstrating the feasibility of deploying IP multicast across the Internet, this approach has serious shortcomings in its ability to scale and to offer acceptable convergence levels. To get around these limitations, several vendors and working groups are currently developing the Multicast Border Gateway Protocol (MBGP).

Similar to the unicast BGP, MBGP allows for the sectioning off of multicast domains and provides a mechanism for the communication of multicast routing information between domains. MBGP allows providers to distinguish prefixes they will use for performing multicast reverse path forwarding (RPF) checks. MBGP is based on RFC 2283, Multiprotocol Extensions for BGP-4. Since MBGP is closely related to the current widely deployed BGP protocol, service providers can take advantage of the same policy control tools such as route maps to implement routing policy for multicast. The successful development of MBGP will allow for the deployment of multicast applications across multiple network domains.

Reliable Multicast Transport

At Layer 3, IP Multicast uses the User Datagram Protocol (UDP) as its transport. UDP does not allow for reliable data transmission, since there is no acknowledgement mechanism between the sender and the receiver. So there is no recovery mechanism for lost packets. While this approach is useful for one-way broadcasts such as video or voice streaming, it does not allow for the deployment of applications such as interactive multimedia or software distribution, both of which require a reliable transport mechanism to ensure that packets are properly delivered.

The biggest issue in delivering reliable IP multicast is where retransmissions occur. Obviously, each multicast receiver can't communicate directly with the source of the multicast transmission, since a potential of hundreds or even thousands of connections would overwhelm the ability of the sender to manage them. Instead, most reliable multicast protocols break the multicast group into smaller groups, where either the sender or the receivers are responsible for, maintaining reliable data transport.

A number of protocols either exist or are under development to enable reliable transport of IP Multicast traffic. These include the Real-Time Transport Protocol (RTP), Real-Time Control Protocol (RTCP) and the Real-Time Streaming Protocol (RTSP). While all three of these protocols were not specifically designed to carry multicast traffic, they were designed to carry multimedia traffic more efficiently than TCP and are capable of delivering reliable IP Multicast traffic.

For the delivery of non-multimedia, reliable traffic via IP multicast, several proprietary protocols exist, including the Multicast File Transport Protocol (MFTP), the Multicast Transport Protocol (MTP), and the Reliable Adaptive Multicast Protocol (RAMP). Several other protocols are currently under development.

In addition to the reliable transport control protocols, several efforts are underway by vendors, the Internet community, and IETF working groups to develop protocols that will allow for guaranteed reliability of IP multicast transmissions, utilizing QoS methods such as RSVP, the resource reservation setup protocol. Current status on the various initiatives to provide reliable IP Multicast can also be found at the IP Multicast Forum's site.

IP Multicast offers tremendous advantages to organizations looking for the most efficient way to distribute data to large numbers of hosts. However, significant concerns must be addressed before deploying IP Multicast applications in order to ensure that network performance is not adversely affected and that desired performance levels can be obtained. Fortunately, many products and initiatives exist or are being developed to address these concerns. For organizations deploying multicast applications, these technologies will prove invaluable to their success. Irwin Lazar is the network analyst of NetReference Inc. (Sterling, VA).