Re: multicast-transition

[Radia Perlman - Boston Center for Networking <radia@bcn.East.Sun.COM>]

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