d of doing it one-to-one, the server could have established a one-to-many relationship -- a multicast -- using the bandwidth much more efficiently.
IP Multicast is an Internet Engineering Task Force (IETF) recommended standard, RFC 1112, that defines extensions to the Internet Protocol. The extensions are designed to keep corporate and public IP networks from drowning in traffic generated by certain types of applications. Specifically, IP Multicast works its magic where there are multiple receivers for a single transmission. For these kinds of network traffic, in a best-case scenario, IP Multicast reduces the network load in proportion to the number of receivers. If there are 10 receivers all receiving the same transmission, instead of each one having its own data stream, you could get as little as one-tenth the traffic.
But organizations have some good excuses for not getting around to IP Multicast. For one thing, IP itself has only recently gained popularity in commercial environments. In addition, IP Multicast has faced a daunting array of obstacles, from lack of applications to insufficient support in routers and other network equipment. These problems continue to hold back deployment.
That may change. The IP Multicast Initiative (IPMI) aims to ensure that the technology will firm up during 1997, preparing the way for a surge of deployment in 1998. Never heard of IPMI? Well, you've heard of some of its members: AT&T, Bay Networks, BBN Planet, Boeing, Cisco Systems, Hewlett-Packard, IBM, Intel, Lawrence Berkeley Laboratories, MCI, Microsoft, NASA, Netscape, Sun, and 3Com. Even with such heavy backers, IP Multicast deployment won't enter all at once. It will come first on corporate intranets. Widespread deployment on the Internet will take longer.
A Happy Medium
There are
three basic
ways for a sender to transmit identical data to multiple receivers: broadcast, multiple unicast, and multicast.
A broadcast is a single data stream intended for every station on the network. In forwarding broadcasts, routers (and switches) have no way to intelligently determine, on a case-by-case basis, whether any stations on a particular network actually need or want the data. Routers are usually configured to just pass or block broadcasts on any particular route. Routers are often set up to block broadcast traffic because of the potential for "broadcast storms," in which packets are broadcast and rebroadcast, severely degrading network performance. When they are blocked by all routers, broadcasts are limited to one LAN segment.
To get past routers and yet avoid flooding innocent bystanders (networks where there are no stations that need the data), the sender can transmit multiple unicasts. Each unicast is directed at a particular end station; the data is not forwarded to net
works where there are no recipients. However, generating a separate, identical data stream for each receiver is inefficient. It gobbles up network bandwidth, particularly with data-intensive applications. In addition, it's a lot of work for the sender, requiring extra processing power and memory.
Multicast offers a happy medium. A multicast is a single data stream that is intended only for stations that have joined the appropriate "multicast group." Other stations filter out multicast packets at the hardware level (e.g., Ethernet or Token Ring). The sender has to generate only a single data stream. Unlike a broadcast, however, a multicast-enabled router will forward a multicast to a particular network only if there are multicast receivers on that network. When the last station on a network segment leaves a multicast group, the router "prunes" the multicast data stream associated with that group by ceasing to forward that stream to that segment. Thus networks with no receivers are spared the burden of ca
rrying the multicast traffic. Pruning also makes "storms" much less likely. Multicasting offers the best of both worlds: efficiency for members of the multicast group, peace and quiet for nonmembers.
Using It Today
Pioneering development on IP Multicast, which was introduced in 1989, was done on the MBONE (multicast backbone). The MBONE, created in 1992 to multicast audio and video from IETF meetings, provides multicast service over the Internet.
Other early adopters included satellite networks, where return on investment is particularly high. That's because all satellite traffic is inherently multicast in nature, bandwidth is limited (often to 256 Kbps per satellite), and the number of receivers is large. In addition, satellite networks usually have no routers but act as one large bridged network. (Most of the problems in implementing IP Multicast relate to routers in one way or another.)
As an example of what can be accomplished using satellites and IP Multicast, Toys
R Us has reduced from more than 6 hours to less than 4 minutes the time it takes to send software updates to 865 stores nationwide. Toys R Us uses StarBurst Multicast, file transfer software from IPMI member StarBurst Communications, over a VSAT satellite network from Hughes Network Systems.
Intel currently has about 6000 employees who can watch and listen to company presentations using Intel's Proshare Presenter, IP Multicast-enabled video-distribution software. Intel is also using its IP Multicast network to test bandwidth reservation capabilities based on the Resource Reservation Protocol (RSVP). Intel has done some trials with Cisco, MCI, and a few customers, testing IP Multicast and RSVP. Intel licenses RSVP to developers for use in both multicast and unicast environments.
By the third quarter of this year 8900 General Motors auto dealerships will be receiving software upgrades and data from GM headquarters in Detroit, over the Hughes Network Systems satellite network, using StarBurst Multica
st. Multicasting reduces the time required for updates from 3 hours to about 20 minutes.
Multiproblems
Despite these examples, IP Multicast technology overall has made little headway on corporate networks. Interlocking obstacles stand in its way.
Although popular LAN topologies and nearly all current TCP/IP stacks, as well as router and switch products, support IP Multicast, their support may be minimal or not well tested in a variety of environments. As an example of minimal support, John Meylor, a network engineer for the NASA Research and Education network, notes that NASA's DEC GigaSwitches actually broadcast multicast traffic. Broadcasting is better than dropping the multicast traffic, but it would be better still if the switches intelligently multicasted it. That many IP Multicast implementations are not thoroughly tested results from the fact that most organizations have not enabled multicast capabilities in their networks. And some have not even upgraded to recent releas
es that support multicasting.
Users' lack of interest stems largely from the lack of killer applications that require multicasting. Applications must be modified to interface with the multicast capabilities of TCP/IP stacks, which in turn join and leave multicast groups by using the Internet Group Management Protocol (IGMP). Developers, however, haven't been eager to create such applications, knowing that most users' routers and switches aren't configured to support multicasting. In addition, the majority of IP applications, including individual Web, e-mail, and file access, derive no benefit from multicasting since they are inherently single-point-to-single-point applications.
IP Multicast has also been at odds with firewall strategies. The conflict stems from IP Multicast's use of the connectionless User Datagram Protocol (UDP). Connectionless protocols provide only best-effort delivery. They do not use acknowledgments (acks), negative acknowledgments (nacks), or retransmission to achieve reliab
le delivery. IP Multicast requires a connectionless protocol in order to avoid "ack implosion," in which the sender is overwhelmed by acks from multiple receivers. Unfortunately, the most popular type of firewall, the application gateway, cannot secure connectionless protocols.
It is possible to configure an application gateway firewall with a "generic service pass" that locks open certain ports for all packets. Unfortunately, that also opens a huge security hole. Even though it may be possible to limit exposure by performing further checks on the UDP packets that are passed, most organizations have chosen simply to block UDP entirely.
Unreliable delivery also means that a reliable protocol has to be layered on top of IP Multicast in order to accommodate applications such as financial transactions or file transfers, where any loss of data is unacceptable. Even for applications like video and audio multicasting, where some loss is acceptable, it might become more worthwhile to safeguard the quality
of the data stream as the number of stations receiving it increases. Unfortunately, reliable IP Multicast protocols and products that implement them have been slow in coming. Other protocols that could help insure the quality of IP Multicast data streams, such as RSVP, are also in their infancy. Given the need to reconfigure, replace, or upgrade routers and applications, to stay within firewalls, and to address reliability and bandwidth issues, most network managers have found it easier to curtail deployment of applications such as voice and video over IP rather than try to implement IP Multicast.
The major technical hurdle for Internet service providers (ISPs) has been the lack of a protocol for interdomain multicast routing (IDMR). Protocol-Independent Multicast (PIM), Multicast Open Shortest Path First (MOSPF), and Distance Vector Multicast Routing Protocol (DVMRP), the multicast routing protocols in common use, are not designed for multiple autonomous systems that do not necessarily want to share a
ll their routing information. All three protocols lack controls to limit route propagation based on policy considerations, such as definitions of autonomous systems. Instead, both protocols send all routing information to all known routers.
The Border Gateway Protocol (BGP) provides interdomain routing capabilities for IP. There is no equivalent of BGP for IP Multicast. Lack of an IDMR protocol limits the scalability of IP Multicast and, along with limited bandwidth, is a major reason why the MBONE has only about 30,000 users. Growth is severely limited if all routers have to contain all routing information for the whole network. "It's a flat routing topology," says NASA engineer John Meylor. "The only way to scale is with a hierarchical routing topology."
DVMRP
, the protocol currently used on the MBONE, can also be tricky to configure. DVMRP maintains its own routing tables, separate from the unicast routing tables, which is why the MBONE is described as an overlay to the IP
network. With the overlay architecture, there can be discrepancies between DVMRP routing tables and unicast routing tables, with the result that multicast traffic does not follow the routes that the organization prefers for connecting to particular network locations.
PIM solves the routing discrepancy problem by using the unicast routing tables for multicasting. But, of course, it has its drawbacks. In particular, if there are specific routes that multicast traffic should or must take, it can be difficult to ensure that it will continue to take those routes as the
unicast routing
topology adjusts automatically to equipment or link failures. In today's networks, where only some of the routers are likely to be multicast-enabled, there usually are specific routes that multicast must take.
NASA addressed this problem partly by moving the responsibility for the multicast network to the same groups that were managing the unicast network, Meylor explains. That shift made it much ea
sier to insure that the unicast and multicast routing tables are congruent.
NASA also uses PIM in the Cisco-based portions of its network. The hardware usually has a decisive influence on the choice of multicast routing protocol, says Meylor. Cisco has focused on PIM, for instance, while Proteon is more oriented toward MOSPF. NASA tends to use the protocol that works best on the particular type of router.
Big ISPs and very large organizations also need to know how routers will react to steady, high volumes of multicast traffic. Unfortunately, little testing has been done in this area. There are some indications that routers may need hardware or software enhancements in order to be able to handle continuous high volumes of multicast traffic at backbone speeds, such as the OC-3 (155 Mbits per second) on MCI's backbone. That is a major reason that MCI is supporting only multicast tunneling, not native multicast, on its production network today.
"We're not comfortable with the level of maturity
of IP Multicast code in Cisco routers," says Rob Hagens, MCI's director of Internet engineering. "We don't want to take any chances with running into multicast problems that could affect nonmulticast traffic."
On the MBONE, some Cisco routers managed by NASA have had performance problems when traffic has been very heavy, Meylor says. "The router code may be fine," surmises Meylor, "but the input buffer may be full. With streaming multicast, you may be more likely to get head-of-line blocking on switches and routers. It may be that the interface cards or switching mechanisms were not designed for that kind of traffic."
Another question of special interest to large users and ISPs is whether to use the multicasting native to asynchronous transfer mode (ATM) or IP Multicast over ATM. The former requires a gateway between the two multicast technologies. The latter introduces added overhead, although that may be minimized with technologies such as Ipsilon Network's IP switching or Cisco's tag switching.
The jury is still out as to which approach is best, according to Meylor, who currently leans toward IP over ATM.
ISPs have also had business reasons for being ambivalent, at best, toward multicast capabilities: Multicasting tends to reduce traffic. Although many Internet connections are priced at a nominally flat rate, ISPs may have graduated services, which in effect allow them to charge more when there is more traffic. Thus less traffic could turn out to mean less income. Theoretically, ISPs could charge more for multicast connections. However, most are not set up with the traffic monitoring and accounting mechanisms to do that today. In addition, once in the ISP's network, multicast traffic can "explode" as it is routed to multiple receivers. ISPs currently have no way to track or bill for such explosions and might therefore tend to grossly undercharge for multicast traffic.
For customers who demanded multicast capabilities, some ISPs have implemented multicast tunneling. Tunneling is relative
ly quick and easy to implement and may be the best solution when both the number of customers using IP Multicast and the quantities of multicast traffic are limited. However, there are two major disadvantages to tunneling. First, it involves setting up and managing separate multicast servers or gateways. Native multicast, in contrast, is implemented and managed on routers, along with native IP. Thus all the work that vendors and organizations have put into streamlining and automating router management has to be either duplicated or, more likely, sacrificed for multicast traffic. Second, tunneling inserts the encapsulation process into the transmission chain, slowing things down and introducing scaling problems.
We're Working on It
Vendors are working on some of these problems now. For instance, IP Multicast support in routers and other equipment is being widely tested this year. MCI has RSVP and native IP Multicast running in the lab and hopes to have native IP Multicast deployed thro
ughout its network by the end of the year. That schedule may be reasonable, according to NASA's Meylor, given that major router vendors have been working on multicast capabilities since at least late 1996. For the most part, he adds, IP Multicast is running fine on NASA's Cisco-based router network.
At least two companies are pushing reliable protocols for IP Multicast. StarBurst Multicast is based on the company's Multicast File Transfer Protocol (MFTP). As the name implies, the protocol is designed strictly for file transfer as opposed to real-time applications like videoconferencing. StarBurst Multicast is being used to distribute software, to transfer business-critical information such as inventory, parts, pricing, and account information, and to prevent degradation in multimedia files.
In contrast, the Reliable Multicast Transport Protocol (RMTP) used by Lucent Technologies in its e-cast product can handle file transfer, real-time applications, and near-real-time applications. Whereas StarBur
st Multicast involves one sender and multiple receivers, Lucent's e-cast is based on a single sender, an optional hierarchy of "designated receivers," and multiple ordinary receivers. The ordinary receivers are divided into domains, with receivers in each domain sending status packets (which combine the functions of acks and nacks) to the designated receiver in that domain. The designated receiver also performs retransmissions where necessary. Since the sender receives status packets only from the first tier of designated receivers, there is no ack implosion. If a designated receiver fails, receivers in that domain use the designated receiver one step closer to the sender in the hierarchy. RMTP is currently being used in the AT&T network, transferring billing records from toll switches.
Both StarBurst and Lucent are likely to offer their technologies as a basis for standardization efforts within the IETF. Because reliable protocols are implemented primarily on end stations, it could actually be usef
ul to have multiple standards for different applications.
Other issues appear to be on the back burner. The firewall problem remains, for instance, and is a major reason why most organizations may implement IP Multicasting on their intranets but not try to exchange multicast traffic over the Internet. If organizations keep IP Multicast traffic behind the firewall, there is no requirement to pass UDP through the firewall.
IDMR is another area not being addressed currently. "Interdomain routing is really a research issue, at this point," says Henning Schulzrinne, an associate professor in the computer science department at Columbia University and one of the architects of the Real-Time Transport Protocol (RTP) used on the MBONE. There is not even a proposal for a standard, he adds.
The bottom line is that for most of 1997, the bulk of IP multicasting will be confined to satellite networks and bridged LAN environments. IP Multicast will see more deployment in routed intranets in 1998.
"The
real wild card is when native IP Multicast will available on the Internet," observes Steve Collins, vice president of marketing and business development for StarBurst. "I'm not counting on seeing widespread deployment until 1999." According to Todd Dagres, a general partner with Battery Ventures (Wellesley, MA), a venture capital firm focusing on the communications and software industries, IP Multicast could take five years to reach critical mass on the Internet.
Where to Find
Intel
Santa Clara, CA
Phone: 408-765-8080
Internet:
http://www.intel.com
Multicast to the Masses
