3-Apr-82 03:54:47-PST,11617;000000000001
Mail-from: ARPANET host BRL rcvd at 3-Apr-82 0353-PST
Sender: Mike Muuss <TCP-IP@Brl>
From: TCP-IP at Brl
To: TCP-IP at Brl
Date: 3 Apr 1982
Subject: TCP-IP Digest, Vol 1 #18
Via: Brl; 3 Apr 82 1:51-EST
TCP/IP Digest Saturday, 3 Apr 1982 Volume 1 : Issue 18
Today's Topics:
Implementation of TCP/IP for UNIX?
VDH Code for UNIX TCP/IP?
Info on 3 UNIX TCP/IP Implementations
TCP/IP for VAX/VMS Report ("ACCESS-T")
Xerox Internet Transport Protocol Specifications availible
1-Apr ComputerWhirled Extra
----------------------------------------------------------------------
LIMITED DISTRIBUTION
For Research Use Only --- Not for Public Distribution
----------------------------------------------------------------------
Subject: TCP/IP for Unix v7
From: BNL at BBNC
To: TCP-IP at BRL
Two independent requests:
1) Does anyone have a public domain implementation of TCP/IP for
Unix v7? (Don't laugh, conventional wisdom to the contrary I have
not been able to locate one!)
2) Does there exist VDH code for the above, or that is adaptable to it?
Graham Campbell
------------------------------
From: Nathaniel Mishkin <Mishkin at YALE>
Subject: VDH (Gasp!)
To: Tcp-Ip at BRL
I have just finished perusing the archive of the TCP-IP list and have
not gotten any clues about whether anyone has or will have a UNIX
IP/TCP implementation that runs VDH. Yale is connected VDH to the
IMP at Harvard so we are very interested in the status of any VDH
work.
Does anyone have any information on the subject?
------------------------------
From: Mike Muuss <Mike@BRL>
To: Dreifus at Wharton-10, Tcp-IP at Brl
Subject: Re: PDP11/45 UNIX IP/TCP
I know of three TCP/IP implementations for UNIX, all of which could
potentially fit on an 11/45:
1) BBN all-user-mode TCP/IP. Requires many BBN kernel hacks for
asynchronous I/O, etc. Best price: free. Seems to be fairly slow.
Also reputed to be somewhat buggy. Not used by BBN for some time.
2) 3Com's UNET package. Kernel mode IP, user mode TCP. Supposed to
"drop in" to V7 kernels. Price $5K, performance believed to be very
good, in excess of 200Kbits/sec user-user throughput in early
benchmarks. May not track ArpaNet version of protocols though.
3) MIT LCS ringnet project. Kernel IP, user TCP. Status and
availibility uncertain. Progressing fast, but just now
getting TCP running at all. Speed at least 50Kbits/sec user-user,
full potential rather better than that, but not measured yet.
For your information the NAVY and SRI are (jointly) taking path #1,
BRL is taking paths #2 and #3 simultaneously, and other parts of
the ARMY are taking path #2. I will report on BRL's results with
the 3Com and MIT software as soon as we have anything to say.
Best,
-Mike
------------------------------
From: grg at DTI (Gary Grossman)
To: tcp-ip@brl
Subject: TCP/IP for VAX/VMS
Mike,
Here, at last, is the information you requested about
our TCP/IP-based "ACCESS-T" product:
DTI VAX/VMS
Date: 12 Mar 1982
From: John Schur <schur at dti-vms>
This TCP implementation is written in C for the VMS operating
system. It uses ACP's for the TCP and IP processes, and supports
user level interfaces to these ACP's.
The implementation fully conforms to the TCP and IP specifications
(RFC 791, 793) and ICMP (RFC 792). Higher level protocol
services include user and server TELNET, FTP, and SMTP.
1. Hardware - VAX 11/780 or 11/750 running VMS 2.2 or later,
and ACC LH/DH-11 interface (other devices will be
supported in future according to user interest).
2. Software - written in mostly C and some MACRO. Supports a
user-definable number of connections.
3. Status - TCP/IP ACP's are currently in testing stages,
with field test sites to begin use in April.
4. Protocol Features Supported:
IP:
Fragmentation/Reassembly: reassembly is supported,
but fragmentation is not implemented.
Options: all options are generated and interpreted.
Reassembly timeout: fixed value. Oldest fragments
are discarded first when buffers fill up.
TCP:
Options: All defined options are implemented.
Urgent, Push: Supported as per specifications.
Retransmission: Timeouts employ exponential backoff
until a limit is reached, at which time user is
notified.
Window strategy: Window size is larger than the actual
available buffer space by the maximum size of an
internal buffer.
Please contact DTI for further information.
------------------------------
From: Taft at PARC-MAXC
Subject: Re: Xerox protocol query
To: Roy Marantz <MARANTZ at RUTGERS>
cc: tcp-ip at BRL
Copies of the Xerox Internet Transport Protocols specification may be obtained
from:
Xerox Corporation
Office Products Division
Network Systems Administration Office
3333 Coyote Hill Road
Palo Alto, California 94304
Attention: Stan Suk (Arpanet mail address: Suk@PARC-MAXC)
------------------------------
Subject: Xerox NS protocol documents
To: TCP-IP at BRL
From: (Larry) Kluger at PARC-MAXC
The address for requesting copies of the Xerox NS protocol documents is:
Xerox Corporation
Office Products Division
Network Systems Administrative Office
3333 Coyote Hill Road
Palo Alto, CA 94304
Two protocol documents have been released so far. Request copies of:
"Internet Transport Protocols", doc. # XSIS028112 and
"Courier: The Remote Procedure Call Protocol", doc. # XSIS038112
Larry
------------------------------
From: RENTSCH at USC-ECL
Subject: Re: Xerox Network Protocols
To: Marantz at RUTGERS
cc: TCP-IP at BRL
Xerox Network Systems protocols can be obtained by writing to:
Xerox Corporation
Office Products Division
Network Systems Administration Office
3333 Coyote Hill Road
Palo Alto, California 94304
I have two such protocol manuals. They are:
1) Internet Transport Protocols XSIS 028112
2) Courier: The Remote Procedure Call Protocol XSIS 038112
Both of which are dated December, 1981. (Probably hence the xx8112 in the
title, which suggests there is an XSIS 018112, but I don't know.) In any
case, there probably are other publications on the protocols, get the info
from the Network Systems Administration Office.
For more details, Bob Printis at the Palo Alto facility ( (415) 494-4000 )
is involved in the actual implementation. DO NOT call him just to request
information, but if you have a detailed technical question . . .
Tim Rentsch
------------------------------
FROM: s.r.kleiman
TO: ucbvax!tcp-ip@Berkeley
SUBJECT: Service Specifications
Via: Ucb-C70; 1 Apr 82 2:09-EDT
I am a member of the IEEE project 802 High Level Interface
subcommittee (HILI). One of our concerns is a specification
of the service provided by the link layer to the network
layer. Our model of interface interaction is based on
primitives. These are discrete, instantaneous interface
events which convey the information required in order to
provide a particular service. This is the same as the model
that ISO uses in their service specifications. However, we
differ from ISO in several important ways, and I would like
to solicit comments from the newsgroup about them.
The ISO (ISO/TC 97/SC 16 N697) transport service
specification uses the "four arrow model" of service
primitive interaction. For example, the user layer passes a
"CONNECT.request" primitive to the serving layer to request
that a connection be set up. The serving layer then passes
an "CONNECT.indication" primitive to the remote user layer
to indicate the connection attempt. The remote user layer
evaluates this and then passes a "CONNECT.response"
primitive to the serving layer to accept or deny the
connection. The serving then passes a "CONNECT.confirm"
primitive to the original user layer to convey the results
of the connection attempt.
local | serving | remote
user layer | layer | user layer
| |
--------->| |
request | |
| |------------>
| | indication
| |
| |<------------
| | response
<---------| |
confirm | |
| |
The HILI committee uses a "three arrow model". For example,
the "CONNECT.request" and "CONNECT.indication" are the same
as above. However, after the "CONNECT.indication" is passed
to the remote user layer, the serving layer passes a
"CONNECT.response" to the original user layer. Thus the
purpose of the response primitive is convey to the original
user layer whether or not an indication primitive was sent
to its peer. (The name "response" is unfortunate since it
conflicts with the ISO primitive, but we couldn't think of a
better one)
local | serving | remote
user layer | layer | user layer
| |
--------->| |
request | |
| |------------>
| | indication
<---------| |
response | |
| |
The HILI committee feels that the three arrow model is more
appropriate because:
1. It makes the layers more independent, because the
serving layer does not have to depend on or wait for
the remote user layer to respond to an indication
primitive.
2. The "four arrow model" interaction is actually a user
layer protocol and should not be the business of the
serving layer. In the example the acceptance or
rejection of a peer connection is a user layer
protocol. If the remote peer wishes to reject the
connection it should do so with a user layer PDU
and/or disconnect the serving layer connection. The
purpose of the serving layer should be to set up a
communication pipe between the "bottoms" of the two
user layers. It should not say whether the user of
the pipe accepted the data or not.
If people want to discuss this on the net thats fine,
otherwise sent comments to me:
Steven Kleiman
Bell Labs
Neptune, N.J. 07753
(201) 922-7276
npois!srk
ihnss!npois!srk@berkeley (from Arpanet)
------------------------------
From: Zellich at OFFICE-3 (Rich Zellich)
Subject: APRIL FIRST Bulletin from INFOCOM '82 in Las Vegas
To: TCP-IP at BRL
Value: Humor
The following news bulletin appeared in stacks all over the INFOCOM '82
coffee break and registration areas this week:
COMPUTERWHIRLED EXTRA
IBM ADOPTS TCP
"Tired of Trying to Physicalize Virtual Resources"
4/1/82. Old Teddybear, N.Y. (AFP) In an unprecedented bout of
corporate clarity, SNA was publicly renounced by the entire
IBM Board of Directors, clad in off-blue sackcloth. "What a gas,"
said a spokesman for the Ethernet Consortium, while a DECNET
representative was still looking for a few extra cards. DOD
spokesmen declined immediate comment, indicating that they wanted
time to reassess their position in light of IBM's new posture.
END OF TCP-IP DIGEST
********************
