----MESSAGE-BEGIN---- <1982040220510000>
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
********************

----MESSAGE-END----
----MESSAGE-BEGIN---- <1982041914430000>
Mail-from: ARPANET host BRL rcvd at 19-Apr-82 2129-PST
Sender:    Mike Muuss <TCP-IP@Brl>
From:      TCP-IP at Brl
To:        TCP-IP at Brl
Date:      19 Apr 1982
Subject:   TCP-IP Digest, Vol 1 #19
Via:  Brl-Bmd; 19 Apr 82 19:43-EST

TCP/IP Digest             Monday, 19 Apr 1982      Volume 1 : Issue 19

Today's Topics:
        InterNet Protocol Transition Workbook Availible from NIC
        TOPS-10 Implementation of TCP/IP Slated by U.S. Air Force
         Misinformation corrected:  3-Com, Navy Plans, SRI Plans
                Further comments on DTI's ACCESS Offering
                   Comments on Service Specifications
                 TCP/IP from Scratch -- Request for Help
----------------------------------------------------------------------
                         LIMITED DISTRIBUTION
          For Research Use Only --- Not for Public Distribution
----------------------------------------------------------------------

From: POSTEL at USC-ISIF
Subject: Internet Protocol Transition Workbook
To:   tcp-ip at BRL

A book containing just about all of the ARPA Internet protocols has
been put together by the Network Information Center.  This book includes
IP, TCP, Telnet, FTP, Mail, UDP, TFTP, and Name Server Protocols.  It
also includes information about host tables, assigned numbers, and other
reference information.  The book can be obtained from the Network Information
Center by sending a message with your name and address to NIC@NIC.

--jon.

------------------------------

From: PROVAN at WPAFB-AFWAL
Subject: tops-10 implementation slated
To:   tcp-ip at BRL

	The air force has allocated me to implement ip/tcp for
tops-10.  I'm hoping to get it up before january 1.  interested
parties should get in touch with me.

------------------------------

Sender: CERF at USC-ISI
Subject: Re:   TCP-IP Digest, Vol 1 #18
From: CERF at USC-ISI
To: TCP-IP at BRL

IT IS MY UNDERSTANDING THAT 3COM INTENDS TO TRACK ANY CHANGES IN
THE DOD STANDARD PROTOCOLS INCLUDING TCP AND IP.

VINT CERF DARPA/IPTO

------------------------------

From:     Mike Muuss <Mike@brl>
To:       Vint <Cerf@usc-isi>
cc:       TCP-IP at Brl
Subject:  3Com tracking DoD Standards

I stand corrected.  That is a welcome message indeed.  Thanks!
				Best,
				 -Mike

------------------------------

From: ron at NOSC-CC (Ronald L. Broersma)
Subject: NAVY no longer attempting plan #1
To: tcp-ip at brl

Mike,

In the recent DIGEST, you said that NAVY and SRI were doing #1 of the
three efforts for TCP/IP on Unix V7.  The NAVY has just decided to
buy 7 VAX 11/750s to replace most of the PDP 11/40s and go with the
Berkeley TCP/IP software (4.2BSD) whenever that is released.

--Ron

------------------------------

From: croft at SRI-TSC
To: tcp-ip at brl, croft at SRI-TSC
Subject: Re:   TCP-IP Digest, Vol 1 #18

Mike,

In your latest TCP-IP digest you mention that SRI is going to be using
the BBN user-mode TCP.  This is incorrect.  What we are doing is 
converting the Berkeley 4.2 VAX TCP/IP to run in an overlayed
2.81 BSD PDP-11 environment.  As a stop-gap we have one UNET host
running TCP/NCP (SRI-PRMH).  In about 2 months we hope to have the
Berkeley TCP running on all our VAX's and 11's.

	--Bill Croft

[ Looks like lots of folks have updated their plans since my last contact
  with them...  Sorry to have distributed out of date information.  -Mike ]

------------------------------

Subject: TCP/IP for VAX/VMS
From: BOLTE at OFFICE-8
To: TCP-IP at BRL

