1
00:00:08,060 --> 00:00:12,560
 So any introduction to multicast video
 has to start out with the basics

2
00:00:12,560 --> 00:00:17,880
 of multicast, what it is, where it's used,
 and how to recognize a multicast

3
00:00:17,880 --> 00:00:22,180
 packet at layer 3 and a multicast
 ethernet frame at layer 2.

4
00:00:22,180 --> 00:00:24,540
 So that's what we're going
 to look at right now.

5
00:00:24,540 --> 00:00:27,560
 So let's start talking
 about why multicast.

6
00:00:27,560 --> 00:00:31,640
 So multicast is what we
 refer to as one to many.

7
00:00:31,640 --> 00:00:34,780
 In other words, I'm sure you know
 what a unicast is, right?

8
00:00:34,780 --> 00:00:38,700
 A unicast is there's some web server
 out there that's sending a packet

9
00:00:38,700 --> 00:00:42,280
 unicast to your laptop
 and your laptop only.

10
00:00:42,280 --> 00:00:44,980
 And that packet contains like a web
 page or something inside of it.

11
00:00:44,980 --> 00:00:46,980
 So that's a one-to
-one transmission.

12
00:00:46,980 --> 00:00:48,600
 And I'm sure you know what
 a broadcast is, right?

13
00:00:48,600 --> 00:00:51,020
 A broadcast is something that
 goes out to everybody.

14
00:00:51,020 --> 00:00:53,740
 And we know that routers
 kill broadcast.

15
00:00:53,740 --> 00:00:57,900
 When a broadcast reaches a router's
 layer 3 interface, it stops.

16
00:00:57,900 --> 00:01:01,380
 Or in the case of a multi-layer switch
 that has switched virtual interfaces,

17
00:01:01,380 --> 00:01:04,860
 if you're using your switch
 as a router, same thing.

18
00:01:04,860 --> 00:01:09,780
 Any layer 3 interface stops a
 broadcast dead in its tracks.

19
00:01:09,780 --> 00:01:13,900
 So multicast is like in the middle
 of that, we call it one to many.

20
00:01:13,900 --> 00:01:19,000
 For example, typical use case of multicast
 is for what's called streaming

21
00:01:19,000 --> 00:01:26,120
 video. So let's say, for example, that
 my CEO of my company is scheduled

22
00:01:26,120 --> 00:01:31,580
 at 2 o'clock today to deliver a
 state of the company address.

23
00:01:31,580 --> 00:01:33,520
 Well, let's actually make
 it more specific.

24
00:01:33,520 --> 00:01:36,200
 A state of engineering
 address, OK?

25
00:01:36,200 --> 00:01:38,840
 So he's going to get up there and talk
 specifically about the engineering

26
00:01:38,840 --> 00:01:42,360
 department, engineering
 focus and vision.

27
00:01:42,360 --> 00:01:44,880
 And that's what he's
 going to talk about.

28
00:01:44,880 --> 00:01:50,060
 So and in our engineering department,
 we have maybe 100 employees scattered

29
00:01:50,060 --> 00:01:51,440
 throughout the campus.

30
00:01:51,440 --> 00:01:52,420
 They don't all sit together.

31
00:01:52,420 --> 00:01:54,560
 They sit in sort of pockets
 here and there.

32
00:01:54,560 --> 00:02:00,000
 Well, so we got a video camera at
 2 o'clock, trained on my CEO.

33
00:02:00,000 --> 00:02:03,340
 That video camera is then going back
 to a server which is digitizing the

34
00:02:03,340 --> 00:02:06,520
 video. And so now we got to think about,
 OK, how am I going to send that

35
00:02:06,520 --> 00:02:09,760
 video stream out to
 those 100 employees?

36
00:02:09,760 --> 00:02:13,160
 And maybe not even all of them
 want to see it, right?

37
00:02:13,160 --> 00:02:17,000
 Maybe some of those employees are on
 vacation and their laptops are here

38
00:02:17,000 --> 00:02:17,520
 and they're running.

39
00:02:17,520 --> 00:02:19,960
 They're locked to the desk,
 but they're just gone.

40
00:02:19,960 --> 00:02:21,740
 The employees not here.

41
00:02:21,740 --> 00:02:23,780
 Others, employees could
 just care less.

42
00:02:23,780 --> 00:02:26,660
 They think the CEO is full of hot air
 and they don't watch the videos

43
00:02:26,660 --> 00:02:28,800
 anymore. They don't
 watch the streams.

44
00:02:28,800 --> 00:02:33,040
 So there's going to be a subset of
 employees and engineering that want

45
00:02:33,040 --> 00:02:34,300
 to watch this video stream.

46
00:02:34,300 --> 00:02:35,420
 So how do we get it to them?

47
00:02:35,420 --> 00:02:41,280
 Let's say that of the 100 employees,
 maybe 60, 60 of them want to watch

48
00:02:41,280 --> 00:02:42,580
 this video stream.

49
00:02:42,580 --> 00:02:47,420
 Well, if you've ever researched anything
 about multicast video, one of

50
00:02:47,420 --> 00:02:51,500
 the characteristics of multicast video
 is that typically it's very bandwidth

