RFC 2 - Host Software

• Status: Unknown
• Published: April 1969
• Stream: Legacy
• Errata: RFC 2 Errata

---

Document Information

• RFC Number: 2
• Title: Host Software
• Authors: Bill Duvall (SRI)
• Date: April 1969
• Category: Unknown

Note: Page 1 of the original document is missing; the archived source carries the placeholders [unknown title] and [page 1 missing] where the title line and any opening text would have been. The title and author shown above are taken from the RFC Editor catalogue and from RFC 3, which records that RFC 1 and RFC 2 are both titled HOST Software.

Abstract

RFC 2 outlines the host software planned for the ARPANET. It defines three kinds of links — control, primary and auxiliary — and describes how each is established, maintained and released through the network monitor. It then specifies the error checking applied to messages, the monitor functions that handle input and output and track network status, the executive primitives a user program calls to open and use links, and the initial checkout procedure planned for bringing two hosts into communication.

Table of Contents

• 1. Links
  • 1a. Control Links
    • 1a1. Logical link 0 will be a control link between any two HOSTs on the network
      • 1a1a. Only one control link may exist between any two HOSTs on the network. Thus, if there are n HOSTs on the network, there are n-1 control links from each HOST.
    • 1a2. It will be primarily used for communication between HOSTs for the purposes of:
      • 1a2a. Establishing user links
      • 1a2b. Breaking user links
      • 1a2c. Passing interrupts regarding the status of links and/or programs using the links
      • 1a2d. Monitor communication
    • 1a3. Imps in the network may automatically trace all messages sent on link 0.
  • 1b. Primary Links
    • 1b1. A user at a given HOST may have exactly 1 primary link to each of the other HOSTs on the network.
      • 1b1a. The primary link must be the first link established between a HOST user and another HOST.
      • 1b1b. Primary links are global to a user, i.e. a user program may open a primary link, and that link remains open until it is specifically closed.
      • 1b1c. The primary link is treated like a teletype connected over a normal data-phone or direct line by the remote HOST, i.e. the remote HOST considers a primary link to be a normal teletype user.
      • 1b1d. The primary link is used for passing (user) control information to the remote HOST, e.g. it will be used for logging in to the remote host (using the remote hosts standard login procedure).
  • 1c. Auxilliary Links
    • 1c1. A user program may establish any number of auxilliary links between itself and a user program in a connected HOST.
      • 1c1a. These links may be used for either binary or character transmission.
      • 1c1b. Auxilliary links are local to the sub-system which establishes them, and therefore are closed when that subsystem is left.
