rfc33.txt

著名的RFC文档,其中有一些文档是已经翻译成中文的的.

Network Working Group                                         S. Crocker
Request for Comments: 33                                            UCLA
                                                                 S. Carr
                                                      University of Utah
                                                                 V. Cerf
                                                                    UCLA
                                                        12 February 1973


                         New HOST-HOST Protocol

   Attached is a copy of the paper to be presented at the SJCC on the
   HOST-HOST Protocol.  It indicates many changes from the old protocol
   in NWG/RFC 11; these changes resulted from the network meeting on
   December 8, 1969.  The attached document does not contain enough
   information to write a NCP, and I will send out another memo or so
   shortly.  Responses to this memo are solicited, either as NWG/RFC's
   or personal notes to me.


                     HOST-HOST Communication Protocol
                           in the ARPA Network*

   by C. Stephen Carr
   University of Utah
   Salt Lake City, Utah

   and

   by Stephen D. Crocker
   University of California
   Los Angeles, California

   and

   by Vinton G. Cerf
   University of California
   Los Angeles, California

   *This research was sponsored by the Advanced Research Projects
   Agency, Department of Defense, under contracts AF30(602)-4277 and
   DAHC15-69-C-0825.

INTRODUCTION

   The Advanced Research Projects Agency (ARPA) Computer Network
   (hereafter referred to as the "ARPA network") is one of the most
   ambitious computer networks attempted to date.  [1]  The types of



Crocker, et. al.                                                [Page 1]

RFC 33                   New HOST-HOST Protocol         12 February 1970


   machines and operating systems involved in the network vary widely.
   For example, the computers at the first four sites are an XDS 940
   (Stanford Research Institute), an IBM 360/75 (University of
   California, Santa Barbara), an XDS SIGMA-7 (University of California,
   Los Angeles), and a DEC PDP-10 (University of Utah).  The only
   commonality among the network membership is the use of highly
   interactive time-sharing systems; but, of course, these are all
   different in external appearance and implementation.  Furthermore, no
   one node is in control of the network.  This has insured reliability
   but complicates the software.

   Of the networks which have reached the operational phase and been
   reported in the literature, none have involved the variety of
   computers and operating systems found in the ARPA network.  For
   example, the Carnegie-Mellon, Princeton, IBM network consists of
   360/67's with identical software. [2]  Load sharing among identical
   batch machines was commonplace at North American Rockwell Corporation
   in the early 1960's.  Therefore, the implementers of the present
   network have been only slightly influenced by earlier network
   attempts.

   However, early time-sharing studies at the University of California
   at Berkeley, MIT, Lincoln Laboratory, and System Development
   Corporation (all ARPAA sponsored) have had considerable influence on
   the design of the network.  In some sense, the ARPA network of time-
   shared computers is a natural extension of earlier time-sharing
   concepts.

   The network is seen as a set of data entry and exit points into which
   individual computers insert messages destined for another (or the
   same) computer, and from which such messages emerge.  The format of
   such messages and the operation of the network was specified by the
   network contractor (BB&N) and it became the responsibility of
   representatives of the various computer sites to impose such
   additional constraints and provide such protocol as necessary for
   users at one site to use resources at foreign sites.  This paper
   details the decisions that have been made and the considerations
   behind these decisions.

   Several people deserve acknowledgement in this effort.  J. Rulifson
   and W. Duvall of SRI participated in the early design effort of the
   protocol and in the discussions of NIL.  G. Deloche of Thompson-CSF
   participated in the design effort while he was at UCLA and provided
   considerable documentation.  J. Curry of Utah and P. Rovner of
   Lincoln Laboratory reviewed the early design and NIL.  W. Crowther of
   Bolt, Beranek and Newman, contributed the idea of a virtual net.  The
   BB&N staff provided substantial assistance and guidance while
   delivering the network.



Crocker, et. al.                                                [Page 2]

RFC 33                   New HOST-HOST Protocol         12 February 1970


   We have found that, in the process of connecting machines and
   operating systems together, a great deal of rapport has been
   established between personnel at the various network node sites.  The
   resulting mixture of ideas, discussions, disagreements, and
   resolutions has been highly refreshing and beneficial to all
   involved, and we regard the human interaction as a valuable by-
   product of the main effect.

