1. Controlling Campus Device Access
Chapter 9
Chapter 10
Controlling Campus Device Access
Multicast Overview
Purpose: This module describes the concepts of multicast traffic and operations.
Timing: The total amount of time to complete this chapter:
Lesson—2 hours 30 minutes
Laboratory Exercises —30 minutes
Note: This section has written exercises at the end.
Contents: This section includes the following topics:
Objectives
Multicast Overview
Addressing in a Multicast Environment
Coordinating Multicast Operations
Routing Multicast Traffic
Written Exercise
Summary
Review Topics
Transition: Following are the list of performance objectives that describe what students will be able to do at the end of the course.
© 1999, Cisco Systems, Inc.
10-1

2. Objectives
Upon completion of this chapter, you will be able to perform the following tasks:
Match the correct transmission method to the appropriate definition
Reconcile a set of IP multicast addresses to Ethernet addresses
Describe the functional differences between IGMPv1 and IGMPv2
Describe the setup procedure in which routers and switches facilitate multicast traffic
Identify the appropriate multicast routing protocol for a given network requirement
Purpose: This graphic states the chapter objectives.
Emphasize: Read or state each objective so each student has a clear understanding of the chapter objectives.
At the end of this chapter, the students will be able to:
Given a list of transmission characteristics, match the correct transmission method to appropriate definition.
Given a list of multicast IP addresses, correctly reconcile them to Ethernet addresses.
Given a set of multicast operations, place each step in the correct order of occurrence.
Given a set of network requirements, select the appropriate multicast routing protocol.
Given a list of multicast routing protocols, identify the correct multicast forwarding technique used for each one.
Transition: The following is a definition of a unicast traffic.

3. Multicast Overview In this chapter, we discuss the following topics:
Addressing in a multicast environment
Managing multicast traffic in a campus network
Routing multicast traffic
Multicast routing protocols
Purpose: This graphic lists the chapter topics.
Emphasize: Read or state each topic so students have a clear understanding of them.
Transition: The following begins a discussion of different transmission types.

4. Multicast Overview In this section, we discuss the following topics:
Unicast Traffic
Broadcast Traffic
Multicast Traffic
IP Multicast Characteristics
Addressing in a Multicast Environment
Managing Multicast Traffic in a Campus Network
Routing Multicast Traffic
Multicast Routing Protocols
Purpose: This graphic states the section topics.
Emphasize: Read or state each topic so each student has a clear understanding of the what is covered in this section.
Transition: The following begins the discussion on the different transmission types.

5. Unicast Traffic
Video Server
Purpose: This graphic defines unicast traffic and lists the issues concerning this method of transmission.
Emphasize:
With a unicast design, an application sends one copy of each packet to every client unicast address.
Unicast transmission requires a large amount of bandwidth as the same information has to be carried multiple time, even on shared links.
A large number of clients can impact the scalability of the network.
Two areas of unicast traffic that are of concern to network managers are as follows:
Number of user connections
Amount of replicated unicast transmissions
Transition: The following is a discussion on how the number of user connections can overload the network links.
Receiver
Not A
Unicast applications send one copy of each packet to every client unicast address

6. Unicast Traffic (cont.)
1.5 Mb x 3 = 4.5 Mb
Video Server
1.5 Mb x 2 = 3 Mb
1.5 Mb x 1 = 1.5 Mb
1.5 Mb x 1 = 1.5 Mb
Purpose: This graphic shows the impact of unicast multimedia traffic from the perspective of replicated traffic.
Emphasize:
A server in a unicast environment must send a separate video stream for each client requesting access to the application.
Use the example to illustrate how the number of clients in a unicast environment can quickly consume bandwidth.
Transition: The following is a discussion on how the amount of replicated traffic can overload the network router and switches.
1.5 Mb x 1 = 1.5 Mb
1.5 Mb x 1 = 1.5 Mb
Receiver
Not A

7. Unicast Traffic (cont.)
1.5 Mb x 100 = 150 Mb
Video Server
1.5 Mb x 100 = 150 Mb
1.5 Mb x 100 = 150 Mb
Purpose: This graphic shows the impact of unicast multimedia traffic from the perspective of replicated traffic.
Emphasize:
Replicated unicast transmissions consumes bandwidth within the network. The path between server and client must take into account the number of router and switch hops that occur between the two points.
Use the example to illustrate how the number of clients in a unicast environment can overload the intermediate devices by causing those devices to replicate the required number of packets.
Transition: The following is a discussion of how broadcast transmission handles multimedia traffic.
1.5 Mb x 100 = 150 Mb
. . .
Receiver 1
Receiver 100

8. Broadcast Traffic
1.5 Mb
Video Server
I don’t want to receive this video stream, but
my CPU still needs to process that 1.5 MB
of data!
1.5 Mb
1.5 Mb
Purpose: This graphic shows the effects of multimedia traffic in a broadcast environment.
Emphasize:
In a broadcast design, an application sends only one copy of each packet using a broadcast address.
Broadcast multimedia is dispersed throughout the network just like normal broadcast traffic.
This method of transmission is easier to implement than unicast applications, but can have serious effects on the network. Allowing the broadcast to propagate throughout the network is a significant burden on both the network and the hosts connected to the network.
Even if an end station is not using a multimedia application, the device still processes the broadcast traffic.
Routers can be configured to stop broadcasts at the LAN boundary, but this technique limits the receivers according to physical location.
Transition: The following introduces the concept of multicast transmission.
1.5 Mb
1.5 Mb
1.5 Mb
1.5 Mb
Receiver
Not A
Hosts not using a multimedia application must still process the broadcast traffic

9. Multicast Traffic
1.5 Mb
Video Server
1.5 Mb
1.5 Mb
Purpose: This graphic shows the concept of multicast transmission.
Emphasize:
A multicast server sends out a single data stream to multiple clients using a special broadcast address.
Client devices decide whether or not to listen to the multicast address.
The advantages of multicasting are as follows:
Enhanced efficiency—Available network bandwidth is utilized more efficiently since multiple streams of data are replaced with a single transmission
Optimized performance—Fewer copies of data require forwarding and processing
Distributed applications—Multipoint applications will not be possible as demand and usage grows because unicast transmission will not scale
Use the example to illustrate how multicasting saves bandwidth and controls network traffic by forcing the network to replicate packets only when necessary.
Transition: The following describes the characteristics of multicast transmission.
1.5 Mb
1.5 Mb
1.5 Mb
Receiver
Not A
A multicast server sends out a single data stream to multiple clients using a special broadcast address

