[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: multicast-transition
Dave Thaler wrote:
> 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.
Dave;
As I was talking about this with Tony I will volunteer here.
>
>
> 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.
Is this the same as draft-thaler-ngtrans-6to4-multicast-01.txt ?
( http://www.ietf.org/internet-drafts/draft-thaler-ngtrans-6to4-multicast-01.txt )
I can't find it under the other name.
>
> 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
It seems to me that if you go to the trouble of having IGMP or PIM set up, then you
are likely to be multicast savvy, and so won't really need this. Otherwise, IGMP may
be set up (or not) by your provider - if they don't do multicasting, they are unlikely to
do IGMP. In fact, I know of at least one ISP that has PIM enabled backbones
but does not IGMP enable edge routers just to keep multicasting under tight control.
This all seems a lot different from the case of IPv6, where the provider may be
assumed to be cooperative. Having application level auto-tunneling would really
expand the usability of multicasting, I suspect a lot more than for network-layer tunnels.
--
Regards
Marshall Eubanks
>
>
> > -----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
> >
T.M. Eubanks
Multicast Technologies, Inc
10301 Democracy Lane, Suite 410
Fairfax, Virginia 22030
Phone : 703-293-9624
Fax : 703-293-9609
e-mail : tme@on-the-i.com tme@multicasttech.com
http://www.on-the-i.com http://www.buzzwaves.com