Re: New Internet Draft on automatic (end-user) tunneling for SSM

[Ross Finlayson <finlayson@live.com>]

If automatic multicast tunneling is to succeed (and thus spur the 
deployment of multicast throughout the Internet), it's important not only 
that the actual tunneling *mechanism* be automatic, but also that the 
*deployment* of this mechanism happen automatically.

What I mean by this is that if network providers (at whatever 'tier') are 
required to make an explicit decision to install new infrastructure 
specifically for multicast tunneling (e.g., tunneling relays, anycast 
routes, etc.), then it's unlikely that many of them will make the effort to 
do this.  (As Marshall Eubanks noted, most of them wouldn't install this 
unless they got paid to do so - but if you're going to pay providers to do 
something, you might as well pay them to turn on native multicast; that's 
what broadcast.com did.  In any case, we should never lose sight of the 
fact that one of the promises of multicast is the 'democratizing' effect 
that it has on content providers - even content providers with limited 
means should be able to reach arbitrary-sized audiences.)

Instead, the best way to deploy multicast tunneling is to have this happen 
automatically as providers upgrade their routers to support 
multicast.  I.e., when a provider makes a decision to upgrade his routers, 
he can know that he's also getting support multicast tunneling (so that 
remaining legacy, non-multicast-capable routers below him can also 
participate in multicast).  Of course, the provider can always disable the 
tunneling functionality (or tweak parameters such as max fan-out) if he 
wishes.  But they should not be required to install anything separate to 
make tunneling happen.

This is one of the key facets of the "URI" proposal (aka. "UDP router 
intercept"; draft-finlayson-mboned-autotunneling-00.txt).  Assuming that 
SSM becomes as popular as many people hope, many providers will be wanting 
to upgrader their routers to support SSM.  It would be great if they could 
automatically get tunneling support at the same time.

Focusing on SSM rather than ISM (at least at first) makes the 'tunnel 
endpoint location' problem easier.  In the "URI" proposal, you don't need 
any separate tunnel location mechanism (or infrastructure).  Instead, a 
tunnel endpoint ('slave') is found automatically by the JOIN_GROUP message 
sent from the end node towards the SSM source.  (This is the 'router 
intercept' mechanism; the challenge, of course, will be to see if routers 
can implement this efficiently.)

In contrast, I worry about how easy it would be to deploy schemes that 
require a separate 'tunnel endpoint location' mechanism.  In particular, 
the "AMT" draft (Thaler at al) proposes using "anycast" to find tunnel 
endpoints.  However, do we expect anycast to be widely available - even by 
users of J. Random Non-Multicast-Connected ISPs?  Aren't some providers 
likely to filter out anycast routes (because of the length of their 'prefix')?

         Ross.