summaryrefslogtreecommitdiff
path: root/doc/rfc/rfc1.txt
diff options
context:
space:
mode:
Diffstat (limited to 'doc/rfc/rfc1.txt')
-rw-r--r--doc/rfc/rfc1.txt619
1 files changed, 619 insertions, 0 deletions
diff --git a/doc/rfc/rfc1.txt b/doc/rfc/rfc1.txt
new file mode 100644
index 0000000..1b84030
--- /dev/null
+++ b/doc/rfc/rfc1.txt
@@ -0,0 +1,619 @@
+
+
+
+
+
+
+Network Working Group Steve Crocker
+Request for Comments: 1 UCLA
+ 7 April 1969
+
+
+ Title: Host Software
+ Author: Steve Crocker
+ Installation: UCLA
+ Date: 7 April 1969
+ Network Working Group Request for Comment: 1
+
+
+CONTENTS
+
+INTRODUCTION
+
+ I. A Summary of the IMP Software
+
+ Messages
+
+ Links
+
+ IMP Transmission and Error Checking
+
+ Open Questions on the IMP Software
+
+ II. Some Requirements Upon the Host-to-Host Software
+
+ Simple Use
+
+ Deep Use
+
+ Error Checking
+
+III. The Host Software
+
+ Establishment of a Connection
+
+ High Volume Transmission
+
+ A Summary of Primitives
+
+ Error Checking
+
+ Closer Interaction
+
+ Open Questions
+
+
+
+
+Crocker [Page 1]
+
+RFC 1 Host Software 7 April 1969
+
+
+ IV. Initial Experiments
+
+ Experiment One
+
+ Experiment Two
+
+Introduction
+
+ The software for the ARPA Network exists partly in the IMPs and
+ partly in the respective HOSTs. BB&N has specified the software of
+ the IMPs and it is the responsibility of the HOST groups to agree on
+ HOST software.
+
+ During the summer of 1968, representatives from the initial four
+ sites met several times to discuss the HOST software and initial
+ experiments on the network. There emerged from these meetings a
+ working group of three, Steve Carr from Utah, Jeff Rulifson from SRI,
+ and Steve Crocker of UCLA, who met during the fall and winter. The
+ most recent meeting was in the last week of March in Utah. Also
+ present was Bill Duvall of SRI who has recently started working with
+ Jeff Rulifson.
+
+ Somewhat independently, Gerard DeLoche of UCLA has been working on
+ the HOST-IMP interface.
+
+ I present here some of the tentative agreements reached and some of
+ the open questions encountered. Very little of what is here is firm
+ and reactions are expected.
+
+I. A Summary of the IMP Software
+
+Messages
+
+ Information is transmitted from HOST to HOST in bundles called
+ messages. A message is any stream of not more than 8080 bits,
+ together with its header. The header is 16 bits and contains the
+ following information:
+
+ Destination 5 bits
+ Link 8 bits
+ Trace 1 bit
+ Spare 2 bits
+
+ The destination is the numerical code for the HOST to which the
+ message should be sent. The trace bit signals the IMPs to record
+ status information about the message and send the information back to
+ the NMC (Network Measurement Center, i.e., UCLA). The spare bits are
+ unused.
+
+
+
+Crocker [Page 2]
+
+RFC 1 Host Software 7 April 1969
+
+
+Links
+
+ The link field is a special device used by the IMPs to limit certain
+ kinds of congestion. They function as follows. Between every pair of
+ HOSTs there are 32 logical full-duplex connections over which messages
+ may be passed in either direction. The IMPs place the restriction on
+ these links that no HOST can send two successive messages over the
+ same link before the IMP at the destination has sent back a special
+ message called an RFNM (Request for Next Message). This arrangement
+ limits the congestion one HOST can cause another if the sending HOST
+ is attempting to send too much over one link. We note, however, that
+ since the IMP at the destination does not have enough capacity to
+ handle all 32 links simultaneously, the links serve their purpose only
+ if the overload is coming from one or two links. It is necessary for
+ the HOSTs to cooperate in this respect.
+
+ The links have the following primitive characteristics. They are
+ always functioning and there are always 32 of them.
+
+ By "always functioning," we mean that the IMPs are always prepared to
+ transmit another message over them. No notion of beginning or ending
+ a conversation is contained in the IMP software. It is thus not
+ possible to query an IMP about the state of a link (although it might
+ be possible to query an IMP about the recent history of a link --
+ quite a different matter!).
+
+ The other primitive characteristic of the links is that there are
+ always 32 of them, whether they are in use or not. This means that
+ each IMP must maintain 18 tables, each with 32 entries, regardless of
+ the actual traffic.
+
+ The objections to the link structure notwithstanding, the links are
+ easily programmed within the IMPs and are probably a better
+ alternative to more complex arrangements just because of their
+ simplicity.
+
+IMP Transmission and Error Checking
+
+ After receiving a message from a HOST, an IMP partitions the message
+ into one or more packets. Packets are not more than 1010 bits long
+ and are the unit of data transmission from IMP to IMP. A 24 bit
+ cyclic checksum is computed by the transmission hardware and is
+ appended to an outgoing packet. The checksum is recomputed by the
+ receiving hardware and is checked against the transmitted checksum.
+ Packets are reassembled into messages at the destination IMP.
+
+Open Questions on the IMP Software
+
+
+
+
+Crocker [Page 3]
+
+RFC 1 Host Software 7 April 1969
+
+
+ 1. An 8 bit field is provided for link specification, but only 32
+ links are provided, why?
+
+ 2. The HOST is supposed to be able to send messages to its IMP. How
+ does it do this?
+
+ 3. Can a HOST, as opposed to its IMP, control RFNMs?
+
+ 4. Will the IMPs perform code conversion? How is it to be
+ controlled?
+
+II. Some Requirements Upon the Host-to-Host Software
+
+Simple Use
+
+ As with any new facility, there will be a period of very light usage
+ until the community of users experiments with the network and begins
+ to depend upon it. One of our goals must be to stimulate the
+ immediate and easy use by a wide class of users. With this goal, it
+ seems natural to provide the ability to use any remote HOST as if it
+ had been dialed up from a TTY (teletype) terminal. Additionally, we
+ would like some ability to transmit a file in a somewhat different
+ manner perhaps than simulating a teletype.
+
+Deep Use
+
+ One of the inherent problems in the network is the fact that all responses
+ from a remote HOST will require on the order of a half-second or so,
+ no matter how simple. For teletype use, we could shift to a
+ half-duplex local-echo arrangement, but this would destroy some of the
+ usefulness of the network. The 940 Systems, for example, have a very
+ specialized echo.
+
+ When we consider using graphics stations or other sophisticated
+ terminals under the control of a remote HOST, the problem becomes more
+ severe. We must look for some method which allows us to use our most
+ sophisticated equipment as much as possible as if we were connected
+ directly to the remote computer.
+
+Error Checking
+
+ The point is made by Jeff Rulifson at SRI that error checking at major
+ software interfaces is always a good thing. He points to some
+ experience at SRI where it has saved much dispute and wasted effort.
+ On these grounds, we would like to see some HOST to HOST checking.
+ Besides checking the software interface, it would also check the
+ HOST-IMP transmission hardware. (BB&N claims the HOST-IMP hardware
+ will be as reliable as the internal registers of the HOST. We believe
+
+
+
+Crocker [Page 4]
+
+RFC 1 Host Software 7 April 1969
+
+
+ them, but we still want the error checking.)
+
+III. The Host Software
+
+Establishment of a Connection
+
+ The simplest connection we can imagine is where the local HOST acts as
+ if it is a TTY and has dialed up the remote HOST. After some
+ consideration of the problems of initiating and terminating such a
+ connection , it has been decided to reserve link 0 for communication
+ between HOST operating systems. The remaining 31 links are thus to be
+ used as dial-up lines.
+
+ Each HOST operating system must provide to its user level programs a
+ primitive to establish a connection with a remote HOST and a primitive
+ to break the connection. When these primitives are invoked, the
+ operating system must select a free link and send a message over link
+ 0 to the remote HOST requesting a connection on the selected link.
+ The operating system in the remote HOST must agree and send back an
+ accepting message over link 0. In the event both HOSTs select the same
+ link to initiate a connection and both send request messages at
+ essentially the same time, a simple priority scheme will be invoked in
+ which the HOST of lower priority gives way and selects another free
+ link. One usable priority scheme is simply the ranking of HOSTS
+ by their identification numbers. Note that both HOSTs are aware that
+ simultaneous requests have been made, but they take complementary
+ actions: The higher priority HOST disregards the request while the
+ lower priority HOST sends both an acceptance and another request.
+
+ The connection so established is a TTY-like connection in the
+ pre-log-in state. This means the remote HOST operating system will
+ initially treat the link as if a TTY had just called up. The remote
+ HOST will generate the same echos, expect the same log-in sequence and
+ look for the same interrupt characters.
+
+High Volume Transmission
+
+ Teletypes acting as terminals have two special drawbacks when we
+ consider the transmission of a large file. The first is that some
+ characters are special interrupt characters. The second is that
+ special buffering techniques are often employed, and these are
+ appropriate only for low-speed character at time transmission.
+
+ We therefore define another class of connection to be used for the
+ transmission of files or other large volumes of data. To initiate
+ this class of link, user level programs at both ends of an established
+ TTY-like link must request the establishment of a file-like connection
+ parallel to the TTY-like link. Again the priority scheme comes into
+
+
+
+Crocker [Page 5]
+
+RFC 1 Host Software 7 April 1969
+
+
+ play, for the higher priority HOST sends a message over link 0 while
+ the lower priority HOST waits for it. The user level programs are, of
+ course, not concerned with this. Selection of the free link is done
+ by the higher priority HOST.
+
+ File-like links are distinguished by the fact that no searching for
+ interrupt characters takes place and buffering techniques appropriate
+ for the higher data rates takes place.
+
+A Summary of Primitives
+
+ Each HOST operating systems must provide at least the following
+ primitives to its users. This list knows not to be necessary but not
+ sufficient.
+
+ a) Initiate TTY-like connection with HOST x.
+
+ b) Terminate connection.
+
+ c) Send/Receive character(s) over TTY-like connection.
+
+ d) Initiate file-like connection parallel to TTY-like connection.
+
+ e) Terminate file-like connection.
+
+ f) Send/Receive over file-like connection.
+
+Error Checking
+
+ We propose that each message carry a message number, bit count, and a
+ checksum in its body, that is transparent to the IMP. For a checksum
+ we suggest a 16-bit end-around-carry sum computed on 1152 bits and
+ then circularly shifted right one bit. The right circular shift every
+ 1152 bits is designed to catch errors in message reassembly by the IMPs.
+
+Closer Interaction
+
+ The above described primitives suggest how a user can make simple use
+ of a remote facility. They shed no light on how much more intricate
+ use of the network is to be carried out. Specifically, we are
+ concerned with the fact that as some sites a great deal of work has
+ gone into making the computer highly responsive to a sophisticated
+ console. Culler's consoles at UCSB and Englebart's at SRI are at
+ least two examples. It is clear that delays of a half-second or so
+ for trivial echo-like responses degrade the interaction to the point
+ of making the sophistication of the console irrelevant.
+
+ We believe that most console interaction can be divided into two
+
+
+
+Crocker [Page 6]
+
+RFC 1 Host Software 7 April 1969
+
+
+ parts, an essentially local, immediate and trivial part and a remote,
+ more lengthy and significant part. As a simple example, consider a
+ user at a console consisting of a keyboard and refreshing display
+ screen. The program the user is talking typing into accumulates a
+ string of characters until a carriage return is encountered and then
+ it processes the string. While characters are being typed, it
+ displays the characters on the screen. When a rubout character is
+ typed, it deletes the previous non-rubout character. If the user
+ types H E L L O <- <- P <CR> where <- is rubout and <CR> is
+ carriage-return, he has made nine keystrokes. If each of these
+ keystrokes causes a message to be sent which in return invokes
+ instructions to our display station we will quickly become bored.
+
+ A better solution would be to have the front-end of the remote program
+ -- that is the part scanning for <- and <CR> -- be resident in our
+ computer. In that case, only one five character message would be
+ sent, i.e., H E L P <CR>, and the screen would be managed locally.
+
+ We propose to implement this solution by creating a language for
+ console control. This language, current named DEL, would be used by
+ subsystem designers to specify what components are needed in a
+ terminal and how the terminal is to respond to inputs from its
+ keyboard, Lincoln Wand, etc. Then, as a part of the initial protocol,
+ the remote HOST would send to the local HOST, the source language text
+ of the program which controls the console. This program would have
+ been by the subsystem designer in DEL, but will be compiled locally.
+
+ The specifications of DEL are under discussion. The following
+ diagrams show the sequence of actions.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Crocker [Page 7]
+
+RFC 1 Host Software 7 April 1969
+
+
+A. Before Link Establishment
+
+
+ / \
+ | +-----------+ +-----------+ |
+ | | | | | |
+ | | | | | |
+ | | terminal | | terminal | |
+ | | | | | |
+ | | | | | |
+ | +-----+-----+ +-----+-----+ |
+ | | | |
+ | | | |
+ | | | |
+ | +-----+-----+ +-----------+ |
+ | | | | Request connection | | | |
+ UCLA { | | | -> over link 25 | | | } SRI
+ | | +-+-+ | +-+ +-+ | +-+-+ | |
+ | | | OS|---+-=|I|----------|I|=-+---| OS| | |
+ | | +-+-+ | +-+ +-+ | +---+ | |
+ | | | | | |
+ | | | | | |
+ | +-----------+ +-----------+ |
+ | HOST: UCLA HOST: SRI |
+ \ /
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Crocker [Page 8]
+
+RFC 1 Host Software 7 April 1969
+
+
+b. After Link Establishment and Log-in
+
+
+ / \
+ | +-----------+ +-----------+ |
+ | | | | | |
+ | | | | | |
+ | | terminal | | terminal | |
+ | | | | | |
+ | | | | | |
+ | +-----+-----+ +-----+-----+ |
+ | | | |
+ | | | |
+ | | | |
+ | +-----+-----+ "Please send front"+-----------+ |
+ | | | | end control" | | | |
+ UCLA { | | | -> | | | } SRI ___
+ | | +-+-+ | +-+ +-+ | +--+---+ | | / |
+ | | | OS|---+-=|I|----------|I|=-+--|OS|NLS| +----+---| |
+ | | +-+-+ | +-+ +-+ | +------+ | | |___/
+ | | | DEL prog. | | | | |
+ | | | <- | | | |____|
+ | +-----------+ +-----------+ |
+ | HOST: UCLA HOST:SRI |
+ \ /
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Crocker [Page 9]
+
+RFC 1 Host Software 7 April 1969
+
+
+c. After Receipt and Compilation of the DEL program
+
+
+ / \
+ | +-----------+ +-----------+ |
+ | | | | | |
+ | | | | | |
+ | | terminal | | terminal | |
+ | | | | | |
+ | | | | | |
+ | +-----+-----+ +-----+-----+ |
+ | |Trivial | |
+ | |Responses | |
+ | | | |
+ | +-----+------+ +-----------+ |
+ | | | | | | | |
+ UCLA { | | | Major Responses | | | } SRI ___
+ | | +--+--+ | +-+ +-+ | +--+---+ | | / |
+ | | |DEL |---+-=|I|----------|I|=-+--|OS|NLS| +---+---| |
+ | | |front| | +-+ +-+ | +------+ | | |___/
+ | | | end | | | | | | |
+ | | |prog.| | | | | |____|
+ | | +-----+ | | | |
+ | | | OS | | | | |
+ | | +-----+ | | | |
+ | | | | | |
+ | +------------+ +-----------+ |
+ | HOST: UCLA HOST: SRI |
+ \ /
+
+Open Questions
+
+ 1. If the IMPs do code conversion, the checksum will not be correct.
+
+ 2. The procedure for requesting the DEL front end is not yet
+ specified.
+
+IV. Initial Experiments
+
+Experiment One
+
+ SRI is currently modifying their on-line retrieval system which will
+ be the major software component on the Network Documentation Center so
+ that it can be operated with model 35 teletypes. The control of the
+ teletypes will be written in DEL. All sites will write DEL compilers
+ and use NLS through the DEL program.
+
+Experiment Two
+
+
+
+Crocker [Page 10]
+
+RFC 1 Host Software 7 April 1969
+
+
+ SRI will write a DEL front end for full NLS, graphics included. UCLA
+ and UTAH will use NLS with graphics.
+
+
+ [ This RFC was put into machine readable form for entry ]
+ [ into the online RFC archives by Celeste Anderson 3/97 ]
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Crocker [Page 11]
+