If you've had the misfortune of having large numbers of your Internet-connected users discover the PointCast Network, you've already barked your nose against the real-world disadvantage of "push" technologies. It takes only a dozen users to bury a 56Kb line. A couple of hundred subscribers will flood a T-1. The problem with most push applications, including PointCast, is their unicast nature. It's the same problem that guarantees video-on-demand over the Internet will remain a pipe dream for the forseeable future. Each subscriber must make a separate IP connection to the provider's host and each subscriber's session creates a separate data stream, even though the content of that stream may exactly duplicate another subscriber's session on the same subnet. Enter IP Multicast IP multicast, first proposed by Steve Deering in 1989 in RFC 1112, employs a one-to-many architecture, as opposed to the one-to-one approach used by the PointCast Network. Unlike IP broadcast, which sends an identical data stream to all hosts on a network, a host which wishes to receive an IP multicast session sends an IGMP (Internet Group Management Protocol) request to join a session, and is temporarily assigned the same Class D IP address shared by all other subscribers to that session (Class D IP addresses are described in RFC 1700, "Assigned Numbers"). Thus, only those hosts that request the session actually receive it, and all subscribers to a given session receive a single, shared data stream. The amount of bandwidth saved increases as the number of subscribers grows. By default, IP multicast uses UDP (User Datagram Protocol), rather than TCP (Transmission Control Protocol), as its transport, because TCP is exclusively a unicast architecture. However, researchers are working on finalized versions of native multicast transport protocols, such as RTP (Real-time Transport Protocol) and RSTP (Real-time Streaming Transport Protocol), which incorporate the data integrity and packet sequencing functions absent from UDP. Of course, the client's NIC, IP stack and application software must all support IP multicasting. In an internetworked environment, a Designated Router close to the source of the multicast session creates a Spanning Tree of all multicast-capable routers which serve one or more subscribing hosts. This further conserves network bandwidth by eliminating multiple pathways to subscribing subnets, eliminating redundant data streams. Within a campus, the Designated Router may periodically flood the tree with IGMP packets to determine which routers currently have hosts subscribed to the session. Routers which no longer serve any subscribers are "pruned" from the tree, further reducing bandwidth usage. Pruning mechanisms for wide-area applications (particularly over the Internet) are still under development. IP multicasts can be routed through non-multicast-capable routers via IP tunneling. Since most ISPs don't currently support native multicasting, this is the technique most commonly used to route traffic from the Mbone, the 5-year-old Multicast Backbone which acts as the proof-of-concept for IP multicasting on the Internet. So What? Although Mbone multicasts, such as space shuttle missions and Rolling Stones concerts, get all the press, multicast is being deployed to solve a number of real-world corporate and organizational problems. For instance, both Intel and Microsoft employ campus-wide multicasts for executive briefings and product rollouts. Microsoft's custom multicast client includes scheduling and channel selection functions that permit its employees to subscribe in advance to product announcements, analyst briefings and the ubiquitous addresses from Chairman Bill. Over 5000 Microsoft employees also have the choice of subscribing to MSNBC, BBC and assorted local radio stations. Meanwhile, Toys R Us is using a custom IP multicast solution to distribute software updates. The multicast solution takes approximately 4 minutes to update 250 clients nationwide, replacing an older, unicast, VSAT-based system which required 6 hours to accomplish the same task. Likewise, Boeing Corporation is planning on implementing multicast to the desktop to solve the problem of rolling out productivity software updates to hundreds of thousands of desktops overnight. Future Applications Lawrence Berkeley National Laboratory's Van Jacobson, one of the guiding lights behind the Mbone, has been working on a Web browser which would be natively multicast-enabled. He sees it as extending the capabilities of today's search engines to permit a user to multicast a query for a particular file. The first server to respond to the request would forestall any other server from answering and would automatically set up an ftp or http session with the requesting client, allowing a single request to efficiently reach myriad potential respondents. The IP Multicasting Intiative (http://www.ipmulticast.com/) is an industry consortium of developers and implementers working on this exciting technology. They offer a number of white papers on related subjects. (Copyright© 1997 by Thom Stark--all rights reserved)
|