Subject: mboned: RE: Automated Tunnels for IP Multicast

From: Venketesan <[email-masked]>
Date: Mon, 18 Jul 2005 10:00:16 -0400

Hi,
The complete protocol specification is available at 
www.iit.edu/~venkthi1/imcast/itp.pdf and you could visit the project 
website www.iit.edu/~venkthi1/imcast1.html.
We havn't yet proposed an internet draft but intend to do so soon.
Our scheme ITP is completely independent of AMT solution. We are 
different approaches to solve the same problem, Follwoing are primary 
differences (I hope i havn't misunderstood some of the concepts in 
AMT, I would appreciate feedback from the authors in case i have)

1. AMT requires gateways, relays and the MBONE for ASM support. We 
dont use MBONE and introduce only one new network element i.e. ITP 
border routers or gateways both for ASM and SSM.

2. Our message propagation paths between the domains boundries is 
reverse shortest path for SSM as well as for ASM. In AMT, ASM trafic 
will flow through the MBONE.

3. AMT relays could be bottle necks, ITP there are no relays. ITP 
border routers would carry multicast traffic only for those domain 
for/from whom they are carring unicast traffic also.

4. AMT is based on ANY cast addresses, ITP provisions connectivity 
between domains only by using the unicast address of the source or the 
RP of the source. 

5. Because of the AMT design of the anycast addressing scheme it adds 
restrictions on usable SSM address space by each domain.

6. AMT can support sources only in SSM mode. There are no such 
restriction is ITP.

7. We provide a functionality what is called "progresive deployment". 
For example there are two multicast aware leaf domain( receiver and 
source), we would form the tunnel automatically between the border 
routers, suppose later one of the ISP "in between (i.e. ISP is 
responsible for routing unicast traffic between the two)" the unicast 
path i.e. the tunnel, adds IP multicast functionality with ITP routers 
at its border. Then ITP adopts itself such that the original end to 
end connectivity between the receiver and source domains breaks into 
two tunnels, one receiver to new ISP domain, second ISP to source 
domain. Thus when new receivers may join the group in the island of 
the new ISP all the three islands form the same tree optimizing the 
structure. See the protocol specification for detailed example.
In case of any other tunneling scheme the connectuvity would be one 
tunnel between the receiver and source, and one frm the new ISP and 
source and the two tunnels would overlap each other on many links from 
the ISP to the source domain.

regards,
Venkat

_______________________________________________________________
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 08:25:24 +0300 (EEST)

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 
mapping)
  - [some] traffic between AMT sites can be optimized with direct 
tunneling if needed.

Also inline,

> border routers or gateways both for ASM and SSM.

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

> will flow through the MBONE.

AMT allows to use direct tunneling between AMT sites.

> for/from whom they are carring unicast traffic also.

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.

> between domains only by using the unicast address of the source or the

See above.  Using anycast allows for topologically-closest third 
parties to be used by AMT sites, without any configuration.

> restrictions on usable SSM address space by each domain.

And IMT requires manual config ?

> 6. AMT can support sources only in SSM mode. There are no such

And requires manual config?

> routers,

This "direct tunneling", is also provided in AMT (as a "MAY").

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