All things related to multicast

[John Zwiebel <>]

On May 23, 2004, at 8:41 AM, Dan Pritts wrote:

> I'm a bit confused - what work does vbrick need to do to support
> SSM/IGMPv3?

If vBrick is only concerned with sending multicast video and doesn't
care whether or not it gets to the receivers, then you are right --
they don't have to do a thing.

If they actually want folks to view the stream they are sending, then
IGMPv3/MLDv2 should be a top priority for them.  Router vendors have it.
Host stacks and L2 switches don't.  That's why we need some kind of
committee to move it forward.

BTW, we haven't discussed the "last-mile" problem.  Many ISPs have not
enabled multicast to most of the receivers.  Lots of reasons for this.
DSLAMs can't (or couldn't) replicate mpackets so a separate copy had to
be sent over every PVC to the subscribers.  Cable companies don't want
you watching "free" content that they don't control.  Content providers
don't want someone sourcing the latest block buster movie.  So, 
depending
on your perspective of which is important, multicast also needs some way
of protecting intellectual property -and/or- it needs a way of tunneling
around these barriers.

I think Michael Eisner is rich enough so content protection isn't
interesting to me.

However, the last-mile problem is.  There is a proposal for Automatic
Multicast Tunneling being developed which will allow a -host- to
set up a tunnel with an AMT enabled router so it can receive multicast
content over a tunnel.

Why AMT?
  -- content provider recognizes the advantages of providing a
        single source (ie, wouldn't it be -much- easier and cheaper
        for AirAmericaRadio to have one multicast source to serve its
        50,000 internet listeners?)
  -- ISP recognizes the advantages of BW saving by replication
        of the data only where the paths diverge.  (ie, if AAR was
        doing video, wouldn't their ISP be much happier?  Audio,
        I'm sure they're happier with unicast streams since they
        charge by the packet.)
  -- Users indirectly benefit from being able to access many, many
        more sources.  (50,000 channels and 'nothing on' ;-)
  -- As the demand for specific content grows, ie. an ISP finds that
        hundreds of its customers are watching the same content, such
        as Victoria's Secret, and that is congesting their network, they'll
        start turning on multicast.
  -- We don't have to have a "flag day" for everyone to turn it on at 
once.


> 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?

Should be, but the software has to discover the source somehow, and has
to make the calls to the OS to get the IGMPv3/MLDv2 report sent out.

And we see that some OS's aren't moving forward in that arena.  
(Specifically
Apple -- I'm not going to buy a windows machine.  :-)  So, what does
vBrick do there?


> 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.

Well, it -might-.

IGMPv2 and MLDv1 use the multicast group MAC layer address to 
communicate
with the switch.  That means the switch has to snoop every multicast 
packet
to see if its an IGMPv2/MLDv1 packet.

IGMPv3/MLDv2 use a single multicast destination address.  It shouldn't 
be
that difficult to listen to that single address to enable/disable 
forwarding
a specific multicast group on a port.  Of course, (S,G) for IPv4 is a 
64-bit
decision not just a 32-bit decision, so there would still be potential
conflict where two sources sending to the same group are forwarded when 
only
one is desired.

Of course, I am requiring at least a software upgrade to make this 
happen,
so it may still not be "good enough" even though it is an order of 
magnitude
(if not several) better than what currently exists.

Which brings us back to GARP/GMRP which is the L2 IGMP/MLD.  Lots of 
switches
have it, but yes, if it isn't also implemented in the host one can't 
make use
of it.

GARP/GMRP is part of the definition of VLANs and is also used to provide
L2 QoS.  Does this mean anything?  How many host stacks have implemented
any part of this spec?  I don't think any have.

So, if we are going to "move forward", there are lots of questions that 
still
need to be answered.