No Subject

Automatic tunneling can initiate a process and provide an incentive 
for wide spread multicast deployment at the routers. By enabling an 
immediate multicast to applications, routers that are not multicast 
enabled will suffer a larger load, while the multicast enabled routers 
will require less computational power since they receive a fewer 
number of packets from the next-hop router. This creates a 
positive-feedback that will cause most routers, especially in the 
critical areas, to be SSM-enabled.


Removing IGMP:
==============
(This section is less critical than the sections above)

In the Internet standard multicast [ISM] model, where multicast group 
was identified using a class-D address, there was a reason of using 
one protocol between routers, and other protocol between hosts and 
routers. First, the routers needed to maintain information about the 
structure of the autonomous system (AS), and the structure of the 
multicast group delivery graph, that the host didn't care about. 
Second historical reason for IGMP was the dense-mode design, when 
there is a flat, non-switched LAN, and a big number of users who want 
to listen to the same multicast group.

We think that this is not the case today. In general, using IGMP has a 
lot of drawbacks:

1. IGMPv1 designed to be a super-set of all the information that a 
host needs to send to the designated router (DR). When the multicast 
protocols required low leave latency, IGMPv2 was created. When the 
protocols required source-specific, IGMPv3 was created. Any of these 
changes caused a redundant change in the operating system. This may 
continue forever. The basic flaw is that there is no general 
super-set, and the required information to be transferred between the 
host and the router is protocol specific.

2. There is no need for two different set of protocols. There is no 
real difference between the last hop and all other hops. One protocol 
can, and should, do it all. This way, IP multicast can be defined by a 
single specification!

3. There is a need to update the application, the operating system, 
and the first router before an application can use multicast. Using 
UDP, like we suggest above, will imply modification only to the 
application.

4. IGMP, especially [IGMPv3], is far too complicated, with too many 
messages and fields that [SSM] protocols do not need. 


Acknowledgement:
================
This document benefited a lot from discussions and specific comments 
of Radia Perlman and Jon Crowcroft. Useful discussion with Suchitra 
Raman are also acknowledged.


References:
===========
[ISM] S. Deering, "Host Extensions for IP Multicasting".
http://www.ietf.org/rfc/rfc1112.txt

[IGMPv3] B. Cain, S. Deering, I. Kouvelas, A. Thyagarajan, "Internet 
Group Management Protocol, Version 3", Work in Progress.
http://www.ietf.org/internet-drafts/draft-ietf-idmr-igmp-v3-04.txt 

[PIM-SM] B. Fenner, M. Handley, H. Holbrook, I. Kouvelas, "Protocol 
Independent Multicast - Sparse Mode (PIM-SM)", Work in Progress.
http://www.ietf.org/internet-drafts/draft-ietf-pim-sm-v2-new-00.txt

[SSM] H. Holbrook, B. Cain, "Source-Specific Multicast for IP", Work 
in Progress.
http://www.ietf.org/internet-drafts/draft-holbrook-ssm-00.txt 

[PIM-SO] N. Bhaskar, I. Kouvelas, "Source-Specific Protocol 
Independent Multicast", Work in Progress.
http://www.ietf.org/internet-drafts/draft-bhaskar-pim-ss-00.txt 

[PIM-SS] S. Bhattacharyya, C. Diot, L. Giuliano, R. Rockell, 
"Deployment of PIM-SO at Sprint", Work in Progress.
http://www.ietf.org/internet-drafts/draft-bhattach-diot-pimso-00.txt 


Author's Address:
=================
Doron Rajwan
BandWiz Inc.
doron@bandwiz.com

Meir Feder
BandWiz Inc.
meir@bandwiz.com