Internet Group Management Protocol
Multicast packets from remote sources must be relayed by routers, which should only forward them onto the local network if there is a recipient for the multicast host group on the LAN. The Internet Group Management Protocol is the multicast protocol that is used by mutlicast routers to learn the existance of host group members on their direcly attatached subnets. It relies on Class D IP addreses for the creation of multicast groups. It dynamically registers individual hosts in a multicast group with a Class D address.
Hosts identify their membership by sending IGMP messges, and traffic is sent to all members in that group. Routers listen for IGMP messages and periodically sends out hardware (data link layer) IGMP Host Membership Query to all IP end nodes on its LAN to discover which groups are active or inactive in a particular network. This query is send to the all-hosts group (network address 224.0.0.1) and TTL 1 and each host sends back one IGMP HOst Membership Rerport message per host group, sent to the group address.
IGMP loosely resembles ICMP and is implemented over IP. IGMP messages are encapsulated in IP datagrams and has two kinds of packets, Host Membership Query and Host Membershipi Report, both with the same fixed format containing some control information in the first word o the payload field and a class D address in the second work:
Routers communicate with each other by sending IGMP updates that are used by multicast routing protocols to communicate hosts group memberships to neighbouring routers, propagating group information through the internetwork. IGMP is used to identify a designated router in the LAN for this purpose. The bandwidth needed to tranmit host group information is usually slight compared to the mulicast application traffic, so this propagation method is workable. More sophisticated methods enable routers to detemine dynacially how to best forward the multicast application traffic. (See IP Routing).
IGMP version 2 is an extension of IGMP and consists of the following IGMP messages,
- Membership Query
- Version 1 Membership Report
- Version 2 Membership Report
- Leave Group
IGMP Version 2 basically works the same as Version 1. The main difference is that there is a Leave Group message that allow hosts to actively communicate with the local multicast router to leave the multicast group. The router then sends out a group specific query and determines if there are any remaining hosts interested in receiving the traffic. If there are no replies, the router will time out the group and stop forwarding the traffic. This can greatly reduce the elave latency compared to IGMP version 1. Unwanted and unnecessary traffic can be stopped sooner, hence reducing used bandwidth.
This following is a summary of RFC 2236 (IGMP v2)
IGMP is used by IP hosts to report their multicast group memberships to mutlicast routers that are immediately neighbouring the host. For level 2 hosts, it is considered to be implemented within the IP module.
This extract does not discribe IGMP between routers, but it is however possible.
Similar to ICMP, IGMP is integral to IP and is required to be implemented on all hosts that wish to participate on multicasts. IGMP messages are encapsulated in IP datagrams, with a IP protocol number of 2. IGMP messages have the following format:
Type
There are three types of IGMP messages that are important to host-router interaction:
| Message | Type | Description |
| 0x11 | Membership Query |
There are 2 subtypes. 1) General query, used to learn which groups have members on an attatched network 2) Group-Specific query, used to learn if a particular group has any members on the attatched network. |
| 0x16 | Version 2 Membership Report | |
| 0x17 | Leave Group | |
| 0x12 | Version 1 Membership Report | Used for back-wards compatibility with IGMPv1. |
Unrecognised message types should be silently ignored.
Max Repoonse Type
This field is only meaningful in Membership query messages. It specifies the maximum allowed time before sending a responding report in units of 1/10th of second. In other messages, this should be set to zero by the sender and ignored by receivers.
Varying this settings allows IGMPv2 routers to tune the 'leave latency' (time between the alst host leaving a group and the time it takes for the routing protocol to be notified that there are no more members). This also allows tuning of the burstiness of IGMP traffic.
Checksum
16-bit one's complement of the one's complement sum of the whole IGMP message (entire IP payload). When transmitting packets, the checksum must be computerd from and inserted into the checksum field.
When receiving packets, the checksum must be verfied before processing the packet.
Group Address
In Membership query messages, the gourp address field is set to zero when sending a General Query. Is is then set to the group address being queried when sending a Group-Specific Query.
In a Membership Report or Leave Group message, the group address field holds the IP multicast group of the gorup being reported or left.
Other
IGMP messages may not be longer than 8 octects. As long as the Type field is one that is recognised, IGMPv2 must ignore anything past the first 8 octects while processing the packet. Note that the IGMP checksum is always computed over the whole IP payload, not just the IGMP header.
Protocol Description
Multicast routers use IGMP to learn which groups have members on each of their attatched physical networks. Each multicast routers keeps a list of multicast group memberships for each of these attatched network with a timer for each membership.
Multicast Group Membership refers the to the presense of at least one member of a multicast group on a given attached network, NOT a list of all its members.
One each attatched network, a multicast router may assume of of two roles,
1) Querier
2) Non-Querier
There is normally only one querier per physical network. All multicast routers start up as a querier on each attached network. If a multicast router hears query message from a router with a lower IP address it must become a non-querier on that network.
If a router has not heard a query message from another router for [other querier present interval], it resumes the role of a querier. Routers periodically [query interval] sends a General Query on each attached network for which this router is the Querier to get membership information.
On startup, a router should send [startup query count] General Query spaced closely together [startup query interval] in order to quickly and reliable determine the membership information. This query is addressed to the all-systems multicast group (x.0.0.1), has a Group Address of field of 0 and has a Max Response Time of [Query Response Interval].
| Host receiving a General Query |
A host sets delay times for each group (excluding the all systems group) of which it is a member on the interface from which it receives the query. Each timer is set to a random value in the range (0, Max Response Time) with the Max Response time in the Query packet. When a host receives a Group-Specific query, it also sets a delay time randomly in the range (0, Max Response Time). If a timer for the group is already running, it is reset to that random value only if the requested Max Reponse Time is less than the remaining value of the running timer. When a group's timer expires, the host multicasts a Version 2 membership report to the group, with IP TTL of 1. If the host receives another host's report (version 1 or 2), while a timer is running, it stops its timer for the specified group and does not send a report. |
| Routers Receiving a report | When a router receives a Report, it adds the group being reported to the list of multicast gorup memberships on the network from which it receives the report. A timer is set for the membership to the [Group Membership Interval]. Repeated reports refresh the timer. Should no reporst be received, the router assumes that the gorup has no local members and that it need not forward remotely-originated multicasts for that group onto the attached network. |
| Host joins a multicast group | Hosts should immediately transmit a unsolicited Version 2 Membership Report for the group (in case it is the first member in that group). To cover the possibility of the Membership report being lost or damaged, the report should be transmitted once or twice after a short delay [unsolicited report interval]. |
| Host leaves a multicast group |
If it is 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 (x.0.0.2). If it is not the last, it may send nothing as there must be another member on the subnet. Routers should accept a 'leave group' message addressed to the group being left, in order to accomodate implementations of an earlier version of IGMPv2. 'Leave group' messages are addressed to the all-routers group because other group members have no need to know that a host has left the group - it does not harm to address the message to the group. |
| Querier receives a 'leave group' message |
(for the group that has gourp members on the reception interface), it sends [last member query count] Group-Specific queries every [last member query interval] to the gourp being left. These queries have their Max Response Time set to [last member query interval]. If no reports are received after the response time of the last query expires, the routers assume that he group has no local members. Any Querier to non-Querier transition is ignored during this time - the same reouter keeps sending the Group-Speicific queries. 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. When a non-Querier receives a Group-Specific Query message, if its existing gorup membership timer is greater than [last member query count] times the max response time specified in message, it sets its group membership timers to that value. |
Compatibility with IGMPv1 Routers
IGMPv2 hosts may be placed on a subnet wher the Querier router not IGMPv2. This requires that,
| 1) | IGMPv1 router will send Genery Queries with the Max Response Time=0. This must be interpreted as 100 (10sec) |
| 2) | IGMPv1 will only pay attention to IGMPv1 membership reports and hence a state variable must be kept for each interface. This should describe whether the multicast querier on that interface is IGMP v1 or v2. This should be set according to whether or not a IGMPv1 query was heard in the last [Version 1 Router Present Timeout] seconds and NOT on the type of last query heard. This wil be used to decide the type of Membership reports to send for unsolicited membership reports as well as membership reports in response to a query. |
| 3) | IGMPv2 host may suppress leave group messages on a network where the querier on a network is IGMPv1. |
IGMPv2 routers may be place on a subnet where at least one router on the subnet is not IGMPv2. This requires that,
| 1) |
If IGMPv1 routers are present, IGMPv1 must be used by the querier. This must be administratively configured as there is no reliable way of determine the types of routers. In the absense of adminstation, routers must default to IGMPv2. When in IGMPv1 mode, routers must send periodic queries with max repsonse time of 0, and must ignore leave group messages. They should also warn about receiving IGMPv2 queries. |
| 2) | If a router is not explicity configured to use IGMPv1 and hears a IGMPv1 qeury, it hsould log a warning. |
Compatibility with IGMPv1 Hosts
A IGMPv2 host may be placed on a subnet with IGMPv1 hosts as long as the following applies,
| 1) | The host must allow its membership report to be suppressed by either a version 1 or version 2 membership report. |
An IGMPv2 router may be placed on a subet where not all hosts are IGMPv2 as long as,
| 1) |
If a router receives a version 1 membership report, it must set a timer to note that here are version 1 hosts present in that group. This timer should be the same as [Group Membership Interval]. |
| 2) | If there are version 1 hosts present in a particular group, a router must ignore any leave group messages received for that group. |
Host State Diagram
Host behaviour is formally specified in the host state transition digram below. A host may be in one of three possible states with respect to any single IP multicast gorup on any single network interface.
| State | Description |
| Non-Member | The host does not beling to the group on the interface. Initial state for all memberships on all network interfaces. No storage on host required. |
| Delaying Member | Host belongs to the group on the interface and has a report delay timer running for that membership. |
| Idle Member | Host belongs to the group on the interface and does not have a report delay timer running for that membership. |
And there are 5 significant events that can cause IGMP state transitions,
| Event | Description |
| Joing Group | Happens when hosts decide to join the group on the interface. May only occur if the host is in the Non-Member state. |
| Leave Group | Occurs when the host decides to leave the group on the interface. Only happens when in the delaying member state and Idle member states. |
| Query Receive |
Happens when the host receives either a valid General Membership Query message or a valid Group-Specific Membership Query message. In order to be valid, the Query message must be at least 8 octets long, and have the correct IGMP checksum. The group address must be either a zero (General Query) or a valid multicast group address (Group-Specific Query). A General Query applies to all memberships on the inreface from which the query was received. Whilst a Group-Specific Query applies to membership in a single group on the interface from which the Query is received. Should queries be received in a Non-Member state, it is ignored. |
| Report Received |
Happens when the host receives a valid IGMP Membership Report message (v1 or v2). Again, to be valid, the message must be at least 8 octets long and have the correct IGMP checksum. A Membership report only applies to the membershpi in the group identified by the Membership report, on the interface from which it is received. It is ignored for memberships in the non-member or idle idlem states. |
| Timer Expired | Happesn when the report dealy timer for the group on the interface expires. Only occurs in the delaying member state. |
All other events (receiving incorect IGMP messages or IGMP messages other than Query or Report) are ignored in all states.
There are 7 possible actions that may be taken in response to the 5 events above.
| Action | Description |
| Send Report | (for the group on that interface). The type of report is determined by the type of interface. The report message is sent to the group being reported. |
| Send Leave | (for the group on the interface). If the interface state says the Querier is runnign IGMPv1, this action should be skipped. If the flag saying we were the last host to report is cleared, this action may be skipped. The leave message is sent to the all-routers group (x.0.0.2). |
| Set Flag | That we were teh last host to send a report for theis group. |
| Clear Flag | Since we were not the last host to send a report for this group. |
| Start Timer |
(for the group on that interface). Use a delay value chosen uniformly from the interval (0, Max Response Time) - where the latter is specified in the query. If it is an unsolicited report, the timer is set to a delay chosen uniformly in the range (0, [Unsolicited report interval]). |
| Reset Timer | (for the group on the interface) reset the timer to a new value, using a delay value chosen uniformly in the interval (o, max response time). |
| Stop Timer | For the group on the interface. |
Example
________________
| |
| |
| |
| |
--------->| Non-Member |<---------
| | | |
| | | |
| | | |
| |________________| |
| | |
| leave group | join group | leave group
| (stop timer, | (send report, | (send leave
| send leave if | set flag, | if flag set)
| flag set) | start timer) |
________|________ | ________|________
| |<--------- | |
| | | |
| |<-------------------| |
| | query received | |
| Delaying Member | (start timer) | Idle Member |
---->| |------------------->| |
| | | report received | |
| | | (stop timer, | |
| | | clear flag) | |
| |_________________|------------------->|_________________|
| | timer expired
| query received | (send report,
| (reset timer if | set flag)
| Max Resp Time |
| < current timer)|
| |
-------------------
|
In the all-systems group (address x.0.0.1) us 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 ends a report for that group.
In addition, a host may be in one of two possible states with respect to any single network interface,
| State | Description |
| No IGMPv1 Router Present | When the host has not heard an IGMPv1 style query for the [Version 1 Router Present Timeout]. This is the initial state. |
| IGMPv1 Router Present | When the host has heard an IGMPv1 style query within the [Version 1 Router Present Timeout]. |
And with these, there are two events that can cause state transitions,
| State | Description |
| IGMPv1 Query Received | When the host receives a query with the Max Response Time field - 0. |
| Timer Expires | When the timer set to note teh presense of an IGMPv1 router expires. |
With a single action that can be triggered by an event,
| Action | Description |
| Set Timer | Set the timer to its maximum value [Version 1 Router Present Timeout] and (re)starting it. |
Example
________________
| |
| |
| No IGMPv1 |
| Router |
| Present |
| |
---->| |----
| | | |
| |________________| |
timer expires | | IGMPv1 query
| ________________ | received
| | | | (set timer)
| | | |
| | | |
-----| IGMPv1 |<---
| Router |
| Present |
| |
---->| |----
| |________________| |
| |
| IGMPv1 query received |
| (set timer) |
---------------------------
|
| Sun, 21 October, 2001 18:43 |   |
Room D14, High Energy Particle Physics, Dept. of Physics & Astronomy, UCL, Gower St, London, WC1E 6BT
