All things related to multicast

[Toerless Eckert <>]

On Tue, Jun 12, 2001 at 05:32:43PM -0500, Bill Nickless wrote:
> (*,*,*) switching is what you get when you turn on IGMP snooping on that 
> same exchange point because IGMP snooping detects only the 
> multicast-capable routers.  (Alternatively, you use a separate VLAN for 
> multicast.)  Now the unicast-only participants don't get the multicast 
> traffic.

Hmm.. Ok, but that's a small difference. Wouldn't you like to use a
VLAN for all participants that do multicast anyhow ? If all routers
on aq VLAN do multicast, you have effectively a shared media - that's what
i was referring to...

> I don't think the two reasons (dup elimination, upstream (s,g) choice) are 
> orthogonal.  You get the duplicates WHEN some participant chooses the 
> "wrong" peer to send the PIM-SM join--that is, they pick a different RPF 
> for an (S,G).

Well, but that's ust a few packets, PIM assert will take care of this.
YOu may get these kind of few duplicates in other places along the path
also, i don't think this is an interesting differentiator.

> You want to support the ability of participants to choose 
> their RPF neighbor for reasons that include the avoidance of duplicates.

I would immediately say no, this is not an argument, but maybe you're
using the term duplicate different from i do: I say duplicates to
indicate that there really is something happening that will result
in the actual group receiver (somewhere down the path) to receive
duplicate packets. I think you are more referring to it to notiify the
case where a downstream peer on a MIX get's excess traffic which may or
may not be actual duplicates. In any case, in case of a single VLAN
you get very few duplicates because of PIM-asserts. YOU will get a
lot more excess raffic if you only have (*,G) based traffic constrainment
within the VLAN.


> Thinking about it more carefully, your solution isn't quite fully (S,G,RPF) 
> even with RGMP and current PIM-SM snooping.  Consider two sources S1 and 
> S2, and three participants A, B, and C.  A might want to get (S1,G) from B, 
> but (S2,G) from C.  The exchange point would be forwarding (*,G) from both 
> B and C, which means A could still get duplicates--(S2,G) from B or (S1,G) 
> from A.

C would RPF (S1,G) to the VLAN owned by B and would drop (S,1G) packets
if arriving on the VLAN owned by A.  You are right that if the VLAN switch
does not support per-(S,G) trafic restriction, that C would then actually
receive the duplicates, but it wouldn't accept them... But that is
anothe proof that the VLAN concept is orthogonal - just add a (S,G)
snooping switch and you have the optimum restriction of traffic on the
links to the routers. -> The VLAN solution itself is only meant to
provide downstream routers to make their RPF selection based on their
own policy and not based on PIM asserts !

> Very good point.  I forgot about that one!  Just for my curiosity's sake, 
> do you know who has that implemented, and if anyone is using it?

Cisco IOS implements this since eternities. I am not aware of any MIX
that uses it, though, it's only deployed in enterprise networks as far as
i am aware.

Cheers
        Toerless