10. IP Multicast Characteristics
Transmits to a host group
Delivers with “best effort” reliability
Supports dynamic membership
Supports diverse numbers and locations
Supports membership in more than one group
Supports multiple streams host
Purpose: This graphic lists the characteristics of multicast transmission.
Emphasize:
Internet Protocol (IP) multicast is the transmission of an IP data frame to a host group that is defined by a single IP address.
IP multicasting is an extension to the standard IP network-level protocol and is described in RFC 1112, Host Extensions for IP Multicasting.
IP multicasting has the following characteristics.
Transmits IP datagrams to a host group identified by a single IP destination address. A host group is dynamic and can contain zero or more host devices at any given time.
Delivers a multicast packets to all members of the destination host group with the same “best-efforts” reliability as regular unicast IP datagrams.
Supports dynamic membership of a host group
Supports all host groups regardless of the location or number of members
Supports the membership of a single host in one or more multicast groups
Upholds multiple data streams at the application level for a single group address
Supports a single group address for multiple applications on a host

11. IP Multicast Characteristic (text cont.)
The multicast server does not know the unicast network address of any particular recipient of the transmission. All recipients share the same multicast network address.
Multicast traffic is handled at the transport layer using the User Datagram Protocol (UDP). Unlike the Transmission Control Protocol (TCP), UDP adds no reliability, flow control, or error recovery functions to IP. Because of the simplicity of UDP, data packet headers contain fewer bytes and consume less network overhead than TCP.
Transition: The following is the signpost for the next section.

12. Multicast Overview In this section, we discuss the following topics:
Addressing in a Multicast Environment
IP Multicasting Address Structure
Mapping MAC addresses to IP Multicast Addresses
Managing Multicast Traffic in a Campus Network
Routing Multicast Traffic
Multicast Routing Protocols
Purpose: This graphic states the section topics.
Emphasize: Read or state each topic so each student has a clear understanding of what is covered in this section.
Transition: The following begins the discussion of how multicast addressing is structured.

13. Multicast IP Address Structure
28 bits
Class D 1 1 1
Multicast Group ID
A Class D address consists of 1110 as the higher order bits in the first octet, followed by a 28-bit group address.
Class D addresses range from through The high-order bits in the first octet identify this 224-base address.
Purpose: This graphic shows how a multicast address is structured.
Emphasize:
The only difference between a multicast IP packet and a unicast IP packet is the presence of a group address in the destination address field of the IP header. The IP multicast datagram contains a specific combination of the destination Media Access Control (MAC) address and a destination IP address.
IP multicast uses Class D addresses. The last 28 bits of the Class D address are unstructured.These 28 bits of the IP address identify the multicast group ID.
Multicast addresses are denoted in decimal numbers in the range of through
Multicast addresses may be dynamically or statically allocated. Dynamic multicast addresses are requested on an as-needed basis.
Statically allocated addresses are reserved for specific protocols that require well-known addresses. Refer to the table in the Student Guide for some of the well-known Class D addresses.
Refer to the document, Internet Multicast Addresses, at ftp://ftp.isi.edu/in-notes/iana/assignments or for the complete list of well-known addresses.
Transition: The following is a discussion on mapping IP multicast addresses to Ethernet addresses.

14. Mapping IP Multicast to Ethernet Addresses7 8 15 16 23 24 31
Class D IP Address
1110
224
Not
Low-Order 23 Bits of Multi-cast
Used
Group ID Copied to Ethernet Address 01 00 5E
Purpose: This graphic shows mapping IP multicast to Ethernet addresses.
Emphasize:
The mapping between a Class D IP address and an IEEE-802 MAC-layer multicast address is obtained by placing the low-order 23 bits of the Class D address into the low-order 23 bits of the Internet Assigned Numbers Authority (IANA) reserved MAC-layer multicast address block.
Ethernet addresses corresponding to IP multicasting are in the range 01:00:5e:00:00:00 through 01:00:5e:7f:ff:ff. The prefix e identifies the frame as multicast; the next bit is always 0, leaving only 23 bits for the multicast address.
The remaining 5 high-order bits are ignored, resulting in 32 different multicast groups being mapped to the same Ethernet address.
This procedure removes the need for an explicit protocol for multicast address resolution on LANs. All LAN stations know this simple transformation, and can easily send any IP multicast over any IEEE-802-based LAN.
Transition: The following is an example of mapping an IP address to an Ethernet address.
48-Bit Ethernet Address

15. Mapping Multicast to Ethernet Addresses: Example 1
Multicast Address:
224 - 10 - 8 - 5
Ethernet Address:
Purpose: This graphic shows an example of mapping an IP multicast address to an Ethernet address.
Emphasize:
This graphic illustrates how the multicast group address , or EA-8A expressed in hex, is mapped into an IEEE-802 multicast address.
Note that the high-order nine bits of the IP address are not mapped into the MAC-layer multicast address.
In the example, the mapping places the low-order 23 bits of the IP multicast group ID into the low order 23 bits of the IEEE-802 multicast address.
Because the upper five bits or the IP Class D address are not used, the mapping may correlate multiple IP groups into the same IEEE-802 address. Therefore, there is a 32-to-1 ratio of IP class D addresses to valid MAC-layer multicast addresses.
The Class D address (E0-0A-08-05) in this example, and the Class D address (E1-8A-08-05) in the following example, map to the same IEEE-802 MAC-layer multicast address ( E-0A-08-05).
Transition: The following is another example of IP multicasting to Ethernet address mapping. 01 - 00 - 5E - 0A - 08 - 05

16. Mapping Multicast to Ethernet Addresses: Example 2
Multicast Address:
224 - 10 - 8 - 5
Ethernet Address:
Purpose: This graphic shows another example of IP multicast to Ethernet address mapping.
Emphasize:
Work through the second example with the students. Point out how the two IP addresses map to the same Ethernet address.
In practice, there is a small chance of collisions should multiple groups happen to pick Class D addresses that map to the same MAC-layer multicast address.
Usually, higher-layer protocols will let hosts interpret which packets are for the application. The chances of two different groups picking the same class D address and the same set of UDP ports are extremely unlikely.
Refer to “draft-ietf-mboned-intro-multicast-03.txt: Introduction to IP Multicast Routing” for more information on mapping IP multicast addresses to Ethernet addresses.
Transition: The following is the signpost for the next section. 01 - 00 - 5E - 0A - 08 - 05

17. Multicast Overview In this section, we discuss the following topics:
Addressing in a Multicast Environment
Managing Multicast Traffic in a Campus Network
Subscribing and Maintaining Groups
IGMPv1
IGMPv2
Handling Multicast Traffic in the Switch
Routing Multicast Traffic
Multicast Routing Protocols
Purpose: This graphic states the section topics.
Emphasize: Read or state each objective so each student has a clear understanding of the module objectives.
Transition: The following is a a discussion on managing multicast traffic in a campus network.

