Date: Thu, 29 Aug 1996 16:50:17 -0700 From: Julian Elischer <julian@whistle.com> To: grefen@carpe.net Cc: freebsd-atm@freebsd.org Subject: Re: Virtual Circuit support (fwd) Message-ID: <32262CB9.2781E494@whistle.com> References: <m0utDG3-00001ZC@ernie.kts.org> <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>
next in thread | previous in thread | raw e-mail | index | archive | help
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.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?32262CB9.2781E494>