IEN 167                                            Sax and Edmond
                                     Bolt Beranek and Newman Inc.
                                                        July 1980












                   HP3000 TCP DESIGN DOCUMENT

                   Jack Sax and Winston Edmond

                  Bolt Beranek and Newman Inc.

                            July 1980




































IEN 167                                            Sax and Edmond
                                     Bolt Beranek and Newman Inc.
                                                        July 1980



                        Table of Contents




1   Preface............................................... 3
2   Introduction.......................................... 4
3   Current HP3000 Structure.............................. 7
3.1   Processor Features.................................. 7
3.2   Network Interface Hardware.......................... 8
3.3   Operating System Software........................... 8
3.4   Input/Output....................................... 10
3.5   Interprocess Communication......................... 12
3.6   Existing INP Software.............................. 14
4   Protocol Software Architecture....................... 16
5   System Protocol Software............................. 20
5.1   Implemented Features............................... 20
5.2   Software Architecture Overview..................... 21
5.3   Control Structures................................. 23
5.3.1   Network Resources Control Block.................. 24
5.3.2   Foreign Host Control Blocks...................... 25
5.3.3   Connection Control Block......................... 26
5.3.4   Network Buffer Resources List Structures......... 26
6   User Process/TCP Interface........................... 29
6.1   Interface Intrinsics............................... 30
6.2   Flow Control Across the Interface.................. 36
6.3   Interface Control Structures....................... 36
6.4   Interface Control Algorithms....................... 37
6.5   Windowing, Acknowledgment, and Retransmission...... 48
7   1822 Layer/INP Driver Communication.................. 50
8   Protocol Software Buffering Scheme................... 52
8.1   Network Buffer Pool................................ 54
8.1.1   Packet Compaction................................ 55
8.1.2   Buffer Recycling................................. 56
8.2   User Process Buffer Pool........................... 58
9   Data Flow Through the Protocol Software.............. 60
9.1   ARPANET to the User Level Data Flow................ 61
9.2   User Level to the ARPANET Data Flow................ 64











                               -2-

IEN 167                                            Sax and Edmond
                                     Bolt Beranek and Newman Inc.
                                                        July 1980



1  Preface


     This report describes a  design  implementation  of  ARPANET

protocols on a Hewlett Packard HP3000 Series III computer system.

Specific protocols  to  be  implemented  include  a  Transmission

Control  Protocol  (TCP),  Internet  Protocol (IP), File Transfer

Protocol (FTP), and TELNET Protocols.  The reader is  assumed  to

be  familiar  with  the purpose of these protocols.  The protocol

software will run under the HP  Multiprocessing  Executive  (MPE)

operating system.


     The  designs  reflect  our  current  understanding  of   the

environment  and the tasks ahead and may be changed as we proceed

with implementation.


























                               -3-

IEN 167                                            Sax and Edmond
                                     Bolt Beranek and Newman Inc.
                                                        July 1980



2  Introduction


     The overall purpose of this project is to modify the Hewlett

Packard 3000/Series III computer system running the MPE operating

system so that it converses with the ARPANET.


     A  layered  protocol  approach   will   be   used   in   our

implementation.   Protocol  layers one through four represent the

system layers which are responsible for moving a message reliably

from  one Host to another.  The next protocol layer consists of a

number of applications protocols which determine the content  and

meaning of the messages exchanged.


     Protocol levels  one  and  two  are  X.25  LAP  link  access

protocols.   These  protocols are implemented in microcode on the

Intelligent Network  Processor  (INP)  interface  available  from

Hewlett  Packard.   Since  the  X.25 LAP  protocols are different

from the standard 1822 IMP Host protocols,  a  special  X.25  IMP

interface  is  used  to  link  the  HP3000 with the ARPANET.  The

interface divides standard 1822 packets into  a  number  of  X.25

frames  and  transfers  each  frame  separately.   The diagram in

Appendix A shows the hardware  configuration  used  to  link  the

HP3000 to the ARPANET.


     The next two protocol layers consist  of  the  DOD  standard

Internet  Protocol  (IP)  and  the  Transmission Control Protocol




                               -4-

IEN 167                                            Sax and Edmond
                                     Bolt Beranek and Newman Inc.
                                                        July 1980



(TCP).  The  Internet  protocol  provides  communication  between

Hosts  on  different  networks via gateways between the networks.

The Transmission Control Protocol provides reliable  transmission

between Hosts and performs some Host-to-Host flow control.


     The initial implementation will  include  three  application

layer  protocols.   One  of  these  is the File Transfer Protocol

(FTP), which allows a user to move files from one computer system

to another.  The second and third application layer protocols are

User and Server TELNET.  User TELNET  gives  the  user  a  remote

terminal capability by taking the characters from the local input

device and sending  them  to  the  foreign  host,  and  returning

characters  from  the  foreign  host  to  the local output device

(typically a terminal).  The foreign  host  will  have  a  Server

TELNET  process  which  acts  as a pseudo-Teletype, with incoming

network messages providing TTY input, and TTY output  being  sent

to  the  network.   The operating system treats the Server TELNET

pseudo-Teletype like an ordinary terminal.


     Most of  the  protocol  software  is  new  code,  the  major

exception  being  the  INP microcode which is supplied by Hewlett

Packard.   The  programs  will  be  written   in   HP's   Systems

Programming  Language  (SPL),  which  resembles PASCAL and allows

intermixing of assembly code and compiled code.  In  addition  to

new   code,  implementation  will  require  changes  to  the  MPE




                               -5-

IEN 167                                            Sax and Edmond
                                     Bolt Beranek and Newman Inc.
                                                        July 1980



operating system code, which is also written in SPL.


















































                               -6-

IEN 167                                            Sax and Edmond
                                     Bolt Beranek and Newman Inc.
                                                        July 1980



3  Current HP3000 Structure


     This section describes the HP3000 system with an emphasis on

the  features  that  affect  the  network  software  design.  The

description  includes  both  the  processor  hardware   and   the

operating   system.    Some  of  the  operating  system  features

described are not currently released by Hewlett Packard, but  are

about  to  be  released or are part of the planned MPE IV release

this fall.




3.1  Processor Features


     The HP3000 CPU is a medium speed machine which uses a  stack

architecture.   It  executes uncomplicated instructions in one to

two microseconds.  Code and data are separate and thus  all  code

is  re-entrant.   There  are  approximately 38 hardware registers

which make up the state of  the  processor,  most  of  which  are

associated  with  the  stack  (data)  and the current instruction

address (code).


     Memory is divided into segments.  A segment is a  contiguous

block   of  memory  of  any  desired  length  up  to  32K  words.

Individual segments are swapped in and out of memory  as  needed.

Memory  paging,  a  scheme which uses fixed size memory chunks as

the basis for memory swapping, is not  used  in  the  HP3000.   A




                               -7-

IEN 167                                            Sax and Edmond
                                     Bolt Beranek and Newman Inc.
                                                        July 1980



segment  may  be  designated  as  code  or  data by the operating

system.




3.2  Network Interface Hardware


     The interface unit  between  the  HP3000  computer  and  the

ARPANET  machines  will  be  HP's  Intelligent  Network Processor

(INP).  This device consists of two boards located in the  HP3000

main  cabinet.   It  is  a  microprogrammed  interface unit whose

microcode is down-line loaded by HP3000 software.  HP will supply

the microcode to make the INP obey the X.25 LAP protocol and will

supply the device driver necessary to access the INP.


     The INP will be connected to  a  BBN  C/30  (MBB)  computer.

This  machine  will  convert the X.25 protocols from the INP into

suitable ARPANET protocols.




3.3  Operating System Software


     The  operating  system  for  the  HP3000  is  known  as  the

Multiprogramming  Executive  System  (MPE).  It offers both batch

and interactive job capabilities and allows  multiple  concurrent

users  of  either  type.   It  offers a file system which manages

files on disk, magnetic tape  and/or  punched  cards.   Some  I/O

devices, such as the line printer, have spooler programs built in



                               -8-

IEN 167                                            Sax and Edmond
                                     Bolt Beranek and Newman Inc.
                                                        July 1980



to the system.


     User programs are run as processes within MPE.  Each process

has associated with it a code segment and a stack (data) segment.

In privileged mode, it may run in "split-stack mode", where it is

allowed  to  have  two  data  segments.   The  most common use of

split-stack mode is to access  tables  in  the  operating  system

during system calls.


     The design of  MPE  is  greatly  influenced  by  the  HP3000

hardware  architecture.   MPE's  organization  relies  heavily on

operations which incur little processor overhead  while  avoiding

operations  which incur large amounts of processor overhead.  The

most striking example of this is the  MPE's  dependence  on  user

processes  for  a  large  number  of  what  would  ordinarily  be

considered system functions.  MPE  avoids  the  use  of  "system"

processes to perform these functions.


     The design organization is a  direct  result  of  the  stack

architecture of the HP3000.  The large number of status registers

which must be saved when a new process is invoked  makes  process

switching a very expensive operation.  The time needed to perform

a procedure call into a new segment of system code  is  typically

less than the time to switch context from one process to another.

Writing  efficient  code  for  this  machine  has  thus  led   to

organizing   the   system  as  relatively  independent  "utility"



                               -9-

IEN 167                                            Sax and Edmond
                                     Bolt Beranek and Newman Inc.
                                                        July 1980



routines callable by the user rather  than  as  a  collection  of

separate processes which manage I/O devices and system utilities.

These operating system calls, called Intrinsics, are  implemented

as  subroutine  calls  into  system  code  segments.  The program

segments which implement the Intrinsics run in a privileged  mode

which allows them to directly access system tables and I/O device

tables.


     One notable  side-effect  of  this  design  is  that  system

resources  such  as  I/O  devices  are  assigned to only a single

program and are not normally shared.  This approach  has  allowed

the  system  programmers  to  create  a  complex operating system

without tackling the problems of interprocess  communication  and

resource  sharing.   As  will  be  discussed later, it also has a

significant effect on protocol software design.




3.4  Input/Output


     Input/Output operations typically consist of two steps.  The

first step is initiation of the desired operation.  This involves

checking to insure that access to the device is allowed (software

protection),  and  issuing  I/O  instructions  to  the  device to

initiate the desired action.   This  step  usually  occurs  as  a

result  of  an intrinsic call to the device handler code and thus

is executed  on  the  user's  stack.   The  second  step  is  the



                              -10-

IEN 167                                            Sax and Edmond
                                     Bolt Beranek and Newman Inc.
                                                        July 1980



operation  completion  handling.  This may occur using either the

Interrupt Control  Stack  (ICS)  or  the  System  Control  Stack,

neither  of which is the user's stack.  The choice of which stack

to use depends on the specific device's function.


     A consequence of this system design is  that  "system  code"

