1
00:00:00,000 --> 00:00:03,920
[AUDIO LOGO]

2
00:00:03,920 --> 00:00:08,039

3
00:00:08,039 --> 00:00:10,480
So now that we've
configured PIM sparse mode

4
00:00:10,480 --> 00:00:14,170
on our routers and the
appropriate interfaces

5
00:00:14,170 --> 00:00:16,360
as well as configuring
them statically

6
00:00:16,360 --> 00:00:19,630
with the appropriate RP
address, we should probably

7
00:00:19,630 --> 00:00:22,240
take just a moment
here to talk about some

8
00:00:22,240 --> 00:00:24,760
of the details of
the protocol that's

9
00:00:24,760 --> 00:00:28,300
used between the
client or receiver

10
00:00:28,300 --> 00:00:30,730
and the last-hop router.

11
00:00:30,730 --> 00:00:35,410
This protocol is called IGMP,
or Internet Group Management

12
00:00:35,410 --> 00:00:36,400
Protocol.

13
00:00:36,400 --> 00:00:39,610
And it's used by the
client or receiver

14
00:00:39,610 --> 00:00:42,280
to signal the
last-hop router to let

15
00:00:42,280 --> 00:00:45,490
it know what groups
that last-hop router

16
00:00:45,490 --> 00:00:48,850
should join on behalf
of that receiver.

17
00:00:48,850 --> 00:00:52,990
Now, IGMP currently
comes in three versions--

18
00:00:52,990 --> 00:00:55,810
version 1, version
2, and version 3.

19
00:00:55,810 --> 00:00:57,850
So what we want
to do here is jump

20
00:00:57,850 --> 00:00:59,950
into some of the
differences, pros

21
00:00:59,950 --> 00:01:01,810
and cons of the
different versions,

22
00:01:01,810 --> 00:01:05,150
and talk about the major
differences between them.

23
00:01:05,150 --> 00:01:07,820
So let's go ahead and
jump in and take a look

24
00:01:07,820 --> 00:01:09,360
at some of those details.

25
00:01:09,360 --> 00:01:11,930
We'll talk about a
general overview.

26
00:01:11,930 --> 00:01:13,550
And then we'll
look at the details

27
00:01:13,550 --> 00:01:16,800
of each different version.

28
00:01:16,800 --> 00:01:21,560
So between the last-hop
router and the receiver,

29
00:01:21,560 --> 00:01:24,020
or the client, or the
listener, whatever

30
00:01:24,020 --> 00:01:28,100
we want to call this end device,
we need to run a protocol.

31
00:01:28,100 --> 00:01:30,200
And as we mentioned,
that protocol

32
00:01:30,200 --> 00:01:35,330
is Internet Group Management
Protocol, or IGMP.

33
00:01:35,330 --> 00:01:38,930
This is how the
client or the receiver

34
00:01:38,930 --> 00:01:42,560
indicates its interest
in that specific group

35
00:01:42,560 --> 00:01:44,780
to the last-hop router.

36
00:01:44,780 --> 00:01:48,290
The last-hop router
has to know what group

37
00:01:48,290 --> 00:01:53,300
to build the tree for in PIM,
be that the star comma G tree

38
00:01:53,300 --> 00:01:56,510
going to the rendezvous
point or maybe an S comma G

39
00:01:56,510 --> 00:01:58,400
tree directly to the source.

40
00:01:58,400 --> 00:02:02,570
But either way, we need to know
the group that the clients want

41
00:02:02,570 --> 00:02:06,620
to receive, or else the
last-hop router would literally

42
00:02:06,620 --> 00:02:09,050
have no idea what to do.

43
00:02:09,050 --> 00:02:11,520
It would just be, OK,
I'm a multicast router.

44
00:02:11,520 --> 00:02:12,260
Now what?

45
00:02:12,260 --> 00:02:15,230
So this is a very
important protocol

46
00:02:15,230 --> 00:02:18,840
because the routers have to
know what groups to join.

47
00:02:18,840 --> 00:02:22,320
There are currently
three versions of IGMP.

48
00:02:22,320 --> 00:02:26,290
So let's talk about some of
the information about each one.

49
00:02:26,290 --> 00:02:30,870
So first up is IGMP version 1.

