Client Registration

One of the issues that must be dealt with in multicasting is the discovery of the end stations that will be participating in a multicast group. Preferably, you want the end stations to advertise the fact that they will be participating and have your RPs and switches use this information to intelligently forward multicast traffic from the multicast server to the end stations. Without this type of information, the network would have to flood the traffic to every segment.

The solution provided for IP networks is called the Internet Group Management Protocol (IGMP), which works between end stations and RPs. End stations send out advertisements to the RPs, denoting which multicast application (or applications) they're participating in. The RPs then forward the multicast traffic from the server to the client's segment. The RP maintains a list of participating clients, updating it as clients join and leave multicast groups. To ensure the validity of its client list, the RP periodically sends out a query to the end stations on its different segments. In this manner, the RP forwards multicast traffic only to segments that have active multicast clients. RPs then share this information with each other via a multicast routing protocol so that multicast traffic from a server can be routed to participating end stations. As long as there's one active station on a given segment, the RP continues to forward the multicast stream to the segment.

Overview

IGMP provides a standardized, dynamic, client registration process in which clients advertise the multicast applications they want to participate in to their connected RPs. The three different versions of IGMP are v1, v2, and v3. In all versions of IGMP, you'll find two basic components: multicast hosts and multicast queriers. These two components share two different types of messages:

• Query messages are used by the RP to discover the end stations on a segment that are participating in a multicast group.

• Report messages are used by end stations in response to the RP's query message to notify the RP of its participation in a multicast group.

The relationship between multicast querier and host is a loose one. Hosts come and go as they please, based on the user starting or stopping a multicast application. Likewise, senders of multicast information the RPs do not have to be members of the multicast group to participate in the multicast process. All versions rely on the use of Class D IP multicast addresses to differentiate between the multicast applications.

IGMPv1

IGMP is an IP protocol. Using 28-byte IP packets, information is transmitted to members of the multicast groups. The top part of Figure 8.1 displays the format of an IGMPv1 message.

Figure 8.1. IGMPv1 and v2 packet formats.

There's a 4-bit version field, which is set to 1 for IGMPv1 messages and defines which of the two message types this is either a host membership query or a host membership report. The last part of the message is the multicast group address of the application. For query messages, this field contains zeroes and is ignored by the end stations. For report messages, the field contains the multicast address of the application that the host is participating in.

Joining a Group Using IGMPv1

Membership in a multicast group is a dynamic process users join and leave with a click of a button on their desktop. To begin with, hosts do not have to wait for the RP to generate a query message. When a host wants to join a multicast group, it generates an IGMP message that contains the group address of the multicast application in which it wants to participate. This message is called a host membership report and is sent to the all-router group (224.0.0.2). By doing this, the end station speeds up the process by notifying the RP that the RP needs to start forwarding multicast information to the segment.

The second way that a host can join a multicast group is if an RP generates a query message and the host responds back with the multicast application address it wants to access. This message is called a host membership query and is sent to the all-hosts group. It uses a destination address of 224.0.0.1 in the IP packet to do this. The query's TTL is set to 1 so that any other RP on the segment does not inadvertently forward it to a different segment. Any packet with a destination IP address ranging from 224.0.0.0 through 224.0.0.255 should never be forwarded by an RP. By default, Cisco RPs generate this query every 60 seconds.

If multiple RPs are on the same segment as the hosts, it's left to the implementation of the multicast routing protocol to limit the number of RPs that actively participate in the query process. If the interface on the RP has just been enabled, the RP, instead of using its 60-second timer for generating queries, will fire off a handful of IGMP queries to speed up the discovery process and the forwarding of multicast traffic. After so many of these quick-fire queries, the RP will settle down and generate queries based only on its configured timer.

Maintaining a Group Using IGMPv1

The multicast-enabled RP will periodically generate IGMP queries to verify whether there are still any hosts on a given segment participating in a multicast application. The RP will do this on each of its configured interfaces. Because the RP is generating the message, the group address in the IGMP message is set to 0.0.0.0 and the destination IP address is 224.0.0.1. This is the host membership query discussed in the previous section.

To reduce the amount of IGMP traffic, only one host will respond to the RP's query by generating a host membership report message. This process, sometimes referred to as response suppression, reduces the amount of bandwidth needed by IGMP and also reduces the amount of processing that the hosts must perform.

When the hosts on the segment receive the RP's query, they use a timer to start counting down the seconds from a random starting point. In IGMPv1, the range of seconds in the timer can be from 0 to 10. After choosing the random time value between 0 and 10 and then counting down the seconds, the host checks whether another host has generated a membership report in response to the RP's query. If the host sees a response, it cancels its countdown timer and does not generate a report. However, if the host's timer expires and it has not seen a response from another host, it generates the report itself and sends it to the all-router group.

Leaving a Group Using IGMPv1

IGMPv1 has no defined leave mechanism through which a host can dynamically inform the RP that it is quitting the multicast group. The RP discovers that no hosts are participating in a multicast group via the periodic query messages it generates. If the RP misses a certain number of query messages from the multicast group, the RP will stop forwarding multicast traffic for the specific application to the segment.

IGMPv2

IGMP version 2 adds some additional features and improvements to the earlier version. Like IGMPv1, IGMPv2 uses IP packets to transfer its messages. Also just like IGMPv1, the IGMPv2 messages are 28 bytes long. The bottom part of Figure 8.1 displays the format of IGMPv2 messages. The Type field describes the different message types. The four message types are as follows: Membership query, IGMPv1 membership report, IGMPv2 membership report, and a leave report. The second field, Maximum Response Time, is used to specify the maximum time allowed before sending a responding report. The default value is 10 seconds.

