Standards & Protocols
Joining the Multicast Community
By Mike Rodbell
IGMP provides information that the multicast routing protocols can employ in constructing
comprehensive multicast routing trees and paths.
Last month, we reviewed how multicast services can be handled within IP networks. One of the widely accepted components of IP multicast is the Internet group management protocol (IGMP). In simple terms, IGMP provides a set of mechanisms for routers to track memberships to any multicast groups on their attached interfaces (also known as subnetworks). Once a router has determined that there are group members on a subnetwork that it supports, routing
mechanisms can be employed to interconnect widely distributed multicast groups. In this role, IGMP is a fundamental element of IP multicast services.
There are two accepted versions of IGMP, with a third in the research phase. Version 1 defined the initial mechanisms that could be employed, but left some room for improvement. Version 2, published as an Internet draft, provides a set of mechanisms that shorten the amount of time required for a router to determine that no stations are in a particular group.
IGMPv2 has become the accepted standard for IP group membership management. Additional work on the protocol has been sporadic, with several topics of discussion, including more sophisticated group identification and consideration for IPv6 interoperability. There is now a draft of version 3 that adds the ability to have hosts express interest in groups identified by the IP multicast address, as well as the ability to include several groups in the same transmission.
IGMP operation is based on central routers
polling all stations on the subnet for membership information. As each station receives the poll, it issues reports that identify their interest in participating in different multicast groups. The mechanisms employed to allow group members to terminate (leave) their participation in a multicast group are one of the distinguishing differences between the versions of IGMP.
IGMP version 1
IGMP version 1 (IGMPv1) is defined in Appendix 1 of Request for Comments (RFC) 1112. This is actually the
second version of IGMP. There was an IGMP version 0, specified by RFC 988, which was made obsolete through the introduction of version 1. Like the Internet control message protocol (ICMP), IGMP is considered an integral part of multicast capable nodes and runs directly above IP. As such, it is also considered an integral portion of IP and uses IP protocol number 2.
IGMP provides a set of mechanisms that allow multicast routers to collect and maintain a set of multicast group memberships for each
supported subnet. The fundamental operations include the following:
• Adding a group to the subnet
• Removing a group from the subnet.
Group membership status is derived from IGMP transactions between the multicast router and the hosts attached to the local subnet.
All IGMPv1 transactions are performed using the data transfer format shown in
Figure 1
. This simple message contains the following elements:
•
Version
indicates the IGMP
version being processed by the message.
•
Type
indicates the message type. In IGMPv1, there are two types of messages. Type 1 host-membership queries are sent to request all membership information. Type 2 host-membership reports are sent in response to the queries to indicate the various group memberships being handled over the particular interface.
•
Checksum
is the 16-bit one’s complement of the one’s complement sum of the IGMP message.
•
Group address
is zero in the case of a query. For the IGMP response, this contains the IP host address of the group being reported.
This simple message format is used to allow two types of devices to communicate group membership information over a single subnet. To ensure that the messages traverse only the local interface, all IGMP messages are sent with an IP time to live (TTL) of 1. In general, the operation of IGMP is based on multicast routers periodically sending host membership queries on the subnet. This
message is sent to the “all-hosts” group address (224.0.0.1). As hosts receive this query, they respond with IGMP reports identifying the multicast group memberships that each group requires.
While, on the surface, the query/ response nature of IGMP seems simple, there are a few tricks. Consider the case of a LAN where several hosts are participating in the same multicast group. If you took the protocol in its simplest form, each query could result in a barrage of response messages, where a
single response would suffice. Two general techniques are suggested to deal with this situation:
• Hosts delay for a random period of time. This spreads the responses to avoid large accumulations of peak responses.
• Hosts delay responses to queries for a random period between zero and “D seconds.” Upon expiration of the random period, if the host has not witnessed a different host issuing a report for the multicast group, it emits the unannounced multicast groups. This algorithm
provides the benefit of requiring only a single transmission for each multicast group on a subnetwork.
The routers periodically emit the query messages. If a multicast group does not appear after several query periods, the group is considered to be inactive over the referenced subnetwork. Also, to speed entry into a multicast group, hosts initially entering a group can send a IGMP report. The referenced router can then immediately add the group to its list.
IGMP version 2
More
recently, version 2 of IGMP has been developed and become something of a defacto standard for group membership. Never formally released as a standard or RFC, IGMP lives as a set of widely distributed source code and a (now obsolete) draft specification submitted to the Internet Engineering Task Force (IETF). This version of the protocol was initially deployed with the distance-vector multicast routing protocol (DVMRP), which could be found in the routed package. The specification is published only in a now
obsolete draft titled “draft-ietf-idmr-igmp-v2-07.txt,” which can be found (although not always easily) through some of the Internet search engines.
So why did they put out a modification of the standard? There were a few characteristics of IGMPv1 that didn’t scale very well. Some subnetworks could have multiple multicast routers, leading to linear growth in the IGMP traffic where no growth should have been necessary. The earlier algorithms also could result in a considerable amount of time
being required to shut down multicast traffic after the last station exited from a multicast group. This “leave latency” can result in additional multicast traffic being routed to a subnetwork when no machines have any interest in receiving the traffic.
The message format, shown in
Figure 2
, is slightly different from that used in IGMPv1, although interoperability is retained. Version 2 messages include two format changes. The type field is extended to include the
first full octet, although, given the message numbering scheme, this is only a semantic change (the resulting messages that overlap with IGMPv1 are retained). The new field that has been added is the maximum response time, which represents the maximum amount of time in tenths of seconds that a querier will wait for group membership responses. Since this field was unused in IGMPv1, it is ignored by old hosts.
To limit the number of stations polling on a subnetwork, IGMPv2 has introduced the concept of
“querier election.” This algorithm is designed to result in only a single router issuing multicast queries. For IGMPv2, the multicast router with the lowest IP address is selected to act as the source of all IGMP query messages. The algorithm is accomplished by having each station adhere to the following policy:
• On initial start up, the router assumes that it must take the role of the multicast querier. As such, the device will issue queries on the subnet.
• If the station
receives an IGMP query from another station on the subnet with a lower IP address, the receiving station will cease transmission of any subsequent query messages.
• Once a station has determined that it doesn’t need to send query messages, it still eavesdrops on the IGMP traffic, learning about the presence or absence of group memberships.
This algorithm can greatly reduce the amount of traffic required to maintain group memberships on networks in which there is significant host
participation.
To limit the amount of unnecessary multicast traffic, faster group exit mechanisms have been added. There is now a new message, “leave group,” which can be sent by hosts to indicate that they no longer wish to participate in a particular multicast group. On receipt of the leave group message, the selected querier must then issue a second new message, the “group specific query” to determine if any other stations still wish to continue participation in the referenced multicast group.
If no responses are received for the group, then the querier (and all other eavesdropping routers) can determine the absence of interest. The router(s) can then more quickly propagate the lack of interest and limit the traffic on both the subnetwork in question, as well as any routes that may have been established for the sole purpose of routing the multicast group to that particular subnetwork.
IGMP version 3
As time moves forward, so does technology. IGMP version 3 is a more recent
research effort targeted at further improving the IGMP services. In particular, IGMPv3 efforts are geared towards providing mechanisms that allow hosts to better specify group memberships. The IGMPv3 group membership services add the ability to specify the actual host machines that are to source the information, rather than only the group address. By specifying the host, applications that permit several hosts to share a group address no longer result in every end-system needing to receive the traffic.
Furthermore, by better defining the group memberships, the number of established multicast routes can be better constrained to only those nodes requiring participation.
As can be seen in
Figures 3
,
4
, and
5
, the message formats have been extended to support additional message types and information. Group specific queries can now include the source addresses (
Figure 3
) and the
reports can include a series of group reports (
Figure 4
), each containing the multicast group address and a list of acceptable sources (
Figure 5
).
By providing these services to automatically detect membership in multicast groups, IGMP provides information the multicast routing protocols can employ in constructing more comprehensive multicast routing trees and paths. More on that will be presented in the following months.
Mike
Rodbell is a director of embedded software development for CIENA Communications Inc. He has developed voice and data communication systems for a wide range of commercial and military systems. He holds a BSCS from Trinity College of Hartford, CT, and an MSEE from Loyola College of Baltimore, MD. He can be reached at mrodbell@ciena.com or http://www.ciena.com.
Puzzled by a network processing design issue?