18. Facilitating Multimedia Traffic
Coordinate multicast operations of network devices
Establish a path between between source and destination
Forward multicast traffic through the network
Source
Purpose: This graphic lists the issues that arise when multicast packets pass through routers.
Emphasize:
When multicasting is extended beyond a single physical network, the routers must implement a multicast routing protocol that permits the construction of multicast delivery trees and supports multicast packet forwarding.
In addition, each router needs to implement a group membership protocol that allows the router to learn about the existence of group members on directly attached subnetworks.
IP multicast traffic for a particular source/destination group pair is transmitted from the source to the host group via a spanning tree. This spanning tree connects all the hosts in the group.
Different IP multicast routing protocols use different techniques to construct these multicast spanning trees.
Transition: The following is a discussion on how a host obtains group membership.
Destination

19. Group Membership
Are there any members for Group XYZ?
I’m not a member so I won’t respond.
Host D
Host A
Host B
Host C
Purpose: This graphic shows the process that takes place when a host wants to receive multicast traffic.
Emphasize:
The Internet Group Management Protocol (IGMP) runs between hosts and the immediately-neighboring multicast routers. The protocol allows a host to inform the local router that the host wants to receive transmissions addressed to a specific multicast group.
The host sends an IGMP join message to the designated multicast router. The destination MAC address maps to the Class D address of group being joined, rather than the MAC address of the router. The body of the IGMP datagram also includes the Class D group address.
When a host wants joins a group, the host immediately transmits an IGMP report message for the group. This action reduces the “join latency” for the first host to join a given group on a particular subnet. “Join latency” is measured from the time when the host sends the first IGMP report message until the transmission of the first packet for that group onto the subnet for that host. If the group is already active on that subnet, the join latency is zero.
Transition: The following begins the discussion of IGMPv1.
I’m a member so I will respond.
I’m a member so I will respond.
I’m a member so I will respond.
Multicast uses query and report messages to establish and maintain group membership

20. IGMPv1—Packet Format Version Code Version = 1 Type:4 7 15 23 31
Ver
Type
Unused
Checksum
Group Address
Version Code Version = 1
Type:
1 = Host Membership Query
2 = Host Membership Report
Group Address:
Multicast Group Address
Purpose: This graphic introduces the IGMPv1 packet structure.
Emphasize:
The Version field is the IGMP version and should be “0x1” in IGMPv1. This field has been merged with the Type field in IGMPv2 and eliminated. The Type field contains IGMP message type. 0x1 = Host membership query 0x2 = Host membership report This field has been expanded into an 8-bit field in IGMPv2. The Group field is the multicast group address being specified for reports.
Transition: The following begins the discussion of IGMPv1.

21. IGMPv1—Joining a Group
Report H1 H2 H3
Purpose: This graphic introduces asynchronous joins using IGMPv1.
Emphasize:
Members joining a group do not have to wait for a query to join; they send in an unsolicited report indicating their interest. This reduces join latency for the end system joining if no other members are present.
Join latency is measured from the time an end station’s first IGMP report is sent until the transmission of the first packet for that group onto that host’s subnetwork. If the group is already active on this LAN, the join latency is approximately zero.
If the LAN segment is not on this distribution tree, and the group is currently active elsewhere on the network, then the join latency is how much time it takes to attach this LAN—along with any necessary intermediate upstream links and their intervening routers—to this group’s distribution tree.
Transition: The following continues the discussion of IGMPv1.
IGMPv1
Joining member sends report to immediately upon joining

22. IGMPv1—General QueriesH1 H2 H3
General Query to
Purpose: This graphic introduces general queries using IGMPv1.
Emphasize:
General queries go to the all-hosts ( ) multicast address. One member from each group on the segment will respond with a report. General queries are sent out periodically based on the setting of the ip igmp query-interval command. The default setting is 60 seconds.
There is no formal IGMP query router election process within IGMPv1 itself. Instead, the election process is left up to the multicast routing protocol, and different protocols use different mechanisms. This often results in multiple queriers on a single multiaccess network.
Transition: The following continues the discussion of IGMPv1.
IGMPv1
Multicast Router
The router periodically sends general queries to to determine memberships

23. IGMPv1—Maintaining a Group H1 H2 X H3
Report
Suppressed #2 #3
Query to #1
Purpose: This graphic shows how a group is maintained using IGMPv1.
Emphasize:
The router multicasts periodic IGMPv1 membership queries to the all-hosts ( ) group address. Only one member per group responds with a report to a query. This is to save bandwidth on the subnet network and processing by the hosts. This is process is called response suppression.
The countdown timers are each initialized to a random count within a given time range.
In IGMPv1, this was a fixed range of 10 seconds. Therefore the countdown timers were randomly set to some value between 0 and 10 seconds.
When a countdown timer reaches zero, the host sends a membership report for the group associated with the countdown timer to notify the router that the group is still active.
However, if a host receives a membership report before its associated countdown timer reaches zero, it cancels the countdown timer associated with the multicast group, thereby suppressing its own report.
Work through the example.
Transition: The following continues the discussion of IGMPv1.
IGMPv1 #1
Router sends periodic queries #2
One member per group per subnet report #3
Other members suppress reports

24. IGMPv1—Leaving a Group Router sends periodic queriesH1 H2 H3
Query to
Purpose: This graphic shows how a end station leaves a group using IGMPv1.
Emphasize:
No special leave mechanism was defined in Version 1 of IGMP. Instead, IGMPv1 hosts leave a group passively or quietly at any time without any notification to the router.
This is not a problem if there are multiple members present because the multicast flow still must be delivered to the segment. However, when the member leaving is the last member, there will be a period when the router continues to forward the multicast traffic onto the segment needlessly since there are no members left.
It was up to the IGMP query router to timeout the group after several query intervals pass without a response for a group. This is inefficient, especially if the number of groups and/or the traffic in these groups is high.
Transition: The following begins the discussion of IGMPv2.
IGMPv1
Router sends periodic queries
Hosts silently leave group
Router continues sending periodic queries
No reports for group received by router
Group times out

