High Level Overview of IGMP

Welcome to episode 1 of the Multicast Class series. I decided to start this with how the Layer 2 part works, and then slowly build it up until we have the full picture. You will notice that I never covered the “why” of multicast. I felt this was too basic. If you have made it to this article, you probably understand why multicast is used on a network and do not need to be taught that. If you have no idea what multicast is, then i would start here.

The “opt-in” model.

In traditional networking, the sender is the “boss”. If a host a wants to talk to hosts b over the internet, it needs the specific IP address of the other hosts. This can be computer -> computer, computer -> web-server, web-server -> database, really anything with an IP address. The hosts will wrap the packet using enough information in the header where the network can take it and route it to it’s final destination. This is the basics of MOST of the traffic on the internet today.

In multicast environments, this is not really how it works. The sender (or source as we call it) sends all of it’s data to a “logical” destination. This destination is an IP address in the 224.0.0.0 to 239.255.255.255 range. The source does not care if it has 0 listeners or 100 listeners, it will continue sending packets to that destination IP address as long as it is configured to do so.

This stream of packets from the source to a non-host IP address creates a unique challenge. How do I, the multicast receiver, “join” that stream so I can see the video or hear the audio that is being streamed? That is a perfect segway into IGMP!

IGMP: The host-to-router handshake

IGMP, or the “Internet Group Management Protocol”, is the secret protocol that is used by hosts on their local network whenever they want to receive traffic from a certain multicast group. A quick example; imagine you and I were engineers on a network together and we stood up a server that streamed ESPN all day. Well, the users on the local network would want to watch too. During the time of this posting, it is Masters weekend. The hosts (or computers) would use IGMP to signal to the local router that they would like to join this multicast stream so that they can watch some golf!

IGMP is what is responsible for the conversation between the hosts and its local Gateway (or what we call the last-hop router). Wether you are using PIM-ASM or PIM-SSM (we will get into it later), there is a specific IGMP message version that is responsible for conveying the message of “I am host X and I am interested in joining group Y”.

As with (mostly) everything, the protocol has evolved over time. There is now three versions of IGMP, though version one is essentially obsolete. If you find a network or hosts running IGMPv1, please email me and send me a picture. We will discuss how version one worked just so that we can get the foundation of IGMP and then see how v2 and v3 improved upon it, but like I said it is not used really at all today.

Version 1

IGMPv1 is the first version of the IGMP protocol that allowed hosts on a network to communicate to the last-hop router that they want to join a specific multicast group. It uses only two messages, the membership report and the membership query.

The membership report is sent by a host when it wants to join a multicast group. The packet destination will be the group address that it wants to receive, not the last-hop router. When the router receives the report, it will eventually begin to forward multicast traffic back down the LAN interface that it received the IGMP membership report on.

sequenceDiagram
    participant Host
    participant Router
    Note over Host: 1. The Interest
    Host->>Router: Membership Report for 239.10.10.10
  

The membership query is sent by the last hop router to a destination of 224.0.0.1. This is the “all hosts” multicast group address that computers and other end devices are already pre-programmed to listen to in todays world. When a host receives this message, it will reply with a membership report notifying the router that it is still listening to multicast traffic. Once the router receives this report, it refreshes its expiry timer and repeats this cycle. In v1, this is how multicast traffic ends. The timer eventually expires and the router assumes no one else is interested in the traffic. This is very inefficient!

sequenceDiagram
    participant Host
    participant Router
    Note over Router: 1. Query
    Router->>Host: Membership Query on 224.0.0.1
    Note over Host: 2. Report
    Host->>Router: Membership Report for 239.10.10.10
    Note over Router: 3. Expiry timer refresh
  

Version 2

In IGMPv2, they added a new message type which makes our LAN side of the multicast traffic way more efficient. Hosts can now send an explicit leave message to the querier or last hop router. The leave group message is sent to the destination of 224.0.0.2, the all routers multicast group. Other key improvements include the Group-Specific query, where routers can query a specific multicast group instead of a generic query for all multicast traffic. And there also is included a configurable max response timer on the router. Below is a diagram of a host that is already receiving traffic for 239.10.10.10 and shows the new message types.

sequenceDiagram
    participant Host
    participant Router
    Note over Host: 1. Leave
    Host->>Router: Leave group 239.10.10.10, dest 224.0.0.2
    Note over Router: 2. Group Query
    Router->>Host: Group-Specific Query for 239.10.10.10, no one answers.
    Note over Router: 3. Prune the LAN interface from OIL after no response
  

If another host is still subscribed to our example address of 239.10.10.10, it would respond when the router sent the Query and the router would know not to prune that interface.

Version 3

Version 3 is the newest version of the IGMP protocol and was built to support Source-Specific Multicast. Hosts can now include the source in the membership report, where as before the host did not know of the source and was relying on the router to find it for them. The model of multicast that was running in our previous examples is called Any Source Multicast (ASM). What is also new is hosts now send their reports to 224.0.0.22, which is “IGMPv3 capable routers” address.

The Membership Reports include a list of source IP addresses. This is handled via two modes:

INCLUDE Mode: The host provides a list of specific source addresses it wants to receive traffic from.

EXCLUDE Mode: The host provides a list of sources it doesn't want to hear from (effectively blocking specific senders).

The leave packet is also slightly different in v3 where the leaving is actually handled through another Membership Report message to 224.0.0.22. The host sends a report with a record type of “TO_IN(0)” which means “my new list of included sources for the group is zero”.

sequenceDiagram
    participant Host
    participant Router
    Note over Host: 1. Join Group
    Host->>Router: Membership Report for 239.10.10.10, source 10.255.255.2, dest 224.0.0.22
    Note over Router: 2. Router Process
    Router->>Host: After PIM is complete, router forwards traffic onto the LAN.
    Note over Host: 3. Leave Group
    Host->>Router: Membership Report for 239.10.10.10, source 0, dest 224.0.0.22
    Note over Router: 4. Router Query
    Router->>Host: Group-and-Source-Specific Query to 239.10.10.10 with source 10.255.255.2.
    Note over Router: 5. No answer from host
    Note over Router: 6. Router Prunes
    Router->>Host: The router stops forwarding that traffic to the segment
  

By using 224.0.0.22, IGMPv3 allows Layer 2 switches (using IGMP Snooping which we cover next) to be much smarter. Because these reports contain more complex source information, the specialized multicast address helps the infrastructure differentiate v3 membership state changes from older v1/v2 control traffic.