• 2. Manipulation of Links
  • 2a. Control links
    • 2a1. The control link is established at system load time.
    • 2a2. The status of a control link may be active or inactive
      • 2a2a. The status of the control link should reflect the relationship between the HOSTs.
  • 2b. Primary Links
    • 2b1. Primary links are established by a user or executive call to the monitor
      • 2b1a. The network identification number of the HOST to be linked to must be included in the call
      • 2b1b. An attempt to establish more than one primary link to a particular HOST will be regarded as an error, and the request will be defaulted
      • 2b1c. Standard Transmission Character Set
        • 2b1c1. There will be a standard character set for transmission of data over the primary links and control links.
          • 2b1c1a. This will be full (8 bit) ASCII.
      • 2b1d. (get link) The protocol for establishing a link to HOST B from HOST A is as follows
        • 2b1d1. A selects a currently unused link to HOST B from its allocation tables
        • 2b1d2. A transmits a link-connect message to B over link 0.
        • 2b1d3. A then waits for:
          • 2b1d3a. A communication regarding that link from B
          • 2b1d3b. A certain amount of time to elaspse
        • 2b1d4. If a communication regarding the link is received from B, it is examined to see if it is:
          • 2b1d4a. A verification of the link from B.
          • 2b1d4a1. This results in a successful return from the monitor to the requestor. The link number is returned to the requestor, and the link is established.
          • 2b1d4b. A request from B to establish the link. This means: that B is trying to establish the same link as A independently of A.
          • 2b1d4b1. If the network ID number of A(Na) is greater than that of B(Nb), then A ignores the request, and continues to await confirmation of the link from B.
          • 2b1d4b2. If, on the other hand, Na<Nb, A:
          • 2b1d4b2a. Honors the request from B to establish the link,
          • 2b1d4b2b. Sends verification as required,
          • 2b1d4b2c. Aborts its own request, and repeats the allocation process.
          • 2b1d4c. Some other communication from B regarding the link.
          • 2b1d4c1. This is an error condition, meaning that either:
          • 2b1d4c1a. A has faulted by selecting a previously allocated link for allocation,
          • 2b1d4c1b. B is transmitting information over an un-allocated link,
          • 2b1d4c1c. Or a message regarding allocation from B to A has been garbled in transmission.
          • 2b1d4c2. In this case, A's action is to:
          • 2b1d4c2a. Send a link disconnect message to B concerning the attempted connection
          • 2b1d4c2b. Consider the state of HOST B to be in error and initiate entry to a panic routine(error).
        • 2b1d5. If no communication regarding the link is received from B in the prescribed amount of time, HOST B is considered to be in an error state.
          • 2b1d5a. A link disconnect message is sent to B from A.
          • 2b1d5b. A panic routine is called(error).
  • 2c. Auxilliary Links
    • 2c1. Auxilliary links are established by a call to the monitor from a user program.
      • 2c1a. The request must specify pertinent data about the desired link to the monitor
        • 2c1a1. The number of the primary link to B.
      • 2c1b. The request for an auxilliary link must be made by a user program in each of the HOSTs (A and B).
      • 2c1c. If Na > Nb, then HOST A proceeds to establish a link to HOST B in the manner outlined above (getlink).
      • 2c1d. If Na<Nb, then A waits:
        • 2c1d1. For HOST B to establish the link (after looking to see if B has already established the corresponding link).
        • 2c1d2. For a specified amount of time to elapse.
          • 2c1d2a. This means that HOST B did not respond to the request of HOST A.
          • 2c1d2b. The program in HOST A and B should be able to specifiy the amount of time to wait for the timeout.
