mitchell@LOCUS.UCLA.EDU (07/25/86)
HELLO: Granted, all of the STREAMS, RFS support and all, but, is ATT delivering any Transport-layer network support (i.e. ethernet, starlan, token-ring, etc...) in the 3.0 release of sysV? I gather no! I'm used to 4.2bsd and they, at least, deliver an ethernet driver and all of the stuff you need to talk to other machines providing that you have the supported hardware (3com, interlan, exelan). From what I can obtain, I get that they are delivering sysV 3.0 with lots of networking support, but nothng below and including the transport layer. So, I get 3.0 and I can't talk to anything else until I write or buy my own transport support and the corrisponding hardware??? Please correct me if I'm wrong and tell me which networks are supported or, if I'm right, tell me what transport I can buy. Of particular interest is STARLAN, ethernet and any other net support for the pc AT running INTERATIVES port of 3.0. any info on hardware would be appreciated. Thanx P.S. does anyone know what STARLAN is??? -> what will RFS be like running on a STARLAN? Our goal is to setup a sysV testbed on ATs via some lan. please respond to --> Cadovax!mitchell@ucla-locus.arpa
jrw@hropus.UUCP (Jim Webb) (07/26/86)
> Granted, all of the STREAMS, RFS support and all, but, is ATT delivering any > Transport-layer network support (i.e. ethernet, starlan, token-ring, etc...) > in the 3.0 release of sysV? I gather no! I am 99 44/100 percent sure that the 3B2 SVR3 will support ethernet in the form of 3bnet. If AT&T drops this, no one around here will buy SVR3. > I'm used to 4.2bsd and they, at least, deliver an ethernet driver and > all of the stuff you need to talk to other machines providing that you > have the supported hardware (3com, interlan, exelan). ^^^^^^^^ AT&T supports interlan boards under SVR2 for vaxen ethernet. The software emulates 3bnet, so one can easily interconnect 3b2s, 3b5s, and 3b20s to vaxen. I don't know if there are plans to port this package to SVR3, but it is a source package if one is a hacker/porter. AT&T has be quite, how should I say, inconsistent, in its support of X25, but hopefully it will be included as yet another add-on package in some form or another. -- Jim Webb "Out of phase--get help" ihnp4!houxm!hropus!jrw "Research shows that disco music causes homosexuality in white mice" -- TIME
csg@pyramid.UUCP (Carl S. Gutekunst) (07/29/86)
>> Granted, all of the STREAMS, RFS support and all, but, is ATT delivering any >> Transport-layer network support (i.e. ethernet, starlan, token-ring, etc...) >> in the 3.0 release of sysV? I gather no! > >I am 99 44/100 percent sure that the 3B2 SVR3 will support ethernet in the >form of 3bnet. Then you are 99 44/100 percent wrong. :-) AT&T has been quite clear that the only physical network they will support (initially) in SVR3 is Starlan. No Ethernet, and no TCP/IP. As you can well imagine, this created quite a stew at the SVR3 product seminar. 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. Down the road, AT&T may buy some of the modules, or develop their own. AT&T has stated that an as-yet-unnamed ISV will announce the availability of TCP/IP protocol modules Real Soon Now. 3bnet is going away completely as of SVR3, last I heard. <csg>
ssl@ptsfa.UUCP (Sam Lok) (07/29/86)
In article <540@pyramid.UUCP> csg@pyramid.UUCP (Carl S. Gutekunst) writes: > >AT&T has been quite clear that the only physical network they will support >(initially) in SVR3 is Starlan. No Ethernet, and no TCP/IP. As you can well >imagine, this created quite a stew at the SVR3 product seminar. 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. Down the road, AT&T >may buy some of the modules, or develop their own. > >AT&T has stated that an as-yet-unnamed ISV will announce the availability of >TCP/IP protocol modules Real Soon Now. > >3bnet is going away completely as of SVR3, last I heard. > That's right, only Starlan is supported. As for Ethernet, the Bell Lab folks would not comment on it couple weeks ago when I met with them. 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 The AT&T Enhanced TCP/IP WIN/3B Interface is a full featured suite of applications protocols for users requiring high-level networking services such as mail, remote login, and file transfer between AT&T computers and other minicomputers that support the TCP?IP protocols. Lower Level Protocols: TCP/IP WIN/3B has been ported to AT&T 3B computers on top of the X.25 and Ethernet lower level protocols. . .. The Enhanced TCP/IP WIN/3B Interface will support both a Berkeley Sockets and an AT&T Transport Level Interface. ... " But as for any vendors, wait till you see it to believe it! -- =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= Sam Lok {ihnp4,dual,qantel}!ptsfa!ssl
bzs@BU-CS.BU.EDU (Barry Shein) (07/30/86)
>AT&T has been quite clear that the only physical network they will support >(initially) in SVR3 is Starlan. No Ethernet, and no TCP/IP. Whoa... Does that mean that if I upgrade my 3Bs (which currently have ethernet, well, all but the 3B5 [20 months and waiting ATT!]) I have to yank out the ethernet boards? Say it ain't so... -Barry Shein, Boston University
guy@sun.uucp (Guy Harris) (07/30/86)
> >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)
gwyn@brl-smoke.ARPA (Doug Gwyn ) (07/31/86)
In article <5666@sun.uucp> guy@sun.uucp (Guy Harris) writes:
-- "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).
What puzzles me is why Dennis Ritchie's streams-based TCP/IP
implementation doesn't seem to be becoming an AT&T product.bzs@bu-cs.bu.EDU (Barry Shein) (08/01/86)
From Doug Gwyn >What puzzles me is why Dennis Ritchie's streams-based TCP/IP >implementation doesn't seem to be becoming an AT&T product. Just some speculations: I am fairly certain the TCP/IP for 3Bs mentioned on this list is the one developed by The Wollongong Group (purveyors of VMS/EUNICE.) I further suspect that the reason they (ATT) got involved in TCP/IP at all was in response to the large NSA (et al) contracts they were awarded, before that became an issue ATT seemed fairly determined to go their own way (eg. 3Bnet.) I would therefore assume that they needed to latch onto a quick vendor, DEC had gone with TWG/TCP (for VMS) as had a few other vendors (notably, in this discussion, Amdahl for UTS which ATT re-markets.) So, probably just an early direction that has become entrenched, for better or for worse (I honestly don't know, I fooled around with the TWG/SYSV/3B/WIN/TCP/IP at USENIX also and it appeared to work.) -Barry Shein, Boston University