Subject: Re: mboned: RE: Automated Tunnels for IP Multicast

From: Venketesan <[email-masked]>
Date: Fri, 22 Jul 2005 10:16:28 -0400

Hi,
I hope i havn't missed any questions in my reply.
My answers are based on two facts:
1. ITP can be installed in hosts if required i.e. hosts network 
providers do not deploy ITP.
2. Why do we need an relay at all when the protocol is already running 
either in the gateway of leaf domain or the hosts themselves.

****************************************
>  - it is a transition tool for connecting leaf sites, not a new 
multicast paradigm - more important to solve the most pressing 
problems (being able 
> to receive ASM, using SSM). [ASM sending is problematic due to 
virus, 
> worm, etc. traffic in any case]
So is ITP we connect leaf sites too, u could consider ITP border 
routers to be synonoumous to AMT gateways. Additionally we update the 
difinition of a leaf site "automatically" as adjacent leaf sites and 
their immediate site above them connecting to internet enable IP 
multicast with ITP borders. See the last point in this mail and 
theprotocol specifications...
****************************************

****************************************
> no changes that are visible to the users or applications >  - no 
configuration required at AMT leaf sites, no leaf-site  specific 
configuration at the relays ("can be enabled automatically").....

All of it is true for ITP also, additionally there are is no network 
element called a relay. When u say no configuration at leaf sites i 
assume you mean other than the deployment of the gateway itself. Even 
ITP itself needs only one time commissiong of the ITP border router. 
All tunnels are "dynamicallY/automatically" setup by ITP using the 
unicast routes only and the dynamic griuo membesrhips of the hosts 
within the leaf domains.  
****************************************

****************************************
- relay service can be provided for third parties as well, which use 

> the closest relays (i.e., as short tunnels as possible)
ITP does not need anyrelay service. AMT tunnels ("using relays") are 
short Ok, but do you consider the distance between the relays? i mean 
supppose that two leaf domains connect to separate relays, packet from 
first gateway goes to the gateway's nearest relay, then to the other 
relay (i.e. withing the MBONE network) and then to the second gateway 
of the leaf router, This path may be longer than the direct "unicast" 
shortest path between the two gateways of the leaf domains.
****************************************

****************************************
- 
non-active hosts do not require state in the network, i.e., a 
> relay 
> could provide service to millions of hosts if hosts are not active 
> simultaneously.  In other words, the AMT capability could be 
> deployed 
> in host operating systems without having to wait for network 
> deployment.

ITP can also be deployed in the hosts without waiting for network 
deployment, these have been detailed in the protocol specifications. 
An ITP host sender/receiver can install ITP and get connected to a 
mcast communicastion in a remote island.
****************************************

****************************************
- receiving works through NAT (sending can't because there's no 
> NAT mapping)
I guess u assume either the hosts behind NAT are AMT aware or the NAT 
router has IP multicast capability, i.e they can send a PIM SM join on 
behalf of their hosts. In that case ITP receiver will also work from 
NATs. 

>  - [some] traffic between AMT sites can be optimized with direct 
> tunneling if needed.
1. How does AMT decide whento use direct tunneling, with SSM i believe 
the tunneling is always direct. All traffic between  ITP sites is 
optimized by direct tunneling in addition to the Optimized progressive 
deployment capability (see last point in the mail). 
2. If AMT has to do direct rtunneling between the sender domain to 
receiver domain using "ASM" (if at all) how would the tunnels be 
established. how would the AMt gateways at receiver domain know the 
border router address in the source domain. 
3.The problem agreviates as in AMT SSM all sources within the domain 
are identified as one by the identifier of the gateway of its domain. 
****************************************

****************************************
>Basically, I think 'relay' and a 'gateway' is just one network 
component.  Not a big difference there.

Relays and gateways may be [mostly] owned by two different entities 
isn't it.  It acts as a central routing point between the leaf domains 
many times, why do u need that when we can get the leaf domains 
directly connected, with the assumtions that ether the leaf domains or 
the hoststhemsellves are running AMT/ITP. Why should the gateways go 
to the relay at all when they don need to and can get connected 
directly. In ITP the ideology is install ITP border routers(i.e. 
gateways) or ITP in  host, and leave evrything to the unicast routing 
tables that will be used by the ITP protocol to connect. Or if u don 
have an ITP border router run ITP on the host.
**************************************** 

****************************************
> This is probably a drawback in ITP.  As there are no relays, you 
require deployment of ITP border router everywhere in the Internet 
where ITP leaf sites want to connect to.  AMT relays are specifically 
designed to allow third party to provide the service, and the AMT 
sites to fidn that service.
Doesn't AMT also requires deployment of either a "gateway" or AMt 
stack in the hosts in places which need the service i.e  all over the 
Internet. So does ITP.  
> See above.  Using anycast allows for topologically-closest third 
parties to be used by AMT sites, without any configuration.

Again my answer is why do u need a third party service provider, when 
in the respective leaf domains or host the automatic protocol is 
ruuning. ITP forms the shortest path tunnels using unicast routes.
****************************************

