[AUDIO LOGO]
So now that we've configured PIM sparse mode
on our routers and the appropriate interfaces
as well as configuring them statically
with the appropriate RP address, we should probably
take just a moment here to talk about some
of the details of the protocol that's
used between the client or receiver
and the last-hop router.
This protocol is called IGMP, or Internet Group Management
Protocol.
And it's used by the client or receiver
to signal the last-hop router to let
it know what groups that last-hop router
should join on behalf of that receiver.
Now, IGMP currently comes in three versions--
version 1, version 2, and version 3.
So what we want to do here is jump
into some of the differences, pros
and cons of the different versions,
and talk about the major differences between them.
So let's go ahead and jump in and take a look
at some of those details.
We'll talk about a general overview.
And then we'll look at the details
of each different version.
So between the last-hop router and the receiver,
or the client, or the listener, whatever
we want to call this end device, we need to run a protocol.
And as we mentioned, that protocol
is Internet Group Management Protocol, or IGMP.
This is how the client or the receiver
indicates its interest in that specific group
to the last-hop router.
The last-hop router has to know what group
to build the tree for in PIM, be that the star comma G tree
going to the rendezvous point or maybe an S comma G
tree directly to the source.
But either way, we need to know the group that the clients want
to receive, or else the last-hop router would literally
have no idea what to do.
It would just be, OK, I'm a multicast router.
Now what?
So this is a very important protocol
because the routers have to know what groups to join.
There are currently three versions of IGMP.
So let's talk about some of the information about each one.
So first up is IGMP version 1.
This is referenced in RFC 1112.
And with IGMP version 1, the way this works
is the client sends a report when joining a group.
Now, when other clients see that report,
if they were going to be joining the same group,
they will then suppress their own report.
That way, the router doesn't get overwhelmed
by multiple individual devices asking for the same group.
Keep in mind that from the router's perspective,
it only needs one interested client or receiver
on that interface in order to forward the traffic.
So it doesn't need to know that there's 2 or 20 or 1,000
potential receivers out there.
It only needs to know about one.
So there would be no need to receive multiple reports.
Now, the next point here is probably the biggest downfall
to IGMP version 1.
There was no leave mechanism.
There was no way for a client to say that it no longer wants
that multicast group.
It would have to just time out.
This could take up to three minutes.
This may not seem like a big deal at first.
But imagine you were doing something like IPTV, where
you had a variety of video streams
available over multicast.
Then you have a client, which is essentially
doing channel surfing.
They're going one video to the next, to the next, to the next
to try to pick what they want to view.
Well, the problem is they're joining every one
of those groups as they go.
They could potentially flip through hundreds
of different video streams in that three-minute period.
And nobody's actually watching those streams.
But the router doesn't know that.
So it continues forwarding on to the segment.
So in certain environments, this lack of a leave message
was really a big problem.
And that's why we generally don't
use IGMP version 1 any longer.
We'll see in just a moment, of course,
that version 2 fixes this.
Now, just as one more final detail here, in IGMP version 1,
we send a query message to ask if the clients are still
interested in receiving the traffic to the multicast group
224.0.0.1.
That is the link local multicast for all devices.
We send that with a TTL of 1 since it's link local.
And we send this every 60 to 120 seconds.
If nobody replies to that message,
then we begin timing out the stream.
So now let's take a look at IGMP version 2.
IGMP version 2 is referenced in RFC 2236.
And it brought some major changes.
The first thing it brought was a group-specific query.
Group-specific queries mean that, for example,
if a client says that it wants to join the group 224.3.7.9,
when it comes to sending the query to find out
if the client is still interested,
we would send that query to the group 224.3.7.9.
In other words, it queries the same group
that the clients are listening to.
As we sort of mentioned in our IGMP version 1 discussion,
one of the big things missing from version 1
was the leave message.
Well, this has been incorporated into IGMP version 2.
So when a client is done watching a group,
they can then send a leave message to the last-hop router.
At that point, the last-hop router
would then send one of these queries
to see if anybody else is still interested.
It won't just stop the stream, because, again, there
could be other listeners.
But it will send a query message at that point
to see if anybody else is interested.
And if they are, those devices would then respond, say,
yes, we're interested.
And therefore, it wouldn't actually stop the flow.
But if that was the only listener, then,
yes, that flow would stop on that interface.
So this is going to stop those unnecessary flows much quicker.
Also, we added a querier election mechanism.
That mechanism is simply the lowest IP address.
What this is for is if there's multiple routers
on the same network, we have to determine which one of them
is going to send these query messages that we've
been discussing.
Just like multiple clients don't need
to report their interest in a group,
we don't need multiple routers asking the clients
if they still want a group.
We also implemented a query-interval response time.
This way, all of the devices do not
answer one of these group queries all at the same time.
And again, if one answers, the rest of them will see it.
And they will cancel their reply because, again, the router
only needs to know about one.
One other quick thing to note here about IGMP version 2, this
is currently the default on all of the interfaces
on our routers when we enable this feature.
So just be aware that if we want something that IGMP version
3 gives us, we will have to go change that version to version
3.
On that note, let's go ahead and talk about version 3.
So IGMP version 3, referenced in RFC 3376,
changes a few minor things and one major thing.
First, it changes the group that the reports are sent to.
Reports are actually sent to 224.0.0.22.
And the big change here is those reports
can now specify the source of the multicast group.
This is the feature that allows us to do SSM,
or Source-Specific Multicast.
And since we can specify the source,
this means that it also removes the need for a rendezvous
point.
So we no longer need the RP.
This simplifies the environment.
We will be looking at SSM in more detail in a future skill.
But be aware that when we jump into it in more detail,
we will have to implement IGMP version 3.
This is the big new feature in version 3.
In this video, we jumped in and we talked about some
of the details of the differences between the three
different versions of IGMP.
Remember some of our key takeaways.
IGMP version 1 had sort of a big downside, which was
that it had no leave mechanism.
IGMP version 2 introduced a leave mechanism,
group-specific queries, and a couple
other pretty cool features.
What it didn't have, however, is support to specify a source.
And that's the big thing that came to the table
with IGMP version 3, where we picked up the ability
to do SSM, or Source-Specific Multicast.
So now that we've discussed the details
of the client-side protocol, it's
probably time to actually fire up a client
and watch how the S comma G tree gets formed in our environment.
And that's exactly what we're going to do next.
Until then, I hope this has been informative for you,
and I'd like to thank you for viewing.