25. IGMPv2—Packet Format Multiple message types Max. Resp. Time7 15 31
Type
Max. Resp. Time
Checksum
Group Address
Multiple message types
Max. Resp. Time
Max. time before sending a responding
report in 1/10 secs (default = 10 secs)
Group Address:
Multicast Group Address
( for General Queries)
Purpose: This graphic shows the IGMPv2 packet format.
Emphasize:
In IGMPv2, the old 4-bit Version field was merged with the old 4-bit Type field to create a new 8-bit Type field. By assigning IGMPv2 type codes 0x11 and 0x12 as the membership query (V1 and V2) and the V1 membership report respectively, backwards compatibility of IGMP v1 and v2 packet formats was maintained.
The Max Response field is a new field which allows the querying router to specify exactly what the query interval response time is for this query. The value (in one-tenth of a second) is used by the IGMPv2 hosts as the upper bound when randomly choosing the value of their response timers this helps to control the burstiness of the responses during the query-response interval.
The Group Address field is identical to the IGMPv1 version of this field with the exception that it is set to for general queries.
Transition: The following continues the discussion of IGMPv2.

26. IGMPv2—Joining a Group H3
Report H1 H2
Purpose: This graphic shows how an end station joins a multicast group using IGMPv2.
Emphasize: Members joining a group do not have to wait for a query to join; they send in an unsolicited report indicating their interest. This reduces join latency for the end system joining if no other members are present.
Transition: The following continues the discussion of IGMPv2.
RTR141
Joining member sends report to immediately upon joining (same as IGMPv1)

27. IGMPv2—Joining a Group (cont.) H2 H3 H1 E0
Purpose: This graphic shows the router database after H2 has joined the multicast group.
Emphasize:
Point out that group is active on Ethernet 0.
Point out that this database has been active on this interface for 6 days and 17 hours.
Point out that this database for expires (and will be deleted) in 2 minutes and 31 seconds if an IGMP Host Membership Report for this group is not heard in that time.
Point out the last host to report membership was (H2).
Transition: The following continues the discussion of IGMPv2.
RTR141
RTR141>show ip igmp group
IGMP Connected Group Membership
Group Address Interface Uptime Expires Last Reporter
Ethernet d17h :02:

28. IGMPv2—Querier Election H1 H2 H3
Query
Query
IGMP
Non-Querier
Purpose: This graphic shows the querier election process in IGMPv2.
Emphasize:
In IGMPv1 there was no formal IGMP querying router election process within IGMPv1 itself—it was left up to the multicast routing protocol, and different protocols used different mechanisms. This would often result in multiple queriers on a single multiaccess network.
With the definition of IGMPv2, a formal querying router election process was specified within the IGMPv2 protocol itself.
In IGMPv2, each router on a multiaccess network will initially assume it is the querier and begin sending queries. Each router will see the queries from the other IGMPv2 routers and will examine the IP address of these queries. All IGMPv2 routers will then defer to the router with the lowest IP address.
In other words, the IGMPv2 router with the lowest IP address will become the querying router.
Finally, if the currently elected query router fails to issue a query within a specified time limit, a timer in the other IGMPv2 routers will time out and cause them to reinitiate the query election process.
IGMP Querier
IGMPv2
Intially all routers send out a query
Router with lowest IP address “elected” querier
Other routers become non-queriers

29. Querier Election (Text Only)
IGMPv2 also added the concept of Group Specific Queries. This is accomplished by sending the IGMPv2 Membership Query to the group’s multicast address, as opposed to sending to the all-hosts ( ) multicast address as is done for IGMPv2 General Queries.
Membership queries are sent every 60 seconds (default).
Transition: The following continues the discussion of IGMPv2.

30. IGMPv2—Querier Election
RTR141>show ip igmp interface e0
Ethernet0 is up, line protocol is up
Internet address is , subnet mask is
IGMP is enabled on interface
Current IGMP version is 2
CGMP is disabled on interface
IGMP query interval is 60 seconds
IGMP querier timeout is 120 seconds
IGMP max query response time is 10 seconds
Inbound IGMP access group is not set
Multicast routing is enabled on interface
Multicast TTL threshold is 0
Multicast designated router (DR) is (this system)
IGMP querying router is (this system)
Multicast groups joined:
Purpose: This graphic shows how to locate the multicast group querier.
Emphasize:
Use the show ip igmp interface command to determine which router is the IGMPv2 Querier on the multiaccess network.
Point out that the designated router is a different function and is listed separately in the display above.
Transition: The following continues the discussion of IGMPv2.
Locating the designated querier router

31. IGMPv2—Maintaining a Group H2 H3
Report H1 X
Suppressed
Query
Purpose: This graphic shows how to maintain a group using IGMPv2.
Emphasize:
The router multicasts periodic IGMPv1 Membership Queries to the all-hosts ( ) group address.
Only one member per group responds with a report to a query. This saves bandwidth on the subnet network and processing by the hosts.
In the example above, H2’s time expired first, so it responded with its Membership Report. H3 cancelled its timer associated with the group; thereby suppressing its reports.
Transition: The following continues the discussion of IGMPv2.
IGMPv2
Router sends periodic queries
One member per group per subnet report
Other members suppress reports

32. IGMPv2—Leaving a Group IGMP state in RTR141 before leave 172.16.41.1 H2 H1 H3
RTR141
Purpose: This graphic shows the database of the router before any end station leaves a group.
Emphasize: Point out that the last report came from H2.
Transition: The following continues the discussion of IGMPv2.
RTR141>sh ip igmp group
IGMP Connected Group Membership
Group Address Interface Uptime Expires Last Reporter
Ethernet d17h :02:
IGMP state in RTR141 before leave

33. IGMPv2—Leaving a Group (cont.) H2 H2 H1 H3
Leave to
Report to #1 #3
Group Specific
Query to
RTR141
Purpose: This graphic shows how to maintain a group using IGMPv2.
Emphasize:
In IGMPv1, hosts leave passively—they do not explicitly say they are leaving, they just stop reporting. However, IGMPv2 has explicit leave group messages.
When the IGMPv2 query router receives a leave message, it responds by sending a group specific query for the associated group to see if there are still other hosts wishing to receive traffic for the group. This process helps to reduce overall leave latency.
When CGMP is in use, the IGMPv2 leave message mechanism also helps the router better manage the CGMP state in the switch. This also improves the leave latency for the specific host at Layer 2. #2 #1
H2 leaves group; sends leave message #2
Router sends group-specific query #3
A remaining member host sends report;
group remains active

34. Leaving a Group (Text Only)
Note: Due to the wording of the current IGMPv2 draft specification, hosts may chose to NOT send leave messages if they are not the last host to leave the group. This can adversely affect CGMP performance.
Example :
H1 has already left this example.
#1—H2 leaves.
#2—Router sends group-specific query to see if any other group members are present.
#3—H3 hasn’t left yet so it responds with a report message.
Router keeps sending multicast for since there is > 1 member present.
Transition: The following continues the discussion of IGMPv2.

