Internet DRAFT - draft-mckenzie-arpanet-host-host-protocol

draft-mckenzie-arpanet-host-host-protocol



Network Working Group                                        A. McKenzie
Internet Draft                                                S. Crocker
Intended Status: Historic                                 August 8, 2011


               Host/Host Protocol for the ARPA Network
           draft-mckenzie-arpanet-host-host-protocol-01.txt


Abstract

   This document reproduces the Host/Host Protocol developed by the ARPA
   Network Working Group during 1969, 1970 and 1971.  It describes a
   protocol used to manage communication between processes residing on
   independent Hosts.  It addresses issues of multiplexing multiple
   streams of communication over a single hardware interface including
   addressing, flow control, connection establishment/disestablishment,
   and other signaling.  It was the official protocol of the ARPA
   Network from January 1972 until the switch to TCP/IP in January 1983.
   It is offered as an "intended RFC" at this late date to help complete
   the historical record available through the RFC series.

IPR-Related Notice

   Copyright (c) 2011 IETF Trust and the persons identified as the
   document authors. All rights reserved.

   This document is subject to BCP 78 and the IETF Trust's Legal
   Provisions Relating to IETF Documents
   (http://trustee.ietf.org/license-info) in effect on the date of
   publication of this document. Please review these documents
   carefully, as they describe your rights and restrictions with respect
   to this document.

Status of this Document

   This Internet-Draft is submitted in full conformance with the
   provisions of BCP 78 and BCP 79. Internet-Drafts are working
   documents of the Internet Engineering Task Force (IETF). Note that
   other groups may also distribute working documents as Internet-
   Drafts. The list of current Internet-Drafts is at
   http://datatracker.ietf.org/drafts/current.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time. It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."




           This Internet-Draft will expire on February 9, 2012.


McKenzie & Crocker      Expires February 9, 2012                [Page 1]

Internet Draft   Host-Host Protocol for the ARPA Network  August 8, 2011


Table of Contents

1. Introduction........................................................3
2. A Few Comments on Nomenclature and Key Concepts.....................4
3. Host/Host Protocol Document (with its own table of contents
      on page 7).......................................................5
4. Security Considerations............................................33
5. Authors' Addresses.................................................33












































McKenzie & Crocker      Expires February 9, 2012                [Page 2]

Internet Draft   Host-Host Protocol for the ARPA Network  August 8, 2011


1. Introduction


   The Host/Host Protocol for the ARPA Network was created during 1969, 
1970 and 1971 by the Network Working Group, chaired by Steve Crocker, a 
graduate student at UCLA.  Many of the RFCs with numbers less than 72, 
plus RFCs 102, 107, 111, 124, 132, 154, and 179 dealt with the 
development of this protocol.  The first official document defining the 
protocol was issued by Crocker on August 3, 1970 as "Host-Host Protocol 
Document No. 1" (see citation in RFC #65), which was based on RFC #54 by 
Crocker, Postel, Newkirk, and Kraley.  Revision of Document No. 1 began 
in mid-February 1971, as discussed in RFC #102.  Although McKenzie is 
listed as the author of the January 1972 document, which superseded 
Document No. 1, it is more correct to say McKenzie was the person who 
compiled and edited the document.  Most or all of the ideas in the 
document originated with others.

   At the time "Host-Host Protocol Document No. 1" was issued it was not 
given an RFC number because it was not to be viewed as a "request for 
comments" but as a standard for implementation.  It was one of a set of 
such standards maintained as a separate set of documentation by the 
Network Information Center (NIC) at Stanford Research Institute (SRI).  
The January 1972 version reproduced here also followed that approach.  
It has been noted by many that all subsequent standards were issued as 
RFCs, and the absence of the Host/Host Protocol specification from the 
RFC series creates a curious gap in the historical record.  It is to 
fill that gap that this "intended RFC" is offered.

   In 1972 most ARPA Network documents, RFCs and others, were prepared 
and distributed in hard copy.  The Host/Host Protocol document was typed 
on a typewriter (probably an IBM Selectric) which had interchangeable 
print elements, and used both italic and boldface fonts in addition to 
the regular font.  Diagrams were drawn by a graphic artist and pasted 
into the typed document.  Since RFCs are constrained to use a single 
typeface we have tried to indicate boldface by the use of either all 
capitals or by a double underline, and to indicate italics by the use of 
underscores around words in place of spaces.  The resulting document is 
a bit more difficult to read, but preserves the emphases of the 
original.  Of course, the pagination has changed, and we hope we have 
correctly modified all of the page numbers.  There were three footnotes 
in the original document and we have moved these into the text, set off 
by indentation and square brackets. A .pdf image of the original 
document can be found at http://alexmckenzie.weebly.com/hosthost-
protocol-for-the-arpa-network.html.







McKenzie & Crocker      Expires February 9, 2012                [Page 3]

Internet Draft   Host-Host Protocol for the ARPA Network  August 8, 2011


2. A Few Comments on Nomenclature and Key Concepts

In the protocol definition "RFC" is used to mean "Request for 
Connection," which refers to either a "Sender to Receiver" or a 
"Receiver to Sender" request to initiate a connection.  In retrospect, 
this seems like an unnecessarily confusing choice of terminology.

At the time this protocol was defined, it was given the undistinguished 
name "Host-Host Protocol."  The acronym "NCP" meant "Network Control 
Program" and referred to the code that had to be added to the operating 
system within each host to enable it to interact with its IMP and manage 
multiple connections.  Over time, and particularly in the context of the 
change from this protocol to TCP/IP, this protocol was commonly called 
"NCP" and the expansion changed to "Network Control Protocol."

This protocol was superseded by TCP.  In this document, the protocol is 
referred to as a second layer (or "level") protocol, where as in current 
writings TCP is usually referred to as a layer 3 protocol.  When this 
protocol was created, it was expected that over time new layers would be 
created on top of, below and even in between existing layers.

This protocol used a separate channel (the control link) to manage 
connections.  This was abandoned in future protocols.

There was no checksum or other form of error control except for the RST 
in this design.  There had been in earlier versions, but it was removed 
at the insistence of the IMP designers who argued vigorously that the 
underlying network of IMPs would never lose a packet or deliver one with 
errors.  Although the IMP network was generally quite reliable, there 
were instances where the interface between the IMP and the host could 
drop bits, and, of course, experience with congestion control as the 
network was more heavily used made it clear that the host layer would 
have to deal with occasional losses in transmission.  These changes 
were built into TCP. 

Uncertainty about timing constraints in the design of protocols is 
evident in this document and remains a source of ambiguity, limitation 
and error in today's design processes.













McKenzie & Crocker      Expires February 9, 2012                [Page 4]

Internet Draft   Host-Host Protocol for the ARPA Network  August 8, 2011

3. Host/Host Protocol Document






                           Host/Host Protocol
                                for the
                              ARPA Network 




























Prepared for the Network Working Group by
   Alex McKenzie
   BBN
   January 1972 









McKenzie & Crocker      Expires February 9, 2012                [Page 5]

Internet Draft   Host-Host Protocol for the ARPA Network  August 8, 2011


                                PREFACE 

   This document specifies a protocol for use in communication between 
Host computers on the ARPA Network.  In particular, it provides for 
connection of independent processes in different Hosts, control of the 
flow of data over established connections, and several ancillary 
functions.  Although basically self-contained, this document specifies 
only one of several ARPA Network protocols; all protocol specifications 
are collected in the document _Current_Network_Protocols,_ NIC #7104.

   This document supersedes NIC #7147 of the same title.  Principal 
differences between the documents include: 

   - prohibition of spontaneous RET, ERP, and RRP commands
   - a discussion of the problem of unanswered CLS commands (page 16)
   - a discussion of the implications of queuing and not queuing RFCs
     (page 14)
   - the strong recommendation that received ERR commands be logged,
     and some additional ERR specifications.

   In addition to the above, several minor editorial changes have been 
made.  

   Although there are many individuals associated with the network who 
are knowledgeable about protocol issues, individuals with questions 
pertaining to Network protocols should initially contact one of the 
following: 

   Steve Crocker 
   Advanced Research Projects Agency 
   1400 Wilson Boulevard 
   Arlington, Virginia 22209 
   (202) 694-5921 or 5922

   Alex McKenzie 
   Bolt Beranek and Newman Inc.  
   50 Moulton Street 
   Cambridge, Massachusetts 02133 
   (617) 491-1350 ext.  441 

   Jon Postel
   University of California at Los Angeles
   Computer Science Department
   3732 Boelter Hall
   Los Angeles, California 90024 
   (213) 325-2363 1/72





McKenzie & Crocker      Expires February 9, 2012                [Page 6]

Internet Draft   Host-Host Protocol for the ARPA Network  August 8, 2011


                           TABLE OF CONTENTS 

I.    INTRODUCTION.....................................................8
      An overview of the multi-leveled protocol structure in the ARPA
      Network.  

II.   COMMUNICATION CONCEPTS..........................................10
      Definitions of terminology and a description of the overall
      strategy used in Host-to-Host communication.  

III.  NCP FUNCTIONS...................................................13
      The meat of the document for the first-time reader.  Host-to-Host
      "commands" are introduced with descriptions of conditions of
      their use, discussion of possible problems, and other background
      material.  

            Connection Establishment..........................13
            Connection Termination............................15
            Flow Control......................................17
            Interrupts........................................19
            Test Inquiry......................................20
            Reinitialization..................................20 

 IV.   DECLARATIVE SPECIFICATIONS.....................................22
       Details for the NCP implementer.  A few additional "commands"
       are introduced, and those described in Section III are
       reviewed.  Formats and code and link assignments are specified.

            Message Format....................................22
            Link Assignment...................................24
            Control Messages..................................24
            Control Commands..................................24
            Opcode Assignment.................................31
            Control Command Summary...........................31

















McKenzie & Crocker      Expires February 9, 2012                [Page 7]

Internet Draft   Host-Host Protocol for the ARPA Network  August 8, 2011


                            I.  INTRODUCTION

   The ARPA Network provides a capability for geographically separated 
computers, called Hosts, to communicate with each other.  The Host 
computers typically differ from one another in type, speed, word length, 
operating system, etc.  Each Host computer is connected into the network 
through a local small computer called an _Interface_Message_Processor_ 
_(IMP)._  The complete network is formed by interconnecting these IMPs, 
all of which are virtually identical, through wideband communications 
lines supplied by the telephone company.  Each IMP is programmed to 
store and forward messages to the neighboring IMPs in the network.  
During a typical operation, a Host passes a message to its local IMP; 
the first 32 bits of this message include the "network address" of a 
destination Host.  The message is passed from IMP to IMP through the 
Network until it finally arrives at the destination IMP, which in turn 
passes it along to the destination Host.  

   Specifications for the physical and logical message transfer between 
a Host and its local IMP are contained in Bolt Beranek and Newman (BBN) 
Report No. 1822.  These specifications are generally called the _first_ 
_level_protocol_ or Host/IMP Protocol.  This protocol is not by itself, 
however, sufficient to specify meaningful communication between 
processes running in two dissimilar Hosts.  Rather, the processes must 
have some agreement as to the method of initiating communication, the 
interpretation of transmitted data, and so forth.  Although it would be 
possible for such agreements to be reached by each pair of Hosts (or 
processes) interested in communication, a more general arrangement is 
desirable in order to minimize the amount of implementation necessary 
for Network-wide communication.  Accordingly, the Host organizations 
formed a Network Working Group (NWG) to facilitate an exchange of ideas 
and to formulate additional specifications for Host-to-Host 
communications.  

   The NWG has adopted a "layered" approach to the specification of 
communications protocol.  The inner layer is the Host/IMP protocol.  The 
next layer specifies methods of establishing communications paths, 
managing buffer space at each end of a communications path, and 
providing a method of "interrupting" a communications path.  This 
protocol, which will be used by all higher-level protocols, is known as 
the _second_level_protocol,_ or Host/Host protocol.  (It is worth noting 
that, although the IMP sub-network provides a capability for _message_ 
_switching,_ the Host/Host protocol is based on the concept of _line_ 
_switching._) Examples of further layers of protocol currently developed 
or anticipated include:  

1) An _Initial_Connection_Protocol_ (ICP) which provides a convenient
   standard method for several processes to gain simultaneous access to
   some specific process (such as the "logger") at another Host.  



