Browse Prior Art Database

Some comments on the official protocol (RFC0117)

IP.com Disclosure Number: IPCOM000001982D
Original Publication Date: 1971-Apr-01
Included in the Prior Art Database: 2019-Feb-10
Document File: 5 page(s) / 6K

Publishing Venue

Internet Society Requests For Comment (RFCs)

Related People

J. Wong: AUTHOR

Related Documents

10.17487/RFC0117: DOI

This text was extracted from a PDF file.
This is the abbreviated version, containing approximately 51% of the total text.

Network Working Group J. Wong Request for Comments: 117 UCLA NIC #5826 7 April 1971

Some Comments on the Official Protocol

[Categories B.1, C.1, C.2, C.3, C.4, C.5]

Document No. 1 and NWG/RFC No. 107 gave a very detailed description of connection establishment, connection termination and flow control over the Network. Throughout the implementation of the NCP it was discovered that the handling of ERR control commands, messages of types other than 0 (regular), 4 (nop), and 5 (rfnm), and messages with the From-imp bit on are not well discussed so that problems arise when they occur.

The Protocol is not complete if the above situations are not handled clearly, and the Host-Host Protocol Glitch Cleaning Committee should take this into consideration. In this document, experience with these unfavorable situations and suggestions for handling are given:

1. ERR Control Commands

In Document No. 1, the following error conditions are described:

a. Illegal Op. code. b. End of message encountered before all expected parameters. c. Bad socket polarity within commands. d. Link number not in the range of 0 <= L < 32. e. A request (other than RTS/STR) on a non-existent socket. f. A request (ALL, GVB, RET, INR, INS) on a non-existent link number. g. Transmit over non-existent link number.

Other error conditions are:

h. A request (GVB, RET, INR, INS) on an existent link, but connection is not established.

[Page 1]

i. Transmit over an existent link, but connection is not established. j. ALL or GVB on a send connection. k. RET on a receive connection. l. An attempt to send more than the allocated number of bits or messages. m. ECO, ERP, ERR commands do not have the defined number of bits of data.

In Document No. 1, each site is supposed to document the information on their ERR command. No one has done that so far, and the main reason is we are not sure of what information is important. In NWG/RFC No. 107, the text portion of the ERR Commands is decided to have a fixed length of 80 bits because 80 bits is long enough to hold the longest non-ERR command. In some of the above error conditions, more information than the command itself is desirable. It was noted that these error conditions arise very often in the experimental stage of the NCP. If every NCP is operating properly, none of them should ever occur. The ERR commands are therefore, an excellent debugging tool for the protocol. So it is desirable to define a set of possible error conditions, and for each condition, define a set of arguments in the corresponding ERR command so that enough information is given to tell what’s wrong. The suggested arguments for each situation (a - m) are listed below:

a. 1. Op. code in error. 2. Part of message following op. code (A maximum of 72 bits).

b, c, d, e, f. 1. The command in error.

g. 1. Link number, 2. Beginning of message (A maximum of 72 bits),

h. 1. Command in error. 2. Socket numbers for the connection. 3. Status of the connection.

[Page 2]

i. 1. Link number, 2. B...

Processing...
Loading...