The IGMP Protocol

The Internet Group Management protocol, IGMP version 2

[RFC 2236], operates between a host and its directly attached router
(informally, think of the directly-attached router as the "first-hop" router that
a host would see on a path to any other host outside its own local network,
or the "last-hop" router on any path to that host), as shown in Figure 4.8-3.
Figure 4.8-3 shows three first-hop multicast routers, each connected to its
attached hosts via one outgoing local interface. This local interface is
attached to a LAN in this example, and while each LAN has multiple
attached hosts, at most a few of these hosts will typically belong to a given
multicast group at any given time.
IGMP provides the means for a host to inform its attached router that
an application running on the host wants to join a specific multicast group.
Given that the scope of IGMP interaction is limited to a host and its attached
router, another protocol is clearly required to coordinate the multicast routers
(including the attached routers) throughout the Internet, so that multicast
datagrams are routed to their final destinations. This latter functionality is
accomplished by the network layer multicast routing algorithms such as
PIM, DVMRP, MOSFP and BGP. Network layer multicast in the Internet
thus consists of two complementary components: IGMP and multicast
routing protocols.

Diagram 1

Although IGMP is referred to as a "group membership protocol,"

the term is a bit misleading since IGMP operates locally, between a host and
an attached router. Despite its name, IGMP is not a protocol that operates
among all the hosts that have joined a multicast group, hosts that may be
spread around the world. Indeed, there is no network-layer multicast group
membership protocols that operates among all the Internet hosts in a group.
There is no protocol, for example, that allows a host to determine the
identities of all of the other hosts, network-wide, that have joined the
multicast group.

table

Diagram 2
 IGMP version 2 [Fenner 1997] has only three message types, as
shown in Table. A general membership_query messages sent by a
router to all hosts on an attached interface (e.g., to all hosts on a local area
network) to determine the set of all multicast groups that have been joined
by the hosts on that interface. A router can also determine if a specific
multicast group has been joined by hosts on an attached interface using a
specific membership_query. The specific query includes the multicast
address of the group being queried in the multicast group address field of the
IGMP membership_query message, as shown in Figure.

Hosts respond to a membership_query message with an IGMP

membership_report message, as illustrated in Figure .
Membership_report messages can also be generated by a host when
an application first joins a multicast group without waiting for a
membership_query message from the router . Membership_report
messages are received by the router, as well as all hosts on the
attached interface (e.g., in the case of a LAN). Each
membership_report contains the multicast address of a single group
that the responding host has joined. Note that an attached router doesn't
really care which hosts have joined a given multicast group or even how
many hosts on the same LAN have joined the same group. (In either case,
the router's work is the same - it must run a multicast routing protocol
together with other routers to ensure that it receives the multicast datagrams
for the appropriate multicast groups.) Since a router really only cares about
whether one or more of its attached hosts belong to a given multicast group,
it would ideally like to hear from only one of the attached hosts that belongs
to each group (why waste the effort to receive identical responses from
multiple hosts?). IGMP thus provides an explicit mechanism aimed at
decreasing the number of membership_report messages generated
when multiple attached hosts belong to the same multicast group.
Specifically, each membership_query message sent by a router
also includes a "maximum response time" value field, as shown in Figure.
After receiving a membership_query message and before sending a
membership_report message for a given multicast group, a host waits
a random amount of time between zero and the maximum response time
value. If the host observes a membership_report message from some
other attached host for that given multicast group, it suppresses (discards) its
own pending membership_report message, since the host now knows
that the attached router already knows that one or more hosts are joined to
that multicast group. This form of feedback suppression is thus a
performance optimization -- it avoids the transmission of unnecessary
membership_report messages. Similar feedback suppression
mechanisms have been used in a number of Internet protocols, including
reliable multicast transport protocols [Floyd 1997].

The final type of IGMP message is the leave_group message.

Interestingly, this message is optional! But if it is optional, how does a
router detect that there are no longer any hosts on an attached interface that
are joined to a given multicast group? The answer to this question lies in the
use of the IGMP membership_query message. The router infers that no
hosts are joined to a given multicast group when no host responds to a
membership_query message with the given group address. This
is an example of what is sometimes called soft state in an Internet protocol.
In a soft state protocol, the state (in this case of IGMP, the fact that there are
hosts joined to a given multicast group) is removed via a timeout event (in
this case, via a periodic membership_query message from the router) if
it is not explicitly refreshed (in this case, by a membership_report
message from an attached host). It has been argued that soft-state protocols
result in simpler control than hard-state protocols, which not only require
state to be explicitly added and removed, but also require mechanisms to
recover from situation where the entity responsible for removing state has
terminated prematurely or failed [Sharma 1997]. An excellent discussion of
soft state can be found in [Raman 1999].

The IGMP message format is summarized in Figure 4.8-5. Like ICMP,

IGMP messages are carried (encapsulated) within an IP datagram, with an IP
protocol number of 2.

Diagram 3

Having examined the protocol for joining and leaving multicast groups we
are now in a better position to reflect on the current Internet multicast
service model, which is based on the work of Steve Deering [RFC 1112,
Deering 1991]. In this multicast service model, any host can "join" a
multicast group at the network layer. A host simply issues a
membership_report IGMP message to its attached router. That router,
working in concert with other Internet routers, will soon begin delivering
multicast datagrams to the host. Joining a multicast group is thus receiver-
driven. A sender need not be concerned with explicitly adding receivers to
the multicast group (as is the case with multicast in ATM) but neither can it
control who joins the group and therefore receives datagrams sent to that
group. Indeed, recall that it is not possible at the network layer to even know
which hosts, network-wide, have joined a multicast group. Similarly, there is
no control over who sends to the multicast group. Datagrams sent by
different hosts can be arbitrarily interleaved at the various receivers (with
different interleaving possible at different receivers). A malicious sender can
inject datagrams into the multicast group datagram flow. Even with benign
senders, since there is no network layer coordination of the use of multicast
addresses, it is possible that two different multicast groups will choose to
use the same multicast address. From a multicast application viewpoint, this
will result in interleaved extraneous multicast traffic.

These problems may seem to be insurmountable drawbacks for

developing multicast applications. All is not lost, however. Although the
network layer does not provide for filtering, ordering, or privacy of
multicast datagrams, these mechanisms can all be implemented at the
application layer. There is also ongoing work aimed at adding some of this
functionality into the network layer [Cain 1999]. In many ways, the current
Internet multicast service model reflects the same philosophy as the Internet
unicast service model -- an extremely simple network layer with additional
functionality being provided in the upper layer protocols in the hosts of the
"edges" of the network. This philosophy has been unquestionably successful
for the unicast case; whether the minimalist network layer philosophy will
be equally successful for the multicast service model still remains an open
question.