McKenzie & Crocker      Expires February 9, 2012                [Page 8]

Internet Draft   Host-Host Protocol for the ARPA Network  August 8, 2011


2) A _Telecommunication_Network_ (TELNET) protocol which provides for
   the "mapping" of an arbitrary keyboard-printer terminal into a
   Network Virtual Terminal (NVT), to facilitate communication between a
   terminal user at one Host site and a terminal-serving process at some
   other site which "expects" to be connected to a (local) terminal
   logically different from the (remote) terminal actually in use.  The
   TELNET protocol specifies use of the ICP to establish the
   communication path between the terminal user and the terminal-service
   process.  

3) A _Data_Transfer_ protocol to specify standard methods of formatting
   data for shipment through the network.  

4) A _File_Transfer protocol to specify methods for reading, writing,
   and updating files stored at a remote Host.  The File Transfer
   protocol specifies that the actual transmission of data should be
   performed in accordance with the Data Transfer protocol.  

5) A _Graphics_ protocol to specify the means for exchanging graphics
   display information.  

6) A _Remote_Job_Service_ (RJS) protocol to specify methods for
   submitting input to, obtaining output from, and exercising control
   over Hosts which provide batch processing facilities.  

   The remainder of this document describes and specifies the Host/Host, 
or second level, protocol as formulated by the Network Working Group.  
























