We need to spend just a few minutes talking about how receivers
can signal their interest in multicast traffic.
There are two protocols that receivers can use,
depending on what IP version is in use.
Internet Group Management Protocol, or IGMP for short, is the protocol
used in IPv4 to signal interest in multicast traffic.
There are currently three versions of IGMP, though version 1 is
broadly considered a legacy implementation.
IGMP supports any source multicast in all three versions,
but source‑specific multicast is only supported in version 3.
This is because the source IP address field within the IGMP
packet was not added until version 3.
IPv6 uses Multicast Listener Discovery, or MLD for short. There are only two
versions of MLD because IPv6 was developed after version 1 of IGMP had been
improved with version 2. Because of this, MLD version 1 is equivalent to IGMP
version 2, and MLDv2 is equivalent to a IGMPv3.
This means that ASM is supported in MLDv1 and v2, but
SSM is only supported in MLDv2.
As I said before,
this is a deep dive on the PIM protocol, so I don't want to
spend a lot of time discussing IGMP and MLD.
But let's quickly review how the signaling process works.
A receiver sends either an IGMP or MLD membership report onto the local segment.
This packet must include a requested multicast group address and may or
may not include a source IP address. Whether or not the source is
included is based on the version in play and whether the receiver knows
the IP of the sources. In this example, for brevity and simplicity,
let's assume it's IGMP version 3 and references a specific
source IP, as well as the multicast group address. Any routers
on the local link will receive the report, and if more than one
router is on that segment,
they will have decided which of them will be the
one to forward multicast traffic.
That router will convert the report into a PIM join.
Another important function of receiver signaling is
maintaining the multicast forwarding state.
No multicast state is assumed to be permanent, and it must be
constantly refreshed to ensure that the traffic optimization
benefits of multicast are taking place.
If a receiver drops off without signaling its
intention to leave the multicast group,
it could be a very long time until traffic stops being
delivered without state maintenance and timers.
To this end,
each local LAN segment should contain an IGMP or MLD querier. This may
or may not be the designated multicast router itself,
a Layer 3 switch or another router.
The querier's job is to periodically send queries onto the local segment,
asking, does anyone want multicast? The receivers who are currently using
multicast reply with a triggered membership report.
This is the same report that was initiated by the receiver
originally, and it serves to refresh the timers on the multicast
router and ensure that multicast is still needed.
If a receiver wants to leave the group, it will send another membership report,
but this time, it will use a different flag indicating
that it wants to leave the group.
There are more specific details based on the version of IGMP or MLD in use,
but this is enough to cover what's needed for a deep dive on PIM.
I encourage anyone who wants to understand IGMP and MLD better to
watch Nick Russo's IGMP and MLD deep dive on Pluralsight as part of the Protocol Deep Dive learning path.