Subject: Automatic Tunneling for Rapid Multicast Deployment

From: Doron Rajwan <[email-masked]>
Date: Fri, 28 Jul 2000 16:10:26 +0200

As a background for the presentation in the SSM workgroup
meeting next Tuesday, we provide below a document describing 
the automatic tunneling suggestions.

Any comment will be appreciated.

Doron Rajwan.

====================================================
 Automatic Tunneling for Rapid Multicast Deployment
====================================================

Introduction:
=============
The intent of this document is to promote rapid multicast deployment. 
A recent consensus in the multicast community is that source specific 
multicast [SSM] will be easier to deploy and so it can accelerate 
multicast acceptance. 

In order to have rapid SSM deployment throughout the network, we 
suggest a protocol that will enable multicast even if the routers near 
the receivers do not support multicast protocols. Further more, this 
protocol will work from any host, running any operating system, using 
UDP only. It will discover the nearest SSM-enabled router in the path 
to a specific source, and create a tunnel between the joining host and 
that router. This tunnel will be used in order to transfer multicast 
data for (S,G), from the router to the joining host.

Hardware support in routers:
============================
Each SSM-enabled router will have the hardware capability to create a 
tunnel to arbitrary number of hosts. When a multicast UDP packet is 
received, it will be duplicated and sent to each entry in the olist of 
(S,G), which may contain both neighboring SSM-enabled routers and 
tunnels. In the later case, the destination class-D address of the UDP 
packet will be replaced with the tunnel exit address (A), and the 
destination port will be replaced with the tunnel exit port (P). There 
is no need to encapsulate the packet inside another UDP packet.

The host can de-multiplex the group (G) from the port (P) by 
remembering each of the tunnels it created, and assigning different 
port number (P) for each tunnel coming from a specific source.

The original destination port number is gone forever, and cannot be 
used by the transmitter in order to implement de-multiplexing of any 
kind at the receivers. This limitation seems to be reasonable, and we 
do not think that packets should be encapsulated just because of it.

Software support in routers:
============================
In order to create tunnels, SSM-enabled routers will be able to 
receive UDP packets, containing join and leave commands, sent directly 
to them (using their IP address and a specific port number). These 
packets will contain the source (S), the group (G), the tunnel exit 
address (A) and port (P). Upon receiving it, the router will 
acknowledge the reception, by sending UDP packet to the joining host 
(A), and add this host to the olist for (S,G).

Currently, we do not specify the suggested packet format. It can be 
[IGMPv3] in UDP, with additional port number. Also, the tunnel should 
be refreshed from time to time. 

** Assuming there is interest in this protocol, we will write an 
Internet draft specifying the exact details of this tunneling process, 
and the exact requirements from routers.

Detecting the optimal router:
=============================
How can the joining host decide which is the optimal router to create 
a tunnel to? There can be many possible methods, e.g., use manual 
configuration, use hashing from a pre-defined set of routers, and so 
on. These methods while not optimal, will work at least as good as the 
methods for setting the Rendezvous Points (RP) in PIM-SM.

Another method is to use directory services, that will be asked to map 
(client IP, source IP) to (router IP). The result will be a list of 
entries containing these fields:
1. Client IP, mask: The group of clients which this entry is applied 
to. The mask is needed because clients can have temporary IP addresses 
from the same subnet.
2. Source IP, mask: The source of the multicast packet. This will 
usually be entire AS.
3. Router IP, mask: A group of routers that the host can round-robin.
4. Expiration: Time of expiration of this entry.

** Assuming there is an interest in this protocol, we will write an 
Internet draft specifying the exact details of this DNS process. We 
can also implement this DNS service world-wide.

Detecting the optimal router using trace-route:
===============================================
We now suggest an automatic router discovery method, using 
trace-route. The joining host will use standard trace-route algorithm 
in order to locate the first router towards the source. Then, it will 
send a UDP join massage to this router, as defined above. If the 
router does not acknowledge, the host will check the next router, and 
so on, until it finds a router that is SSM-enabled. This router will 
be used for tunneling.

The application needs the ability to send UDP packets with small TTL, 
and the ability to receive ICMP error messages. If the current socket 
implementation on the host computer cannot support it, the application 
can spawn the trace-route program itself, and process it's output. 
This can be done by any host!

Optimally, this protocol should be executed for every multicast 
source. For some applications there is only a single multicast source 
with a lot of groups, so, this problem doesn't exist. Also, in some 
cases, access ISPs are connected to the backbone using a single point. 
Assuming the backbone is SSM-enabled, the output of this process is 
independent of the source address.

The routers can help in this process. When locating an optimal router 
for a given source, that router can include (in the tunnel 
acknowledgment message) a list of subnets that it supports. Then, if 
the host needs to locate a router for each of the subnets, it can use 
the same router. There is no need to execute this protocol again. In 
this case the routes might not be optimal, but they are still much 
better than the routes created using RP in PIM-SM.

