| The Internet Group Management Protocol (IGMP) is used to manage group memberships in local area networks. A multicast router should know all groups having members in the local area network. Accordingly, the Multicast Routing Protocol subscribes packets for these groups. The router does not have to know exactly who in the local area network belongs to a group. It is sufficient for the router to know that there is at least one receiver. The reason is that, when the router transports a packet to the local area network, all stations subscribed to this group receive it automatically. To avoid unnecessary data transmissions, the router checks periodically for multicast groups that are still desired. For this purpose, it sends a membership query to all local computers (i.e., to the all-hosts group) within a specific time interval (approximately every two minutes). Each computer currently interested in a group should then return a reply for each of its groups to the router. As was mentioned earlier, the router is not interested in knowing who exactly is a member of a group; it is interested only in knowing whether there is at least one member in the LAN. For this reason, and to prevent all computers from replying at the same time, each computer specifies a random delay time, and it will reply when this time expires. The first computer to reply sends its message to the router and to all other local computers of the specified group. Cleverly, it uses the multicast group address for this message. This means that the other computers learn that the router has been informed, so that they don't have to reply. The router has to continue forwarding data for this group from the Internet to the local area network. Naturally, if a computer wants to join a group, it does not have to wait for a membership query; it can inform the router immediately about the group it wants to join. Section 17.3.3 describes how exactly the IGMP protocol works. In addition to the tasks discussed above, IGMP is used for other things. The following list summarizes everything the IGMP is used for: Query a multicast router for groups desired in a LAN. Join and leave a multicast group. Exchange membership information with neighboring or higher-layer multicast routers.
17.3.1 Formatting and Transporting IGMP Packets IGMP messages are transported in the payload field of IP packets, and the number 2 in the Protocol field of the IP packet header identifies them as IGMP messages. They are always sent with the TTL value one, which means that they cannot leave the area of a subnetwork and so means that IGMP manages group memberships only within a subnetwork. To distribute this information beyond these limits, we have to use multicast routing protocols. Figure 17-5 shows the format of IGMP packets; it includes the following fields: Version: Number of the IGMP version used. Type: Type of the IGMP message. Max. Response Time: This field is used differently, depending on the IGMP version. (See Section 17.3.2.) Checksum: Checksum of the IGMP message.
Figure 17-5. The IGMP packet format and its representation in the Linux kernel. 
The information in an IGMP packet is managed internally by the igmphdr structure in the Linux kernel. Consequently, it corresponds to an IGMP packet, also shown in Figure 17-5. 17.3.2 Different Versions The Internet Group Management Protocol comes in three different versions: IGMPv0, IGMPv1, and IGMPv2. The first version (IGMPv0) is outdated [Deer86] and no longer used, so we won't discuss it here. The successor version (IGMPv1) is specified in RFC 1112 and fully implemented in the Linux kernel. This version defines two protocol messages, which can be distinguished by the contents of the Type field: The field Max. Response Time is set to null in this IGMP version when a packet is sent, and it is ignored by the receiver. Version 2 of the Internet Group Management Protocol was specified in [Fenn97]. In this version, the field Type can take any of four values, and the field Max. Response Time plays a more important role. 0x11: Query sent by a router (IGMP_HOST_MEMBERSHIP_QUERY) 0x12: Reply sent by an end system (IGMP_HOST_MEMBERSHIP_REPORT) 0x16: Reply of type 2 (IGMP_HOST_NEW_MEMBERSHIP_REPORT) 0x17: Request to leave a group (IGMP_HOST_LEAVE_MESSAGE)
The value in the field Max. Response Time is specified in tenth-second units. It specifies an interval within which a computer may not send a reply. Once this interval has expired, a reply is sent after a random time. 17.3.3 Operation of the IGMP Protocol Now that we explained how an IGMP message is structured and how it is transmitted, this section will discuss group management, including the differences between IGMPv1 and IGMPv2. Multicast routers send group membership queries (IGMP_HOST_MEMBERSHIP_QUERY) to the all-hosts group members with group address 224.0.0.1 periodically, at an interval of a few minutes (125 seconds is recommended). Each multicast-capable computer is a member of this group, so all multicast systems receive these queries. (See Figure 17-6.) Figure 17-6. A multicast router sends a membership query to all multicast computers in the local area network (224.0.0.1). 
Notice that, in these queries, the router sets the TTL value to 1 to ensure that its query packets travel only within the local area network. Next, each computer belonging to one or more multicast groups starts a timer with a random value for each group. (See Figure 17-7.) Figure 17-7. Membership report of a group by the participant with the smallest timer value in that group. 
Next, as soon as the timer for one of these groups in one computer expires, this computer sends, a report (IGMP_HOST_MEMBERSHIP_REPORT) addressed to the multicast group. In addition, the value of the TTL field is set to one in this case. All members of the group receive this report and stop their timers. The effect is that only one computer sends a report, and thus a flood of reports is prevented. The router also receives the report. This reply is sufficient for the router to learn that at least one computer interested in receiving group data is in its local area network. Consequently, the router will subscribe packets of this group via the multicast routing protocol and forward them in the LAN. If the router does not receive reports for a specific group over a certain period of time, it assumes that there are no more interested computers, and deletes this group from its list. If a computer wants to join a group, it can explicitly request this in IGMPv2 by sending a New Membership Report packet. In older protocols, the computer may have had to wait a few minutes until the router sends a query message. When IGMPv2 routers send their queries, they write a specific value to the Max Resp Time field. A value larger than null tells the computers that this is an IGMPv2 router. This means that IGMPv2 computers can send version-2 reports (IGMP_HOST_NEW_MEMBERSHIP_REPORT). In addition, IGMPv2-enabled computers can leave a specific group by sending an IGMP_HOST_LEAVE_MESSAGE to the all-routers group. The group to be left is identified in the group address field. Early notification of a station to leave a group can help to reduce the load in the local area network. However, each group member's request to leave a group are sent to the local area network not when it is no longer interested in this data, but only if the group member was the reporter the computer that originally sent the membership report for that group. This approach avoids a large number of Leave packets. If the reporter was the only group member, then the router can stop delivering packets of this group in any event. If there are members other than the reporter in the local area network, then these members can react to a Leave message immediately by sending a report to the router telling it that there is still an interest in this data. A conflict can arise if there is more than one multicast-capable router in one local area network. In such a situation, two routers could transport redundant multicast packets to the LAN. The question is: Who decides which router will serve which group? The problem is solved by a simple mechanism known from other protocols: The router with the smallest IP address assumes the role of a coordinator. The other routers just listen to the traffic until the coordinator fails. In this case, the router with the next smaller address assumes the role of the multicast router. A good indicator that a multicast router has failed occurs when no more group queries arrive. 17.3.4 Implementing IGMP This section describes how the Internet Group Management Protocol (IGMP) is implemented in the Linux kernel. Among other things, we will explain how entries for multicast groups are stored and how an IGMP query is handled in the kernel. We saw how a packet is handled in the Linux kernel in Figure 14-4, and we learned that a packet can travel over different paths. The processing of IGMP packets begins at the multiplex point of IP: the point where the mechanism branches to the handling routine of the respective layer-4 protocol. The further path that an IGMP packet takes (see Figure 17-8) will be explained in the section that describes the igmp_rcv() function. Figure 17-8. Implementing IGMP in the Linux kernel. 
igmp_rcv() | net/ipv4/igmp.c |
The starting point of the IP multicast control path is in igmp_rcv(). Once an IGMP packet has passed the lower layers and arrived in the IP layer, its protocol type is checked and the appropriate protocol-handling routine is invoked. For IGMP messages (protocol identifier 2), this is the function igmp_rcv(skb, len). The function involves the following steps: int igmp_rcv(struct sk_buff *skb, unsigned short len) { struct igmphdr *ih = skb->h.igmph; switch (ih->type) { case IGMP_HOST_MEMBERSHIP_QUERY: //0x11 igmp_heard_query(in_dev, in->code, ih->group); break; case IGMP_HOST_MEMBERSHIP_REPORT: //0x12 case IGMP_HOST_NEW_MEMBERSHIP_REPORT: //0x16 igmp_heard_report(in_dev, ih->group); break; case IGMP_HOST_LEAVE_MESSAGE: //0x17 break; ... }
In this function, the type of the IGMP packet is extracted, and, once the IGMP packet has been checked for correctness, the function branches to the corresponding routine. If the message type is IGMP_HOST_LEAVE_MESSAGE, then the packet is ignored in a simple computer. For queries arriving from a router, further handling of the message is started by igmp_heard_query(). If the message is a report from another system, then it is handled by igmp_heard_report(). All other packet types are ignored. igmp_heard_query() | net/ipv4/igmp.c |
The function igmp_heard_query is invoked for IGMP queries arriving from a router (IGMP_HOST_MEMBERSHIP_QUERY). In this case, the function walks through the list of all active IP multicast groups to which the computer with the network card that received the query belongs. This list is managed in the structure dev->ip_ptr->in_device->mc_list. Next, igmp_mod_timer is used to start a timer or update a running timer for every group except the all-hosts group. Notice that each computer belongs to the all-hosts group and that no timer is started for this group, for performance reasons. The requesting router assumes that, in addition to itself, at least one active multicast computer is connected to each local area network. igmp_heard_report() | net/ipv4/igmp.c |
If another computer responds to a query, it directs its reply to the appropriate group, and all other members of this group will receive this reply. The IGMP message type is either IGMP_HOST_MEMBERSHIP_REPORT or IGMP_HOST_NEW_MEMBERSHIP_REPORT, depending on the version used to send the message. As a response to an incoming query report, each other computer in the local area network can stop its timer for the group concerned. In the Linux kernel, this task is handled by igmp_heard_report. For this purpose, the list of active multicast groups of the network device that received the report is walked through. This list is managed in the structure dev->ip_ptr->in_device->mc_list. The timer of this group is stopped (igmp_stop_timer()), and the variable reporter records that this computer has not replied for this group (reporter = 0;). igmp_send_report() | net/ipv4/igmp.c |
Once a query message has been sent, a timer is started for each multicast group in each computer. The computer with the timer expiring first sends a query report. This is done by the function igmp_send_report, which was started by the timer handler (igmp_timer_expire()) for this group (timer in the ip_mc_list structure). In addition, the variable reporter in the function igmp_timer_expire() remembers that this station replied to the query. This information may be required later to tell the router that the computer wants to leave that group. However, igmp_send_report() serves not only to send query reports; it can also be used to generate packets to announce that a computer wants to leave a group (leave messages). The actions required are identical in both cases; only the destination address and the IGMP message type are different. In case of a report, the packet is sent to the corresponding group; in the case of a leave message, all multicast routers in the LAN (all-routers) are addressed. Notice that the value of the TTL field has to be set to 1 to ensure that the response will spread only within the LAN. Next, the IP packet is built, and the IGMP fields are set accordingly. Finally, the packet is shipped out over the LOCAL_OUT hook. ip_check_mc() | net/ipv4/igmp.c |
ip_check_mc(in_dev, mc_addr) is actually not part of the IGMP protocol; it is used for IP routing. More specifically, ip_check_mc() checks on whether the local computer is currently a member of the multicast group mc_addr. For this purpose, the list of active groups of the network device's IP instance (mc_list in the in_device structure) is checked and compared against the group address passed. If a match is found, then one is returned; otherwise, null is returned. ip_check_mc() is also used in the function ip_route_input() to learn whether the packet should be delivered locally. If this is the case (as is always true for multicast routers), then the packet is passed to ip_route_input_mc(). If the computer does not act as a multicast router, and if the packet does not belong to any group of the input network device, then it will be discarded. This actually means that rather few packets are discarded, because most undesired multicast packets are normally filtered out by the hardware filter in the network card. (See Section 17.4.1.) | 
