The IP over ATM Mailing List Archive by date

[asmith@Baynetworks.COM (Andrew Smith)]

> From gja@thumper.bellcore.com Tue Mar 26 13:56:40 1996
> To: asmith@BayNetworks.COM (Andrew Smith)
> Cc: ip-atm@nexen.com, gja@thumper.bellcore.com
> Subject: Re: MARS ipmc-12 suggestions 
> In-Reply-To: Your message of Tue, 26 Mar 1996 10:48:01 -0800.
>              <9603261848.AA08790@milliways-le0.engwest> 
> Date: Tue, 26 Mar 1996 16:53:11 -0500
> From: Grenville Armitage <gja@bellcore.com>

Grenville,
 
> >>1a. *change* the interface definition in ipmc-12 section 6.2 to allow a MARS to 
> >>   use a point-to-point VC for the ServerControlVC if it knew
> >>   it would never be adding more than one leaf - as written, a MCS is allowed
> >>   to reject the ServerControlVC SETUP if it did not have the pt-mpt bit set.
> 
> But since the text does not _require_ an MCS to reject pt-pt calls, ipmc-12
> has the flexibility you're after already.

Not true: we need to specify necessary and sufficient rules. The problem in this 
case is that a MCS perfectly compliant with the current text *is allowed* to assume
that its ServerControlVC will be point-to-multipoint because the text says that
the MARS *must* use a point-to-multipoint VC. If we now *allow* the MARS to
use a pt-pt then we have a classic interoperability loophole. Hence, the
right "flexibility" fix is to *allow* the MARS to use a pt-pt but also *not
allow* the MCS to assume pt-pt. (Of course the issue of what flexibility to allow
is orthogonal to loophole-free text: let's discuss the flexibility issue and 
fix text when we have consensus that this flexibility is desireable or otherwise)

> >>   Note that pt-mpt calls, even those with a single leaf, can be a lot more 
> >>   expensive than pt-pt in some ATM switch implementations.
> 
> Reality check here - are you _seriously_ suggesting people are going
> to be building MARS-based IP multicast over ATM solutions when their
> ATM switches are having trouble coping with a pt-mpt VC with a _single_
> leaf node!? C'mon Andrew, lets not optimize for silly cases.

It's not a case of "having trouble with a pt-mpt VC", it's just an economic 
argument not to waste resources unnecessarily: I believe there will be a 
cost differential between pt-pt and pt-mpt-with-a-single-leaf in many
cases (do any other switch vendors think this important? If not, I'll willingly
wear the "silly" hat and do a "silly walk" off into the corner). Against this we should 
weigh the extra cost of some more words in a protocol spec and some more lines of code.
 
> >>1b. An alternative to (1a) would be to actually *change* the interface definition 
> >>   to make MCSs "expect" SJOIN/SLEAVE messages on either their ClusterControlVC
> >>   or their ServerControlVC (this is the solution that was adopted in anotherobscure 
> >>   data-over-ATM protocol definition from a highly secretive non-standards body when
> >>   faced with the same problem :-)
> 
> (a) MCSs dont have a ClusterControlVC 
> attachment point (perhaps you meant something else?), and

I guess what I meant was "the nameless pt-pt VC that the MCS first used to contact 
the MARS". Sorry for my confusion. Do a global replace in my original comment.

> (b) I couldn't find anything in ipmc-12 that currently requires an
> MCS to verify that the SJOIN/SLEAVE arrived on the actual ServerControlVC. 

Again, it does not *require* MCS to verify but it does *allow* MCS to 
assume it. The text probably should not allow this assumption.

... 
> What isn't actually in ipmc-12 doesn't need to be changed, does it?

Not necessarily true (see my comment above about freedom from loopholes).
 
> 	[..]
> >>   I think as currently written,
> >>   it would be difficult (impossible?) to share VCs between ATM-ARP and MARS 
> for
> >>   example, because of the references to particular VCs.
> 
> Well, dont tell that to my ATMARP/MARS client. It seems to quite happily
> share the control VC to my MARS/ATMARPServer. But that's because I,
> like any implementor, recognise that encapsulation means I _can_
> share VCs even if the ipmc-12/nhrp-08/1577 texts dont hold me by
> the hand and tell me this.

But in some cases ipmc-12 *does* hold your hand and tell you explicitly to
establish and tear-down VCs. So you have probably broken (or at least bent)
some of your own explicit rules to make it work. But you're right - any
remotely intelligent implementor knows which rules can and cannot be
bent to get the commercially-necessary level of interoperability.

> cheers,
> gja

Andrew

********************************************************************************
Andrew Smith					TEL:	+1 408 764 1574
Technology Synergy 				FAX:	+1 408 988 5525
Bay Networks, Inc.				E-m:	asmith@baynetworks.com
Santa Clara, CA
********************************************************************************