51
00:02:51,500 --> 00:02:55,640
 hungry. Multicast video consumes a lot
 of bandwidth, especially if you're

52
00:02:55,640 --> 00:02:59,700
 talking about an HD like a high
 definition video stream.

53
00:02:59,700 --> 00:03:02,140
 It can really consume
 a lot of bandwidth.

54
00:03:02,140 --> 00:03:06,500
 So if I have my multicast server so that's
 connected to that camera, that's

55
00:03:06,500 --> 00:03:10,120
 digitizing, turning into an MPEG or
 an ABI or something like that, it's

56
00:03:10,120 --> 00:03:14,180
 going to send it out as a multicast,
 well, we've got some options.

57
00:03:14,180 --> 00:03:18,060
 We could send it out as a unicast stream
 where each one of those 60 employees

58
00:03:18,060 --> 00:03:22,700
 has to click on some web page, which
 sends a unicast message to my server

59
00:03:22,700 --> 00:03:27,820
 and then my server's CPU has to create
 a copy of the packet and send it

60
00:03:27,820 --> 00:03:32,200
 to that person. So now imagine if all
 60 people were doing that, that

61
00:03:32,200 --> 00:03:34,900
 would be asking that server
 to do a lot of work.

62
00:03:34,900 --> 00:03:37,960
 It'd have to take that video stream,
 which might be, let's just make it

63
00:03:37,960 --> 00:03:41,140
 easy, 256 kilobits per second.

64
00:03:41,140 --> 00:03:42,560
 And that's a pretty slow stream.

65
00:03:42,560 --> 00:03:44,580
 That's pretty small
 bandwidth stream.

66
00:03:44,580 --> 00:03:50,360
 Imagine 256 kilobits per second packets
 and it has to replicate that 60

67
00:03:50,360 --> 00:03:54,640
 times for 60 individual
 unicast streams.

68
00:03:54,640 --> 00:03:58,520
 Chances are the server would have
 a real tough time doing that.

69
00:03:58,520 --> 00:04:01,960
 And imagine what kind of load that would
 put on the actual network infrastructure.

70
00:04:01,960 --> 00:04:07,620
 That's 256 kilobits per second
 times 60 unicast streams.

71
00:04:07,620 --> 00:04:09,640
 Probably don't want to do that.

72
00:04:09,640 --> 00:04:11,760
 And you say, well, why don't
 I just broadcast it?

73
00:04:11,760 --> 00:04:15,420
 Well, number one, broadcast can't get
 to everybody because we know that

74
00:04:15,420 --> 00:04:17,560
 routers drop broadcasts.

75
00:04:17,560 --> 00:04:21,020
 And I said that these employees were
 scattered throughout the campus.

76
00:04:21,020 --> 00:04:22,700
 They're not all sitting together.

77
00:04:22,700 --> 00:04:28,300
 And even if I theoretically could get
 my routers to force them to flood

78
00:04:28,300 --> 00:04:33,820
 this broadcast, well, that's going to
 be impacting everybody in my company.

79
00:04:33,820 --> 00:04:37,560
 It's going to be impacting the payroll
 and the human resources and the

80
00:04:37,560 --> 00:04:43,000
 marketing departments because all of
 their links are going to be saturated

81
00:04:43,000 --> 00:04:46,440
 with this broadcast traffic
 that has the video in it.

82
00:04:46,440 --> 00:04:49,060
 So this is where multicast
 comes into play.

83
00:04:49,060 --> 00:04:54,400
 So with multicast, the server only has
 to create one stream of traffic,

84
00:04:54,400 --> 00:04:56,180
 one stream of traffic.

85
00:04:56,180 --> 00:04:59,940
 And that one stream of traffic is going
 to a special, what they call group

86
00:04:59,940 --> 00:05:02,760
 destination address or GDA.

87
00:05:02,760 --> 00:05:06,020
 And just a moment, I'll show
 you what those look like.

88
00:05:06,020 --> 00:05:10,220
 Now, you might be wondering, well, how
 do we get it to where of all the

89
00:05:10,220 --> 00:05:14,420
 people in my company, only those 60
 people in engineering will actually

90
00:05:14,420 --> 00:05:16,080
 get that stream.

91
00:05:16,080 --> 00:05:17,400
 How does that work?

92
00:05:17,400 --> 00:05:20,040
 Well, it's basically
 a multi-part process.

93
00:05:20,040 --> 00:05:24,820
 So number one, the employees have to
 have some sort of application on

94
00:05:24,820 --> 00:05:28,060
 their laptop. It might be embedded
 into their web browser.

95
00:05:28,060 --> 00:05:31,440
 But they have to have something that
 they can click on to see a listing

96
00:05:31,440 --> 00:05:35,260
 of all the multicast streams that are
 currently happening right now, like

97
00:05:35,260 --> 00:05:37,520
 a directory, like a program guide.

98
00:05:37,520 --> 00:05:39,220
 You might think of it.

99
00:05:39,220 --> 00:05:45,980
 And normally, your laptop, those employees'
 laptops, are seeing all kinds

100
00:05:45,980 --> 00:05:47,120
 of Ethernet frames.

101
00:05:47,120 --> 00:05:49,940
 If you think about, if you're sitting in
 a cube right now and you're actually

