
In addition, support for IP multicast is built into your current and future operating systems. Microsoft has taken the necessary steps that will enable Windows NT 4.0, Windows95, Windows98 as well as future NT products to fully participate in IP-multicast networks.
For the technically curious, that involves changing the TCP/IP stack to use IGMP, which single-handedly enables efficient multicast networks. Furthermore, future Microsoft operating systems, such as Windows98 and Windows NT 5.0, will include support for Microsoft NetShow, a handy tool for playing back streaming multicast video and audio. Thus, the software to take advantage of IP multicast is finally at the desktop, where it needs to be.
The tools to serve IP-multicast traffic are not grossly misproportioned, either. As we found, a standard Pentium Pro server running Windows NT is capable of encoding several high-quality audio streams or a medium-quality video stream without additional hardware.
Uses of IP Multicast You may be asking why your organization should be in the business of providing audio and video to the desktop; after all, you're not in the business of entertaining your employees. But IP multicast can bring you so much more. Remember your last business unit briefing? Perhaps you herded 800 employees into an auditorium or rental facility. Tearing users away from their office environment is highly disruptive and scheduling time and location costs money. Transporting remote-office workers may be even more expensive.
But what if you could selectively deliver a presentation to your entire sales force via a desktop presentation? This presentation would include a camera-eye view of the narrator, a half-screen PowerPoint presentation and a complete audio track. Does it sound too good to be true? It's available now.
Another valuable use of IP multicast involves training. Whether briefing employees on regular Monday morning news events or instructing them on proper service and support procedures, an IP-multicast infrastructure will enable you to streamline the processes. And if end users can't attend the first showing, a later one can be delivered to their desktop on demand using conventional unicast technology.
An IP-multicast infrastructure also promotes the use of similar technologies. Having a three-on-three meeting among design engineers, marketing and product managers across the globe is an expensive proposition. Bring them together in a virtual conference room using your highly tuned IP-multicast infrastructure and significant cost savings can be realized.
While an IP-multicast infrastructure will speed unicast applications, it won't solve bandwidth problems entirely. Unicast traffic--such as video on demand and real audio--still eats up a significant amount of bandwidth. Here, big pipes and fast servers are the only solution to better on-demand service.
The Test Results At Microsoft's NT Performance Lab in Redmond, Wash., we set up 72 IP-multicast clients and a single NetShow Multicast server. The workstations and server were connected via a Cisco Catalyst 5500 switch populated with 242 ports of 10/100 Fast Ethernet and a route switch module. Microsoft Windows98 Beta 3 was used as a client running on 100-MHz client machines from Hewlett-Packard Co. No special audio or video hardware was used--there was only the on-board resources the computer came configured with.
After configuring the NetShow server to stream using IP multicast, we started up all 72 clients. Four unique streaming videos were sent on two IP subnets. Half of the traffic crossed IP subnet boundaries via the Catalyst's Route Switch Module, while the other half of the traffic remained local. All 72 clients displayed the video perfectly. Furthermore, load on the switch was less than 10 percent and load on the router module was less than 5 percent.
The real truth of the test shows when you connect a traffic analyzer to the network. In our tests, we used streaming media with data rates of 200 Kbps to 1,800 Kbps. Today's compression technology enables you to display high-quality full-screen video at rates that won't affect network performance. The highest quality stream--1,800 Kbps--still consumed only 120 packets per second of network bandwidth. For Ethernet switches, that's less than 1 percent of the available packet payload and about 20 percent of available bandwidth. On Fast Ethernet switches, the impact is negligible. Even high-speed serial WAN connections are capable of supporting streams of a reasonable magnitude, which is welcome news when it comes to holding conferences over IP multicast.
After testing IP multicast in Microsoft's NT Performance Lab, we toured the Microsoft site, where more than 30,000 nodes are connected and participating in what may be one of the largest IP-multicast networks on the face of the planet. Even with dozens of audio and video channels, Microsoft's routers held steady at under 8 percent utilization. What better proof that IP multicast can scale?
Knowing What to Look For The beauty of IP multicast lies in its dependence on the underlying network hardware. Multicasting is based on a hierarchical tree. IP routers only forward traffic to downstream routers if a host is "listening" to the multicast. Routers only forward IP-multicast streams to switches and hubs with listening clients (see "IP Multicast Routing," on page 132).
In both cases, just a single copy of the data is sent downstream. The brunt of the load is placed on the switches--only a single stream is sent out to the distribution points, cutting down on the forwarding load your routers have to cope with. Because so much responsibility is placed on your edge devices, however, it's important that you watch for IP-multicast features if you plan to deploy this technology at your site.
One important feature to look for is a hardware-based multicast architecture, that is, a switch fabric that can copy packets to destination ports quickly in hardware. At Microsoft's lab, we tested Cisco's Catalyst 5500 using Netcom SmartBits and found that it could forward up to 35 million IP-multicast packets per second, all at under 10 percent load. The Catalyst uses a shared memory architecture, common to many switches now on the market. The shared memory architecture is particularly good for IP multicast because packets can be copied quickly from memory to multiple destinations.
With the capacity for that many packets per second, it's critical to have some control over the IP-multicast traffic in your network. When an IP-multicast stream arrives at a switch, the default behavior is to treat it like a broadcast, sending it to every port on the switch. In a large campus network, that can lead to an excessive amount of network white noise, congesting your network and leading to poor performance.
To solve this problem, vendors have implemented intelligence at the switch level. When a workstation joins a multicast tree, it sends an IGMP message to the nearest router, notifying the router that it wishes to receive multicast traffic. An intelligent switch monitors the wire for IGMP packets and limits multicast traffic to the ports that have requested a multicast stream. This process is called IGMP snooping, and is becoming common in higher-end switches (see "IP Multicasting With and Without IGMP Snooping," at left). Cisco implements a proprietary version, called CGMP, that lets extra data be passed between switches and routers. Cisco also plans to add standard IGMP snooping to its list of supported features.
Live presentations, state-of-the-corporation addresses, business briefings, CNN at Work and local radio stations are just a few of the things that your network could be carrying. With Windows98 shipping imminently and Windows NT 5.0 just around the corner, the time is right to think about deploying IP multicast. Likewise, as your intranet needs evolve, your infrastructure will move toward Layer 2 and Layer 3 switching, priming your network for IP-multicast applications. 1998 will be the year that IP multicast finally makes its mark, thanks to tight integration from Microsoft and network hardware vendors.
Joel Conover can be reached at jconover@nwc.com.
|