I recently received (indirectly) a copy of DTI's ACCESS ARPANET
Software Products paper.  It was an unsolicited response to
someone's plans for a VAX 11/780.  It seems that DTI reads the
Commerce Business Daily.

In addition to the comments that Gary Grossman made in the last
TCP-IP Digest, here are some more:

Documentation:  *ACCESS Site Administrator's Giude
              & *ACCESS User's Guide

Training:  They expect to offer ACCESS-T training course by this month.

Pricing:  ACCESS-N (NCP version) & ACCESS-T (TCP/IP version)
          each cost $15,000.
          Upgrade from ACCESS-N to ACCESS-T is $6,000.
          ACC LH/DH-11 hardware (Assoc.Comp.Cons.) is $6,500.
          Additional ACCESS-T's at the same site cost $6,000. each.

Software Support:  ACCESS-T: $4000/yr  or $400/mo

Above prices quoted as of Jan '82.

An additional POC is:   Gary Tauss (217) 384-8500.
                        Digital Technology Incorporated
                        302 E. John St.
                        Champaign, Il  61820

 ...Bill

------------------------------

From: Walt <Haas at UTAH-20>
Subject: Re: Service Specifications
To: ihnss!npois!srk at UCB-C70
cc: TCP-IP at BRL

The major objection to the three-arrow approach proposed by the HILI
committee is precisely that the response generated by the server layer
does not in fact carry any information to indicate whether the
recipient of the connection has accepted it.  For example, my X.25
implementation for the DEC-20 verifies that the original user can in
fact connect to the system before it returns the "CONNECT.response"
primitive to the network; hence the "CONNECT.confirm" primitive
received by the original user layer indicates that there has in fact
been some response from the remote user layer.  This is my
understanding of how the ISO reference model is intended to work.

The three arrow model which the HILI committee proposes strips the
"CONNECT.confirm" primitive of most of its useful information content,
and so renders it vitually useless.  In the HILI committee's proposed
model, this primitive indicates only that the remote user layer is
capable of absorbing "CONNECT.indication".  The original user receives
absolutely no useful information about whether the remote user has,
for example, enough resources to actually establish a connection.  In
fact this "CONNECT.confirm" is equivalent to a server-level
acknowledgement, and as such is scarcely worth the trouble of passing
to the original user.

------------------------------

From:     Frank J. Wancho <wancho@brl>
To:       tcp-ip at Brl
Subject:  TCP/IP from scratch

Please forgive the following naive message, but I need to ask some basic
questions which don't appear to be addressed anywhere.

I have a couple of potential hosts in our lab of which no similar
machine already exists on the net.  Both are SEL 32/xx series machines
which are capable of running a HASP background program (if that's worth
anything).

After reading through all of the existing documentation on TCP/IP
conversions for *existing* ARPANET hosts, it finally dawned on me that
those hosts still have the advantage of being able to use the existing
physical interface (1822), and here I thought that maybe "all" I had to
do was find some existing code (preferably in FORTRAN), and I'd have
those machines on the air.  Not so simple...

Given that our SELs are able to run a HASP protocol, would the fact that
the C/30's optionally support HDLC be related? - I need some
enlightenment here - the point of mentioning HASP is that we have the
hardware to support a bisync interface at some arbitrarily high speed.
Of course, if this is not pertinent, then the rest of this message can
be ignored...

Second, and last question: is there a version of TCP/IP already written
under government sponsorship in any FORTRAN-77/78 dialect?  Why FORTRAN?
Well, ours is a real-time FORTRAN designed to handle high-speed I/O on a
fully interrupt-driven architecture with separate I/O processors for
each major subsystem with "asynchronous" (no-wait) I/O capability.  That
means we can put a program to sleep while it waits for I/O to complete
with an interrupt to wake it up.  (All of this, I'm sure, is not a new
capability to most of you.  All it means to me is that perhaps we can
run this mini as a direct host with minimum loading on the system and
our users.)

Any and all help encouraged!

--Frank

END OF TCP-IP DIGEST
********************

----MESSAGE-END----