tends  to  be  executed  using  the  data stack of the first user

process needing the function.  If process 1 wants to  do  an  I/O

operation,  it  invokes  a  system  procedure  which knows how to

manage that I/O device.  If process 2 now wishes  to  invoke  the

same device, and if the device is capable of supporting more than

one request concurrently, it invokes the same routine.  To  avoid

multiprocessing  hazards  in  issuing  I/O  commands,  the system

procedure first checks to see if it is the  first  invocation  of

itself  --  if not, it queues the request and exits; if it is, it

proceeds to issue the  I/O  instructions.   If  the  request  was

queued,  it  is  assumed  that  the first process will detect the

newly queued request and process it also.  The first  process  is

thus  performing  system functions for the second, and all later,

processes, and will be charged run time for doing their work.  In

practice, we do not expect this to be significant, but in theory,

the first process could run indefinitely, even if its own request

has long since completed.







                              -11-

IEN 167                                            Sax and Edmond
                                     Bolt Beranek and Newman Inc.
                                                        July 1980



3.5  Interprocess Communication


     Interprocess communication under the current version of  MPE

is  a  problem.   Only two techniques are currently available and

neither of them is really satisfactory.


      One technique that may be  used  is  that  of  the  logical

device.   It  is  chiefly  used  to  accomplish  multiplexing  of

physical devices.  This facility is implemented by creating a new

entry in the system's Device Information Table, and by creating a

set of procedures which act as a  device  handler.   The  handler

will be run in privileged mode.


     Like other system device handlers, the procedures to  manage

the  device  are  invoked  directly  by the user process, and the

user's stack is used by the system code.  This has the  advantage

of speed, since it avoids some process context switching.


     There are a number of drawbacks to this  technique.   First,

the  Device  Information  Table entry must be maintained as if it

were a real hardware device.  This requires knowledge of all  the

MPE   internal   functions   that   might   access   this  table.

Furthermore, since these tables are  system  internal,  they  are

subject to change with each new release of MPE.  Use of the table

requires Privileged Mode.  Bugs in the code would have a  greater

chance  of  crashing  the  system.  The greatest drawback is that




                              -12-

IEN 167                                            Sax and Edmond
                                     Bolt Beranek and Newman Inc.
                                                        July 1980



logical devices are still under development at HP, and  are  more

than usually likely to change over time.


     A new operating system feature, not yet released officially,

that  has  been  written for MPE is an interprocess communication

method known at HP as message files.  These  correspond  to  Unix

ports,  and  allow  unrelated  processes  to communicate with one

another.  Each message file has one or  more  "reader"  processes

and  one or more "writer" processes.  During use, these files act

as FIFO queues.


     Message files are implemented using the file system.   Read,

write, and query commands are all patterned after the file system

commands.  The message file code is designed so that  if  readers

and  writers  stay more or less in synchronization, disk I/O will

not be needed.  However, if the writers get far enough  ahead  of

the  readers,  the message file will start being spooled out onto

disk.


     Message files are to be introduced as user  level  functions

by  HP, and, as such, their use will not change with new releases

of the operating system.  Code for this feature has already  been

implemented  at  HP  and  is  available with both MPE III and the

future MPE IV.  They appear to be relatively easy to use  and  do

not  require  knowledge of the internals of the operating system.

Their chief drawbacks  are  that  a  process  context  switch  is



                              -13-

IEN 167                                            Sax and Edmond
                                     Bolt Beranek and Newman Inc.
                                                        July 1980



required  between  writer  and  reader, and that some file system

overhead is incurred.


     Timeouts, as seen in  message  files,  are  another  new  HP

function  that  will be available.  The older version of timeouts

simply suspended the process for a fixed amount of time, but  did

not  allow the process to be awakened by the completion of an I/O

event during its sleep.  The new version is equivalent to setting

a timer whose alarm may be awaited with the same IOWAIT intrinsic

that awaits I/O completion.  It allows  a  process  to  wait  for

either  some  I/O  device  operation completion or the passage of

some  maximum   amount   of   time,   whichever   occurs   first.

Alternatively, a timeout could be used to insure that waiting for

a specific event will terminate if the expected event does  occur

soon  enough.   There will be both user level and system internal

ways of accomplishing timeouts.




3.6  Existing INP Software


     The  code  to  drive  the  INP  is  part  of   the   CS/3000

Communications  Software  package  from  HP.  It contains code to

send and receive packets via the INP and code to  manipulate  the

Device  Information  Tables.   The  code  also allows the user to

down-line load  microcode  into  the  INP  memory.   It  contains

intrinsics  to  open  and  close  the  line and to read and write



                              -14-

IEN 167                                            Sax and Edmond
                                     Bolt Beranek and Newman Inc.
                                                        July 1980



packets.  The microcode  allows  the  INP  to  support  X.25  LAP

protocols  and also allows the INP to buffer up to eight 128-byte

packets.  These packets are read by CS/3000 as soon  as  possible

in  order  to  keep  the INP from losing packets due to a lack of

buffer space in the  INP.   This  technique  allows  the  INP  to

function  as  a full duplex device, even though the MPE operating

system offers  only  a  half  duplex  control  mechanism  in  its

software.




































                              -15-

IEN 167                                            Sax and Edmond
                                     Bolt Beranek and Newman Inc.
                                                        July 1980



4  Protocol Software Architecture


     The protocol software architecture is dictated by a  set  of

design  requirements and MPE operating system constraints.  These

requirements and constraints are summarized as follows:


     - The  new  network  software  must  be  isolated  from  the

       existing  operating  system  as  much  as  possible.   The

       isolation will allow any site to add or remove the network

       software  with a minimum of effort.  It will also make the

       network software less vulnerable to any changes  HP  makes

       to MPE.


     - Efficient high speed network communications are  extremely

       important  because  this  TCP  version  will  be used on a

       production rather than an experimental basis.


     -_One of the problems with MPE is that, though the operating

       system  performs  device assignment and access control for

       its I/O devices,  the  user  process  is  responsible  for

       operating  the  I/O  device.  MPE does offer intrinsics to

       operate common devices,  but  these  are  very  low  level

       operations.   This  I/O  arrangement makes it difficult to

       control an asynchronous network interface.   The  protocol

       software  architecture will therefore require at least one

       process which has exclusive control of the INP interface.




                              -16-

IEN 167                                            Sax and Edmond
                                     Bolt Beranek and Newman Inc.
                                                        July 1980



     - One of the properties of these network protocols  is  that

       the message acknowledgments and retransmissions occur at a

       relatively high  level  --  in  the  Transmission  Control

       Protocol  in layer four.  A moderate amount of time passes

       from the time the originating TCP queues the  message  for

       transmission  and  the receiving TCP gets the message.  In

       order to prevent acknowledgment delays which in turn cause

       the   foreign   host  to  retransmit  data,  the  software

       architecture should minimize the amount of time  it  takes

       for  incoming  data  to move through the 1822, IP, and TCP

       protocols.


     - With many network users and many connections  concurrently

       in  use,  the  network software must be able to handle the

       problems of multiplexing  use  of  the  network  interface

       hardware.   The  interface on which the multiplexing takes

       place must support a number of simultaneous users in  such

       a  way  that  the behavior of any individual user does not

       affect data throughput of the other users.


     In  order  to  meet  all  of  the  design  requirements  and

constraints  described  above,  the  HP3000  protocol software is

implemented in a set of processes (see diagram  in  Appendix  B).

One  process  which will be called the system protocol process is

responsible  for  maintaining  the  INP  interface  as  well   as




                              -17-

IEN 167                                            Sax and Edmond
                                     Bolt Beranek and Newman Inc.
                                                        July 1980



supporting  the  1822,  IP  and  TCP  protocols.  The rest of the

processes, called applications protocol processes,  support   the

user interactive network functions including FTP and TELNET.


     The use of a single system protocol process is a key element

in  the  protocol  design.   The system protocol process provides

control over the INP interface by providing buffers and acting as

multiplexer and de-multiplexer of network traffic to and from the

INP.  Use of a  single  process  minimizes  inter-protocol  layer

communication  delays  which  in turn minimize the acknowledgment

delays for incoming data.  A single system protocol process makes

it  possible  to  use  interprocess  communication  primitives to

provide a uniform network interface for  the  applications  level

protocol processes.


     User TELNET and User FTP protocols are to be implemented  as

ordinary  user  programs.   They use the same system calls as any

other network accessing program, but are  written  to  provide  a

higher  level  command  language for the user.  As user programs,

they execute in the user's  address  space  with  the  privileges

normally  available  to  the  user.  The User TELNET and User FTP

programs are re-entrant, with as many processes running this code

as users wishing the service.


     Server TELNET is a single  process  created  as  the  system

starts  up  or  whenever  the  first  need  for  it  arises.  De-



                              -18-

IEN 167                                            Sax and Edmond
                                     Bolt Beranek and Newman Inc.
                                                        July 1980



multiplexing of  Server  TELNET  inputs  is  accomplished  via  a

pseudo-teletype driver.  The driver acts as the interface between

the Server TELNET process and the Teletype handler.


     The interface between application protocol processes and the

system  protocol process is through a set of TCP intrinsics.  The

intrinsics are designed to form a uniform interface  between  the

user  and  the  TCP.   Actual  data  communication between a user

process  and  the  system  protocol  process  is  done   with   a

combination   of   message   files  and  direct  buffer-to-buffer

transfers.   Message  files  are  used  to  pass   flow   control

information  while  the  actual  data transfer is made by copying

data between user  buffers  and  system  protocol  buffers.   The

combination  of  message  files  and  buffer copy is used to take

advantage of the flexibility of message files and the data  rates

achieved by direct data copy.





















                              -19-

IEN 167                                            Sax and Edmond
                                     Bolt Beranek and Newman Inc.
                                                        July 1980



5  System Protocol Software


     Since this TCP implementation is to be used on a  production

rather   than  an  experimental  basis,  the  design  effort  has

concentrated on the efficiency rather than the sophistication  of

the  protocol  software.   This  is especially true of the system

protocol  software  whose  initial  design  includes  only  those

features needed to support the FTP and TELNET protocols.


     At the same time,  the software design does  allow  for  the

future  enhancement  of  the  protocol  software.   There  are no

inherent design limitations which will prevent implementation  of

the more sophisticated TCP and Internet features.




5.1  Implemented Features


     The specific TCP and Internet  features  to  be  implemented

include the following:


















                              -20-

IEN 167                                            Sax and Edmond
                                     Bolt Beranek and Newman Inc.
                                                        July 1980



     - multiple connections to multiple hosts,

     - flow control at the 1822, Internet, and TCP layers,

     - error recovery,

     - fair allocation of resources among all connections,

     - handling of urgent data,

     - surviving incorrect packets,

     - datagram reassembly,

     - routing,

     - source quenching.




