The IP over ATM Mailing List Archive by date

[asmith@Baynetworks.COM (Andrew Smith)]

Whilst on the topic of MARS-MCS interfaces I have the following suggestions
for *changes* to this interface definition, in the spirit of potential
optimisations in VC usage and increasing flexibility in the face of multi-MCS
deployments. Note that none of these proposals are necessary for implementation,
they merely allow some optimisations:


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

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 another obscure 
   data-over-ATM protocol definition from a highly secretive non-standards body when
   faced with the same problem :-)


2. A more general comment would be that, in support of the WGs desire to:
   --------------------------
   + Maintain RFC1577's LIS model and minimal reliance on the ATM
     services - keep dependencies to point-to-point VCs and signaling and
     keep IP layer topology decoupled from ATM layer topology; i.e. if
     RFC1577 runs there now, RFC1577+ will run there also.
   ---------------------------
   and maybe allow use of MARS on other multicast-challenged NBMA technologies
   that we define the MARS protocol more in terms of a "data flow" abstraction and
   then define an ATM-specific piece which maps flows onto some combination
   of pt-pt and pt-mpt VCs: this is the approach being used elsewhere and, once
   you get over the initial hurdle of understanding, seems to lead to clearer protocol 
   definition text. It helps when there are several encapsulations in use
   on a single VC but the major win is that, when a VC is being shared e.g. between NHRP, 
   MARS and ATM-ARP (is this a goal/non-goal for MARS?), the protocol definition
   for each protocol does not refer to "establishing/tearing-down of VCs" but
   talks instead of "establishing a data/control flow". 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.

Apologies for the tardiness of these comments.


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