Text File

Aucbvax.4494 fa.unix-wizards utzoo!decvax!ucbvax!unix-wizards Fri Oct 16 02:19:39 1981 TCP-IP Digest, V1 #1 >From mike@brl Thu Oct 15 20:24:37 1981 TCP/IP Digest Thursday, 8 Oct 1981 Volume 1 : Issue 1

Today's Topics: A new Discussion Group Gateway Connection Policy -- TCP and IP Protocol Definitions Comments on TCP4 from BBN -- SRI Networks Development Group EDN-UNIX TCP/IP Notes -- 3Com TCP/IP Troubles NALCON Conversion Meeting -- BRL TCP/IP Environment (Planned) BBN VMUNIX (4.1BSD) TCP/IP -- BBNCC C/30 Features & Futures UTexas TCP4 (BBN) Mods -- 3Com TCP/IP: A Happy User Internet Gateway & Computer List -- TCP/IP Implementation Status Overview Are PDP-11's Dead? -- 3Com TCP/IP: More comments BBN TCP/IP for VAX: Manual Page ----------------------------------------------------------------------

From: Michael Muuss <MIKE @ BRL> Subject: A New Discussion Group

Greetings Earthlings! This is the first issue of a new digest which purports to discuss TCP and IP, the "DoD Standard Networking Protocols for the Eighties". Comments will probably center around UNIX implementations, but any technical networking or implementation discussions too specific for HUMAN-NETS is fair game here. Please send submissions to "TCP-IP @ BRL", requests to "TCP-REQUEST @ BRL" or "TCP-IP-REQUEST @ BRL".

This is sort of a spur-of-the-moment thing; it started with our trying to find out about TCP/IP iplementations, and wound up with dozens of letters asking for a report of what I found. This list may die stillborn, or it may flurish. Only time will tell! Cheers, -Mike

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

Date: 1 Oct 1981 1022-PDT Sender: WESTINE at USC-ISIF From: Postel@isif

1) The question about connection policy should be directed to DCA or your site's ARPANET sponsor. But my guess at an answer is "For a site with a host on the ARPANET (properly authorized) there should be no additional policy issues in connecting a local network to the ARPA Internet when the purpose and use of the local net is the same as for the existing host."

2) The question about IP and TCP is correctly addressed to me. RFCs 791, 792, and 793 define IP and TCP. The ARPANET already supports these protocols. Many TOPS20s, Unix-es (including VAX) and MIT-Multics, and UCLAs IBM system, already have these protocols in use. Work is in progress to replace all TIPs with TACs that use IP and TCP. There are about 10 internet gateways in service already. ARPA has set a goal for the complete switchover to IP and TCP by January 1983.

--jon.

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

Date: 2 Oct 1981 0520-PDT From: DEDWARDS at USC-ISI

