Subject: Re: IGMP Proxying and CBT/Simple Multicast

From: Christoph Reichert <[email-masked]>
Date: Thu, 1 Mar 2001 22:03:27 +0100

On Thu, Mar 01, 2001 at 02:55:38PM -0500, Radia Perlman - Boston Center for Networking wrote:

[...]

> or not. Bidirectional trees (which Simple Multicast
> advocated) would make multi-sender applications
> more efficient, and perhaps can be explored at some point in the future,
> but the notion of "explicit Root" multicast is the most
> critical portion of both proposals, and is becoming a success, I believe.

I understand that the "explicit root" identification of a tree is the
important thing.
This requires IGMP to be extended to carry (R, G) pairs, right ?

[...]

> I don't think Root centered trees solve ALL possible multicast, by the way.
> I still think there's a place for very localized "dense mode" multicast,
> to solve things similarly to what's solved in layer 2 multicast...e.g.,
> finding something. That would not be Root-hosted, but would involve
> a small number of more-or-less statically allocated groups, as opposed

I understand that (R, G)-trees are for wide-area multicasting, and
that "dense-mode" is good for finding local time servers etc.

How will hosts differentiate between rooted trees and "dense" trees ?
(0.0.0.0, G) versus (R, G) ?

> An interesting alternative to this "dense"
> form of multicast, though, is "anycast",
> which will only find one of the thing you search for, which might be
> all you need (unless the one the routing structure finds for you is
> broken or something).

I understand anycast, and that it is provided natively in IPv6.  IPv6
uses a separate portion of IPv6's address space for anycast.
How will this be done in IPv4 ?

> Radia

chris

---

From: Radia Perlman - Boston Center for Networking <[email-masked]>
Date: Thu, 1 Mar 2001 14:55:38 -0500 (EST)

Re: Christoph Reichert's email:

	b) Why is simple multicast scheme 
(draft-perlman-simple-multicast-03.txt)
	   not a great success ? :-)
	
	   To me, it seems to solve all multicast problems at once
	   (address allocation, core discovery etc.)
	
The main point of Simple Multicast was Root-centered trees, and
you're right that it makes address allocation and core
discovery simple. It's
really quite similar to what's being called
"Single Source", in that a group is (R,G)
with R (the Root's address) being known as an attribute of the group,
and G being assigned by that R, with no need for it
to be globally unique. The only real difference between what's
called "single source" (which used to be called Express), and
what was called "Simple Multicast" is whether the trees are bidirectional
or not. Bidirectional trees (which Simple Multicast
advocated) would make multi-sender applications
more efficient, and perhaps can be explored at some point in the future,
but the notion of "explicit Root" multicast is the most
critical portion of both proposals, and is becoming a success, I believe.

Anything that can be done with bidirectional trees can be done with
unidirectional trees by tunneling to the Root and having the Root
multicast, or by forming a different tree per sender. Bidirectional
trees are only an optimization, and not nearly as important to
making the idea of easily, efficiently, and dynamically creating
millions of multicast groups with far-flung membership, as
the basic idea of getting rid of the need to do global coordination
of addresses or needing algorithms to find the Root of the tree to be formed.

I don't think Root centered trees solve ALL possible multicast, by the way.
I still think there's a place for very localized "dense mode" multicast,
to solve things similarly to what's solved in layer 2 multicast...e.g.,
finding something. That would not be Root-hosted, but would involve
a small number of more-or-less statically allocated groups, as opposed
to conference calls, or data-pushing web-sites, or in the most
touching example someone gave to me...multicasting all church services
from all over the world to anyplace in the Internet, which are perfectly
suited to Root-hosted multicast.

Since "dense-mode" multicast can't be efficient in huge areas,
I sympathize with those that say that form of
multicast is dangerous to deploy, but I believe such
multicast will always be useful if confined
to very low bandwidth applications (finding something with probing with
very low-frequency), and in a limited region. (I suspect it would be
very rare for anyone to configure a firewall to let such traffic pass through,
for instance), or even to accept it from a foreign domain.

My favorite use of this form of multicast would be finding a nearby
directory server, or time server.

Radia

---

From: JINMEI Tatuya / 神明達哉 <[email-masked]>
Date: Fri, 02 Mar 2001 16:28:12 +0900

>>>>> On Thu, 1 Mar 2001 22:03:27 +0100, 
>>>>> Christoph Reichert <[email-masked]> said:

> uses a separate portion of IPv6's address space for anycast.

No, that's not true.  Section 2.6 of RFC2373 says

   Anycast addresses are allocated from the unicast address space, using
   any of the defined unicast address formats.  Thus, anycast addresses
   are syntactically indistinguishable from unicast addresses.  When a
   unicast address is assigned to more than one interface, thus turning
   it into an anycast address, the nodes to which the address is
   assigned must be explicitly configured to know that it is an anycast
   address.

					JINMEI, Tatuya
					Communication Platform Lab.
					Corporate R&D Center, Toshiba Corp.
					[email-masked]