Subject: mboned: Re: Automated Tunnels (Re Pekka Savola's comments-II)

From: Venketesan <[email-masked]>
Date: Fri, 22 Jul 2005 13:08:25 -0400

Hi,

Thanks for your comments. I understand that we need to specify how the 
protocls are different and what are their respective advantages/ 
disadvantages over each other.

I guess there is a difference in our repective definitions of native 
multicast infrastructure, i guess u rs says islandsof IP multicast and 
connected to MBONE while mine says just islands of IP multicast and no 
MBONE. 

*******************************************
>Yes, but who deploys the gateway to connect a leaf site?  The 
>important goal of AMT (by using anycast address and mapping tricks) 
is 
>to not require lot of gateways at ISPs.  AMT could work (though 
>probably not very well :) with just one AMT relay in the whole 
>Internet.

Consider the case: We have a native multicast island, the island has 
one or more gateway routers that connect to the ISP router that 
services te domain. ISP is unicast only:
When we have no AMT "gateway" or no host in the domain implements 
anything related to AMT how is the domain going to connect to the AMT 
relay. I assume no MBONE connectivity or manual tunneling. Someone 
needs to be there to do the encapsulation, anycst address, mapping and 
stuff..
So if we dont allow AMT/ITP awareness anywhere in the leaf domain, 
either in the gateway routers or the hosts themselves. We can not 
acheive connectivity.
All that i am assuming in ITP is that for any leaf domain/host-in-leaf-
domain to have reach other multicast islands it needs to deploy ITP 
somewhere gateway or host.  

If you definition of "native multicast" means those multicast domains 
that are connected to the MBONE already, then even in ITP there is no 
need for the domains to have nay ITP awarebness in these domains, but 
the MBONE would have ITP routers, which in this case will be like the 
AMT relays. 
ITP assumes that MBONE is almost dismantled. It doesn't require it, 
but as statetd above it can work with it. I am trying to avoid using 
the MBONE.       
********************************************************

********************************************************

>If you don't have relays, I guess it means that:
>  1) all the gateways will act as relays, or
>  2) there are no relays, and there is no interaction with "native 
multicast".
>If we assume 2) can't be true, which network component acts as a 
>bridge between the "native multicast" and "IMT-aware"?  There needs 
to 
>be such a box, because IMT cannot build implicit tunnels towards 
>native multicast or vice versa. That component is an equivalent of 
AMT 
>relay.

You can call all gateways as relays, but only for their respective 
domains. "Tunneling to native-multicast"  there nneds to be someone in 
the native multicast (island i assume) who will decapsulate the 
tunneled packets i.e. there needs to be a tunnel and it has always two 
end-points.
***********************************************************************

***********************************************************************
>What needs to be configured on the host in that case, particularly 
>when wanting to receive a "native multicast" session?  Do you need 
>to configure an IP address of a "gateway"?  This is zero-config in 
>AMT.
The host sends a IGMP join to its DR which in turn may send PIM-SM 
join as its frwarded it may reach the gateway and get translated into 
an ITP-join (with unicast dest address) automatically and hence the 
connectivity. See the paper for exact details.
If the domain does not support ITP at its gateway (it may or may not 
support native multicast) the host would itslef send an ITP join and 
get connected. Detecting this may be hit and trial and hence zero 
configuration in ITP too. 
In anycase you will never need to configure the address of the 
gateway.  If the join passes through a gateway it willautomatically 
intercept it. I would request you to kindly see the specs to see how 
the "protocol number field"  is used to intercept ITP control 
messages.
******************************************************************

******************************************************************
>No, I meant that mcast can be tunneled _through_ the NAT, without the 
>NAT having to know anything (the tunneling is done using UDP).  I.e., 
>the mechanism needs to work through an unmodified NAT box.
>(obviously, this assumes that there is an AMT gateway or AMT-capable 
>host at the site using NAT.)