102
00:05:49,940 --> 00:05:54,140
 hardwired via a hardwired Ethernet connection,
 that Ethernet connection

103
00:05:54,140 --> 00:05:56,580
 is seeing a lot of different
 Ethernet frames, right?

104
00:05:56,580 --> 00:05:58,400
 Not just frames for you.

105
00:05:58,400 --> 00:06:03,460
 So at layer two, your Ethernet-NIC card
 says, okay, if every single frame

106
00:06:03,460 --> 00:06:07,180
 I'm seeing, which could be tens of thousands
 of them per second, flying

107
00:06:07,180 --> 00:06:11,080
 by, it looks at the destination MAC address
 of each and every one of those

108
00:06:11,080 --> 00:06:13,920
 frames. And it asks
 itself a question.

109
00:06:13,920 --> 00:06:17,260
 It says, is that destination
 MAC address a broadcast?

110
00:06:17,260 --> 00:06:21,560
 If it is, I got to pick it up, send
 it to my CPU and process it.

111
00:06:21,560 --> 00:06:26,360
 Or, is it a unicast MAC address,
 which is my MAC address?

112
00:06:26,360 --> 00:06:29,000
 If so, I'll pick it
 up and process it.

113
00:06:29,000 --> 00:06:32,560
 If the answer is no, to either one
 of those questions, just let it fly

114
00:06:32,560 --> 00:06:34,240
 on by and don't pick it up.

115
00:06:34,240 --> 00:06:35,640
 Don't process it.

116
00:06:35,640 --> 00:06:39,220
 So when you go into your multicast application,
 your directory, your program

117
00:06:39,220 --> 00:06:40,600
 guide, and you...

118
00:06:40,600 --> 00:06:44,880
 So first of all, there has to be
 some server out there, right?

119
00:06:44,880 --> 00:06:49,280
 Probably a web server that's dishing
 up this web page, this page that

120
00:06:49,280 --> 00:06:50,120
 you're looking at.

121
00:06:50,120 --> 00:06:54,660
 And, you know, when you go to that server,
 when you go to employee.stream

122
00:06:54,660 --> 00:06:58,980
.com or something like that, and you
 get this web page back, the web page

123
00:06:58,980 --> 00:07:02,700
 lists every single show that's either
 going right now or will go at a

124
00:07:02,700 --> 00:07:07,740
 scheduled time. And then you probably
 don't see this visually in the GUI,

125
00:07:07,740 --> 00:07:11,860
 but also that web page when it was delivered
 to your laptop in the background

126
00:07:11,860 --> 00:07:18,320
 should have listed the multicast group
 address for each one of those shows.

127
00:07:18,320 --> 00:07:22,220
 So when you click on that, what you're
 actually doing is you're programming

128
00:07:22,220 --> 00:07:25,440
 your net card. You're telling the net
 card, okay, in addition to picking

129
00:07:25,440 --> 00:07:29,840
 up broadcasts and unicasts going to
 me, now I want you to look for the

130
00:07:29,840 --> 00:07:33,700
 special layer two MAC address, which
 is a multicast MAC address.

131
00:07:33,700 --> 00:07:37,140
 If you see that, send that
 to my processor as well.

132
00:07:37,140 --> 00:07:41,540
 I want to see it so it gets displayed
 in my Windows Media Player or my

133
00:07:41,540 --> 00:07:44,440
 Real Player, whatever it
 is that you're watching.

134
00:07:44,440 --> 00:07:45,760
 That's one thing that happens.

135
00:07:45,760 --> 00:07:49,520
 Something has to happen so that your
 net card says, ah, I now need to

136
00:07:49,520 --> 00:07:50,620
 look for something else.

137
00:07:50,620 --> 00:07:52,220
 I need to look for this multicast.

138
00:07:52,220 --> 00:07:56,420
 Now, in addition, when you click on
 that link there to wake up your net

139
00:07:56,420 --> 00:08:00,240
 card, you're also generating
 an IGMP packet.

140
00:08:00,240 --> 00:08:03,180
 We'll go into that in detail in a subsequent
 video, but you're sending

141
00:08:03,180 --> 00:08:07,000
 an IGMP packet to your router, to your
 default gateway, and you're saying,

142
00:08:07,000 --> 00:08:10,540
 hey, if you ever see this
 multicast, send it to me.

143
00:08:10,540 --> 00:08:14,540
 I'm interested. I would like
 to receive that traffic.

144
00:08:14,540 --> 00:08:17,620
 So in multicast terminology, that means
 that your laptop is what's called

145
00:08:17,620 --> 00:08:19,640
 a multicast receiver.

146
00:08:19,640 --> 00:08:21,300
 You've now become a receiver.

147
00:08:21,300 --> 00:08:25,520
 So my example with my 60 employees
 in engineering that wanted to watch

148
00:08:25,520 --> 00:08:29,680
 the stream, each one of them has to open
 up their browser or open up some

149
00:08:29,680 --> 00:08:34,580
 application and click on that link that
 says, CEOs address to engineering

150
00:08:34,580 --> 00:08:37,100
 today at 2 p.m. So
 they click on that.

