Managing Multicast in an Internetwork

As a user on the network, you can understand that spam is not something that is managed by a systems administrator, whereas valid mailing lists require maintenance to keep a current list of valid subscribers. The same can be said of multicast. As we said earlier, one of the major differences between broadcast and multicast communication is that broadcast traffic goes to all hosts on a subnet, whereas multicast traffic goes only to the hosts that request it. The distinguishing factor that puts multicast traffic so far ahead of broadcast traffic in utility is the ability to specify which multiple hosts will receive the transmission.

This isn't done magically; routers and switches don't know who and where the recipients are just because it's multicast traffic. As with any application, protocols are needed to make things happen. Multicast works on the basis of host subscription to groups.

Several methods and protocols have been developed and implemented to facilitate multicast functionality within the internetwork:

• Subscribing groups

• Maintaining groups

• Joining groups

• Leaving groups

Each of these protocols and methods is used for specific tasks or to achieve specific results within the multicast environment. More importantly, each device in the network must know its role regarding multicasting; otherwise, you are left with nothing except a broadcast.

We will now look at these protocols and learn just where they fit in and what they are needed for. We begin with the most important, subscription and group maintenance, and then move on to enhancements for multicast deployment and distribution.

Subscribing and Maintaining Groups

For multicast traffic to reach a host, that host must be running an application that sends a request to a multicast-enabled router informing the router that it wishes to receive data belonging to the specified multicast group. If this request were never to take place, the router wouldn't be aware that the host was waiting for data from the specified group.

As an overview: A multicast-enabled router receives all group advertisements and routes. It listens on all interfaces, waiting for a request from a host to forward multicast group traffic. After a host on an interface makes a request to become a member of a group, the interface activates the requested group on itself and only on itself. While the host is a member, multicast data is forwarded to that interface, and any host subscribed to the group receives the data.

That was a simple overview; now let's look at how this is accomplished in more detail. We start by discussing five major host subscription protocols:

• IGMPv1

• IGMPv2

• IGMPv3

• CGMP

• IGMP Snooping

The differences among them will become apparent as we get further into the discussion.

Internet Group Management Protocol Version 1 (IGMPv1)

As the name indicates, Internet Group Management Protocol version 1 (IGMPv1) was the first version of the protocol. It was a result of RFC 1112. The purpose of this protocol is to enable hosts to subscribe to or join specified multicast groups. By subscribing to groups, the hosts are thereby enabled to receive multicast data forwarded from the router.

IGMP has several processes that it executes to manage multicast group subscription and maintenance. We will discuss them in greater detail so you can get an understanding of what happens.

Three processes are employed by version 1 of IGMP:

• Query

• Join

• Leave

These processes are the means by which multicast group membership is maintained. The first two processes are functional processes, whereas the Leave process is more of a time-out than a formal request. Each process is defined in detail next.

Membership Query Process

One important process is the IGMP Query process, which is kindred to a keep-alive procedure. Because the router needs to keep tabs on which multicast groups need to remain active, or be made active or inactive, it sends a Membership Query out each interface. The query is directed to the reserved address of 224.0.0.1, to which all multicast hosts will answer.

After the request is received, the hosts report back with their group subscription information. After a specific group has been reported to the router, subsequent reports for the same group coming from different hosts are suppressed. This is done because only one host on a subnet/ VLAN needs to request membership for the router to activate that group on the interface. Once active on the router interface, any host on that segment wanting to receive data for that specific group will receive it. Figure 8.8 depicts how this process works.

Figure 8.8: IGMPv1 Query routine

