GENWiki

Premier IT Outsourcing and Support Services within the UK

User Tools

Site Tools


rfc:rfc6529

Independent Submission A. McKenzie Request for Comments: 6529 S. Crocker Category: Historic April 2012 ISSN: 2070-1721

              Host/Host Protocol for the ARPA Network

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 (including addressing, flow control,
 connection establishment/disestablishment, and other signaling) over
 a single hardware interface.  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 RFC at this late date to help complete the
 historical record available through the RFC series.

Status of This Memo

 This document is not an Internet Standards Track specification; it is
 published for the historical record.
 This document defines a Historic Document for the Internet community.
 This is a contribution to the RFC Series, independent of any other
 RFC stream.  The RFC Editor has chosen to publish this document at
 its discretion and makes no statement about its value for
 implementation or deployment.  Documents approved for publication by
 the RFC Editor are not a candidate for any level of Internet
 Standard; see Section 2 of RFC 5741.
 Information about the current status of this document, any errata,
 and how to provide feedback on it may be obtained at
 http://www.rfc-editor.org/info/rfc6529.

McKenzie & Crocker Historic [Page 1] RFC 6529 Host-Host Protocol for the ARPA Network April 2012

Copyright Notice

 Copyright (c) 2012 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.

Table of Contents

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

McKenzie & Crocker Historic [Page 2] RFC 6529 Host-Host Protocol for the ARPA Network April 2012

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 (NIC 8246) 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 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://www.cbi.umn.edu/hostedpublications/pdf/McKenzieNCP1972.pdf.

McKenzie & Crocker Historic [Page 3] RFC 6529 Host-Host Protocol for the ARPA Network April 2012

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 Interface Message Processor (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, whereas in
 current writings TCP is usually referred to as a layer 4 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.
 In this design, there was no checksum or other form of error control
 except for the RST.  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 Historic [Page 4] RFC 6529 Host-Host Protocol for the ARPA Network April 2012

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 Historic [Page 5] RFC 6529 Host-Host Protocol for the ARPA Network April 2012

                                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:
  1. prohibition of spontaneous RET, ERP, and RRP commands
  2. a discussion of the problem of unanswered CLS commands (page 16)
  3. a discussion of the implications of queueing and not queueing

RFCs (page 14)

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

McKenzie & Crocker Historic [Page 6] RFC 6529 Host-Host Protocol for the ARPA Network April 2012

                            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........................................20
             Test Inquiry......................................20
             Reinitialization..................................21
 IV.   DECLARATIVE SPECIFICATIONS...................................23
       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....................................23
             Link Assignment...................................25
             Control Messages..................................25
             Control Commands..................................25
             Opcode Assignment.................................31
             Control Command Summary...........................31

McKenzie & Crocker Historic [Page 7] RFC 6529 Host-Host Protocol for the ARPA Network April 2012

                           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:

McKenzie & Crocker Historic [Page 8] RFC 6529 Host-Host Protocol for the ARPA Network April 2012

 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.
 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 Historic [Page 9] RFC 6529 Host-Host Protocol for the ARPA Network April 2012

                      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.

McKenzie & Crocker Historic [Page 10] RFC 6529 Host-Host Protocol for the ARPA Network April 2012

 In order to accomplish its tasks, the NCP of one Host must
 communicate with the NCPs of other Hosts.  To this end, a particular
 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

McKenzie & Crocker Historic [Page 11] RFC 6529 Host-Host Protocol for the ARPA Network April 2012

 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.
 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 Historic [Page 12] RFC 6529 Host-Host Protocol for the ARPA Network April 2012

                          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.

McKenzie & Crocker Historic [Page 13] RFC 6529 Host-Host Protocol for the ARPA Network April 2012

 These terms apply only to data flow; control messages will, in
 general, be transmitted in both directions.
 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;

McKenzie & Crocker Historic [Page 14] RFC 6529 Host-Host Protocol for the ARPA Network April 2012

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

McKenzie & Crocker Historic [Page 15] RFC 6529 Host-Host Protocol for the ARPA Network April 2012

 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 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^32 !
 socket pairs to be stored before duplicates began to appear.

McKenzie & Crocker Historic [Page 16] RFC 6529 Host-Host Protocol for the ARPA Network April 2012

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

McKenzie & Crocker Historic [Page 17] RFC 6529 Host-Host Protocol for the ARPA Network April 2012

 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 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^16 - 1),
 or the sender's bit counter above (2^32 - 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 |
      +----------------------+

McKenzie & Crocker Historic [Page 18] RFC 6529 Host-Host Protocol for the ARPA Network April 2012

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

McKenzie & Crocker Historic [Page 19] RFC 6529 Host-Host Protocol for the ARPA Network April 2012

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

McKenzie & Crocker Historic [Page 20] RFC 6529 Host-Host Protocol for the ARPA Network April 2012

 "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 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

McKenzie & Crocker Historic [Page 21] RFC 6529 Host-Host Protocol for the ARPA Network April 2012

 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 Historic [Page 22] RFC 6529 Host-Host Protocol for the ARPA Network April 2012

                    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 Historic [Page 23] RFC 6529 Host-Host Protocol for the ARPA Network April 2012

 |<---------------------------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 Historic [Page 24] RFC 6529 Host-Host Protocol for the ARPA Network April 2012

 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 Historic [Page 25] RFC 6529 Host-Host Protocol for the ARPA Network April 2012

 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 |
      +----------------------------------------------+
 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 transmission over the

McKenzie & Crocker Historic [Page 26] RFC 6529 Host-Host Protocol for the ARPA Network April 2012

 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^16 - 1) or bit counter above (2^32 - 1).

McKenzie & Crocker Historic [Page 27] RFC 6529 Host-Host Protocol for the ARPA Network April 2012

 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 Historic [Page 28] RFC 6529 Host-Host Protocol for the ARPA Network April 2012

 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

McKenzie & Crocker Historic [Page 29] RFC 6529 Host-Host Protocol for the ARPA Network April 2012

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

McKenzie & Crocker Historic [Page 30] RFC 6529 Host-Host Protocol for the ARPA Network April 2012

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

McKenzie & Crocker Historic [Page 31] RFC 6529 Host-Host Protocol for the ARPA Network April 2012

         8        32            32
      +-----+-------------+-------------+
      | CLS |  my socket  | your socket |
      +-----+-------------+-------------+
         8      8       16           32
      +------------------------------------+
      | ALL | link | msg space | bit space |
      +------------------------------------+
         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                        |
      +-----+------+---------------------------- ~ -------------+

McKenzie & Crocker Historic [Page 32] RFC 6529 Host-Host Protocol for the ARPA Network April 2012

         8
      +-----+
      | RST |
      +-----+
         8
      +-----+
      | RRP |
      +-----+
 [ This is the end of the January 1972 document. ]

McKenzie & Crocker Historic [Page 33] RFC 6529 Host-Host Protocol for the ARPA Network April 2012

4. Security Considerations

 This document does not discuss any security considerations.

Authors' Addresses

 Alexander McKenzie
 PMB #4334, PO Box 2428
 Pensacola, FL 32513
 USA
 EMail: amckenzie3@yahoo.com
 Steve Crocker
 5110 Edgemoor Lane
 Bethesda, MD 20814
 USA
 EMail: steve@stevecrocker.com

McKenzie & Crocker Historic [Page 34]

/data/webs/external/dokuwiki/data/pages/rfc/rfc6529.txt · Last modified: 2012/04/06 20:26 by 127.0.0.1

Donate Powered by PHP Valid HTML5 Valid CSS Driven by DokuWiki