151
00:08:37,100 --> 00:08:40,860
 In the process of doing that, it programs
 their net card, so they'll now

152
00:08:40,860 --> 00:08:42,580
 pay attention to those frames.

153
00:08:42,580 --> 00:08:45,900
 Each one of their laptops sends out an
 IGMP message to their default gateway

154
00:08:45,900 --> 00:08:47,900
 saying, hey, I want to see this.

155
00:08:47,900 --> 00:08:52,080
 And then in the background, their default
 gateway invokes a multicast

156
00:08:52,080 --> 00:08:54,700
 routing protocol, probably PIM.

157
00:08:54,700 --> 00:08:58,780
 And then PIM gets involved and PIM builds
 this, what's called multicast

158
00:08:58,780 --> 00:09:05,500
 tree, so that eventually, when that server
 sends out its very first multicast

159
00:09:05,500 --> 00:09:10,860
 packet that contains maybe one tenth
 of a second of video, when it hits

160
00:09:10,860 --> 00:09:15,640
 the very first router that's connected
 to that server, that router says,

161
00:09:15,640 --> 00:09:19,020
 ah, I know where to send this, because
 I got a PIM message just a couple

162
00:09:19,020 --> 00:09:23,220
 of minutes ago out my fast ethernet interface
 that said, be on the lookout

163
00:09:23,220 --> 00:09:24,940
 for this. I want it.

164
00:09:24,940 --> 00:09:29,320
 And I also got a message on my fast
 ethernet 1-1 interface from another

165
00:09:29,320 --> 00:09:31,280
 part of the campus
 saying, I want it.

166
00:09:31,280 --> 00:09:34,160
 And so now it's the router's responsibility
 to take that one multicast

167
00:09:34,160 --> 00:09:36,700
 packet that came in
 and replicate it.

168
00:09:36,700 --> 00:09:41,640
 It sends one copy out, one interface,
 another copy out, the other interface.

169
00:09:41,640 --> 00:09:45,400
 And that goes on and on and on, as these
 multicast packet goes from the

170
00:09:45,400 --> 00:09:51,140
 source, which is the server, as it hits
 routers, each router in turn asks

171
00:09:51,140 --> 00:09:55,680
 itself, do I have an entry in my multicast
 routing table to let me know

172
00:09:55,680 --> 00:09:57,040
 where this thing goes?

173
00:09:57,040 --> 00:10:01,080
 And if the answer is yes, do
 I have more than one entry?

174
00:10:01,080 --> 00:10:04,640
 Do I need to replicate this packet and
 send it out more than one interface?

175
00:10:04,640 --> 00:10:10,000
 And eventually it hits the default gateway
 of one of those people in engineering.

176
00:10:10,000 --> 00:10:14,760
 The default gateway says, ah, yes, I've
 got an interface that via IgMP,

177
00:10:14,760 --> 00:10:17,560
 I learned that there's a host out there,
 a receiver that wants to get

178
00:10:17,560 --> 00:10:20,700
 it, and it forwards the multicast
 to that person.

179
00:10:20,700 --> 00:10:23,440
 So only the interested
 receivers get it.

180
00:10:23,440 --> 00:10:28,180
 None of the other laptops get it, because
 they did not click on that link.

181
00:10:28,180 --> 00:10:32,120
 They did not program their NIC card
 to be interested in that multicast

182
00:10:32,120 --> 00:10:35,840
 MAC address. So that's what
 we mean by one to many.

183
00:10:35,840 --> 00:10:39,460
 Long answer to a very
 short bullet.

184
00:10:39,460 --> 00:10:42,780
 So there's a lot of useful
 applications to multicast.

185
00:10:42,780 --> 00:10:45,760
 As I mentioned, video, video
 conferencing, for example.

186
00:10:45,760 --> 00:10:49,800
 A lot of times if you're internal to
 an organization, multicast will be

187
00:10:49,800 --> 00:10:51,200
 used for video conferencing.

188
00:10:51,200 --> 00:10:54,160
 Some sort of corporate communications,
 like I mentioned, where the CEO

189
00:10:54,160 --> 00:10:57,560
 is blasting out a multicast
 at a certain time of day.

190
00:10:57,560 --> 00:11:01,080
 Sometimes distance learning
 will use this as well.

191
00:11:01,080 --> 00:11:04,820
 For example, when you're watching me
 and you're seeing this video right

192
00:11:04,820 --> 00:11:08,260
 now, if you're actually part of the
 live audience, you may actually be

193
00:11:08,260 --> 00:11:10,060
 receiving this via multicast.

194
00:11:10,060 --> 00:11:13,360
 I know we use a company
 called BitGravity.

195
00:11:13,360 --> 00:11:16,400
 That's the actual company that we use
 to propagate this throughout the

196
00:11:16,400 --> 00:11:20,580
 world. And I think BitGravity actually
 does use multicast to pass it on

197
00:11:20,580 --> 00:11:22,580
 down. Not sure about that though.

198
00:11:22,580 --> 00:11:25,960
 But you could certainly open up a sniffer
 like Wireshark on your own local

199
00:11:25,960 --> 00:11:28,280
 laptop and find out.

200
00:11:28,280 --> 00:11:33,140
 And sometimes the distribution of software,
 stock quotes, news, all of

