RWA100S@ODUVM.BITNET (Bob Alston) (04/23/88)
We at ODU Computing Services are looking for a hardware topologically
independent tcp/ip solution for our Novell Networks. We have an
ethernet based TCP/IP backbone that we would like to be able to take
advantage of from several existing and proposed Novell pc networks using
IBM Token Ring, 3COM 501 Ethernet, SMS Arcnet, and other asstd. hardware
topologies. I have seen the Micom-Interlan (Netware) TCP/IP gateway, but
have concerns about its performance. Also, I have seen several workstation
based solutions (ie Excelan, Ungermann-Bass, etc.), but we already have a
substantial hardware investment in other pc network interface cards
(token ring, ethernet, etc. as mentioned above) and also have heard that
the aformentioned workstation based solutions are prohibitively expensive.
I have heard rumors of a netbios based solution and I would be very interested
in learning more. Please send me any and all info you can share. I will
be glad to post the responses to the lists.
Thanks in Advance
Bob Alston
Old Dominion University
Norfolk, VA
BITNET: RWA100S@ODUVMjbvb@VAX.FTP.COM (James Van Bokkelen) (04/23/88)
None of them use NETBIOS to encapsulate IP datagrams, but there are several Novell-compatible, hardware- (but not media-) independent versions of TCP/IP for the IBM PC that are either commercially supported, or widely available in the public domain. Our product for the IBM 802.5 Token Ring calls the IBM-supplied software driver (the ASI interface), and can share it with other programs (Banyan Vines, Novell Netware). IBM's PC product might be able to manage the same trick, but I don't know of anyone who has tried it. A number of Novell's OEMs have modified their versions of Netware so that they support our Packet Driver spec. This allows our Generic Ethernet version to share the interface with Netware. (Or you can ask Karl Auerbach for the CMU version he posted about on pc-ip a week or two ago. It also uses the spec.) Regrettably, none of the versions of Netware that support the Packet Driver spec run on the 3C501, but there may be a workaround: The 3C501 is so simple (I'm being nice) that it is possible for two pieces of software using it to co-exist: You can run a TCP/IP package that is careful about restoring the interrupt vector, as long as you don't try to use the LAN program while the TCP/IP has the card. I know this works with our PC/TCP or the CMU freeware and 3Com's 3+, it would be worth trying with Netware. For Arcnet, you could try Philip Prindeville's version of the CMU code, which has also been mentioned on pc-ip. I don't know if you could manage the "co-existence" trick with Netware, or not. Of course, this approach requires IP routers to forward normal IP packets back and forth across the various networks. Keep in mind that encapsulating IP in NETBIOS datagrams requires at least one IP router, too. Somebody has to get the packets onto and off of your normal-IP backbone (?) Ethernet, and the NETBIOS-space, however it is mapped to the various LANs, is at least one subnet on its own. If you aren't totally committed to Netware, you might try looking up Banyan and asking them how they'd solve your problem. James VanBokkelen FTP Software Inc.
john@twg-ap.UUCP (John Caughy) (04/28/88)
In regard to the query of a topologically independent
TCP/IP solution for Netbios networks, several solutions are
available. Along with several different public domain
implementations, Wollongong supports a Netbios interface for
TCP/IP. When used in conjunction with a PC gateway, also
available from Wollongong, PC LAN users can access Ethernet
networks and their accompanying services utilizing TCP/IP
protocols.
The Netbios interface utilizes Netbios datagram service
to transport TCP/IP packets over PC LANs. The gateway
routes packets to Ethernet based TCP/IP backbones. The
Netbios interface has been developed using the Novell
Netbios and therefore should support any hardware interface
also supported by Novell's Netware.
The gateway requires a dedicated PC/AT to operate and
supports up to three interfaces. The gateway supports a
variety of Ethernet controllers as well token ring
controllers and the Netbios Interface. Routes are
established statically. Fragmentation and reassembly are
also supported.
Another possible solution would be to provide an
interface to Novell's IPX layer. This solution would
provide much better performance than the Netbios interface
and maintain the hardware independence, however you would
then be making a commitment to the use of the Novell
product. I am unaware of any existing PC-IP interfaces to
IPX, but its in the works here at Wollongong.RHX@CORNELLC.CCS.CORNELL.EDU (Dick Cogger) (04/29/88)
Re: TWG Netbios encaps of IP...
Is there (or could there be) a spec on how this is done. We have done
the same thing at Cornell, and Kelly MacDonald has done it for the
KA9Q package. Presumably all three perform the same function but are
different in every detail and won't interoperate. I'll volunteer to
have ours change to something else if we can all agree on a standard.
Items that seem to need considering:
1. What exactly do you register as a name? Presumably your
IP address-- At Cornell, we used the ascii dot-notation
string, and I believe Kelly used the four-byte binary.
2. Lets have a way to find the gateway. Perhaps findname
for IPGateway, as is used with NBP on Appletalk.
3. Lets have a way to get an IP address dynamically if not
hard-configured by the workstation user. I can think of
two approaches: 1) Using info from the gateway to determine
net portion of an IP address, subnet mask and subnet portion,
take a guess for a node portion; addname for the resulting
IP addr and see if anyone complains. If someone does
try another guess. To get info from the gateway, you would
have to temporarily register some random name. 2) Have
the GW assign one from a pool. The later is the method
currently used by the KIP code for Appletalk. (The former
used to be the method.)
Comments?
-Dick Cogger (RHX@cornellc.ccs.cornell.edu)karl@trwind.ind.trw.COM (Karl Auerbach) (04/30/88)
If you try to put IP packets into netbios datagrams watch out for those implementations that do a name discovery for each netbios datagram sent. (Some adaptors did little, if any, caching of prior name discover results.) This is not a problem if you send the IP packets on netbios sessions, except you can have a @!~+* lot of sessions open. --karl--
john@twg-ap.UUCP (John Caughy) (05/05/88)
By all means a spec for Netbios interfaces would be most welcome. The spec should describe a Netbios interface which utilizes Netbios datagram service as opposed to Netbios sessions. I feel that areas which need the most attention are Netbios name conventions and encapsulation. With regard to Netbios name conventions we use the ascii dot notation of the IP address with a prefix of "WIP". This probably guarantees we won't interoperate with anyone but this is easily changed. I think the Netbios name should imply the protocols used as well as the address. Such a naming scheme would permit the multiplexing among various protocol stacks a` la the Ethernet type field. The simple ascii dot notation is perhaps sufficient to identify IP protocols but may later become confused with other addressing schemes which might operate over this interface. This leads to a second important consideration of the spec regarding encapsulation. Wollongong currently directly encapsulates the IP datagram as Netbios data without any other extraneous information, such as a type field. Is there any other data other than the IP datagram which might be useful to encapsulate in the Netbios datagram? My immediate answer is a probably not. I would like to see the interface kept as simple as possible. In regard to your other suggestions, 2. and 3., I don't feel that these are appropriate functions for the interface per se. The IETF is currently defining additional ICMP messages one of which is called the "Gateway Delivery Request/Reply" which is similar to the "Address Mask Request/Reply" message.