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 ; 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 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 From owner-freebsd-atm Sun Sep 22 17:12:52 1996 Return-Path: owner-atm Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id RAA15659 for atm-outgoing; Sun, 22 Sep 1996 17:12:52 -0700 (PDT) Received: from gargoyle.carpe.net (root@gargoyle.carpe.net [194.162.243.7]) by freefall.freebsd.org (8.7.5/8.7.3) with ESMTP id RAA15583 for ; Sun, 22 Sep 1996 17:12:44 -0700 (PDT) Received: from helva.grefen.carpe.net (helva.grefen.carpe.net [194.162.243.129]) by gargoyle.carpe.net (8.7.4/8.7.3) with ESMTP id CAA13633; Mon, 23 Sep 1996 02:16:03 +0200 (MET DST) Received: from hex.grefen.carpe.net (root@hex [194.162.243.130]) by helva.grefen.carpe.net (8.7.5/8.7.3) with ESMTP id CAA13399; Mon, 23 Sep 1996 02:05:42 +0200 (MET DST) Received: from hex.grefen.carpe.net (grefen@localhost [127.0.0.1]) by hex.grefen.carpe.net (8.7.3/8.7.3) with ESMTP id CAA01908; Mon, 23 Sep 1996 02:05:40 +0200 (MET DST) To: Julian Elischer 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 Reply-To: 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> Date: Mon, 23 Sep 1996 02:05:38 +0200 Message-ID: <1892.843437138@hex.grefen.carpe.net> From: Stefan Grefen Sender: owner-atm@freebsd.org X-Loop: FreeBSD.org Precedence: bulk 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. From owner-freebsd-atm Sun Sep 22 19:13:12 1996 Return-Path: owner-atm Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id TAA00348 for atm-outgoing; Sun, 22 Sep 1996 19:13:12 -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 TAA00243 for ; Sun, 22 Sep 1996 19:12:59 -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 TAA19036; Sun, 22 Sep 1996 19:11:20 -0700 (PDT) Message-ID: <3245F162.5656AEC7@whistle.com> Date: Sun, 22 Sep 1996 19:09:38 -0700 From: Julian Elischer Organization: Whistle Communications X-Mailer: Mozilla 3.0b6 (X11; I; FreeBSD 2.2-CURRENT i386) MIME-Version: 1.0 To: grefen@carpe.net CC: atm@freebsd.org, hm@kts.org, rminnich@Sarnoff.COM, dennis@etinc.com Subject: Re: VC support, *BSD and atm/frame/isdn References: <3244E619.ABD322C@whistle.com> <1892.843437138@hex.grefen.carpe.net> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-atm@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Stefan Grefen wrote: > > 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. Well I agree, but do we have any of the other players? I know that dennis' main comment was "don't break what already works" and I have to admit that that must be a primary goal. Also, re-used with different transports.. I wonder if there is a better forum for this, and what about the Net/Open-BSD guys? > > 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). yes, that's (kind of) what OSF did.. > > 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.. The main thing I want to get to is to complete teh transition in teh way that mbufs are considered, (from the original) buffer with a descriptor structure tacked on teh front, to a buffer descriptor which "HAPPENS" to come with a ready made buffer but usually doens't use it.. OSF have a NEAT way of doing this.. and I think Matt Thomas is considering adding it to the kernel. it allows random malloc'd memory to be used to hold net data (or any other random allocation scheme). it's really a sematic differnece, but Van jacobson, in his rehash, had a replacement that I forget the name of, In his scheme, the buffer portion of the mbuf was ALWAYS a separate memory chunk. The descriptors were only the front art of the current mbuf. anyway I digress. yes something that has at least LEARNED from STREAMS would be good, even if it ISN'T STREAMS. (Not to decide right now) > > 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 It doesn't help NetBSD and Open BSD, but I (for the Interjet) was considering making devices flash in and out of existance in the device filesystem for control purposes, rather than in the 'if-space'. thus the actual frame card would be a DEVICE rather than an interface, and the VCs would be Interfaces, unlike in my present code, where both levels are "interfaces" so that it gets confusing as to which you should be using.. > 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. > > [...] > Well all very nice. Other design goals.. arbitrary stacking order.. e.g. ppp over frame over sync ppp over frame over ISDN Bmux ppp over sync ppp over atm AAL5 pdu ip over all the above, ppp over rfc1490 over all the above etc. loadable modules with arbitrary naming (e.g. link by NAME not address or magic number.."PPP" not 0x03) etc. etc stefan.. you said earier you had 'hacked the sppp code to run on BISDN. can you share what the hacks were? julian (I'd like to "hack it " to make it a module in the VC package I sent out..... julian From owner-freebsd-atm Mon Sep 23 01:42:46 1996 Return-Path: owner-atm Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id BAA29838 for atm-outgoing; Mon, 23 Sep 1996 01:42:46 -0700 (PDT) Received: from gargoyle.carpe.net (root@gargoyle.carpe.net [194.162.243.7]) by freefall.freebsd.org (8.7.5/8.7.3) with ESMTP id BAA29796 for ; Mon, 23 Sep 1996 01:42:39 -0700 (PDT) Received: from helva.grefen.carpe.net (helva.grefen.carpe.net [194.162.243.129]) by gargoyle.carpe.net (8.7.4/8.7.3) with ESMTP id KAA13881; Mon, 23 Sep 1996 10:46:06 +0200 (MET DST) Received: from hex.grefen.carpe.net (root@hex [194.162.243.130]) by helva.grefen.carpe.net (8.7.5/8.7.3) with ESMTP id KAA13946; Mon, 23 Sep 1996 10:23:27 +0200 (MET DST) Received: from hex.grefen.carpe.net (grefen@localhost [127.0.0.1]) by hex.grefen.carpe.net (8.7.3/8.7.3) with ESMTP id KAA03142; Mon, 23 Sep 1996 10:23:25 +0200 (MET DST) To: Julian Elischer Cc: atm@freebsd.org, hm@kts.org, rminnich@Sarnoff.COM, dennis@etinc.com Subject: Re: VC support, *BSD and atm/frame/isdn Reply-To: grefen@carpe.net In-reply-to: Julian Elischer's message <3245F162.5656AEC7@whistle.com> of Sun, 22 Sep 96 19:09:38 PDT. References: <3244E619.ABD322C@whistle.com> <1892.843437138@hex.grefen.carpe.net> <3245F162.5656AEC7@whistle.com> Date: Mon, 23 Sep 1996 10:23:24 +0200 Message-ID: <3139.843467004@hex.grefen.carpe.net> From: Stefan Grefen Sender: owner-atm@freebsd.org X-Loop: FreeBSD.org Precedence: bulk In message <3245F162.5656AEC7@whistle.com> Julian Elischer wrote: > Stefan Grefen wrote: > > In message <3244E619.ABD322C@whistle.com> Julian Elischer wrote: > > [...] > > 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. > Well I agree, but do we have any of the other players? > I know that dennis' main comment was "don't break what already works" > and I have to admit that that must be a primary goal. > Also, re-used with different transports.. > I wonder if there is a better forum for this, and what about the > Net/Open-BSD guys? If there is existing code doing something like thise (besides your stuff that I know) I would like to have look at it so I don't do it differently. Why should there be a problem with different transports? Basic stuff like the MTU needs to be configurable by the transport, and existing modules may be needed to split in a protocol and a transport part (if there is a transport depended address in it). BTW. I'm running NetBSD and BSDI's BSD/OS, which both share the problem of dynamnic devices. But I think this is not a major problem for interfaces, You just can't free the associatet memory chunk (dangling pointer problem). I've done that with pcmcia-devices in NetBSD and could attach/detatch/reattach them. > > > > 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). > yes, that's (kind of) what OSF did.. Kind of, the lower levels are even more nasty (at least in /AD). > > > > > 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 bette > r > > 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.. > > The main thing I want to get to is to complete teh transition > in teh way that mbufs are considered, (from the original) > buffer with a descriptor structure tacked on teh front, > to a buffer descriptor which "HAPPENS" to come with a ready made buffer > but usually doens't use it.. > OSF have a NEAT way of doing this.. > and I think Matt Thomas is considering > adding it to the kernel. > it allows random malloc'd memory to be used > to hold net data (or any other random allocation scheme). Thats the same thing streams do, and MBUFS are able to hold 'external' memory today (at the cost of a wasted MBUF per memory chunk, which is unaccapetable for a streams/MBUF gateway). > > it's really a sematic differnece, but Van jacobson, in his rehash, had > a replacement that I forget the name of, > In his scheme, the buffer portion of the mbuf was ALWAYS a separate > memory chunk. The descriptors were only the front art of the current > mbuf. > anyway I digress. > yes something that has at least LEARNED from STREAMS would be good, > even if it ISN'T STREAMS. (Not to decide right now) If we would agree on model for the modules, that is streams with exeception that msgb_t is a struct mbuf, b_rptr=mh_data and b_wptr=mh_data+mh_len and forget about the data blocks, we would have the structure as the streams systeam and if Matt adds his stuff, we could even go to using data blocks with out wasting an MBUF each time. As I said before, there may be a better model for this, but streams is a working model for stacking protocol modules. > > > > > 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 interfac > es > > It doesn't help NetBSD and Open BSD, but I (for the Interjet) > was considering making devices flash in and out of existance in the > device filesystem for control purposes, Thats missing in Net/open yet, but I don't comsider that as a major problem. > rather than in the 'if-space'. thus the actual frame card would be a > DEVICE > rather than an interface, and the VCs would be Interfaces, unlike > in my present code, where both levels are "interfaces" so that > it gets confusing as to which you should be using.. That was my main objection to stacking 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. > > [...] > Well all very nice. > Other design goals.. > > arbitrary stacking order.. > e.g. > ppp over frame over sync > ppp over frame over ISDN Bmux > ppp over sync > ppp over atm AAL5 pdu > ip over all the above, > ppp over rfc1490 over all the above > etc. > > loadable modules with arbitrary naming > (e.g. link by NAME not address or magic number.."PPP" not 0x03) > etc. etc > > stefan.. you said earier you had 'hacked the sppp code to run on BISDN. > can you share what the hacks were? As I'm using NetBSD I looked at hacking if_ppp.c but did get it working without changes in if_ppp.c. The isdn code attaches to the existing if_ppp. This is for the current BISDN, the rewrite to make it a network protocol is not far enough. > > julian (I'd like to "hack it " to make it a module in the VC package > I sent out..... The NetBSD if_ppp may be a good starting point, as this PPP -async stuff. (the is ppp_tty.c for that). The big problem for me was to get a file-handle for the ioctl-stuff and lcp/chap packets etc. passes up to the pppd daemon. I used existing isdn infrastructure for that (Some resulting kludge was one of my main reasons to reconsider they way isdn is done in the kernel). My stuff should be at ftp.ditec.de:pub/bisdn/ppp. (there is a header file missing, I hope to add today :-)) Stefan > > 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. From owner-freebsd-atm Mon Sep 23 10:51:52 1996 Return-Path: owner-atm Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id KAA08173 for atm-outgoing; Mon, 23 Sep 1996 10:51:52 -0700 (PDT) Received: from terra.Sarnoff.COM (terra.sarnoff.com [130.33.11.203]) by freefall.freebsd.org (8.7.5/8.7.3) with SMTP id KAA08152 for ; Mon, 23 Sep 1996 10:51:50 -0700 (PDT) Received: (from rminnich@localhost) by terra.Sarnoff.COM (8.6.12/8.6.12) id NAA19106; Mon, 23 Sep 1996 13:41:11 -0400 Date: Mon, 23 Sep 1996 13:41:10 -0400 (EDT) From: "Ron G. Minnich" X-Sender: rminnich@terra To: Stefan Grefen cc: Julian Elischer , atm@freebsd.org, hm@kts.org, drochner%zelux6.zel.archer@cmr.kiev.ua, kfa-juelich.de@alpo.whistle.com, dennis@etinc.com, Chuck Cranor , Jason Thorpe Subject: Re: VC support, *BSD and atm/frame/isdn In-Reply-To: <1892.843437138@hex.grefen.carpe.net> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-atm@freebsd.org X-Loop: FreeBSD.org Precedence: bulk I've added chuck to the this CC: list. Also just added jason, I'm hoping that the fact that we're mixing Jets and Sharks is not a problem :-) > 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. > > Have you changed your mind? or do you consider the two approaches > > to be reconcilable? I still like IF per VC. Thus I am hoping to see IF per VC added to chuck's code or to the system itself in some way. Jason Thorpe of netbsd has some good ideas in this area. I have looked at chuck's code quite a bit and feel that it is not incompatible with IF per VC. > > 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.) I'm interested. The card I'm building is going to require that a virtual interface per vc work in some way. thanks julian, this is really interesting! ron From owner-freebsd-atm Mon Sep 23 13:13:10 1996 Return-Path: owner-atm Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id NAA26730 for atm-outgoing; Mon, 23 Sep 1996 13:13:10 -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 NAA26699 for ; Mon, 23 Sep 1996 13:13:05 -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 NAA03768; Mon, 23 Sep 1996 13:07:58 -0700 (PDT) Message-ID: <3246EDBA.102F11D5@whistle.com> Date: Mon, 23 Sep 1996 13:06:18 -0700 From: Julian Elischer Organization: Whistle Communications X-Mailer: Mozilla 3.0b6 (X11; I; FreeBSD 2.2-CURRENT i386) MIME-Version: 1.0 To: "Ron G. Minnich" CC: Stefan Grefen , atm@freebsd.org, hm@kts.org, drochner%zelux6.zel.archer@cmr.kiev.ua, kfa-juelich.de@alpo.whistle.com, dennis@etinc.com, Chuck Cranor , Jason Thorpe Subject: Re: VC support, *BSD and atm/frame/isdn References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-atm@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Ron G. Minnich wrote: > I'm interested. > > The card I'm building is going to require that a virtual interface per vc > work in some way. > > thanks julian, this is really interesting! did you get the tar file? > > ron From owner-freebsd-atm Mon Sep 23 18:12:59 1996 Return-Path: owner-atm Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id SAA10667 for atm-outgoing; Mon, 23 Sep 1996 18:12:59 -0700 (PDT) Received: from gargoyle.carpe.net (root@gargoyle.carpe.net [194.162.243.7]) by freefall.freebsd.org (8.7.5/8.7.3) with ESMTP id SAA10607 for ; Mon, 23 Sep 1996 18:12:46 -0700 (PDT) Received: from helva.grefen.carpe.net (helva.grefen.carpe.net [194.162.243.129]) by gargoyle.carpe.net (8.7.4/8.7.3) with ESMTP id DAA16767; Tue, 24 Sep 1996 03:16:05 +0200 (MET DST) Received: from hex.grefen.carpe.net (root@hex [194.162.243.130]) by helva.grefen.carpe.net (8.7.5/8.7.3) with ESMTP id CAA16123; Tue, 24 Sep 1996 02:54:39 +0200 (MET DST) Received: from hex.grefen.carpe.net (grefen@localhost [127.0.0.1]) by hex.grefen.carpe.net (8.7.3/8.7.3) with ESMTP id CAA05903; Tue, 24 Sep 1996 02:54:37 +0200 (MET DST) To: "Ron G. Minnich" Cc: Julian Elischer , atm@freebsd.org, hm@kts.org, drochner%zelux6.zel.archer@cmr.kiev.ua, kfa-juelich.de@alpo.whistle.com, dennis@etinc.com, Chuck Cranor , Jason Thorpe Subject: Re: VC support, *BSD and atm/frame/isdn Reply-To: grefen@carpe.net In-reply-to: "Ron G. Minnich"'s message of Mon, 23 Sep 96 13:41:10 EDT. References: Date: Tue, 24 Sep 1996 02:54:36 +0200 Message-ID: <5899.843526476@hex.grefen.carpe.net> From: Stefan Grefen Sender: owner-atm@freebsd.org X-Loop: FreeBSD.org Precedence: bulk In message "Ron G. Minnich" wrote: > > I still like IF per VC. Thus I am hoping to see IF per VC added to chuck's > code or to the system itself in some way. Jason Thorpe of netbsd has some > good ideas in this area. I have looked at chuck's code quite a bit and feel > that it is not incompatible with IF per VC. Is this code availble somewhere ? looks like everybody besides me knows Chucks code too :-)) > > ron Stefan -- 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. From owner-freebsd-atm Mon Sep 23 18:57:54 1996 Return-Path: owner-atm Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id SAA26633 for atm-outgoing; Mon, 23 Sep 1996 18:57:54 -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 SAA26586 for ; Mon, 23 Sep 1996 18:57:46 -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 SAA08379; Mon, 23 Sep 1996 18:55:04 -0700 (PDT) Message-ID: <32473F13.5E652F78@whistle.com> Date: Mon, 23 Sep 1996 18:53:24 -0700 From: Julian Elischer Organization: Whistle Communications X-Mailer: Mozilla 3.0b6 (X11; I; FreeBSD 2.2-CURRENT i386) MIME-Version: 1.0 To: grefen@carpe.net CC: "Ron G. Minnich" , atm@freebsd.org, hm@kts.org, drochner%zelux6.zel.archer@cmr.kiev.ua, kfa-juelich.de@alpo.whistle.com, dennis@etinc.com, Chuck Cranor , Jason Thorpe Subject: Re: VC support, *BSD and atm/frame/isdn References: <5899.843526476@hex.grefen.carpe.net> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-atm@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Stefan Grefen wrote: as you are using netbsd, you already have it..... /sys/netatm > > In message "Ron G. Minnich" wrote: > > > > I still like IF per VC. Thus I am hoping to see IF per VC added to chuck's > > code or to the system itself in some way. Jason Thorpe of netbsd has some > > good ideas in this area. I have looked at chuck's code quite a bit and feel > > that it is not incompatible with IF per VC. > > Is this code availble somewhere ? looks like everybody besides me knows > Chucks code too :-)) > > > > > ron > > Stefan > > -- > 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. From owner-freebsd-atm Mon Sep 23 19:41:57 1996 Return-Path: owner-atm Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id TAA13944 for atm-outgoing; Mon, 23 Sep 1996 19:41:57 -0700 (PDT) Received: from maria.wustl.edu (maria.wustl.edu [128.252.169.16]) by freefall.freebsd.org (8.7.5/8.7.3) with SMTP id TAA13924 for ; Mon, 23 Sep 1996 19:41:51 -0700 (PDT) Date: Mon, 23 Sep 96 21:40:02 CDT From: Chuck Cranor To: Julian Elischer cc: grefen@carpe.net, "Ron G. Minnich" , atm@freebsd.org, hm@kts.org, drochner%zelux6.zel.archer@cmr.kiev.ua, kfa-juelich.de@alpo.whistle.com, dennis@etinc.com, Chuck Cranor , Jason Thorpe Subject: Re: VC support, *BSD and atm/frame/isdn Message-ID: <9609232140.aa05643@maria.wustl.edu> Sender: owner-atm@freebsd.org X-Loop: FreeBSD.org Precedence: bulk >as you are using netbsd, you already have it..... >/sys/netatm hi- actually, it didn't make the cut-off date for netbsd-1.2, and netbsd's sup server is currently serving up 1.2release. however, i put it up for ftp at ftp://dworkin.wustl.edu/dist/bsd (includes the work i did to get it running under freebsd 2.2-960612-SNAP). when netbsd's sup returns from 1.2 to -current it will all appear. btw, when i wrote that code i tried to constrain myself to making minimal changes to the rest of the kernel and adding no new user-level programs. (i figured if i did anything too offbeat it would make it harder for the BSD groups to accept it in their source trees...!) the single hardware interface with llinfo/arp stuff fit in very well with my plan, and as an added bonus I was also able to fold in support for plain aal0 and aal5 netnatm sockets (which we need and use for our research) with minimal effort. so that (plus a desire to get something useful "on the table" for people to look at) is what motivated the design of the code. i didn't really think about issues such as "IF per VC" at the time... cheers, chuck