WORKSHOPS

IP Multicasting: Diving Through The Layers

IGMP client support needs to be built into your host TCP/IP stack (it is present in Microsoft's TCP/IP-32, Win95 and Windows NT 3.51+ stacks). While TCP/IP-suite sales representatives may drivel on about how fancy their Gopher browser is, savvy admins preparing for a media-rich collaborative future would do well to ask about IGMP support within the stack. IGMP server support needs to be present in your routers; most routers from major vendors do support IGMP. An interesting dilemma, however, involves switches, which we'll discuss momentarily.

Multicast Routing Choices Just as protocols such as the Routing Information Protocol (RIP), Interior Gateway Routing Protocol (IGRP) and Open Shortest Path First (OSPF) handle the routing of unicast data, multicast-routing protocols handle the efficient routing of multicast traffic to multiple points in the internetwork. There are others, but the three competing protocols are the dominant players in multicast routing: Distanc e Vector Multicast Routing Protocol (DVMRP), Multicast Open Shortest Path First (MOSPF) and Protocol-Independent Multicast (PIM).

Multicast-aware routers use these protocols to take the group membership information learned from an IGMP communications to dynamically build multipoint route trees, which map paths from a sender to all receivers. Support for at least one of these protocols is required in your campus routers. Most vendors support one or two. Each protocol has its relative strengths and weaknesses.

DVMRP has been around the longest. When a router receives a multicast packet, DVMRP builds a distribution tree by flooding the packet out to all interfaces except for the one that received the incoming packet. This results in the packet reaching all subnets in the internetwork. Subsequently, routers that have no need to receive a particular multicast group (no hosts on their subnets have requested the group via IGMP) can send a "prune" message back upstream to cut off traffic where it is not requir ed. Determining which routers are located upstream is handled via a distance-vector protocol based on hop counts, similar to RIP, and DVMRP shares several of RIP's shortcomings (see "Should RIP Finally Rest in Peace?" ).

If you choose to route with DVMRP, make certain that your router's implementation supports DVMRP prune messages; earlier implementations of DVMRP, such as those found in Cisco's Internetworking Operating System (IOS) router software prior to version 11, did not support this crucial element of the protocol. Tunneling DVMRP into unicast IP packets sent over the Internet is the basis for the popular MBone, the multicast backbone on the global Internet. The MBone broadcasts audio and video from events of nationwide interest, such as space shuttle transmission s. (Additional information on MBone can be found on the Web at www.mbone.com.)

MOSPF is a multicast-aware extension to the popular unicast OSPF routing protocol, and requires that OSPF also be used. PIM is an IETF draft, and is exceptional because it has two distinct and simultaneously compatible modes of operation: dense and sparse. Dense-mode PIM works well when the volume of multicast traffic is high and there are few senders and many receivers (such as a video server rebroadcast). Operation of dense-mode PIM strongly resembles DVMRP.

Sparse-mode PIM is ideal when many intermittent, separate multicast groups are being transmitted to a relatively small number of subnets (such as the case in many shared-whiteboard scenarios), and/or multicast groups are separated by WANs. In these scenarios, the flood-and-prune methods of DVMRP and dense-mode PIM waste bandwidth. Instead, sparse-mode PIM defines a centralized rendezvous point, which links senders and receivers. Once a link is established, the rendezvous point leaves the picture and PIM optimizes the route to go directly from sender to receiver, minimizing any unneeded hops.

The Multicast Routing Achilles' Heel? Layer 2 switches have gai ned immense popularity as a cost-effective solution for increasing bandwidth, and a switched environment (such as private Ethernet) is best for many desktop video applications. But how do these switches perform in a multicast scenario? We tested a few video servers for "Live! From Your Network," in our October 15 issue and, after some investigative work, we discovered that the answer is disappointing.

Most switches, especially the low-cost per port switches, are strictly Layer 2 devices that look solely at MAC addresses. They ignore IGMP messages and have no idea which multicast groups the hosts on their ports want to receive. They play it safe and flood multicast traffic out of all ports, effectively turning your multicast traffic into broadcast traffic and defeating the traffic- partitioning behavior that enticed you to buy the switch in the first place.

Careful virtual LAN planning can help somewhat, but only in very static, atypical scenarios. Some low-cost switches support Simple Network Management Protocol (SNMP) messages that dynamically alter the MAC lookup tables. Thus, theoretically a host aware of the topology could send SNMP messages to the switch to ensure traffic is not flooded. But, unlike this author who salivates at any excuse to rip out a C++ compiler and write some network-layer custom solutions, most IS shops would correctly appraise this potential solution as completely infeasible.

There are only two possible solutions today to get multicasting and switching to coexist efficiently. One is to purchase higher-end switches that perform some Layer 3 decoding and therefore listen to IGMP traffic. For instance, the low-cost 3Com LinkSwitch does not listen to IGMP and, therefore, blindly floods multicast traffic out all ports in the same VLAN. But the more expensive 3Com LANplex switch supports IGMP, and with it multicast traffic dynamically is switched only out of the ports with hosts that want it.

The other possible solution is to use a vendor that has implemented some kind of proprietary middleware to deal with the problem. For example, several configurations of lower-end Cisco switches do not listen to IGMP either. But if you have a Cisco router somewhere on your network, the IGMP messages will make it to the router. The Cisco router will be aware of the Cisco switch (through use of the Cisco Discovery Protocol), and the router will send messages to the switch using the proprietary Cisco Group Management Protocol (CGMP) to tell the relatively dumb switch in strictly MAC-address terms onto which ports various multicast group traffic should be forwarded. The result is nearly the same as if the switch were doing its own IGMP decoding.

Many organizations are purchasing switches in huge quantities, often in preparation for upcoming bandwidth-hungry mixed-media applicat ions. But in addition to a switch's speed and cost per port, take into consideration how the switch handles multicasting and IGMP, or your network's capacity for multicast-based multimedia co uld be severely limited.

Todd Tannenbaum can be reached at ttannenbaum@nwc.com.