5.2  Software Architecture Overview


     The system protocol software architecture reflects the  need

to  avoid packet processing delays rather than a strict hierarchy

between  protocol  layers.   The  system  protocol  software   is

implemented  as  a  single  process  to allow the system protocol

layers to share software resources for greater  efficiency.   The

shared  resources  include  subroutines  which  perform functions

required by more than one protocol layer and a common buffer pool

to   optimize   storage   resources   and   to   allow  efficient

communication between protocol layers.


     Network traffic through the system  protocol  process  takes

different  forms  including  1822  packets,  datagrams,  and  TCP

segments.  These various forms are  generically  referred  to  as



                              -21-

IEN 167                                            Sax and Edmond
                                     Bolt Beranek and Newman Inc.
                                                        July 1980



"packets".   Packets  are passed into the system protocol process

from either an  applications  protocol  process  or  the  ARPANET

interface.   Packets  from the ARPANET are passed into the system

protocol process by intrinsic calls to the INP  interface.   User

generated  network  packets  are  passed  to  the system protocol

process by using a combination of message files and data buffers.

Message files are used to transfer control and status information

while data transfer is done with buffer-to-buffer copies  between

the  user  protocol  data  segment  and  the system protocol data

segment.


     All read and write commands are done without wait  to  allow

the  system  protocol  process  to  simultaneously  multiplex I/O

channels  and  process  network  packets.   I/O  multiplexing  is

implemented  through  the  IOWAIT intrinsic.  The system protocol

process issues an IOWAIT intrinsic after it finishes processing a

data packet.  The IOWAIT intrinsic returns the file number of the

I/O channel associated with an I/O completion wakeup.


     When the number of free buffers  falls  below  a  prescribed

limit,   an   attempt  is  made  to  free  buffers  through  data

compaction.  The  attempt  begins  with  a  search  for  datagram

fragments  and  unacknowledged  TCP  segments  which waste buffer

space by using only a fraction of the  available  space  in  each

buffer  assigned  to  them.   This  lack  of  efficiency  can  be




                              -22-

IEN 167                                            Sax and Edmond
                                     Bolt Beranek and Newman Inc.
                                                        July 1980



particularly damaging because there is no guarantee that the data

contained  in  the  buffers  will  ever  be  processed.  Wherever

possible, datagram fragments are combined into a single  datagram

fragment  and  TCP segments are combined into a single segment to

more efficiently utilize system buffers.  Any  buffers  freed  by

this compaction process are returned to the freelist.


     Network packets from both the user process and  the  ARPANET

are  processed  along one of a number of data paths in the system

protocol process.  The actual data path taken depends on the type

of data packet and, in the case of TCP segments, the state of its

associated network connection.  Packet processing is performed by

a  series  of  function calls which act as processing steps along

the data path.


     In order to avoid processing delays which can tie up  system

resources, each arriving data packet is processed through as much

of the protocol software as possible.  Processing of a packet  is

suspended  only  when  the lack of some resource or some external

event prevents further processing.




5.3  Control Structures


     All of the status information both  for  individual  network

connections  and  for  the system protocol software as a whole is




                              -23-

IEN 167                                            Sax and Edmond
                                     Bolt Beranek and Newman Inc.
                                                        July 1980



kept in a set of control blocks as well as in a number of  buffer

list  structures  as  shown  in  Appendix  C.  The control blocks

include a general network resources control block, a foreign host

control  block for each foreign host connected to the local host,

and send and receive control blocks for network connection.   The

list  structures include a network buffer free list, a TCP buffer

aging list and an Internet buffer aging list.




5.3.1  Network Resources Control Block


     The Network Resources Control Block contains the information

needed to maintain the network buffer free lists and aging lists.

This information includes pointers to  the  network  buffer  free

lists  and  aging lists and a count of the buffers in each of the

lists.


     The information contained in the Network  Resources  Control

Block   is   used   by  the  protocol  software  to  control  the

distribution of network buffers among  the  various  lists.   The

information   is  scanned  at  various  times  to  determine  the

allocation or disposition of a particular  network  buffer.   The

determinations occur when new buffers are allocated from the free

list and when buffers containing TCP segments  are  about  to  be

acknowledged.   Decisions  are  made  based on the number of free

buffers available and the priority  of  the  task  requiring  the



                              -24-

IEN 167                                            Sax and Edmond
                                     Bolt Beranek and Newman Inc.
                                                        July 1980



buffers.




5.3.2  Foreign Host Control Blocks


     Foreign Host Control Blocks maintain flow control within the

1822 protocol layer.  The block contains a counter for the number

of outstanding 1822 packets sent to a single host.   The  counter

includes all of the packets sent to the host on all sockets.  The

counter is incremented  when  an  1822  packet  is  sent  and  is

decremented  when  either a RFNM or an Incomplete Transmission is

received from the host.


     The counter is used to prevent transmission of too many 1822

packets  to  a  single  host.   All transmission from the host is

blocked when the counter reaches the limit of  eight  outstanding

1822 packets for any foreign host.


     The 1822 level flow control is actually implemented  by  the

send  side of the TCP software.  The TCP checks the RFNM count in

the connection control  block  before  it  tries  to  transmit  a

segment to the foreign host.












                              -25-

IEN 167                                            Sax and Edmond
                                     Bolt Beranek and Newman Inc.
                                                        July 1980



5.3.3  Connection Control Block


     Each TCP connection has an associated  control  block.   The

control  block  contains  data  associated  with the Transmission

Control  Block  (TCB)  along  with   other   connection   related

information.   Specific information included in the control block

is as follows:

     - a  connection  state  variable  used   to   maintain   the
       connection state,

     - the local port number of the connection,

     - the TCP interface control  block  number  associated  with
       this connection,

     - the file number of the  private  message  file  associated
       with this connection,

     - the TCB data associated with  the  receive  side  of  this
       connection,

     - the TCB  data  associated  with  the  send  side  of  this
       connection,

     - A pointer to any buffers  containing  unacknowledged  data
       received on this connection.



5.3.4  Network Buffer Resources List Structures


     Three list structures  are  used  to  maintain  the  network

buffer  resources  shared  by  all  of  the  sockets.  These list

structures include the free list and the two buffer aging queues.


     The network buffer free list contains  all  of  the  network

buffers currently available for use by any socket.  These buffers



                              -26-

IEN 167                                            Sax and Edmond
                                     Bolt Beranek and Newman Inc.
                                                        July 1980



are allocated when new data comes in from either the network or a

user protocol process.


     The Internet  Aging  Queue  is  a  list  of  active  buffers

assigned  to  blocked  datagram fragments and complete datagrams.

These buffers are the first to be reclaimed  when  there  are  no

free  buffers  available.   The  Queue  is  sorted  according  to

datagram age.  All buffers which belong to the same datagram  are

combined  into  a  single  list  structure.   The  datagram  list

structures are linked into the  Internet  Aging  Queue  with  the

least  recently updated datagram always at the head of the queue.

When a new datagram fragment comes in it is moved to the  end  of

the  queue  along with all of the other fragments which belong to

the same datagram.


     The TCP Aging Queue is a list of buffers  which  contain  at

least parts of unacknowledged TCP segments.  These buffers can be

reclaimed when there are no free buffers and no  buffers  on  the

Internet aging list.  The Queue is sorted by socket.  All buffers

which contain data for the same socket are combined in  a  buffer

list and each buffer list is linked into the queue.  The queue is

sorted by the age of the data associated with each socket.   Data

belonging  to  the socket which has been inactive for the longest

period of time is placed at the head of the queue so  it  can  be

recycled   first.    When  a  user  process  reads  data  from  a




                              -27-

IEN 167                                            Sax and Edmond
                                     Bolt Beranek and Newman Inc.
                                                        July 1980



connection, all the network buffers still waiting to be  read  on

that connection are moved to the end of the TCP aging list.  This

assures that data associated with an active TCP  connection  will

not  be  recycled  ahead  of data associated with an inactive TCP

connection.










































                              -28-

IEN 167                                            Sax and Edmond
                                     Bolt Beranek and Newman Inc.
                                                        July 1980



6  User Process/TCP Interface


     The user process/TCP interface is designed to meet two basic

requirements.   First,  the  interface  must allow for high speed

data  transmission  across  the  interface;  this  is  especially

important    since    this    interface   involves   interprocess

communication which could be delayed by excessive system overhead

due  to  context  switching  and process scheduling.  Second, the

interface must isolate  the  system  protocol  process  from  any

buffer  overhead  burdens caused by processing delays in the user

process.  System protocol process  buffers  are  too  valuable  a

resource to be locked into storing TCP segments which are waiting

for response from a user process.


     High speed data transmission  across  tser  process/TCP

interface  is  achieved  by copying data directly from buffers in

the user process to buffers in the system protocol process.   The

direct  transfer is implemented with the move-to-data-segment and

move-from-data-segment instructions provided by the HP3000.


     The system protocol process is isolated from delays  in  the

user process by making the user process responsible for buffering

TCP data segments.  Acknowledged incoming TCP segments,  and  TCP

segments  waiting  to be transmitted over the ARPANET, are stored

in buffers in the  user  protocol  process.   This  use  of  user

buffers  serves  two functions:  it frees system protocol buffers



                              -29-

IEN 167                                            Sax and Edmond
                                     Bolt Beranek and Newman Inc.
                                                        July 1980



from being locked into storing TCP segments, and also  gives  the

user  process  some  control  of  network  connection throughput.

Throughput control is accomplished by allowing each user  process

to  choose  the  amount  of buffer resources it dedicates to each

connection.




6.1  Interface Intrinsics


     The TCP/user interface is implemented through a set  of  TCP

intrinsics.   These  intrinsics  allow the user process to create

and use network  connections  with  other  processes  on  foreign

hosts.


     Seven intrinsics, TCPWAIT,  TCPOPEN,  TCPCLOSE,  TCPRECEIVE,

TCPSEND,   TCPSTAT,  and  TCPABORT,  provide  the  basic  control

functions needed to transfer data through  the  user  process/TCP

interface.  Conceptually, the intrinsics allow the user to create

network connections with other processes on foreign hosts.   Each

connection  consists  of  a pair of sockets as defined in the TCP

protocol  document.   Connections  are  created  with  a  TCPOPEN

intrinsic  whose  parameters define the sockets which make up the

connection.  After a connection is created, the user process uses

the  TCPSEND  and  TCPRECEIVE intrinsics to send or receive data.

The TCPSTAT intrinsic allows the user to check the  status  of  a

connection.



                              -30-

IEN 167                                            Sax and Edmond
                                     Bolt Beranek and Newman Inc.
                                                        July 1980



     Within the user process, connections are identified  through

the  combination  of  a  connection  file number and a connection

