The IP over ATM Mailing List Archive by date

[Grenville Armitage <gja@bellcore.com>]

Andrew,


>>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.

>>   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.


>>1b. An alternative to (1a) would be to actually *change* the interface defini
tion 
>>   to make MCSs "expect" SJOIN/SLEAVE messages on either their ClusterControl
VC
>>   or their ServerControlVC (this is the solution that was adopted in another
 obscure 
>>   data-over-ATM protocol definition from a highly secretive non-standards bo
dy when
>>   faced with the same problem :-)

(a) MCSs dont have a ClusterControlVC 
attachment point (perhaps you meant something else?), and 

(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 appears that ipmc-12 already has the flexibility you
require (unless I've missed something or you read ipmc-12 while
thinking of an obscure data-over-ATM protocol defns from secretive
bodies :-)

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

	[..]
>>   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.

Despite your comment above being wrong, your editorial observation 
re clearer "data flow" wording is on track.  It was something I'd
personally slated for introduction into MARSv2, but that's just me.

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)}