NEUMANN@AWIWUW11.BITNET (Gustaf Neumann) (02/17/89)
While we are rolling our netbios packet driver starting from Russ Nelson's work we ran into the following problem: Addressing is done in netbios via arbitrary symbolic names. For the time being we use the string 'TCPIP' followed by the binary ip address. Thus it is not necessary to use arps to send packets directly to a specific ip destination. When packets are sent over a gateway the netbios name should contain the gateway's ip address. This addressing scheme works fine with ka9q and Kelly MacDonalds direct (non packet driver) netbios interface, because the gateway's ip address is still visible at the driver level. The packet driver interface from ka9q knows essentially two types of address resolutions: ethernet style (arp) and none at all. Our present version of the netbios packet driver is similar to slip (no arp); we just pull out the ip destination address from the packet passed to driver to construct the netbios name of the destination. This works fine without gateways. Obviously, with a slip style link address (none at all) the assumption is that every node can be reached without further addressing. The problem is that this scheme breaks when using gateways. The packet driver has no way address the gateway; the ip address we can pull out of the packet is the ip address of the final destination, not the address of the gateway. It seems that we are left with arp-style resolution, which is not really needed to determine the link address of the next node. The only reason to use arps is to force the ip layer to provide the route information. We would introduce a pseudo link level address (like the 6-byte ethernet address) which contains only the ip address. For send (and receive) operations we will have to strip (or provide) the equivalent of a ethernet header including type field. When the ip layer sends an arp we would immediately return an arp reply just containing the ip address in the link address field. During send we then can pull out the gateway ip address out of the 'destination link address' and use it to construct the netbios name of the destination or gateway. Thus the netbios interface would look like an ethernet driver with arp and such. We hope to keep existing application happy by sticking to a standard ethernet header layout. We are absolutely not amused about these weird contortions. Does anybody have a simpler solution? Eagerly awaiting your opinions Michael A. Haberler <mah@hpuviea.uucp> Gustaf Neumann <neumann@awiwuw11.bitnet>
jqj@oregon.uoregon.edu (02/20/89)
In article <8902160615.aa20239@louie.udel.edu>, NEUMANN@AWIWUW11.BITNET (Gustaf Neumann) writes: > While we are rolling our netbios packet driver starting from Russ > Nelson's work we ran into the following problem: > > Addressing is done in netbios via arbitrary symbolic names. For the > time being we use the string 'TCPIP' followed by the binary ip > address. Thus it is not necessary to use arps to send packets > directly to a specific ip destination. In general, ARP is *not* the only possible way to do address resolution on a packet-oriented multiple-access network. It isn't even the only way it's done for IP: the ARPAnet, X.25-based IP networks, IP-on-Appletalk, etc., all use their own techniques for doing IP-to-physical address mapping. A generic IP implementation needs different mapping modules for different types of physical network. The packet driver spec allows one to ignore differences between Ethernet interfaces, and in general to encapsulate in the driver differences between interfaces, but only interfaces to networks that are a lot like Ethernet. Asking it to encapsulate IP-on-Netbios is asking too much. I think you really need to have an IP implementation that is structured something like: generic IP module broadcast packet net | p-t-p net | NETBIOS net | X.25 | ... module | module | module | module | Packet | 3C501 | ... driver | | Note that the packet driver spec also can't do a very good job of supporting networks with wildly different packet sizes from Ethernet/802.3, wildly different notions of broadcast (even supporting Ethernet multicast is strained), wildly different notions of connectivity (does it support token ring source routing?), wildly different notions of reliablility/throughput (how would you support IP over multiple parallel X.25 virtual circuits?), or wildly different ways to multiplex different protocols on the same network. The packet driver is a very well designed spec for solving a very real problem -- too many incompatible interfaces to Ethernet cards. It can be extended to interfaces to packet-switched networks that are a lot like Ethernets, like 802.3. I don't think you should try to use it to hide differences between *all* interface cards, though.