Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Path: utzoo!mnetor!seismo!ut-sally!pyramid!decwrl!sun!guy From: guy@sun.uucp (Guy Harris) Newsgroups: net.unix-wizards Subject: Re: Any body know networks supported for sysV 3.0 Message-ID: <5666@sun.uucp> Date: Wed, 30-Jul-86 16:33:55 EDT Article-I.D.: sun.5666 Posted: Wed Jul 30 16:33:55 1986 Date-Received: Thu, 31-Jul-86 21:43:04 EDT References: <2544@brl-smoke.ARPA> <587@hropus.UUCP> <540@pyramid.UUCP> <1488@ptsfa.UUCP> Organization: Sun Microsystems, Inc. Lines: 67 > >AT&T has been quite clear that the only physical network they will support > >(initially) in SVR3 is Starlan. No Ethernet, Considering they supply Ethernet interfaces for at least some of the 3Bs, this seems rather dumb. Presumably, if they supply an Ethernet interface that compiles with whatever specification they have for a "network interface to next protocol layer up" interface, any protocol that complies with that interface will be able to use it. The equivalent interface in the 4.2 networking software is pretty simple; there's an "if_output" routine to put packets, and a macro that the interface driver can use to deal with the input queue of the next protocol layer up. The protocol imposed by the streams interface is mostly sufficient for this purpose. One tricky part here is that the protocol-to- network-interface interface passes a message *and* a destination address that is part of the address family of the protocol *above* the link-level protocol; probably you'd have to have an additional convention that the first block of such a message contains the destination address, and that the interface does NOT transmit that block, but uses it to send the packet out. The Ethernet driver would have to remove that block from the message, figure out what address family it belongs to, translate it to an Ethernet address for that host (using ARP, or whatever; note that it must deal with translating higher-level broadcast addresses into Ethernet broadcast addresses), put that translated address into the "destination address" portion of the Ethernet header, put its own interface address into the source address portion of the Ethernet header, and put the appropriate packet type into the "packet type" portion of the Ethernet header, based on the address family of the destination address. It then would have to stick the Ethernet header onto the front of the message and ship it out. Incoming packets will have to have the Ethernet header stripped off before being handed to the next module up the line. I don't know if AT&T has chosen some such interface and made an Ethernet driver that conforms to it; if not, this may explain why they aren't providing an Ethernet interface, since without some convention like that the Ethernet interface is practically useless. > >AT&T is expecting a "cottage" industry to arise to develop and market > >Streams-based protocol modules: TCP/IP, Token Ring, and what have you. I hope they don't expect this cottage industry to develop an Ethernet driver for their own machines; that strikes me as their responsibility. If they can't come up with a protocol-to-network-interface module, I think the growth of this cottage industry is going to be severly stunted. > TCP/IP? It's not part of SVR3, but read the following article, > it's extracted from AT&T Computer Newbits dated July 4, 1986: > > "AT&T Enhanced TCP/IP/WIN/3B At the last UniForum, they showed off a TCP/IP implementation for the 3B under S5R2.x Version y, for some valsue of "x" and "y". It resembled the version you describe; it had "rlogin", "rsh", "rwho" and other Berkeley protocols as well as the usual DOD protocols (FTP, TELNET, SMTP). They did provide an interface that's compatible with sockets (to some unspecified degree). This wasn't on top of streams, obviously. Is this new version a version for S5R3 that runs on top of streams? If so, they've either provided a protocol- to-network-interface interface or have taught the IP layer about Ethernet and X.25 headers (ecch). -- Guy Harris {ihnp4, decvax, seismo, decwrl, ...}!sun!guy guy@sun.com (or guy@sun.arpa)