50
00:02:30,870 --> 00:02:35,550
This is referenced in RFC 1112.

51
00:02:35,550 --> 00:02:39,420
And with IGMP version
1, the way this works

52
00:02:39,420 --> 00:02:45,160
is the client sends a
report when joining a group.

53
00:02:45,160 --> 00:02:48,210
Now, when other clients
see that report,

54
00:02:48,210 --> 00:02:51,090
if they were going to be
joining the same group,

55
00:02:51,090 --> 00:02:54,360
they will then suppress
their own report.

56
00:02:54,360 --> 00:02:57,150
That way, the router
doesn't get overwhelmed

57
00:02:57,150 --> 00:03:02,340
by multiple individual devices
asking for the same group.

58
00:03:02,340 --> 00:03:05,740
Keep in mind that from
the router's perspective,

59
00:03:05,740 --> 00:03:10,020
it only needs one interested
client or receiver

60
00:03:10,020 --> 00:03:13,330
on that interface in order
to forward the traffic.

61
00:03:13,330 --> 00:03:17,940
So it doesn't need to know
that there's 2 or 20 or 1,000

62
00:03:17,940 --> 00:03:20,100
potential receivers out there.

63
00:03:20,100 --> 00:03:22,290
It only needs to know about one.

64
00:03:22,290 --> 00:03:26,460
So there would be no need
to receive multiple reports.

65
00:03:26,460 --> 00:03:30,930
Now, the next point here is
probably the biggest downfall

66
00:03:30,930 --> 00:03:33,300
to IGMP version 1.

67
00:03:33,300 --> 00:03:37,330
There was no leave mechanism.

68
00:03:37,330 --> 00:03:41,310
There was no way for a client
to say that it no longer wants

69
00:03:41,310 --> 00:03:42,990
that multicast group.

70
00:03:42,990 --> 00:03:45,510
It would have to just time out.

71
00:03:45,510 --> 00:03:48,850
This could take up
to three minutes.

72
00:03:48,850 --> 00:03:51,760
This may not seem like
a big deal at first.

73
00:03:51,760 --> 00:03:56,010
But imagine you were doing
something like IPTV, where

74
00:03:56,010 --> 00:03:59,310
you had a variety
of video streams

75
00:03:59,310 --> 00:04:01,530
available over multicast.

76
00:04:01,530 --> 00:04:04,690
Then you have a client,
which is essentially

77
00:04:04,690 --> 00:04:06,340
doing channel surfing.

78
00:04:06,340 --> 00:04:09,340
They're going one video to the
next, to the next, to the next

79
00:04:09,340 --> 00:04:11,650
to try to pick what
they want to view.

80
00:04:11,650 --> 00:04:14,140
Well, the problem is
they're joining every one

81
00:04:14,140 --> 00:04:15,940
of those groups as they go.

82
00:04:15,940 --> 00:04:19,390
They could potentially
flip through hundreds

83
00:04:19,390 --> 00:04:23,200
of different video streams
in that three-minute period.

84
00:04:23,200 --> 00:04:25,840
And nobody's actually
watching those streams.

85
00:04:25,840 --> 00:04:27,950
But the router
doesn't know that.

86
00:04:27,950 --> 00:04:30,830
So it continues forwarding
on to the segment.

87
00:04:30,830 --> 00:04:35,890
So in certain environments,
this lack of a leave message

88
00:04:35,890 --> 00:04:38,030
was really a big problem.

89
00:04:38,030 --> 00:04:39,580
And that's why we
generally don't

90
00:04:39,580 --> 00:04:42,670
use IGMP version 1 any longer.

91
00:04:42,670 --> 00:04:44,630
We'll see in just a
moment, of course,

92
00:04:44,630 --> 00:04:46,630
that version 2 fixes this.

93
00:04:46,630 --> 00:04:51,760
Now, just as one more final
detail here, in IGMP version 1,

94
00:04:51,760 --> 00:04:55,810
we send a query message to
ask if the clients are still

95
00:04:55,810 --> 00:04:59,740
interested in receiving the
traffic to the multicast group

96
00:04:59,740 --> 00:05:02,560
224.0.0.1.

97
00:05:02,560 --> 00:05:06,400
That is the link local
multicast for all devices.

98
00:05:06,400 --> 00:05:10,330
We send that with a TTL of
1 since it's link local.

