WORKSHOPS

IP Multicasting: Diving Through The Layers

Be prepared for rapid changes over the next six months as several key technologies for ushering in the latest crop of communication applications appear. One of these technologies is IP multicasting.

Although it has been on the scene for some time, support for IP multicasting just now is reaching critical mass. Not too long ago, a multivendor effort, the IP Multicast Initiative, was formed to launch IP multicasting into the mainstream. Membership in the Multicast Initiative reads like a Who's Who in network computing, including all the major infrastructure (Bay Networks, Cabletron Systems, Cisco Systems, Intel Corp. and 3Com Corp.) and operating system vendors (Hewlett-Packard Co., Microsoft Corp., Net-scape Communications Corp., Silicon Graphics, Sun Microsystems and most other Unix vendors), in addition to several others.

In this workshop, we'll bring you up to speed on IP multicasting: We will cover what it is, why you should care and how it works; we'll also tell you the things to look for when purchasing and upgrading network infrastructure equipment and software to ensure that the upcoming crop of multicast-aware software will be able to run optimally over your network.

IP Multicasting: Why Do We Want It? Most frame-based networks, such as Ethernet, can communicate in three modes: unicast, broadcast and multicast. Unicast, the most common, is simply point-to-point communication between two devices on the network, such as a PC and a file server. Unicasts are appropriate for the majority of applications, but they fall short in several collaboration software areas. For example, unicasts would not be appropriate for a corporate training exercise for which an instructor is using a collaborative shared-whiteboard application to send in real-time an instructor-station screen to 35 student PCs.

With unicasts, screen-update information from the instructor's station needs to be transmitted separately to each student PC, resulting in noticeable delays--even on shared media--as each update is sent over the network 35 times. This is clearly a waste of bandwidth, as the information being transmitted to every student station is a duplicate of what was sent to the previous station. It would be far better if the 35 student stations all could "listen" to the instructor station at the same time, and if an update is transmitted just once.

A network broadcast would achieve this. A broadcast allows one station on the network to simultaneously talk to all devices contained in the same broadcast domain, or subnet. But broadcasts have their failings as well. For example, a video server can place a live video feed, perhaps a CNN newscast, onto the campus network so that any desktop user could tune in.

But to let a user join in, the broadcasts must be permitted to cross subnet boundaries. In this scenario, broadcasts would use precious bandwidth on subnets throughout the campus. Furthermore, a broadcast requires all machines and internetworking equipment (such as routers and switches) to receive and utilize CPU cycles to process the packet, even if only a tiny minority of mac hines want to receive the broadcast information in the first place.

IP multicasting is the answer. It is a communication method over TCP/IP by which a single station can transmit to multiple receivers simultaneously, but unlike the "one or everyone" possibilities with unicasts and broadcasts, the transmitting machine can specify a specific group of machines to receive the information. This is accomplished by transmitting to an IP multicast address, which can be conceptualized as a TV channel. Machines interested in receiving the information simply "tune in" to the particular multicast address that has the data stream of interest. IP multicasting, when implemented properly, lets shared data streams be transmitted over the network once and solely to those recipients who want to receive the information. If machines on only two out of 40 subnets receive the CNN feed, bandwidth is not utilized on the remaining 38 subnets.

There are three components that allow IP multicasting to occur: Layer 3-to-Layer 2 tr anslation, dynamic membership control and multicast-aware routing. Each requires cooperation and support from the vendors supplying your operating system or TCP/IP stack, network adapters and infrastructure equipment, particularly routers and switches. Understanding these components will help you make purchasing and upgrade decisions to ready your network for an IP multicast future.

Layer 3-to-Layer 2 Translation All network protocols need a method to translate the IP network address ISO/OSI Layer 3 into a hardware/media address (Layer 2), such as an Ethernet Media Access Control (MAC) address.

Groups of machines representing a multicast group are identified by an IP multicast address. Class "D" IP addresses are reserved for multicast traffic. Class "D" IP addresses are those beginning with "1110" for the first four bits, which means addresses 224.0.0.0 through 239.255.255.255. Each address can be considered a "channel" by which groups of hosts interested in receiving the same content can be identified; perhaps a network administrator would broadcast CNN video on 229.15.15.30, and CNBC video on 229.15.15.31. Various videoconference and/or collaborative session groups also would be identified via their own IP multicast address.

Translation between a given IP multicast address and an Ethernet MAC address is trivial; the IP multicast addresses are directly mapped into an Ethernet MAC address by dropping the low-order 23 bits of the IP address into the low-order 23 bits of the Ethernet multicast address (hex 01-00-5E-00-00-00 for those who are sticklers for details.).

The TCP/IP stacks on your machines must be IP multicast-aware to understand the significance of this special range of IP addresses, and to program your network adapter to properly receive requested multicast addresses. More TCP/IP stacks are multicast-aware, but not all. Windows95 and Windows NT stacks, as well as TCP/IP implementations from several leading Unix vendors, are multicast-aware. Third-party TCP/IP stacks, such as thos e for Microsoft's Windows for Workgroups, may or may not be. Find out if your stack is. In addition, practically all Ethernet adapters can be programmed to listen to a few Ethernet MAC addresses, specifically their own as well as the MAC Ethernet broadcast address.

An Ethernet adapter ideally suited for use in an IP multicast environment would let several additional MAC addresses be programmed in by the TCP/IP stack, enabling the machine to listen in on several multicast groups simultaneously without receiving an entire general range of MAC addresses. This would force the machine's CPU to spend cycles weeding out the undesired packets. In the PC arena, the adapter's hardware may have this capacity, but the implementation could be hindered by poor Network Driver Interface Specification (NDIS) or Open Data-Link Interface (ODI) drivers.

Dynamic Membership Control Part of the appeal of IP multicasting is that the multicast traffic is present only on those subnets where one or more hosts is activel y requesting it. Before transmitting a given multicast stream onto a subnet, a router needs to know if any machines on that subnet want to receive that multicast. Via the Internet Group Management Protocol (IGMP, RFC 1112),machines dynamically inform a multicast-aware router of any multicast sessions in which they want to participate. If no hosts on a given subnet register via IGMP for a multicast session, the traffic transmitted to that multicast address will not be routed onto that particular subnet, thereby preserving bandwidth.