The Protocols of IP Multicast

Introduction

I’ve been talking about doing some articles about IP Multicast for a while. It looks like time to put up or shut up!

In this article, we’ll examine the various protocols used for IP Multicast, and the roles played by each protocol. Once we’ve understood how the protocols work together to deliver IP Multicast, then in subsequent articles we’ll be able to go into more detail about each of the protocols. I’ve included links to the key IETF working groups at the end of this post. See those links for the relevant RFC’s and drafts.

Lately I’ve been hearing about more and more companies working with multicast. Where can you get yourself some multicast for your network? Well, for one thing, there seems to be a surprisingly large number of Enterprise Cisco customers using the IP/TV product to distribute video over IP multicast, usually for training of new low tech employees (which is where the large numbers are). The sense I get is that people are using it because it just works, with relatively little fuss. You do have to buy the hardware and architect your solution to scale, but the actual video administration can probably be done by a PC technician. (Unsolicited plug!)

By the way, if you’re interested in multicast, we cover the basics of PIM (see below) in the Switching course, BCMSN. Firing off IP/TV at the end of the course is a really nifty way to see results! By the way, there is now an enhanced version of the Cisco multicast course for CCIP certification, MCAST. The course was in part authored by Beau Williamson, author of the Cisco Press book on IP multicast. For more information, see:

Introducing The Players

The following table should make sure that everyone is equally confused. It also introduces the acronyms and names of the protocols we’ll be talking about.

Role	Acronym	Name of Protocol
Client (PC) to Router	IGMP	Internet Group Management Protocol
Router to Switch (Cisco only)	CGMP GMRP (IGMP snooping) RGMP	Cisco Group Management Protocol GARP Multicast Registration Protocol IGMP Snooping Router-Port Group Management Protocol
Router to Router	PIM DVMRP CBT MOSPF	Protocol Independent Multicast Distance Vector Multicast Routing Protocol Core Based Tree Multicast OSPF
Large Scale Router to Router	MBGP MSDP	Multiprotocol BGP Multicast Source Discovery Protocol
Interim Multicast Address Allocation	GLOP	(I don’t think that’s an acronym!)
Multicast Address Allocation	MADCAP	Multicast Address Dynamic Client Allocation Protocol
Multicast Address Allocation	MASC	Multicast Address Set Claim Protocol

See the links below for other protocols in development, like BGMP.

Why Multicast?

The way I think of multicast is that it is like subscribing to a magazine. Admittedly, the magazine is being shared around with others. The routers are the subscription agency, tracking whether any LAN group of readers needs a copy of a particular multicast feed, and where they are. That way, the routers can ensure that a single copy of the multicast feed is transmitted on each link, at least most of the time. This conserves bandwidth. The catch here is that multicast is like watching TV. If there is sharing, you turn on your viewer and watch the same thing as many other people. It’s not like going to rent a video and playing it when you feel like. Unicast is the counterpart of “start to watch it when I want to”.

Contrast the following pictures.

Unicast video/audio transmission

Unicast video audio transmission

The above picture is the state of streaming video or audio in the Internet right now. Everyone gets their own personal copy. Even for content that could potentially be shared, such as Internet radio.

Multicast video/audio transmission

multicast video audio transmission

Another use of multicast is audio/video-conferencing. The users can use multicast to transmit to each other. Or the conference bridge can use multicast to reach all participants. The benefit here is that the conference bridge just sends multicast packets, then the routers deliver them. This is a lot less work than duplicating packets for each client on the conference.

IGMP

IGMP is used by multicast clients (viewers/listeners) to “subscribe” to content. Suppose you select a “channel” or multicast feed with your favorite PC viewer. I know, you didn’t think you had a favorite. But suppose. The PC then notifies the router that it is interested in receiving the multicast in question. IGMP version 1 only sends join notifications (as in, joining the group of viewers). The router periodically queries the receivers, in effect asking “does anyone here still want Channel 2?” (separately, for each channel). That way, if nobody cares anymore, the router can stop duplicating and transmitting copies of the multicast feed, to save bandwidth. Periodic means every 60 seconds by default, but this is configurable.

