The IP over ATM Mailing List Archive by date

Cell Relay Retreat>List Archive>month:1996-Mar> msg00177



[Date Prev][Date Next][Thread Prev][Thread Next]  
  [Date Index][Thread Index][Author Index][Subject Index]

Multicast Servers for use with MARS

  • From: Grenville Armitage <gja@bellcore.com>
  • Date: Tue, 26 Mar 1996 14:35:02 -0500
  • cc: gja@thumper.bellcore.com

Sorry I haven't had a chance to really contribute to this
thread, but I have some random observations to make.

[..joel wrote, in response to rajesh..]

>>Of course it would.  The assumption in ipmc-12 is that there is only one
>>MARS.  (Any multiple-MARS situation is presumed to be using a proprietary
>>coordination mechanism, which we can assume can cope.)

I'd like to concur with Joel's point here.

ipmc-12 contains MARS<->client (host/router interface) spec.

ipmc-12 contains a fairly basic MARS<->MCS spec.

ipmc-12 does not contain a mechanism for a distribute MARS,
however it _does_ have the hooks to allow an ipmc-12 client
to interact with member MARSs of a distribute-MARS. And, as
Joel notes, proprietary solutions for a distributed MARS may well
exist using the current ipmc-12's MARS<->client spec even
before MARSv2 comes out.

Interestingly, ipmc-12 also currently mandates that there
shall be _no more than one MCS_ per group. This is something
that had slipped my mind until just now. As I recall, this
wording was developed in the understanding that ipmc-12 (MARSv1,
whatever we want to call it) was not intended to be the
full-blown solution to all the hard problems we have in this
area.

As with the possibility of interim distributed MARS solutions,
the wording of ipmc-12 doesn't preclude people from developing
some form of distributed MCS that works with a MARSv1 type MARS.
However, this really restricts a distributed MCS to providing
fault-tolerance rather than load sharing.

	- It must look like a single MCS to the MARS (to work with
	  MARSs implemented in strict conformance with ipmc-12).
	- If the active MCS fails, one of the backups takes its
	  place.

(although, this could be relaxed if someone developed a MARSv1
type MARS that didn't enforce the single-MCS-per-group rule. In
this case perhaps some of rajesh's load sharing ideas could
be built into the distributed MCS without the knowledge of
the v1 MARS. Ultimately, though, this is best considered a proprietary
interim hack on MARSv1.)

In the longer term, MARSv2 is where we should focus on introducing
both distributed MARS functionality, and load sharing support
for distributed MCSs. (I'll admit this is a refinement of my earlier
half-baked hope that some form of distributed MCS could be built
externally to the MARS, v1 or v2. I live and learn.)

cheers,
gja
_________________________________________________________________________
Grenville Armitage                               gja@thumper.bellcore.com
Bellcore, 445 South St.      http://gump.bellcore.com:8000/~gja/home.html
Morristown, NJ 07960 USA          (voice) +1 201 829 2635 {.. 2504 (fax)}