buffer.  The connection file number is returned by  a  successful

TCPOPEN   call.   The  connection  buffer  is  an  integer  array

allocated by the user process.  The buffer is initialized by  the

TCPOPEN  intrinsic  and  is then passed as the first parameter to

all of the other TCP intrinsics.  It is the responsibility of the

user  process  to maintain the association between the connection

file number and the connection buffer.


     The TCP I/O interface is entirely  asynchronous  so  that  a

user  process can queue any number of read or write requests to a

particular connection.  The user process has three limitations in

this  regard:  first, it must provide the buffers associated with

each TCP intrinsic call; second, the user process must keep track

of  which  buffers  are associated with each I/O call; and third,

the user process cannot dequeue buffers until it  has  permission

to do so from the system protocol process.


     The user process uses a combination of the  IOWAIT  ane

TCPWAIT  intrinsic  calls to keep track of I/O completion events.

The IOWAIT  intrinsic  is  invoked  when  the  user  process  has

completed  processing  all  of the current data.  When the IOWAIT

intrinsic returns with  a  file  number  associated  with  a  TCP

connection,  the  TCPWAIT  intrinsic  is called to handle the I/O




                              -31-

IEN 167                                            Sax and Edmond
                                     Bolt Beranek and Newman Inc.
                                                        July 1980



completion.  The TCPWAIT intrinsic uses the connection buffer  to

determine  the  cause of the I/O completion and then performs the

appropriate I/O cleanup task and returns an I/O type code to  the

user process.


     The specific calling sequences of  the  TCP  intrinsics  are

given below:


TCPOPEN(TCPCBUF,FHIA,FP,A/P,LP[,BADDR]) opens a TCP connection


   TCPCBUF - TCP Connection Buffer - This  is  a  pointer  to  an

             integer  array  ten  elements long which acts as the

             control structure for all network connections.   The

             array  is  allocated  by the user process before any

             TCP intrinsics are called.


   FHIA    - Foreign Host Internet  Address  -  32  bit  address.

             This  address  may  be  obtained  with  the HOSTADDR

             intrinsic which takes the host name text string as a

             parameter  and  returns the 32 bit internet address.

             In the  case  of  a  passive  open  a  zero  address

             indicates a listen for any host.


   FP      - Foreign Port -  a  16  bit  port  address  for  this

             connection  at  the  foreign host.  In the case of a

             passive open a 0 port indicates a  listen  from  any

             port on a foreign host.



                              -32-

IEN 167                                            Sax and Edmond
                                     Bolt Beranek and Newman Inc.
                                                        July 1980



   A/P     - Active/Passive - a boolean flag used to indicate  if

             this open is for a listen socket (passive) or for an

             active connection.


   LP      - Local Port - 16 bit local port id.   This  parameter

             is  optional.  If it is not specified, the TCP picks

             a free local port id from a  reserved  part  of  the

             name space.


   BADDR   - Buffer Address - an optional buffer used to give the

             foreign  host  a  window  for  transmission.  If the

             buffer is not provided,  the  connection  is  opened

             with a zero window size until the user process calls

             the TCPRECEIVE intrinsic.


   returns - local connection name or error code  of  -1  if  the

             connection  failed.   The  local  connection name is

             actually the file number of the private message file

             associated with this connection.


TCPCLOSE(TCPCBUF) closes a TCP connection


   TCPCBUF - TCP Connection Buffer  -  same  as  in  the  TCPOPEN

             intrinsic.


TCPABORT(TCPBUF,BUFPTR) aborts a TCP connection


   TCPCBUF - TCP Connection Buffer  -  same  as  in  the  TCPOPEN



                              -33-

IEN 167                                            Sax and Edmond
                                     Bolt Beranek and Newman Inc.
                                                        July 1980



             intrinsic.


   BUFPTR  - Buffer Pointer  -  pointer  to  a  list  of  buffers

             released   by  the  TCPABORT  call.   A  zero  value

             indicates that no buffers were released.


TCPRECEIVE(TCPCBUF,BADDR,BCNT) reads data from a TCP connection


   TCPCBUF - TCP Connection Buffer  -  same  as  in  the  TCPOPEN

             intrinsic.


   BADDR   - Buffer Address - address of user buffer for  receiv-

             ing network data.


   BCNT    - Byte Count - number of bytes to be transferred.


   returns - an error code of -1 if the TCPRECEIVE failed.


TCPSEND(TCPCBUF,BADDR,BCNT,EOL) writes data to a TCP connection


   TCPCBUF - TCP Connection Buffer  -  same  as  in  the  TCPOPEN

             intrinsic.


   BADDR   - Buffer Address - address of user buffer for  sending

             network data.


   BCNT    - Byte Count - number of bytes to be transferred.


   EOL     - End Of Letter - a boolean flag to indicate that this

             buffer is an end of letter.



                              -34-

IEN 167                                            Sax and Edmond
                                     Bolt Beranek and Newman Inc.
                                                        July 1980



TCPSTAT(TCPCBUF,SBADDR) gives TCP connection status


   TCPCBUF - TCP Connection Buffer  -  same  as  in  the  TCPOPEN

             intrinsic.


   SBADDR  - Status Buffer Address - address of user  buffer  for

             receiving network data.


TCPWAIT(TCPCBUF,BUFPTR,DATAPTR) returns the result of a  previous

TCP intrinsic call.


   TCPCBUF - TCP Connection Buffer  -  Same  as  in  the  TCPOPEN

             intrinsic.


   BUFPTR  - Buffer Pointer - used  to  return  a  pointer  to  a

             buffer  list  released  by  an  I/O  event.   A zero

             pointer indicates that no buffers were released.


   DATAPTR - Data Pointer - pointer to  the  first  data  element

             within  a  buffer  returned  by  the  intrinsic to a

             TCPRECEIVE intrinsic.


   returns - a code indicating the type of I/O completed.  A list

             of the I/O codes is given in Appendix D.











                              -35-

IEN 167                                            Sax and Edmond
                                     Bolt Beranek and Newman Inc.
                                                        July 1980



6.2  Flow Control Across the Interface


     Flow  control  across  the  user  process/TCP  interface  is

implemented  through the use of message files.  The message files

act as control channels  to  transmit  flow  control  and  status

messages  between  the user process and the TCP.  Each connection

makes use of two message files.  A general input message file  is

used to transmit control messages from user processes to the TCP.

All user processes share the same  general  input  message  file.

Each  connection  also  uses  a  private  message  file to convey

control and status information from the system  protocol  process

to the user process.


     The control messages passed between the user process and the

system  protocol  process  are short data buffers.  These buffers

contain the message type along with other information  associated

with the particular command.  The formats for each of the message

types is shown in Appendix D.




6.3  Interface Control Structures


     Each network connection  has  an  associated  TCP  interface

control  block.   These blocks include a set of pointers and data

segment numbers used to keep track of  buffers  within  both  the

user  process  and  the  system  protocol  process.  The pointers




                              -36-

IEN 167                                            Sax and Edmond
                                     Bolt Beranek and Newman Inc.
                                                        July 1980



contain buffer addresses relative to the beginning of  the  stack

data  segment  for  each process.  A diagram of the TCP interface

control block is given in Appendix E.


     The control blocks are maintained in a separate data segment

shared  by both the user and system protocol processes.  The data

segment is initialized by the system  protocol  process  when  it

starts  up.   The  initialization  of the data segment divides it

into a number of control blocks.  Individual control  blocks  are

initialized   by   the   TCPOPEN  intrinsic.  Responsibility  for

releasing the  control  blocks  is  shared  among  the  TCPCLOSE,

TCPABORT, and TCPWAIT intrinsics.




6.4  Interface Control Algorithms


     The specific functions performed by each of the network  I/O

intrinsics are as follows:


     TCPOPEN


     1.  The TCPOPEN intrinsic software searches for a  free  TCP

         connection interface control block and initializes it.


     2.  The TCPOPEN software creates a private message file with

         a  unique file name.  The unique file name is formed out

         of the prefix  "TCP"  and  the  id  number  of  the  TCP




                              -37-

IEN 167                                            Sax and Edmond
                                     Bolt Beranek and Newman Inc.
                                                        July 1980



         interface control block.


     3.  The TCPOPEN software sends an  OPEN  CONNECTION  command

         message  to  the TCP via the general input message file.

         The message includes all of the TCPOPEN  parameters  and

         the id number of the TCP interface control block.


     4.  The TCPOPEN software makes a read request  with  timeout

         on the private message file.  If the read times out, the

         TCPOPEN software sends an ABORT  CONNECTION  command  to

         the  TCP,  deletes  the TCP interface control block, and

         returns  an  error  code  to  the  user  process.    The

         connection  buffer provided as a parameter to TCPOPEN is

         used as the read buffer.


     5.  The TCP software reads the open command from the general

         input  message file and uses the information to create a

         connection  control  block.   The  TCP   software   also

         initiates  the  connection  protocols  specified  in the

         command message.


     6.  The TCP software sends an OPEN CONFIRM message  back  to

         the user process via the private message file created by

         the  TCPOPEN  intrinsic  software.   The  OPEN   CONFIRM

         message  will fail if the user process is destroyed by a

         user abort.  If this  occurs,  the  TCP  software  takes




                              -38-

IEN 167                                            Sax and Edmond
                                     Bolt Beranek and Newman Inc.
                                                        July 1980



         responsibility for cleaning up the TCP interface control

         block as well the connection control blocks.


     7.  The TCPOPEN software reads the OPEN CONFIRM message from

         the   private   message   file.   The  TCPOPEN  software

         initiates a read without wait  on  the  private  message

         file.   The  connection buffer is again used as the read

         buffer.


     8.  If the user provides a read buffer as the last parameter

         to the TCPOPEN intrinsic, a read operation is initiated.

         The TCPOPEN software attaches  the  buffer  to  the  TCP

         interface  control structure and sends a RECEIVE message

         to the TCP via the general input message file.  The  TCP

         uses  this  message  to  set  the size of the connection

         window.


     9.  The TCPOPEN software returns  the  file  number  of  the

         private message file to the user process.


     TCPCLOSE


     1.  The TCPCLOSE software marks the  connection  closed  bit

         for  the  send  side in the TCP interface control block.

         The TCPCLOSE software checks to see  if  there  are  any

         data  buffers  waiting  to be read by the TCP.  If there

         are no data buffers, the TCPCLOSE software sends a CLOSE



                              -39-

