Subject: RE: multicast-transition (fwd)

From: Meir Feder <[email-masked]>
Date: Wed, 7 Feb 2001 03:02:12 +0200

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

Acknowledgement
================

This document benefited a lot from discussions and specific comments of
Radia Perlman and Jon Crowcroft. Useful discussion with Suchi 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]

---------- Forwarded message ----------
Date: Tue, 6 Feb 2001 12:29:03 -0500 (EST)
From: Radia Perlman - Boston Center for Networking <[email-masked]>
To: [email-masked], [email-masked], [email-masked]
Subject: Re: multicast-transition

Re: Ross Finlayson said:

Orthogonal to this is the question of how to *find* tunnel endpoints.  The 
simplest solution would be to have this happen automatically, under the 
assumption that tunnel endpoints will be implemented in (or at least, are 
colocated with) multicast routers.  (Again, we might want to focus solely 
on SSM as a simplifying assumption here.)

**********
Here's a straightforward mechanism that does what you want, and
the tunnel endpoint can either be a router or the
Root of the tree, allowing someone to host a multicast group
before the infrastructure around him is multicast enabled, and
not change the mechanism as gradually the routers around him
become multicast enabled. Likewise, you can join a group without
being in a multicast enabled part of the world and use the
same mechanism as you would when your world becomes
multicast enabled.

As I said, there was
an internet draft from some people from a company called Bandwiz, but
I don't remember their names, and it was also part of the Simple Multicast
draft. But it's easier to understand if just the mechanism is summarized,
rather than being part of another draft. Besides, I did a quick
search for the Bandwiz internet draft
and couldn't find it. So here is a summary.

Think of a multicast group as an 8-byte quantity...Root address and
group qualifier assigned by the Root. In the case of SSM, the resulting
tree is unidirectional, but the important thing is that the Root address
is known and the group qualifier need not be universally coordinated
or unique...just unique to that Root which is hosting the group.

An application layer process at the joining host sends the equivalent of a
PIM
join message saying "join (R,G)". That message has an IP header with
destination=R (the tree root),
and an IP option that might be slow-pathed by non-multicast
routers, but will be forwarded (performance is not critical on
a join message...once the tree is set up, data can be fast pathed).

There are other encodings, like a new "protocol" (IPv4) or "next header"
(IPv6 terminology)...just so long as an "old" router will forward it
towards the Root, and a "new router" can know to trap the message
and process it.

The first multicast aware router along the path notices the message
and creates a tunnel to the source address in the IP header.

In the worst case, where only the Root and the joining endnodes are
multicast enabled for this form of multicast, the tunnel is automatically
formed between the receiver and the Root.

The more routers that get upgraded, the fewer tunnels there are, so
eventually it's really multicast rather than n unicast messages sent
by the Root.

And it's trivial to cause an endnode to be multicast enabled, since
it's a user-level process that can send the join. The join can
look the same as a router join.

And this approach has the advantage, as the Bandwiz person pointed out,
that the sender won't bother sending if nobody has joined the group.

And this approach forms the minimal number of tunnels.

This approach could also hop over routers that have run out of room
to keep state.

And I believe people have also proposed ways of reducing fanout at a node
with too many tunnels by having a multiple tunnel endpoint tell
some of the other nodes to tunnel to each other first to
consolidate tunnels. Don't remember where that was written up. Perhaps
only in an email message on some list.

Radia

---

From: Doron Rajwan <[email-masked]>
Date: Sun, 11 Feb 2001 09:52:29 +0200

I am not sure it is a good tradeoff myself. Still, you can use this method
only once per day, and use that selected MBone router for all joins /
leaves.

IP alert seems better at first, but, it requires host modification. You will
need a new version of the OS, a new device driver, or at least raw sockets.
The trace-route method does not need it!

From application point-of-view, it is better not to require administrator
privileges, and reboot. If you do not care about it, the IP alert seems
better. Please remember that we see it as a transition, nothing more.

Doron.

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
Sent: Friday, February 09, 2001 10:55 AM
To: [email-masked]
Subject: RE: multicast-transition (fwd)

I think the trace-route method is not useful 
because host has to send packets untill finding an edge multicast router.
How about the IP alert option method?
By this method, host will send an UDP packet to S only once.

>Detecting the optimal router using trace-route:

Wataru