35. IGMPv2—Leaving a Group (cont.) H1 H2 H3
RTR141
Purpose: This graphic shows the database of the router after H2 leaves a group.
Emphasize: Point out that the last report came from H3.
Transition: The following continues the discussion of IGMPv2.
RTR141>sh ip igmp group
IGMP Connected Group Membership
Group Address Interface Uptime Expires Last Reporter
Ethernet d17h :01:
IGMP state in RTR141 after H2 leaves

36. IGMPv2—Leaving a Group (Cont.) H3 H1 H2 H3
Leave to #1
Group-specific
Query to
RTR141
Purpose: This graphic indicates that H3 now leaves the group.
Emphasize: Point out that the process repeats itself.
However, the router receives no host membership reports. Therefore, the query times out and the router removes group from that interface.
Transition: The following continues the discussion of IGMPv2. #2 #1
Last host leaves group; sends Leave message #2
Router sends group-specific query;
no report is received, group times out

37. IGMPv2—Leaving a Group (cont.) H1 H2 H3
RTR141
Purpose: This graphic shows the database now that all members have left the group.
Emphasize: Point out that there are no entries in the IGMP database on that interface of the router.
Transition: The following is the signpost for the next section.
RTR141>sh ip igmp group
IGMP Connected Group Membership
Group Address Interface Uptime Expires Last Reporter
IGMP state in RTR141 after H3 leaves

38. Multicast Overview In this section, we discuss the following topics:
Addressing in a Multicast Environment
Managing Multicast Traffic in a Campus Network Routing
GCMP
Routing Multicast Traffic
Multicast Routing Protocols
Purpose: This graphic states the section topics.
Emphasize: Read or state each objective so each student has a clear understanding what is covered in this section.
Transition: The following starts a discussion on CGMP.

39. Layer 2 Multicast Video Server Receiver Receiver Receiver Not A
1.5 Mb
Video Server
I don’t want to receive this video stream, but
my CPU still needs to process that 1.5 MB
of data!
1.5 Mb
1.5 Mb
Purpose: This graphic shows the problem that occurs when multicast traffic traverses Layer 2 devices.
Emphasize:
Because, IP multicast traffic maps to a corresponding Layer 2 multicast address, multicast traffic is delivered to all ports of a Layer 2 switch.
In this example, a video client wants to watch a 1.5-Mbps IP multicast-based video feed sent from a corporate video server. The video client sends an IGMP join message to the video server. The next-hop router for the client logs the IGMP join message. IP multicast traffic is transmitted downstream to the video client. The switch detects the incoming traffic and examines the destination MAC address to determine where the traffic should be forwarded. Because the destination MAC address is a multicast address and there are no entries in the switching table for where the traffic should go, the 1.5-Mbit video feed is simply sent to all ports.
Layer 2 switches also need some degree of multicast awareness to avoid flooding multicasts to all switch ports.
Transition: The following is a description of CGMP.
1.5 Mb
1.5 Mb
1.5 Mb
1.5 Mb
Receiver
Receiver
Receiver
Not A
Receiver

40. CGMP CGMP is a Cisco-developed protocol
would like to
join multicast
group XYZ.
IGMP Join Request
Purpose: This graphic shows how IGMP and CGMP interact.
Emphasize:
CGMP provides that dynamic configuration, forwarding multicast traffic to only those ports which have IP multicast clients attached.
CGMP leverages the IGMP signaling command structure of reports and leaves to identify which hosts are members of which groups, and allows the router to download that Layer 3 IP multicast information into the switches.
The initial IGMP join report is sent from the individual host to the all-router multicast address. The join message contains the desired group and the MAC address of the client.
Since some customers may have a mixed router environment and would like to take advantage of the Multicast Switching enhancements of CGMP, Cisco has built into the protocol a proxy agent for non-Cisco routers that may be doing IP multicast routing. In these environments, at least one Cisco router is required.
Transition: The following continues the discussion of CGMP.
0000.0c
CGMP is a Cisco-developed protocol
CGMP allows Catalyst switches to learn about the existence of multicast clients from Cisco routers

41. CGMP (cont.) Device 0000.0c12.3456 wants to join Group 234.10.8.5
I can reach device
0000.0c
out of Port 1. I will
add
to my switch
forwarding table.
I have no
knowledge of
device
0000.0c
CGMP Message
CGMP Message
Purpose: This graphic continues the discussion of CGMP.
Emphasize:
When the router sees an IGMP control packet, the router creates a CGMP packet that contains the request type, the multicast group address, and the actual MAC address of the client.
This packet is sent to a well-known address to which all switches listen. The packet is then interpreted by the switch and an entry is created in the forwarding table.
Transition: The following is a signpost for the next section.
0000.0c

42. Multicast Overview In this section, we discuss the following topics:
Addressing in a Multicast Environment
Managing Multicast Traffic in a Campus Network
Routing Multicast Traffic
Routing Protocols
Distribution Trees
Scope of Delivery
Multicast Routing Protocols
Purpose: This graphic states the section topics.
Emphasize: Read or state each objective so each student has a clear understanding of the module objectives.
Transition: The following starts a discussion of routing in a multicast environment.

43. Unicast Routing Server B 172.45.37.10 Destination Address Source
Network
Purpose: This graphic shows routing in a unicast environment
Emphasize:
Unicast transmission involves transmission from a single source to a single destination. The transmission is directed towards a single physical location that is specified by the host address. This routing procedure is relatively straightforward because of the binding of a single address to a single host.
Unicast routing protocols build a forwarding table, commonly called a routing table. Unicast destinations are entered in the routing table, and are associated with a metric and a next-hop router toward the destination.
Transition: The following continues the discussion of routing in a multicast environment.
Network
Host A

44. Multimedia Stream for Group XYZ
Multicast Routing
Multimedia Stream for Group XYZ e
Network
I don’t have any
clients in group
but
Router B has. A B
Purpose: This graphic shows muticast routing.
Emphasize:
The key difference between unicast forwarding and multicast forwarding is that multicast packets must be forwarded away from their source. If a packet is ever forwarded back toward its source, a forwarding loop could form, possibly leading to a multicast storm.
Transition: The following is an introduction to distribution trees.
Network
Network
Host A
Host B