99
00:05:10,330 --> 00:05:15,010
And we send this every
60 to 120 seconds.

100
00:05:15,010 --> 00:05:17,500
If nobody replies
to that message,

101
00:05:17,500 --> 00:05:20,420
then we begin timing
out the stream.

102
00:05:20,420 --> 00:05:23,215
So now let's take a
look at IGMP version 2.

103
00:05:23,215 --> 00:05:25,900

104
00:05:25,900 --> 00:05:32,620
IGMP version 2 is
referenced in RFC 2236.

105
00:05:32,620 --> 00:05:35,080
And it brought
some major changes.

106
00:05:35,080 --> 00:05:39,610
The first thing it brought
was a group-specific query.

107
00:05:39,610 --> 00:05:43,850
Group-specific queries
mean that, for example,

108
00:05:43,850 --> 00:05:51,670
if a client says that it wants
to join the group 224.3.7.9,

109
00:05:51,670 --> 00:05:54,280
when it comes to sending
the query to find out

110
00:05:54,280 --> 00:05:56,900
if the client is
still interested,

111
00:05:56,900 --> 00:06:02,170
we would send that query
to the group 224.3.7.9.

112
00:06:02,170 --> 00:06:05,200
In other words, it
queries the same group

113
00:06:05,200 --> 00:06:07,750
that the clients
are listening to.

114
00:06:07,750 --> 00:06:11,770
As we sort of mentioned in
our IGMP version 1 discussion,

115
00:06:11,770 --> 00:06:14,800
one of the big things
missing from version 1

116
00:06:14,800 --> 00:06:17,350
was the leave message.

117
00:06:17,350 --> 00:06:21,760
Well, this has been incorporated
into IGMP version 2.

118
00:06:21,760 --> 00:06:25,730
So when a client is
done watching a group,

119
00:06:25,730 --> 00:06:30,710
they can then send a leave
message to the last-hop router.

120
00:06:30,710 --> 00:06:33,320
At that point, the
last-hop router

121
00:06:33,320 --> 00:06:35,690
would then send one
of these queries

122
00:06:35,690 --> 00:06:38,540
to see if anybody else
is still interested.

123
00:06:38,540 --> 00:06:41,330
It won't just stop the
stream, because, again, there

124
00:06:41,330 --> 00:06:43,190
could be other listeners.

125
00:06:43,190 --> 00:06:45,470
But it will send a query
message at that point

126
00:06:45,470 --> 00:06:47,570
to see if anybody
else is interested.

127
00:06:47,570 --> 00:06:52,370
And if they are, those devices
would then respond, say,

128
00:06:52,370 --> 00:06:53,990
yes, we're interested.

129
00:06:53,990 --> 00:06:57,930
And therefore, it wouldn't
actually stop the flow.

130
00:06:57,930 --> 00:07:00,590
But if that was the
only listener, then,

131
00:07:00,590 --> 00:07:04,320
yes, that flow would
stop on that interface.

132
00:07:04,320 --> 00:07:08,630
So this is going to stop those
unnecessary flows much quicker.

133
00:07:08,630 --> 00:07:13,280
Also, we added a querier
election mechanism.

134
00:07:13,280 --> 00:07:16,550
That mechanism is simply
the lowest IP address.

135
00:07:16,550 --> 00:07:20,510
What this is for is if
there's multiple routers

136
00:07:20,510 --> 00:07:24,560
on the same network, we have
to determine which one of them

137
00:07:24,560 --> 00:07:27,380
is going to send these
query messages that we've

138
00:07:27,380 --> 00:07:28,610
been discussing.

139
00:07:28,610 --> 00:07:31,040
Just like multiple
clients don't need

140
00:07:31,040 --> 00:07:33,020
to report their
interest in a group,

141
00:07:33,020 --> 00:07:36,200
we don't need multiple
routers asking the clients

142
00:07:36,200 --> 00:07:38,270
if they still want a group.

143
00:07:38,270 --> 00:07:41,780
We also implemented a
query-interval response time.

144
00:07:41,780 --> 00:07:44,510
This way, all of
the devices do not

145
00:07:44,510 --> 00:07:48,210
answer one of these group
queries all at the same time.

146
00:07:48,210 --> 00:07:52,190
And again, if one answers,
the rest of them will see it.

