The IP Over NBMA (ION) Archive

[Grenville Armitage <gja@bellcore.com>]

Let's stand back and focus on the multicast issue for a moment.

For unicast cut-through SVCs, the major problem faced by the
protocol we call NHRP is that of cut-through discovery. Once
discovered, the target endpoint generally remains in place
or is purged.

For multicast SVCs we have _two_ substantial areas that a management
protocol (of which MARS is an example) must address. They are
group membership discovery (SVC establishment), and group membership
tracking (SVC management). MARS performs both of these for the
intra-Cluster case.

Trying to create a hypothetical multicast cut-through protocol
by focussing on the first phase (SVC establishment) solves only
part of the problem (and leads to a false sense of solvability).
The second phase, SVC management, is where you need every root
of a pt-mpt SVC to be kept up to date with group membership
changes of every remote IP/ATM interface who might possibly have
joined or left a group you're transmitting to (in order to add or
drop them as 'cut through' leaf nodes when necessary).

If you thought propagating MARS_JOIN/LEAVEs to every member
of a single cluster was a pain, you ain't seen nothing yet.

I've been working on a short document discussing this very issue,
which I hope to release as an informational I-D asap. In it
I look at the requirements placed on a hypothetical multicast
cut-through protocol, and conclude that any system that supports
multicast cut-throughs amongst participating clusters is no
different (and indeed, more complex) than simply placing all
hosts across your ATM cloud into one big cluster.

Of course, since every good protocol needs a good acronym, I
called it the Very Extensive Non-Unicast Service - VENUS.

cheers,
gja
_________________________________________________________________________
Grenville Armitage           http://gump.bellcore.com:8000/~gja/home.html
...loony at large.