The IP over ATM Mailing List Archive by date

Cell Relay Retreat>List Archive>month:1995-May> msg00164



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

New encaps not really needed for Multicast Servers

  • From: bryang@eng.adaptec.com (Bryan Gleeson)
  • Date: Thu, 18 May 95 13:47:46 PDT
  • CC: ip-atm@matmos.hpl.hp.com

Jim,

>Not nearly so bad as if you change encapsulations.  We have over a thousand
>ATM interfaces that we've shipped, and we thought the encapsulation stuff
>had been put to bed.  It would be unfortunate if vendors that had nothing
>to lose were not sympathetic to the fact that there *is* an installed base.
>
>I don't see any difference in cycles whatsoever between doing at the IP
>layer or below.  In either case it's one comparison statement.  There might
>be some savings in memory cycles by not lengthening the encapsulation, but
>all this is second or third order compared to changing an installed base.
>

The idea that a new encapsulation, used as part of a new protocol, somehow
breaks an existing installed base is completely bogus. The charge has
been made before, and been refuted before, but let's do it one more time.

For a start it is protocols that are compatible or otherwise with each
other, not encapsulations. Right now 1577/1755 defines the use of two encapsulations,
LLC/SNAP and the null encapsulation, and the rules for using them. Nobody
argues that were somebody to implement the null encapsulation that it
would break anything. With 1577/1755 we don't have any rules for the
encapsulations used on multipoint connections, because we don't have
a protocol which specifies the use of such multipoint connections.
The MARS draft does specify the use of multipoint connections, and
it may be necessary to define an echo-encaps and the rules for its
use, also. Nowhere does it, or will it, say that the encapsulations used 
on unicast / ARP server derived VCCs need to be changed, given that
it is an addition to, not a replacement of, the existing standards,
and the MARS does not deal with unicast address resolution and
subsequent VCC management.

Given this perhaps you could clarify exactly what field upgrades
will be needed to your 1000+ interfaces to maintain their existing
functionality in the presence of deployed MARS-conformant products 
which make use of a new encapsulation ?

Bryan Gleeson,
Adaptec.