Subject: RE: multicast-transition

From: "Dave Thaler" <[email-masked]>
Date: Mon, 5 Feb 2001 10:39:44 -0800

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:[email-masked]]
> Sent: Monday, February 05, 2001 2:19 AM
> To: [email-masked]; [email-masked]
> 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:[email-masked]
>                                 tel:+32 3 2404732
> Network Strategy Group (NSG)    http://www.rc.bel.alcatel.be/nsg
> Alcatel                         http://www.alcatel.com
>

---

From: Marshall Eubanks <[email-masked]>
Date: Mon, 05 Feb 2001 15:43:26 -0500

> we can follow up off-list.

Dave;

As I was talking about this with Tony I will volunteer here.

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

>    technologies (tunnel brokers, 6to4, 6over4, etc) are implemented.

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

> > can a unicast-only host hook up to a multicast distribution via a

T.M. Eubanks
Multicast Technologies, Inc
10301 Democracy Lane, Suite 410
Fairfax, Virginia 22030
Phone : 703-293-9624
Fax     : 703-293-9609
e-mail : [email-masked]     [email-masked]

http://www.on-the-i.com http://www.buzzwaves.com

---

From: "Tony Ballardie" <[email-masked]>
Date: Mon, 5 Feb 2001 19:36:40 -0000

Marshall,

> expand the usability of multicasting, I suspect a lot more than for
network-layer tunnels.

the idea, as I envisage it, is to have a special IGMP message
anycast to a well-known (hard coded) anycast address, though
probably changeable through a config option. Most OSs support
IGMP, so the user would/can be oblivious, and similarly for
intervening ISP(s).

The other component to auto-tunnelling I forgot to mention is
where a *router* has to get over non mcast infrastructure.
My first suggestion for this was to alter the destn of PIM joins
to the anycast addr, but I gather it affects other PIM behaviours.
However, whether the trade-off of doing it anyway and altering
PIM accordingly, is worth it?? My view is, that after all these years
of not getting very far, we *need* transparent auto-tunnelling
for the host AND router, else IP mcast will never fulfil its potential.

As I see it that's not the end of the story either... then there's
QoS, reliability (ok, dealt with by RMT, but still early days), and
inter-provider pricing to solve before it can become commercially
viable in itself. And I'm a fan of IP mcast, but these seem to be the
harsh realities :-(   The CDNs have overtaken IPM because their
solutions plug the holes, although they tend to be less efficient
in the network.

Tony

---

From: Marshall Eubanks <[email-masked]>
Date: Mon, 05 Feb 2001 17:15:48 -0500

> solutions plug the holes, although they tend to be less efficient

Yes, except for one little thing - they are way too expensive to make a profit
from advertising. ALL unicast solutions for which I have pricing are
too expensive to make a profit from advertising. There is a LOT
of interest about multicasting in the (rather desperate) Internet
broadcast community. If we can get it together, the market will be there.

--
                                 Marshall

T.M. Eubanks

---

From: Ross Finlayson <[email-masked]>
Date: Mon, 05 Feb 2001 21:16:11 -0800

In considering a multicast tunneling solution, we need to be clear about 
exactly what environment(s) we are aiming for.  As Tony noted, the 
immediate focus should be on mechanisms for supporting non-native-multicast 
*receivers*.  (It might also be useful to concentrate first on *SSM* 
receivers, although I hope ISM can be supported as well.)

Considering receivers, there seem to be four possibilities, based on two 
independent Boolean variables:
- "OldOS" or "NewOS": Whether or not the receiver's OS supports (or can be 
upgraded to support) IGMPv3, and/or a IP-level multicast tunneling protocol.
- "OldFHR" or "NewFHR": Whether or not the receiver's first-hop router 
supports (or can be upgraded to support) IGMPv3 and PIM, or failing that, a 
multicast tunneling protocol.

So, the four cases to consider are:
1/ OldOS,OldFHR
2/ OldOS,NewFHR
3/ NewOS,OldFHR
4/ NewOS,NewFHR

(Case 4 [NewOS,NewFHR] is the ideal case in which both the OS and FHR are 
doing 'the right thing', so no tunneling is needed.)

Of the remaining 3 cases, the most frequently occurring (and thus the most 
important cases to consider) are probably [OldOS,OldFHR], [NewOS,OldFHR], 
and [OldOS,NewFHR], in that order.  (Note that for most end users, their 
first-hop router is a legacy DSL router or dialup portmaster.)  In any 
event, it seems clear that any useful tunneling solution can't ignore the 
[OldOS,OldFHR] case.

For the two "OldOS" cases, we already have a well-defined (and implemented 
and deployed) tunneling protocol: UMTP 
<http://www.ietf.org/internet-drafts/draft-finlayson-umtp-04.txt>.  There's 
no reason why smart upstream routers couldn't be made smart enough to 
intercept UMTP "join"/"leave" requests, and act as a tunneling endpoint.

For the [NewOS,OldFHR] case, we can (& probably should) do something 
smarter - perhaps some sort of IGMPv3-over-IP tunneling, tied in with the 
OS's IGMPv3 implementation somehow...  From what I can tell, this is the 
case that Tony has been looking at.

Orthogonal to this is the question of how to *find* tunnel endpoints.  The 
simplest solution would be to have this happen automatically, under the 
assumption that tunnel endpoints will be implemented in (or at least, are 
colocated with) multicast routers.  (Again, we might want to focus solely 
on SSM as a simplifying assumption here.)

         Ross.

---

From: Marshall Eubanks <[email-masked]>
Date: Tue, 06 Feb 2001 09:27:34 -0500

Hi Ross;

SSMinterest is not really the appropriate place to discuss this IMHO, as
it is not really an SSM issue. MboneD or even IDMR might be better.

> receivers, although I hope ISM can be supported as well.)

Why ? What's the difference here ? In both ISM and SSM you have a receiver
receiving multicast traffic (maybe by unicast) and mirroring this
traffic out to other
receivers. Why should this system care what address block the traffic
uses ?

Or are you just saying that the first goal should be to support
receivers, not
senders ? That's OK, of course.

Whether it's a IGMP v2 or v3 join, the real problem is source discovery,
which is
going to involve some out of band mechanism, so I do not see that SSM
really buys you
much in this case...

> on SSM as a simplifying assumption here.)

The trouble I have with any sort of router based version of this is that
the people
who cannot get multicast largely cannot get it because their routers are
not configured for
it, and these routers are beyond their control. So a router based
version really solves
nothing, it just replaces one problem with another. At the ISP level, I
think that the
solution should be, _enable multicasting_, not, enable a work-around.

I would argue that this problem has been solved already, and more than
once, just
not in the real time case, and at the application level. Think about
Gnutella, or
even Napster. What are these really but source discovery protocols ? And
this problem is
at heart a source discovery problem. Now, these are not appropriate / efficient
solutions for this problem at hand, but they do show that a protocol for 
application layer multicasting as a standalone piece of software could
find wide
utility.

Also, I regard the MDU/MTU market as the prime target of multicasting at
present. Most
of these people are on Ethernets. A very useful protocol, and a good
first step, would
be one to allow a receiver on a MDU/MTU LAN to  mirror a received tunnel
to others
on the same LAN using layer 2 Ethernet multicast. 

                                   Regards
                                   Marshall Eubanks

   Multicast Technologies, Inc.
   10301 Democracy Lane, Suite 201
   Fairfax, Virginia 22030
   Phone : 703-293-9624          Fax     : 703-293-9609     
   e-mail : [email-masked]     http://www.on-the-i.com