Date: Wed, 16 Jun 1999 09:02:28 -0700 From: "Justin C. Walker" <justin@apple.com> To: freebsd-net@freebsd.org Subject: Re: Multiple ethernet frames for IPX Message-ID: <199906161602.JAA00643@walker3.apple.com> In-Reply-To: <199906160351.UAA00707@walker3.apple.com>
next in thread | previous in thread | raw e-mail | index | archive | help
Hmmm... > From: Boris Popov <bp@butya.kz> > Date: 1999-06-15 22:20:36 -0700 > To: "Justin C. Walker" <justin@apple.com> > Subject: Re: Multiple ethernet frames for IPX > Cc: freebsd-net@FreeBSD.ORG > In-reply-to: <199906160351.UAA00707@walker3.apple.com> > Delivered-to: freebsd-net@freebsd.org > X-Loop: FreeBSD.org > > 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. I understand how routing works. What I'm missing is how the sending host (whether originator or forwarder) decides how to encapsulate a frame, i.e., in your case, how to chose which virtual device to use. Is it the case that the network number determines the encapsulation? Is ARP used, and if so, does the ARP reply dictate how to encapsulate? I never bothered to figure out the answers to these questions for IP (which can be encapsulated in E-2 or 802.3/SNAP). > > > > > 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. I guess this is an answer to the question: network numbers determine encapsulation. Is that true? Thanks for the clarification. Regards, Justin -- Justin C. Walker, Curmudgeon-At-Large * Institute for General Semantics | Manager, CoreOS Networking | Men are from Earth. Apple Computer, Inc. | Women are from Earth. 2 Infinite Loop | Deal with it. Cupertino, CA 95014 | *-------------------------------------*-------------------------------* 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?199906161602.JAA00643>