RE: Automatic Tunneling for Rapid Multicast Deployment

[Doron Rajwan <Doron@bandwiz.com>]

Steve Deering is right about the separation between protocols. We were not
involved in the creation of IGMP, only read the IGMP RFC itself. So we
probably misunderstood this point.

By the "dense-mode" we meant that the query mechanism used by IGMP is
efficient in the case that several hosts on the same LAN listen to the same
multicast group at the same time. Our claim is that this will not be the
typical case for SSM. Maybe part of the IGMP complexity is to provide this
ability, which is not needed for the SSM.

Our purpose in this document is to promote something in which we all share a
common interest, i.e. quick multicast deployment. For this we propose to
design a generic multicast tunnel protocol, sending IGMPv3-in-UDP packets,
etc. We are ready to implement the host side of the protocol, and make it
available as an open-source. This protocol will meet both goals: separation
and quick deployment. This is the important thing in our comments. The
remarks on IGMP are not a necessary important part of that, and so in order
to avoid dis-focusing on the goal we re-submit the document without the IGMP
part.

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:
=========