IGMP (Internet Group Management Protocol)

Since the great success of streaming services such as Netflix and Spotify, IP multicasting has become an indispensable transmission method for the internet. This technical procedure enables the sender to send data streams to entire receiver groups, enabling them to make optimum use of transport and routing capacities. Without this transmission method, the sender would have to send separate data packets to each receiving device, which would require enormous bandwidth and would quickly lead to an overload. This would make it practically impossible to keep the service permanently available.

The Internet Group Management Protocol (IGMP) is a protocol that plays an important role in the organisation of these multicast receiver groups in IPv4 networks.

The Internet Group Management Protocol is a TCP/IP family communication protocol developed at Stanford University and first specified in 1989 in RFC 1112. The first protocol version IGMPv1 was followed by the revised versions IGMPv2 (RFC 2236) and IGMPv3 (RFC 3376; RFC 4604). The versions are always backward compatible, which means that an IGMPv3 device automatically supports versions 1 and 2. The Internet Group Management Protocol is exclusively responsible for IPv4 networks – in IPv6 networks, the similar Multicast Listener Discovery (MLD) takes over its function.

The basic task of IGMP is to manage dynamic groups for IP multicast transmissions, whereby this management doesn’t run via the sending device itself, but via the integrated routers. On the one hand, these receive requests for inclusion in a specific multicast group from the receiver devices (or from the respective subordinate router). On the other hand, they forward IGMP messages to the appropriate parent router when they receive appropriate multicast data packets. The sending station doesn’t receive any information about which end stations and how many a sent packet reaches, since it only forwards a single data packet to its superordinate router.

It has already been mentioned that group administration via IGMP is not the responsibility of the package sender. However, as with all other stations on the network (including the receiver) involved, this output host must support multicast connections. Receiving client requests for inclusion in a specific multicast group and notifying clients in the event of incoming multicast data streams is handled by the individual network routers on the path between the sender and receiver.

For this purpose, the Internet Group Management Protocol offers functions that a station can use to inform the router assigned to it that it is to be included in a multicast group. On the other hand, it enables the routers to remember outgoing interfaces of those receiver devices that are to receive certain IP multicast data streams to be able to send specific reports as soon as corresponding data is received. Multicast groups are characterised by their specific addresses from the 224.0.0x range. In most cases, the first point of contact for a device is the home internet router, which receives the membership application and forwards it to the next network node, typically the internet service provider’s router. This communication chain ends with the router of the data stream transmitter, which in turn duplicates the IP packet if required, if it has several outgoing interfaces to serve.

The three published versions of the Internet Group Management Protocols have a lot in common. IGMPv2 and IGMPv3 extended the predecessor primarily by functions, while the basic features like the group address for general requests (0.0.0.0) were kept unchanged. But what do the respective extensions look like in detail?

The IGMP header has a total length of 64 bits. The first 8 bits always specify the protocol version IGMPv1 and the type of message. There are two options for the field (type): “1” (for membership requests) and “2” (for notifications about multicast data streams). Bits 8 to 15 follow, but they have no function and only consist of zeros. The first 32-bit block ends with a checksum. If it is an IGMP notification package, the 32 bit-long group address will follow.

The original version of the protocol line itself does not specify which router should be used for multicast queries (regulated by the Multicast Routing Protocol).

The header line starts similarly to the first log version, but without specifying the version number. The possible type codes are “0x11” (for requests), “0x16” (for notifications), and “0x17” (for leave messages). For backwards compatibility, there is also the code “0x12” for IGMPv1 notifications. Bits 8 to 15 receive a concrete function in IGMPv2 – at least for membership requests – and define the maximum response time allowed. This is followed by the checksum (16 bits) and the group address (32 bits), which in turn has the protocol-typical form 0.0.0.0 for general requests.

IGMPv2 specifies the rule that the router with the lowest IP address in the subnet is used for multicast queries.

The first two 32-bit sequences are identical to those of the IGMPv2 header – type, maximum response time, checksum, and group address. IGMPv3 also offers the possibility of exchanging with older protocol versions: the codes “0x12” for version 1 and “0x16” for version 2 are available to the hosts for this purpose. After the group address, the IGMPv3 query-specific header part starts, the first 32 bits of which are composed as follows:

• Res.: reserved 4-bit field that has no functions and contains only zeros
• S (suppress router-side processing): S flag that sets the routers to “1” indicating that they should suppress normal updates when receiving a request (if the value is “0” the field is inactive)
• QRV (Querier’s Robustness Variable): 3 bit, which can contain the “robustness variable” value used by requesting hosts
• QQIC (Querier’s Query Interval Code): 8-bit field used to specify the interval for IGMPV3 queries
• Number of source addresses: the amount of source addresses listed below

This very specific information is followed by the source address or a list of the individual source addresses (32 bits each), if several sources are to be defined.

Unlike its predecessor, IGMPv3 allows a host to join one group and leave another in a single transaction – IGMPv2 still requires two separate messages.

The role of IGMP is clearly defined: The communication protocol is always used where multicast transmissions are required in IPv4 networks such as the internet. Classic deployment scenarios are real-time applications that run over multipoint connections – such as web conferencing tools or live streaming services. Not every client should have to be supplied with the required data stream individually, as this would quickly lead the output server and network nodes to overload.