THE NETWORK AS SEEN BY THE HOSTS

   Before going on to discuss operating system communication protocol,
   some definitions are needed.

      A HOST is a computer system which is a part of the network,

      An IMP (Interface Message Processor) is a Honeywell DDP-516
      computer which interfaces with up to four HOSTs at a particular
      site, and allows HOSTs access into the network.  The configuration
      of the initial four-HOST network is given in figure 1.  The IMPs
      from a store-and-forward communications network.  A companion
      paper in these proceedings covers the IMPs in some detail. [3]

   A message is a bit stream less than 8096 bits long which is given to
   an IMP by a HOST for transmission to another HOST.  The first 32 bits
   of the message are the leader.  The leader contains the following
   information:

      (a) HOST
      (b) Message Type
      (c) Flags
      (d) Link Number

   When a message is transmitted from a HOST to its IMP, the HOST field
   of the leader names the receiving HOST.  When the message arrives at
   the receiving HOST, the HOST field names the sending HOST.

   Only two message types are of concern in this paper.  Regular
   messages are generated by a HOST and sent to its IMP for transmission
   to a foreign HOST.  The other message type of interest is a RFNM
   (Request-for-Next-Message).  RFNM's are explained in conjunction with
   links.

   The flag field of the leader controls special cases not of concern
   here.







Crocker, et. al.                                                [Page 3]

RFC 33                   New HOST-HOST Protocol         12 February 1970


   The link number identifies over which of 256 logical paths (links)
   between the sending HOST and the receiving HOST the message will be
   sent.  Each link is unidirectional and is controlled by the network
   so that no more than one message at a time may be sent over it.  This
   control is implemented using RFNM messages.  After a sending HOST has
   sent a message to a receiving HOST over a particular link, the
   sending HOST is prohibited from sending another message over that
   same link until the sending HOST receives a RFMN.  The RFNM is
   generated by the IMP connected to the receiving HOST, and the RFNM is
   sent back to the sending HOST after the message has entered the
   receiving HOST.  It is important to remember that there are 356 links
   in each direction and that no relationship among these is imposed by
   the network.

   The purpose of the link and RFMN mechanism is to prohibit individual
   users from overloading an IMP or a HOST.  Implicit in this purpose is
   the assumption that a user does not use multiple links to achieve a
   wide band, and to a large extent the HOST-HOST protocol cooperates
   with this assumption.  An even more basic assumption, of course, is
   that the network's load comes from some users transmitting sequences
   of messages rather than many users transmitting single messages
   coincidently.

   In order to delimit the length of the message, and to make it easier
   for HOSTs of differing word lengths to communicate, the following
   formatting procedure is used.  When a HOST prepares a message for
   output, it creates a 32-bit leader.  Following the leader is a binary
   string, called marking, consisting of an arbitrary number of zeros,
   followed by one.  Marking makes is possible for the sending HOST to
   synchronize the beginning of the text message with its word
   boundaries.  When the last bit of a message has entered an IMP, the
   hardware interface between the IMP and HOST appends a one followed by
   enough zeros to make the message length a multiple of 16 bits.  These
   appended bits are called padding.  Except for the marking and
   padding, no limitations are placed on the text of a message.  Figure
   2 shows a typical message sent by a 24-bit machine.

DESIGN CONCEPTS

   The computers participating in the network are alike in two important
   respects: each supports research independent of the network, and each
   is under the discipline of a time-sharing system.  These facts
   contributed to the following design philosophy.

   First, because the computers in the network have independent purposes
   it is necessary to preserve decentralized administrative control of
   the various computers.  Since all of the time-sharing supervisors
   possess elaborate and definite accounting and resource allocation



Crocker, et. al.                                                [Page 4]

