No Subject

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.
doron@bandwiz.com

Meir Feder
BandWiz Inc.
meir@bandwiz.com



 

---------- Forwarded message ----------
Date: Tue, 6 Feb 2001 12:29:03 -0500 (EST)
From: Radia Perlman - Boston Center for Networking <radia@bcn.East.Sun.COM>
To: ssm-interest@external.cisco.com, maddogs@ietf.org, finlayson@live.com
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