Internet protocol (IP) multicast technology has matured quite a bit since it was first deployed in the late 1990s. Multicast-enabled applications such as webinars, video/audio conferences, Internet radio/TV, and networked games are now being used widely over the Internet. These multi-user applications require data flow between a set of sources and a set of receivers in real time.
In multicast applications, Internet datagrams (IP packets) are normally sent as unicast packets i.e., from one source to one destination. However when multiple receivers require the same data, replicating the data from the source to all the receivers as individual unicast packets increases the network load, resulting in network congestion and loss of expected QoS. IP multicast enables efficient transfer of data from a set of sources to a dynamically formed set of receivers.
But, IP multicast also has its challenges. these include:
- Maintaining dynamic group member information at a router which forwards the multicast data.
- Determining efficient paths to forward data from a set of sources to a set of receivers.
- Ensuring duplication-free data forwarding.
- Ensuring committed service-level agreements (SLAs).
Multicast routing protocols such as distance vector multicast routing protocol (DVMRP), protocol independent multicast (PIM), multicast border gateway protocol (MBGP) enabled in multicast routers ensure shortest path forwarding between the multicast source(s) and the multicast receivers/hosts. Group membership information is propagated in the network from the hosts towards to the routers that are directly attached to the sources in a bottom-up approach with the help of Internet group management protocol (IGMP) and other multicast protocols (PIM, MOSPF etc.,). These multicast protocols with improved hardware functionality ensure duplication free forwarding and quality of service.
IGMP plays an important role in the maintenance of dynamic group membership information at the local networks. In this article, we'll take an in-depth look at the IGMP protocol and its impact in a multicast network design (Figure 1).
Figure 1: Diagram showing a sample multicast network.
IGMP Version 1
IGMPv1 (IETF RFC 1122) supports two types of protocol messages: membership query and membership report messages. An IGMPv1 host sends a report when it joins a multicast group. An IGMPv1 router (also known as querier) queries periodically using query messages to determine the active members of a group. Whenever a host receives a query message, it responds with report messages (one report per group) for all its associated multicast groups.
A host delays its report to a query by a random period (maximum of ten seconds) for each of its associated groups in order to check for a report sent by other members on the LAN. The report is delayed to avoid a burst of report messages from the hosts to the querier.
When the host does not receive a report from other hosts during the delay period, it generates the report by itself. The host suppresses report generation when it receives reports from other hosts during the delay period. The generated report message contains the same IP group host address in the IP destination address field and in the IGMP group membership field.
The querier starts a timer for the group membership information it receives in reports. If the group membership is not refreshed by subsequent reports (in response to general queries), the group information is removed.
The waiting period, which is comprised of few (2 or 3) query intervals to determine membership validity, is typically large (2 or 3 minutes). During this waiting period, the multicast data continues to be forwarded over the interfaces, occupying unnecessary bandwidth. This delay limitation is removed in IGMP version 2, which we'll discuss.
IGMPv2 (IETF RFC 2236) supports three types of protocol messages: membership query, membership report, and leave group messages. Version 2, along with version 1 and version 3 (discussed below), message groups are shown in Figure 2.
Click here for Figure 2
Figure 2: Diagram showing the IGMP message formats.
An IGMPv2 querier generates two types of query messages: a general query message to obtain all possible multicast membership information and a group specific query to determine whether there are any members for a specific multicast group.
An IGMPv2 host sends a report on joining a multicast group. It generates a report after a random delay when it receives a generic query message. A host that responds to a generic query message maintains information, as it is the last host to reply the query.
A last host sends a leave group message when it is no longer a member of the multicast group. When an IGMPv2 querier receives a leave group message for multicast group, it generates a group specific query to check whether there are any other member hosts for that particular group. It retains the membership information when it receives a report message for the group specific query and discards the membership information when it does not receive a report message for its group specific queries (typically 2 queries are sent with an interval of 1 second).
The support for leave and group specific query messages enables IGMPv2 queriers to quickly determine multicast groups without active members.
IGMPv3 (IETF RFC 3376) supports two types of protocol messages: membership query and membership report messages (see Figure 2 above). An IGMPv3 querier can query three types of information using a query message:
- A general query to determine the multicast reception state (membership information) associated with its neighboring hosts interfaces for all multicast groups enabled at the interface.
- A group-specific query to determine the multicast reception state for a specific multicast group associated with its neighboring hosts interfaces.
- A group-and-source-specific query to determine the multicast reception state for a specific multicast group and a specified set of sources, associated with its neighboring host's interfaces.
IGMPv3 hosts send v3 report messages to indicate their multicast reception states while responding to queries or when they need to indicate any change in their reception states. Reception state information associated with a group is placed as part of a group record (GR). An IGMPv3 report can contain multiple Group Records.
Record Types and Filter Modes
IGMPv3 provides support for source specific multicast. Thus, a receiver of a multicast group can specify an explicit set of sources from which it is interested or not interested to receive data.
Two filter modes are used in IGMPv3: include mode and exclude mode. In the include mode, data from the specified sources are filtered and forwarded towards the hosts by the multicast router. In the exclude mode, data from the specified sources are filtered and not forwarded towards the hosts.
The GR's record type value indicates whether the information is current or changed since the last state indication. IGMPv3 categorizes the group record information into three types:
- Current-State Record (CSR) This indicates the current reception state with respect to one multicast group at a given interface. It contains the filter mode (include or exclude) and the set of related sources. A CSR record type is either MODE_IS_INCLUDE or MODE_IS_EXCLUDE.
- Filter-Mode-Change Record (FMCR) This indicates that the filter-mode of the reception state has changed. It contains the new filter-mode and the set of related sources. A FMCR record type is either CHANGE_TO_INCLUDE_MODE or CHANGE_TO_EXCLUDE_MODE.
- Source-List-Change Record (SLCR) This indicates that the group's associated sources have changed. A SLCR record type is ALLOW_NEW_SOURCES, when data from a new set of sources are to be received. It is BLOCK_OLD_SOURCES, when data from an existing set of sources are not required.
Querier State Information
The functionality of an IGMPv3 querier is complex compared to the earlier versions (v1 or v2). An IGMPv3 querier has to handle the six types of group record information (discussed above) and maintain the state information for each reachable multicast group associated with each network interface. The state information consists of the following: multicast address, group timer, filter mode, and source records. Note: Each source record contains source address and a source timer.
The filter mode for a multicast group in a querier is known as router filter mode (RFM). It is determined after processing all the received state record information from the neighboring IGMPv3 hosts for the group. When the RFM is include, the source record list contains the list of sources whose data are to be forwarded on the attached network.
When the RFM is exclude, the source record list contains two types of sources. The first set (type) contains sources whose data needs to be forwarded by some routers while the second set contains sources whose data are not to be forwarded. The group timer is used when the filter mode is exclude.
When a CSR with record type MODE_IS_EXCLUDE is received, the RFM for the group becomes exclude. When the host that had reported a CSR with MODE_IS_EXCLUDE stops reporting and the group timer expires, the RFM changes to include.
Figure 3 shows a sample sequence of current state records received at a router. The resulting router's state is described in Table 1.
Figure 3: Sample IGMP message exchanges.
Table 1: IGMP State Information at Router R3 for Sequences in Figure 3
It is possible to have more than one IGMP (v2 or v3) querier in a network. To reduce the number of queries and the reports, IGMP has been designed to elect a querier per network.
The querier election algorithm elects the router which has the smallest IP address as the network's querier. The other routers assume a role of non-querier and do not generate any query messages, instead act on the received reports on the attached interfaces.
A non-querier starts a timer and waits for query messages to detect the presence of the elected querier. When the non-querier does not receive query messages from the elected querier for the specified period (approximately 255 seconds) it assumes the role of the querier.
The IEEE 802.1D bridging specification defines multicast packets to be forwarded on all the ports (except the receiving port) that are in the forwarding state. This has an inherent limitation when the intended multicast data is required to be forwarded only on few ports and not on all the ports.
One solution defined in 802.11D to overcome this limitation is to use the generic attribute registration protocol (GARP) and GARP mulitcast registration protocol (GMRP). While GMRP enables efficient multicast data forwarding at the switches, it also requires an implementation of the GARP. Secondly GMRP does not enable the multicast information to be propagated to the Multicast Routers attached to the LANs. In both GARP and GMRP, IGMP is required for distributing the multicast information.
In recent years, the industry has seen vendors offering IGMP snooping (IGS) switches. These switch devices use the multicast information in the IGMP (v1/v2/v3) report messages exchanged between the hosts and the routers connected on the LAN to build their multicast forwarding / filtering database.
An IGS switch typically learns (or is configured with) the ports on which the routers are reachable and the ports on which the hosts are reachable. When a report is received on a port, it is forwarded on the port attached to the router. The report is not forwarded on the other ports containing hosts since this could cause the other hosts to suppress their report generation for the multicast group.
Whenever a new port's state moves to forwarding as a result of the spanning tree functionality, the switch forwards IGMP query message on the newly enabled port to detect the presence of IGMP hosts. This enables the switch to update its multicast filtering database with less latency. An IGS switch removes any invalid multicast information from its filtering database on received IGMP (v2 leave / v3 report) messages or using timeouts for group membership information.
Currently there is no defined standard for IGMP snooping. However, the International Engineering Task Force's (IETF's) Multicast and Anycast Group is working towards a recommendation for IGMP snooping implementation.
IP multicast is growing in importance in internets today and IGMP is a key component that provides the receiver hosts and transmitting sources the capability of being dynamically added and removed on the network. Several enhancements have recently been made to the IGMP protocol in order to optimize for network performance and provide enhanced features. IGMP snooping is a popular mechanism being used by Layer 2 and Layer 3 switch vendors in their implementations and is yet to be recommended as a standard by IETF.
About the Author
Manikantan Srinivasan is the engineering manager at Net-O2 Technologies. He has an ME (Computer Science & Engineering) from the Indian Institute of Science, Bangalore, India and a B.Sc in Physics and Electronics from the University of Bangalore, India. Manikantan can be reached at firstname.lastname@example.org.