Re: multicast-transition

[Ross Finlayson <finlayson@live.com>]

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.