201
00:11:33,140 --> 00:11:37,060
 that stuff is also used
 in multicast frequently.

202
00:11:37,060 --> 00:11:43,100
 Also somebody in the live audience has
 mentioned another good use of multicast

203
00:11:43,100 --> 00:11:48,740
 that he says at an airport, there
 are IP cameras that use multicast.

204
00:11:48,740 --> 00:11:49,760
 Good observation.

205
00:11:49,760 --> 00:11:53,860
 So probably within the terminal itself,
 security uses these cameras to

206
00:11:53,860 --> 00:11:54,380
 watch everything.

207
00:11:54,380 --> 00:12:01,520
 It's multicasted back to some server
 or cameras in the parking lot, which

208
00:12:01,520 --> 00:12:03,420
 multicast everything.

209
00:12:03,420 --> 00:12:09,480
 So great. Thank you, John,
 for mentioning that.

210
00:12:09,480 --> 00:12:13,480
 So we talked a little bit about
 locating the multicast server.

211
00:12:13,480 --> 00:12:21,280
 In other words, your laptop at the very
 beginning has no idea what multicasts

212
00:12:21,280 --> 00:12:25,060
 are going on. It has no idea if there's
 any multicast servers out there,

213
00:12:25,060 --> 00:12:27,740
 which technically we call
 multicast sources.

214
00:12:27,740 --> 00:12:33,520
 So some sort of unicast application
 has to be opened first, which will

215
00:12:33,520 --> 00:12:37,780
 display a listing for you, a directory
 listing or a program guide of the

216
00:12:37,780 --> 00:12:40,620
 various multicasts
 that are available.

217
00:12:40,620 --> 00:12:47,180
 And that's how your laptop very first
 learns potentially of a source.

218
00:12:47,180 --> 00:12:49,720
 Now, it may not know of a source.

219
00:12:49,720 --> 00:12:54,380
 For example, maybe in my example with
 the CEO who's going to be doing

220
00:12:54,380 --> 00:12:56,140
 the video conferencing.

221
00:12:56,140 --> 00:13:01,580
 We've got several different media studios
 throughout the campus, right?

222
00:13:01,580 --> 00:13:03,980
 Maybe my campus stretches
 across the whole city.

223
00:13:03,980 --> 00:13:06,740
 I've got like 10 different campuses
 throughout the city.

224
00:13:06,740 --> 00:13:10,900
 And each one of the campuses of my company
 has a video studio in it with

225
00:13:10,900 --> 00:13:15,320
 a camera and a server, which is capable
 of multicasting something out.

226
00:13:15,320 --> 00:13:19,780
 So it's because it's spread throughout
 my organization, those servers

227
00:13:19,780 --> 00:13:22,440
 have clearly different
 IP addresses.

228
00:13:22,440 --> 00:13:26,080
 They're not all geographically
 located in the same subnet.

229
00:13:26,080 --> 00:13:31,420
 So we don't know before the multicast
 happens what the actual IP address

230
00:13:31,420 --> 00:13:34,760
 is of the server that's going to be
 doing this because you and me who's

231
00:13:34,760 --> 00:13:38,960
 sitting on our desk, we have no idea
 which particular studio the CEO is

232
00:13:38,960 --> 00:13:42,820
 going to be in. Maybe they're even purposely
 keeping that secret because

233
00:13:42,820 --> 00:13:46,120
 they don't want somebody to attack and
 bomb that studio or something else.

234
00:13:46,120 --> 00:13:51,460
 Who knows? So a lot of times when your
 laptop first learns of the multicast

235
00:13:51,460 --> 00:13:56,520
 stream via that directory listing that
 program guide, it'll know what

236
00:13:56,520 --> 00:13:58,100
 the destination address is.

237
00:13:58,100 --> 00:14:01,320
 They'll say, okay, if I receive this
 video, it's going to be going to

238
00:14:01,320 --> 00:14:02,920
 this destination address.

239
00:14:02,920 --> 00:14:04,320
 And that's what I want
 to pick up on.

240
00:14:04,320 --> 00:14:09,200
 But it might have no clue as to what
 the actual source address is the

241
00:14:09,200 --> 00:14:12,320
 unicast source of that
 multicast stream.

242
00:14:12,320 --> 00:14:14,240
 And by the way, that's
 a very critical point.

243
00:14:14,240 --> 00:14:21,040
 Multicast addresses 99% of the time,
 not always, but 99% of the time only

244
00:14:21,040 --> 00:14:26,040
 show up in the destination portion of an
 Ethernet MAC address or the destination

245
00:14:26,040 --> 00:14:28,080
 of an IP before or IPP.

246
00:14:28,080 --> 00:14:30,300
 So it's going to be 6, packet.

247
00:14:30,300 --> 00:14:33,020
 Very, very rarely will
 be in the source.

248
00:14:33,020 --> 00:14:37,240
 Most of the time, the source address
 is a unicast address because it's

249
00:14:37,240 --> 00:14:41,580
 coming from one physical server
 that's doing the multicasting.

250
00:14:41,580 --> 00:14:45,100
 Now, I've heard there are some firewalls
 and stuff out there that do sort

