RE: multicast-transition

["Dave Thaler" <dthaler@Exchange.Microsoft.com>]

As Tony stated, he gave presentations at IETF on this topic that
sparked a lot of discussion about how to do it.  Mohit and I
have talked about some mechansisms like this and are planning to
write an I-D on this.  If you're interested in spending cycles
co-authoring with us (probably including Tony), send us email and 
we can follow up off-list.

Two quick responses:
1) we propose using IGMP rather than PIM for the same reason
   we proposed it for ipv6 in draft-ietf-ngtrans-multicast-6to4-*.txt.
2) we prefer automatically creating network-layer tunnels
   not application-layer tunnels, just like how the various ngtrans
   technologies (tunnel brokers, 6to4, 6over4, etc) are implemented.

-Dave

> -----Original Message-----
> From: Dirk Ooms [mailto:Dirk.Ooms@alcatel.be]
> Sent: Monday, February 05, 2001 2:19 AM
> To: ssm-interest@external.cisco.com; maddogs@ietf.org
> Subject: multicast-transition
> 
> 
> Hi all,
> 
> I was wondering whether anyone ever considered to apply techniques,
> similar to the ones defined in ngtrans for ipv6, to ip multicast.  At
> the moment one needs to configure static tunnels to connect 
> to the MBone
> over a non-multicast network.  Wouldn't it be good to investigate how
> senders and/or receivers can hook up automatically to the 
> MBone (without
> the requirement of somebody in the MBone configuring a tunnel to your
> network).
> 
> So, the concept of tunnel brokers might be useful: potential 
> senders or
> receivers can request a tunnel to a tunnel broker.  This requires some
> boxes at the border of the MBone that are willing to
> encapsulate/decapsulate, possibly take the role of DR (maybe one can
> find broadcasters that want to sponsor such boxes).
> 
> Automatic tunneling might be another mechanism helping the 
> deployment of
> multicast.  In SSM, one could consider mechanisms as the following one
> (I know it impacts the current model, but I think it's also 
> pretty cool,
> so maybe someone else might come up with variants that diminish the
> impact):
> 
> At the SSM meeting in Pittsburg Doron Rajwan presented the idea to
> extend IGMP to enable SSM-senders to check whether there are any
> receivers for their data.  As an alternative one could consider to
> terminate the PIM messages on the senders themselves (this would be a
> scaled down PIM-stub with very limited functionality).  Once this
> principle of terminating PIM at the SSM-sender would be accepted, one
> can easily create automatic tunnels: again a number of 
> special boxes are
> placed at the border of the MBone, which will inject a default route
> into the Mbone (the MRIBs will have a default route).  So (S,G) PIM
> Joins with an S that is not part of the multicast topology will follow
> the default route and will end up in this special border box.  The box
> consults its RIB and tunnels the PIM Join to the sender S.  By looking
> at the source of the outer IP header the sender knows where it has to
> tunnel its multicast data to.
> 
> The above mechanism would allow that anyone can send to the MBone by
> just downloading an application (no need to have a multicast router or
> to configure a tunnel).  In ISM it was required that a sender 
> sends its
> data to the DR of the sender to be able to be discovered by the
> receivers (via flooding or via an RP), but in SSM this is not 
> necessary
> anymore since out-of-band signaling is used.
> 
> In ngtrans there is another group of mechanisms beside 
> tunneling, which
> are the translators.  This could be another topic to investigate: how
> can a unicast-only host hook up to a multicast distribution via a
> special translator box.
> 
> Any comment?
> 
> dirk
> 
> -- 
> Dirk Ooms                       mailto:dirk.ooms@alcatel.be
>                                 tel:+32 3 2404732
> Network Strategy Group (NSG)    http://www.rc.bel.alcatel.be/nsg
> Alcatel                         http://www.alcatel.com
>