McKenzie & Crocker      Expires February 9, 2012                [Page 9]

Internet Draft   Host-Host Protocol for the ARPA Network  August 8, 2011


                       II.  COMMUNICATION CONCEPTS

   The IMP sub-network imposes a number of physical restrictions on 
communications between Hosts; these restrictions are presented in BBN 
Report Number 1822.  In particular, the concepts of leaders, messages, 
padding, links, and message types are of interest to the design of 
Host/Host protocol.  The following discussion assumes that the reader is 
familiar with these concepts.  

   Although there is little uniformity among the Hosts in either 
hardware or operating systems, the notion of multiprogramming dominates 
most of the systems.  These Hosts can each concurrently support several 
users, with each user running one or more processes.  Many of these 
processes may want to use the network concurrently, and thus a 
fundamental requirement of the Host/Host protocol is to provide for 
process-to-process communication over the network.  Since the first 
level protocol only takes cognizance of Hosts, and since the several 
processes in execution within a Host are usually independent, it is 
necessary for the second level protocol to provide a richer addressing 
structure.  

   Another factor which influenced the Host/Host protocol design is the 
expectation that typical process-to-process communication will be based, 
not on a solitary message, but rather upon a sequence of messages.  One 
example is the sending of a large body of information, such as a data 
base, from one process to another.  Another example is an interactive 
conversation between two processes, with many exchanges.  

   These considerations led to the introduction of the notions of 
connections, a Network Control Program, a "control link", "control 
commands", connection byte size, message headers, and sockets.  

   A _connection_ is an extension of a link.  A connection couples two 
processes so that output from one process is input to the other.  
Connections are defined to be simplex (i.e., unidirectional), so two 
connections are necessary if a pair of processes are to converse in both 
directions.

   Processes within a Host are envisioned as communicating with the rest 
of the network through a _Network_Control_Program_ (NCP), resident in 
that Host, which implements the second level protocol.  The primary 
function of the NCP is to establish connections, break connections, and 
control data flow over the connections.  We will describe the NCP as 
though it were part of the operating system of a Host supporting 
multiprogramming, although the actual method of implementing the NCP may 
be different in some Hosts.  

   In order to accomplish its tasks, the NCP of one Host must 
communicate with the NCPs of other Hosts.  To this end, a particular 


McKenzie & Crocker      Expires February 9, 2012               [Page 10]

Internet Draft   Host-Host Protocol for the ARPA Network  August 8, 2011


link between each pair of Hosts has been designated as the 
_control_link._  Messages transmitted over the control link are called 
_control_ _messages_*, and must always be interpreted by an NCP as a 
sequence of one or more _control_commands_.  For example, one kind of 
control command is used to initiate a connection, while another kind 
carries notification that a connection has been terminated.  

   [*Note that in BBN Report Number 1822, messages of non-zero type
   are called control messages, and are used to control the flow of
   information between a Host and its IMP.  In this document, the term
   "control message" is used for a message of type zero transmitted
   over the control link.  The IMPs take no special notice of these
   messages.]

   The concept of a message, as used above, is an artifact of the IMP 
sub-network; network message boundaries may have little intrinsic 
meaning to communicating processes.  Accordingly, it has been decided 
that the NCP (rather than each transmitting process) should be 
responsible for segmenting interprocess communication into network 
messages.  Therefore, it is a principal of the second level protocol 
that no significance may be inferred from message boundaries by a 
receiving process.  _The_only_exception_to_this_principle_is_in_
_control_messages,_each_of_which_must_contain_an_integral_number_of_
_control_commands._ 

   Since message boundaries are selected by the transmitting NCP, the 
receiving NCP must be prepared to concatenate successive messages from 
the network into a single (or differently divided) transmission for 
delivery to the receiving process.  The fact that Hosts have different 
word sizes means that a message from the network might end in the middle 
of a word at the receiving end, and thus the concatenation of the next 
message might require the receiving Host to carry out extensive bit-
shifting.  Because bit-shifting is typically very costly in terms of 
computer processing time, the protocol includes the notions of 
connection byte size and message headers.  

   As part of the process of establishing a connection, the processes 
involved must agree on a _connection_byte_size._  Each message sent over 
the connection must then contain an integral number of bytes of this 
size.  Thus the pair of processes involved in a connection can choose a 
mutually convenient byte size, for example, the least common multiple of 
their Host word lengths.  It is important to note that the ability to 
choose a byte size _must_ be available to the processes involved in the 
connection; an NCP is prohibited from imposing an arbitrary byte size on 
any process running in its own Host.  In particular, an outer layer of 
protocol may specify a byte size to be used by that protocol.  If some 
NCP is unable to handle that byte size, then the outer layer of protocol 
will not be implementable on that Host.  



McKenzie & Crocker      Expires February 9, 2012               [Page 11]

Internet Draft   Host-Host Protocol for the ARPA Network  August 8, 2011


   The IMP sub-network requires that the first 32 bits of each message 
(called the leader) contain addressing information, including 
destination Host address and link number.  The second level protocol 
extends the required information at the beginning of each message to a 
total of 72 bits; these 72 bits are called the _message_header._  A 
length of 72 bits is chosen since most Hosts either can work 
conveniently with 8-bit units of data or have word lengths of 18 or 36 
bits; 72 is the least common multiple of these lengths.  Thus, the 
length chosen for the message header should reduce bit-shifting problems 
for many Hosts.  In addition to the leader, the message header includes 
a field giving the byte size used in the message, a field giving the 
number of bytes in the message, and "filler" fields.  The format of the 
message header is fully described in Section IV.  

   Another major concern of the second level protocol is a method for 
reference to processes in other Hosts.  Each Host has some internal 
scheme for naming processes, but these various schemes are typically 
different and may even be incompatible.  Since it is not practical to 
impose a common internal process naming scheme, a standard intermediate 
name space is used, with a separate portion of the name space allocated 
to each Host.  Each Host must have the ability to map internal process 
identifiers into its portion of this name space.  

   The elements of the name space are called _sockets._  A socket forms 
one end of a connection, and a connection is fully specified by a pair 
of sockets.  A socket is identified by a Host number and a 32-bit socket 
number.  The same 32-bit number in different Hosts represents different 
sockets.  

   A socket is either a _receive_socket_ or a _send_socket,_ and is so 
marked by its low-order bit (0 = receive; 1 = send).  This property is 
called the socket's _gender._  The sockets at either end of a connection 
must be of opposite gender.  Except for the gender, second level 
protocol places no constraints on the assignment of socket numbers 
within a Host.  
















McKenzie & Crocker      Expires February 9, 2012               [Page 12]

Internet Draft   Host-Host Protocol for the ARPA Network  August 8, 2011


                      III.  NCP FUNCTIONS

   The functions of the NCP are to establish connections, terminate 
