4.2 Group registration with IGMP

The requirement for a host to be able to join or leave a multicast group is fundamental to multicasting. Membership of a group is interface specific and dynamic (i.e., processes or applications may join and leave one or more groups at will). To support this functionality the Internet Group Management Protocol (IGMP) is used by hosts and routers to communicate multicast group status. (See Figure 4.4.)

click to expand
Figure 4.4: IGMP message format.

IGMP Field Definitions

Type—Specifies a query or a report. Note that IGMPv2 did away with the IGMPvl Version field and expects subsequent implementations to recognize messages by their type. Current types include:
- 0x11—Membership Query. There are two subtypes of membership query messages: general query, used to learn which groups have members on an attached network, and group-specific query, used to learn if a particular group has any members on an attached network. These two messages are differentiated by the group address; a general query uses the all-hosts group address 224.0.0.1, whereas a group-specific query uses the group address being queried. Note that membership query messages are referred to simply as query messages.
- 0x12—version 1 membership report (for backwards compatibility with IGMPvl)
- 0x16—version 2 membership report
- 0x17—leave group: sent to the all-routers group address 224.0.0.2
Max Response Time (MRT)—Used in membership query messages; in all other messages, it is set to 0 by the sender and ignored by receivers. MRT specifies (in units of 1/10 second) the maximum time allowed before sending a responding report. Modifying this setting allows IGMPv2 routers to tune the leave latency (i.e., the time between the moment when the last host leaves a group and when the routing protocol is notified that there are no more members). It also allows tuning of the burstiness of IGMP traffic on a subnet.
Checksum—A 16-bit checksum calculated as the ones complement of the ones complement sum of the whole IGMP message (i.e., the entire IP payload). Prior to computing the checksum, the checksum field is set to 0.
Group Address—In a membership query message, this field is set to 0 when sending a general query and set to the group address being queried when sending a group-specific query. In a membership report or leave group message, this field holds the IP multicast group address of the group being reported or left.

Group membership requests are sent from hosts directly to their nearest multicast router. When a host is multihomed, it can join any group on one or more of its interfaces or subnets. The host keeps track internally of which processes are interested in which group [4]. IGMP uses the expanding ring search technique (described earlier in this chapter) to locate multicast servers. A special range of addresses, 224.0.0.0 through 224.0.0.255, is intended for applications that never need to multicast further than one hop. A multicast router should never forward a datagram with one of these addresses as the destination, regardless of the TTL. For the interested reader IGMPv2 is specified in [12], which updates [4].

4.2.1 Message format

IGMP messages are encapsulated in IP datagrams. IP uses the protocol identifier 2 to indicate IGMP, sets the Type-of-Service (ToS) field to 0, and the Time-to-Live (TTL) field to 1. In IPv4 multicast support is optional, whereas in IPv6 IGMP functionality is integrated into ICMPv6, since all IPv6 hosts are required to support multicasting. Figure 4.4 shows the format of the eight-byte IGMPv2 message.

4.2.2 Operation

The basic operations of IGMP take place between routers and hosts. Multicast routers need to establish whether hosts are interested in specific multicast groups on a specific interface at any particular time (otherwise, if host machines die, how do we know if they are still interested in receiving multicasts?). Routers achieve this by a process of learning. Queries are sent out to the all-hosts multicast address (224.0.0.1) at roughly two-minute intervals to all IGMP-enabled interfaces, and the reports coming back from hosts are used to maintain a database of group memberships associated with each interface, together with a timer for each group membership. Membership requires the presence of at least one active member of a multicast group on a specific interface. When a router receives a multicast datagram, it forwards the datagram (mapped to a corresponding Layer 2 multicast address) on only those interfaces that still have hosts registering an interest in that group. Note that if a router has multiple physical interfaces on a single network, IGMP need run on only one of them. By contrast, hosts must run IGMP on all interfaces that require group membership.

A multicast router running IGMP will assume one of two states with respect to each of its attached network interfaces: Querier or non-Querier. There is normally only one Querier per physical network; so, for example, on a multiaccess LAN, one router is responsible for issuing queries, and the rest stay quiet. The Querier is determined by a simple election process.

IGMP timers

IGMPv2 operations rely on a number of key timers. Most of these timers are configurable; however, if nondefault settings are used, they must be consistent among all routers on a single link. The timers include the following:

