RE: multicast-transition (fwd)

[Meir Feder <Meir@bandwiz.com>]

 As the presentation of Doron Rajwan (Bandwiz CTO) in Pittsburgh on
automatic tunneling 
came up in the recent discussion, here is what was submitted on the subject.
As always,
any comment is welcomed. We do hope that the automatic tunneling will be
pushed forward
in standardization and implementation, in any reasonable way. For this we
also support 
Toni Ballardie's efforts. Automatic tunneling can definitely assist in rapid
global multicast deployment.

 Meir

-------------------------------------------
Professor Meir Feder
Chief Scientist
Bandwiz



====================================================
 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 list 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 Randevous 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
rentier 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:
=========