The switch to gigabit ethernet and other high-speed technologies will eventually increase the bandwidth available to users, but in the meantime, network managers should look for ways to get the most out of the bandwidth they have, says Ernie Halpern, of W3 Tech, which offers an HTML crash course.
One weapon in the campaign for network efficiency is IP multicasting, now moving from experiments on the Internet’s Mbone (Multicast backbone) toward commercial implementation. IP multicasting can reduce bandwidth demands when groups of users need the same data at the same time, so it’s ideal for such uses as pushing financial data, videoconferencing, streaming multimedia for training and corporate reports, as well as groupware such as shared whiteboards.
The simplest way of transmitting data to multiple recipients is to send a copy of the data to each individual. But this technique, called unicasting, wastes bandwidth–sending a 2M-bps MPEG video to only 10 users would saturate a network pretty quickly.
IP multicasting takes a different approach, letting the source transmit only one copy of the data and depending on multicast-capable routers to duplicate the data whenever more than one recipient is detected downstream. Only one copy of a multicast message passes a router in the network. Copies of the message are made when paths diverge at a router, helping to conserve bandwidth.
Another technique, called broadcasting, is often used in network maintenance. IP multicasting and broadcasting are two examples of the same technique. Just think of broadcasting as a type of multicasting where the group members are everyone on a network, not just certain individuals.
IP multicasting uses Class D IP addresses–those with 1110 as their high-order 4 bits–to specify multicast host groups. In Internet “dotted decimal” notation, host group addresses range from 184.108.40.206 to 220.127.116.11. To send an IP multicast datagram, the sender specifies an appropriate destination address, which represents a host group. Multicast datagrams are then sent via normal IP send operations, which are also used for unicast datagrams.
Although the sending side is quite simple, the receiving side of IP multicasting is more complex. To receive datagrams, an application on users’ workstations requests membership in the multicast host group that’s associated with a particular multicast.
This membership request is transmitted to the user’s LAN router using Internet Group Membership Protocol and, if necessary, is sent on to intermediate routers between the sender and the receiver.
Once this step is completed, the receiving workstation’s network interface starts “listening” for the data-link-layer address that’s associated with the new multicast group address. Routers on the WAN deliver the requested incoming multicast datagrams to the LAN router, which then maps the host group address to its associated data-link-layer address and builds the message using this address.
The receiving link’s network interface card and network driver, listening for this address, pass the multicast address to the TCP/IP protocol stack, which makes the data available to the user’s application.
A need for new routing protocols
Commercial support of IP multicasting is increasing, but there are significant issues to resolve. Mbone, the experimental virtual network overlaid on the Internet for multicasting, has already exhibited the scalability problems that can occur as the multicast network grows. Not only do the participating routers have to deal with the dynamic topological changes common to networks, but they also must deal with the dynamics of host groups as members join and leave.
New routing protocols are being developed and are seeing limited deployment, but more are needed to help ISPs set policies for passing multicast traffic among themselves. Protocols such as Protocol Independent Multicast, Multicast Border Gateway Protocol and Hierarchical DVMRP (Distance Vector Multicast Routing Protocol) are likely to see increasing use, supplanting or at least complementing the original multicast routing protocols, DVMRP and Multicast Open Shortest Path First.
The first implementations of IP multicasting depended on the traditional best-effort delivery method of IP and User Datagram Protocol, but that cannot guarantee reliable delivery of multicast traffic. A variety of protocols (more than 15 at last count) have been proposed for reliable multicast delivery, but no single reliable multicast protocol is yet capable of handling the wide variety of group distributions, the feedback required by the sender, or the various types of applications that use multicast.
Finally, QOS (quality of service) for multicast traffic is an important issue, especially considering the importance of multicasting for distributing multimedia and real-time data on the Internet. Many types of multimedia have special timing and delay requirements that have to be guaranteed by the network if the delivered data is to be useful.
Setting QOS via a protocol like Resource Reservation Protocol can be difficult enough for a session between a server and a single client; problems can increase geometrically when trying to do the same for a multicast session.
Despite the issues that must still be resolved, it’s possible to deploy IP multicasting for business purposes, particularly on intranets and carefully designed extranets. Companies such as Toys R Us and General Motors Corp. are using IP multicasting to distribute software updates and inventory reports nationwide, in some cases cutting transfer times by a factor of 100 or more–for example, from 6 hours, 15 minutes down to 4 minutes.
BankBoston pushes financial data to its traders using multicasting, and Smith Barney Inc. is setting up to transmit live video feeds using multicasting.
Much of the software needed to run IP multicasting is already part of many networks. Most new routers support IP multicasting; routers updated in the past few years might already have built-in multicasting support and need only to be reconfigured to enable the service.
Most workstations also support the necessary protocols in their TCP/IP stacks. Available application software covers the gamut from videoconferencing to push, bulk file transfers and streaming multimedia.
Even if an entire corporate network isn’t multicast-enabled, managers might be able to connect “islands” that support multicasting but are separated by links that do not support it. An approach called tunneling allows managers to encapsulate multicast datagrams in standard unicast datagrams for transmission over nonmulticast-compliant links. This is how Mbone currently operates.
ISPs such as MCI Communications Corp. and BBN Planet Corp. have been experimenting with IP multicasting on a limited basis, and now providers including UUNet Technologies Inc. and @Home Network Inc. have started offering multicast services to their customers, so businesses don’t necessarily have to build a new network from scratch to take advantage of multicasting. Several satellite companies have also added IP multicasting support to their product lines.