RFC 33                   New HOST-HOST Protocol         12 February 1970


   mechanisms, we arranged matters so that these mechanisms would
   control the load due to the network in the same way that they control
   locally generated load.

   Second, because the computers are all operated under time-sharing
   disciplines, it seemed desirable to facilitate basic interactive
   mechanisms.

   Third, because this network is used by experienced programmers it was
   imperative to provide the widest latitude in using the network.
   Restrictions concerning character sets, programming languages, etc.
   would not be tolerated and we avoided such restrictions.

   Fourth, again because the network is used by experienced programmers,
   it was felt necessary to leave the design open-ended.  We expect that
   conventions will arise from time to time as experience is gained, but
   we felt constrained not to impose them arbitrarily.

   Fifth, in order to make network participation comfortable, or in some
   cases, feasible, the software interface to the network should require
   minimal surgery on the HOST operating system.

   Finally, we except the assumption stated above that network use
   consists of prolonged conversations instead of one-shot requests.

   These considerations led to the notions of connections, a Network
   Control Program, a control link, control commands, sockets, and
   virtual nets.

   A connection is an extension of a link.  A connection connects two
   processes so that output from one process is input to the other.
   Connections are simplex, so two connections are needed if two
   processes are to converse in both directions.

   Processes within a HOST communicate with the network through a
   Network Control Program (NCP).  In most HOSTs, the NCP will be a part
   of the executive, so that processes will use system calls to
   communicate with it.  The primary function of the NCP is to establish
   connections, break connections, switch connections, and control flow.

   In order to accomplish its tasks, a NCP in one HOST must communicate
   with a NCP in another HOST.  To this end, a particular link between
   each pair of HOSTs has been designated as the control link.  Messages
   received over the control link are always interpreted by the NCP as a
   sequence of one or more control commands.  As an example, one of the
   kinds of control commands is used to assign a link and initiate a





Crocker, et. al.                                                [Page 5]

RFC 33                   New HOST-HOST Protocol         12 February 1970


   connection, while another kind carries notification that a connection
   has been terminated.  A partial sketch of the syntax and semantics of
   control commands is given in the next section.

   A major issue is how to refer to processes in a foreign HOST.  Each
   HOST has some internal naming scheme, but these various schemes often
   are incompatible.  Since it is not practical to impose a common
   internal process naming scheme, an intermediate name space was
   created with a separate portion of the name space given to each HOST.
   It is left to each HOST to map internal process identifiers into its
   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 specified by the concatenation of three
   numbers:

      (a) a user number (24 bits)
      (b) a HOST number (8 bits)
      (c) AEN (8 bits)

   A typical socket is illustrated in Figure 3.

   Each HOST is assigned all sockets in the name space which have field
   (b) equal to the HOST's own identification.

   A socket is either a receive socket or a send socket, and is so
   marked by the lower-order bit of the AEN (0 = receive, 1 = send).
   The other seven bits of the AEN simply provide a sizable population
   of sockets for each used number at each HOST.  (AEN stands for
   "another eight-bit number")

   Each user is assigned a 24-bit user number which uniquely identifies
   him throughout the network.  Generally this will be the 8-bit HOST
   number of his home HOST, followed by 16 bits which uniquely identify
   him at that HOST.  Provision can also be made for a user to have a
   user number not keyed to a particular HOST, an arrangement desirable
   for mobile users who might have no home HOST or more than one home
   HOST.  This 24-bit user number is then used in the following manner.
   When a user signs onto a HOST, his user number is looked up.
   Thereafter, each process the user creates is tagged with his user
   number.  When the user signs onto a foreign HOST via the network, his
   same user number is used to tag processes he creates in that HOST.
   The foreign HOST obtains the user number either by consulting a table
   at login time, as the home HOST does, or by noticing the
   identification of the caller.  The effect of propagating the user's
   number is that each user creates his own virtual net consisting of
   processes he has created.  This virtual net may span an arbitrary



Crocker, et. al.                                                [Page 6]

RFC 33                   New HOST-HOST Protocol         12 February 1970


   number of HOSTs.  It will thus be easy for a user to connect his
   processes in arbitrary ways, while still permitting him to connect
   his processes with those in other virtual nets.

   The relationship between sockets and processes is now describable
   (see Figure 4).  For each user number at each HOST, there are 128
   send sockets and 128 receive sockets.  A process may request from the
   local NCP the use of any one of the sockets with the same user
   number; the request is granted if the socket is not otherwise in use.
   The key observation here is that a socket requested by a process
   cannot already be in use unless it is by some other process within
   the same virtual net, and such a process is controlled by the same
   user.