connections, control flow, transmit interrupts, and respond to test 
inquiries.  These functions are explained in this section, and control 
commands are introduced as needed.  In Section IV the formats of all 
control commands are presented together.  

Connection Establishment
======================== 

The commands used to establish a connection are STR (sender-to-receiver) 
and RTS (receiver- to-sender).

        8*         32               32           8 
     +----------------------------------------------+
     | STR |   send socket  | receive socket | size |
     +----------------------------------------------+

   [*The number shown above each control command field is the length
   of that field in bits.]

        8          32               32           8 
     +----------------------------------------------+
     | RTS | receive socket |  send socket   | link |
     +----------------------------------------------+

The STR command is sent from a prospective sender to a prospective 
receiver, and the RTS from a prospective receiver to a prospective 
sender.  The send socket field names a socket local to the prospective 
sender; the receive socket field names a socket local to the prospective 
receiver.  In the STR command, the "size" field contains an unsigned 
binary number (in the range 1 to 255; zero is prohibited) specifying the 
byte size to be used for all messages over the connection.  In the RTS 
command, the "link" field specifies a link number; all messages over the 
connection must be sent over the link specified by this number.  These 
two commands are referred to as requests-for-connection (RFCs).  An STR 
and an RTS match if the receive socket fields match and the send socket 
fields match.  A connection is established when a matching pair of RFCs 
have been exchanged.  Hosts_are_prohibited_from_establishing_more_than_ 
_one_connection_to_any_local_socket.

   With respect to a particular connection, the Host containing the send 
socket is called the _sending_Host_ and the Host containing the receive 
socket is called the _receiving_Host._  A Host may connect one of its 
receive sockets to one of its send sockets, thus becoming both the 
sending Host and the receiving Host for that connection.  These terms 
apply only to data flow; control messages will, in general, be 
transmitted in both directions.


McKenzie & Crocker      Expires February 9, 2012               [Page 13]

Internet Draft   Host-Host Protocol for the ARPA Network  August 8, 2011


    A Host sends an RFC either to request a connection, or to accept a 
foreign Host's request.  Since RFC commands are used both for requesting 
and for accepting the establishment of a connection, it is possible for 
either of two cooperating processes to initiate connection 
establishment.  As a consequence, a family of processes may be created 
with connection- initiating actions built-in, and the processes within 
this family may be started up (in different Hosts) in arbitrary order 
provided that appropriate queueing is performed by the Hosts involved 
(see below).  

   _There_is_no_prescribed_lifetime_for_an_RFC._  A Host is permitted to 
queue incoming RFCs and withhold a response for an arbitrarily long 
time, or, alternatively, to reject requests (see Connection Termination 
below) immediately if it does not have a matching RFC outstanding.  It 
may be reasonable, for example, for an NCP to queue an RFC that refers 
to some currently unused socket until a local process takes control of 
that socket number and tells the NCP to accept or reject the request.  
Of course, the Host which sent the RFC may be unwilling to wait for an 
arbitrarily long time, so it may abort the request.  On the other hand, 
some NCP implementations may not include any space for queueing RFCs, 
and thus can be expected to reject RFCs unless the RFC sequence was 
initiated locally.  

_Queueing_Considerations_ 

   The decision to queue, or not queue, incoming RFCs has important 
implications which NCP implementers must not ignore.  Each RFC which is 
queued, of course, requires a small amount of memory in the Host doing 
the queueing.  If each incoming RFC is queued until a local process 
seizes the local socket and accepts (or rejects) the RFC, but no local 
process ever seizes the socket, the RFC must be queued "forever." 
Theoretically this could occur infinitely many times (there is no reason 
not to queue several RFCs for a single local socket, letting the local 
process decide which, if any, to accept) thus requiring infinite storage 
for the RFC queue.  On the other hand, if no queueing is performed the 
cooperating processes described above will be able to establish a 
desired connection only by accident (when they are started up such that 
one issues its RFC while the RFC of the other is in transit in the 
network - clearly an unlikely occurrence).  

   Perhaps the most reasonable solution to the problems posed above is 
for _each_ NCP to give processes running in its own Host two options for 
attempting to initiate connections.  The first option would allow a 
process to cause an RFC to be sent to a specified remote socket; with 
the NCP notifying the process as to whether the RFC were accepted or 
rejected by the remote Host.  The second option would allow a process to 
tell _its_own_ NCP to "listen" for an RFC to a specified local socket 
from some remote socket (the process might also specify the particular 



McKenzie & Crocker      Expires February 9, 2012               [Page 14]

Internet Draft   Host-Host Protocol for the ARPA Network  August 8, 2011


remote socket and/or Host it wishes to communicate with) and to accept 
the RFC (i.e., return a matching RFC) if and when it arrives.  Note that 
this also involves queueing (of "listen" requests), but it is internal 
queueing which is susceptible to reasonable management by the local 
Host.  If this implementation were available, one of two cooperating 
processes could "listen" while the other process caused a series of RFCs 
to be sent to the "listening" socket until one was accepted.  Thus, no 
queueing of incoming RFCs would be required, although it would do no 
harm.  

   _It_is_the_intent_of_the_protocol_that_each_NCP_should_provide_
_either_the_"listen"_option_described_above_or_a_SUBSTANTIAL_queueing_ 
_facility._  This is not, however, an absolute requirement of the 
protocol.  


Connection Termination
====================== 

   The command used to terminate a connection is CLS (close).

        8        32            32 
     +-----+-------------+-------------+
     | CLS |  my socket  | your socket |
     +-----+-------------+-------------+

The "my socket" field contains the socket local to the sender of the CLS 
command.  The "your socket" field contains the socket local to the 
receiver of the CLS command.  _Each_side_must_send_and_receive_a_CLS_ 
_command_before_connection_termination_is_completed_and_the_sockets_are_ 
_free_to_participate_in_other_connections._ 

   It is not necessary for a connection to be established (i.e., for 
_both_ RFCs to be exchanged) before connection termination begins.  For 
example, if a Host wishes to refuse a request for connection, it sends 
back a CLS instead of a matching RFC.  The refusing Host then waits for 
the initiating Host to acknowledge the refusal by returning a CLS.  
Similarly, if a Host wishes to abort its outstanding request for a 
connection, it sends a CLS command.  The foreign Host is obliged to 
acknowledge the CLS with its own CLS.  Note that even though the 
connection was never established, CLS commands must be exchanged before 
the sockets are free for other use.  

   After a connection is established, CLS commands sent by the receiver 
and sender have slightly different effects.  CLS commands sent by the 
sender indicate that no more messages will be sent over the connection.  
_This_command_must_not_be_sent_if_there_is_a_message_in_transit_over_
_the_connection._  A CLS command sent by the receiver acts as a demand 
on the sender to terminate transmission.  However, since there is a 


McKenzie & Crocker      Expires February 9, 2012               [Page 15]