45. Distribution Trees Packet Duplication at This Point Only I am a
Purpose: This graphic introduces the concept of distribution trees.
Emphasize:
IP multicast traffic for a particular (source, destination group) pair is transmitted from the source to the receivers via a spanning tree that connects all the hosts in the group. Different IP multicast routing protocols use different techniques to construct these multicast spanning trees; once a tree is constructed, all multicast traffic is distributed over it.
A distribution tree has just enough connectivity so that there is only one, loop-free, path between every pair of routers.
Messages are replicated only when the tree branches, minimizing the number of copies of the messages transmitted through the network.
Multicast groups are dynamic, with members joining or leaving a group at any time, so the distribution tree must be dynamically updated. Branches that contain new members must be added. Branches in which no listeners exist must be discarded, or pruned.
I am a
member of
Group XYZ.
I am a
member of
Group XYZ.
I am NOT
member of
Group XYZ.

46. Distribution Trees (Text Only)
There are two basic multicast tree construction techniques: source-specific trees and center-specific trees.
Core, or source-specific, trees require finding a shortest path from the sender to each receiver, resulting in multiple minimal-delay trees for a group.
Center-specific trees, or shared trees, use a distribution center(s) and construct a single multicast tree, resulting in a low overhead method, and sacrificing minimal end-to-end delay.
Transition: The following is a definition of a source tree.
Packet Duplication
at this point only
I am a
member of
Group XYZ.
I am a
member of
Group XYZ.
I am NOT
member of
Group XYZ.

47. Source Distribution Tree
Server 1
Group ABC A B C D E F G
Purpose: This graphic defines a source tree.
Emphasize:
Source-specific trees require finding a shortest path from the sender to each receiver.
In this example, the shortest path between Server 1 and Host 1 and Host 2 is through routers A, C, and E, respectively.
Transition: The following continues the discussion of the source tree.
Host 1
Group ABC
Host 2
Group ABC
Host 3
Group ABC
Source-specific trees use the shortest path from the sender to each receiver

48. Source Distribution Tree (cont.)
Server 1
Group ABC A B C D E F G
Purpose: This graphic completes the discussion of source trees.
Emphasize:
Source-based trees are constructed using a technique called Reverse Path Forwarding (RPF). If a packet arrives on a link that the local router believes to be on the shortest path back toward the source of the packet, then the router forwards the packet on all interfaces except the incoming interface. If the packet does not arrive on the interface that is on the shortest path back toward the source, then the packet is discarded.
In this example, Routers E and F receive multicast packets from Router A on what both Routers E and F considered to be the shortest path back toward the source. However, Router E will discard multicast packets from Router F because that link is not the shortest path back to the source for Router E.
Transition: The following is a discussion of shared trees.
Host 1
Group ABC
Host 2
Group ABC
If the link between the local router and the neighboring router is not the shortest path, the packet is not forwarded on that link

49. Shared Distribution Tree
Source 1
Source 2 A B C D E F G
Purpose: This graphic introduces the concept of shared trees.
Emphasize:
Center-specific trees, or shared trees, use a distribution center(s) and construct a single multicast tree, resulting in a low overhead method, but sacrificing minimal end-to-end delay.
A shared-distribution tree is the path derived from a shared point through which sources and receivers must send or receive multicast data.
In this example, regardless of the location or number of receivers, senders register with the shared root (Router C) and always send a single copy of multicast data through the shared root to registered receivers. Also, regardless of the location and number of sources, group members always receive forwarded multicast data from the shared root (Router C).
A shared tree may involve a single router, or a set of routers, which comprises the core of a multicast delivery tree. Shared-tree algorithms make efficient use of router resources because this technique only requires a router to maintain state information for each group, not each (source, group) pair.
Similar to other multicast forwarding algorithms, shared-tree algorithms do not require that the source of a multicast packet be a member of a destination group in order to send to a group.
Multicast traffic for each group is sent and received over the same delivery tree, regardless of the source

50. Shared Distribution Tree (Text Cont.)
Shared trees do not maintain a path for each (source, group) pair, which improves the scalability of applications with many active senders since the number of source stations is no longer a scaling issue.
Shared-tree algorithms conserve network bandwidth since they do not require that multicast packets be periodically flooded across all multicast routers in the internetwork onto every leaf subnet. This can offer significant bandwidth savings, especially across low-bandwidth WAN links, and when receivers sparsely populate the domain of operation.
Finally, since receivers are required to explicitly join the shared delivery tree, data only flows over those links that lead to active receivers.
However, shared trees may result in traffic concentration and bottlenecks near core routers since traffic from all sources traverses the same set of links as it approaches the core.
A single, shared delivery tree may create suboptimal routes, resulting in increased delay, which may be a critical issue for some multimedia applications.
Transition: The following begins the discussion of scope of delivery.

51. Acme Manufacturing, Inc.
Scope of Delivery
Acme Manufacturing, Inc.
Human Resources
Personnel
Payroll
Engineering
Purpose: This graphic introduces the concept of scope of delivery.
Emphasize:
The scope of multicast transmission can be limited by configuring all interfaces in a router with a metric specifying the cost for the given port and a Time To Live (TTL) threshold.
Multicast-enabled routers have a TTL threshold assigned to each interface. Packets with a TTL greater than the interface threshold are forwarded. Packets with a TTL equal to or less than the interface threshold are discarded. The packet TTL is compared with the interface threshold first. The router then decrements the packet TTL upon sending the packet out the interface .
TTL-based scoping is not always sufficient for all applications. Conflicts arise when trying to simultaneously enforce limits on topology, geography, and bandwidth. TTL-based scoping cannot handle overlapping regions, which is a necessary characteristic of administrative regions. Administrative scoping was defined as a way to create boundaries based on multicast address.
Refer to “draft-ietf-mboned-intro-multicast-02.txt” for information of TTL scoping.
Refer to RFC 2365 for information on administratively scoped IP multicast.
Transition: The following is an example of TTL scoping.
TTL Threshold = 15
TTL Threshold = 31
TTL Threshold = 127
Assigning a TTL threshold to each interface limits the scope of multicast transmission

52. Time To Live Threshold E1: (TTL Threshold = 16)
Multicast Packet
w/TTL=24 E0 E1
Packet Not
Forwarded!
Purpose: This graphic provides an example on TTL thresholds.
Emphasize:
In this example, the interfaces on the router have been configured with the following TTL thresholds:
E1: TTL Threshold = 16
E2: TTL Threshold = 0 (none)
E3: TTL Threshold = 64
An incoming multicast packet for Group XYZ is received on interface E0 with a TTL of 24. The outgoing interface list for Group XYZ contains interfaces E1, E0 and S2. The TTL threshold check is performed on each outgoing interface as follows:
E1: TTL (24) > TTL Threshold (16). FORWARD
E2: TTL (24) > TTL Threshold (0). FORWARD
E3: TTL (24) < TTL Threshold (64). DROP
The TTL is then decremented to 23 by the normal router IP packet processing.
Transition: The following is a signpost for the next section. E3 E2

