1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
|
<pre>Network Working Group Vint Cerf
Request for Comments: 22 UCLA
October 17, 1969
<span class="h1">Host-Host Control Message Formats</span>
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.
<span class="grey">Cerf [Page 1]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-2" ></span>
<span class="grey"><a href="./rfc22">RFC 22</a> Host-Host Control Message Formats October 1969</span>
<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 ]
Cerf [Page 2]
</pre>
|
