All things related to multicast

[Nitin jain <>]

Hi Jose,

  Please see my responses:

At 10:03 PM 6/27/02 -0700, José A. Domínguez wrote:
>On Thu, 27 Jun 2002, Nitin jain wrote:
>
>> Hi Lucy,
>> 
>>    I am curious why turning off the IGMP snooping should not work in every
>> case. If that doesn't work, we should examine the case as the plain layer2
>> switch/hub would also exhibit the same issue. 
>> 
>
>No, that's not the case. Turning off IGMP snooping off will solve the 
>problem since it will flood multicast packets to all ports.
>
>For IGMPv3 to work when using layer2 igmp snooping devices the end systems 
>will have to work in compatibility mode, that is, they will have to send 
>both igmpv3 and v2,v1 membership reports. In this case, the igmp snopping 
>switch won't have to look into the igmpv3 membership report packet 
>which is sent to 224.0.0.22 but will create the forwarding state because 
>of the igmpv2/v1 report which is also sent to the group address.
>
>Now I don't know how you can configure an end system to do both ... anyone 
>knows how?

  We'd prefer not to change the behaviour of the end system. It might be
easier to adapt the  switches to learn from either of the v1/v2/v3 reports
based on specific implementations.

>
>> I would think that this would be the case for any vendor that is not aware
>> of IGMPv3 in the snooping implementation as IGMPv2 did not care about the
>> source specificness. Therefore, plain layer2 forwarding would not be
>> adequate for source specific joins, or exclude source. Thus, it would be
>> advisable not to turn on any Layer 2 specific snooping, be it CGMP, IGMP
>> etc. if the implementation is unaware of IGMPv3.
>> 
>
>As I said before the main problem is that membership reports in v3 are no 
>longer sent to the multicast group address but to 224.0.0.22. This will 
>obviously break all current igmpv2 snooping switches. If your igmp 
>snooping switch would identify both membership reports sent to the 
>multicast address and create the forwarding state and then treat 
>224.0.0.22 as a special case where you would then look into the packet 
>to create the forwarding state then it would all work great .... it would 
>also mean that you no longer have a  simple layer2 device but a higher 
>layer device. Can the CPU and switch architecture keep up with this?

  This is implementation specific, but certainly feasible.
>
>In theory, one all devices are igmpv3 only, igmp snooping switches will be 
>easier to implement. Just listen to packets whose destination is 
>224.0.0.22 and you should be able to figure what's going on. 
>
>Also, I'm not sure you want the switch enforcing the INCLUDE/EXCLUDE 
>modes. You basically want a layer 2 device that snoops into membership 
>reports to create the forwarding state. In the end the multicast packets 
>will flow using as destination  the multicast group specified. End 
>systems and routers should be the ones enforcing what makes it up the 
>stack. 

Yes,  it would be better if it were done at the router instead. We can't
have receivers with overlapping INCLUDE/EXCLUDE within the same subnet. 
  
>
>> Please elaborate the case that would break. Thanks.
>> 
>
>The reason why Lucy said that you don't want to just turn off igmp 
>snooping in all switches is due to our very own use of multicast. About 
>40Mbps of continues traffic, is not something that you want going around 
>unless you really want to receive it. 

   Agreed. 
>
>How do Foundry deal with this? Do you guys have any plans to support it? 
>Sorry, if you already do ...

   Foundry currently does not support the IGMPv3, but it is in our plans. 

   Regards,

Nitin