Date: Sun, 22 Sep 1996 00:09:13 -0700 From: Julian Elischer <julian@whistle.com> 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 Message-ID: <3244E619.ABD322C@whistle.com>
next in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?3244E619.ABD322C>