IEN 167                                            Sax and Edmond
                                     Bolt Beranek and Newman Inc.
                                                        July 1980



         CONNECTION  command  to the TCP.  If the receive side is

         marked closed and there are no  buffers  waiting  to  be

         read,   the  TCPCLOSE intrinsic software deletes the TCP

         interface connection control block.


     2.  The TCPCLOSE software returns to the user process.


     3.  When the TCP receives a connection  close  command  from

         the  user process it sends a FIN to the foreign host and

         marks the send side  of  the  connection  as  FINWAIT-1.

         When  the  TCP  receives an ACK of the close the foreign

         host, it marks  the  send  side  of  the  connection  as

         FINWAIT-2.   If  the  receive  side of the connection is

         marked closed, the TCP deletes  the  connection  control

         block.


     4.  If the TCP receives a FIN  from  the  foreign  host,  it

         marks  the  receive  side  of its connection as closing.

         When all data and the FIN sent by the foreign  host  are

         ACKED,  the  TCP  sends  a  NETCLOSE command to the user

         process and marks the receive  side  of  the  connection

         closed.   If the send side is also marked as closed, the

         TCP deletes the connection  control  block.   The  close

         message  sent  to  the  user process is processed by the

         TCPWAIT intrinsic.





                              -40-

IEN 167                                            Sax and Edmond
                                     Bolt Beranek and Newman Inc.
                                                        July 1980



     TCPABORT


     1.  The TCPABORT software sends an ABORT CONNECTION  command

         to  the  TCP  via  the  general input command file.  The

         TCPABORT software releases  the  TCP  interface  control

         block and deletes the connection's private message file.


     2.  The TCPABORT software returns to the user process.   The

         return  includes  a  pointer  to  a list of user buffers

         which were assigned to the connection.


     3.  When the TCP receives an ABORT CONNECTION  command  from

         the  user  process it sends a reset to the foreign host,

         deletes  any  unacknowledged  data  it  has   for   this

         connection, and deletes the connection control block.


     4.  If the TCP receives a reset from the  foreign  host,  it

         deletes all of the data waiting to be transmitted to the

         user process and sends a NETABORT message  to  the  user

         process  via  the  private  message  file.  The NETABORT

         message is handled by the TCPWAIT intrinsic.


     TCPRECEIVE


     1.  The TCPRECEIVE software checks to  see  if  the  receive

         side connection closed flag is set.  If the flag is set,

         the TCPRECEIVE  software  returns  a  connection  closed




                              -41-

IEN 167                                            Sax and Edmond
                                     Bolt Beranek and Newman Inc.
                                                        July 1980



         indication  to  the  user process.  It is up to the user

         process to close the send side  of  the  connection  and

         clean up the connection buffer if it has not done so.


     2.  If the  connection  is  open,  the  TCPRECEIVE  software

         attaches  its  read  buffer to the TCP interface control

         block and sends a  RECEIVE  message  to  the  TCP.   The

         message is used to indicate to the TCP that the user has

         made  a  buffer  available  to  the   connection.    The

         TCPRECEIVE software returns to the user process.


     3.  When the TCP receives the user's read message, it checks

         to  see if it has any unacknowledged segments waiting to

         be transferred to  the  user  process.   If  it  has  no

         segments,  it  uses  the RECEIVE message to increase its

         receive window size.  If the TCP  has  segments  waiting

         for  transfer,  it  transfers  as  much  of  the data as

         possible to the user process.  All transferred  data  is

         immediately  acknowledged  to the foreign host.  The TCP

         sends a PENDING RECEIVE message to the user  process  to

         advise  it  of  the  transfer  of data.  This message is

         processed by the TCPWAIT intrinsic.


     4.  If the TCP receives  data  from  the  foreign  host,  it

         checks  to see if the user process has assigned any free

         buffers to this connection.  If there are free  buffers,



                              -42-

IEN 167                                            Sax and Edmond
                                     Bolt Beranek and Newman Inc.
                                                        July 1980



         the  TCP  copies  as  much  of  the  data it receives as

         possible into the  user  buffers  and  acknowledges  the

         copied  data to the foreign host.  Any data which is not

         copied is maintained on the TCP aging list where  it  is

         stored  until it is transferred to a user process buffer

         or discarded.  The user process is informed of the  data

         transfer  through  a PENDING RECEIVE command message via

         the private message file.  This message is  received  by

         the TCPWAIT intrinsic.


     TCPSEND


     1.  The TCPSEND intrinsic checks to see if the connection is

         still  open.   If  the  connection is marked closed, the

         TCPSEND returns an error code to the user.


     2.  If the connection is still open, the intrinsic  software

         attaches  the  user  supplied  data  buffer  to  the TCP

         interface control block.  The TCPSEND software  sends  a

         SEND  message  to  the TCP via the general input message

         file.  The TCPSEND software  now  returns  to  the  user

         process.


     3.  The TCP software, on receiving the  data  SEND  message,

         checks  to  see  if  it can send the data to the foreign

         host.  The decision on whether to send the data is  made




                              -43-

IEN 167                                            Sax and Edmond
                                     Bolt Beranek and Newman Inc.
                                                        July 1980



         by checking the following conditions:


            - the foreign host has advertised  sufficient  window
              space,

            - the number of outstanding RFNMs for all connections
              to the foreign host is less than eight,

            - the amount of data waiting to be sent is sufficient
              to  warrant a data packet.  This condition prevents
              single byte segments from being sent out  over  the
              ARPANET.   The  TCP  waits until it has at least 10
              bytes of data before transmitting  it  out  to  the
              ARPANET.

            - the user has specified an EOL.


         If the TCP decides to  send  the  data,  it  prepares  a

         network packet and copies as much of the user data as it

         can transmit into the network packet.  The data transfer

         is made directly from the list of user buffers queued by

         the TCPSEND intrinsic to the message packet buffer.  All

         buffers filled by the data transfer are marked as filled

         and appended to the filled buffer list.


     4.  After the TCP has transferred all of the data  from  the

         user buffers, it checks the TCP interface control block.

         If the send side of the connection is marked closed, the

         TCP  sends  a  Fin  to the foreign host.  If the receive

         side is also closed, the TCP sends a  NETCLOSED  command

         to the user process.


     5.  After  the  data  is  transmitted,  the   TCP   sets   a



                              -44-

IEN 167                                            Sax and Edmond
                                     Bolt Beranek and Newman Inc.
                                                        July 1980



         retransmission timer.


     6.  If the TCP receives an acknowledgment from  the  foreign

         host,  it  updates  the  TCP  interface control block to

         reflect the acknowledgment, turns  off  the  timer,  and

         sends  a  DATA  SENT  message  to the user process via a

         connection private message file.  The  message  contains

         the  number  of  bytes  acknowledged.   This  message is

         processed by the TCPWAIT command.  If only some  of  the

         data  is  acknowledged, the TCP resets the timer for the

         unacknowledged data.


     7.  If the TCP does  not  get  an  acknowledgment  from  the

         foreign  host  and  the  connection  times out, it again

         reads as much data as it can from the  user  buffer  and

         sends it out as a network packet.


     TCPSTATUS


     1.  The TCPSTATUS software checks to see if  the  connection

         is still open.  If it is closed, it returns a connection

         closed code to the user process.


     2.  The TCPSTATUS command checks to see if there is an  out-

         standing  status  request by the user process.  If there

         is, it returns an error code to the user process.





                              -45-

IEN 167                                            Sax and Edmond
                                     Bolt Beranek and Newman Inc.
                                                        July 1980



     3.  If there is no pending  status  request,  the  TCPSTATUS

         software  attaches  the status request buffer to the TCP

         interface control block and sends a  STATUS  message  to

         the  TCP  via  the  general  input  message  file.   The

         TCPSTATUS returns to the user process.


     4.  When the TCP receives the status  request   message,  it

         formulates  a  status  message  and  copies  it into the

         user's status buffer attached to the connection  buffer.

         The TCP then sends a status complete message to the user

         process via the connection private  message  file.   The

         message  from  the  TCP  is  processed  by  the  TCPWAIT

         intrinsic.


     TCPWAIT


     1.  The TCPWAIT software checks the  message  received  from

         the TCP.


     2.  If the  message  is  a  NETCLOSE  command,  the  TCPWAIT

         software  checks  if  the send side of the connection is

         closed and there is no data waiting to be  sent  to  the

         TCP.  If the send side is closed and there is no pending

         TCP data, the TCPWAIT software deletes the TCP interface

         control   block.    If  there  is  data  waiting  to  be

         transmitted, the TCPWAIT software marks the receive side




                              -46-

IEN 167                                            Sax and Edmond
                                     Bolt Beranek and Newman Inc.
                                                        July 1980



         of  the  connection  closed.   In  either  case, TCPWAIT

         returns a connection closed code to  the  user  process.

         It is up to the user process to decide when to close the

         send side of the connection, if it has not already  done

         so.   If  there  are  any user buffers still assigned to

         this connection, they are returned to the  user  process

         at this time.


     3.  If  the  message  is  a  NETABORT  command  the  TCPWAIT

         software  deletes  the  TCP  interface control block and

         returns a connection abort code  to  the  user  process.

         Any buffers associated with connection are also returned

         in  a  list  structure  through   the   buffer   pointer

         parameter.


     4.  If the message is a PENDING RECEIVE command, the TCPWAIT

         returns  the  pointer  to  the  head  of  the first data

         buffer, the first data byte, and a  byte  count.   Since

         the  data may be returned in a number of linked buffers,

         it is up to the user to follow the buffer links.  As the

         user  process  reads  the  data  it  should  check  each

         buffer's header.  Completely filled buffers marked  with

         a  zero in the in use field can be reclaimed by the user

         process.


     5.  If the  message  is  a  DATASENT  message,  the  TCPWAIT



                              -47-

IEN 167                                            Sax and Edmond
                                     Bolt Beranek and Newman Inc.
                                                        July 1980



         software checks the acknowledgment count and releases as

         many buffers as it can from the send buffer  list.   The

         released  buffers  are  linked  in a list and the buffer

         pointer parameter is set to point to the first buffer in

         the   list.    The   TCPWAIT  software  returns  a  data

         acknowledgment code to the user process.


     6.  If the message is a STATUS COMPLETE message, the TCPWAIT

         software  sets  the buffer pointer parameter to point to

         the status buffer and returns a status complete  command

         code to the user process.




6.5  Windowing, Acknowledgment, and Retransmission


     The receive window size and data segment acknowledgment  are

completely  dependent  on  the number of buffers the user process

allocates  to  a  connection.  The  receive  window  size  of   a

connection  is  always set to the amount of free buffer space the

user process allocates to  the  receive  side  of  a  connection.

Acknowledgments  of  incoming  TCP  segments are limited to those

sequence   numbers   which   fit   in   the    receive    window.

Acknowledgments  are  sent  as  soon  as  data is copied from the

system protocol buffers to the user protocol buffers.







                              -48-

IEN 167                                            Sax and Edmond
                                     Bolt Beranek and Newman Inc.
                                                        July 1980



     The initial retransmission algorithm  is  extremely  simple.