251
00:14:45,100 --> 00:14:48,720
 of weird multicasting where they do
 it in the source and that's a whole

252
00:14:48,720 --> 00:14:52,260
 other ball of worms, but most of the
 time, the multicast address will

253
00:14:52,260 --> 00:14:53,860
 only be in the destination.

254
00:14:53,860 --> 00:14:56,740
 So my laptop doesn't know
 what the source is.

255
00:14:56,740 --> 00:15:02,800
 It says, look, I want to watch my CEO
 and it says the destination address,

256
00:15:02,800 --> 00:15:06,360
 I'll click on that, program my knit
 car, but it doesn't know the source.

257
00:15:06,360 --> 00:15:10,720
 So sometimes the way these multicast
 routing protocols start up is that

258
00:15:10,720 --> 00:15:14,960
 the routers don't know where
 the source is either.

259
00:15:14,960 --> 00:15:17,300
 The source just has to start.

260
00:15:17,300 --> 00:15:20,880
 The multicast server just has to start
 pumping out multicast data onto

261
00:15:20,880 --> 00:15:25,460
 the wire. And then when the very first
 router gets that, so you might

262
00:15:25,460 --> 00:15:28,120
 say the default gateway
 for that server.

263
00:15:28,120 --> 00:15:32,420
 When that very first router gets it,
 he says, hmm, okay, this is the first

264
00:15:32,420 --> 00:15:35,480
 time I've seen this source
 sending the stream.

265
00:15:35,480 --> 00:15:39,200
 Don't know if anybody is interested
 in watching it because after all,

266
00:15:39,200 --> 00:15:42,500
 none of the other routers would have
 talked to this guy because they have

267
00:15:42,500 --> 00:15:44,460
 no idea where the source is.

268
00:15:44,460 --> 00:15:48,800
 So this router might say, okay, well,
 I've got two choices I can do here.

269
00:15:48,800 --> 00:15:52,720
 If I'm not running a multicast routing
 protocol, drop the traffic, just

270
00:15:52,720 --> 00:15:58,600
 kill it. If I am running a multicast
 routing protocol, chances are that

271
00:15:58,600 --> 00:16:02,980
 router that's receiving the multicast
 will say, okay, I don't know where

272
00:16:02,980 --> 00:16:05,880
 the receivers are, where the hosts
 are that want to get this.

273
00:16:05,880 --> 00:16:11,580
 But there is some central router in
 my topology that's running a special

274
00:16:11,580 --> 00:16:14,480
 feature of my route multicast
 routing protocol.

275
00:16:14,480 --> 00:16:19,040
 He knows where everybody is because everybody
 has told him all the routers

276
00:16:19,040 --> 00:16:23,960
 have said, hey, Joe router, if you
 ever get this multicast, don't know

277
00:16:23,960 --> 00:16:24,880
 if you are or not.

278
00:16:24,880 --> 00:16:28,060
 But if you ever see this destination,
 send it to us.

279
00:16:28,060 --> 00:16:31,280
 So there's some central router sitting
 here topology that says, okay,

280
00:16:31,280 --> 00:16:34,660
 I've heard how this interface, this
 interface and this interface that

281
00:16:34,660 --> 00:16:36,020
 there's people down there.

282
00:16:36,020 --> 00:16:39,800
 Waiting to get this particular
 multicast destination.

283
00:16:39,800 --> 00:16:43,060
 And now the default gateway says, let
 me take this multicast and send

284
00:16:43,060 --> 00:16:47,460
 it to him. And he can then distribute
 it down the tree.

285
00:16:47,460 --> 00:16:51,360
 So a lot of times in your typical multicast,
 the source address of where

286
00:16:51,360 --> 00:16:53,660
 it's coming from will be unknown.

287
00:16:53,660 --> 00:16:56,520
 There are some circumstances where it
 is known and we'll talk about that,

288
00:16:56,520 --> 00:17:01,520
 especially when we get
 to I GMP version three.

289
00:17:01,520 --> 00:17:05,780
 We also have to talk about multicast
 distribution methods, the push versus

290
00:17:05,780 --> 00:17:11,420
 the pull model. So let me draw something
 here quickly to demonstrate that.

291
00:17:11,420 --> 00:17:16,880
 Let's say that this is my
 multicast server here.

292
00:17:16,880 --> 00:17:21,680
 And he's connected to router one.

293
00:17:21,680 --> 00:17:35,280
 And then let's just draw
 some other routers.

294
00:17:35,280 --> 00:17:42,440
 Okay, let's just say router two, three,
 four, five, and six, seven, eight,

295
00:17:42,440 --> 00:17:51,680
 nine. Okay, so there's two different sort
 of high level ways that multicast

296
00:17:51,680 --> 00:17:54,360
 routing protocols work.

297
00:17:54,360 --> 00:17:57,460
 One way is what we call
 the push model.

298
00:17:57,460 --> 00:18:02,120
 You'll also frequently hear this referred
 to as dense mode protocols.

299
00:18:02,120 --> 00:18:08,820
 So in a dense mode protocol, what happens
 is that let's say that my interested

300
00:18:08,820 --> 00:18:13,680
 receivers are right
 here and right here.

