From owner-freebsd-atm  Sun Sep 22 00:13:02 1996
Return-Path: owner-atm
Received: (from root@localhost)
          by freefall.freebsd.org (8.7.5/8.7.3) id AAA07927
          for atm-outgoing; Sun, 22 Sep 1996 00:13:02 -0700 (PDT)
Received: from alpo.whistle.com (s205m1.whistle.com [207.76.205.1])
          by freefall.freebsd.org (8.7.5/8.7.3) with ESMTP id AAA07882
          for <atm@freebsd.org>; Sun, 22 Sep 1996 00:12:58 -0700 (PDT)
Received: from current1.whistle.com (current1.whistle.com [207.76.205.22]) by alpo.whistle.com (8.7.5/8.7.3) with SMTP id AAA11265; Sun, 22 Sep 1996 00:10:51 -0700 (PDT)
Message-ID: <3244E619.ABD322C@whistle.com>
Date: Sun, 22 Sep 1996 00:09:13 -0700
From: Julian Elischer <julian@whistle.com>
Organization: Whistle Communications
X-Mailer: Mozilla 3.0b6 (X11; I; FreeBSD 2.2-CURRENT i386)
MIME-Version: 1.0
To: atm@freebsd.org, grefen@carpe.net, hm@kts.org,
        drochner@zelux6.zel.archer@cmr.kiev.ua,
        kfa-juelich.de@alpo.whistle.com, rminnich@Sarnoff.COM
CC: dennis@etinc.com
Subject: VC support, *BSD and atm/frame/isdn
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-atm@freebsd.org
X-Loop: FreeBSD.org
Precedence: bulk

Well I've been threatenning for a while to start working on this...
well we've got the first version out of the way,
(see http://ww.whistle.com) so now I've  enough time
to start thinking about this again.

I've been looking at chuck cranor's stuff.
it's not bad, but very
atm specific (anyone have his email address?
I'd like to include him in the conversation.)

Ron, You once indicated that you prefered the etinc style of 
things, where each VC became a separate interface, and indead
I've been using that style of things here myself. but
you've been recomending chuck's work, and I see that it has a single
interface  for the hardware, and uses routing tables 
and llinfo (arpish) information to connect VCs with 
logical connections. 
Have you changed your mind? or do you consider the two approaches 
to be reconcilable? 
I have some code to make the interface/per VC approach
more generic (i.e it can be easily applied to any low level driver
to support VCs by creating interfaces as needed etc.)
but there are problems I couldn't get around 
with the One iffor all VCs approach that
I don't see being addressed in teh Open/Net BSD 
code..
1/ Frame relay may require a different mtu per VC
2/ some VC's may be grouped together in a network that
would look like an ether net.. e.g. several nodes on the other ends
migh be in the same 'net' or alternatively they might be
set up like P2P links in which case the routing
is done with host routes to the far end rather than
a net route for the near end + llinfo.
how do you get an interface to be both net oriented, and P2P
at teh same time (one could concievably
have both setups on a single ATM/Frame interface at the same time)
similarly for ISDN with multile B channels.
different VCs migh tbe using totally different encapsulations
(e.g. PPP, rfc1490, rfc1973, raw-ip, SNAP, ether-emulation etc,etc.)

any of you guys have thoughts on this?

for what I've done so far as an experiment,
look at:
ftp://ref.tfs.com/incoming/VC.tar
I've layerd this onto a stipped down version of a driver
for the SGS mk50h28 frame chip (hey it ain't released code so don't
spread that part too much..) it's just an example of how it MIGHT work.
the VC code only supports rfc1490 but you could add modules to do 
other  types just as easily...
this all assumes however that one if/VC is acceptable..

julian