Robustness_Variable (default: 2)—This allows tuning for the expected packet loss on a subnet. If a subnet is expected to be lossy, this variable may be increased. IGMP is robust to (Robustness Variable-1) packet losses. The Robustness_Variable must not be zero and should not be one.
Query_Interval (default: 125 seconds)—This is the interval between general queries sent by the Querier. By varying this interval an administrator can tune the number of IGMP messages on the subnet; larger values cause IGMP queries to be sent less often.
Query_Response_Interval (default: 100—i.e., 10 seconds)—This is the max response time inserted into the periodic general queries. By varying this interval, an administrator can tune the burstiness of IGMP messages on the subnet; larger values make the traffic less bursty, since host responses are spread out over a larger interval. Note that (Query_Response_Interval/10) must be less than the Query_Interval.
Group_Membership_Interval—This is the amount of time that must pass before a multicast router decides there are no more members of a group on a network. This value must be (Robustness_Variable × Query_Interval) - Query_Response_Interval.
Other_Querier_Present_Interval—This is the length of time that must pass before a multicast router decides that there is no longer another multicast router that should be the Querier. This value must be [(Robustness Variable) × Query_Interval) + (Query_Response_Interval/2)].
Startup_Query_Interval (default: Query_Interval/4)—This is the interval between general queries sent by a Querier on startup.
Startup_Query_Count (default: Robustness Variable)—This is the number of queries sent out on startup, separated by the Startup_Query_Interval.
Last_Member_Query_Interval (default: 10—i.e., 1 second)—This is the max response time inserted into group-specific queries sent in response to leave group messages and is also the amount of time between group-specific query messages. This value may be tuned to modify the leave latency of the network. A reduced value results in reduced time to detect the loss of the last member of a group.
Last_Member_Query_Count (default: Robustness Variable)—The Last_Member_Query_Count is the number of group-specific queries sent before the router assumes there are no local members.
Unsolicited_Report_Interval (default:—10 seconds)—This is the time between repetitions of a host's initial report of membership in a group.
Version_1_Router_Present_Timeout (value: 400 seconds)—This is how long a host must wait after hearing an IGMPv1 query before it may send any IGMPv2 messages.

Querier election process

All multicast routers start up in the Querier state on each attached network. If a multicast router hears a query message from a router with a lower IP address, then it must defer and enter the non-Querier state; so ultimately the router with the lowest IP address wins. If a router has not heard a query message from another router for Other_Querier_Present_Interval, it resumes the role of Querier.

Building group membership tables

As described previously, in order to solicit group membership information a router periodically sends (at Query_Interval) a general query for all attached networks where the router is the Querier. Query messages are sent with a TTL of one to ensure they are not forwarded, and the long interval ensures that IGMP traffic is low. The group address in a query is set to 0, since the router expects a response from a host for every group that contains one or more members. Host membership for the all-hosts multicast group (224.0.0.1) is automatic. Each host that wishes to remain a member of one or more groups replies once for each group. These replies are sent after a random delay to ensure that IGMP does not cause traffic spikes on a subnet. Note that during the startup phase, a router should send Startup_Query_Count general queries more frequently (at Startup_Query_Interval) to the all-systems multicast group (224.0.0.1) in order to precharge its knowledge base.

When a host receives a general query, it sets delay timers for each group of which it is a member on the receiving interface. Each timer is set to a different random value, selected from the range (0 ± max response time], where max response time is specified in the query packet. When a host receives a group-specific query, it sets a delay timer for the specific group being queried, assuming that it is a member on the receiving interface. Subsequent queries may cause this timer to be reset but only if the specified max response time is less than the value of the timer. When a timer expires, the host multicasts a version 2 membership report for that group, with an IP TTL of one. If the host receives another host's report while it has a timer running, it stops its timer for the specified group and does not send a report in order to avoid duplicate reports.

When a router receives a report, it adds the group specified to the receive interface database and sets the timer for the membership at Group_Membership_Interval. Subsequent reports refresh this timer. If no reports are received for a particular group before this timer has expired, the router assumes that the group has no active members on that interface and so the interface is pruned.

Joining a multicast group

To join a group, the host first sends an unsolicited IGMPv2 membership report to the interface on which it requires service. This report is addressed to the multicast group of interest with a TTL of one. To allow for the possibility of the initial membership report being lost, it is recommended that the report is transmitted once or twice after a short delay (Unsolicited_Report_Interval). Multicast routers on the same subnet receive the report and set a flag (if not already set) to indicate that at least one host on the subnet is an active group member. If that branch was previously pruned, the router will graft the subnet onto the distribution tree and start to forward multicasts. Multicast routers must listen to all multicast addresses in order to detect such reports. If other applications or processes on the same subnet subsequently join the same multicast group, there is no need for the host to send another report.

On a large subnet there could be many hosts registering an interest in various multicast groups. To avoid excessive bandwidth spikes, [4] recommends that either a random timer be used by hosts, or, since routers do not care how many hosts are members of a group, only one host need register interest for a group on an interface. Hosts are already listening to registration claims (since they are issued to the multicast group address of interest) and can cancel any pending claims if another host registers interest on the same subnet. This saves wasting resources unnecessarily. If no hosts claim membership of a group within a specified interval, a multicast router will assume that there are no group members on that interface and take appropriate action (such as pruning, if necessary).

