So any introduction to multicast video has to start out with the basics
of multicast, what it is, where it's used, and how to recognize a multicast
packet at layer 3 and a multicast ethernet frame at layer 2.
So that's what we're going to look at right now.
So let's start talking about why multicast.
So multicast is what we refer to as one to many.
In other words, I'm sure you know what a unicast is, right?
A unicast is there's some web server out there that's sending a packet
unicast to your laptop and your laptop only.
And that packet contains like a web page or something inside of it.
So that's a one-to -one transmission.
And I'm sure you know what a broadcast is, right?
A broadcast is something that goes out to everybody.
And we know that routers kill broadcast.
When a broadcast reaches a router's layer 3 interface, it stops.
Or in the case of a multi-layer switch that has switched virtual interfaces,
if you're using your switch as a router, same thing.
Any layer 3 interface stops a broadcast dead in its tracks.
So multicast is like in the middle of that, we call it one to many.
For example, typical use case of multicast is for what's called streaming
video. So let's say, for example, that my CEO of my company is scheduled
at 2 o'clock today to deliver a state of the company address.
Well, let's actually make it more specific.
A state of engineering address, OK?
So he's going to get up there and talk specifically about the engineering
department, engineering focus and vision.
And that's what he's going to talk about.
So and in our engineering department, we have maybe 100 employees scattered
throughout the campus.
They don't all sit together.
They sit in sort of pockets here and there.
Well, so we got a video camera at 2 o'clock, trained on my CEO.
That video camera is then going back to a server which is digitizing the
video. And so now we got to think about, OK, how am I going to send that
video stream out to those 100 employees?
And maybe not even all of them want to see it, right?
Maybe some of those employees are on vacation and their laptops are here
and they're running.
They're locked to the desk, but they're just gone.
The employees not here.
Others, employees could just care less.
They think the CEO is full of hot air and they don't watch the videos
anymore. They don't watch the streams.
So there's going to be a subset of employees and engineering that want
to watch this video stream.
So how do we get it to them?
Let's say that of the 100 employees, maybe 60, 60 of them want to watch
this video stream.
Well, if you've ever researched anything about multicast video, one of
the characteristics of multicast video is that typically it's very bandwidth
hungry. Multicast video consumes a lot of bandwidth, especially if you're
talking about an HD like a high definition video stream.
It can really consume a lot of bandwidth.
So if I have my multicast server so that's connected to that camera, that's
digitizing, turning into an MPEG or an ABI or something like that, it's
going to send it out as a multicast, well, we've got some options.
We could send it out as a unicast stream where each one of those 60 employees
has to click on some web page, which sends a unicast message to my server
and then my server's CPU has to create a copy of the packet and send it
to that person. So now imagine if all 60 people were doing that, that
would be asking that server to do a lot of work.
It'd have to take that video stream, which might be, let's just make it
easy, 256 kilobits per second.
And that's a pretty slow stream.
That's pretty small bandwidth stream.
Imagine 256 kilobits per second packets and it has to replicate that 60
times for 60 individual unicast streams.
Chances are the server would have a real tough time doing that.
And imagine what kind of load that would put on the actual network infrastructure.
That's 256 kilobits per second times 60 unicast streams.
Probably don't want to do that.
And you say, well, why don't I just broadcast it?
Well, number one, broadcast can't get to everybody because we know that
routers drop broadcasts.
And I said that these employees were scattered throughout the campus.
They're not all sitting together.
And even if I theoretically could get my routers to force them to flood
this broadcast, well, that's going to be impacting everybody in my company.
It's going to be impacting the payroll and the human resources and the
marketing departments because all of their links are going to be saturated
with this broadcast traffic that has the video in it.
So this is where multicast comes into play.
So with multicast, the server only has to create one stream of traffic,
one stream of traffic.
And that one stream of traffic is going to a special, what they call group
destination address or GDA.
And just a moment, I'll show you what those look like.
Now, you might be wondering, well, how do we get it to where of all the
people in my company, only those 60 people in engineering will actually
get that stream.
How does that work?
Well, it's basically a multi-part process.
So number one, the employees have to have some sort of application on
their laptop. It might be embedded into their web browser.
But they have to have something that they can click on to see a listing
of all the multicast streams that are currently happening right now, like
a directory, like a program guide.
You might think of it.
And normally, your laptop, those employees' laptops, are seeing all kinds
of Ethernet frames.
If you think about, if you're sitting in a cube right now and you're actually
hardwired via a hardwired Ethernet connection, that Ethernet connection
is seeing a lot of different Ethernet frames, right?
Not just frames for you.
So at layer two, your Ethernet-NIC card says, okay, if every single frame
I'm seeing, which could be tens of thousands of them per second, flying
by, it looks at the destination MAC address of each and every one of those
frames. And it asks itself a question.
It says, is that destination MAC address a broadcast?
If it is, I got to pick it up, send it to my CPU and process it.
Or, is it a unicast MAC address, which is my MAC address?
If so, I'll pick it up and process it.
If the answer is no, to either one of those questions, just let it fly
on by and don't pick it up.
Don't process it.
So when you go into your multicast application, your directory, your program
guide, and you...
So first of all, there has to be some server out there, right?
Probably a web server that's dishing up this web page, this page that
you're looking at.
And, you know, when you go to that server, when you go to employee.stream
.com or something like that, and you get this web page back, the web page
lists every single show that's either going right now or will go at a
scheduled time. And then you probably don't see this visually in the GUI,
but also that web page when it was delivered to your laptop in the background
should have listed the multicast group address for each one of those shows.
So when you click on that, what you're actually doing is you're programming
your net card. You're telling the net card, okay, in addition to picking
up broadcasts and unicasts going to me, now I want you to look for the
special layer two MAC address, which is a multicast MAC address.
If you see that, send that to my processor as well.
I want to see it so it gets displayed in my Windows Media Player or my
Real Player, whatever it is that you're watching.
That's one thing that happens.
Something has to happen so that your net card says, ah, I now need to
look for something else.
I need to look for this multicast.
Now, in addition, when you click on that link there to wake up your net
card, you're also generating an IGMP packet.
We'll go into that in detail in a subsequent video, but you're sending
an IGMP packet to your router, to your default gateway, and you're saying,
hey, if you ever see this multicast, send it to me.
I'm interested. I would like to receive that traffic.
So in multicast terminology, that means that your laptop is what's called
a multicast receiver.
You've now become a receiver.
So my example with my 60 employees in engineering that wanted to watch
the stream, each one of them has to open up their browser or open up some
application and click on that link that says, CEOs address to engineering
today at 2 p.m. So they click on that.
In the process of doing that, it programs their net card, so they'll now
pay attention to those frames.
Each one of their laptops sends out an IGMP message to their default gateway
saying, hey, I want to see this.
And then in the background, their default gateway invokes a multicast
routing protocol, probably PIM.
And then PIM gets involved and PIM builds this, what's called multicast
tree, so that eventually, when that server sends out its very first multicast
packet that contains maybe one tenth of a second of video, when it hits
the very first router that's connected to that server, that router says,
ah, I know where to send this, because I got a PIM message just a couple
of minutes ago out my fast ethernet interface that said, be on the lookout
for this. I want it.
And I also got a message on my fast ethernet 1-1 interface from another
part of the campus saying, I want it.
And so now it's the router's responsibility to take that one multicast
packet that came in and replicate it.
It sends one copy out, one interface, another copy out, the other interface.
And that goes on and on and on, as these multicast packet goes from the
source, which is the server, as it hits routers, each router in turn asks
itself, do I have an entry in my multicast routing table to let me know
where this thing goes?
And if the answer is yes, do I have more than one entry?
Do I need to replicate this packet and send it out more than one interface?
And eventually it hits the default gateway of one of those people in engineering.
The default gateway says, ah, yes, I've got an interface that via IgMP,
I learned that there's a host out there, a receiver that wants to get
it, and it forwards the multicast to that person.
So only the interested receivers get it.
None of the other laptops get it, because they did not click on that link.
They did not program their NIC card to be interested in that multicast
MAC address. So that's what we mean by one to many.
Long answer to a very short bullet.
So there's a lot of useful applications to multicast.
As I mentioned, video, video conferencing, for example.
A lot of times if you're internal to an organization, multicast will be
used for video conferencing.
Some sort of corporate communications, like I mentioned, where the CEO
is blasting out a multicast at a certain time of day.
Sometimes distance learning will use this as well.
For example, when you're watching me and you're seeing this video right
now, if you're actually part of the live audience, you may actually be
receiving this via multicast.
I know we use a company called BitGravity.
That's the actual company that we use to propagate this throughout the
world. And I think BitGravity actually does use multicast to pass it on
down. Not sure about that though.
But you could certainly open up a sniffer like Wireshark on your own local
laptop and find out.
And sometimes the distribution of software, stock quotes, news, all of
that stuff is also used in multicast frequently.
Also somebody in the live audience has mentioned another good use of multicast
that he says at an airport, there are IP cameras that use multicast.
Good observation.
So probably within the terminal itself, security uses these cameras to
watch everything.
It's multicasted back to some server or cameras in the parking lot, which
multicast everything.
So great. Thank you, John, for mentioning that.
So we talked a little bit about locating the multicast server.
In other words, your laptop at the very beginning has no idea what multicasts
are going on. It has no idea if there's any multicast servers out there,
which technically we call multicast sources.
So some sort of unicast application has to be opened first, which will
display a listing for you, a directory listing or a program guide of the
various multicasts that are available.
And that's how your laptop very first learns potentially of a source.
Now, it may not know of a source.
For example, maybe in my example with the CEO who's going to be doing
the video conferencing.
We've got several different media studios throughout the campus, right?
Maybe my campus stretches across the whole city.
I've got like 10 different campuses throughout the city.
And each one of the campuses of my company has a video studio in it with
a camera and a server, which is capable of multicasting something out.
So it's because it's spread throughout my organization, those servers
have clearly different IP addresses.
They're not all geographically located in the same subnet.
So we don't know before the multicast happens what the actual IP address
is of the server that's going to be doing this because you and me who's
sitting on our desk, we have no idea which particular studio the CEO is
going to be in. Maybe they're even purposely keeping that secret because
they don't want somebody to attack and bomb that studio or something else.
Who knows? So a lot of times when your laptop first learns of the multicast
stream via that directory listing that program guide, it'll know what
the destination address is.
They'll say, okay, if I receive this video, it's going to be going to
this destination address.
And that's what I want to pick up on.
But it might have no clue as to what the actual source address is the
unicast source of that multicast stream.
And by the way, that's a very critical point.
Multicast addresses 99% of the time, not always, but 99% of the time only
show up in the destination portion of an Ethernet MAC address or the destination
of an IP before or IPP.
So it's going to be 6, packet.
Very, very rarely will be in the source.
Most of the time, the source address is a unicast address because it's
coming from one physical server that's doing the multicasting.
Now, I've heard there are some firewalls and stuff out there that do sort
of weird multicasting where they do it in the source and that's a whole
other ball of worms, but most of the time, the multicast address will
only be in the destination.
So my laptop doesn't know what the source is.
It says, look, I want to watch my CEO and it says the destination address,
I'll click on that, program my knit car, but it doesn't know the source.
So sometimes the way these multicast routing protocols start up is that
the routers don't know where the source is either.
The source just has to start.
The multicast server just has to start pumping out multicast data onto
the wire. And then when the very first router gets that, so you might
say the default gateway for that server.
When that very first router gets it, he says, hmm, okay, this is the first
time I've seen this source sending the stream.
Don't know if anybody is interested in watching it because after all,
none of the other routers would have talked to this guy because they have
no idea where the source is.
So this router might say, okay, well, I've got two choices I can do here.
If I'm not running a multicast routing protocol, drop the traffic, just
kill it. If I am running a multicast routing protocol, chances are that
router that's receiving the multicast will say, okay, I don't know where
the receivers are, where the hosts are that want to get this.
But there is some central router in my topology that's running a special
feature of my route multicast routing protocol.
He knows where everybody is because everybody has told him all the routers
have said, hey, Joe router, if you ever get this multicast, don't know
if you are or not.
But if you ever see this destination, send it to us.
So there's some central router sitting here topology that says, okay,
I've heard how this interface, this interface and this interface that
there's people down there.
Waiting to get this particular multicast destination.
And now the default gateway says, let me take this multicast and send
it to him. And he can then distribute it down the tree.
So a lot of times in your typical multicast, the source address of where
it's coming from will be unknown.
There are some circumstances where it is known and we'll talk about that,
especially when we get to I GMP version three.
We also have to talk about multicast distribution methods, the push versus
the pull model. So let me draw something here quickly to demonstrate that.
Let's say that this is my multicast server here.
And he's connected to router one.
And then let's just draw some other routers.
Okay, let's just say router two, three, four, five, and six, seven, eight,
nine. Okay, so there's two different sort of high level ways that multicast
routing protocols work.
One way is what we call the push model.
You'll also frequently hear this referred to as dense mode protocols.
So in a dense mode protocol, what happens is that let's say that my interested
receivers are right here and right here.
So these two PCs in red are the only PCs that have ever expressed any
interest in receiving the multicast video or audio.
Well, in a dense mode application, what we call a push model, when the
multicast server starts sending out his traffic, everything's flooded.
It goes out to every single router like this.
And so yeah, it actually will get to our client.
And the idea is, as it reaches routers that are not interested in this
multicast traffic, they'll send some sort of signaling message back, which
will prune off branches that don't need it.
And so at the end, after this pushing has taken place, oops, I don't want
to erase that one, that one needs to be there.
After the pushing takes place and the pruning takes place after that,
now we're left with the multicast only being forwarded out interfaces
where it needs to go.
Now, if all of these links are very high speed links, like let's say all
of this is within your campus, and all these links are like 10 gigabit
links or faster, you know, terabit links or something, then you could
probably do this because you've got plenty of bandwidth to spare.
You know, who cares if the multicast gets flooded out interfaces where
it doesn't need to go because you've got plenty of bandwidth anyway, so
just prune it off.
But chances are, your network probably isn't like that.
You've probably got certain links, our slowed speed links, maybe other
links that typically experience congestion because they're very popular,
and you really don't want your multicast being flooded everywhere.
So in that case, the type of multicast distribution method you want to
use is not a push model, but rather a pull model.
And that's like what I've been talking about to this point.
So in a pull model, typically what has to happen first is that the multicast
receivers, which are my laptops, have to send some sort of packet to indicate
their interest in this multicast saying, hey, I want to receive it.
And then usually there's some router that's configured in this network
with a very special functionality.
Let's just say it's router two, and I'll use the letters RP.
Now that you'll learn a lot more about this when you learn about PIM protocol
independent multicast at layer three, but this is called the rendezvous
point. Now think about that term for a second, rendezvous, right?
If I'm talking to my friend, I say, hey, where do you want to meet today
so we can have lunch?
Maybe my friend says, oh, let's meet at TGI Fridays for lunch, that restaurant.
I might say, OK, I'll rendezvous with you over there, which means rendezvous.
I'll meet with you at that location.
So in the world of multicast, a rendezvous point basically serves the
same purpose. So once my receivers, and these are most likely going to
be IGMP, or if we're talking about IPv6, the MLDP, the multicast listener
protocol, either way, I'll just do both of them here.
Actually, let's keep it with IPv4 for now.
So IGMP. So my receivers have indicated interest to their default gateways.
Now, nobody knows at this point what the actual IP address is of the source
of the multicast.
Or actually, even if the source actually exists yet, this might just be
a test stream and it hasn't even been configured yet.
So, but these routers, if they're running a multicast rendezvous protocol,
what they do know is the IP address of this guy, router two, our rendezvous
point. So once they receive an indication from their receivers, that the
receivers want to receive multicast, now these routers are going to send
special messages, some multicast routing messages, up to the rendezvous
point, saying, hey, router two, if you ever happen to see a multicast
that matches this destination, we're down here.
We want to get it.
And so now the rendezvous point says, okay, I haven't received anything
yet, but if I ever do, I received a message on this interface and this
interface that someone's down there that wants to get it.
And so now the rendezvous point just sits around twiddling his thumbs,
waiting to see if the multicast will ever start up.
Now, let's just say a few minutes or maybe an hour later, the actual multicast
does start up. Okay, well, this is great because now we have this tree
ready and waiting.
So these lines here, these red lines have just formed a tree.
These are branches of the tree leading from the rendezvous point down
to our receivers, where our receivers are ready and waiting to receive
this. So once the multicast actually starts up, look at router one here.
He never received any of these red arrows.
Router number one never received a request for this stream because he's
not the rendezvous point and he's not in the path of the rendezvous point.
But just like all these other routers, he knows who the rendezvous point
is. So he takes that multicast and forwards it to the rendezvous point.
And now the rendezvous point says, oh, okay, somebody has already asked
for it. They're asking to pull the multicast down to them, and I know
where they are. So now we'll send the multicast down this way, and it
goes down to my intended receivers.
So we call that a pull model.
Remember in the push model, which is what we call dense mode protocols,
the multicast starts out and is flooded everywhere.
And it's up to the routers to send messages back upstream saying, hey,
I never wanted this.
Stop flooding it to me.
In a pull model, which we typically call sparse mode protocols, sparse
mode, this is where the receivers have to indicate their interest, and
then the routers have to forward that interest up to some central router
that we call a rendezvous point.
So we pre-build the path in advance.
And then once the multicast comes in, all the routers know what that path
is, and where to forward that multicast.
So those are the two typical modes of multicast routing protocols, push
modes and pull modes, or otherwise known as dense mode protocols and sparse