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.

IGMP General Query message

My last post An introduction to igmp explained what IGMP is and how it works. I kept that post simple, small and easy to follow. I had decided to explain each IGMP part in greater details in separate posts. So with this post, we will look at IGMP General Query message. Let us use the latest version of IGMP (i.e IGMPv3) in this discussion. Also please note that all the values that are available as configuration are added in 'Italic'.

A router uses General Query to collect and update group membership information for the hosts.

General Query Message contents

General queries are sent to All-Host-Multicast IP Address (224.0.0.1). IP protocol field in the IP header is set to 2 (Protocol number for IGMP). A router-alert IP option is added just after the IP header. IGMP header contains following fields:

      0                   1                   2                   3
      0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |  Type = 0x11  | Max Resp Code |           Checksum            |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                         Group Address                         |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     | Resv  |S| QRV |     QQIC      |     Number of Sources (N)     |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                       Source Address [1]                      |
     +-                                                             -+
     |                       Source Address [2]                      |
     +-                              .                              -+
     .                               .                               .
     .                               .                               .
     +-                                                             -+
     |                       Source Address [N]                      |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

A router sets following fields in the IGMP header:

• Type is set to 0x11
• Max-response-code is calculated based on the configured value of 'maximum-response-time'.
• 'checksum' is calculated by initializing the checksum field with 0.
• Group-Address is set to 0.0.0.0
• Reserved field is set to 0
• S flag is set to 0
• QRV is set to the configured 'robustness-count' value.
• QQIC is set to the configured 'query-interval'
• Number-of-sources is set to 0

 

General Queries during initialization

During initialization, a router sends 'Startup Query Count' number of General Queries every 'Startup Query Interval'. 'Startup Query Interval' and 'Startup Query Count' is usually configured by the administrator. Router declares itself the querier on the LAN. The Startup General Queries help in quickly collecting the group membership information. Each router usually adds a small random delay before it sends out the first Startup query. This helps in avoiding the General Query implosion on the LAN. Once the required number of General Queries are sent, router moves to the steady-state where it sends periodic General Query every 'Query Interval'.

General Queries after initialization

Querier router periodically sends General Query every 'Query Interval'. So in steady-state, there should be only one router sending out General Queries.

General Query processing in Hosts

All multicast capable Hosts receive the General Query. A host generates a group membership report with current state of all the groups it has joined, within the maximum-response-time. Hosts generate multiple group membership reports are generated if all the group information does not fit in one single packet. Please note that host will pass the maximum possible information for a group in one single packet. Take a hypothetical case, for example, a host has requested multicast traffic for a specific group from 400 different sources. All these sources for this group cannot be sent in one single membership report message so host adds the maximum possible sources (366 as per RFC 3376) in the message. Host also makes sure that it uses the same set of sources in each of its membership report message.

General Query processing in Routers

All IGMP enabled routers receive general query of other routers and run querier election. Following processing is done:

• If this router is currently a querier:
• If the source IP address of the received general query is lesser than the current querier address:
• The router that sent this general query is selected as querier. Current router starts a other-querier-present-timer and stops generating General Query message.
•  Else
• Continue to act as querier.
• If this router is not a querier:
• If the source IP address of the received general query is lesser than the current querier address:
• Update the current querier address with source IP address.
• Update other-querier-present-timer.

When other-querier-present-timer fires, this router assumes the role of querier and start sending out General Queries.

Summary

I hope the above explanation would clarify your doubts about IGMP General Query. If you still have any questions, please leave me a comment. I will surely update the text to answer it. In my next post, I will explain Group and Group-and-Source specific queries.

Multicast in Ethernet LANs

Now that we know why do we need multicast and how multicast addressing works, let us look at how Multicast works in Ethernet LANs.

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

Please take a look at figure 1, what do you think who all will receive the multicast traffic sent by the sender?

Did you say 'all-of-them'? If yes, you got it wrong. To tell you the truth, none of them will receive the multicast traffic as they did not indicated their interest beforehand.