****************************************
> And IMT requires manual config ?

Not at all. There are only some first time commisioning rules. This 
would be cleareer when u read the paper.
****************************************

****************************************
> This "direct tunneling", is also provided in AMT (as a "MAY").
Our Progressive deployment definition is very different from direct 
tunneling. I understand the confusion as i believe none has addressed 
thispoint. let me give an example.

leaf domains A, B, and C. C has the source, A, B and C have receivers. 
A and B are connected to an ISP X who does not support multicast , C 
is connected to ISP Y who alos does not support multicast. Initially 
the tunnel configuration in ITP is two tunnels 1. A-C 2. B-C. In case 
of "direct" AMT its the same.
 Now X adopts IP multicast. Assume X enables its border routers 
connecting to A and B as ITP aware and also the border router (say 
XC)  connected to the rest of Internet i.e towards C. Between these 
border routers there may be many other routers withing the scoope of 
X. X has enabled IP multicast there (ITP not required). In ITP the new 
tunnel configuration is one tunnel from XC-C. all packets from A and B 
reached XC via native multicast. Note this configuration took place 
automatically once ISP X adopted Ip multicast and ITP. ITP 
functionality got disabled automatically at A and B borders without 
theadministrators talking to the ISP X adiminstrator. In case ISP X 
adopted only IP multicast the tunnels would have automatically stayed.
Now in case of "AMT direct", suppose XC is a AMT gateway. wouldn't it 
be true, the tunnels stay as A-C and B-C, hence path is non optimum 
from borders of  A, B to XC. There is no control plane in AMT to dtect 
the availability of another gateway as the hosts would always use the 
nearest gateway. Note that if the administrator in A and B disable 
their gateways then ist fine but this is manual how much can u 
coordinat, ISP and leaf domains are diferent owenerships. In ITP 
everything is automatic.

In other words let me say the definition of leaf domain in ITP in this 
case was autiomatically extended to an island that included A, B and 
ISP X.    
All this will be clearer when u read the ITP specs.
****************************************
*****************************************
My arguments on the restriction on SSM address space due to AMT may be 
still relevant
*****************************************

I am reading the direct tunneling specs in AMT in more detail and 
would giv ore comments.

Thanks for the discussion!

regards,
Venkat

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

> Hi,
> 
> I didn't look through the paper in detail, maybe on the trip to 
> Paris 
> IETF.  However, I'm not sure if you have spelled out the basic 
> assumptions well enough, and understood the basic tradeoffs made 
> in 
> AMT design -- these haven't been spelled out anywhere, but I'll 
> try to 
> list a few features:
> 
>  - it is a transition tool for connecting leaf sites, not a new 
> multicast paradigm
>  - more important to solve the most pressing problems (being able 
> to 
> receive ASM, using SSM). [ASM sending is problematic due to virus, 
> worm, etc. traffic in any case]
>  - no changes that are visible to the users or applications
>  - no configuration required at AMT leaf sites, no leaf-site 
> specific 
> configuration at the relays ("can be enabled automatically")
>  - relay service can be provided for third parties as well, which 
> use 
> the closest relays (i.e., as short tunnels as possible)
>  - non-active hosts do not require state in the network, i.e., a 
> relay 
> could provide service to millions of hosts if hosts are not active 
> simultaneously.  In other words, the AMT capability could be 
> deployed 
> in host operating systems without having to wait for network 
> deployment.
>  - receiving works through NAT (sending can't because there's no 
> NAT 

> -- 
> Pekka Savola                 "You each name yourselves king, yet the
> Netcore Oy                    kingdom bleeds."
> Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings
> _______________________________________________________________
> user interface: http://darkwing.uoregon.edu/~llynch/mboned.html
> web archive:  http://darkwing.uoregon.edu/~llynch/mboned/
> 
_______________________________________________________________
user interface: http://darkwing.uoregon.edu/~llynch/mboned.html
web archive:  http://darkwing.uoregon.edu/~llynch/mboned/

---

From: Pekka Savola <[email-masked]>
Date: Fri, 22 Jul 2005 17:58:31 +0300 (EEST)

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

> either in the gateway of leaf domain or the hosts themselves.

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.

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

> unicast routes only and the dynamic griuo membesrhips of the hosts

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.

The longer path is intentional, because it optimizes throughput by 
putting the role of packet duplication in the native multicast 
network.  But that said, the direct tunneling capability exists 
between AMT sites.

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.

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

> are identified as one by the identifier of the gateway of its domain.

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.

... below

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.

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.

> automatically once ISP X adopted Ip multicast and ITP.

How is the "XC-C" tunnel configured?  How do the tunnel endpoints know 
where to tunnel to?

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.

> from borders of  A, B to XC. There is no control plane in AMT to detect
> nearest gateway.

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.

> case was autiomatically extended to an island that included A, B and

Respectively, in AMT, the leaf site is always the same site, connected 
by an AMT "gateway" (which can even be a single host).