From owner-freebsd-atm Tue Aug 27 11:55:22 1996 Return-Path: owner-atm Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id LAA20796 for atm-outgoing; Tue, 27 Aug 1996 11:55:22 -0700 (PDT) Received: from plains.nodak.edu (tinguely@plains.NoDak.edu [134.129.111.64]) by freefall.freebsd.org (8.7.5/8.7.3) with ESMTP id LAA20791 for ; Tue, 27 Aug 1996 11:55:19 -0700 (PDT) Received: (from tinguely@localhost) by plains.nodak.edu (8.7.5/8.7.3) id NAA29994; Tue, 27 Aug 1996 13:54:55 -0500 (CDT) Date: Tue, 27 Aug 1996 13:54:55 -0500 (CDT) From: Mark Tinguely Message-Id: <199608271854.NAA29994@plains.nodak.edu> To: brian@MediaCity.com, freebsd-atm@freebsd.org Subject: Re: NicStar 25mbit or 155mbit? Sender: owner-atm@freebsd.org X-Loop: FreeBSD.org Precedence: bulk I am using the 155 Mb cards. The current shipping cards is revision D and it has a very serious bug. CBR and the highest priority VBR queue cannot work together. This means we will have troubles implementing CBR, VBR, ABR and UBR at the same time. I would wait until revision E fixes this to buy too many cards. as a fix around this, I was thinking of putting VBR and ABR in the second highest priority queue for now. I have the card probing and initialized, I get clock overflow interrupts every 3 minutes. My next step is to force a PVC into the tables of two cards to hand send/recieve a PDU. --mark. From owner-freebsd-atm Thu Aug 29 16:53:34 1996 Return-Path: owner-atm Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id QAA16910 for atm-outgoing; Thu, 29 Aug 1996 16:53:34 -0700 (PDT) Received: from whistle.com (s205m131.whistle.com [207.76.205.131]) by freefall.freebsd.org (8.7.5/8.7.3) with ESMTP id QAA16876 for ; Thu, 29 Aug 1996 16:53:11 -0700 (PDT) Received: (from smap@localhost) by whistle.com (8.7.5/8.6.12) id QAA04926; Thu, 29 Aug 1996 16:51:50 -0700 (PDT) Received: from current1.whistle.com(207.76.205.22) by whistle.com via smap (V1.3) id sma004921; Thu Aug 29 16:51:22 1996 Message-ID: <32262CB9.2781E494@whistle.com> Date: Thu, 29 Aug 1996 16:50:17 -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: freebsd-atm@freebsd.org Subject: Re: Virtual Circuit support (fwd) References: <4813.840656512@hex.grefen.carpe.net> <321B962C.59E2B600@whistle.com> <7753.840700743@hex.grefen.carpe.net> <321CEE16.31DFF4F5@whistle.com> <2374.841351869@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 <321CEE16.31DFF4F5@whistle.com> you wrote: > > > Can I have a look at it? > > > > > > [...] > > > > hopefully the attached shar file comes through ok.. > > if_wfra.c is a proprietary frame relay card driver, > > but it interfaces to the vc code and is an example of how to use it.. > > I got it (sorry my day jobs get the nights too at the moment). so do mine.. I didn't get home at all last night.. the vc stuff is shelved for 2 or 3 weeks while we go into beta with teh (freebsd based) product > > It is mostly what I want todo. What bugs me is that it doesn't fit into > the BSD design. Stacking visible interfaces that way, doesn't > 'feel' right. true, but maybe we can put the ones we want to be INvisible on a separate list.. the thing is that the "interface" structure holds all the information we need. the routing structures don't nor do the ifaddr structs.. it turns out that interfaces are now very dynamic.. the only thing I have against using them is that they clutter up the netstat output (or ifconfig). however having them visible does allow them to be reached for 'tacking' modules (ala streams ) onto them. > > My goal is to make an implementation that fits in the architecture. > I looked further around and think if I would merge your code with the > routing table tricks in netcitt, we would get the same functionality without > the stacked interface. well Something has to be stacked.. and why make aup a new structure to do it..? I notice BTW that teh RFC1490 code is really s sub/super set of the LLC code in if_ethersubr.c.. I guess that requires some rationalisation. > I would attach the information for the vc's and the > encapsulation to routing structures (I would use the llinfo pointer). I tried that but how do you stack them? > > You would add routes to SAP's to the routing tables and the information > about the encapsulation and any necessary addressing is embedded in the SAP. yeeessss, I tried to use Llinfo fields and adding extra ifaddrs on the interfaces.. but it became a mess because teh scope fo teh information is all wrong.. the interfaces may need to have many VCs all on differnt logical networks and all possibly using different encapsulation.. while this looks at the start like a use for llinfo fields, in the end it became hellishly complicated.. especially when: a single fram relay link might have 3 links on one network (sharing a single local address and several on totally different addresses. > eg. > route add yy.xx.dd.00 -frame E:some-name > route add -frame some-name -ifp frame0 > > > for isdn > route add -inet yy.xx.dd.00 -isdn R:D.6192920404 > route add -isdn D.6192920404 -ifa D.6131998566 for this, route has to know in advance about every type of encapsulation or whatever.. I would like to have things attached by ascii names if possible :) > > Assuming that E stands for Etherframes and R for Raw. > (The D stand s for isdn data service) > > The parsing of the encapsulation would be hidden in the library. I'd like to have each module do its own parsing.. or we'll spend FOREVER editing route(1) and friends I'm really just skimming this for now.. so that you get an answer I'll think about it more.. p.s. I cc'd it to the atm group.. they're about to need the same stuff too, and I think rfc1490 applies to atm as well. > > > > > > > > > julian > > 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 Fri Aug 30 01:47:14 1996 Return-Path: owner-atm Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id BAA24007 for atm-outgoing; Fri, 30 Aug 1996 01:47:14 -0700 (PDT) Received: from gargoyle.carpe.net (gargoyle-cx.carpe.net [192.35.90.1]) by freefall.freebsd.org (8.7.5/8.7.3) with ESMTP id BAA23989 for ; Fri, 30 Aug 1996 01:47:01 -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 KAA04838; Fri, 30 Aug 1996 10:42:29 +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 KAA04975; Fri, 30 Aug 1996 10:43:05 +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 KAA04543; Fri, 30 Aug 1996 10:43:03 +0200 (MET DST) To: Julian Elischer Cc: freebsd-atm@freebsd.org Subject: Re: Virtual Circuit support (fwd) Reply-To: grefen@carpe.net In-reply-to: Julian Elischer's message <32262CB9.2781E494@whistle.com> of Thu, 29 Aug 96 16:50:17 PDT. References: <4813.840656512@hex.grefen.carpe.net> <321B962C.59E2B600@whistle.com> <7753.840700743@hex.grefen.carpe.net> <321CEE16.31DFF4F5@whistle.com> <2374.841351869@hex.grefen.carpe.net> <32262CB9.2781E494@whistle.com> Date: Fri, 30 Aug 1996 10:43:01 +0200 Message-ID: <4540.841394581@hex.grefen.carpe.net> From: Stefan Grefen Sender: owner-atm@freebsd.org X-Loop: FreeBSD.org Precedence: bulk In message <32262CB9.2781E494@whistle.com> Julian Elischer wrote: > Stefan Grefen wrote: [...] > > > > > It is mostly what I want todo. What bugs me is that it doesn't fit into > > the BSD design. Stacking visible interfaces that way, doesn't > > 'feel' right. > > true, but maybe we can put the ones we want to be INvisible on a > separate list.. the thing is that the "interface" structure holds all > the information we need. > the routing structures don't nor do the ifaddr structs.. Partly true, the routing structs can hold in llinfo anything you want. The problem with interfaces is that the interfaces used for stacking have a different semantic than 'real' ones' (and the stacked ones will be visible) and if you stack multiple modules will you do that with multiple interfaces or with one? If you use only one the vc-interface is just a placeholder that supplies the stacking info. I think we can put that in the routing tables. > > it turns out that interfaces are now very dynamic.. > the only thing I have against using them is that they clutter > up the netstat output (or ifconfig). however having them visible > does allow them to be reached for 'tacking' modules (ala streams ) > onto them. You can add an invisible flag and don't export them via ioctls and sysctl. > > > > > > > > My goal is to make an implementation that fits in the architecture. > > I looked further around and think if I would merge your code with the > > routing table tricks in netcitt, we would get the same functionality withou > t > > the stacked interface. > well Something has to be stacked.. and why make aup a new > structure to do it..? I notice BTW that teh RFC1490 code is really > s sub/super set of the LLC code in if_ethersubr.c.. > I guess that requires some rationalisation. With routing-tables that would be also possible (plus it's using llinfo for arp-info) ... > > > I would attach the information for the vc's and the > > encapsulation to routing structures (I would use the llinfo pointer). > I tried that but how do you stack them? By adding routing dependencies in the thing you attach to llinfo. That can be stacked any level (I've got the idea from netccitt, the implementation there doesn't work for the 'generic' case). By 'explicit' (user supllied) routing or automatic creation of routes for the livetime of a vc. If we introduce generic -sap addresses : Add a stack of Ethernet (ethertype 234) and PPP to route some-name route add -inet 223.45.67.0 -sap E.234/P:some-name Add a for U (unkown encap :-)) point to some Ethertype 567: route add -sap E.567:* U:* and let U:* point to an inet address route add -sap u:* -inet 127.0.0.1 route add -inet 192.234.56.0 -sap u:* -ifp ed0 This would route any incoming Ethertype-567 packet through encap U to inet 127.0.0.2 (assuming U can output IP-packets) route packets to 192.234.56 through encap U to ed0. To add a sap to an interface: route add -sap some-name -ifp frame0 route add -sap E:some-other-name -ifp ed0 Think aout that we can also introduce a generic SAP protocol so you can bind a socket to a generic SAP point in case you din't have a kernel implementation for it. (eg. instead of running appletalk through BPF you would just open a socket bound to the correct ether-type sap). That way we could also get 'raw' frame relay , isdn or atm access. > > > > You would add routes to SAP's to the routing tables and the information > > about the encapsulation and any necessary addressing is embedded in the SAP > . > yeeessss, > I tried to use Llinfo fields and adding extra ifaddrs on the > interfaces.. Why extra ifaddrs ( I would use them to add the different possible incoming phone-numbers)? The llinfo in the last stack has a pointer to the interface and the interface has a pointer to every 'connected' (active) vc. Alll in the structures pointed to by llinfo. > but it became a mess because teh scope fo teh information is all wrong.. > the interfaces may need to have many VCs all on differnt > logical networks and all > possibly using different encapsulation.. > while this looks at the start like a use for llinfo > fields, in the end it became hellishly complicated.. > especially when: > > a single fram relay link might have 3 links on one network (sharing a > single local address and several on totally different addresses. Where is the problem (X25 has the same problem)? Just lookup the source in the routing table to find the matching vc and add that to a cache on the frame-relay interface. (you can have different types of LLINFO here for encapsulation or 'real' interfaces or gateways to other protocols). > > > eg. > > route add yy.xx.dd.00 -frame E:some-name > > route add -frame some-name -ifp frame0 > > > > > > for isdn > > route add -inet yy.xx.dd.00 -isdn R:D.6192920404 > > route add -isdn D.6192920404 -ifa D.6131998566 > > for this, route has to know in advance about every type of > encapsulation or whatever.. I would like to have things attached by > ascii names if possible :) Why? It has to know how to convert a frame or isdn ot atm or .. address to a socketaddr, but that can be strcpy and has to be there anyway... I would just copy the name of the encapsulation character wise and have the vc-library doing a search for such module and cache the result on the llinfo struct. > > > > > > Assuming that E stands for Etherframes and R for Raw. > > (The D stand s for isdn data service) > > > > The parsing of the encapsulation would be hidden in the library. > > I'd like to have each module do its own parsing.. > or we'll spend FOREVER editing route(1) and friends No, because all route does is converting the ascii-address to sockaddr. Dealing with the encapsulation-stuff is for lower layers. A addtional canditate for encapsulation is IP-IP tunneling. > > I'm really just skimming this for now.. > so that you get an answer > I'll think about it more.. The same ... > p.s. I cc'd it to the atm group.. > they're about to need the same stuff too, and I think rfc1490 > applies to atm as well. > I think there is a need for a generic solution. 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.