BBN (of course) has a TCP 4 up and running written in C. Its slow and large (mainly due to the fact that it is entirely outside the kernelrunning as a user pgm with only a device driver in the kernel. Jack Haverty (JHAVERTY at BBN) or Mike Wingfield (wingfield at BBN-UNIX or BBN-RSM) can say lots more.

Howard Weiss

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

Date: 2 Oct 1981 0702-PDT From: NRL at USC-ISIE

For you information the below message was received by us in late September 1981; you may find in useful.

Regards, Doug Shannon - ARPAnet mailbox - NRL@ISIE

- - - - - - - - -

The Networks Development group at SRI can offer assistance in the development or operations support of one or more of the following:

- modernizing the NALCON sites UNIX from Version 6 to Version 7 (the current release from BTL); - 96-bit leader NCP software required to address all hosts on the ARPANET; - DoD standard TCP/IP network software with Version 7 UNIX and associated user software such as TCP-FTP, MTP (Mail Transfer Protocol), TELNET, etc.; - TCP/NCP mail gateway software to facilitate transition from NCP to TCP; - a VDH Front-End which would remove the overhead associated with the Very Distant Host protocol off of UNIX; - other areas related to UNIX and network systems.

The Networks Development group at SRI specializes in the development of local and long-haul network software, hardware, and protocols. There are currently 8 UNIX systems in operation at SRI, most of which are attached to our local area network and/or the ARPANET.

If you would like to discuss your needs and how we can assist you in any of the mentioned areas, please contact me at:

Geoff Goodfellow 333 Ravenswood Ave. Menlo Park, CA. 94025 (415) 859-3098 ARPANET: Geoff@SRI-CSL

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

Date: 2 Oct 1981 13:38:33 EDT From: Edward A. Cain <CAIN@EDN-UNIX>

Our TCP/IP is an extension of the one on the 11/70 at BBN, in case you have already heard from them. It runs on V6 here, and on V7 at BBN. Both machines support two interprocess communication mods to UNIX in order to allow the tcp/ip to work: (a) Rand "ports", with supporting "await" and "capacity" system calls, or (b) shared memory. The user-to- tcp interface can employ either of these techniques.

Our extensions to that work include: (a) handling GGP or ICMP packets, and (b) reassembly of fragments within IP.

You're welcome to the sources, manual pages, and UNIX hacks needed to make them work -- if you are using an 11/70. If you have some other machine like the C/70 or a vax, better get in touch with someone at BBN. Their active work on tcp/ip has centered around those 2 machines over the past couple of years. Jack Haverty is one point of contact (haverty at bbn-unix).

I recall an SRI status report on the 3-com stuff just last week. Seems the 3-com tcp/ip is full of bugs, and 3-com is under no obligation to fix things under the license agreement. However, SRI (one of 3-com's customers) has been able to get some fixes out of 3-com. Sounds kind of risky.

Ed Cain

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

Date: Fri, 2 Oct 81 16:31-PDT From: Greg at NPRDC

Indeed, we all are [Converting to TCP/IP] in a year or so. Geoff@SRI-CSL has offered to help the NALCON sites convert; maybe we can all get together and reduce our mutual costs. We're trying to set up a meeting to talk about it, probabally in the DC area; would you be interested in it?

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

Date: 2 Oct 81 20:45:01-EDT (Fri) From: Michael Muuss <MIKE@BMD70> To: Greg at NPRDC

We will probably be building an extensive local network which will initially include such varried systems as a CDC 7600 (SCOPE), CDC 173 (NOS), 40 MIPS HEP (UNIX, probably!), zillions of 11/70s and 11/34s, PE 3240s, C/70s, etc, and using Hyperchannels, PCL-11Bs, DQ-11s, UMC-11s, .... for communications. In my opinion, only a "standard" protocol like TCP will permit a plan like this to succeed (!).

Networking forever! -Mike

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

Date: 5 Oct 1981 9:24:30 EDT (Monday) From: Rob Gurwitz <GURWITZ AT BBN-RSM>

Jack Haverty passed your inquiry about TCP/IP along to me. In addition to the experimental TCP/IP that was done for the 11's (which you may or may not already have), we have been developing a version for the VAX running Berkeley 4.1BSD UNIX. This software is a full implementation of the protocols and is completely independent of any of the old U of I NCP code (including the RMI). It allows access at the TCP, IP, or local network access levels. The software is currently running and under test at several sites, including Berkeley. When it is generally released (probably around the first of the year), it will be available through Berkeley and will be included as part of a future 4.xbsd distribution. The configuration currently supports ARPANET 1822 local net protocol and a driver for the ACC LH/DH-11 IMP i/f, but work is also going on to develop other local net drivers (i.e., ETHERNET) for it.

Rob Gurwitz

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

Date: 2 Oct 81 18:48:08-EDT (Fri) From: Michael Muuss <MIKE@BMD70> To: Paul Santos <SANTOS@BBNE> Subject: C/30 Features & Futures

Just out of curiosity, I have some questions about our nice shiney new C/30.

1) How difficult is it to change a DISTANT host interface to a LOCAL host interface. It it a switch, a board, or a big deal? Could you estimate the cost of doing this? Our liason's crystal ball must have been a little cloudy...

2) Just for kicks, is it possible for a C/30 to support either (a) more than 4 modem lines, and/or (b) run the trunk lines at more than 50Kb?

3) Is there any provision for more than one trunk to connect between two C/30's to improve transmission between them?

We are doing a lot of planning here on networking, and are strongly considering using TCP/IP. What can you tell me about (or point me to) how BBN plans to proceed with TCP, and how will this affect the ArpaNet?

Cheers, -Mike ------------------------------

Date: 4 Oct 1981 16:10:25 EDT (Sunday) From: Paul Santos <SANTOS AT BBN-UNIX> To: Michael Muuss <MIKE.BMD70 AT BRL>

Mike,

I have forwarded your message to Nancy Mimno, who is the primary point of contact for ARPANET users. I believe the answers are in brief: 1) Easy, 2)(a) in progress, 2)(b) already exists, and 3) has been thought of but not currently planned. As for TCP/IP, it is a host isssue, and does not directly affect the subnetwork; however, DCA and ARPA (and DoD in general) are pushing on TCP and plan to outlaw NCP someday.

Paul

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

Date: 5 Oct 1981 at 0945-CDT From: roya at UTEXAS-11 (roya)

I have been working on TCP/IP BBN version 4 in our PWB-UNIX System. There were and are some problems that I'm trying to fix in it. Let me know if I can be any help to you.

Roya ------------------------------

Date: 7 Oct 1981 11:38:55-PDT From: menlo70!sytek!zehntel!billn at Berkeley

We have been running it [3Com] for a short time between two 70's hooked up via an able da-11. With unloaded systems we get about 60kb during file transfer. With one heavily loaded system and one lightly loaded one we get about 45kb. We run 2.?bsd and had a few problems, not many, during installation. Our problems were due to the fact that, as the previous msg said, it IS big. They have tried v. hard to make it a "drop in" product, and have done a good job, but the 2.?bsd systems are just too huge, as normally run, to avoid some hacking during installation. (3com is now more experienced in 2.?bsd-ese than they were...) It seems relatively bug free and robust. Our general users have not been unleashed on it yet -- that'l be the really telling blow. /b

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

Date: 5 Oct 1981 1358-PDT From: POSTEL at USC-ISIF To: mike.bmd70 at BRL

