Date: Mon, 23 Sep 1996 02:05:38 +0200 From: Stefan Grefen <grefen@carpe.net> To: Julian Elischer <julian@whistle.com> Cc: atm@freebsd.org, hm@kts.org, drochner%zelux6.zel.archer@cmr.kiev.ua, kfa-juelich.de@alpo.whistle.com, rminnich@Sarnoff.COM, dennis@etinc.com Subject: Re: VC support, *BSD and atm/frame/isdn Message-ID: <1892.843437138@hex.grefen.carpe.net> In-Reply-To: Julian Elischer's message <3244E619.ABD322C@whistle.com> of Sun, 22 Sep 96 00:09:13 PDT. References: <3244E619.ABD322C@whistle.com>
next in thread | previous in thread | raw e-mail | index | archive | help
In message <3244E619.ABD322C@whistle.com> Julian Elischer wrote: [...] > > 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. I see someone else is working on this too. The basic code should be shared between all implementations, so that the modules can be reused for different hardware devices. > 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 Depends on who wants to know it: For user programs (ioctl's) it's hard to make that work without changes. For TCP you can attach it to the route, and for IP-output code can be added to also honor the routing table entry. > 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. This would be handled by the routing code. The Interface would have one (or several) IP-Addresses (because they have to be attached somewhere), but no idea of P2P or net oriented. The difference would be a NET or HOST route. The specific stuff must be handled by the module that pushed (oops streams term). Destination address is not needed here because this differentiation between network and P2P links is for routing purposes that don't apply here (we don't need to find an interface because it's specified in the route). The encapsulation type and dest ATM/VC/ISDN address would be in the llinfo. > different VCs migh tbe using totally different encapsulations > (e.g. PPP, rfc1490, rfc1973, raw-ip, SNAP, ether-emulation etc,etc.) There shouldn't be a problem with that. There must be a common way to specify the module (and parameters for it) in the LLINFO. > > any of you guys have thoughts on this? Reading that, Anybody thought of implementing a rudimentary STREAMS version (with the possibility to make the head end in an interface to be compatible with the rest of the kernel). We would simply redesign the streams functionality in incompatible way. (I don't think we would come up with a programming model that so much better than streams, that it is worth to be incompatible ( I DIDN'T said it can't be done better, but this is another research project)). At the moment I get paid for hacking streams-modules, and I volunteer to work on this STREAMS for BSD stuff. The only tricky (and maybe incompatible) thing would be the usage of MBUFS instead of STREAMS mblk_t / datab pairs.. We would solve all of our problems here (and we could reuse our modules for SYS5 systems or SYS5 modules as available) ... This would be a (kind of) IF per VC structure. But below that IF multiplexor modules can merge any number of real interfaces to any number of pseudo interfaces, plus that the real interface wouldn't be a BSD network-interfaces so all above problems wouldn't appear. For our *BSD systems an interface would 'magicly' appear with all characteristics properly set. [...] Stefan > this all assumes however that one if/VC is acceptable.. > > julian -- Stefan Grefen Am Grossberg 16, 55130 Mainz, Germany grefen@carpe.net +49 6131 998566 Fax:+49 6131 998568 Living on Earth may be expensive, but it includes an annual free trip around the Sun.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?1892.843437138>