Host-host control message formats
How early ARPANET hosts sent control messages to set up and manage connections.
Cerf, V.G., "Host-host control message formats", RFC 22, DOI 10.17487/RFC0022, October 1969, <https://www.rfc-editor.org/info/rfc22>.
@misc{rfc22,
series = {Request for Comments},
number = 22,
howpublished = {RFC 22},
publisher = {RFC Editor},
doi = {10.17487/RFC0022},
url = {https://www.rfc-editor.org/info/rfc22},
author = {V.G. Cerf},
title = {{Host-host control message formats}},
pagetotal = 2,
year = 1969,
month = oct,
} RFC text
Network Working Group Vint Cerf
Request for Comments: 22 UCLA
October 17, 1969
Host-Host Control Message Formats
NWG/RFC 11 has been modified at UCLA; and will be republished. In
the meantime, it seems important to report a new control message
format which does not use 7-bit ASCII character mode of transmission.
All Host-Host control messages consist of sequences of 8-bit bytes of
the form:
<control byte> <parameter byte l> ... <parameter byte n>
It is reasonable to transmit more than one control message in any
given packet, although this is not mandatory.
Presently, 9 control messages have been defined by UCLA; these are
given in the table below along with their parameters. The
interpretation is given from the point of view of the transmitting
host. ("L" or "Li" mean Link#, and are binary values.)
Control byte Parameter Interpretation
<0> <L> Please establish primary connection;
our output link # is L
<1> <L,> <L2> Please establish auxiliary connection
parallel to our primary output link L.
The auxiliary output link is L2.
<2> <L1> <L2> DK primary. Your primary output link
to us was L; our primary output link
to you is L2.
<3> <L1> <L2> OK auxiliary. Your auxiliary output
link is Li, our auxiliary output link
is L2.
<4> <L> Not OK primary. We cannot establish a
primary connection. Your primary
output link number was L.
<5> <Li> <L2> Not OK auxiliary. We cannot establish
an auxiliary connection. Your primary
output link no was L2.
<6> <L> Please stop transmitting over link
number L. This is called the CEASE
directive.
<7> <L> We are CLOSING our output link number
L. You may get this message before
the last message arrives over this
link since control messages are higher
priority than regular data messages.
<8> <L> UNCEASE: that is, you may resume
transmitting over output link number
L.
Each control message is embedded in the appropriate message structure
e.g.:
<-------------32 bits --------------->
| HEADER |
|____________________________________|
| | | | |
| mark | l | <L1> | <L2> |
|______|_______|___________|_________|
| | |
| checksum | Padding |
|_________________|__________________|
typical control message (please
establish auxiliary link #L2
parallel to our primary link #l)
The header for all HOST-HOST control messages is given below:
0 3 4 7 8 9 10 14 LINK# 24 31
_______________________________________________________________
| | | | | |////////////////|
| FLAGS | TYPE | H | SITE | 00000001 |////////////////|
|_______|______|_____|_______|_______________|________________|
where FLAGS - 0000
TYPE - 0000 (regular message)
H - host #(0-3) at SITE (usually 0 for single HOST sites)
SITE - Site #
LINK# - 00000001 (HOST-HOST control link)
[ This RFC was put into machine readable form for entry ]
[ into the online RFC archives by Alison De La Cruz 12/00 ]
AI ELI5
On this page
§1Control Message Format
Host-to-host control messages consist of sequences of 8-bit bytes with a control byte followed by zero or more parameter bytes. Multiple control messages can be transmitted together in a single packet for efficiency. This format departs from the 7-bit ASCII character mode used in earlier specifications.
A control message is like a short instruction: a code byte that says what kind of message it is, then some numbers that give details.
§2Connection Establishment Messages
At the time RFC 22 was written, nine control messages were defined. Type 0 requests a primary connection with a single link number parameter. Type 1 requests an auxiliary connection parallel to a primary link, with two parameters for the primary and auxiliary link numbers. Type 2 acknowledges a primary connection request from the other host, and type 3 acknowledges an auxiliary connection request. Type 4 rejects a primary connection request, and type 5 rejects an auxiliary request. These messages handle the initial setup and negotiation phase of host-to-host communication.
Some message types open a primary or parallel link. Others confirm or reject those requests.
- 0Establish primary — Request primary connection with our output link number.
- 1Establish auxiliary — Request auxiliary connection parallel to primary.
- 2OK primary — Acknowledge a primary connection request.
- 3OK auxiliary — Acknowledge an auxiliary connection request.
- 4Not OK primary — Reject a primary connection request.
- 5Not OK auxiliary — Reject an auxiliary connection request.
- 6CEASE — Stop transmitting on specified link.
- 7CLOSING — Close output link (arrives before final data).
- 8UNCEASE — Resume transmission on link.
§3Link Control Messages
Once a link is established, other control messages manage its operation. Type 6 is the CEASE directive, instructing the receiving host to stop transmitting on a specified link (flow control). Type 7 closes an output link and may be received before the last data packet arrives, since control messages take priority. Type 8 is UNCEASE, allowing transmission to resume on a previously ceased link. These messages provide dynamic control over data flow during the session.
After links are open, you can pause a link, close it, or restart it.