, 27-May-81 16:52 JBP ;;;; ADDRESSES The internet addresses in this memo are stated as four 8-bit fields with the value of each field given in decimal. GATEWAYS Name Addresses --------------- --- --- --- --- --- --- --- --- DCEC-EDN/ARPA 21 0 0 2 10 3 0 20 MIT-LCS/ARPA 18 8 0 4 10 0 0 77 BBN-RCC/ARPA 3 2 0 5 10 2 0 5 BBN-SAT/ARPA 4 0 0 61 10 3 0 40 NDRE-SAT/ARPA 4 0 0 38 10 3 0 41 COMSAT-SAT/COMSAT 4 0 0 39 29 0 2 2 UCL-SAT/UCL 4 0 0 60 11 3 0 42 UCL-SAT/NULL 4 0 0 60 35 7 0 0 UCL-UCL/RSRE 11 3 2 42 25 6 0 0 RSRE-NULL/PPSN 35 6 0 0 25 6 0 0 RSRE-NULL/PPSN 35 6 0 0 25 13 0 0 SRI-PR1/ARPA 2 0 0 11 10 3 0 51 SRI-PR2/ARPA 6 0 0 11 10 1 0 51 BBN-BBNPR/ARPA 1 0 0 11 3 0 0 62 Bragg-BraggPR/ARPA 9 0 0 11 10 0 0 38 COMPUTERS Name Address --------------- --- --- --- --- ALTA-COMA 3 1 0 50 BBN-UNIX 10 0 0 63 BBN-VAX 10 2 0 82 BBNA 10 3 0 5 BBNB 10 0 0 49 BBNC 10 3 0 49 BBND 10 1 0 49 BBNE 10 0 0 5 BBNF 3 2 0 51 BBNG 10 1 0 5 EDN-HOST1 21 1 0 1 EDN-HOST3 21 0 0 3 EDN-UNIX 10 3 0 20 ISIB 10 3 0 52 ISIC 10 2 0 22 ISID 10 0 0 27 ISIE 10 1 0 52 ISIF 10 2 0 52 MIT-DevMultics 10 4 0 31 MIT-Multics 10 0 0 6 UCLA-CCN 3033 10 1 0 1

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

Date: 5 Oct 1981 1544-PDT From: POSTEL at USC-ISIF

BBN C/70 UNIX

Date: 14 May 1981 From: Jack Haverty <HAVERTY@BBN-UNIX>

The C/70 processor is a BBN-designed system using C as its native mode. It supports Version 7 of UNIX, and provides for user processes with 20-bit address spaces. The TCP/IP for this machine is in development; the BBN VAX-11/780 UNIX implementation will be ported to the C/70 UNIX system. This work is expected to be complete in summer '81.

BBN GATEWAYS

Date: 8 May 1981 From: Ginny Strazisar <STRAZISAR@BBNA>

This is a status report on the implementation of the Internet Protocol in these gateways:

the ARPANET/SATNET gateway at BBN (10.3.0.40), the ARPANET/SATNET gateway at NDRE (10.3.0.41), the Comsat DCN Net/SATNET gateway at COMSAT (4.0.0.39), the SATNET/UCL Net/RSRE Net gateway at UCL (4.0.0.60), the PR Net/RCC Net gateway at BBN (3.0.0.62), the PR Net/ARPANET gateways at SRI (10.3.0.51, 10.1.0.51), and the PR Net/ARPANET gateway at Ft. Bragg (10.0.0.38).

The gateways forward packets with internet header formats as specified in the DoD Standard Internet Protocol, January, 1980. The gateways implement this Internet Protocol with the following exceptions:

1. The type of service field is ignored, i.e., the gateways use the same type of service in each network regardless of the value of the internet type of service field.

2. No options are implemented. Packets containing options are forwarded by the gateways, subject to the specified constraints, i.e., correct checksum, correct length, non-zero time to live field, but the gateways do not process any options. Packets with options are not fragmented. If a packet is too large to be sent through the next network on the route to its destination and it contains options, then the packet is discarded.

BBN H316 and C/30 TAC

Date: 14 May 1981 From: Bob Hinden <HINDEN@BBNE>

The Terminal Access Controller (TAC) is user Telnet host that supports TCP/IP and NCP host to host protocols. It runs in 32K H-316 and 64K C/30 computers. It supports up to 63 terminal ports. It connects to a network via an 1822 host interface.

The TAC's TCP/IP is intended to conform with the IEN-128 and IEN-129 specifications with the following exceptions: 1) IP options are accepted but ignored. 2) TCP options are not accepted. 3) Precedence, Security, etc. are ignored.

The TAC also supports Packet core, TAC Monitoring, Internet Control, and a subset of the Gateway-Gateway protocols.

For more information on the TAC's design, see IEN-166.

Currently, TAC's TCP/IP has been tested with several other implementations. This includes TOPS20 (BBND, BBNC, BBNA, ISID), Multics (MIT-Multics), IBM (UCLA), 11/70 Unix (BBN-Unix,EDN-Unix), and VAX Unix (BBN-VAX). All major features have been implemented except IP reassembly and TCP Urgent handling. These will be done in the near future.

BBN HP-3000

Date: 14 May 1981 From: Jack Sax <SAX@BBN-UNIX>

The HP3000 TCP code is in its final testing stages. The code includes under the MPE IV operating system as a special high priority process. It is not a part of the operating system kernel because MPE IV has no kernel. The protocol process includes TCP, IP, 1822 and a new protocol called HDH which allows 1822 messages to be sent over HDLC links. The protocol process has about 8k bytes of code and at least 20k bytes of data depending on the number of buffers allocated.

