IGMP (Internet Group Man­age­ment Protocol)

Since the great success of streaming services such as Netflix and Spotify, IP mul­ti­cas­t­ing has become an in­dis­pens­able trans­mis­sion 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 ca­pac­i­ties. Without this trans­mis­sion 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 prac­ti­cal­ly im­pos­si­ble to keep the service per­ma­nent­ly available.

The Internet Group Man­age­ment Protocol (IGMP) is a protocol that plays an important role in the or­ga­ni­za­tion of these multicast receiver groups in IPv4 networks.

The Internet Group Man­age­ment Protocol is a TCP/IP family com­mu­ni­ca­tion protocol developed at Stanford Uni­ver­si­ty 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 com­pat­i­ble, which means that an IGMPv3 device au­to­mat­i­cal­ly supports versions 1 and 2. The Internet Group Man­age­ment Protocol is ex­clu­sive­ly re­spon­si­ble 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 trans­mis­sions, whereby this man­age­ment doesn’t run via the sending device itself, but via the in­te­grat­ed routers. On the one hand, these receive requests for inclusion in a specific multicast group from the receiver devices (or from the re­spec­tive sub­or­di­nate router). On the other hand, they forward IGMP messages to the ap­pro­pri­ate parent router when they receive ap­pro­pri­ate multicast data packets. The sending station doesn’t receive any in­for­ma­tion about which end stations and how many a sent packet reaches, since it only forwards a single data packet to its su­per­or­di­nate router.

It has already been mentioned that group ad­min­is­tra­tion via IGMP is not the re­spon­si­bil­i­ty of the package sender. However, as with all other stations on the network (including the receiver) involved, this output host must support multicast con­nec­tions. 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 in­di­vid­ual network routers on the path between the sender and receiver.

For this purpose, the Internet Group Man­age­ment 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 in­ter­faces of those receiver devices that are to receive certain IP multicast data streams to be able to send specific reports as soon as cor­re­spond­ing data is received. Multicast groups are char­ac­ter­ized 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 mem­ber­ship ap­pli­ca­tion and forwards it to the next network node, typically the internet service provider’s router. This com­mu­ni­ca­tion chain ends with the router of the data stream trans­mit­ter, which in turn du­pli­cates the IP packet if required, if it has several outgoing in­ter­faces to serve.

The three published versions of the Internet Group Man­age­ment Protocols have a lot in common. IGMPv2 and IGMPv3 extended the pre­de­ces­sor 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 re­spec­tive ex­ten­sions 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 mem­ber­ship requests) and “2” (for no­ti­fi­ca­tions 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 no­ti­fi­ca­tion 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 spec­i­fy­ing the version number. The possible type codes are “0x11” (for requests), “0x16” (for no­ti­fi­ca­tions), and “0x17” (for leave messages). For backwards com­pat­i­bil­i­ty, there is also the code “0x12” for IGMPv1 no­ti­fi­ca­tions. Bits 8 to 15 receive a concrete function in IGMPv2 – at least for mem­ber­ship 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 pos­si­bil­i­ty of ex­chang­ing 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 pro­cess­ing): S flag that sets the routers to “1” in­di­cat­ing that they should suppress normal updates when receiving a request (if the value is “0” the field is inactive)
• QRV (Querier’s Ro­bust­ness Variable): 3 bit, which can contain the “ro­bust­ness variable” value used by re­quest­ing 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 in­for­ma­tion is followed by the source address or a list of the in­di­vid­ual source addresses (32 bits each), if several sources are to be defined.

Unlike its pre­de­ces­sor, IGMPv3 allows a host to join one group and leave another in a single trans­ac­tion – IGMPv2 still requires two separate messages.

The role of IGMP is clearly defined: The com­mu­ni­ca­tion protocol is always used where multicast trans­mis­sions are required in IPv4 networks such as the internet. Classic de­ploy­ment scenarios are real-time ap­pli­ca­tions that run over mul­ti­point con­nec­tions – such as web con­fer­enc­ing tools or live streaming services. Not every client should have to be supplied with the required data stream in­di­vid­u­al­ly, as this would quickly lead the output server and network nodes to overload.