Date: Fri, 30 Aug 1996 10:43:01 +0200 From: Stefan Grefen <grefen@carpe.net> To: Julian Elischer <julian@whistle.com> Cc: freebsd-atm@freebsd.org Subject: Re: Virtual Circuit support (fwd) Message-ID: <4540.841394581@hex.grefen.carpe.net> In-Reply-To: Julian Elischer's message <32262CB9.2781E494@whistle.com> of Thu, 29 Aug 96 16:50:17 PDT. 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> <32262CB9.2781E494@whistle.com>
next in thread | previous in thread | raw e-mail | index | archive | help
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.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?4540.841394581>