301
00:18:13,680 --> 00:18:18,200
 So these two PCs in red are the only
 PCs that have ever expressed any

302
00:18:18,200 --> 00:18:22,440
 interest in receiving the
 multicast video or audio.

303
00:18:22,440 --> 00:18:28,600
 Well, in a dense mode application,
 what we call a push model, when the

304
00:18:28,600 --> 00:18:33,540
 multicast server starts sending out
 his traffic, everything's flooded.

305
00:18:33,540 --> 00:18:39,760
 It goes out to every single
 router like this.

306
00:18:39,760 --> 00:18:43,360
 And so yeah, it actually
 will get to our client.

307
00:18:43,360 --> 00:18:48,600
 And the idea is, as it reaches routers
 that are not interested in this

308
00:18:48,600 --> 00:18:52,820
 multicast traffic, they'll send some
 sort of signaling message back, which

309
00:18:52,820 --> 00:18:59,360
 will prune off branches
 that don't need it.

310
00:18:59,360 --> 00:19:03,460
 And so at the end, after this pushing
 has taken place, oops, I don't want

311
00:19:03,460 --> 00:19:05,600
 to erase that one, that
 one needs to be there.

312
00:19:05,600 --> 00:19:10,720
 After the pushing takes place and the
 pruning takes place after that,

313
00:19:10,720 --> 00:19:14,060
 now we're left with the multicast only
 being forwarded out interfaces

314
00:19:14,060 --> 00:19:15,660
 where it needs to go.

315
00:19:15,660 --> 00:19:21,280
 Now, if all of these links are very
 high speed links, like let's say all

316
00:19:21,280 --> 00:19:25,460
 of this is within your campus, and
 all these links are like 10 gigabit

317
00:19:25,460 --> 00:19:28,980
 links or faster, you know, terabit
 links or something, then you could

318
00:19:28,980 --> 00:19:32,200
 probably do this because you've got
 plenty of bandwidth to spare.

319
00:19:32,200 --> 00:19:35,160
 You know, who cares if the multicast
 gets flooded out interfaces where

320
00:19:35,160 --> 00:19:37,800
 it doesn't need to go because you've
 got plenty of bandwidth anyway, so

321
00:19:37,800 --> 00:19:39,420
 just prune it off.

322
00:19:39,420 --> 00:19:43,260
 But chances are, your network
 probably isn't like that.

323
00:19:43,260 --> 00:19:46,820
 You've probably got certain links,
 our slowed speed links, maybe other

324
00:19:46,820 --> 00:19:50,320
 links that typically experience congestion
 because they're very popular,

325
00:19:50,320 --> 00:19:53,780
 and you really don't want your multicast
 being flooded everywhere.

326
00:19:53,780 --> 00:19:57,340
 So in that case, the type of multicast
 distribution method you want to

327
00:19:57,340 --> 00:20:01,540
 use is not a push model,
 but rather a pull model.

328
00:20:01,540 --> 00:20:06,120
 And that's like what I've been
 talking about to this point.

329
00:20:06,120 --> 00:20:16,800
 So in a pull model, typically what has
 to happen first is that the multicast

330
00:20:16,800 --> 00:20:23,180
 receivers, which are my laptops, have to
 send some sort of packet to indicate

331
00:20:23,180 --> 00:20:28,200
 their interest in this multicast saying,
 hey, I want to receive it.

332
00:20:28,200 --> 00:20:33,560
 And then usually there's some router
 that's configured in this network

333
00:20:33,560 --> 00:20:36,340
 with a very special functionality.

334
00:20:36,340 --> 00:20:42,700
 Let's just say it's router two,
 and I'll use the letters RP.

335
00:20:42,700 --> 00:20:46,620
 Now that you'll learn a lot more about
 this when you learn about PIM protocol

336
00:20:46,620 --> 00:20:51,760
 independent multicast at layer three,
 but this is called the rendezvous

337
00:20:51,760 --> 00:20:55,300
 point. Now think about that term
 for a second, rendezvous, right?

338
00:20:55,300 --> 00:20:58,960
 If I'm talking to my friend, I say,
 hey, where do you want to meet today

339
00:20:58,960 --> 00:21:00,220
 so we can have lunch?

340
00:21:00,220 --> 00:21:04,220
 Maybe my friend says, oh, let's meet at
 TGI Fridays for lunch, that restaurant.

341
00:21:04,220 --> 00:21:08,640
 I might say, OK, I'll rendezvous with you
 over there, which means rendezvous.

342
00:21:08,640 --> 00:21:11,420
 I'll meet with you
 at that location.

343
00:21:11,420 --> 00:21:15,420
 So in the world of multicast, a rendezvous
 point basically serves the

344
00:21:15,420 --> 00:21:21,180
 same purpose. So once my receivers,
 and these are most likely going to

345
00:21:21,180 --> 00:21:27,160
 be IGMP, or if we're talking about IPv6,
 the MLDP, the multicast listener

346
00:21:27,160 --> 00:21:30,120
 protocol, either way, I'll
 just do both of them here.

347
00:21:30,120 --> 00:21:34,080
 Actually, let's keep
 it with IPv4 for now.

