As discussed on previous blog multicast is a technology which enables one to many or many to many connectivity. Though, unlike with unicast connectivity, the destination (multicast) IP address represents a group of hosts which show interest in multicast traffic.

The key here is that the group of hosts is dynamic and therefore and, the IP address cannot be pinned to a specific host!

How could you then get a communication path end-to-end, if you dont’ know which are the hosts and where are they located within the network topology!?

IGMP comes to rescue – it is a control-plane protocol which allow hosts and their respective gateways to agree on multicast groups membership.

Is this enough for establishing a comm path end-to-end? No, it is not!

A different mechanism is further used to establish the communcation path back to the multicast source – see PIM (Protocol Independent Protocol).

Next, I will highlight few properties of the IGMP protocol (with emphasis on version 2), following up with a diagram outlining the different messages that the protocol uses.


  • IGMP exist today in three versions, version 2 being the most used – as the protocol evolved, not only the packet header changed, but also the actual operation of the protocol

igmp-versions-v2

  • IGMP messages are encapsulated inside the IP protocol as protocol id of 2 (also shown above)
  • The IGMPv2 header is quite simple as it has 4 fields only

igmpv2-header-explained

  • There are 3 main types of messages: Queries, Reports, and Leave messages
    • Queries are always sent by the routers
      • Generic sent at regular time intervals to enquiry for group membership – Is any host on my segment interested in multicast messages? 
      • Group Specific sent by the router in response to a leave message from hosts
    • Reports are sent from the hosts to the gateway either upon startup of the mcast application, or as a reply to a previous query
    • When the muticast applicaiton stops, a Leave message is sent out to the gateway. Again, this will trigger a Group Specific Query from the router just in case there are IGMP enabled hosts left on that segment

And now to the promised diagram …

igmpv2-lifecycle-flow-v2


To wrap this up, I’d strongly recommend you to also take a look at samples from live packet captures, found Packet Captures. Notice the following:

  • MRT (Maximum Response Time) is 0 (zero) except for generic messages
  • IP protocol id 2
  • Differences between v1, v2 & v3 such as:
    • IGMPv1 does not include the MRT field; it doesn’t use a Leave message either – both introduced in IGMPv2
    • IGMPv3 includes fields for the the multicast source – this enables SSM (Source Specific Multicast) which itself, reduces discovery traffic in the network an improves network security
  • Generic Query messages have a destination IP address the well-known address of all-hosts (224.0.0.1) – but what about the Group Specific Query?
  • Notice the destination address in the Leave Message; it’s the well-known mcast address all-routers (224.0.0.2)
  • Notice the cases where the group address field in the encapsulated packet is different from the destination IP address in the IP header – and think about it; ask yourself why. Use the diagram above.

Lastly, when you are rested, do take some time and read the RFCs.


Thank you,
Signature
View Rafael A Couto Cabral's profile on LinkedIn



Comments are closed.