Internet Draft   Host-Host Protocol for the ARPA Network  August 8, 2011


delay in getting the CLS command to the sender, the receiver must expect 
more input.  

   A Host should "quickly" acknowledge an incoming CLS so the foreign 
Host can purge its tables.  However, _there_is_no_prescribed_time_
_period_in_which_a_CLS_must_be_acknowledged._ 

   Because the CLS command is used both to initiate closing, aborting 
and refusing a connection, and to acknowledge closing, aborting and 
refusing a connection, race conditions can occur.  However, they do not 
lead to ambiguous or erroneous results, as illustrated in the following 
examples.  

   EXAMPLE 1: Suppose that Host A sends Host B a request for connection,
   and then A sends a CLS to Host B because it is tired of waiting for a
   reply.  However, just when A sends its CLS to B, B sends a CLS to A
   to refuse the connection.  A will "believe" B is acknowledging the
   abort, and B will "believe" A is acknowledging its refusal, but the
   outcome will be correct.  

   EXAMPLE 2: Suppose that Host A sends Host B an RFC followed by a CLS
   as in example 1.  In this case, however, B sends a matching RFC to A
   just when A sends its CLS.  Host A may "believe" that the RFC is an
   attempt (on the part of B) to establish a new connection or may
   understand the race condition; in either case it can discard the RFC
   since its socket is not yet free.  Host B will "believe" that the CLS
   is breaking an _established_ connection, but the outcome is correct
   since a matching CLS is the required response, and both A and B will
   then terminate the connection.  

   Every NCP implementation is faced with the problem of what to do if a 
