The IP over ATM Mailing List Archive by date

[asmith@Baynetworks.COM (Andrew Smith)]

> From owner-ip-atm@nexen.com Tue Mar 26 08:50:37 1996
> From: taddy@cc.gatech.edu (Rajesh Talpade)
> Subject: Re: Multicast Servers for use with MARS
> To: jhalpern@us.Newbridge.com (Joel Halpern)
> Date: Tue, 26 Mar 1996 11:48:25 -0500 (EST)
> Cc: ip-atm@nexen.com

Rajesh,

> I suppose the limitation you refer to is the fact that the MARS will
> have to use a different VC for sending MARS_SJOIN/MARS_SLEAVE in
> the example above. Is this still preserving the ipmc-12 MARS<->MCS 
> interface ? What if client implementations expect MARS_SJOIN/MARS_SLEAVE
> on ServerControlVC only ?

Yes this still preserves the MARS-MCS interface: from the point of view of 
the *interface* definition in ipmc-12 section 6.2, there is no need for a 
MARS to establish the ServerControlVC to *all* MCSs: a MARS would be perfectly 
compliant if it used a different ServerControlVC to each MCS.

Agreed, this is somewhat suboptimal in VC usage and we could maybe fix that before 
RFCing ipmc-12 but this is not really important if the number of MCSs is only a 
handful - 1 extra VC per MCS and one extra packet copy/AAL5_Send per control message.

I have some other tightening/easing of restrictions suggestions for ipmc-12 (it's
amazing the ideas you get when you actually read it in detail - sorry Grenville): 
I will suggest these in a different message and someone else can rule whether they
are too late or not.

> 
> Regards,
> Rajesh.

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