The Internet Group Management Protocol (IGMP) is used by IP hosts to
report their host group memberships to any immediately-neighboring
multicast routers. IGMP is an asymmetric protocol and is specified
here from the point of view of a host, rather than a multicast
router. (IGMP may also be used, symmetrically or asymmetrically,
between multicast routers. Such use is not specified here.)
Like ICMP, IGMP is a integral part of IP. It is required to be
implemented by all hosts conforming to level 2 of the IP multicasting
specification. IGMP messages are encapsulated in IP datagrams, with
an IP protocol number of 2. All IGMP messages of concern to hosts
have the following format:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Version| Type | Unused | Checksum |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Group Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Version
This memo specifies version 1 of IGMP. Version 0 is specified
in RFC-988(-> 1112std5 | 1054(-> 1112std5)) and is now obsolete.
Type
There are two types of IGMP message of concern to hosts:
1 = Host Membership Query
2 = Host Membership Report
Unused
Unused field, zeroed when sent, ignored when received.
Checksum
The checksum is the 16-bit one's complement of the one's
complement sum of the 8-octet IGMP message. For computing
the checksum, the checksum field is zeroed.
Group Address
In a Host Membership Query message, the group address field
is zeroed when sent, ignored when received.
In a Host Membership Report message, the group address field
holds the IP host group address of the group being reported.
8.1. Informal Protocol Description
Multicast routers send Host Membership Query messages (hereinafter
called Queries) to discover which host groups have members on their
attached local networks. Queries are addressed to the all-hosts
group (address 224.0.0.1), and carry an IP time-to-live of 1.
Hosts respond to a Query by generating Host Membership Reports
(hereinafter called Reports), reporting each host group to which they
belong on the network interface from which the Query was received.
In order to avoid an "implosion" of concurrent Reports and to reduce
the total number of Reports transmitted, two techniques are used:
1. When a host receives a Query, rather than sending Reports
immediately, it starts a report delay timer for each of its
group memberships on the network interface of the incoming
Query. Each timer is set to a different, randomly-chosen
value between zero and D seconds. When a timer expires, a
Report is generated for the corresponding host group. Thus,
Reports are spread out over a D second interval instead of
all occurring at once.
2. A Report is sent with an IP destination address equal to the
host group address being reported, and with an IP
time-to-live of 1, so that other members of the same group on
the same network can overhear the Report. If a host hears a
Report for a group to which it belongs on that network, the
host stops its own timer for that group and does not generate
a Report for that group. Thus, in the normal case, only one
Report will be generated for each group present on the
network, by the member host whose delay timer expires first.
Note that the multicast routers receive all IP multicast
datagrams, and therefore need not be addressed explicitly.
Further note that the routers need not know which hosts
belong to a group, only that at least one host belongs to a
group on a particular network.
There are two exceptions to the behavior described above. First, if
a report delay timer is already running for a group membership when a
Query is received, that timer is not reset to a new random value, but
rather allowed to continue running with its current value. Second, a
report delay timer is never set for a host's membership in the all-
hosts group (224.0.0.1), and that membership is never reported.
If a host uses a pseudo-random number generator to compute the
reporting delays, one of the host's own individual IP address should
be used as part of the seed for the generator, to reduce the chance
of multiple hosts generating the same sequence of delays.
A host should confirm that a received Report has the same IP host
group address in its IP destination field and its IGMP group address
field, to ensure that the host's own Report is not cancelled by an
erroneous received Report. A host should quietly discard any IGMP
message of type other than Host Membership Query or Host Membership
Report.
Multicast routers send Queries periodically to refresh their
knowledge of memberships present on a particular network. If no
Reports are received for a particular group after some number of
Queries, the routers assume that that group has no local members and
that they need not forward remotely-originated multicasts for that
group onto the local network. Queries are normally sent infrequently
(no more than once a minute) so as to keep the IGMP overhead on hosts
and networks very low. However, when a multicast router starts up,
it may issue several closely-space Queries in order to quickly build
up its knowledge of local memberships.
When a host joins a new group, it should immediately transmit a
Report for that group, rather than waiting for a Query, in case it is
the first member of that group on the network. To cover the
possibility of the initial Report being lost or damaged, it is
recommended that it be repeated once or twice after short delays. (A
simple way to accomplish this is to act as if a Query had been
received for that group only, setting the group's random report delay
timer. The state transition diagram below illustrates this
approach.)
Note that, on a network with no multicast routers present, the only
IGMP traffic is the one or more Reports sent whenever a host joins a
new group.
IGMP behavior is more formally specified by the state transition
diagram below. A host may be in one of three possible states, with
respect to any single IP host group on any single network interface:
- Non-Member state, when the host does not belong to the group
on the interface. This is the initial state for all
memberships on all network interfaces; it requires no storage
in the host.
- Delaying Member state, when the host belongs to the group on
the interface and has a report delay timer running for that
membership.
- Idle Member state, when the host belongs to the group on the
interface and does not have a report delay timer running for
that membership.
There are five significant events that can cause IGMP state
transitions:
- "join group" occurs when the host decides to join the group on
the interface. It may occur only in the Non-Member state.
- "leave group" occurs when the host decides to leave the group
on the interface. It may occur only in the Delaying Member
and Idle Member states.
- "query received" occurs when the host receives a valid IGMP
Host Membership Query message. To be valid, the Query message
must be at least 8 octets long and have a correct IGMP
checksum. A single Query applies to all memberships on the
interface from which the Query is received. It is ignored for
memberships in the Non-Member or Delaying Member state.
- "report received" occurs when the host receives a valid IGMP
Host Membership Report message. To be valid, the Report
message must be at least 8 octets long, have a correct IGMP
checksum, and contain the same IP host group address in its IP
destination field and its IGMP group address field. A Report
applies only to the membership in the group identified by the
Report, on the interface from which the Report is received.
It is ignored for memberships in the Non-Member or Idle Member
state.
- "timer expired" occurs when the report delay timer for the
group on the interface expires. It may occur only in the
Delaying Member state.
All other events, such as receiving invalid IGMP messages, or IGMP
messages other than Query or Report, are ignored in all states.
There are three possible actions that may be taken in response to the
above events:
- "send report" for the group on the interface.
- "start timer" for the group on the interface, using a random
delay value between 0 and D seconds.
- "stop timer" for the group on the interface.
In the following diagram, each state transition arc is labelled with
the event that causes the transition, and, in parentheses, any
actions taken during the transition.
________________
| |
| |
| |
| |
--------->| Non-Member |<---------
| | | |
| | | |
| | | |
| |________________| |
| | |
| leave group | join group | leave group
| (stop timer) |(send report, |
| | start timer) |
________|________ | ________|________
| |<--------- | |
| | | |
| |<-------------------| |
| | query received | |
| Delaying Member | (start timer) | Idle Member |
| |------------------->| |
| | report received | |
| | (stop timer) | |
|_________________|------------------->|_________________|
timer expired
(send report)
The all-hosts group (address 224.0.0.1) is handled as a special case.
The host starts in Idle Member state for that group on every
interface, never transitions to another state, and never sends a
report for that group.
8.3. Protocol Parameters
The maximum report delay, D, is 10 seconds.