matching CLS is not returned "quickly" by a foreign Host (i.e., if the 
foreign Host appears to be violating protocol in this respect).  One 
naive answer is to hold the connection in a partially closed state 
"forever" waiting for a matching CLS.  There are two difficulties with 
this solution.  First, the socket involved may be a "scarce resource" 
such as the "logger" socket specified by an Initial Connection Protocol 
(see NIC # 7101) which the local Host cannot afford to tie up 
indefinitely.  Second, a partially broken (or malicious) process in a 
foreign Host may send an unending stream of RFCs which the local Host 
wishes to refuse by sending CLS commands and waiting for a match.  This 
could, in worst cases, require 2-to-the-32nd-power! socket pairs to be 
stored before duplicates began to appear.  Clearly, no Host is prepared 
to store (or search) this much information.  

   A second possibility sometimes suggested is for the Host which is 
waiting for matching CLS commands (Host A) to send a RST (see page 20) 
to the offending Host (Host B), thus allowing all tables to be
reinitialized at both ends.  This would be rather unsatisfactory to any


McKenzie & Crocker      Expires February 9, 2012               [Page 16]

Internet Draft   Host-Host Protocol for the ARPA Network  August 8, 2011


user at Host A who happened to be performing useful work on Host B via 
network connections, since these connections would also be broken by 
the RST.  

   Most implementers, recognizing these problems, have adopted some 
unofficial timeout period after which they "forget" a connection even if 
a matching CLS has not been received.  The danger with such an 
arrangement is that if a second connection between the same pair of 
sockets is later established, and a CLS finally arrives for the first 
connection, the second connection is likely to be closed.  This 
situation can only arise, however, if one Host violates protocol in two 
ways; first by failing to respond quickly to an incoming CLS, and second 
by permitting establishment of a connection involving a socket which it 
believes is already in use.  It has been suggested that the network 
adopt some standard timeout period, but the NWG has been unable to 
arrive at a period which is both short enough to be useful and long 
enough to be acceptable to every Host.  Timeout periods in current use 
seem to range between approximately one minute and approximately five 
minutes.  _It_must_be_emphasized_that_all_timeout_periods,_although_
_they_are_relatively_common,_reasonably_safe,_and_quite_useful,_are_in_
_violation_of_the_protocol_since_their_use_can_lead_to_connection_
_ambiguities._ 


Flow Control
============ 

   After a connection is established, the sending Host sends messages 
over the agreed-upon link to the receiving Host.  The receiving NCP 
accepts messages from its IMP and queues them for its various processes.  
Since it may happen that the messages arrive faster than they can be 
processed, some mechanism is required which permits the receiving Host 
to quench the flow from the sending Host.  

The flow control mechanism requires the receiving Host to allocate 
buffer space for each connection and to notify the sending Host of how 
much space is available.  The sending Host keeps track of how much room 
is available and never sends more data than it believes the receiving 
Host can accept.  

   To implement this mechanism, the sending Host keeps two counters 
associated with each connection, a _message_counter_ and a_bit_counter._ 
Each counter is initialized to zero when the connection is established 
and is increased by allocate (ALL) control commands sent from the 
receiving Host as described below.  When sending a message, the NCP of 
the sending Host subtracts one from the message counter and the _text_ 
_length_ (defined below) from the bit counter.  The sender is prohibited 
from sending if either counter would be decremented below zero.  The 
sending Host may also return all or part of the message or bit space 


McKenzie & Crocker      Expires February 9, 2012               [Page 17]

Internet Draft   Host-Host Protocol for the ARPA Network  August 8, 2011


allocation with a return (RET) command upon receiving a give-back (GVB) 
command from the receiving Host (see below).

   The _text_length_ of a message is defined as the product of the 
connection byte size and the byte count for the message; both of these 
quantities appear in the message header.  Messages with a zero byte 
count, hence a zero text length, are specifically permitted.  Messages 
with zero text length do not use bit space allocation, but do use 
message space allocation.  The flow control mechanisms do not pertain to 
the control link, since connections are never explicitly established 
over this link.  

   The control command used to increase the sender's bit counter and 
message counter is ALL (allocate).  

        8      8       16           32 
     +------------------------------------+
     | ALL | link | msg space | bit space |
     +------------------------------------+

This command is sent only from the receiving Host to the sending Host, 
and is legal only when a connection using the link number appearing in 
the "link" field is established.  The "msg space" field and the "bit 
space" field are defined to be unsigned binary integers specifying the 
amounts by which the sender's message counter and bit counter 
(respectively) are to be incremented.  The receiver is prohibited from 
incrementing the sender's counter above (2-to-the-16th-power minus 1), 
or the sender's bit counter above (2-to-the 32nd-power minus 1).  In 
general, this rule will require the receiver to maintain counters which 
are incremented and decremented according to the same rules as the 
sender's counters.  

   The receiving Host may request that the sending Host return all or 
part of its current allocation.  The control command for this request is 
GVB (give-back).

        8      8    8    8 
     +----------------------+
     | GVB | link | fm | fb |
     +----------------------+

This command is sent only from the receiving Host to the sending Host, 
and is legal only when a connection using the link number in the "link" 
field is established.  The fields fm and fb are defined as the fraction 
(in 128ths) of the current message space allocation and bit space 
allocation (respectively) to be returned.  If either of the fractions is 
equal to or greater than one, _all_ of the corresponding allocation must 
be returned.  Fractions are used since, with messages in transit, the
sender and receiver may not agree on the actual allocation at every 
point in time. 

McKenzie & Crocker      Expires February 9, 2012               [Page 18]

Internet Draft   Host-Host Protocol for the ARPA Network  August 8, 2011


   Upon receiving a GVB command, the sending Host must return _at_
_least_* the requested portions of the message and bit space 
allocations.  (A sending Host is prohibited from spontaneously returning 
portions of the message and bit space allocations.) The control command 
for performing this function is RET (return).  

   [*In particular, fractional returns must be rounded up, not
   truncated.]

        8      8       16           32 
     +------------------------------------+
     | RET | link | msg space | bit space |
     +------------------------------------+

This command is sent only from the sending Host to the receiving Host, 
and is legal only when a connection using the link number in the "link" 
field is established and a GVB command has been received from the 
receiving Host.  The "msg space" field and the "bit space" field are 
defined as unsigned binary integers specifying the amounts by which the 
sender's message counter and bit counter (respectively) have been 
decremented due to the RET activity (i.e., the amounts of message and 
bit space allocation being returned).  NCPs are obliged to answer a GVB 
with a RET "quickly"; however, there is _no_ prescribed time period in 
which the answering RET must be sent.  

Some Hosts will allocate only as much space as they can guarantee for 
each link.  These Hosts will tend to use the GVB command only to reclaim 
space which is being filled very slowly or not at all.  Other Hosts will 
allocate more space than they have, so that they may use their space 
more efficiently.  Such a Host will then need to use the GVB command 
when the input over a particular link comes faster than it is being 
processed.  

Interrupts
========== 

   The second level protocol has included a mechanism by which the 
transmission over a connection may be "interrupted." The meaning of the 
"interrupt" is not defined at this level, but is made available for use 
by outer layers of protocol.  The interrupt command sent from the 
receiving Host to the sending Host is INR (interrupt-by-receiver).  

        8      8 
     +------------+
     | INR | link |
     +------------+

The interrupt command sent from the sending Host to the receiving Host 
is INS (interrupt-by-sender).


McKenzie & Crocker      Expires February 9, 2012               [Page 19]

Internet Draft   Host-Host Protocol for the ARPA Network  August 8, 2011  


        8      8 
     +------------+
     | INS | link |
     +------------+

The INR and INS commands are legal only when a connection using the link 
number in the "link" field is established.  


Test Inquiry
============ 

   It may sometimes be useful for one Host to determine if some other 
Host is capable of carrying on network conversations.  The control 
command to be used for this purpose is ECO (echo).  

        8      8 
     +------------+
     | ECO | data |
     +------------+

The "data" field may contain any bit configuration chosen by the Host 
sending the ECO.  Upon receiving an ECO command an NCP must respond by 
returning the data to the sender in an ERP (echo-reply) command.  

        8      8 
     +------------+
     | ERP | data |
     +------------+

A Host should "quickly" respond (with an ERP command) to an incoming ECO 
command.  However, there is no prescribed time period, after the receipt 
of an ECO, in which the ERP must be returned.  A Host is prohibited from 
sending an ERP when no ECO has been received, or from sending an ECO to 
a Host while a previous ECO to that Host remains "unanswered."  Any of 
the following constitute an "answer" to an ECO: information from the 
local IMP that the ECO was discarded by the network (e.g., IMP/Host 
message type 7 - Destination Dead), ERP, RST, or RRP (see below).  


Reinitialization 
================

   Occasionally, due to lost control messages, system "crashes", NCP 
errors, or other factors, communication between two NCPs will be 
disrupted.  One possible effect of any such disruption might be that 
neither of the involved NCPs could be sure that its stored information 
regarding connections with the other Host matched the information stored 



McKenzie & Crocker      Expires February 9, 2012               [Page 20]

Internet Draft   Host-Host Protocol for the ARPA Network  August 8, 2011


by the NCP of the other Host.  In this situation, an NCP may wish to 
reinitialize its tables and request that the other Host do likewise; for 
this purpose the protocol provides the pair of control commands RST 
(reset) and RRP (reset-reply).  

        8 
     +-----+
     | RST |
     +-----+

         8 
     +-----+
     | RRP |
     +-----+

The RST command is to be interpreted by the Host receiving it as a 
signal to purge its NCP tables of any entries which arose from 
communication with the Host which sent the RST.  The Host sending the 
RST should likewise purge its NCP tables of any entries which arise from 
communication with the Host to which the RST was sent.  The Host 
receiving the RST should acknowledge receipt by returning an RRP.  
_Once_the_first_Host_has_sent_an_RST_to_the_second_Host,_the_first_Host_
_is_not_obliged_to_communicate_with_the_second_Host_(except_for_
_responding_ _to_RST)_until_the_second_Host_returns_an_RRP._  In fact, 
to avoid synchronization errors, the first Host _should_not_ communicate 
with the second until the RST is answered.  Of course, if the IMP 
subnetwork returns a "Destination Dead" (type 7) message in response to 
the control message containing the RST, an RRP should not be expected.  
If both NCPs decide to send RSTs at approximately the same time, then 
each Host will receive an RST and each must answer with an RRP, even 
though its own RST has not yet been answered.  

   Some Hosts may choose to "broadcast" RSTs to the entire network when 
they "come up." One method of accomplishing this would be to send an RST 
command to each of the 256 possible Host addresses; the IMP subnetwork 
would return a "Destination Dead" (type 7) message for each non-existent 
Host, as well as for each Host actually "dead."  _However,_no_Host_is_ 
_ever_obliged_to_transmit_an_RST_command._ 

   Hosts are prohibited from sending an RRP when no RST has been 
received.  Further, Hosts may send only one RST in a single control 
message and should wait a "reasonable time" before sending another RST 
to the same Host.  Under these conditions, a single RRP constitutes an 
"answer" to _all_ RSTs sent to that Host, and any other RRPs arriving 
from that Host should be discarded.  






McKenzie & Crocker      Expires February 9, 2012               [Page 21]

Internet Draft   Host-Host Protocol for the ARPA Network  August 8, 2011


                    IV.  DECLARATIVE SPECIFICATIONS

Message Format
============== 

   All Host-to-Host messages (i.e., messages of type zero) shall have a 
header 72 bits long consisting of the following fields (see Figure 1): 

   Bits 1-32   Leader - The contents of this field must be constructed
               according to the specifications contained in BBN Report
               Number 1822.  

   Bits 33-40  Field M1 - Must be zero.  

   Bits 41-48  Field S - Connection byte size.  This size must be
               identical to the byte size in the STR used in
               establishing the connection.  If this message is being
               transmitted over the control link the connection byte
               size must be 8.  

   Bits 49-64  Field C - Byte Count.  This field specifies the number of
               bytes in the text portion of the message.  A zero value
               in the C field is explicitly permitted.  

   Bits 65-72  Field M2 - Must be zero.  

Following the header, the message shall consist of a text field of C 
bytes, where each byte is S bits in length.  Following the text there 
will be field M3 followed by padding.  The M3 field is zero or more bits 
long and must be all zero; this field may be used to fill out a message 
to a word boundary.  


   

















McKenzie & Crocker      Expires February 9, 2012               [Page 22]

Internet Draft   Host-Host Protocol for the ARPA Network  August 8, 2011



   |<---------------------------32 bits--------------------------->|
   |<----8 bits--->|<----8 bits--->|<-----------16 bits----------->|

   +---------------------------------------------------------------+
   |                                                               |
   |                             LEADER                            |
   |                                                               |
   +---------------------------------------------------------------|
   |               |               |                               |
   |    FIELD M1   |    FIELD S    |            FIELD C            |
   |               |               |                               |
   +---------------+---------------+-------------------------------+
   |               |               ^                               |
   |    FIELD M2   |               |                               |
   |               |               |                               |
   +---------------+               |                               |
   |                               |                               |
   |                               |                               |
   |                               |                               |
   |                               |                               |
   |                             TEXT                              |
   |                               |                               |
   |                               |                               |
   |                               |                               |
   |                               |                               |
   |                               |          +--------------------+
   |                               |          |                    |
   |                               |          |      FIELD M3      |
   |                               V          |                    |
   +-----------------------------------+------+--------------------+
   |                                   |
   |      10-----------------0         |<-------PADDING
   |                                   |
   +-----------------------------------+

                               Figure 1
                               ========

   The message header must, among other things, enable the NCP at the 
receiving Host to identify correctly the connection over which the 
message was sent.  Given a set of messages from Host A to Host B, the 
only field in the header under the control of the NCP at Host B is the 
link number (assigned via the RTS control command).  Therefore, each NCP 
must insure that, at a given point in time, for each connection for 
which it is the receiver, a unique link is assigned.  Recall that the 
link is specified by the sender's address and the link number; thus a 
unique link number must be assigned to each connection to a given Host.
 


McKenzie & Crocker      Expires February 9, 2012               [Page 23]

Internet Draft   Host-Host Protocol for the ARPA Network  August 8, 2011


Link Assignment
=============== 

   Links are assigned as follows: 

   Link number    Assignment
   ===========    ========== 

   0              Control link 

   2-71           Available for connections 

   1, 72-190      Reserved - not for current use 

   191            To be used only for measurement work under the
                  direction of the Network Measurement Center at UCLA

   192-255        Available for private experimental use.
 

Control Messages
================ 

   Messages sent over the control link have the same format as other 
Host-to-Host messages.  The connection byte size (Field S in the message 
header) must be 8.  Control messages may not contain more than 120 bytes 
of text; thus the value of the byte count (Field C in the message 
header) must be less than or equal to 120.  

   Control messages must contain an integral number of control commands.  
A single control command may not be split into parts which are 
transmitted in different control messages.
 

Control Commands
================ 

   Each control command begins with an 8-bit _opcode._  These opcodes 
have values of 0, 1, ...  to permit table lookup upon receipt.  Private 
experimental protocols should be tested using opcodes of 255, 254, ...  
Most of the control commands are more fully explained in Section III.  










McKenzie & Crocker      Expires February 9, 2012               [Page 24]

Internet Draft   Host-Host Protocol for the ARPA Network  August 8, 2011


NOP - No operation
==================

        8 
     +-----+
     | NOP |
     +-----+ 

The NOP command may be sent at any time and should be discarded by the 
receiver.  It may be useful for formatting control messages.  

RST - Reset
===========

        8
     +-----+
     | RST |
     +-----+

The RST command is used by one Host to inform another that all 
information regarding previously existing connections, including 
partially terminated connections, between the two Hosts should be purged 
from the NCP tables of the Host receiving the RST.  Except for 
responding to RSTs, the Host which sent the RST is not obliged to 
communicate further with the other Host until an RRP is received in 
response.  

RRP - Reset reply
================= 

        8 
     +-----+
     | RRP |
     +-----+

The RRP command must be sent in reply to an RST command.  

RTS - Request connection, receiver to sender
============================================

        8          32               32           8 
     +----------------------------------------------+
     | RTS | receive socket |  send socket   | link |
     +----------------------------------------------+

RTS receive socket send socket link The RTS command is used to establish 
a connection and is sent from the Host containing the receive socket to 
the Host containing the send socket.  The link number for message 



McKenzie & Crocker      Expires February 9, 2012               [Page 25]

Internet Draft   Host-Host Protocol for the ARPA Network  August 8, 2011


transmission over the connection is assigned with this command; the 
"link" field must be between 2 and 71, inclusive.

STR - Request connection, sender to receiver
============================================
 
        8          32               32           8 
     +----------------------------------------------+
     | STR |   send socket  | receive socket | size |
     +----------------------------------------------+

The STR command is used to establish a connection and is sent from the 
Host containing the send socket to the Host containing the receive 
socket.  The connection byte size is assigned with this command; the 
size must be between 1 and 255, inclusive.  

CLS - Close
=========== 

        8        32            32 
     +-----+-------------+-------------+
     | CLS |  my socket  | your socket |
     +-----+-------------+-------------+

The CLS command is used to terminate a connection.  A connection need 
not be completely established before a CLS is sent.  

ALL - Allocate
============== 

        8      8       16           32 
     +------------------------------------+
     | ALL | link | msg space | bit space |
     +------------------------------------+ 

The ALL command is sent from a receiving Host to a sending Host to 
increase the sending Host's space counters.  This command may be sent 
only while the connection is established.  The receiving Host is 
prohibited from incrementing the Host's message counter above (2-to-the- 
16th-power minus 1) or bit counter above (2-to-the-32nd-power minus 1).