So how do the receivers indicate their interest? They use a simple protocol known as IGMP (Internet Group Management Protocol). I will talk about how IGMP works in detail in a future post.  For the time being, just remember that a receiver uses IGMP membership report messages to indicate his interest in receiving multicast traffic for a specific Group Address.

Now look at figures 2 and tell me who all will receive the multicast traffic sent by the sender?

Did you say R1 and R2? If yes, you got it right. Congratulations!

With the figures, can you figure out what difference does the IGMP membership report messages made in this network so that R1 and R2 can now receive the multicast traffic? Actually speaking, nothing, IGMP messages do not change anything. So then question is, how does R1 and R2 can now receive multicast traffic by just sending IGMP messages? Answer lies in what Hosts does when they send IGMP messages?

I am sure most of you already know, how a hosts accept traffic for himself on a LAN. But let me explain it in my terms. Hosts uses Ethernet NICs to send/receive traffic in LANs. Every NIC card is configured with a unique 48 bits MAC address. When one hosts (or any network element) communicate with other hosts, it figure out the destination host's MAC address using ARP. It then prepare an Ethernet Packet with that MAC address as destination MAC and sends the packet on LAN. All Hosts NIC card receive this packet and compare the MAC address with their own MAC address and only that hosts whose MAC address matches, accept the packet. Look at figure - 3. Destination MAC in ethernet frame is of R1 so only R1 accept the packet.

Now there are two things that comes out of this. One is that what MAC address should the sender use when sender is sending a Multicast packet. Another is what should the receivers do to accept the multicast packet?

To keep things simple, an IP multicast address is mapped to an Ethernet MAC address. Here is how the mapping works. Out of 48 bits, first 25 bits are a constant (01 00 5E 0) while rest of the 23 bits are same as the lower 23 bits of the multicast IP address. For example: 224.1.1.1 will map to 01 00 5E 01 01 01.

Do you see a potential issue with this mapping? If you do, take a pat on the back. With this mapping scheme, two different Multicast IP address can map to the same MAC address. If you try to map IP address 224.1.1.1 and 235.1.1.1, they both will map to the same MAC address 01 00 5E 01 01 01. This happens because out of 28 unique bits of multicast address, only 23 bits are used in mapping. Take a look at figure - 4 to see how the mapping works.

Your next question might be that why we ended up with such a scheme. Why did not someone got it right? Actually there is a small story behind this. Steve Deering requested a block of MAC address to be reserved for IP multicast use such that he could create a unique MAC address for each multicast address. But he was allocated a smaller block which had  first 25 bits fixed and we ended up with this scheme.

Now that we know how a multicast address is mapped to Ethernet MAC address, let us see how the multicast communication works. When a receiver indicates its interest in receiving multicast traffic for a given group, apart from sending an IGMP membership report, receiver configure their NIC cards with multicast MAC address calculated based on the mapping of the multicast group address. It means if receivers is interested in multicast group address 224.1.1.1, it configures the NIC card to receive traffic with 01 00 5E 01 01 01. Because of this, any data traffic received with this multicast MAC address is accepted by the receiver. Similarly a sender populates the destination MAC address by calculate the multicast MAC address based on the mapping of the multicast group address. Please look at figure - 5 to understand what I am suggesting.


This is the first post where I have tried to add as many figures as possible. Please do let me know how you like this post in comparison to others where I avoided figures completely. I will leave you with a question now. If multiple multicast group address can map to single MAC address, how does the end hosts filter out packets he is not interested in?

Multicast addressing : Whats the big deal?

In my previous, I tried to reason why IP multicast is required and how does it help in the network. In this post, I will focus on multicast addressing.

IP multicast uses Class D address space. First address is 224.0.0.0 and last address is 239.255.255.255. This range is also referred as 224/4.

Similar to unicast address space, some of the multicast address ranges are special. 224.0.0.0/24 are known as local multicast addresses. Packets destined to these addresses are not forwarded by a router and treated as broadcast packets by switches. Addresses in this range is used by various protocols like RIP, OSPF etc. to communicate with immediate neighbors. 232/8 are used only for Source Specific Multicast. I will talk about different types and how they are used in greater details in some future post.

