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 document. 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:
| 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.
Contrast the following pictures.
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.
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 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 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.
For more information about CGMP and IGMP Snooping, see the Cisco Tech Note at http://www.cisco.com/warp/public/473/22.html . See also the Tech Note on Constraining Multicast Traffic with Source and Receivers on the Same VLAN, at http://www.cisco.com/warp/public/473/38.html .
For more information, see the RGMP Tech Note at http://www.cisco.com/warp/public/473/94.html .
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.
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 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.
Dr. Peter J. Welcher (CCIE #1773, CCSI #94014) is a Senior Consultant with Chesapeake NetCraftsmen. NetCraftsmen is a high-end consulting firm and Cisco Premier Partner dedicated to quality consulting and knowledge transfer. NetCraftsmen has nine CCIE's, with expertise including large network high-availability routing/switching and design, VoIP, QoS, MPLS, network management, security, IP multicast, and other areas. See http://www.netcraftsmen.net for more information about NetCraftsmen. Pete's links start at http://www.netcraftsmen.net/welcher . New articles will be posted under the Articles link. Questions, suggestions for articles, etc. can be sent to pjw@netcraftsmen.net .