The TCP code is believed to support all features except rubber EOL. The IP code currently supports fragment reassembly but not fragmentation. In addition provisions have been made to allow the IP layer to accept and act on routing and source quench messages. These features will be added sometime this summer. Security and precedence are currently ignored.

In addition to the TCP the HP3000 has user and server TELNET as well as user FTP. A server FTP may be added later.

A complete description of the implementation software can be found in IEN167.

BBN PDP 11/70 UNIX

Date: 14 May 1981 From: Jack Haverty <HAVERTY@BBN-UNIX>

This TCP implementation was written in C. It runs as a user process in version 6 UNIX, with modifications added by BBN for network access. It does not perform reassembly, or rubber eol, and has no separate IP user interface. It supports user and server Telnet.

This implementation was done under contract to DCEC. It is installed currently on several PDP-11/70s and PDP-11/44s. Contact Ed Cain at DCEC <CAIN@EDN-UNIX> for details of further development.

BBN TENEX & TOPS20

Date: 13 May 1981 From: Charles Lynn <CLYNN@BBNA>

TCP4 and IP4 are available for use with the TENEX operating system running on a Digital KA10 processor with BBN pager. TCP4 and IP4 are also available as part of TOPS20 Release 3A and Release 4 for the Digital KL10 and KL20 processors.

Above the IP layer, there are two Internet protocols within the monitor itself (TCP4 and GGP). In addition up to eight (actually a monitor assembly parameter) protocols may be implemented by user-mode programs via the "Internet User Queue" interface. The GGP or Gateway-Gateway Protocol is used to receive advice from Internet Gateways in order to control message flow. The GGP code is in the process of being changed.

TCP4 is the other monitor-supplied protocol and it has two types of connections -- normal data connections and "TCP Virtual Terminal" (TVT) connections. The former are used for bulk data transfers while the latter provide terminal access for remote terminals.

Note that TVTs use the standard ("New") TELNET protocol. This is identical to that used on the ARPANET with NCP and in fact, is largely implemented by the same code.

At the IP level, fragmentation and reassembly are not currently supported. The Autodin II Security related option can be parsed, but no code for doing preemption of resources has been writen. Certain other security-related options are implemented.

User and Server FTP processes above the TCP layer are under active development.

BBN UNIX

Date: 1 May 1981 From: Mike Wingfield <WINGFIELD@BBND>

1. Hardware - PDP-11 running UNIX version 7, with BBN IPC additions.

2. Software - written in C, requiring 22K instruction space, 15K data space. Supports 10 connections.

3. Status - TCP has been essentially completed since March, 1979, and no additional work has been done on it since then.

4. Unimplemented protocol features

A. TCP Does not support Rubber EOL Ignores options except S/P/T Discards out-of-order segments

B. IP Does not support fragmentation or reassembly. Ignores options

5. Documentation - "TCP/PSIP Development Report", and "TCP Software Documentation", both BBN reports.

BBN VAX

Date: 7 May 1981 From: Rob Gurwitz <GURWITZ@BBN-UNIX>

The VAX TCP/IP implementation is written in C for Berkeley/VMUNIX. It is described in detail in IEN168. It is currently operational experimentally and is undergoing further development.

The implementation is believed to conform to the specification with the following exceptions:

1) All internet options are currently ignored.

2) Security, precedence, etc. are ignored.

The TCP/IP is implemented within the kernel. It supports all aspects of the protocol, and provides a separate user interface at the IP level.

Continuing development includes implementation of handling internet routing messages, hosts on multiple networks, and performance improvement. Tools are available on the VAX for monitoring and recording net traffic.

COMSAT

Date: 30 Apr 1980 From: Dave Mills <MILLS@ISIE>

1. The TCP/IP implementation here runs in an LSI-11 with a homegrown operating system compatible in most respects to RT-11. Besides the TCP/IP levels the system includes many of the common high-level protocols used in the ARPANET community, such as TELNET, FTP and XNET.

2. Connections have been verified with the following other implementations:

TOPS-20 (BBNF, ISID, ISIE and ISIF) Unix (BBN, NPL and EDN) Multics (MIT-Multics) IBM 3033 (CCN) Packet Radio TIU (UCL, RSRE) and the several hosts on the COMSAT local net (DCNET) running the the same software.

3. The TCP implementation is believed to conform to the specification in all aspects except:

a. It does not implement the rubber-EOL mechanism. All buffers appear a single octed in length.

b. It does not implement the urgent mechanism.

4. The IP implementation is believed to conform to the specification in all respects except:

a. Fragmentation and reassembly is not implemented.

b. All options, including security, timestamping, etc., are ignored by the IP layer. Timestamping is handled by the protocol and user layers. Other options can be specified by the protocol and user layers and checked by the protocol layer.

Our plans for the remainder of the FY80 and FY81 years are to upgrade the implementation to conform to the full specification in all practicable respects and, especially, to evaluate overall performance in systems involving both high-performance and limited-performance hosts and nets.

DTI VAX

Date: 15 May 1981 From: Gary Grossman <GRG@DTI)>

Digital Technology Incorporated (DTI) IP/TCP for VAX/VMS