McKenzie & Crocker      Expires February 9, 2012               [Page 26]

Internet Draft   Host-Host Protocol for the ARPA Network  August 8, 2011


GVB - Give back
=============== 

        8      8    8    8 
     +----------------------+
     | GVB | link | fm | fb |
     +----------------------+
                    ^    ^
                    |    +--- bit fraction
                    +-------- message fraction

The GVB command is sent from a receiving Host to a sending Host to 
request that the sending Host return all or part of its message space 
and/or bit space allocations.  The "fractions" specify what portion (in 
128ths) of each allocation must be returned.  This command may be sent 
only while the connection is established.  

RET - Return
============
 
        8      8       16           32 
     +------------------------------------+
     | RET | link | msg space | bit space |
     +------------------------------------+
 

The RET command is sent from the sending Host to the receiving Host to 
return all or a part of its message space and/or bit space allocations 
in response to a GVB command.  This command may be sent only while the 
connection is established.  

INR - Interrupt by receiver
===========================
 
        8      8 
     +------------+
     | INR | link |
     +------------+
 

The INR command is sent from the receiving Host to the sending Host when 
the receiving process wants to interrupt the sending process.  This 
command may be sent only while the connection is established.





  


McKenzie & Crocker      Expires February 9, 2012               [Page 27]

