Re: multicast-transition

[Doron Rajwan <Doron@bandwiz.com>]

Hi everyone,

I would like to participate in the effort to define the automatic tunneling
mechanism. I think that ANY tunneling method will do, as long as it gives
incentive to ISPs to open their network to native multicast. We just need to
agree and get it going...

The tunneling mechanism I suggested at the SSM meeting in Pittsburgh is
different from other tunneling mechanisms in few points / ideas. These ideas
are independent, so, you can take whichever you think is right.

The second thing I suggested in Pittsburgh was the multicast-on-demand, or,
the reverse-IGMP, as Hugh called it. Since the PIM tree ends in the source
DR, not the source itself, the source cannot know which groups has
listeners. I consider it as a "hole" in the multicast protocols. A future,
IGMP v3.1, can fix it. Dirk, I think that this problem is independent of the
tunneling problem, and we shouldn't try to tie them together.


Tunneling points:
=================

0. TARGET: All 4 cases Ross talked about: old or new OS, old or new
first-hop-router.

1. POWERFUL: Every router in the multicast domain will have the ability to
be a tunnel end-point. The router will simply "join" the group, and use the
tunnel as the output interface. This will give a lot of horse-power to drive
the tunnels.

2. NO-HOST-MODIFICATIONS: All the protocols will be user level protocols,
i.e., above unicast UDP (including the tunnel creation and destruction).
This will allow an application to use tunnels w/o modifying the OS kernel,
using raw-sockets, and so.

3. EFFICIENT-DATA-DELIVERY: The IP-in-IP encapsulation method costs a lot of
resources, and cause packet fragmentation. This degrades performance a lot.
I suggest to simply replace 4 header fields:
	a. Source IP address will be set to the tunnel end-point
         address. The original source address is known in the 
         SSM case, since the tunnel was created to deliver 
         this (S,G). In the ASM it is lost forever (that's why 
         I presented it in the SSM in the first place).
	b. Source port will be set to a well-known port number 
         at the tunnel end-point. The original source port is 
         lost forever, but I do not consider it as a problem.
	c. Destination IP address will be set to the receiver 
         address. The original multicast group address is 
         known, since the tunnel was created to deliver this
         address.
	d. Destination port will be set to a port specified by
         the receiver. Again, the original destination port 
         is lost forever, but I do not consider it as a problem.

4. NO-MANUAL-CONFIGURATION: Automatic detection of tunnel end-point. Instead
of using manual configuration or directory services, I suggested that the
application will use the standard "trace-route" algorithm, and then ask each
router in the path to the source be a tunnel end-point. The first router
that will agree will be taken. In the worst case, the source will always
agree. Again, this works only for SSM.

thanks,
  Doron.

______________________________________________
Doron Rajwan, CTO, Bandwiz Inc.
8 Shaul Hameleh Blvd., Tel Aviv 64733, ISRAEL.
mailto:doron@bandwiz.com
Direct: +972-(3)-6941805
Bandwiz:+972-(3)-6941800
Cell:   +972-(56)-507799
Fax:    +972-(3)-6941818
Home:   +972-(3)-6736614