147
00:07:52,190 --> 00:07:56,090
And they will cancel their
reply because, again, the router

148
00:07:56,090 --> 00:07:58,991
only needs to know about one.

149
00:07:58,991 --> 00:08:03,610
One other quick thing to note
here about IGMP version 2, this

150
00:08:03,610 --> 00:08:06,970
is currently the default
on all of the interfaces

151
00:08:06,970 --> 00:08:10,370
on our routers when we
enable this feature.

152
00:08:10,370 --> 00:08:14,500
So just be aware that if we
want something that IGMP version

153
00:08:14,500 --> 00:08:18,700
3 gives us, we will have to go
change that version to version

154
00:08:18,700 --> 00:08:19,840
3.

155
00:08:19,840 --> 00:08:25,090
On that note, let's go ahead
and talk about version 3.

156
00:08:25,090 --> 00:08:31,660
So IGMP version 3,
referenced in RFC 3376,

157
00:08:31,660 --> 00:08:35,710
changes a few minor things
and one major thing.

158
00:08:35,710 --> 00:08:40,240
First, it changes the group
that the reports are sent to.

159
00:08:40,240 --> 00:08:45,610
Reports are actually
sent to 224.0.0.22.

160
00:08:45,610 --> 00:08:49,780
And the big change
here is those reports

161
00:08:49,780 --> 00:08:55,630
can now specify the source
of the multicast group.

162
00:08:55,630 --> 00:08:59,980
This is the feature that
allows us to do SSM,

163
00:08:59,980 --> 00:09:03,160
or Source-Specific Multicast.

164
00:09:03,160 --> 00:09:06,370
And since we can
specify the source,

165
00:09:06,370 --> 00:09:11,440
this means that it also removes
the need for a rendezvous

166
00:09:11,440 --> 00:09:12,350
point.

167
00:09:12,350 --> 00:09:14,680
So we no longer need the RP.

168
00:09:14,680 --> 00:09:17,240
This simplifies the environment.

169
00:09:17,240 --> 00:09:22,670
We will be looking at SSM in
more detail in a future skill.

170
00:09:22,670 --> 00:09:25,940
But be aware that when we
jump into it in more detail,

171
00:09:25,940 --> 00:09:29,750
we will have to
implement IGMP version 3.

172
00:09:29,750 --> 00:09:34,580
This is the big new
feature in version 3.

173
00:09:34,580 --> 00:09:38,030
In this video, we jumped
in and we talked about some

174
00:09:38,030 --> 00:09:41,510
of the details of the
differences between the three

175
00:09:41,510 --> 00:09:44,540
different versions of IGMP.

176
00:09:44,540 --> 00:09:46,940
Remember some of
our key takeaways.

177
00:09:46,940 --> 00:09:51,410
IGMP version 1 had sort of
a big downside, which was

178
00:09:51,410 --> 00:09:54,270
that it had no leave mechanism.

179
00:09:54,270 --> 00:09:58,710
IGMP version 2 introduced
a leave mechanism,

180
00:09:58,710 --> 00:10:01,380
group-specific
queries, and a couple

181
00:10:01,380 --> 00:10:03,450
other pretty cool features.

182
00:10:03,450 --> 00:10:08,880
What it didn't have, however,
is support to specify a source.

183
00:10:08,880 --> 00:10:11,730
And that's the big thing
that came to the table

184
00:10:11,730 --> 00:10:15,780
with IGMP version 3, where
we picked up the ability

185
00:10:15,780 --> 00:10:20,040
to do SSM, or
Source-Specific Multicast.

186
00:10:20,040 --> 00:10:22,950
So now that we've
discussed the details

187
00:10:22,950 --> 00:10:26,070
of the client-side
protocol, it's

188
00:10:26,070 --> 00:10:29,880
probably time to
actually fire up a client

189
00:10:29,880 --> 00:10:34,810
and watch how the S comma G tree
gets formed in our environment.

190
00:10:34,810 --> 00:10:37,500
And that's exactly what
we're going to do next.

191
00:10:37,500 --> 00:10:40,920
Until then, I hope this has
been informative for you,

192
00:10:40,920 --> 00:10:44,060
and I'd like to thank
you for viewing.

193
00:10:44,060 --> 00:10:48,000