All things related to multicast

["Marshall Eubanks" <>]

On Sun, 23 May 2004 11:41:50 -0400
 Dan Pritts 
<>
 wrote:
> On Sat, May 22, 2004 at 06:07:08PM -0400, Richard Mavrogeanes wrote:
> > SSM is certainly on our map. In many ways, it's easy to implement. You
> > are right, VBrick is a vendor and must be driven by business.  There is
> > only so much "if you build it they will come" a company can undertake,
> > and I doubt my company will sell more stuff any time soon by having
> > IGMPv3 support, as much as we can all agree it is "better".  With that
> > said, it *is* coming.
> 
> I'm a bit confused - what work does vbrick need to do to support
> SSM/IGMPv3?


I can't speak for VBrick, but I can speak for my application and my 
experience.

> 
> I'd think that your server software would not need to change at all,
> and any client side changes would be handled by the IGMP stack in the
> OS, not in your software?

Wrong. First, who says that the device is using an OS that handles IGMPv3 at
all ? Many embedded devices use VX Works (used by the current crop of Mars 
Rovers, for
example). AFAIK, VX Works does not support IGMPv3 - in fact, it just recently 
added
IGMPv2. Many other embedded devices use Linux. If your device uses, say, 
Linux 2.2, then
it is not trivial to upgrade to Linux 2.6. System calls, for example, will 
have to
be changed. It makes no sense, of course, to upgrade your receiver side 
software
to a different kernel from your server side (assuming that there is a clear 
separation between
the two sides in code, which there may not be), so this imposes server side 
changes all over the
place. For any application except for strict static broadcasting, there also 
now probably has to be
a new means of communication between sender and receiver (the receiver cannot 
receive until it
knows the sender's IP address, so the sender has to find that and send it by 
some out-of-band
mechanism to the receiver). 

On the client side, IGMPv3 / SSM imposes a further set of profound changes 
which are not at all
handled by the OS. The API has to change - has to, because previous openings 
of a "group"
socket are now calls to open the "channel" socket, including the group 
address and the source 
address. This triggers a whole bunch of other changes - because the source 
address was
not previously required. These changes can be quite profound (I have seen 
cases where the order
of the code execution had to be profoundly changed, because the socket call 
had to go from early in
the code to later, after it got information from the outside). 

> 
> You're certainly right about the switch issue.  If a switch doesn't support
> IGMP at all, well, it won't work any better with IGMPv3.  
> 

Misleading. Many installed switches do snoop IGMPv2 snooping. Most of these 
do not support
IGMPv3 snooping. I am sure that will change, but it hasn't yet.

> However, there is still a benefit to using SSM - no MSDP needed in the
> router infrastructure.  
> 

Which, although laudible, is not really the problem of a device developer. 
The only way I can
get traction with device people is to stress the likely DOS destruction of 
MSDP.

> danno

Regards
Marshall Eubanks

> --
> dan pritts                                       
> 
> systems administrator                            734/352-4953 office
> internet2                                        734/834-7224 mobile
>