Re: multicast-transition

[Radia Perlman - Boston Center for Networking <radia@bcn.East.Sun.COM>]

Actually, part of the Simple Multicast proposal involved automatic
tunneling, with joins sent from the endnode or from
a router that looked more or less
like ordinary packets with destination=root. That way non-multicast
routers just forward the message, and tunnels get automatically created
between multicast routers or between the multicast endnodes and
the routers.

Some guys from Bandwiz attempted to get on the agenda to discuss this
at a previous MADDOGs, but for some reason this was considered not
important enough to make it onto the MADDOGs agenda, or perhaps the
argument was that it was "too researchy", which doesn't make sense because
my summer intern implemented it in 2 weeks, and there was a concrete
proposal for it. Perhaps people didn't understand what the bandwiz people
actually wanted to discuss.

But the proposal is a better solution than IGMPv3 because it does not require
a local multicast router, and because it can be deployed totally
as a user process on the joining endnode, so it doesn't require
getting a new version of the OS.

So the advantages are:
   a) easy deployment...don't need new version of OS...deploying something
      at user level is always easier than waiting for new versions of the OS...
      e.g., SSL deployment vs IPSec...SSL happened "overnight" basically
   b) automatic tunneling so anyone, anywhere can join a multicast group
      (assuming an 8-byte multicast group, where the root is known to
      the joining node)
   c) the root of the tree gets at least one join if there are any
      listeners. So if there are no listeners, the root, if it's a sender,
      knows not to send.
      
Radia