The following describes the IP and TCP implemenation that DTI plans to begin marketing in 4th Quarter 1981 as part of its VAX/VMS network software package.

Hardware: VAX-11/780 or /750.

Operating System: DEC standard VAX/VMS Release 2.0 and above.

Implementation Language: Mostly C, with some MACRO.

Protocol Features Supported:

IP:

Fragementation/Reassembly: Does not fragment, but does reassemble.

Options: Security option is both generated and interpreted.

Packet identifier: Can be specified by user, but will generate a unique identifier if user does not supply one.

Reassembly timeout: Fixed value. If buffers fill up, oldest fragment is discarded first.

Gateway functions: All necessary GGP functions will be implemented. (GGP functions are not implemented in current NFE IP.)

Type of Service: As for Gateway functions.

Support of protocols other than TCP: Yes, simultaneously with TCP.

TCP:

Precedence and security fields: Both generated and interpreted.

TCP options: All defined options are implemented.

Urgent: Implemented as per specification.

EOL: As per specification.

Buffer size: Option implemented; user may specify buffer size within limits.

Retransimission: Timeouts employ exponential backoff until a limit is reached, at which time user is signalled. Transmits empty packets into a zero window.

Initial sequence number: Derived from 32-bit system clock with 10 us. resolution.

Window strategy: Window size is larger than the actual buffer space available by the size of the maximum size internal buffer.

ACK generation: ACK is sent as soon as data has been placed in sequence into user buffer.

Code size:

IP (Includes BBN 1822 interface code, about 30%):

Object code: 14K bytes. Buffer and table space: 24K bytes. Source: 7K lines of C code with commentary.

TCP:

Object code: 27K bytes. Buffer and table space: 46K bytes. Source: 15K lines of C code with commentary.

Fixed table space: See above.

Connections supported: Maximum of 64.

User level protocols available: TELNET, FTP, and MTP will be available. (The NFE version uses AUTODIN II protocols.)

MIT MULTICS

Date: 13 May 1981 From: Dave Clark <CLARK@MIT-MULTICS>

Multics TCP/IP is implemented in PL/1 for the HISI 68/80. It has been in experimental operation for about 18 months; it can be distributed informally as soon as certain modifications to the system are released by Honeywell. The TCP and IP package are currently being tuned for performance, especially high throughput data transfer.

It is believed that the implementation fully conforms to the DOD standard. It also supports most relevant features of GGP, including redirect packets. The IP layer is a gateway, and supports fragmantation as well as reassembly.

Higher level services include user and server telnet, and a full function MTP mail forwarding package.

The TCP and IP contain good logging and debugging facilities, which have proved useful in the checkout of other implementations. Please contact us for further information.

SRI LSI-11

Date: 15 May 1981 From: Jim Mathis <MATHIS.TSCB@SRI-UNIX>

The IP/TCP implementation for the Packet Radio terminal interface unit is intended to run on an LSI-11 under the MOS real-time operating system. The TCP is written in MACRO-11 assembler language. The IP is currently written in assembler language; but is being converted into C. There are no plans to convert the TCP from assembler into C.

The TCP implements the full specification, although the current user interface lacks a mechanism to communicate URGENT pointer information between the TCP and the higher-level software. The code for rubber-EOL has been removed in anticipation of a change to the specification. The TCP appears to be functionally compatible with all other major implementations. In particular, it is used on a daily basis to provide communications between users on the Ft. Bragg PRNET and ISID on the ARPANET.

The IP implementation is reasonably complete, providing fragmentation and reassembly; routing to the first gateway; and a complete host-side GGP process. Currently the source quench message is ignored. No IP options are generated and all received options are ignored.

A measurement collection mechanism is currently under development to collect TCP and IP statistics and deliver them to a measurement host for data reduction.

UCLA IBM

Date: 13 May 1981 From: Bob Braden <BRADEN@ISIA>

Implementation Status -- IP/TCP for IBM 360/370 under OS/MVT. May 12, 1981

1. Hardware

IBM 360 or 370, with a "Santa Barbara" interface to the IMP.

2. Operating System

OS/MVS with ACF/VTAM. An OS/MVT version is also available.

The UCLA NCP operates as a user job, with its own internal multiprogramming and resource management mechanisms.

3. Implementation Language