IGMP version 2 allows a polite application to also notify the router “I’m outta here”, formally known as “leaving the group”. That in turn means the router has a chance to save bandwidth, sooner. It still queries to see if there are any other viewers, since it is not tracking how many subscriptions there are (this would be overly complex and error prone), just whether there is some receiver on each LAN segment.

IGMP version 3 allows the client to specify the sources of multicast traffic, sources that it is interested in, for each multicast group of interest. It also supports Source Specific Multicast (SSM).

By the way, IGMP is not something we generally have to enable on our PC. It should be built into the client/viewer/listener software, and transparent to the end user.

CGMP

Layer 2 switches flood three kinds of packets within VLAN’s: broadcasts, multicasts, and unknown unicasts (unicasts where the location of the destination MAC address is not known). Thus if one PC on a VLAN is tuned into a multicast feed, all the PC’s on the VLAN will see the multicast packets. Suppose the multicast feed is hi-resolution video using a lot of bandwidth. Then the other PC’s in the VLAN are contending with the multicast. If they’re on half duplex ports, they cannot transmit as often. If on full duplex, replies to the packets they send are delayed by the multicast packet flooding. To make things worse, until very recently, Windows drivers were multicast-ready in the simple sense of enabling the processing of MAC multicast addresses, and handing them off by interrupting the PC’s CPU. A typical PC would “see” no multicasts until you turned on your viewer, upon which the NIC card would start passing all multicast packets to the CPU. The problem there is the PC CPU then gets bombarded by multicast packets, both those it wishes to receive and others. This saps the power of the CPU.

CGMP was Cisco’s answer to this. The router already tracks which PC’s need which multicast groups. It also knows the MAC addresses of the PC’s. Using CGMP, it passes the PC MAC address and multicast MAC address back to the switch, and the switch can then locate the port with the PC, and enable only the specified multicast MAC address(es) out the port to the PC. In that way, each PC will only receive the multicasts it asked for. CGMP also does some other messaging, basically the router letting the switch know which port it is connected to, and housekeeping functions such as keepalives.

IGMP Snooping

IGMP Snooping is an ad hoc standard initiated by other vendors and now supported by Cisco. It uses the chip set for the switch port to snoop on IGMP packets. By observing such packets, the switch sees the PC IGMP join or leave and can do the right thing: record the multicast MAC as allowed or blocked on the port. We do have to make sure the switch knows which port(s) router(s) are connected to, or the switch won’t know to forward a copy of any locally sourced multicast to the the router. (We’ll see why this is important later in this series.) This is automated in the Cisco implementation (details: see the following link).

For more information about CGMP and IGMP Snooping, see the Cisco Tech Note. See also the Tech Note on Constraining Multicast Traffic with Source and Receivers on the Same VLAN.

GMRP

GMRP is part of 802.1q, which some of us see as a PC-centric standard driven significantly by 3Com engineers. The idea is for the PC to use a special protocol named GARP (Generic Attribute Registration Protocol) to notify the switch about the multicast groups it wishes to receive. (In general, GARP is how a PC registers membership in a VLAN and other per-PC settings. I don’t want my users doing things like that. Whatever could they have been thinking of?) The question here is: are there NIC card drivers that support this (probably there are by now, 802.1q is a standard), do PC viewer applications have a standard way to tell the NIC card to send the GARP packet (doubt it), and do the applications in fact do so (doubt it). As you can guess, I’m betting GMRP soon becomes the answer to a trivia question, and not much else.

RGMP