This protocol is only needed in cases that there is no other option. 
If there is a multicast enabled router on the host's LAN, it can be 
detected using limited broadcast of UDP packet to the LAN. This is 
needed if the operating system is old. If both the routers and the 
operating system is up-to-date, standard [IGMPv3] can be used.

Changes to the applications:
============================
Each application should be linked with a library for multicast join 
and leave. This library will check whether the operating system 
supports [IGMPv3]. If it is supported, it will be used.

If [IGMPv3] is not supported, the library will do limited broadcast of 
UDP packet in order to see if there is a SSM-enabled router on the 
LAN. If such a router exists, it will use it to join the multicast 
group.

In all other cases, the optimal router will be detected, and a tunnel 
will be crated to that router.

** Assuming there is interest in this protocol, we will implement this 
library, as an open-source code. It will utilize the OS [IGMPv3], LAN 
limited broadcast, or create a tunnel. It will locate the router for 
the tunnel by using directory services or by the trace-route 
algorithm.

Benefits:
=========
From the application point of view, the automatic tunneling feature 
opens multicast immediately, even in the extreme case, where only the 
joining hosts and the source support it, and it is effectively 
unicast. All the application need to do is to call join / leave 
functions, and receive packets. Later, when the routers are updated, 
things will become more efficient, of course.

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.
[email-masked]

Meir Feder
BandWiz Inc.
[email-masked]

---

From: Steve Deering <[email-masked]>
Date: Fri, 28 Jul 2000 09:39:36 -0700

>Removing IGMP:

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.

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

>can, and should, do it all. This way, IP multicast can be defined by a 

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

>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

---

From: Jon Crowcroft <[email-masked]>
Date: Sat, 29 Jul 2000 08:34:09 +0100

>>router-to-router protocol was to allow the use of multiple, different

um, i thought at the time that the breakthrough was in designing 
the first working example of a new communications paradigm:
receiver driven end to end protocols

the separation of inter-domain and intra-domain routing for multicast
is not a function of IGMP at all, and is not made easier or harder by
it....the problems of interdomain in terms of distributing receiver
membership and the existinence of senders in domains has dogged us for
some time and was at least to some extent  exacerbated by the
existence of dense mode protocols, but not anything to do with the
host group model or its management as far as i can se...

sender 
 >>of any particular multicast routing protocol, in keeping with IGMP's

i guess the only case where this isn't 100% is the debate about adding
msaks, which in abny case just supports your argument, since the
debate largely went against addign them:-)
 >>from knowledge of the multicast routing protocol du jour.

this is a misrepresentation of the change proposed in simple - the
change there was to the address format and had no efect on the
operation of IGMP, only on its payload (and then no more than IPv6
does:-)
 >>Sure, until next year, when someone comes up with the New New Multicast

yep....
 >>things you don't understand.
 
this is a bit harsh steve - someoen could understand the apparent
current technical state but get the history wrong - aerguing that they
are technically wrong _because_ they dont know the history is not a
good way to debate what may otherwise be a valid contribution...

i think whats being proposed might be thought of as IGMPbis in the
same way that SSM supports IP Multicast Servicebis -with an
appropriate applicability statement (for both the host group
management and the subset routing protocl) I dont see why this is
a totally bad idea, history notwithstanding...

 cheers

   jon
history is bunk - ford
ford is dead - god
god is dead - nietcsze
god is ford - huxley
landrover is ford - bmw

---

From: Steve Deering <[email-masked]>
Date: Sat, 29 Jul 2000 07:55:49 -0700

>receiver driven end to end protocols

Perhaps, but that wasn't the purpose at the time.

>it....

You misunderstood what I said, Jon.  The purpose of IGMP was to isolate
hosts from knowledge of the multicast routing protocols, *not* to separate
multicast routing protocols  from each other.

>debate largely went against addign them:-)

Indeed.  No smiley meeded.

>operation of IGMP, only on its payload

I wasn't talking about any changes proposed to IGMP for SSM (which can
in fact be done in a way that does no protocol-specific violence to IGMP).
I was talking about the criticism of IGMP as supporting the super-set of
various protocol-specific requirements.

>good way to debate what may otherwise be a valid contribution...

I didn't argue that they were technically wrong, just that they were
historically wrong and that they were out-of-line in claiming that IGMP
was technically wrong ("flawed").  There is no "right" or  "wrong" in
protocol design, only engineering trade-offs, and indeed theirs may well
be a valid and valuable contribution.  They shouldn't need to appeal to
imagined history to explain its merits.

>a totally bad idea, history notwithstanding...

Nor do I, nor did I say that is was.  My flame was against their shoddy
analysis of IGMP, not against their own proposal.

Steve

---

From: Lloyd Wood <[email-masked]>
Date: Sat, 29 Jul 2000 20:19:42 +0100 (BST)

> receiver driven end to end protocols

...but TCP is receiver driven! ( ack clocking, receiver windows,
Savage demonstrating subtle effects of receiver control, etc.) er,
what am I missing?

L.

> landrover is ford - bmw

dhjgfdsifg is alidaodahdl - crocrowft

<[email-masked]>PGP<http://www.ee.surrey.ac.uk/Personal/L.Wood/>