BAL (IBM's macro assembly language)

4. Protocol features supported:

A. IP PROTOCOL:

(1) Fragmentation/reassembly: performs reassembly. Does not fragment, assuming that higher-level protocol (TCP) will create suitable size segments during packetizing.

(2) Options: all internet options accepted but ignored. None are sent (in particular, no error options).

(3) Identifier selection: uses globally-unique identifiers for transmitted segments, independent of destination.

(4) Reassembly timeout: fixed value (30-60 seconds), independent of time-to-live field. Packets are discarded if time-to-live field is zero.

(5) Gateway functions: Unable to select an alternate route (gateway) if the original route fails. Does accept GGP, and acts on Redirect, Destination Unreachable, and Echo packets. Source Quench is ignored.

(6) Type of Service: default Type of Service set, may cause either Subtype 0 or Subtype 3 (Uncontrolled) packets to be sent.

B. TCP PROTOCOL:

(1) Precedence, security fields: not set or tested.

(2) TCP Options: no options generated. All options received but only Buffer Size is acted upon.

(3) Urgent: may be sent and received by user process.

(4) EOL: may be sent by user process, but received EOL's are not passed to user process.

(5) Buffer Size: will transmit according to specified buffer size. Uses circular buffer for received data, so never specifies a buffer size to remote TCP.

(6) Retransmission: successive retransmissions use exponential backoff. Base time is 2 times observed weighted-average round-trip time. Round-trip time is measured by initial packet transmission to complete acknowledgment. Retransmits slowly into zero window.

(7) Initial Sequence Number: derived from system clock.

(8) Window strategy: uses conservative strategy, never adver- tising a receive window larger than the space available in the circular buffer.

(9) ACK generation: always sends <ACK> in response to receipt of a non-empty packet. As user process removes bytes from buffer, optimizing algorithm determines when to generate <ACK> to inform sender of larger window.

5. Code Size (addition to existing NCP code)

Resident Control Process: 4K bytes.

Internet Protocol Layer: 10K bytes. (transient)

TCP Protocol Layer: 10K bytes. (transient)

6. Fixed Table Space

The limited fixed table space is included in the code (above).

7. Connections Supported:

Only practical limitation is amount of memory available in NCP region for buffers and per-connection control blocks; requirements are:

For each connection, the internet and TCP layers require control blocks totalling 256 bytes.

(*) Receive:

Segment reassembly buffer= max segment size - min internet header length + 16= 572 bytes per buffer.

(*) Send:

128 bytes per unacknowledged segment.

Note: the actual data being sent is not counted here, as it occupies buffer space belonging to the appropriate user-level protocol module.

(*)Note: there is a pool of these objects, shared among all active connections. The pool grows and shrinks dynamically with the number of connections; it is probably reasonable to expect an average of one segment reassembly buffer and one unacknowledged segment (total of 700 bytes) per TCP connection.

In addition to this TCP-specific memory, there is the memory to support the user-level protocol. For example, a server-Telnet session to TSO requires control blocks and buffers totalling about 1800 bytes; this is identical for TCP and for the ARPANET Host-Host ("NCP") protocol.

8. User-Level Protocols Available

User and Server Telnet

9. Philosophical Remarks

This implementation of the Internet and TCP protocols is designed to meet the following general objectives:

(a) operate within the existing NCP system job, sharing code and control-block formats wherever possible;

(b) be compatible at the system-call level with the existing user-level protocol modules;

(c) implement the Internet protocol as a distinct layer, with interfaces designed to expedite the implementation of other higher-level internet protocols in addition to TCP;

(d) require minimum NCP resources when internet protocol is not in use.

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

Date: 5 Oct 81 20:09:53-EDT (Mon) From: Michael Muuss <MIKE@BMD70> To: Rob Gurwitz <GURWITZ@BBN-RSM>

Rob - Thanks very much for the information about the 4.1 BSD TCP/IP implementation. Sounds like a very nice job! What is the feasibility of moving it to a PDP-11 UNIX system? There are some of us who can not afford to subscribe to the Berkeley "PDP-11s are dead" philosophy...

Can you feed me any handy dribbles of documentation or overview information? Cheers, -Mike ------------------------------

Date: 3 Oct 1981 00:13:28-PDT From: ESVAX.clemc at Berkeley To: csvax.unix-wizards at Berkeley

The 3Com version for the 11 is fairly good. It is like the old U of I NCP in that it is not all kernel resident (like the BBN Version). It IS large. Tektronix has been using it will 2.8 BSD for a few months but they have had lots of trouble. It has been a conbination of sparse comments in the 3Com code, 2.8 BSD and trying to Talk TCP to a CDC Cyber on the other end. They are using Network System's Corp "HYPERchannel" gear for the physical medium, which is very fast but the 11/70 can not keep up with it (niether can the cyber when running TCP).

Both BBN and 3Com have used Psuedo TTY's for the Virtual Terminal Protocol. This has both advantages and disadvantages. 3Com wants to make their code portable to other UNIX versions. They are working on/have made to work a version that runs on an 11/34 with overlays. As far as I know, BBN has punted the 11's.

Clem

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

Date: 6 Oct 1981 11:32:45 EDT (Tuesday) From: Rob Gurwitz <GURWITZ AT BBN-RSM> To: Michael Muuss <MIKE.BMD70 AT BRL>

There is a note describing the internals of the TCP/IP for the VAX available from the ARPANET NIC as IEN 168. In addition, I have manual pages for the lowest level TCP/IP/local net i/f, if you want them. The TELNET and FTP are ports of software that has been around for awhile, so manual pages for them are probably generally available (you probably already have them if you're running NCP on an 11). MTP mail is new, but we have no manual pages ready yet.

Rob.

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

Date: 7 Oct 1981 9:21:34 EDT (Wednesday) From: Rob Gurwitz <GURWITZ AT BBN-RSM> To: Michael Muuss <MIKE.BMD70 AT BRL>

Here is the manual page for low level TCP access. I hope it's useful. Feel free to include info about the implementation in your summary. Rob.

NET(5) UNIX Programmer's Manual NET(5)

NAME tcp, ip, rawnet - internet networking software

SYNOPSIS open ("/dev/net/net", ncon);

struct con *ncon;

struct lhost { /* net library format internet address */ unsigned char l_hoi; /* host on imp */ unsigned char l_net; /* network */ n_short l_imp; /* imp */ }; /* c_mode field definitions */ struct con { /* user connection structure */ unsigned char c_mode; /* mode 0-passive 1-active (see flags) */ unsigned char c_sbufs; /* # send buffers to use */ unsigned char c_rbufs; /* # rcv buffers to use */ unsigned char c_prec; /* precedence */ #define c_lo c_prec /* low raw link or proto # */ unsigned char c_sec; /* security level */ #define c_hi c_sec /* hi raw link or proto # */ unsigned char c_compt; /* compartment */ unsigned char c_timeo; /* tcp open timeout */ unsigned char c_x; /* (unused) */ unsigned short c_lport; /* local port */ unsigned short c_fport; /* foreign port */ struct lhost c_con; /* foreign socket */ };

struct netstate { /* network status structure */ unsigned char n_lolink; /* low link no. in range (IP, RAW) */ unsigned char n_hilink; /* high link no. in range (IP, RAW) */ unsigned char n_snd; /* # send bufs allocated */ unsigned char n_rcv; /* # receive bufs allocated */ unsigned char n_ssize; /* # bufs on send buffer */ unsigned char n_rsize; /* # bufs on receive buffer */ unsigned char n_state; /* state of this connection */ unsigned char n_flags; /* misc. flags (see below) */ unsigned short n_lport; /* local port */ unsigned short n_fport; /* foreign port */ struct lhost n_con; /* foreign socket */ };

#define CONACT 1 /* active connection */ #define CONTCP 2 /* open a tcp connection */ #define CONIP 4 /* open a raw ip connection */ #define CONRAW 8 /* open a raw local net connection */ #define CONDEBUG 128 /* turn on debugging info */

/* net ioctl definitions */ #define NETGETS 1 /* get status */ #define NETSETD 2 /* set debugging info */ #define NETSETU 3 /* set urgent mode */ #define NETRSETU 4 /* reset urgent mode */ #define NETSETE 5 /* set EOL mode */ #define NETRSETE 6 /* reset EOL mode */ #define NETCLOSE 7 /* initiate tcp close */ #define NETABORT 8 /* initiate tcp abort */

#define SIGURG 16 /* urgent signal */

#ifndef KERNEL /* n_flags field definitions */

#define UEOL 0001 /* EOL sent */ #define UURG 0002 /* urgent data sent */ #define UDEBUG 0004 /* turn on debugging info recording */ #define ULOCK 0010 /* receive buffer locked */ #define UTCP 0020 /* this is a TCP connection */ #define UIP 0040 /* this is a raw IP connection */ #define URAW 0100 /* this is a raw 1822 connection */ #define ULISTEN 0200 /* awaiting a connection */

/* n_state field definitions */ #define UCLOSED 0000 /* connection closed */ #define UCLSERR 0001 /* error -- connection closing */ #define UABORT 0002 /* connection aborted */ #define UINTIMO 0004 /* open failed -- init timeout */ #define URXTIMO 0010 /* retransmit too long timeout */ #define URESET 0020 /* connection aborted due to reset */ #define UOPERR 0040 /* open failed -- not enough buffers */ #define UURGENT 0100 /* urgent data received */ #define UNETDWN 0200 /* connection aborted due to net */

#endif KERNEL

DESCRIPTION The special file /dev/net/net is used to access ARPANET type packet-switched networks via the DoD standard host-host Internetworking Protocols, TCP (Transmission Control Protocol), and IP (Internet Protocol). It also allows communication over the local network(s) to which the system is connected with "raw" packets, enabling user software to do its own communications processing. Access to the network at this level is the most direct form of use. It is assumed that most users will use higher level protocol programs, like ftp(1) and telnet(1) to communicate over the network. (This description assumes the reader is familiar with ARPANET type communications protocols.)

ESTABLISHING CONNECTIONS To establish a connection via TCP or IP, or to communicate with raw packets, the open(2) call is given, with the usual mode argument replaced by a pointer to a connection structure, defined in /usr/include/con.h. The c_mode field of this structure specifies what type of connection is desired (TCP, IP, or RAW), and whether or not the connection is to be active (specifying a specific foreign host address), or passive (with no foreign address, implying that the connection will be established when any foreign process tries to communicate with the opener).

The c_sbufs and c_rbufs fields specify buffer allocations for the send and receive sides of the connection, respectively. If either value is zero, the default allocation will be used for that direction (currently 1K bytes). The user can request up to 4K bytes each for send and receive directions by varying these parameters between 1 and 4.

The c_prec, c_sec, and c_compt fields specify values of precedence, security level, and compartmentalization for TCP connections. (N.B. This feature is currently not implemented). For IP and RAW connections, the c_hi and c_lo fields specify a range of IP protocol numbers or local net dispatch numbers (e.g., ARPANET link numbers) to watch for. Messages falling into this range are queued for the user. The low end of the range is used in sending messages. Low must be less than or equal to high, and numbers in the range must not be in use in any other connection.

The c_timeo parameter specifies a length of time in seconds to wait for connection establishment before aborting (this does not apply to passive opens). If the field is zero, the default of 30 seconds is used.

The remaining fields specify local, and foreign ports for TCP, and the foreign host address in net long format (see libn(3)). The local port may be zero, in which case TCP assigns a unique port number to the connection. The foreign port and host address may only be zero for a passive open.

READING AND WRITING If the open succeeds, a file descriptor is returned which may be used in subsequent reads and writes (see, read(2), write(2)). Reads and writes work as usual with a few exceptions. A read may return with error condition ENETSTAT, which indicates that some exceptional condition has been detected. In this case, a 16 bit value is returned to the read buffer, which give the status of the connection that caused the return. Further status may be determined with ioctl(2). (see, NETWORK STATUS). If the condition is non-fatal, the read may be re-issued. Reads may return less data than requested if a TCP EOL was detected. Reads will block if there is no data for the user. Writes block if the amount of send buffer resources for the connection is exceeded. IP and RAW reads return the appropriate protocol leaders along with any data received. Only one IP or RAW message may be received or sent per call.

In addition to normal TCP reads and writes, the user may wish to indicate EOL and URGENT data on writes and receive notification of URGENT data sent by the foreign peer. EOL and URGENT are enabled by issueing the NETSETE or NETSETU ioctl calls. Once set, EOL is sent at the last byte of each subsequent write. Similarly, the URGENT pointer is set to start at the first byte of the next write, and ends with the first byte sent after URGENT mode is disabled. These modes are disabled by the NETRSETE and NETRSETU ioctl calls. URGENT data is indicated by signal SIGURG when the first byte is received. This signal is normally ignored. (A status flag is also set in the presence of urgent data.)

CLOSING CONNECTIONS Normally, the close(2) call is used to close a TCP, IP, or RAW connection. In each case, it indicates that the user will send or receive no more data. For TCP connections, close initiates the connection closing protocol, though it returns immediately. Thus, the internal connection structures persist until the connection has reached the CLOSED state. For IP and RAW connections, the close is immediate and deletes all internal structures.

In addition to close for TCP connections, there is an ioctl call, NETCLOSE, which indicates that the local connection will send no more data, but is still able to receive data from the foreign peer. In this case, subsequent writes are illegal and will terminate with errors, but subsequent reads will work until the connection is closed by the foreign peer.

NETWORK STATUS There are several ioctl(2) calls available for receiving network status information or initiating certain modes or functions. Most of these calls have been described above. The status call, NETGETS, takes a status buffer pointer, which points to a netstate structure, illustrated above, which is filled in by the call.

To summarize, the various ioctl calls are:

NETGETS Return network status information to the structure pointed at by third argument of ioctl.

NETSETD Reset the debugging log to the file name pointed at by the third argument. The file must already exist. If the argument is zero, turn off debug logging (see, DEBUGGING).

NETSETU Set urgent mode starting at next byte written (TCP only).

NETRSETU Reset urgent mode, urgent pointer ends at last byte written (TCP only).

NETSETE Set EOL mode, send EOL at last byte of each subsequent write (TCP only).

NETRSETE Terminate EOL mode (TCP only).

NETCLOSE Start TCP connection close. User can continue to receive data (TCP only).

NETABORT Abort TCP connection. Foreign peer is reset and no more data may be sent or received (TCP only).

DEBUGGING The network software enables certain trace information to be recorded for TCP connections. This information is logged in a single debugging log file. To enable this feature, the CONDEBUG bit in the c_mode field of the open connection parameter structure must be set. The default debugging log is /etc/net/tcpdebug. This may be changed or the feature may be disabled system wide with the NETSETD ioctl call. Only the super-user may do this. The format of the debugging information is several bytes of binary data per TCP transaction. The log may be printed in readable form with trpt(1).

DIAGNOSTICS The following system error codes may be returned by network system calls:

ENETSTAT (35) Network status available (not a fatal error, see READS AND WRITES).

ENETDWN (36) Open failed because network connection is unavailable.

ENETCON (37) Open failed because there were too many connections.

ENETBUF (38) No more network buffer space.

ENETERR (39) Fatal error from network protocol processor.

ENETRNG (40) IP or RAW open failed because the protocol or dispatch number was out of range or already in use. TCP open failed because the user tried to open an already existing connection (i.e., one with the identical foreign host address and local and foreign ports).

FILES /dev/net/net /etc/net/tcpdebug

SEE ALSO ftp(1), telnet(1), trpt(1), read(2), write(2), open(2), close(2), ioctl(2), libn(3)

R.F. Gurwitz, VAX-UNIX Networking Support Project Implementation Description, DARPA Information Processing Techniques Office, IEN 168, January, 1981.

J. Postel (ed.), DoD Standard Internet Protocol, DARPA Information Processing Techniques Office, IEN 128, January, 1980.

J. Postel (ed.), DoD Standard Transmission Control Protocol, DARPA Information Processing Techniques Office, IEN 129, January, 1980.

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

End of TCP-IP Digest ********************

----------------------------------------------------------------- gopher://quux.org/ conversion by John Goerzen <jgoerzen@complete.org> of http://communication.ucsd.edu/A-News/

This Usenet Oldnews Archive article may be copied and distributed freely, provided:

1. There is no money collected for the text(s) of the articles.

2. The following notice remains appended to each copy:

The Usenet Oldnews Archive: Compilation Copyright (C) 1981, 1996 Bruce Jones, Henry Spencer, David Wiseman.