Re: Automatic Tunneling for Rapid Multicast Deployment

[Steve Deering <deering@cisco.com>]

At 4:10 PM +0200 7/28/00, Doron Rajwan wrote:
>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.

Your second claimed "historical reason" is false and confused:

	(a) "Dense-mode" has nothing to do with the density of
	    receivers or presence of switches on a LAN.  Dense-
	    mode refers to the nature of the router-to-router
	    protocol, which would be just as applicable to a
	    network with no LANs or other multi-access networks
	    at all, i.e., just point-to-point links.

	(b) When IGMP was initially designed, there were two known
	    IP multicast protocols, which came to be named DVMRP and
	    MOSPF, one of which is a "dense-mode" protocol and one
	    of which is "sparse-mode".  The nature of the multicast
	    routing protocol (intentionally) had no effect on the
	    design of IGMP.

	    (I put "dense" and "sparse" in quotation marks because those
	    terms were invented much later and they are inaccurate terms
	    that lead to the kind of false conclusion that you seem to
	    have drawn.  There was *no* assumption in the design of
	    DVMRP that multicast membership would be "dense", either
	    within a single LAN or throughout the region of the network
	    that was running DVMRP.)

The *real* historical reason why IGMP is a separate protocol from the
router-to-router protocol was to allow the use of multiple, different
multicast routing protocols in different parts of the Internet, and to
allow a region to change from one multicast routing protocol to another,
without requiring any changes to the hosts or knowledge in the hosts of
which particular multicast routing protocol they happened to be
connected to on any given day.  That this was important was evident
from the experience with unicast routing protocols, where we had RIP,
OSPF, IGRP, and others all being used in different parts of the Internet;
requiring host changes whenever a unicast routing protocol was changed
or introduced would have been a major deployment hurdle, and would have
inhibited improvements in unicast routing.  And indeed IGMP accomplished
its goal: hosts that implement only IGMP can successfully be used to
receive multicast packets via DVMRP, MOSPF, PIM-DM, PIM-SM, and CBT.

>1. IGMPv1 designed to be a super-set of all the information that a 
>host needs to send to the designated router (DR).

That's exactly opposite to the truth.  The "classic" multicast routing
protocols were designed to work with the information the IGMP provided,
not the other way around.  The changes to IGMP have been driven by the
desire to correct inherent shortcomings (specifically, high leave latency)
or to enhance the multicast service model (i.e., adding support for source
filters), both of which reasons are completely independent of the "needs"
of any particular multicast routing protocol, in keeping with IGMP's
purpose.

And by the way, not all multicast routing protocols have "designated
routers" and IGMP, being routing-protocol agnostic, does not assume that
they do.

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

Any successful protocol evolves over time to correct shortcomings and
meet new needs.  After all, we are not running IPv1.  The important
observation is that IGMP has required fewer and less frequent changes
than all the various multicast routing protocols that it has
interoperated with, which is exactly as it was designed to do (given
that updating IGMP in all hosts takes far more time and effort that
updating the multicast routing protocol in the routers in one domain).

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

The basic flaw in your analysis is that you misunderstand the nature and
purpose of IGMP and its evolution.  It has not evolved to provide a
"super-set" of the requirements of specific multicast routing protocols.
There has often been pressure to throw in routing-protocol-specific
features (e.g., including a "core" or "rendezvous point" address for
CBT or PIM-DM), but so far we have managed to prevent such changes,
which would be exactly contrary to IGMP's goals of keeping hosts isolated
from knowledge of the multicast routing protocol du jour.

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

Sure, until next year, when someone comes up with the New New Multicast
protocol.

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

I agree that IGMPv3 is more complicated than I would wish.  But the
mismatch between what IGMPv3 provides and what SSM requires is due
to the fact that SSM provides only a limited subset of the *service model*
(*not* the multicast routing protocols) that IGMPv3 is designed for.
Sure, if you offer a less functional service, you can do it with a simpler
protocol (just as IGMPv2 is much less complex than IGMPv3).  The choice of
what service(s) to provide at what layer is, of course, the topic of the
most long-running debates in the field of data networking.  I would
appreciate it if you would acknowledge that these issues are indeed
debatable, and the fact that IGMP is not what you want does not
necessarily represent a "basic flaw" in IGMP.  And if you won't do that,
at least resist the urge to fabricate bogus "historical reasons" for
things you don't understand.

Steve