Internet Draft   Host-Host Protocol for the ARPA Network  August 8, 2011


INS - Interrupt by sender
=========================
 
        8      8 
     +------------+
     | INS | link |
     +------------+

The INS command is sent from the sending Host to the receiving Host when 
the sending process wants to interrupt the receiving process.  This 
command may be sent only while the connection is established.  

ECO - Echo request
==================
 
        8      8 
     +------------+
     | ECO | data |
     +------------+

The ECO command is used only for test purposes.  The data field may be 
any bit configuration convenient to the Host sending the ECO command.  

ERP - Echo reply
================ 

        8      8 
     +------------+
     | ERP | data |
     +------------+

The ERP command must be sent in reply to an ECO command.  The data field 
must be identical to the data field in the incoming ECO command.  
 
ERR - Error detected
====================
 
        8      8                    80 
     +-----+------+---------------------------- ~ -------------+
     | ERR | code |                data                        |
     +-----+------+---------------------------- ~ -------------+ 

The ERR command may be sent whenever a second level protocol error is 
detected in the input from another Host.  In the case that the error 
condition has a predefined error code, the "code" field specifies the 
specific error, and the data field gives parameters.  For other errors 
the code field is zero and the data field is idiosyncratic to the 
sender.  Implementers of Network Control Programs are expected to 
publish timely information on their ERR commands.


McKenzie & Crocker      Expires February 9, 2012               [Page 28]

Internet Draft   Host-Host Protocol for the ARPA Network  August 8, 2011


   The usefulness of the ERR command is compromised if it is merely 
discarded by the receiver.  Thus, sites are urged to record incoming 
ERRs if possible, and to investigate their cause in conjunction with the 
sending site.  The following codes are defined.  Additional codes may be 
defined later.  

   a. Undefined (Error code = 0) 
      The "data" field is idiosyncratic to the sender.

   b. Illegal opcode (Error code = 1)
      An illegal opcode was detected in a control message.  The "data"
      field contains the ten bytes of the control message beginning with
      the byte containing the illegal opcode.  If the remainder of the
      control message contains less than ten bytes, fill will be
      necessary; the value of the fill is zeros.

   c. Short parameter space (Error code = 2)
      The end of a control message was encountered before all the
      required parameters of the control command being decoded were
      found.  The "data" field contains the command in error; the value
      of any fill necessary is zeros.

   d. Bad parameters (Error code = 3)
      Erroneous parameters were found in a control command.  For
      example, two receive or two send sockets in an STR, RTS, or CLS;
      a link number outside the range 2 to 71 (inclusive); an ALL
      containing a space allocation too large.  The "data" field
      contains the command in error; the value of any fill necessary is
      zeros.  

   e. Request on a non-existent socket (Error code = 4)
      A request other than STR or RTS was made for a socket (or link)
      for which no RFC has been transmitted in either direction.  This
      code is meant to indicate to the NCP receiving it that functions
      are being performed out of order.  The "data" field contains the
      command in error; the value of any fill necessary is zeros.

   f. Socket (link) not connected (Error code = 5)
      There are two cases:

      1.  A control command other than STR or RTS refers to a socket (or
         link) which is not part of an established connection.  This
         code would be used when one RFC had been transmitted, but the
         matching RFC had not.  It is meant to indicate the failure of
         the NCP receiving it to wait for a response to an RFC.  The
         "data" field contains the command in error; the value of any
         fill necessary is zeros.

 


McKenzie & Crocker      Expires February 9, 2012               [Page 29]

Internet Draft   Host-Host Protocol for the ARPA Network  August 8, 2011


      2. A message was received over a link which is not currently being
         used for any connection.  The contents of the "data" field are
         the message header followed by the first eight bits of text (if
         any) or zeros.  













































 

McKenzie & Crocker      Expires February 9, 2012               [Page 30]

Internet Draft   Host-Host Protocol for the ARPA Network  August 8, 2011


Opcode Assignment
================= 

   Opcodes are defined to be eight-bit unsigned binary numbers.  The 
values assigned to opcodes are: 

   NOP = 0
   RTS = 1
   STR = 2
   CLS = 3
   ALL = 4
   GVB = 5
   RET = 6
   INR = 7
   INS = 8
   ECO = 9
   ERP = 10 
   ERR = 11
   RST = 12
   RRP = 13 


Control Command Summary 
=======================

        8 
     +-----+
     | NOP |
     +-----+

        8          32               32           8 
     +----------------------------------------------+
     | RTS | receive socket |  send socket   | link |
     +----------------------------------------------+

        8          32               32           8 
     +----------------------------------------------+
     | STR |   send socket  | receive socket | size |
     +----------------------------------------------+

        8        32            32 
     +-----+-------------+-------------+
     | CLS |  my socket  | your socket |
     +-----+-------------+-------------+

        8      8       16           32 
     +------------------------------------+
     | ALL | link | msg space | bit space |
     +------------------------------------+ 
 

McKenzie & Crocker      Expires February 9, 2012               [Page 31]

Internet Draft   Host-Host Protocol for the ARPA Network  August 8, 2011


        8      8    8    8 
     +----------------------+
     | GVB | link | fm | fb |
     +----------------------+

        8      8       16           32 
     +------------------------------------+
     | RET | link | msg space | bit space |
     +------------------------------------+

        8      8 
     +------------+
     | INR | link |
     +------------+

        8      8 
     +------------+
     | INS | link |
     +------------+

        8      8 
     +------------+
     | ECO | data |
     +------------+

        8      8 
     +------------+
     | ERP | data |
     +------------+

        8      8                    80 
     +-----+------+---------------------------- ~ -------------+
     | ERR | code |                data                        |
     +-----+------+---------------------------- ~ -------------+

        8
     +-----+
     | RST |
     +-----+

        8 
     +-----+
     | RRP |
     +-----+




[ This is the end of the January 1972 document.  ]


McKenzie & Crocker      Expires February 9, 2012               [Page 32]

Internet Draft   Host-Host Protocol for the ARPA Network  August 8, 2011


4. Security Considerations

   This document does not discuss any security considerations.

5. Authors' Addresses

   Alexander McKenzie
   PMB #4334, PO Box 2428
   Pensacola, FL 32513
   amckenzie3 at yahoo dot com

   Steve Crocker
   5110 Edgemoor Lane
   Bethesda, MD 20814
   USA
   steve at stevecrocker dot com
































           This Internet-Draft will expire on February 9, 2012.

 
McKenzie & Crocker      Expires February 9, 2012               [Page 33]