The  first retransmission of unacknowledged data occurs 3 seconds

after  the  original  transmission.   The  second  retransmission

occurs  6  seconds  after  the  first.   The third and successive

retransmissions   occur   15   seconds   after    the    previous

retransmissions.








































                              -49-

IEN 167                                            Sax and Edmond
                                     Bolt Beranek and Newman Inc.
                                                        July 1980



7  1822 Layer/INP Driver Communication


     Communication between the system protocol  process  and  the

INP  driver  is implemented with four intrinsics:  IOPEN, ICLOSE,

IREAD, and IWRITE.  These intrinsics are modified  forms  of  the

CS/3000  intrinsics.   Their  function is to open a connection to

the INP network processor and to transmit  data  buffers  to  and

from  the  INP.   The IREAD and IWRITE intrinsics are always done

without wait.  The IOWAIT intrinsic  is  used  to  determine  the

completion of an I/O request.


     Initialization of the INP interface  begins  with  an  IOPEN

call  which initializes the interface software.  This is followed

by four IREAD intrinsic calls to initialize buffers for  incoming

network  packets.   Four  pending  buffers  should  allow  enough

buffering to catch all of the incoming data without tying up  too

many network buffers.


     The  following  is  a  summary  of  the  commands  used   to

communicate between the protocol process and the INP driver.


     - IOPEN()


       returns error code on  failure.   Possible  failure  modes

       include failure to find the INP microcode file, failure to

       load the microcode file in the INP, and a hardware failure

       in the INP.



                              -50-

IEN 167                                            Sax and Edmond
                                     Bolt Beranek and Newman Inc.
                                                        July 1980



       This  command  initializes  the  connection  between   the

       protocol process and the INP.  The initialization includes

       activating the INP and loading its microcode.


     - ICLOSE()


       This command closes the connection between the INP and the

       protocol  process  when  the  network  software is brought

       down.


     - IREAD(buffer)


       This intrinsic passes an empty buffer to the  INP  driver.

       The  buffer  is  queued to a DIT with an ATTACHIO command.

       Control then returns to the protocol process.


     - IWRITE(buffer)


       This intrinsic passes a full buffer to the  INP  DIT  with

       the  ATTACHIO  command.   Control  is  returned  after the

       buffer is attached to the DIT.   The  buffer  is  released

       when  the calling process receives an interrupt indicating

       I/O completion.












                              -51-

IEN 167                                            Sax and Edmond
                                     Bolt Beranek and Newman Inc.
                                                        July 1980



8  Protocol Software Buffering Scheme


     Data buffer management is the most  important  component  of

the  network  protocol  software.   Data  buffers perform the key

functions of data  storage  and  data  communication  within  the

protocol  software.  These functions have complex and conflicting

requirements which must be  balanced  by  the  buffer  management

scheme.    An  understanding  of  the  buffer  management  scheme

therefore begins with an understanding of its requirements.


     First, data buffers must be  considered  a  scarce  resource

shared  by  a number of competing "interests" within the protocol

software.  These "interests" include the various protocol  layers

as  well  as individual network connections within the TCP layer.

The major problem is how to effectively allocate buffer resources

among   these   interests.   This  problem  becomes  particularly

difficult when there is a shortage of buffers.


     An examination of the buffer requirements  shows  that  they

fall  into  two  categories.   The  first category includes those

buffers used to support general network functions.  This includes

buffers  used  in  the  1822 and Internet protocol layers.  These

buffers are assigned to move and store  data  in  these  protocol

layers  without  regard  to  particular network connections.  The

second category includes those buffers used by the  TCP  protocol

to support specific connections.



                              -52-

IEN 167                                            Sax and Edmond
                                     Bolt Beranek and Newman Inc.
                                                        July 1980



     The  distinction  between  the  two  buffer  categories   is

important  because  buffer use within each category is controlled

by a different set of events.  The use of buffers assigned to the

general  network  functions  can  be  controlled  by  the  system

protocol software.  Buffers are processed  through  the  Internet

and  1822  protocol layers without regard to the behavior of user

processes and their affect on  individual  connections.   Buffers

assigned  to the connection specific network functions in the TCP

and higher level protocol layers are greatly affected  by  events

which  occur  in  user  processes.   The  rate  at  which data is

accepted from or transmitted to the ARPANET by user processes  is

totally  unpredictable.  This unpredictability makes it difficult

for the system protocol  process  to  effectively  assign  buffer

resources to individual network connections.


     Two buffer  pools  are  used  to  separate  those  buffering

functions  shared  by all network connections from the connection

specific buffering functions.  A network buffer pool,  maintained

by  the  system protocol process, is used to support the 1822 and

Internet and some TCP buffering functions.  A user  buffer  pool,

maintained  by  each  user  protocol  process  is used to support

connection dependent buffering functions for the TCP  and  higher

level protocols.







                              -53-

IEN 167                                            Sax and Edmond
                                     Bolt Beranek and Newman Inc.
                                                        July 1980



8.1  Network Buffer Pool


     The network buffer  pool  supports  the  following  specific

functions.


     - movement of network packets from the INP driver  1822  and
       Internet protocol layers;

     - storage of Internet datagram  fragments  in  the  Internet
       protocol layer;

     - storage of unacknowledged TCP segments which do  not  fall
       into the current window;

     - movement of network packets from the TCP layer through the
       Internet and 1822 layer to the INP driver.


     The network buffer pool is maintained on the system protocol

process  stack  where  it  can  be accessed easily by the various

system protocol layers.  All of the buffers in the pool  are  the

same  size  to minimize the amount of software overhead needed to

maintain the buffers.  The buffer size is matched to the  maximum

frame  size  (128  bytes)  which may be transmitted over the X.25

link between the INP and the ARPANET IMP.


     The size choice is the result of  two  constraints.   First,

the  buffers used to catch incoming data must be large enough for

the largest incoming network packet.  The packets are transferred

directly into memory by the INP hardware making it impossible for

a packet to cross buffer boundaries.   Second,  the  single  size

buffer  scheme  limits  the amount of software overhead needed to




                              -54-

IEN 167                                            Sax and Edmond
                                     Bolt Beranek and Newman Inc.
                                                        July 1980



maintain the buffer pool.


     The single size buffer scheme does not  waste  buffer  space

because  the  buffer  size  is  well  matched  with  the  data it

processes.  The 128 byte buffer size allows room for all  of  the

protocol  headers and a small amount of data.  Messages with more

data will use multiple buffers.  The buffers are large enough  to

hold  a  significant amount of data yet small enough to limit the

waste caused by partially filled buffers.


     No  attempt  is  made  to  assign  network  buffers  to  any

particular  protocol layer or task.  Buffers are allocated either

when data is read from the ARPANET or when the  TCP  layer  sends

data out to the ARPANET.




8.1.1  Packet Compaction


     When the total number of network buffers in  the  free  list

falls  below a set value, a data compaction algorithm is invoked.

This algorithm searches for  partially  filled  buffers  used  to

store Internet datagram fragments and unacknowledged TCP segments

waiting to be transferred to a user process.  These  buffers  are

chosen  because  processing  of  the data in them is indefinitely

suspended.  Compaction of the data in these buffers  allows  some

of the buffers to be released to the free list.




                              -55-

IEN 167                                            Sax and Edmond
                                     Bolt Beranek and Newman Inc.
                                                        July 1980



8.1.2  Buffer Recycling


     A buffer recycling algorithm  is  invoked  when  the  system

protocol process runs out of free network buffers.  The algorithm

allows buffers to be reused even if they currently contain  data.

The  mechanism  works  by  identifying  which data buffers can be

reused without losing irreplaceable information.   These  buffers

are  sorted in a priority scheme wallows the least important

buffers to  be  recycled  first.   The  buffer  recycling  scheme

prevents  one socket from tying up too much of the network buffer

resources.  It also helps assure a supply of network buffers even

under heavy load conditions.


     The buffer algorithm scheme  divides  network  buffers  into

three   categories:  free  buffers,  in-use  buffers,  and  aging

buffers.  Free buffers are available for  immediate  use  by  any

protocol  layer and are maintained on a common free list.  In-use

buffers are buffers bound to messages currently  being  processed

and cannot be used for any other purpose.  Aging buffers are used

in messages where processing  is  suspended  for  any  number  of

reasons.   These  buffers  are placed in one of two special lists

arranged in order of decreasing age.  That  is,  message  buffers

which  have been blocked for the longest time are at the front of

the queue, while the message buffers  which  were  most  recently

blocked are at the end of the queue.




                              -56-

IEN 167                                            Sax and Edmond
                                     Bolt Beranek and Newman Inc.
                                                        July 1980



     There are two points in the protocol software where messages

may  be  blocked.  The  first  point  is in the Internet Protocol

software.  Fragmented datagrams cannot be passed on  to  the  TCP

and  can  be blocked indefinitely if one or more of the fragments

which make up the datagram is lost.   A  duplicate  datagram  may

eventually  be  transmitted  leaving the fragmented datagram in a

suspended state.   The  second  blocking  point  is  in  the  TCP

software.   Unacknowledged segments sent by a foreign host remain

suspended in the TCP until they are transferred to a user process

buffer.  Any segments which are not transferred to a user process

will remain blocked indefinitely.


     Buffer recycling is implemented through buffer  aging  lists

which  are  adjuncts  to  the buffer free list.  When an incoming

message is blocked, its buffers are attached to the end of one of

two  aging  lists.   Buffers  bound  to  datagram  fragments  are

attached to one aging lists while buffers bound to  TCP  segments

waiting  to  be read by user processes are attached to the second

aging list.


     The aging lists are  periodically  manipulated  when  a  new

datagram  fragment  comes in or when a user process receives some

data from  the  TCP.   Buffers  associated  with  the  particular

datagram  fragments or TCP segments are moved to the end of their

respective aging lists.  This helps assure that  any  data  which




                              -57-

IEN 167                                            Sax and Edmond
                                     Bolt Beranek and Newman Inc.
                                                        July 1980



has a chance of being used will not be thrown away.


     The buffers bound to fragmented datagrams are recycled first

because  they  are the most expendable.  Blocked datagram buffers

may be a part of datagrams  which  have  been  retransmitted  and

passed  on  to  the  TCP.   When the blocked datagram buffers are

exhausted the buffers bound to blocked  TCP  segments  are  used.

These  buffers contain the unacknowledged segments which have not

been claimed by a user process.  The assumptions  here  are  that

the  user  process  will never claim these segments and that they

are expendable.




User Process Buffer Pool


     The user process is responsible for  maintaining  a  set  of

fixed  length buffers for passing the user data to the TCP.  Each

buffer must include a four byte header along  with  80  bytes  of

data space.


     The first element of the header is used  as  either  a  byte

