Any body know networks supported for sysV 3.0

[Guy Harris]

> >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 at sun.com (or guy at sun.arpa)