53. Multicast Overview In this section, we discuss the following topics:
Addressing in a Multicast Environment
Managing Multicast Traffic in a Campus Network
Routing Multicast Traffic
Multicast Routing Protocols
Dense Mode Routing Protocols
Sparse Mode Routing Protocols
Purpose: This graphic states the section topics.
Emphasize: Read or state each objective so each student has a clear understanding of what is covered in this section.
Transition: The following starts a discussion of the dense-mode routing protocols.

54. Dense Mode Routing Protocols
Densely distributed receivers
Plentiful bandwidth
Majority of routers forwarding multicast traffic
Protocols
DVMRP
MOSPF
PIM DM
Purpose: This graphic is an overview of the prominent multicast routing protocols available.
Emphasize:
Currently, there are four multicast routing protocols:
DVMRPv2 (Internet draft)
MOSPF (RFC 1584) “Standards Track”
PIM-DM (Internet draft)
CBT (Internet draft)
PIM-SM (RFC 2117) “Experimental”
These routing protocols fall into one of the following three catagories:
Dense-mode
Sparse-mode
Sparse-dense mode

55. Dense Mode Routing Protocols (Text Only)
Dense-mode protocols consist of the following:
Distance Vector Multicast Routing Protocol (DVMRP)
Multicast Open Shortest Path First (MOSPF)
Protocol Independent Multicast dense mode (PIM DM).
DM protocols assume that almost all routers in the network will need to distribute multicast traffic for each multicast group. The DM protocols are most appropriate in LAN environments with densely clustered receivers and the bandwidth to tolerate flooding.
Transition: The following begins the discussion of the individual routing protocols.

56. Distance Vector Multicast Routing Protocol
This is a
multicast packet
for Group XYZ.
Purpose: This graphic introduces DVMRP.
Emphasize:
DVMRP was first defined in RFC-1075.
The original specification was derived from the Routing Information Protocol (RIP) and employed the Truncated Reverse Path Broadcasting (TRPB) technique. The major difference between RIP and DVMRP is that RIP calculates the next-hop toward a destination, while DVMRP computes the previous-hop back toward a source. DVMRP now uses the Reverse Path Multicasting (RPM) algorithm. Thus, the latest implementations of DVMRP are quite different from the original RFC specification in many regards.
There is an active effort within the IETF Inter-Domain Multicast Routing (IDMR) working group to specify DVMRP version 3 in a standard form.
The current DVMRP v3 Internet Draft is “draft-ietf-idmr-dvmrp-v3-04.txt.”
When using RPM, a router receives a packet and floods the packet out of all paths except the one that leads back to the packet source. This technique allows a data stream to reach all LANs.
Transition: The following continues the discussion of multicast routing protocols.
Reverse path flooding floods a packet on all paths except the path leading back to the source.

57. Multicast Open Shortest Path First (MOSPF)
Source 1
Router F has
a new member
for Group XYZ.
Designated
Router A B C D E F G
Purpose: This graphic discusses MOSPF.
Emphasize:
The multicast extensions to OSPF (MOSPF) are defined in RFC 1584.
MOSPF routers maintain a current image of the network topology through the unicast OSPF link-state routing protocol. The multicast extensions to OSPF are built on top of OSPF Version 2 so that a multicast routing capability can be incrementally introduced into an OSPF Version 2 routing domain. Routers running MOSPF will interoperate with non-MOSPF routers when forwarding unicast IP data traffic.
MOSPF routers maintain a local group database which lists directly-attached groups and determines the local router responsibility for delivering multicast datagrams to these groups.
On any given subnetwork, the transmission of IGMP host membership queries is performed solely by the designated router (DR). The DR is responsible for communicating group membership information to all other routers in the OSPF area by flooding group-membership link-state advertisements (LSAs). Similar to router LSAs and network LSAs, group-membership LSAs are only flooded within a single area.
Transition: The following continues the discussion of multicast routing protocols.
I have a new
member for
Group XYZ.
Group XYZ
Group XYZ
Uses OSPF link-state advertisements to construct distribution trees
Trees must be recomputed when a link-state change occurs

58. Protocol Independent Multicast Dense Mode (PIM DM)
This is a
multicast packet
for Group XYZ.
Prune Message
Purpose: This graphic introduces the PIM DM routing protocol.
Emphasize:
PIM receives its name because it is not dependent on the mechanisms provided by any particular unicast routing protocol.
Any implementation supporting PIM requires the presence of a unicast routing protocol to provide routing table information and adapt to topology.
PIM DM refers to a protocol that is designed to operate in an environment where group members are relatively densely packed and bandwidth is plentiful.
PIM DM is deployed in resource-rich environments, such as a campus LAN, where group membership is relatively dense and bandwidth is likely to be readily available.
To find routes back to sources, PIM DM relies on the presence of an existing unicast routing table. PIM DM is independent of the mechanisms of any specific unicast routing protocol.
Unlike DVMRP, which calculates a set of child interfaces for each (source, group) pair, PIM DM simply forwards multicast traffic on all downstream interfaces until explicit prune messages are received.
I have no
members for
Group XYZ.
Protocol-independent means the protocol is not dependent on any unicast routing protocol

59. PIM-DM (Text Cont.)
For those cases where group members suddenly appear on a pruned branch of the delivery tree, PIM DM employs graft messages to reattach the previously pruned branch to the delivery tree. If a router that sent a prune message for a (source, group) pair discovers new group members on a leaf network, the router sends a graft message to the previous-hop router for this source.
When an upstream router receives a graft message, the upstream router cancels out the previously received prune message. Graft messages cascade hop-by-hop back toward the source until they reach the nearest “live” branch point on the delivery tree. In this way, previously-pruned branches are quickly restored to a given delivery tree.
PIM DM is the routing protocol used in this course.
For more information regarding PIM DM, refer to Internet Draft “draft-ietf-idmr-pim-dm-06.txt.”
Transition: The following is an introduction to sparse-mode routing protocols.

60. Sparse-Mode Routing Protocols
Sparsely distributed receivers
Limited bandwidth
Add branches as a result of explicit joins
Protocols
CBT
PIM SM
Purpose: This graphic introduces sparse-mode routing protocols.
Emphasize:
The most recent additions to the set of multicast routing protocols are called sparse-mode protocols.
Sparse-mode routing protocols are more suited to scaling over large WANs, where bandwidth is scarce and expensive.
These emerging routing protocols include the following:
Core-Based Trees (CBT)
Protocol Independent Multicast-sparse mode (PIM SM)
While these routing protocols are designed to operate efficiently over a wide-area network where bandwidth is scarce and group members may be quite sparsely distributed, this is not to imply that these protocols are only suitable for small groups.
Sparse does not mean small; rather this term is meant to convey that the groups are widely dispersed, and thus it is wasteful to flood data periodically across the entire network.
Transition: The following is an introduction to core-based trees.

