receive the multicast traffic sends a PIM join message toward the root node (rendezvous point). As this join message travels up the tree, the multicast routers along the way forward the requested traffic back down the tree to the destination.

To put it in a simple form, PIM−DM will send the multicast traffic everywhere until it is told not to. PIM−SM will not send any multicast traffic until it is asked to.

Note Cisco routers use PIM−SM. They can receive and forward messages to DVMRP neighbors, but they do not actually implement DVMRP in their networks.

Multicast Open Shortest Path First

Multicast Open Shortest Path First (MOSPF) is an extension of the Open Shortest Path First (OSPFv2) unicast routing protocol. OSPF must be running on the network for MOSPF to work. OSPF is a link−state routing protocol that allows a network to be split into multiple areas. The OSPF link−state database provides the complete map of an area at each router. MOSPF’s extension is a new link−state advertisement (LSA) to distribute multicast group membership throughout the OSPF area. The group membership LSA includes the multicast group address, the router ID, and the interfaces on the router that have members in the multicast group. This information reaches all the MOSPF routers in the area, so each router will have a complete database of all the multicast group members. Each router will then construct a source tree from the link−state information.

MOSPF is a very bandwidth−efficient multicast routing protocol, but it does have a downside: It is very CPU intensive. If the network topology is not stable, the router will have to recalculate the routing tabling. Multicast increases the problem, because each membership change will cause a new computation. In a many−to−many multicast environment, by utilizing the source tree model, a new SPT is created for each source. Because of this, MOSPF is most suitable in a stable environment where the location of sources, number of sources, number of groups, and group membership are under tight control.

Internet Group Management Protocol (IGMP)

Internet Group Management Protocol (IGMP) is used by hosts to request multicast traffic. An individual host sends out an IGMP member report to inform the multicast router that it wants to receive data transmissions. The router maintains a list of multicast group memberships learned from IGMP. The multicast group membership list is built on a per−interface basis and is considered active if one host maintains its membership.

There are currently two versions of IGMP: version 1 (IGMPv1), which is defined in RFC 1112; and version 2 (IGMPv2), which is defined in RFC 2236. Let’s look at the two versions of IGMP and how they differ.

IGMPv1

You may wonder why we’re explaining version 1, when version 2 is the standard. Well, there are PCs that still use IGMPv1. Windows 95 (the OS that never goes away) supports IP multicast utilizing IGMPv1, unless you download an upgrade version of Microsoft’s Winsock dynamic link library (DLL). (Windows 98 and Windows 2000 have native support for IGMPv2.) The same situation applies to the different versions of Unix. Unless all of the computers on your network are running the latest version of an OS or you’ve installed a patch, you’re going to have computers using IGMPv1.

IGMP uses a query and response format. The router sends a host membership query message to the all−hosts multicast address, 244.0.0.1. (If multiple routers are on the network, one will be designated to send the message.) When a host receives the query message, it responds with a membership report to the multicast group of which the host is a member. If more than one host on the subnet belongs to the same multicast group, it will see the membership report and not respond to the membership query. As the router receives the

145

responses, it will build a list of all the multicast groups for that interface. Any other router on the same subnet will also receive the responses and will have the same information.

Note A host does not have to wait for a host membership query to send out a membership report. It could send an unsolicited membership report, a process sometimes mistakenly referred to as sending out an IGMP join to the router.

To minimize the traffic, IGMP utilizes a report suppression mechanism. The host starts a countdown with a random value between zero and the maximum response interval for each multicast group to which it belongs. When the value reaches zero, the host sends a membership report. All members of the same multicast group receive this message and reset their own countdown values. As long as the router receives a membership response, it will not send out a host membership query.

To leave a multicast group, a host simply stops sending membership responses. If no group members send member responses, the router begins its own timer (usually one minute). It will then send a membership query and reset its timer. If the router sends a membership query three times and does not get a reply, it will stop sending the multicast group’s traffic out that interface.

The time interval from when the last host leaves the multicast group until the router stops transmitting traffic can create network problems. Assume that a user is trying to find a channel (multicast group) on a multimedia application. As the user surfs the different channels to locate the one he wants, he will join multiple multicast groups. If he goes through six channels before finding the one he wants, the router will transmit all six multicast groups’ traffic until the timer runs out. This process may not affect the user much, but if the traffic is coming across a WAN link, the unnecessary high−bandwidth multimedia traffic will bog down the link. IGMPv2 was developed with this situation in mind.

IGMPv2

IGMPv2 functions the same as version 1, with the following enhancements:

∙Querier election process—Allows the routers on the local subnet to elect the designated IGMP querier utilizing IGMP rather than using an upper−layer protocol, as in version 1. The router with the lowest IP address is elected and is responsible for sending out the multicast query for that subnet.

∙Maximum response time—Allows the router to set an upper limit for the value the host will use to determine when to send a membership report. This limit enables you to fine−tune your IGMP traffic.

∙Multicast group−specific query message—An enhancement to the original all−host membership

query. Rather that being sent to everyone, a multicast query will be sent only to the specific multicast group.

∙Leave group message—The biggest improvement in IGMPv2. In version 2, a host joins a multicast group the same way as in version 1. However, the process of leaving is completely different. Instead of just keeping quiet, the host sends a leave group message to the all−routers (224.0.0.2) multicast group. When a router receives this message, it sends out a multicast group−specific query. (The router must send this query because it only keeps a list of multicast groups associated with each interface. It doesn’t know if any other multicast group members exist.) When another host on the same subnet receives the query, it responds with a membership report. The router will then maintain that multicast group’s association to that interface. Just as in version 1, other members of the same multicast group will see the reply and not respond to the query. If the host is the last member of the multicast group and no other host responds to the query, the router will wait a last member query interval (default value one second) and send out another group−specific query. If it doesn’t receive any reply to this second query, the router will stop transmitting multicast traffic out that interface. This process results in a much faster response time than in version 1 when a host leaves the multicast group.

Tip By default, Cisco routers utilize version 2. If any host on the subnet does not support version 2, you must change the router to version 1.

146