IP-Multicasting Technology Part 2: Switches vs. Routers

1.0 IP-Multicast: Using Switches with IP-Multicast

Previously in our review of IP-Multicast history and technology, we concentrated on OSI Layer-3 devices, i.e. multicast-enabled routers. However, due to the substantial deployment of high-speed Layer-2 Ethernet switches, developers must also be aware of the issues involved with the use of switches in multicasting.

1.1 Making Switches Multicast-Aware: IGMP Snooping, CGMP, and GARP

With the prevalence of Layer-2 Ethernet switches, problems concerning the use of such switches for directing multicast traffic have come to light. Many of these problems have been addressed by a variety of clever techniques, including IGMP Snooping, Cisco's Group Management Protocol (CGMP), and IEEE's Group Address Resolution Protocol (GARP).

One of the primary difficulties encountered in multicasting over Layer-2 switches (or bridges) is that the normal response to multicast traffic is the immediate flooding of the packets to every interface on the switch (other than the interface from which the packet arrived). This response is typical of a switch when either a multicast or broadcast MAC address is identified in the destination field of an Ethernet packet. If, somehow, the switch could determine which interfaces should be used for egress processing, the amount of unwanted multicast traffic could be drastically reduced. Thus, our question becomes: how can a switch determine the appropriate output interfaces for a particular multicast? To do so, the switch must access the type of information that is available within the IGMP protocol (discussed in our previous article). However, with only the Layer-2 header available (MAC addresses and protocol types), the switch cannot differentiate between IGMP traffic (to and from the Designated Router) and normal multicast traffic. The following approaches were developed to resolve this issue.

IGMP Snooping
The first technique for resolving this dilemma is simple to implement but may not scale well, particularly in lower-end switch models. Referred to as "IGMP Snooping", this approach requires that the switch decode the IP header (Layer-3 information) by examining IP "protocol" field in order to separate out IGMP messages from normal multicast traffic. However, without some type of hardware (ASIC) assist, this additional decode process can be quite taxing on a central CPU-based switch. In fact, IGMP snooping may cause such switches to arbitrarily discard a large number of packets during times of multicast peaks. However, with the proper hardware assist, IGMP snooping is a viable solution. IGMP snooping is available on a variety of mid-to-high end switches.

Cisco's Group Management Protocol (CGMP)
The second approach, CGMP, is proprietary to Cisco and involves a router-to-switch multicast-group information exchange protocol. A mid-to-high end Cisco switch (Catalyst) can receive multicast-group join/leave messages from a multicast-enabled Cisco router (6000, 7000, etc.). These join/leave updates are then used by the switching logic to provide better multicast filtering through the switch fabric. CGMP provides such messages as "Add Port to Group", "Delete Port from Group", "Assign Router Port", "De-assign Router Port", "Delete Group", and "Delete All Groups".

Group Address Resolution Protocol (GARP)
A third approach is the IEEE's GARP protocol, whose primary purpose is to maintain VLAN group information. GARP can be extended to also provide (S,G) lists that allow the switch to map multicast groups to egress ports in much the same way that a VLAN is a list of MAC addresses that belong to a specific broadcast domain.

Regardless of which of these three methods is used, the primary CAM table to be updated with the multicast group information (mapped to a multicast MAC address) is called the "Switch Forwarding Table" or SFT.

While all of the above methods have been widely deployed, the most common is CGMP particularly due to the size of the installed base of Cisco multicast-enabled equipment. IGMP Snooping is the next most popular approach. IEEE GARP is a distant third and has much work left to be done in order to provide a viable solution.

1.2 Dealing with IP-Multicast Traffic Overflow

The increasing acceptance of IP-Multicast as a viable protocol suite with a whole spectrum of applications within the enterprise intranet has raised bandwidth concerns. In particular, corporate network managers possess the very real concern that multicast popularity might lead to a dramatic downturn in available bandwidth on a given network segment. This bandwidth concern would be especially problematic in the switched fabric due to the switch's inherent "flooding" behavior with multicast packet flows. An early technique presented to control this flood of multicast over switched networks was that of "multicast metering" or "rate-limiting". Metering would control the data flows so that a given level of multicast packets (packets/sec or percentage of theoretical maximum bandwidth) was never exceeded for a given network segment, i.e. the switch would throw away packets to satisfy the specified rate.

This approach proved to be a poor solution since many standard unicast protocols use some multicasting to get their messages around (e.g. OSPF HELLO routing updates and Spanning Tree Bridge Protocol Data Units (BPDUs)). The loss of these crucial control messages could easily meltdown a network during topology changes! Most network managers now consider this form of indiscriminant rate-limiting to generally be a bad idea.

