Re: multicast at the data layer (layer 2) non-flooding ?


George Nychis wrote:
> Thanks for the response, but I think you're missing my main question
>
> you say:
> At the link layer, when you join a multicast group, you inform your
> kernel (or whatever contols the TCP/IP stack in your OS of choice) that
> you want to listen for certain traffic, traffic that will have a
> defined data link address.
>
> I understand this about multicasting, however what I am wondering is
> controlling the multicast data from being flooded in the network.

Multicast routers only forward traffic out an interface from which a
join request/membership is active. If no one requests membership, then
no traffic is forwarded. This is _one_ of the main functions of the
multicast routing protocols. The other is building the trees that lead
back from the membership request, through intermediate multicast
routers, to the closest source (or rendevous point). The routing
protocols can get really dumbfounding.

> What you're saying is you tell your kernel you want to listen for
> certain traffic... which is of course the multicast traffic. However,
> what I am wondering is what kind of technology is out there at the
> router to prevent those not in a multicast group from getting the
> multicast flooded messages.
>
> For instance, you join a multicast group, and I do not. However if we
> are on the same router, as you said, the multicast message gets flooded
> and we both get it. You told your kernel you want to receive those
> messages, so you receive it. I did not, so i drop the message. The
> message still came to my link though. I want to prevent it from ever
> being put on my link, i do not even want to hear it.
>
> I think I found an article as to what I was talking and asking about
> though and an answer:
> http://www.intelligraphics.com/articles/ipmulticasting2_article.html

Yes, I have the article. Beware that it is Cisco protocols (and GARP)
and switched equipment that is being discussed. If you have all Cisco
gear, this is a good start on what you have available. Note also that
the problems discussed are directly related to switching technology,
not to the layer 2 aspects of multicasting per se. If yours is a
wholly switched network then this is what you need. If you have
routers in the path, you will have to catch up on the multicast routing
protocols as well.

For switches you might also want to check this:
http://www.cisco.com/univercd/cc/td/doc/cisintwk/ito_doc/ipmulti.htm

again, good luck,
prg

.

Relevant Pages

  • Re: IGMP Snooping Expert Needed !!
    ... Is that the source for IP multicast streams? ... If so which ports on the switch are the multicast streams destined to? ... IGMP is a layer 3 protocol used between hosts and multicast routers to ...
    (comp.dcom.sys.cisco)
  • Re: A question about ospf
    ... Some books and Cisco training books usually use two routers to explain ... OSPF from powerup state to full state and not mention it is point to ... Second question is that all relate to OSPF packets use multicast ...
    (comp.dcom.sys.cisco)
  • Re: Windows 2k3 MediaServices 9 and SAM Broadcaster
    ... Multicast won't be useful if your routers don't support it. ... it might be that some internet routers still do not support Multicast. ...
    (microsoft.public.windowsmedia)
  • Re: Quality of BBC Internet radio to overtake DAB
    ... multicast streams to choose from in the future will be zero. ... There is no need for IP4 to know anything about multicasting, provided that that the multicasting standards are implemented at a higher layer than the IP4 standard. ... To illustrate what I mean consider the situation of setting up 1000s of servers all connected to the internet. ... Now I seem to remember reading in this NG about routers needing to be multicast enabled. ...
    (alt.radio.digital)
  • Re: Interprocess communication
    ... Multicast has some problems, such as how any routers in the local network handle it. ... When server receives the startup message, ... This tells the server that the client is alive/active. ...
    (microsoft.public.vc.mfc)