You can follow the numbers indicated in the figure. First, the query to 224.0.0.1 is sent, and subsequently, the hosts begin to report back. The first host to respond (#2a) is Host B, requesting data for the multicast group 224.2.127.254. Host D responds next (#3a) with a request for the group 224.2.168.242. The next host to reply is Host A (#4a). However, because the report from Host D was already multicast to the 224.2.168.242 group, Host A heard the report and suppressed its own report to the group.

The protocol is 'smart' enough to understand that after one host has reported, more hosts don't need to report as well. This helps prevent unwanted and unnecessary bandwidth and processor utilization. To accomplish this, when a query is sent, each participating device sets a random countdown timer. The first device whose timer runs out will respond; the others will reset their timers.

Host C (#5a) responds with a different group number, 224.2.155.145. After all the hosts have responded to the query, Router 1 can maintain activity for these groups on interface E0.

Notice that this description applies to interface E0 on Router 1. Simultaneously, a multicast flood to 224.0.0.1 was sent out interface E1 as well. The first host to respond on this segment is Host E (#2b), and it is reporting membership to 224.2.168.242. Notice that this report was not suppressed, even though Host D had already multicast a report to this group, because it occurred on a different interface. The router queries the local All Hosts address 224.0.0.1, which is not forwarded by the router. That is why the same query is sent out all interfaces on the router. Now that Host E has multicast to the group for that segment, none of the other hosts on the E1 segment will report because they are all members of the 224.2.168.242 group.

Join Process

The other processes are joining and leaving multicast groups. Both of these processes are quite simple and straightforward. You understand how interfaces are maintained in an active state through Membership Queries. The query process runs only every 60 seconds. If a host wants to join a multicast group outside the Membership Query interval, it can simply send an unsolicited report to the multicast router stating that it wants to receive data for the specified multicast group. Figure 8.9 depicts how this occurs. This is known as the IGMP Join process.

Figure 8.9: Unsolicited join requests

Leave Process

Withdrawal from a group is not initiated by the host, as one would imagine. The router hosts a timer that is reset every time a response is received from a host on the subnet. The timer runs for three minutes, which is equivalent to three Membership Query cycles (a cycle lasts 60 seconds). If the timer expires and no response is received from the hosts on the interface, the router disables multicast forwarding on that interface. If the router was forwarding for a specific group and doesn't get responses for that group but continues to get responses for other groups, it stops forwarding only for the group that no longer has hosts listening.

Internet Group Management Protocol Version 2 (IGMPv2)

As with any software revision, features are made better. Defined by RFC 2236, Internet Group Management Protocol version 2 (IGMPv2) provides the same functionality as version 1 did, but with a few enhancements:

• The Leave process in version 2 was included to avoid long time-outs that are experienced in version 1.

• There are two Query forms, General and Group-Specific.

• Network traffic is less bursty due to new timing mechanisms.

In this section, these enhancements are discussed.

It is important to be aware of issues when both versions of IGMP are present on the network. Version 2 provides backward compatibility with version 1, but the functionality of version 2 is lost when it's operating with version 1 devices. A version 2 host has to use version 1 frame formats when talking with a version 1 router. The same applies when a version 2 router tries to communicate with a version 1 host; it must use the version 1 format.

General and Group-Specific Query Processes

One enhancement that was made to IGMPv2 processes was the creation of a new query type. The Membership Query, as it was called in IGMPv1, was renamed General Queries, and the new type is Group-Specific Query. The new query type is used to query a specific multicast group (kind of obvious from the name). The overall procedure is the same as it is in IGMPv1.

When multiple IGMPv1 routers existed on the same segment, a multicast routing protocol made the decision as to which of all the multicast routers would perform the Membership Queries. Now, the decision is made by using a feature added to IGMPv2. This feature is known as the Querier Election Process.

The frame for the query was changed to enable a maximum response time that allows the hosts on the segment more time to respond to the query. This reduces the bursty traffic on the network.

IGMPv2 Leave Process

IGMPv2 implemented the capability for hosts to remove themselves from the multicast group immediately (in a matter of seconds) instead of the router having to wait up to three minutes. The process is known as the IGMP Leave process. The two new additions of the Leave and Group-Specific messages work together to enable a host to remove itself from the multicast group immediately without interrupting the state of the interface on the multicast router.

Figure 8.10 depicts how the IGMPv2 Leave process works. First, Host A sends a Leave message to the All multicast routers address (224.0.0.2), expressing the intent to withdraw from the multicast group. Because Router 1 doesn't know how many hosts on the segment belong to group 224.2.155.145, it must send a Group-Specific Query to see whether any hosts remain members of the group. If no responses are received, the router disables multicast forwarding out of the interface for the 224.2.155.145 group. If any hosts respond to the query, the router leaves the interface status quo. In the figure, you can see that Host B responds because it is still participating in the group 224.2.155.145. Hence, the interface is left active for that group.

Figure 8.10: IGMPv2 Leave process

Internet Group Management Protocol Version 3 (IGMPv3)

Multicasting is a rapidly evolving world of multicast traffic flows. No surprise, then, that version 2 of IGMP is not without its own flaws.

Known problems with IGMPv2 (which were not obvious in the past) include the possibility of two multicast applications being 'live' at the same time with the same multicast address, the lack of knowledge about the multicast server source address causing routing tree instability, and the ease with which multicast groups can be subjected to Denial-of-Service attacks (or even simple spamming).

Internet Group Management Protocol Version 3 (IGMPv3) addresses these problems specifically by allowing hosts to specify the list of hosts from whom they want to receive traffic, blocking traffic from other hosts transmitting the same stream, and allowing hosts to block packets that come from sources sending unwanted traffic.

Only two types of message exists in IGMPv3: Membership Query and Membership Report.

Membership Query

The Query message is used to determine if there are any extant members in a particular group. Two types of query exist: Group-Specific Queries and Group-and-Source-Specific Queries.

Group-Specific Queries If a host receives an IGMPv3 Group-Specific Query in its source- specific range, it must respond with a report.

Group-and-Source-Specific Queries An IGMPv3 router will query any source-specific channel that a host has requested to leave with a Group-and-Source-Specific Query. Hosts must respond to any Group-and-Source-Specific Query for which both the group and source match any channel to which they are subscribed.

Membership Report

IGMPv3 receivers signal their membership to a multicast host group in one of two possible modes, Include and Exclude.

Include When operating in Include mode, the receiver announces its membership to a host group and provides a list of IP addresses (referred to as the include list) from which it wants to receive traffic.

Exclude When operating in Exclude mode, the receiver announces membership to a host group and provides a list of IP addresses (referred to as the exclude list) from which it does not want to receive traffic. Obviously, this indicates that the host will only receive traffic from other sources whose IP addresses are not listed in the exclude list.

To receive traffic from all sources, a host transmits an empty exclude list.

Cisco Group Management Protocol (CGMP)

We have discussed IGMPv1, IGMPv2, and IGMPv3, which are open standard protocols for host membership of multicast groups. When running multicast at layer 2, things get a little complicated for the switch. It doesn't know which packets are membership report messages or which are actual multicast group data packets because all of them have the same MAC address. Cisco Group Management Protocol (CGMP) was implemented to fill this void. It runs on both routers and switches.

Real World Scenario-Multicast Design

If the router interface is connected to a hub or a switch that doesn't understand multicasting, when the router forwards the multicast, the stream acts like a broadcast. In other words, every device gets a copy. In IGMPv1, the router would keep forwarding the multicast stream out to the hub, which forwards it to every connected client. Multicast routers work well because they can forward a broadcast from one router to the next, something that doesn't happen with true broadcasts. The problem is that clients on a multicast segment get the stream whether they want it or not.

This type of scenario is fine when the CEO wants to give a speech to every desktop, but what about video that is only for a specific division, department, or business unit? If the packets need to go to five different locations, and after you get past the routers all you have are switches, everyone will receive the multicast stream. This doesn't reduce bandwidth utilization!

So far, corporate multicasting with IGMP, either version, works well at the router level. Too bad most clients aren't connected directly to router ports. Because IGMP is essentially nothing more than intelligent broadcast propagation, Cisco created something that would enable switches to participate as well, CGMP.

The key feature of CGMP is that it uses two MAC addresses:

Group Destination Address (GDA) The GDA is the multicast group address mapped to the MAC multicast address.

Unicast Source Address (USA) The USA is the unicast MAC address of the host. USA enables the host to send multicast membership reports to the multicast router-the multicast router can also be a Route Switch Module (RSM) or Multi-layer Switch Feature Card (MSFC)-and still tell the switch which port needs to receive the multicast data.

In addition to being able to make port assignments on the switch, CGMP also handles the interface assignment on the router. If a switch doesn't have any ports that need to receive multicast data, CGMP informs the router that it doesn't need to forward multicast group data out the router interface.

CGMP uses many of the same processes IGMP uses. The main difference is that CGMP is used between the router and switch. When switches are involved, the IGMP requests must be translated to CGMP and passed on to the switch. These processes include the following:

• CGMP Join process

• Switch host management

• CGMP Leave process

CGMP Join

Hosts do not use CGMP; only the switches and routers that the host connects to use it. When a host sends an IGMP report (membership report) advertising membership of a multicast group, the message is forwarded to the router (that is, an actual multicast router, an RSM, or an MSFC) for processing. The router sees the request and processes it accordingly. The multicast group is set up, and the two MAC addresses are generated. The router then gives the switch the CGMP message. With the CGMP message, the switch can assign the multicast group to the port of the requesting host. You can see the entire process in Figure 8.11.

Figure 8.11: CGMP Join process

Host Management

Host management is performed by the router. The router continues to receive IGMP messages from the host. Then the router converts the message into a CGMP message and forwards it to the switch. The switch then performs the port maintenance as directed by the router. This process is followed for the multiple types of messages that the host can generate. The router forwards three critical pieces of information to the switch in the CGMP message:

• Request type

• MAC address of the requesting host

• Multicast group the request is for

The CGMP Leave process is done in the same manner. The router receives the request and then informs the switch that the multicast group address needs to be removed from the Content Addressable Memory (CAM) table for the host's port.

IGMP Snooping

While CGMP is a Cisco proprietary protocol to enable switches and routers to communicate regarding multicast traffic patterns, IGMP Snooping is referenced in IGMPv3 and does that same thing. Several vendors have created implementations of IGMP Snooping that don't quite play well with each other.

IGMP Snooping doesn't require any sort of translation into a different protocol at the switch. IGMP is used from the client to the router. The switch monitors, or sniffs, the IGMP packets as they pass through and records the MAC addresses and the port that requested to be a part of the process.

Because the switch becomes an integral part of the process of IGMP, the router forwards status messages to the switch and the switch forwards them out the appropriate ports. This is the process of Fast-Leave and is done on both CGMP and IGMP Snooping:

• Client A is listening to a multicast stream and decides to stop listening. The client sends an IGMP Leave message to the switch.

• The switch responds with an IGMP Query to find out whether other clients exist that still want that multicast stream.

• If a client exists out that port, the switch makes no changes.

• If there is no reply out that port but other ports are receiving the stream, the switch does nothing.

• If there is no reply to the Query and there are no other ports participating, the switch forwards the Leave message to the router.

Real World Scenario-Multicast and Spanning Tree

It might seem that CGMP and IGMP Snooping are the way to go. That is true-if you have a very stable network. Remember that STP is used to allow for redundancy but that it disables the redundant links until they are needed. If you have a switched network with redundant connections and a link drops, spanning tree takes over and figures out the next best topology. Unfortunately, the spanning tree process doesn't tell the multicasting process that this is happening. The switch will still forward the multicast message out the port that it was using. This can cause delays and dropped connections. Eventually it settles down, unless the topology changes are always going on.