count  or a full buffer marker.  The count is used by the TCPSEND

intrinsic to indicate the number of data  bytes  in  the  buffer.

The  TCPRECEIVE intrinsic uses the buffer full marker to identify

buffers which may be reclaimed by the user process.






                              -58-

IEN 167                                            Sax and Edmond
                                     Bolt Beranek and Newman Inc.
                                                        July 1980



     The second element in  the  array  header  contains  a  list

pointer.   This  pointer  is maintained by the intrinsic software

and should not be altered by the user process until the buffer is

released.












































                              -59-

IEN 167                                            Sax and Edmond
                                     Bolt Beranek and Newman Inc.
                                                        July 1980



9  Data Flow Through the Protocol Software


     Data flow through the protocol software is effected  through

a  series  of tests and function calls.  The tests check the type

and processing state of each  packet  while  the  function  calls

perform  specific  operations  on  each packet.  These operations

include such things as creating or checking headers and  queueing

or de-queueing packet buffers.


     Whenever possible, network packets are processed through all

of  the  system protocol layers without interruption.  This helps

increase  throughput  by  minimizing  two  important  parameters.

First,  the  amount  of  buffering  required  to  process data is

decreased because all network buffers associated  with  a  packet

are  released  when  the  packet  has passed through the protocol

software.  Second, the time between the receipt of a packet  from

the ARPANET and the transmission of an ACK is reduced.


     There are a number of instances when  the  processing  of  a

packet  can  be  interrupted  within the system protocol process.

This can occur when the lack of some resource or  event  prevents

further processing.  Examples of this are as follows:


     - Internet datagram fragments waiting for reassembly;

     - TCP segments from a foreign host waiting to be read  by  a
       user process;

     - TCP segments  from  a  user  process  waiting  for  window



                              -60-

IEN 167                                            Sax and Edmond
                                     Bolt Beranek and Newman Inc.
                                                        July 1980



       allocation before being transmitted to the ARPANET;

     - TCP segments from a  user  process  already  sent  to  the
       ARPANET but waiting for an acknowledgment.




9.1  ARPANET to the User Level Data Flow


     Data packets come in from the network via a DMA interface to

the  INP  network  processor.  Incoming data is first transferred

into the protocol process via network buffers passed to the IREAD

intrinsic  which  places  a  read request on the DIT queue of the

INP.  An arriving network packet is placed in the network  buffer

by  the  INP  driver.  The system protocol process is notified of

each I/O completion through the IOWAIT intrinsic.


     Processing of network packets begins  when  an  IOWAIT  call

returns   on   completion  of  an  IREAD  intrinsic.   The  first

processing step is to link the network buffers which contain  the

pieces of an 1822 packet.


     The next processing steps are performed by the 1822 protocol

software.   If  this  is  a normal data packet the 1822 header is

removed and the data packet  is  passed  as  a  datagram  to  the

Internet Software.  The transfer is done by calling a sequence of

Internet protocol routines with the datagram as a parameter.







                              -61-

IEN 167                                            Sax and Edmond
                                     Bolt Beranek and Newman Inc.
                                                        July 1980



     The  Internet  software  checks  the  datagram  header   for

integrity  and  then  tries  to  find the proper address for this

datagram.  If the datagram is not for the local host it is routed

to  the  proper ARPANET Host and the network buffers are returned

to the free list.


     If the datagram is a fragment of a  larger  datagram  it  is

linked to any existing fragments waiting to be processed.  If the

new  fragment  does  not  complete  the  incoming  datagram,  the

fragment  is placed in an aging buffer queue next to the youngest

buffer in the partially complete datagram.   At  this  point  all

processing  on  the incoming datagram is suspended until the rest

of the datagram fragments arrive.


     A complete datagram is stripped of its Internet  header  and

sent  to  the TCP software as a data segment.  The TCP performs a

number of functions on  incoming  segments:   first  the  segment

header is checked to see if it belongs to a known socket -- if it

does, any acknowledgment information from the header is taken  to

update  the socket status; next, the segment is checked to see if

it falls within a window -- if it is not within the window (or  a

reasonable  approximation  thereof), the segment is discarded and

its buffers are returned to the free list.


     Accepted TCP segments are transferred into the user buffers.

The  transfer  is  initiated by the user process which provides a



                              -62-

IEN 167                                            Sax and Edmond
                                     Bolt Beranek and Newman Inc.
                                                        July 1980



buffer through the TCPOPEN or TCPRECEIVE  intrinsic.   A  command

message sent via the general input message file is used to inform

the system protocol process that  a  buffer  is  available.   The

system  protocol  process  transfers  as  much  of its segment as

possible to the user buffer.  The user process is  then  notified

of  the  data transfer via the connection's private message file.

Only the transferred portions of the segments are acknowledged to

the  foreign  host.  Any portions of segments which do not fit in

the receive window are stored in the TCP aging queue.


     The acknowledgment may be sent in a number of ways.  If  the

same  network  connection  has  an  outgoing  packet  waiting for

transmission, the acknowledgment  information  is  added  to  the

outgoing packet.  If there is no pending outgoing packet, a check

is made to see if there  is  sufficient  unacknowledged  data  to

warrant   an   acknowledgment   packet.    If   there  is  enough

information, a separate acknowledgment packet  is  generated  and

transmitted  out  to  the ARPANET as if it were a normal message.

If the number  of  unacknowledged  segments  is  insufficient  to

justify  an acknowledgment packet, the pending acknowledgment bit

in the TCB is set and a timer is started.  If the timer runs out,

an  acknowledgment  packet  is  sent  regardless of the number of

unacknowledged segments.







                              -63-

IEN 167                                            Sax and Edmond
                                     Bolt Beranek and Newman Inc.
                                                        July 1980



9.2  User Level to the ARPANET Data Flow


     Transfer of data from the user process out  to  the  ARPANET

begins  with  a  NETSEND  intrinsic call.  The intrinsic software

sends a message to the system protocol process to inform it  that

it has data to send.  The system protocol process tests the state

of the connection to see if data transmission is  feasible.   The

following  are sufficient conditions for data transmission out to

the ARPANET:


     - enough data has collected to justify  transmitting  it  to
       the foreign host;

     - the  user  process  has  specified  an  EOL  in  the  data
       transmission;

     - there are  fewer  than  eight  outstanding  1822  protocol
       packets waiting for RFNMs to the foreign host;

     - the waiting data falls within the foreign host's window.


     If the state of the connection does not allow a transmission

to  occur,  a  request-to-send data flag is set in the connection

control block.  When the connection state  changes  due  to  some

external  event,  a  check is made to see if the new state allows

the transmission of waiting data.  An example of such an event is

the  arrival  of  a RFNM from a foreign host; in this case all of

the connections to the foreign host are checked for data  waiting

for  transmission.   The  connection  with  data  which  has been

waiting for the longest time is processed first.  An  attempt  is




                              -64-

IEN 167                                            Sax and Edmond
                                     Bolt Beranek and Newman Inc.
                                                        July 1980



made  to  combine as many of the waiting TCP segments as possible

into  one  data  transfer  to  increase  the   amount   of   data

transmitted.


     If there is nothing blocking transmission of the  data,  the

TCP  software  allocates  a  buffer,  creates  the necessary TCP,

Internet, and 1822 headers, and copies the data to be transmitted

from the user buffer to the system's buffer.  The TCP header will

include any acknowledgment information for data received  on  the

return socket associated with the connection.


     In order to assure proper transmission of the TCP segment  a

retransmission  sequence  is  started.  A retransmission timer is

started to wake up the protocol software when a retransmission is

needed.   If  a  timeout  occurs, the segment is retransmitted as

soon as the state of the connection  allows  it.   The  necessary

conditions  for  a  retransmission  are the same as those for the

original transmission.  If the segment is partially acknowledged,

the  data  left  in  the  retransmission  queue is only that data

represented by the unacknowledged sequence numbers.














                              -65-

IEN 167                                            Sax and Edmond
                                     Bolt Beranek and Newman Inc.
                                                        July 1980



               APPENDIX A - HP3000 to ARPANET Link




      +----------+                      +----------+
      |          |---+              +---|          |
      |          | I |   X.25 LAP   |   |          |
      |  HP3000  | N |--------------|   |  C30 IMP |
      |          | P |              |   |          |
      |          |---+              +---|          |
      +----------+                      +----------+







































                              -66-

IEN 167                                            Sax and Edmond
                                     Bolt Beranek and Newman Inc.
                                                        July 1980

         APPENDIX B - Protocol Software Organization

                                +---------+
                                |   MBB   |
                                +---+-+---+
                                    ^ |
                                    | v
                                +---+-+---+
                                |   INP   |
                                +---------+
                                | Driver  |
                                +---+-+---+
                                    ^ |
                                    | v
                               ,----+-+----,
             High Priority    /  Device   /
             User Mode       /Information/
             Process        /    Table  /
                           '----+-+----'
                                ^ |
                             ATTACHIO
                                | v
                          +-----+-+----+
                          |    1822    |
                          |  -------   |           ,---------------,
                          |  Internet  |--------->/ Transmission  /
                          |  -------   |<--------/ Control Block /
                          |    TCP     |        '---------------'
                          +-+--+---+--++
                            ^  |   |  |
                            :  |   |  |
                   +--------:--+   |  +------------+
                   |        :      |               |
                   |     ...:......|...............|....
                   |     :         |      :        |   :
                   v     :         v      :        v   :
               +---+-----+---+  +--+------+-+   +--+---+--+
               |Server Telnet|  |User Telnet|   |User FTP |
               |  Program    |  |  Program  |   | Program |
               +-----+--+----+  +--+-+-+-+--+   +-+-+-+-+-+
                     ^  |          | | | |        | | | |
                     |  v          | | | |        | | | |
 Pseudo-TTY        ,-+--+-,         USERS          USERS
 Logical Devices  / PTY  /
 (one each user) '-+-+--'
                   ^ |
                   | v
                 HP3000
           Command Interpreter
                                  ---- Private Message Files
                                  .... General Input Message File


                              -67-

IEN 167                                            Sax and Edmond
                                     Bolt Beranek and Newman Inc.
                                                        July 1980



                 APPENDIX C - Control Structures

             _______________________________
             |POINTER TO BUFFER FREELIST   |
             |-----------------------------|
             |POINTER TO END OF FREELIST   |
             |-----------------------------|
             |FREE BUFFER COUNT            |
             |-----------------------------|
             |POINTER TO INTERNET AGE LIST |
             |-----------------------------|
             |POINTER TO END OF INTERNET   |
             |-----------------------------|
             |INTERNET AGE LIST COUNT      |
             |-----------------------------|
             |POINTER TO TCP AGE LIST      |
             |-----------------------------|
             |POINTER TO END OF TCP LIST   |
             |-----------------------------|
             |TCP AGE LIST BUFFER COUNT    |
             |-----------------------------|

             NETWORK RESOURCE CONTROL BLOCK





             _______________________________
             |HOST NUMBER                  |
             |-----------------------------|
             |NUMBER OF OUTSTANDING 1822   |
             |PACKETS WAITING FOR RFNMS    |
             |_____________________________|

              FOREIGN HOST CONTROL BLOCK















                              -68-

