RE: multicast-transition (fwd)

[Hitoshi Asaeda <asaeda@yamato.ibm.com>]

It must be too early to tell my detail design, though.

I've been doing my research around this topic, to implement SSM very
easily. My idea just uses modified IGMP and may not require multicast
routing protocol.

Protocol changes are;
	o. Modified IGMP defines new three IGMP types, IGMP Reply,
	   IGMP Ack, and IGMP Data.
	o. Modified IGMP can be sent as a unicast packet.

e.g., as for receiver's join, followings are basic deals;
	o. Receiver just sends IGMP Report(Join) to an interesting
	   sender by unicast.
	o. Sender tries to send IGMP Reply back toward the receiver
	   after receiving IGMP Report(Join).
	o. A new-IGMP-capable-intermediate router located between
	   sender and receiver steals this IGMP Reply and sends IGMP
	   Ack back to the source address of the Reply packet.
	o. Above intermediate router creates (S,G) state which
	   consists of iif, oif list, and destination list.
	   (oif is given by unicast routing table, or MRIB if you want 
	    to use additional multicast routing protocol.)
	o. Above intermediate router sends IGMP Reply toward the
	   receiver continuously.
	o. After sender receives IGMP Ack, he sends IGMP Data which
	   encapsulates IGMP header and UDP data to Ack sender.
	o. Destination address of IGMP Data can be changed according
	   to the next destination (i.e. neighbor node to forward
	   Data). The destination is Ack sender if the neighbor is not
	   on a same LAN, and it is G if the neighbor is on a same LAN.
	o. ...

My proposal has several important points.
1. It doesn't require any multicast routing protocol. Only supporting
   new IGMP by sender and receiver is required.
2. If there is no intermediate router which supports new IGMP within a 
   sender and receiver path, it looks like sender sends unicast packet 
   whose protocol type (ip->ip_p) is IGMP (#2). So, it must be so easy
   to deploy.
3. Because only unicast route is used and data path is created from
   the sender toward each receiver, it is very scalable and
   bi-directional.
4. Not so difficult to implement. (I believe so.)
5. It is easy to implement on IPv6, too. (Specific needs.)
6. It doesn't require some tunneling mechanism. It requires simple
   encapsulation technique. (You may say I use tunneling but I don't
   like to say "tunnel", because, to me, tunnel just gives an image to
   make some stateful or keep track of the connection, anyway.:)

Of course, there are some immature/unsolved points.
1. Interoperability between current multicast routing protocol.
2. Scalable timer management.
3. Security.:)
... and so on.

Any comments, even objection, would be welcome.
--
Hitoshi Asaeda