RE: multicast-transition (fwd)

[Doron Rajwan <Doron@bandwiz.com>]

Hitoshi,

The protocol you are suggesting is a totally new multicast protocol. It is
self-contained, i.e., does not need different join/leave protocol, and can
automatically create tunnels. This protocol uses the "8-byte" notation,
i.e., (S,G).

There was another protocol, with these specifications, called Simple
Multicast. From various reasons it didn't pass the IETF. At this point, I
would say, there is no need for another multicast protocol. We have PIM-SSM
/ IGMPv3, which I think is ready, partially deployed, and will scale well to
the entire Internet. We should, however, fix some problems: tunneling,
reverse-IGMP, and most important -- deploy it, and use it.


For the protocol itself, I think that it has a severe security bug: the
forward tree setup. Other multicast protocols uses the (sub-optimal) reverse
tree setup. With forward tree setup, there can be an attack from the
multicast transmitter; it can send join packets to everyone in the Internet,
and cause a flood. Any forward tree setup is subject to this attack. These
protocols will work only if you PAY per receiver; in this case, I am not
sure that we need multicast at all.

Doron.


-----Original Message-----
From: Hitoshi Asaeda [mailto:asaeda@yamato.ibm.com]
Sent: Friday, February 09, 2001 2:07 PM
To: ssm-interest@external.cisco.com
Cc: asaeda@yamato.ibm.com
Subject: RE: multicast-transition (fwd)


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