IP multicast is built upon the assumption that senders and receivers do not need to know where the other is sitting in a network. They just need to know the multicast address that they need to use. Receivers shows its interest by sending out an IGMP/MLD join request with the multicast address they are interested in while senders just sends multicast data using the multicast address.

So how does an application finds out which IP multicast address to use? Very simple. Pick any multicast address and start sending data using that address. Am I kidding? No. This is how it is suppose to be.  But then how do receivers suppose to know which multicast address sender is using? Some out-of-band mechanism usually manual configuration.

But should not there be some means for sender to decide on a multicast address so that it is not in conflict with others. To start with, IP Multicast did not had any allocation mechanism. People came up with various mechanism to allocate multicast addresses like MALLOC but nothing was widely deployed. Later, some mechanisms like GLOP addressing, SSM address space, Administrative scope address range etc. were defined to help administrator with a range of multicast group address they can use within their network or globally. So usually sender is configured with a multicast address that it should use.

Now a days, Applications uses an address from administrative scoped address range if multicast traffic is not suppose to go out of its Autonomous System (AS). Application can use an address from the GLOP multicast address range or SSM address range as it will be unique globally. Receivers are told about this address through out-of-band mechanisms like passing it back in a http response.

If you want a consolidated information on Multicast address architecture, please read through RFC 6308. A whole list of the special multicast addresses can be found in Wikipedia. IANA maintains the IP multicast address space registry here.

Why IP Multicast - My take

When I started my career, I did an initiative on IP multicast and since then I have been working on this technology. There are various articles and blogs in the net that defines IP multicast. I decided to attempt to provide simple explanation. I hope you will let me know if I have succeeded or not. So here we go.

When a PC wants to communicate with a specific PC, it uses Unicast. This is similar to you writing a letter and posting it to your father.

When a PC wants to communicate with all the PCs in a network, it uses Broadcast. This is similar to you writing a letter and a copy is sent to all the people.

Multicast is somewhat in the middle. When a PC wants to communicate with a specific set of PCs in a network, it uses Multicast. This set may contain all the PCs in the network.This is similar to you writing a letter and a copy is sent to only sepecific set of people who want to receive your letter.

I am sure after reading this, the next question is why do we need Multicast? Why not use Broadcast itself? I completely agree. We can use Broadcast instead of Multicast. But is not there a catch? Yes, there surely is. Otherwise people would not have spent time, energy and lots of Rupees in creating Multicast. Here are the two which I could think of:

1. To receive Multicast traffic, a receiver specifically indicates that it wants to receive the traffic. So CPU of a receiver will not see the Multicast traffic if it has not wished to receive it. While in case of Broadcast traffic, receivers of all CPU
2. There are only two broadcast addresses and only one can be routed. While there are 2^28 or 268,435,456 Multicast addresses to choose from and except 255 ( 224.0.0.0 to 224.0.0.255) multicast addresses, all others can be routed. So applications can choose from a wider range of addresses in case of Multicast.

Now we know Broadcast cannot be used and we need something special like Multicast. To start with, Multicast was designed to help in one-to-many communication. Later it was extended to support many-to-many communication. In multicast, sender sends out one single packet and routers forward them towards the receiver. A router replicates a packet if it has receiver on multiple interfaces and send one packet towards each receiver. I will talk about Protocols used in IP multicast in future posts.

So how actually Multicast helps in a network? Here are the most visible aspects:

1. A server needs to send out only one copy of the packet if Multicast is used. If unicast would have been used instead, server would have to send out as many copies as the number of receiver. Right.
2. Network bandwidth is saved. Because server sends only one copy out instead of as many as the number of receiver.
3. As the overall number of packets in the network is reduced, it also helps in avoiding network congestion.

I did not use any network topology to put across my points. It could be a problem but I feel that it will be more satisfactory if you can visualize the whole thing with your strong visualizing capabilities.

I shall be talking more about IP multicast in upcoming posts so stay tuned.