IGMP Group and Group-and-Source Specific Query

Sometime back I decided to explain IGMP internals in multiple post. I started with an introduction and then covered General Query messages. This post explains the IGMP group and group-and-source specific query messages.

IGMP querier router sends out IGMP group specific query to check if there is any host interested in the specified group.

Similarly IGMP querier sends out IGMP group and source specific query to check if there is any host interested in receiving multicast traffic for the specified group and source combination.

In both the cases, if any host is still interested, it will respond with its current-state record.

Now let us use figure - 1 to discuss these operations in more details. We will discuss Group-and-Source specific query as Group specific query is pretty much same. Router R1 and R2 both are running IGMP on their interface connected to the LAN. Router R1 is elected as Querier. Router R1 is also the DR for the Multicast Routing Protocol so R1 will create multicast forwarding state.

Handling Join Message by Routers:

Let us assume that host PC-1 joins a channel (S,G), it sends an IGMPv3 join message. Router R1 receives this join message, creates local state and also creates multicast forwarding state for the channel. Router R2 also receives this join message and create local states for this channel.  As explained in here, this state is kept alive until host leaves this channel.

Now let us assume that another host PC-2 is also interested in (S,G), it sends an IGMPv3 join. Router R1 receives this join message and updates the local state information. Router R1 need not update the multicast forwarding state. Similarly router R2 also updates the local state. Please note routers usually just maintain the group, source and interface information and does not maintain which host had joined what channel.

Handling Leave Message by Routers:

After some time,  PC-1 sends a leave message for (S,G). Both Router R1 and R2 receives this leave message. As router R1 does not know how many hosts were interested in this channel, it sends out a Group-and-Source specific query. Why Group-and-Source specific query? That is because the leave has come for a specific Group and Source.

Router R1 will lower down the source timer to LMQI (Last Member Query Interval) for this source and group combination and send out a Group-and-Source specific query. This query is sent every LMQT (Last-Member-Query-Time) seconds for robustness count times (Let us assume robustness count for LAN interfaces is 2) irrespective of whether a host respond before the next query is sent.

Router R2 will do the state calculation based on RFC 3376 but will not lower down the source timer as it is not a querier.

Handling Query Message by Hosts and Routers:

Query sent by router R1 is received by hosts as well as other non-querier routers.

When Router R2 receives this query, it lowers down its own source timer to LMQI (Last Member Query Interval) for this channel (S,G).

Now PC-1 does not send any response while PC-2 starts an internal timer to send a response within Maximum-Response-Time as it still wants to receive traffic for this channel (S,G). Once the timer fires, PC-2 sends out a current state record for channel (S,G) (i.e. a message suggesting that PC-2 is still interested in receiving multicast traffic for channel (S,G)).

Handling Current State Record Message by Routers:

Router R1 receives this current state record and update the source timer for this channel (S,G).

Similarly, Router R2 receives this current state record and update the source timer for this channel (S,G).

Please note that during all these operations, multicast data was continuously forwarded on LAN.

Handling LMQT Timer Fires:

If you would recall, router R1 will need to resend this Group-and-Source specific query one more time. But now that Router R1 knows that PC-2 is still interested in receiving traffic for this channel (S,G), it sets the suppress router-side processing flag for this channel. So when the Group-and-Source specific query is sent out, Router R1 does not lower the source timer.

But how does router R1 communicates this to router R2 because as described above, as soon as Router R2 sees the Group-and-Source specific query, it will lower down its source timer.

Same suppress router-side processing flag is passed in the query message and router R2 does not lower its source timer for the channel (S,G) because this flag is set.

Some Home Work:

Am I kidding? No. If you want to learn something new, you must always do some home work.

I have described Group-and-Source specific query and Group specific query is exactly same. Please try to find out the differences between the two type of queries and post your findings in the comment section.

Summary:

