Re: understand multicasting from the client/host perspective .

thanks Ryan!

You and Mike are the type of my favorite teachers. From the way you
teach I can see how you study things ...

I've seen too many people just know certain aspects of a technology,
and also forget common sense when they talk about a technology.

I believe all technologies can be described with layman terms .. if a
person cannot use his/her own words talking a technology, he/she has
not mastered the technology yet.

Thanks Mike and Ryan again, and everyone else.

rdymek wrote:
The switch doesn't really do a whole lot with Multicast other than deal
with the multicast address and identify which ports belong to that
multicast group. Nothing more. Its reality a simple concept - I
believe you're probably over thinking this just a bit.

Think of the layers of your OSI model. If the multicast mac is
assigned to your PC (and possibly hundreds of others and the network
propagates) then data destined for your mac will be sent to you via the
switch. The router encapsulates the MAC frame into an IP Packet with
IP addressing and the process goes on and on. Just like a Unicast. In
fact, most of the network looks at Multicast as a Unicast, even though
its in all reality a type of broadcast. Its a hybrid so to speak.

But since Layer 2 requires a MAC to communicate you couldn't possibly
map the multicast IP to your real MAC, because there'd have to be a
separate ARP mapping for each host involved. And you can't have an ARP
entry that is 1 to many mapping. Otherwise you'd be saying that the
real MAC of your PC translates to multiple IP's and vise versa (one IP
mapping to multiple MAC). Since that's not the way ARP works, you need
sort of a broadcast method involved. Its similar to your network
broadcast (i.e. 255.255.255.255) which goes to all systems on the
network and all systems choose to listen to that broadcast. With
Multicast, its the same concept but only the systems that needs to
receive the packet/frame get it.

So end result it you're talking last leg, layer 2. Layer 2 needs a
mapping, normally done through ARP. Since ARP doesn't work with 1 to
many, you have to do it slightly differently and assign a MAC to IP
mapping. This is an RFC standard and is the same from vendor to
vendor.

Ultimately, multicast doesn't work without a mechanism to use it though
- your original post mentioned how to use it from the end user
perspective. You need an application or something to say what
multicast addresses to use to communicate with (whether it be the
client [receive] or the server [sending]). Without the application in
place, Multicast won't function.

There are entire courses set aside just for Multicast - it can get very
detailed, but the basic concept isn't much different than from your
basic IP knowledge, just with a little twist on it.

Ryan

April wrote:
So, at the last leg, the router translate the multicast IP to the
multicast MAC (according to Mike), and forward to the switch. The
switch then delivers the multicast frames to the multicast MAC.
Although this multicast MAC does not exist on the subnet - not relate
to any physical NIC, the NIC belongs to the host that joined the
multicast group knows it, and picks up the frames that sent to the
multicast MAC, is this the picture I should get?

It seems to me the switch should play a more active role here?

Barry Margolin wrote:
In article <1151321439.743671.169080@xxxxxxxxxxxxxxxxxxxxxxxxxxxx>,
"April" <yinzhang57@xxxxxxxxx> wrote:

Thanks Mike and Sam ...

The multicast MAC part is where I have difficulty to understand well ..
like why this is needed? As the sender, it seems to me it only needs
to send to an IP ... I can think this signifies the frame is multicast,
and somehow the switch can relate the multicast MAC to the MAC of a
host that joined the group, but not sure this is all it about?

It's the same reason why a unicast IP address has to be translated to a
MAC address when sending to the final destination. Everything on a LAN
has to be sent to a MAC address, that's how LANs work.

In the case of unicast we we ARP to find out the MAC address that
corresponds to a particular IP address. But for multicast you can't use
ARP because each member of the group has a different MAC address. So
instead there's a direct translation algorithm, where a piece of the
multicast IP address is appended to a standard MAC prefix.

--
Barry Margolin, barmar@xxxxxxxxxxxx
Arlington, MA
*** PLEASE post questions in newsgroups, not directly to me ***
*** PLEASE don't copy me on replies, I'll read them in the group ***

.

Relevant Pages

  • Re: Stranges with ARP
    ... once my user's MAC doesn't appear in my ARP ... > me how to block user IP block without touching ipfw (I think to use ... Remember the multicast bit of 802.11? ...
    (freebsd-net)
  • Re: understand multicasting from the client/host perspective .
    ... multicast group, my teacher told me that ... ... The multicast MAC part is where I have difficulty to understand well .. ... who lives there - he just delivers a mail. ... which MAC address available thriugh which port. ...
    (comp.dcom.sys.cisco)
  • Re: understand multicasting from the client/host perspective .
    ... The switch doesn't really do a whole lot with Multicast other than deal ... If the multicast mac is ... And you can't have an ARP ...
    (comp.dcom.sys.cisco)
  • Re: Spoof ethernet MAC address
    ... mac addresses are multicast addresses (there are more than just the ... If you are referring to the multicast and locally administered ... were not issuing address ranges consecutively, ... OUIs used for the classic 3C509 NIC. ...
    (comp.unix.bsd.openbsd.misc)
  • Re: Network Security
    ... prg wrote: ... _unless_ it is multicast -- I think I read that in one of the IEEE ... > to outfox the cable modems that expect to see one, and only one MAC ... that the "standard" for serial link transmission is LSB first. ...
    (linux.redhat)