Leaving a multicast group

When a host leaves a multicast group, it has one of the two following choices:

If it was the last host to reply to a query with a membership report for that group, it should send a leave group message to the all-routers multicast group (224.0.0.2). Note that some older implementations use the group multicast destination address, and this should also be supported for backward compatibility.
If it was not the last host to reply to a query, it may send nothing, since there must be another member on the subnet.

Note that IGMPv1 relied on membership dying out through lack of response; IGMPv2 modifies this behavior to reduce traffic and speed up convergence. A host that cannot maintain status information can always send a leave group message. If a Querier receives a leave group message for a multicast group on an interface that is thought to have active group members, it sends group-specific queries to those groups remaining. If no reports are received after the response time of the last query expires, the routers assume that the group has no local members. Any Querier to non-Querier transition is ignored during this time; the same router keeps sending the group-specific queries. Furthermore, non-Queriers must ignore leave group messages, and Queriers should ignore leave group messages for which there are no group members on the reception interface.

Multicast distribution

IGMP operates effectively as an ES-IS protocol for multicasts; it does not deal with the mechanisms for multicast distribution between multicast routers. There are several multicast routing protocols (such as MOSPF or DVMRP) available for multicast packet routing between multicast routers. Figure 4.5 shows interaction between IGMP and a multicast routing protocol operating in different parts of the topology. Multicasts are transmitted from a sender through a Spanning Tree to the receivers. If none of the hosts on an interface requires multicasts, the branch is pruned. In Figure 4.5, we see that S1 and S2 are multicast servers propagating multicasts on groups A and B, respectively. Shaded areas show current areas where IGMP is running. Hosts 7 and 8 register an interest in group A multicasts, while Host 6 registers an interest in group B multicasts. Routers 3 and 5 prune back the distribution tree to Router 1, since they have no current hosts requiring multicast service. All routers periodically send IGMP requests out on all downstream interfaces to check status. Any host wishing to receive multicasts must issue IGMP report and then respond positively to any future router IGMP requests. The protocol running between routers (i.e., unshaded areas) could be MOSPF or DVMRP.

click to expand
Figure 4.5: Multicast routing operations with IGMP.

When a host or a multicast router receives a multicast datagram, its action is dependent upon the TTL value and the destination IP address, as follows:

A datagram with a TTL of zero is restricted to the source host and should not be transmitted.
A datagram with a TTL of one will be seen by all hosts on the subnet that are members of the group. Multicast routers decrement the TTL value to zero. Multicast routers view this as a normal occurrence, and they do not send ICMP time-exceeded messages (which would be the norm for unicasts with a low TTL).
A datagram with a TTL of two (or greater) will be seen by all hosts that are members of the group and all multicast routers (depending upon the actual TTL and the radius of the network). The action of the routers depends on the multicast group address, as follows:
- [224.0.0.0-224.0.0.255]—Multicast routers will not forward datagrams with destination IP addresses in this range; these addresses are intended for single-hop multicasting applications only. When a host issues a report to these addresses, this informs other hosts on the subnet that the host is a member of the destination multicast group. The exceptions to this rule are 224.0.0.1 and 224.0.0.2.
- [Other multicast groups]—Datagrams with other destination addresses are forwarded as normal by a multicast router. Each router decrements the TTL value by one at each hop, which allows a host to locate the nearest server using an expanding ring search.

Compatibility with IGMPv1 devices

The changes between IGMPv2 and IGMPv1 were fairly significant and are summarized as follows:

The IGMPv1 Version and Type fields were combined into a single Type field.
A new IGMP Type was assigned to version 2 membership report messages, so a router may differentiate between an IGMPv1 and IGMPv2 host report.
The leave group message type was added.
The unused field in the membership query message was reallocated to a new max response time field.
The IGMPv2 specification now specifies a Querier election mechanism.
The requirements on validity checking for membership queries and membership reports were relaxed.
The IP router alert option [13] is required to be in all IGMPv2 packets.

For full details, refer to [12], which imposes several requirements to enable backward compatibility. If an IGMPv2 host is deployed on a subnet where there are IGMP hosts that predate IGMPv2, the host must allow its membership report to be suppressed by either a version 1 membership report or a version 2 membership report. If an IGMPv2 router is deployed on a subnet where there are other IGMP hosts that predate IGMPv2, two further requirements apply, as follows:

If a router receives a version 1 membership report, it must set a timer to note that there are version 1 hosts present that are members of the group for which it heard the report.
If there are version 1 hosts present for a particular group, a router must ignore any leave group messages that it receives for that group.

Note also that in some older versions of IGMPv2, hosts send leave messages to the remaining multicast group. A router should accept leave messages addressed in this manner for backward compatibility. In all cases, however, hosts must send leave messages to the all-routers address (224.0.0.2). For further details refer to [12].