>thanks for the clarification similar functionality can be achieved in 
ITP too.
>There is no direct tunneling in AMT with ASM because AMT sites can't 
>be senders.
>Whether or not direct tunneling is done in SSM is implementation 
>dependent, I guess

OK.
***********************************************************************

***********************************************************************

>So, I guess you are assuming that there doesn't need to be any 
>interaction between the current "native multicast" domains and 
>"ITP-aware" [or AMT-aware] sites?

>If so, there certainly wouldn't need to be something like AMT relays 
>-- if you can tunnel directly to/from anyone you want to send to or 
>receive from, there's no need for interoperability.

>But that is an unacceptable assumption.  We assume that AMT [or IMT] 
>sites would want to connect to the "native multicast" infrastructure: 
>be able to receive transmission from there, and send there.

***********************************************************************
No thats not my assumption, i am assuming :
1. My definition of a native multicast infrastrcture is a isolated 
domain with native multicast.  
2. There is no MBONE operation hence every native multicast island is 
isolated except for manual tunnels.  
3. even if an Internet-wide-native multicast infrastructure connected 
via the MBONE does exit then as i said before ITP would need to be 
deployed at least some wehre in the MBONE(just like AMT relays)

***********************************************************************
>Ok so far.
>But you don't seem to be supporting the (major) case where the source 
>C is not [IMT/AMT] aware site, but is connected to native multicast 
>infrastructure.  That's why you need the relays in AMT.

I guess i answered this. ITP gateway in MBONE = AMT Relay.
***********************************************************************

***********************************************************************
>How is the "XC-C" tunnel configured?  How do the tunnel endpoints 
know 
>where to tunnel to?
Kindly see the protocol specs. Its automatic, the control plane using 
ITP join messages ensures that.
***********************************************************************

***********************************************************************
>This all seems to be for the case where you have IMT capability or 
you 
>have nothing.  The main goal of AMT is to provide multicast 
capability 
>to the leaves even if their ISPs (or the other leaves) don't support 
>AMT at all.
ITP is for the case when:
1. Leaf domains are not connected to MBONE or
2. MBONE can deploy ITP gateway (Or relay)
ISP not supporting ITP/IP multicast is fine.

***********************************************************************
>I'm not sure why you say "non optimum" as the tunneling is direct 
>between the A-C and B-C.  The AMT gateways are deployed at AMT sites 
>(A, B, C), not at the ISPs.  The relays are deployed at ISPs, but if 
>direct tunneling is used, the relay is not involved.
Non optimum becuase there may be needless packet duplication in the 
network between XC-A and XC-B, may be the new IP multicast 
functionality of the ISP  can save packet copies when being routed in 
its network. 
Kindly see figure 3 in the paper.
***********************************************************************

***********************************************************************
>Unless I'm mistaking, IMT tunnels are configured between two 
>endpoints.  The same could be achieved e.g., with L2TP or GRE 
tunnels, 
>I guess.  The main difference to AMT are:
 > - automatic deployment benefits due to the use of anycast address
 > - relays don't need to keep state for idle leafs

ITP there is no manual tunneling, everything is automatic. Kindly see 
our control operation in the paper. take note of the concept of using 
protocol number field to intercept control messages

regards,
Venkat

----- Original Message -----
From: Pekka Savola <[email-masked]>
Date: Friday, July 22, 2005 10:58 am
Subject: Re: mboned: RE: Automated Tunnels for IP Multicast

> (Note: when I made the list of AMT design considerations, I wasn't 
> implying that IMT couldn't do the same, just that I think it's 
> worth 
> considering the differences.)
> 
> On Fri, 22 Jul 2005, Venketesan wrote:
> > 2. Why do we need an relay at all when the protocol is already 

_______________________________________________________________
user interface: http://darkwing.uoregon.edu/~llynch/mboned.html
web archive:  http://darkwing.uoregon.edu/~llynch/mboned/