GENWiki

Premier IT Outsourcing and Support Services within the UK

User Tools

Site Tools


rfc:ien:ien167

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:

  1. 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.
  1. Efficient high speed network communications are extremely
     important  because  this  TCP  version  will  be used on a
     production rather than an experimental basis.
  1. _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
  1. 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.
  1. 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
  1. multiple connections to multiple hosts,
  1. flow control at the 1822, Internet, and TCP layers,
  1. error recovery,
  1. fair allocation of resources among all connections,
  1. handling of urgent data,
  1. surviving incorrect packets,
  1. datagram reassembly,
  1. routing,
  1. 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:

  1. a connection state variable used to maintain the

connection state,

  1. the local port number of the connection,
  1. the TCP interface control block number associated with

this connection,

  1. the file number of the private message file associated

with this connection,

  1. the TCB data associated with the receive side of this

connection,

  1. the TCB data associated with the send side of this

connection,

  1. 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:
  1. the foreign host has advertised sufficient window

space,

  1. the number of outstanding RFNMs for all connections

to the foreign host is less than eight,

  1. 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.
  1. 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.

  1. 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.
  1. ICLOSE()
     This command closes the connection between the INP and the
     protocol  process  when  the  network  software is brought
     down.
  1. 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.
  1. 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.

  1. movement of network packets from the INP driver 1822 and

Internet protocol layers;

  1. storage of Internet datagram fragments in the Internet

protocol layer;

  1. storage of unacknowledged TCP segments which do not fall

into the current window;

  1. 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:

  1. Internet datagram fragments waiting for reassembly;
  1. TCP segments from a foreign host waiting to be read by a

user process;

  1. 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;
  1. 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:

  1. enough data has collected to justify transmitting it to

the foreign host;

  1. the user process has specified an EOL in the data

transmission;

  1. there are fewer than eight outstanding 1822 protocol

packets waiting for RFNMs to the foreign host;

  1. 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-
/data/webs/external/dokuwiki/data/pages/rfc/ien/ien167.txt · Last modified: 2001/06/25 20:33 by 127.0.0.1

Donate Powered by PHP Valid HTML5 Valid CSS Driven by DokuWiki