Date: Wed, 16 Jun 1999 12:19:56 +0700 (ALMST) From: Boris Popov <bp@butya.kz> To: "Justin C. Walker" <justin@apple.com> Cc: freebsd-net@FreeBSD.ORG Subject: Re: Multiple ethernet frames for IPX Message-ID: <Pine.BSF.4.10.9906161134030.13554-100000@lion.butya.kz> In-Reply-To: <199906160351.UAA00707@walker3.apple.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Tue, 15 Jun 1999, Justin C. Walker wrote: > Thanks for the response; I have a few more questions: > > > > How does this handle the problem of getting a forwarded packet back > > > into the wrapper it needs (e.g., 802.3/SNAP)? > > > > Packet sended/forwarded to interface. Since frame type > > determined from the interface it is not a problem for ether_output() > > rotine to select appropriate frame to wrap in. > I should be clearer. What I meant to ask is: given that you have > a packet in the routing layer to forward, and that its incoming > framing has been stripped, how does the routing layer decide what > framing (E-II, 802.3/SNAP, ..) to use when sending it? In case of IPX protocol you have network numbers as a routing and forwarding criteria, and since one frame have only one corresponding network number it is easy to select outgoing interface. If host have no direct connection to destination network it will use routing entries gathered from RIP packets. So, it doesn't matter which frame type was on incoming packet. As a special case consider routing between different frame types on a single ethernet segment. > > > > Why is this better than, e.g., having stacks register for > > > packet-type reception? I'd think this would perform better than > the > > > "virtual device" scheme. A (minor?) drawback is updating both > stack > > > and "driver family support" (e.g., ether_input()) to handle this. > > > > No, you will also need to rewrite route* procedures. And changes > > required to protocol stack(s) aren't "minor" in this case. > I don't understand this. If the route* procedures need rewriting > in this case, why not in the "virtual device" case? Because route includes destination interface and only virtual interface knows about frames. > Also, I don't see why the stack changes are a big deal. For each > configured interface, the stack has to "register", which can be > handled in the same "piece" of the stack that deals, e.g., with ARP > and addressing issues. May be this will be reasonable when you'll redesign stack/interface framework to include frames support. But as follows from README file I have tried to keep minimal changes to kernel files. -- Boris Popov http://www.butya.kz/~bp/ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.BSF.4.10.9906161134030.13554-100000>