Index Journeys
RFC 40 UNKNOWN PROTOCOL · ERROR HANDLING · DESIGN

More Comments on the Forthcoming Protocol

Proposals for protocol error messages, connection queries, and NCP host status.

On rfc-editor.org ↗
PUBLISHED
March 1970
AUTHORS
E. Harslem, J.F. Heafner
STREAM
Legacy
ERROR CODE FIELD
8 bits
COMMAND LENGTH FIELD
16-bit count of bits
DOI
10.17487/RFC0040

RFC text

Original text · RFC Editor View on rfc-editor.org ↗ 
Network Working Group                                         E. Harslem
Request for Comments: 40                                      J. Heafner
                                                                    RAND
                                                              March 1970

               More Comments on the Forthcoming Protocol

We have recently discussed NWG/RFC Nos. 36 and 39 with Steve Crocker,
UCLA.  Steve has asked that we elaborate on the errors, queries, and
HOST status that were mentioned in NWG/RFC #39.

Please voice your opinions soon in order to affect the forthcoming
protocol specifications.

ERROR MESSAGES

     <ERR> <Code> <Command length> <Command in error>

<Code> is an eight-bit field that specifies the error type.  The
assigned codes are shown below.  <Command length> is a 16-bit integer
that indicates the length of the <Command in error> in bits.  The
<Command in error> is the spurious command.

The ranges of <Code> are shown below in hexidecimal.

     00     Unspecified error types
     10-0F  Resource errors
     10-1F  Status errors
     20-2F  Content errors
     30-3F  Unused

Specific values of <Code> are shown below with their meaning.

     <Code> value   Semantics

         00         Unspecified errors.
         01         Request for an invalid resource.
         02         Request for an exhausted resource, try later.
        03-0F       Unused.
         10         Invalid <RSM>, i.e., link connected but unblocked.
         11         Invalid <SPD>.
         12         Invalid <ASG>, i.e., connected but no <RDY>
                      received.

     <Code> value   Semantics

         13         Message received on blocked link.
        14-1F       Unused.
         20         Unknown command code.
         21         Message received on unconnected link.
         22         Invalid <RFC>.
         23         Invalid <CLS>.
         24         Invalid <RSM>, i.e., link not connected.
         25         Invalid <FND>.
         26         Invalid <END>.
         27         Invalid <RDY>.
         28         Invalid <ASG>, i.e., not connected.
        29-2F       Unused.
        30-FF       Unused.

QUERIES

     <QRY> <My Socket>
or   <RPY> <Your Socket> <Text>

The <QRY> is the query indicated in NWG/RFC #39 and <RPY> is the reply.
The format of <Text> is shown below; also refer to NWG/RFC #36, p. 3.

<Text>::= <16 bit count of relevant connection table entries>
          <relevant connection table entries>

<relevant connection table entries>::=
                                     <relevant connection table entries>
                                     <a relevant connection table entry>
                                     <a relevant connection table entry>

<a relevant connection table entry>::= <local socket> <foreign socket>
                                       <link> <connection state>
                                       <flow state and buffer control>
                                       <reconnection control state>

HOST STATUS

     <NOP>

An NCP may be up, down, pending, etc.  When an NCP changes its
state to UP it should send a <NOP> to each remote NCP which
indicates the NCP is available.  The sending NCP can then
construct a vector of HOST status from the RFNMs it receives.  An
NCP receiving a <NOP> can update the availability of the sending
NCP in its HOST status vector.



       [ This RFC was put into machine readable form for entry ]
         [ into the online RFC archives by Richard Ames 6/97 ]

ISO Plain Language

On this page
PROBLEMThe forthcoming host-to-host protocol needed more detail about reporting errors, querying connection state, and tracking host availability.
MECHANISMRFC 40 proposes an error message containing a code and the command in error, a query/reply with connection-table entries, and a NOP message for host status.
PROTOCOL DISCUSSIONThis memo provides proposals and discussion for the forthcoming protocol; it does not report a finalized design.

§1Error Messages

The proposed error message contains an error code, the length of the command in error, and the command itself. The error code is eight bits, and the command-length field is a 16-bit integer measured in bits.

Examples include code 01 for a request for an invalid resource, code 02 for an exhausted resource, code 20 for an unknown command code, and code 21 for a message received on an unconnected link.

An error report identifies the error type and includes the command that caused it. Codes distinguish conditions such as an invalid resource request or an unknown command.

§2Connection Queries and Replies

The proposed QRY message includes the sender's socket. An RPY response includes the other socket and text containing a count of relevant connection-table entries followed by those entries.

Each entry contains local and foreign socket information, link and connection state, flow and buffer control, and reconnection control state.

A host can ask another host for information about relevant connections. The reply lists connection details such as sockets, links, and state.

§3NCP Availability

The note proposes a NOP command for host status. When an NCP changes its state to UP, it should send NOP to each remote NCP to announce availability.

A receiving NCP can use that notice to update its host-status information. The sending NCP can also build a status vector from the RFNMs it receives.

An NCP that becomes available can notify remote NCPs with a NOP. Receiving hosts can use that notice to update their host-status records.