RGMP is a relatively new Cisco protocol. Normally, all multicasts are forwarded to the router port. The purpose of RGMP is so the router can tell the switch which multicast groups it wishes to receive. That way, the router doesn’t get hit with many multicasts that are irrelevant to it. One way to use this might be to have multiple routers, each forwarding certain high-volume multicast groups. With RGMP, the chip set in the switch can filter which multicasts go where, instead of using the CPU in the router for this (and overwhelming it, probably).

For more information, see the RGMP Tech Note.

PIM

PIM is Cisco’s protocol for router to router tracking of where multicasts are needed. It comes in two forms, Dense Mode (DM) and Sparse Mode (SM). We’ll look more deeply at each of these modes in later articles.

Dense mode is named that because you have to be dense to run it. (Just kidding!) Dense mode assumes most PC’s want the multicast, so it forwards the multicast feed everywhere, and then routers prune this (cut off the feed) where it is not needed. Dense mode is characterized by flooding every 3 minutes, which is rather anti-social if you have significant volumes of multicast in your network. The polite way to say this: “it doesn’t scale well”. A recent feature known as PIM Dense Mode State Refresh means the pruned state can be maintained, reducing the periodic flooding. This feature is enabled by default as of 12.1(5)T.

Sparse mode works by routers sending Join messages, to start the multicast feed being sent across links. The assumption in Sparse Mode is that relatively few sites or PC’s are viewers, so PIM-SM starts with no flooding of multicast. Very quickly, router-to-router Join messages cause the multicast feed to be sent across links to where it is needed. This scales well. This is the current standard for ISP’s wishing to allow multicast on their part of the Internet.

DVMRP, CBT, MOSPF

These are other protocols for multicast, pre-dating PIM. DVMRP is sort of RIP for multicast, with hop count and robustness challenges. CBT comes from research, scales to very large scale at the price of some possibly delay in reaching the viewer. MOSPF was put forth by the OSPF advocates. It requires OSPF as unicast routing protocol, and furthermore is generally conceded to not scale well. Cisco does implement DVMRP but not CBT and not MOSPF.

MBGP

Multiprotocol BGP can carry routing information about several protocols. Elsewhere, we’ve seen that it can be used for an IPX Internetwork (who cares anymore?), multicast, IPv6, and the VPNv4 information for MPLS VPN’s.

When used for IP multicast, MBGP actually is carrying a separate copy of unicast routes. We’ll see why when we actually go over what it does and how it works, in a later article. The short form of it: multicast routing requires something called an RPF check, which we’ll probably go into in the next article. RPF checking uses the unicast routing table. By giving multicast a special copy of the unicast routing information, MBGP allows us to “steer” which links the PIM Join messages use, which in turn allows us to control which links the multicast traffic traverses. And it does so using all the traditional tools and tricks of BGP, which ISP’s understand and feel comfortable with.

MSDP

PIM-SM uses routers that we designate as “Rendezvous Points” (RP’s). RP’s are the original way a multicast source and receiver get connected with each other in PIM-SM. When a multicast source wishes to transmit multicast, it just starts sending. It is up to the routers to do the right thing with the multicast. In PIM-SM, the right thing is to forward the multicast packets to the RP. (Well, it’s a little more complex, and we’ll go into this when we talk about PIM-SM). The RP is the crucial router that is aware of sources and multicasts in the network. (I’m skipping over the fact that different multicasts can use different RP’s here, to keep this simpler.) Because of this, in PIM-SM we can normally have only one RP.

MSDP is a BGP-like protocol which allows an RP to forward source and multicast group information to other RP’s. This means we can have redundant RP’s, for higher availability of a multicast service. Furthermore, it means different ISP’s can each have their own RP or RP’s, which arguably helps from the policy, control, management, and troubleshooting perspectives.

Links

A list of IETF working groups and links directly related to multicast follow.

Cisco:

The Samples & Tips page off the Support Page is very interesting. It contains links to other documents with multicast configuration samples and tips.

In Conclusion

Hope you’ve enjoyed this taste of multicast. Next: getting thick with PIM Dense Mode!