348
00:21:34,080 --> 00:21:44,800
 So IGMP. So my receivers have indicated
 interest to their default gateways.

349
00:21:44,800 --> 00:21:50,860
 Now, nobody knows at this point what the
 actual IP address is of the source

350
00:21:50,860 --> 00:21:52,640
 of the multicast.

351
00:21:52,640 --> 00:21:56,080
 Or actually, even if the source actually
 exists yet, this might just be

352
00:21:56,080 --> 00:21:59,620
 a test stream and it hasn't
 even been configured yet.

353
00:21:59,620 --> 00:22:03,080
 So, but these routers, if they're running
 a multicast rendezvous protocol,

354
00:22:03,080 --> 00:22:07,660
 what they do know is the IP address of
 this guy, router two, our rendezvous

355
00:22:07,660 --> 00:22:13,300
 point. So once they receive an indication
 from their receivers, that the

356
00:22:13,300 --> 00:22:17,940
 receivers want to receive multicast,
 now these routers are going to send

357
00:22:17,940 --> 00:22:24,060
 special messages, some multicast routing
 messages, up to the rendezvous

358
00:22:24,060 --> 00:22:29,020
 point, saying, hey, router two, if
 you ever happen to see a multicast

359
00:22:29,020 --> 00:22:32,240
 that matches this destination,
 we're down here.

360
00:22:32,240 --> 00:22:33,600
 We want to get it.

361
00:22:33,600 --> 00:22:36,320
 And so now the rendezvous point says,
 okay, I haven't received anything

362
00:22:36,320 --> 00:22:41,680
 yet, but if I ever do, I received a
 message on this interface and this

363
00:22:41,680 --> 00:22:45,080
 interface that someone's down
 there that wants to get it.

364
00:22:45,080 --> 00:22:48,280
 And so now the rendezvous point just
 sits around twiddling his thumbs,

365
00:22:48,280 --> 00:22:50,880
 waiting to see if the multicast
 will ever start up.

366
00:22:50,880 --> 00:22:56,080
 Now, let's just say a few minutes or maybe
 an hour later, the actual multicast

367
00:22:56,080 --> 00:23:01,980
 does start up. Okay, well, this is
 great because now we have this tree

368
00:23:01,980 --> 00:23:03,540
 ready and waiting.

369
00:23:03,540 --> 00:23:06,200
 So these lines here, these red
 lines have just formed a tree.

370
00:23:06,200 --> 00:23:09,540
 These are branches of the tree leading
 from the rendezvous point down

371
00:23:09,540 --> 00:23:12,740
 to our receivers, where our receivers
 are ready and waiting to receive

372
00:23:12,740 --> 00:23:18,180
 this. So once the multicast actually
 starts up, look at router one here.

373
00:23:18,180 --> 00:23:21,400
 He never received any
 of these red arrows.

374
00:23:21,400 --> 00:23:27,020
 Router number one never received a request
 for this stream because he's

375
00:23:27,020 --> 00:23:31,460
 not the rendezvous point and he's not
 in the path of the rendezvous point.

376
00:23:31,460 --> 00:23:35,840
 But just like all these other routers,
 he knows who the rendezvous point

377
00:23:35,840 --> 00:23:41,080
 is. So he takes that multicast and forwards
 it to the rendezvous point.

378
00:23:41,080 --> 00:23:45,800
 And now the rendezvous point says, oh,
 okay, somebody has already asked

379
00:23:45,800 --> 00:23:49,540
 for it. They're asking to pull the
 multicast down to them, and I know

380
00:23:49,540 --> 00:23:53,380
 where they are. So now we'll send the
 multicast down this way, and it

381
00:23:53,380 --> 00:23:56,500
 goes down to my intended
 receivers.

382
00:23:56,500 --> 00:23:59,220
 So we call that a pull model.

383
00:23:59,220 --> 00:24:02,840
 Remember in the push model, which is
 what we call dense mode protocols,

384
00:24:02,840 --> 00:24:05,660
 the multicast starts out and
 is flooded everywhere.

385
00:24:05,660 --> 00:24:09,220
 And it's up to the routers to send
 messages back upstream saying, hey,

386
00:24:09,220 --> 00:24:10,240
 I never wanted this.

387
00:24:10,240 --> 00:24:12,020
 Stop flooding it to me.

388
00:24:12,020 --> 00:24:16,860
 In a pull model, which we typically
 call sparse mode protocols, sparse

389
00:24:16,860 --> 00:24:22,300
 mode, this is where the receivers have
 to indicate their interest, and

390
00:24:22,300 --> 00:24:27,440
 then the routers have to forward that
 interest up to some central router

391
00:24:27,440 --> 00:24:29,100
 that we call a rendezvous point.

392
00:24:29,100 --> 00:24:33,300
 So we pre-build the
 path in advance.

393
00:24:33,300 --> 00:24:37,500
 And then once the multicast comes in,
 all the routers know what that path

394
00:24:37,500 --> 00:24:40,820
 is, and where to forward
 that multicast.

395
00:24:40,820 --> 00:24:46,600
 So those are the two typical modes of
 multicast routing protocols, push

396
00:24:46,600 --> 00:24:51,560
 modes and pull modes, or otherwise known
 as dense mode protocols and sparse