61. Core-Based Tree
Source 1
Core
Router B A
Source 2
Join
Message C D E
I have a member
who wants to join
Group XYZ.
I am already a
branch of that tree.
I will acknowledge
the join message.
Purpose: This graphic covers of core-based trees.
Emphasize:
The CBT protocol constructs a single tree that is shared by all members of the group. Multicast traffic for the entire group is sent and received over the same tree, regardless of the source.
A CBT shared tree has a core router that is used to construct the tree. Routers join the tree by sending a join message to the core. When the core receives a join request, it returns an acknowledgment over the reverse path, thus forming a branch of the tree.
Join messages need not travel all the way to the core before being acknowledged. If a join message encounters a router on the tree before the message reaches the core, that router terminates the join message and acknowledges it. The router that sent the join is then connected to the shared tree.
For more information regarding core-based trees, refer to RFC 2201: Core-Based Trees (CBT) Multicast Routing Architecture.
Transition: The following continues the discussion on multicast routing protocols.
Join
Message
CBT protocol constructs a single tree shared by all members of the group
A CBT shared tree has a core router that is used to construct the tree

62. Protocol Independent Multicast Sparse Mode (PIM SM)
I want to
start sending
multicast packets
to Group XYZ
I want to
start receiving
multicast packets
to Group XYZ
Optimized
Path A
Initial
Path
Rendezvous
Point D B
Purpose: This graphic begins the discussion of PIM SM.
Emphasize:
PIM sparse mode (PIM SM) was developed to provide a multicast routing protocol that provides efficient communication between members of sparsely distributed groups, such as those groups common in wide-area internetworks. PIM SM was developed on the premise that several hosts wanting to participate in a multicast conference do not justify flooding the entire internetwork periodically with the multicast traffic for a particular group.
PIM SM differs from existing dense-mode protocols in two key ways:
PIM SM evolved from the Core-Based Trees (CBT) approach in that PIM SM employs the concept of a core, or rendezvous point (RP).
Routers with adjacent or downstream members are required to explicitly join a sparse-mode delivery tree by transmitting join messages. If a router does not join the predefined delivery tree, the router will not receive multicast traffic addressed to the group.
PIM SM works by designating a router as a rendezvous point. When a sender needs to transmit data, the sender first registers with the rendezvous point.
Initial
Path C
Initial
Path

63. PIM-SM (Text Only)
A receiver must first join the group by registering with the rendezvous point.
As the data stream begins to flow from sender to rendezvous point to receiver, the routers along the way optimize the path automatically to remove any unnecessary hops.
However, routers continue sending to the rendezvous point, in case any new senders or receivers become active.
For more information on PIM SM, consult the following documentation:
draft-ietf-mboned-intro-multicast-02.txt
RFC 2362: Protocol Independent Multicast Sparse Mode (PIM SM) Protocol Specification
Transition: The following is the exercise for this chapter.

64. Following is the written exercise for this chapter
Purpose: This cues the instructor to begin the written exercise.
Emphasize: Give the students enough time to complete the exercises for this chapter.
Transition: The following is the summary for this chapter.

65. Summary
Multicast is the most efficient method for data transmission to multiple client.
IP Multicast employs special addressing.
IGMP allows clients to join and leave multicast groups.
CGMP allows switches to handle multicast traffic.
Special routing protocols are used to route multicast traffic through the network.
Multicast routing protocols are divided into two categories.
Purpose: This page summarize what was discussed in this chapter.
Transition: The following are the review questions.

66. Review
Discuss the three types of transmission methods and the effect each one has on network bandwidth.
Explain how routers and switches handle the impact of multicast addressing techniques.
Discuss different multicast routing protocols and identify which ones are most effective in a campus network.
Purpose: This page provides several topics for discussion.
Emphasize:
Points of Discussion for Review Question 1:
With a unicast design, an application sends one copy of each packet to every client unicast address. Replicated unicast transmissions consume bandwidth within the network.
In a broadcast design, an application sends only one copy of each packet using a broadcast address. End stations not using a multimedia application must process the broadcast traffic.
Multicasting sends one copy of each packet to a special address. Multicasting saves bandwidth and controls network traffic by forcing the network to replicate packets only when necessary. By eliminating traffic redundancy, multicasting reduces network and host processing.

67. Review (text cont.) Points of Discussion for Review Question 2:
IP multicast uses Class D addresses.
This multicast group ID is a single address typically written as decimal numbers in the range through The high-order bits in the first octet identify this 224-base address.
The last 28 bits of a Class D address identify the multicast group ID.
The lower 23 bits of the Class D address are mapped into a block of Ethernet addresses.
Because IP multicast groups are 28 bits long, the mapping cannot be one-to-one. Only the 23 least-significant bits of the IP multicast group are placed in the frame. The remaining 5 high-order bits are ignored, resulting in 32 different multicast groups being mapped to the same Ethernet address.
There is a small chance of collisions should multiple groups happen to pick Class D addresses that map to the same MAC-layer multicast address.
Usually, higher-layer protocols will let hosts interpret which packets are for the application. The chances of two different groups picking the same class D address and the same set of UDP ports is extremely unlikely.
Points of Discussion for Review Question 3:
Routing protocols fall into two categories: dense and sparse.
Dense-mode multicast routing protocols are designed to work well in environments that have plentiful bandwidth and where receivers are densely distributed, such as campus networks.
Sparse-mode routing protocols are more suited to scaling over large WANs, where bandwidth is scarce and expensive
DVMRP is widely used on the Internet multicast backbone.
MOSPF is best suited for environments that have relatively few (source, group) pairs active at any given time. This protocol will work less well in environments that have many active sources, or environments that have unstable links. Although this is a good protocol for campus LANs, Cisco does not support MOSPF.
PIM DM works best when there are numerous members belonging to each multimedia group and resources, such as bandwidth, are plentiful. This is a good routing protocol for a campus LAN.

68. Review (text cont.)
Sparse-mode PIM is optimized for environments where there are many multipoint data streams. Sparse multicast is most useful when:
There are few receivers in a group
Senders and receivers are separated by WAN links
The type of traffic is intermittent
The CBT protocol is designed to operate efficiently over a wide area network where bandwidth is scarce and group members may be sparsely distributed.
Transition: This concludes the overview of multicast concepts. Following are the chapters in how to enable and configure multicast technologies on both the router and the switch.