IGMPv2 deals with the deficiencies of the join-and-leave process in IGMPv1. One of the issues with IGMPv1 is that it might take a while before an IGMP RP discovers the fact that no end stations are participating in a multicast group or that an end station wants to participate in a multicast group. In addition, there's no process to ensure that only one RP plays an active role and forwards multicast traffic to the segment. When there's more than one RP on a segment, it could create the unnecessary forwarding of multicast traffic.

One new addition to IGMPv2 is the group-specific query message. This allows an RP to send a specific query to only one multicast group on a segment. In IGMPv1, the RP can discover whether an end station has left only after it has sent its periodic query. To speed up the process, the end station can send a leave report message, thus reducing the latency involved for the RP to stop forwarding multicast traffic to segments that no longer haveparticipating hosts. Version 2 RPs can generate version 1 messages for backward-compatibility purposes. This is proven by the two different membership report message types that the IGMPv2 packet supports.

Joining a Group with IGMPv2

The join process occurs in IGMPv2 the same as it does in IGMPv1. When a user starts a multicast application, the end station generates a multicast message to the all-router group. The RP looks at the IGMP group multicast address in the IGMPv2 message. If it does not already contain this address in its multicast table, it adds the address and starts forwarding multicast traffic from the multicast server to the segment. If the end stations do not advertise the fact that they want to participate in a multicast application, the multicast RP uses periodic queries and the response reports from the end stations to build its multicast table. The multicast table contains the multicast application addresses and the port off of which there are participating end stations.

Maintaining a Group with IGMPv2

In IGMPv1, there's no defined process as to which RP should play the active role. Initially, all IGMPv2 RPs assume that they are the active querier and periodically generate query messages.

Every RP on a segment will see the others' query messages. Through this process, the RP with the lowest IP address on the segment is automatically elected as the querier for the segment. If a new RP with a lower IP address is introduced to the segment, it will be promoted as the active querier.

In IGMPv1, a random timer is used to determine which end station will respond back to the RP's query. The end station timer that expires first is the one that responds. IGMPv2 takes a different approach to the election process.

When an active RP generates a query, it expects a response back from a participating multicast end station within the time interval specified in the Maximum Time Response field in the IGMP packet. This is sometimes referred to as the query-interval response period. Likewise, IGMPv2 allows the querying RP to send a query message to a single multicast group instead of every group on the segment. With IGMPv1, the RP forwards its queries to the all-hosts multicast address of 224.0.0.1. With IGMPv2, the RP forwards the query to the group multicast address.

As with IGMPv1, only one end station will respond all other members of the multicast group suppress their reports. When the end station responds with its v2 membership report, it sets the TTL field in the IP packet to 1. This ensures that the RP will not forward it to other segments. One member from each group will respond to each specific multicast group address query. If there are five different multicast applications with five unique multicast addresses, the RP generates five IGMP queries and expects five different responses.

Leaving a Group with IGMPv2

With IGMPv2, the client can stop participating in a multicast application by sending an IGMP leave request to the RP. This is different from IGMPv1, in which the RP discovers a lack of participation by checking for responses to its queries.

This special leave group message has a destination IP address of 224.0.0.2 and enters the multicast application address in the Multicast Group Address field in the IGMP packet. When the RP receives this, it immediately generates an IGMP group-specific query report to check for any participating end stations. This speeds up the process of the RP discovering when the last end station leaves a multicast group, causing the RP to stop forwarding the multicast traffic to the segment.

An RP, with IGMPv1, discovers an end station has left a group by examining the responses to its queries. In IGMPv2, the end station generates a special leave message.

IGMPv3

IGMPv3 is an enhancement of IGMPv2. IGMPv3 allows an end station to tell an RP which multicast groups it wants to participate in as well as from which source servers it wants to receive this information. The RP can then forward multicast traffic to the end station from one of the specified source servers. This is called source filtering.

IGMPv3 Message Types

IGMPv3 supports two general types of messages: membership query and membership report. Figure 8.2 displays the format of the two message types. The membership query message is used by an RP to determine which end stations are participating in a multicast group or groups. With this message type, there is a group multicast address field, a number of sources field, and a list of source addresses. This allows the RP to advertise all the sources for a particular multicast group so that clients can indicate whether they're using source filtering and tell the RP which source or source of these messages they want to receive the multicast information from.

Figure 8.2. IGMPv3 packet formats.

The membership report message is generated by an end station. There are two types of membership report messages: INCLUDE and EXCLUDE. If the end station is not performing source filtering, it sends an INCLUDE message. The INCLUDE message lists all the multicast groups the end station wants to participate in. If the end station is performing source filtering, it generates an EXCLUDE message, which indicates, for a particular multicast group address, the source addresses the end station wants to receive data from. This tells the RP which multicast sources it should use when forwarding multicast traffic for the group address to the end station.

IGMP v3lite

Because many vendors have not included support for IGMPv3 in their operating systems, Cisco has developed a proprietary version of IGMPv3 as a temporary solution. IGMP v3lite, which contains a subset of IGMPv3 features and functions, allows Cisco partners to develop applications that take advantage of PIM and SSM, allowing for a very scalable multicast solution. If you install v3lite on an end station that already supports IGMPv3, the v3lite software will have the IGMPv3 component of the operating system handle IGMP processing.

IGMPv3 is disabled by default on Cisco routers. You can enable it by using the following configuration:

 Router(config)# interface type [slot#/]port_# Router(config-if)# ip igmp v3lite