• 3. Error Checking
  • 3a. All messages sent over the network will be error checked initally so as to help isolate software and hardware bugs.
  • 3b. A checksum will be associated with each message, which is order dependent.
    • 3b1. The following algorithm is one which might be used:
      • 3b1a. A checksum of length 1 may be formed by adding successive fields in the string to be checked serially, and adding the carry bit into the lowest bit position of the sum.
        • 3b1a1. This process is known as folding.
        • 3b1a2. Several fields may be added and folded in parallel, if they are folded appropiately after the addition.
          • 3b1a2a. Using this scheme, it is assumed that, if there are n fields, the carries from the first n-1 fields are automatically added into the low order position of the next higher field, so that in folding, one need only add the [n] result fields to the carry from the nth field, and then add in an appropiately sized carry from that addition (and repeat the desired number of times to achieve the result.
        • 3b1a3. A checksum computed in this manner has the advantage that the word lengths of different machines may each be used optimally:
          • 3b1a3a. If a string of suitable length is chosen for computing the checksum, and a suitable checksum field length is selected, the checksum technique for each of the machines will be relatively optimal.
          • 3b1a3a1. Field length: 288 bits (lowest common denomenator of (24,32,36)
          • 3b1a3a2. Checksum length: 8 bits (convenient field size for all machines)
      • 3b1b. If a message is divided into groups of fields, and each group is checksummed in this manner, an order dependent checksum may be got by shifting the checksum for each group, and adding it in (successively) to the checksum of the next group
  • 3c. A facility will be provided where two HOSTs may enter a mode which requires positive verification of all messages. This verification is sent over the control link.
• 4. Monitor Functions
  • 4a. Network I/O drivers
    • 4a1. Input
      • 4a1a. Input message from IMP.
      • 4a1b. Do error checking on message.
        • 4a1b1. Verify checksum,
        • 4a1b2. Send "message recieved" aknowledgement over control link if aknowledge mode is in effect.
      • 4a1c. (trans)character translation
        • 4a1c1. There is a strong possibility that the character translation may be done in the IMP.
        • 4a1c2. This needs to be explored further with BBN.
        • 4a1c3. There are two main considerations
          • 4a1c3a. Should the translation be done by table or algorithm?
          • 4a1c3a1. Initially it seems as though the best way to go is table.
          • 4a1c3b. How should we decide which messages should be translated, i.e. is it desirable to not translate everything (YES!!) and by what means can we use to differentiate?
      • 4a1d. Decode header, and pass message to correct recipient as identified by source, and link.
    • 4a2. Output
      • 4a2a. Build header
      • 4a2b. Character translation
        • 4a2b1. See remarks under the section on output translation (trans).
      • 4a2c. Create checksum
      • 4a2d. Check status of link
        • 4a2d1. If there has not been a RFNM since the last message transmitted out the link, wait for it.
      • 4a2e. Transmit message to IMP
      • 4a2f. If aknowledge mode is in effect,wait for
        • 4a2f1. RFNM from destination IMP.
        • 4a2f2. Response from destination HOST over control line 0.
  • 4b. Network status
    • 4b1. Maintain status of other HOSTs on network
      • 4b1a. If an IMP is down, then his HOST is considered to be down.
    • 4b2. Maintain status of control lines.
    • 4b3. Answer status queries from other HOSTs.
    • 4b4. Inform other HOSTs as to status of primary and auxilliary links on an interrupt basis.
    • 4b5. Inform other HOSTs as to status of programs using primary and secondary links
• 5. Executive Primitives
  • 5a. Primary Links
    • 5a1. These require the HOST number as a parameter.
      • 5a1a. Establish primary link
      • 5a1b. Connect controlling teletype to primary link
      • 5a1c. INPUT/OUTPUT over primary link
      • 5a1d. Interrogate status of primary link
        • 5a1d1. Don't know what, exactly, this should do, but it seems as though it might be useful.
      • 5a1e. Disconnect controlling teletype from primary link
      • 5a1f. Kill primary link
  • 5b. Auxilliary Links.
    • 5b1. Establish auxilliary link.
      • 5b1a. requires the HOST number as a parameter
      • 5b1b. It returns a logical link number which is similar to a file index. It is this number which is passed to all of the other Auxilliary routines as a parameter.
    • 5b2. INPUT/OUTPUT over auxilliary link
    • 5b3. Interrogate status auxilliary link.
      • 5b3a. Don't know what, exactly, this should do, but it seems as though it might be useful.
    • 5b4. Kill auxilliary link.
  • 5c. Special executive functions
    • 5c1. Transparent. INPUT/OUTPUT over link
      • 5c1a. This may be used to do block I/O transfers over a link
      • 5c1b. The function of the monitor in this instance is to transfer a buffer directly to its IMP
      • 5c1c. At does not modify it in any way
        • 5c1c1. This means that the header and other control information must be in the buffer.
      • 5c1d. The indended use of this is for network debugging.
• 6. Initial Checkout
  • 6a. The network will be initially checked out using the links in a simulated data-phone mode.
    • 6a1. All messages will be one character in length.
    • 6a2. Links will be transparent to the monitor, and controlled by user program via a special executive primitive.
      • 6a2a. The initial test will be run from two user programs in different HOSTs, e.g. DDT to DDT.
      • 6a2b. It will be paralleled by a telephone link or similar.

---

Related Resources

• Official RFC: RFC 2
• DataTracker: RFC 2 Info
• Errata: RFC Editor Errata