In this blog post, we looked at IGMP Group and Group-and-Source specific queries. If you have any doubts on any specific part, please leave me a comment. In next blog post, I will explain IGMP Snooping and Proxying  in more detail.

An introduction to IGMP

Now that we know why do we need multicast and how multicast addressing works, let us look at how hosts/receivers indicate their interest in receiving contents for a given multicast group.

As described in my earlier post on multicast addressing, Applications/Servers uses a IP Multicast Address (Class D address) as the destination address in the IP data packet while sending out the contents.

Let me take a simple test. Please take a look at figure 1 below, what do you think who all will receive the multicast traffic sent by the Multicast Server?

Did you say 'all-of-them'? If yes, you got it wrong. None of them will receive the multicast traffic as they did not indicated their interest in receiving the multicast traffic.

So how do receivers indicate their interest? They use a simple protocol known as IGMP (Internet Group Management Protocol). IGMP has two parts. One part runs in the hosts (receivers) which is used to indicate host's interest while other part runs in routers which is used to collect the interests of all local hosts.  IGMP runs directly on top of IP protocol and so is unreliable in nature. Routers running IGMP sends queries and all hosts send their current multicast state in the form of IGMP reports.

In a LAN environment, when a host indicate its interest in a IP multicast address, its corresponding ethernet MAC gets configured in the NIC to receive multicast data traffic. So if you look back at figure-1 and if PC-1 has indiacated its interest in the group, only PC-1's NIC will be configured and so only PC-1 will receive the multicast traffic.

Let me give you a little run down on the two parts of IGMP.

Host part:

Host part, as the name suggest, runs in a host. When the host is interested in receiving traffic for a multicast group or a combination of group and source, it sends out an unsolicited IGMP membership report.

Host usually sends two memberrship report messages. This is to make sure that the routers receive at least one. Can you guess why is this done?

As I mentioned IGMP is unreliable and this is one of the simplest way to make sure that all routers receive at least one of the report. Now you will ask, what if both the reports are lost? I will say 'good thinking'. To just take care of such a scenario, this count, known as 'robustness count' can be configured. So if you think your network can loose two reports, configure this as three or so on. If you are increasing this count, you must know that there will be more control packets on the network.

Now let us assume that all unsolicited reports are lost, how will this work? It may not work till the next query comes in.  Once the next query comes, host will generate a solicited report which router can use to update its state.

Once host does not want to receive multicast traffic, it generates a leave.

When host receives a general query, it sends out solicited membership report with all the multicast groups it is interested in.

When host receives a group or group-source specific query, it sends out membership report with this group or group-source information.

Router part:

Router part, as the name suggest, runs in a router. All routers on a LAN elect one router as querier. This router sends general queries periodically.

All the routers on a LAN does querier election and once a querier is selected, only that router sends queries. The router with the lowest IP address is selected as the querier.

When routers receives the unsolicited membership report, it creates local forwarding state and refresh this state when solicited membership reports are received.

When routers receive leave message, it does not leave the group immediately, it first send group or group-and-source specific query and if no host is interested in this group or group-and-source, router removes the local state.

Usually IGMP is configured either in IGMP Proxy mode or along with a multicast routing protocol like PIM (i.e both IGMP router part and a multicast routing protocol is enabled). In case of IGMP proxy, there is usually one single upstream router. In case of multicast routing protocol, routing protocol defines which router should handle the locally connected host membership. For example: in PIM-SM, Designated Router (DR) or the Assert Winner takes care of local host memberships. Please look at figure-2 where router R1 acts as IGMP proxy while router R2 and R3 on LAN-2 are configured with PIM-SM. In LAN-2, router R2 is DR and so handles the IGMP joins sent by R1 on upstream interface.

Whats next:

I have explained the basic IGMP functionality here. I will cover some of the finer points of IGMP in other posts. Now that we understand how IGMP works, we will next look at IGMP proxying.

If you want me to explain any specific behaviour of IGMP, please do let me know.