However, such multicast metering might be useful if the packet could be classified as vital (BPDU, OSPF HELLO, etc.) vs. non-critical (audio multicast frames) with some sort of priority tagging scheme. Just such a scheme is discussed in the IEEE 802.1p and IEEE 802.1Q standards as well as other, vendor-proprietary, solutions. If the switch could handle this classification in a relatively low cycle-demanding manner, then multicast overflow could be dealt with efficiently.

2.0 IP-Multicast: To Switch or Route?

The initial requirements for dealing with multicast traffic within a switch/router device seems to suggest that a VLAN switching algorithm could be used to differentiate the traffic. After all, a multicast packet riding on the Ethernet frame format uses a MAC multicast address. However, the mapping between IP multicast addresses and a given MAC address is 32-to-1. Thus, a strictly Layer-2 interface lookup algorithm would not be able to differentiate between an entire block of 32 multicast addresses that may be in use (i.e. that may have a multicast source/group assigned to them). For example, the octet 224.1.1.1 has the exact same MAC multicast ("01:00:5E:01:01:01") as 225.1.1.1 and 226.1.1.1. Remember that the compression takes place at bits 4 through 8 of the 32-bit IP multicast address.

Apparently, multicast IP addresses (groups) that do not collide when translated into their equivalent multicast MAC addresses should thus be used. This address selection is precisely what the industry accomplishes when multicast addresses are assigned to multicast sources. This "solves" our first obstacle to switching (instead of routing) a multicast packet.

Unfortunately, however, whether a given multicast packet is actual user-data (video, audio, data-cast, push, etc.) or just part of the control and management of a multicast protocol is impossible to determine. A case in point is IGMP, which transmits a "Membership Report" packet that uses the multicast group it wishes to join as the packet's IP destination address and, thus, the same MAC address as data that will be later sent on that same group.

Using one of the techniques discussed above (IGMP snooping, CGMP, and GARP), one can build a MFT ("Multicast Forwarding Table") for packet-egress decision logic, i.e. to which interfaces should a multicast packet be forwarded. With this table, multicasters would be able to more closely adhere to the adage "switch when you can, route when you must". As it turns out, this MFT would be essentially equivalent to the SFT ("Switch Forwarding Table") mentioned above.

By using traditional routing techniques for all multicast traffic, the problem is greatly simplified since a variety of IP-Multicast routing protocols exist (four of them discussed in our previous article). These routing protocols will build interface-forwarding tables based on the packet's multicast group (destination IP address) and, possibly, the multicast source. Remember that with the PIM-SM and CBT protocols, the source is typically the RP (a network manager-specified, multicast-enabled router that is usually quite close to the multicast sources), which is a well-known address to the router.

Thus the forwarding of a multicast packet is highly dependent on the source of the interface-forwarding information - via a Layer-2 method such as IGMP Snooping or CGMP, or a Layer-3 method such as DVMRP or PIM. However, a generic MFT can be constructed that uses either the Ethernet MAC Destination Address (48-bit) or the IP Destination Address (32-bit) as its key, depending on a configured option - the Multicast-Router-Flag (MRF). In this way, we use the packet's IP-DA if the MRF is set or the packet's MAC-DA if the MRF is cleared to find our egress interfaces. The MFT would be typically implemented as a hardware CAM as is the case with the VLAN switching tables.

To summarize our options for using multicast-forwarding in the MFT:

Route (Layer-3 decision): Uses the IP-DA for a key to the MFT. The MFT is maintained by the forwarding tables established by DVMRP, PIM-SM or MOSPF. (PIM-DM is a special case that floods the packet to all interfaces, unless an interface has its "prune status" set).

Switch (Layer-2 decision): Uses the MAC-DA for a key to the MFT. The MFT is maintained by the information collected from IGMP Snooping, CGMP router-to-switch protocol, or via the GARP protocol.

The most common setting, of course, is to clear the MRF (=0) and use the switch (Layer-2) lookup to implement fast-switching of IP-Multicast. This setting assumes that some mechanism for mapping of multicast grouping is active (e.g. IGMP Snooping, CGMP, or some future, workable version of GARP). Of course, if no Layer-2 protocol is available, the MRF must be set on (=1) in order to use the available IP-Multicast routing protocols.

Importantly, the TTL (Time To Live) field in the IP header of all IGMP join/leave control packets will always be set to one (1). This setting means that IGMP will not be accidentally transmitted to other egress interfaces, since the packet will be discarded after it is processed since its TTL will be decremented to zero.

Conclusion

As IP multicasting continues to grow in popularity, developers and network managers must be aware of the options available for (and challenges associated with) routed and switched IP multicast packet transmission. In our next and final article on IP multicasting, we will explore timing and sizing the protocols as well as decoding the protocols.