IEN 167                                            Sax and Edmond
                                     Bolt Beranek and Newman Inc.
                                                        July 1980



              _____________________
              | CONNECTION STATE  |
              |-------------------|
              | LOCAL PORT NUMBER |
              |-------------------|
              | TCP INTERFACE     |
              | CONTROL BLOCK NO. |
              |-------------------|
              |CONNECTION PRIVATE |
              |MESSAGE FILE ID    |
              --------------------|

             GENERAL INFORMATION SECTION
             OF THE CONNECTION CONTROL
             BLOCK


              _____________________
              |RECEIVE SEQUENCE   |
              |-------------------|
              |RECEIVE WINDOW     |
              |-------------------|
              |RECEIVE BUFF SIZE  |
              |-------------------|
              |RECEIVE URGENT PTR |
              |-------------------|
              |RECEIVE LAST BUFF  |
              |-------------------|
              |INITIAL RECEIVE    |
              |SEQUENCE NUMBER    |
              |-------------------|
              |PTR TO UN-ACKED TCP|
              | SEGMENTS          |
              |___________________|

             CONNECTION RECEIVE DATA















                              -69-

IEN 167                                            Sax and Edmond
                                     Bolt Beranek and Newman Inc.
                                                        July 1980



   _____________________
   |SEND UN-ACKED      |
   |-------------------|
   |SEND SEQUENCE      |
   |-------------------|
   |SEND WINDOW        |
   |-------------------|
   |SEND BUFFER SIZE   |
   |-------------------|
   |SEND URGENT PTR    |
   |-------------------|
   |SEND SEQUENCE FOR  |
   |LAST WINDOW UPDATE |
   |-------------------|
   |SEND LAST BUFFER   |
   |-------------------|
   |INITIAL SEND       |
   |SEQUENCE NUMBER    |
   |___________________|

   CONNECTION SEND DATA






























                              -70-

IEN 167                                            Sax and Edmond
                                     Bolt Beranek and Newman Inc.
                                                        July 1980



                     ________________
FREEBUFFER QUEUE --->|NEXT BUFFER   |____
                     |--------------|   |
                     |              |   |
                     |______________|   |
                                        |
                  ______________________|
                  |
                  |  ________________
                  -->|NEXT BUFFER   |____
                     |--------------|   |
                     |              |   |
                     |              |   |
                     |______________|   |
                                        |
                  ______________________|
                  |
                  |  ________________
                  -->|NULL          |
                     |--------------|
                     |              |
                     |              |
                     |______________|

                 NETWORK BUFFER FREELIST


























                              -71-

IEN 167                                            Sax and Edmond
                                     Bolt Beranek and Newman Inc.
                                                        July 1980



           OLDEST DATAGRAM          SECOND OLDEST
           FRAGMENT                 DATAGRAM FRAGMENT
INTERNET   ________________         ________________
AGING  --->|NEXT DATAGRAM |-------->|NEXT DATAGRAM |-->  PTR TO
LIST       |--------------|         |--------------|     THIRD
           |NEXT BUFFER   |____     |NEXT BUFFER   |____ OLDEST
           |--------------|   |     |--------------|   |
           |______________|   |     |______________|   |
                              |                        |
        ______________________|   _____________________|
        |                         |
        |  ________________       |  _______________
        -->|NEXT BUFFER   |____   -->|NEXT BUFFER  |____
           |--------------|   |      |-------------|   |
           |              |   |      |             |   |
           |              |   |      |             |   |
           |______________|   |      |_____________|   |
                              |                        |
        ______________________|    ____________________|
        |                          |
        |  ________________        |  _______________
        -->|NULL          |        -->|NULL         |
           |--------------|           |-------------|
           |              |           |             |
           |              |           |             |
           |______________|           |_____________|

                     INTERNET AGING LIST























                              -72-

IEN 167                                            Sax and Edmond
                                     Bolt Beranek and Newman Inc.
                                                        July 1980



           CONNECTION 1             CONNECTION 2
           OLDEST UN-ACKED          SECOND OLDEST UN-ACKED
           SEGMENT BUFFERS          SEGMENT BUFFERS
TCP        ________________         ________________    PTR TO
AGING  --->|NEXT SEGMENT  |-------->|NEXT SEGMENT  |--> THIRD
LIST       |--------------|         |--------------|    OLDEST
           |NEXT BUFFER   |____     |NEXT BUFFER   |____
           |--------------|   |     |--------------|   |
           |______________|   |     |______________|   |
                              |                        |
        ______________________|   _____________________|
        |                         |
        |  ________________       |  _______________
        -->|NEXT BUFFER   |____   -->|NEXT BUFFER  |____
           |--------------|   |      |-------------|   |
           |              |   |      |             |   |
           |              |   |      |             |   |
           |______________|   |      |_____________|   |
                              |                        |
        ______________________|    ____________________|
        |                          |
        |  ________________        |  _______________
        -->|NULL          |        -->|NULL         |
           |--------------|           |-------------|
           |              |           |             |
           |              |           |             |
           |______________|           |_____________|

                       TCP AGING LIST






















                              -73-

IEN 167                                            Sax and Edmond
                                     Bolt Beranek and Newman Inc.
                                                        July 1980



              APPENDIX D - Command Message Formats


General Message Format

    _________________________
    | Command Type (2 bytes)|
    |_______________________|
    | TCP Interface Control |
    | Block No. (2 bytes)   |
    |_______________________|
    | Data  (10 bytes)      |
    |_______________________|


OPEN CONNECTION Data Area Format

    _________________________
    | Foreign Host Internet |
    | Address (4 bytes)     |
    |_______________________|
    | Foreign Port (2 bytes)|
    |_______________________|
    | Local Port (2 bytes)  |
    |_______________________|
    | Status Flag bits      |
    | (2 bytes)             |
    |_______________________|


SEND Command Data Area Format

    _________________________
    | Send Byte Count       |
    | (2 bytes)             |
    |_______________________|















                              -74-

IEN 167                                            Sax and Edmond
                                     Bolt Beranek and Newman Inc.
                                                        July 1980



Message File Command Codes

    ___________________________________________________
    |User To TCP Command | TCP to User Command | Code |
    |____________________|_____________________|______|
    | OPEN CONNECTION    |  OPENCONFIRM        |   0  |
    |____________________|_____________________|______|
    | CLOSE CONNECTION   |  NETCLOSE           |   1  |
    |____________________|_____________________|______|
    | ABORT CONNECTION   |  NETABORT           |   2  |
    |____________________|_____________________|______|
    | SEND               |  DATASENT           |   3  |
    |____________________|_____________________|______|
    | RECEIVE            |  PENDING RECEIVE    |   4  |
    |____________________|_____________________|______|
    | STATUS             |  STATUS COMPLETE    |   5  |
    |____________________|_____________________|______|


































                              -75-

IEN 167                                            Sax and Edmond
                                     Bolt Beranek and Newman Inc.
                                                        July 1980



            APPENDIX E - TCP Interface Control Block


      GENERAL INFO SECTION OF THE
    TCP INTERFACE CONNECTION BLOCK
   +----------------------------+
   | TCP STATUS BUFFER PTR      |
   +----------------------------+
   | USER PROCESS STACK DATA    |
   | SEGMENT NUMBER             |
   +----------------------------+
   | SEND Side Open/Close flag) |
   +----------------------------+
   |RECEIVE Side Open/Close flag|
   +----------------------------+


       SEND PORTION OF THE TCP                  USER BUFFERS USED
      INTERFACE CONNECTION BLOCK                TO TRANSMIT DATA
                                                TO THE TCP
   +----------------------------+              +--------------+
   | Ptr to First Free Buffer   |------------->| Data Count   |
   | (user buffer whose data    |              |(no data bytes|
   |  has been read by TCP      |              | in buffer)   |
   +----------------------------+              +--------------+
   | Ptr to Next Data Buffer    |              | Link to next |
   | (user buffer whose data    +-----+     +--+ Buffer       |
   |  not been read by TCP)     |     |     |  +--------------+
   +----------------------------+     |     |  | DATA         |
   | Ptr to first UnAcked byte  +---+ |     |  +--------------+
   +----------------------------+   | |     |
   | Offset in Next Data Buffer |   | |     |
   |(offset in next data buffer +-+-+ |     |
   | to first unread data byte) | | | |     |  +--------------+
   +----------------------------+ | | +--->-+->| Data Count   |
                                  | |          +--------------+
                                  | |       +--| LINK         |
                                  | |       |  +--------------+
                                  | +-------|->|              |
                                  +-------->|->| DATA         |
                                            |  +--------------+
                                            |
                                            |  +--------------+
                                            +->| Data Count   |
                                               +--------------+
                                               | LINK         |
                                               +--------------+
                                               | DATA         |
                                               +--------------+


                              -76-

IEN 167                                            Sax and Edmond
                                     Bolt Beranek and Newman Inc.
                                                        July 1980



      RECEIVE PORTION OF THE TCP                USER BUFFERS USED
      INTERFACE CONNECTION BLOCK                FROM THE TCP
      TO TRANSMIT DATA
   +----------------------------+              +--------------+
   | Ptr to First Filled Buffer |------------->|Full/Filling  |
   | (user buffer which has been|              |True indicates|
   |  filled by TCP)            |              |buffer is full|
   +----------------------------+              +--------------+
   | Ptr to Next Data byte to be|           +--+ Link to next |
   | read by user process       +-------+   |  | Buffer       |
   +----------------------------+       |   |  +--------------+
   | Ptr to First Partially Full|       |   |  | DATA         |
   | Buffer (buffer not yet     +-----+ +->-+->|              |
   |  filled by TCP)            |     |     |  +--------------+
   +----------------------------+     |     |
   | Offset in Partially Full   |     |     |
   | Buffer (next free byte for +--+  |     |
   |  TCP)                      |  |  |     |  +--------------+
   +----------------------------+  |  +-----+->| Full/Filling |
                                   |           +--------------+
                                   |        +--| LINK         |
                                   |        |  +--------------+
                                   +------->+->| DATA         |
                                            |  +--------------+
                                            |
                                            |
                                            |
                                            |  +--------------+
                                            +->| Full/Filling |
                                               +--------------+
                                               | LINK         |
                                               +--------------+
                                               | DATA         |
                                               +--------------+

















                              -77-

mirror server hosted at Truenetwork, Russian Federation.