summaryrefslogtreecommitdiff
path: root/doc/rfc/rfc36.txt
blob: b668e5e8a601637b4dc34a7ebe4499ba153d1ded (plain) (blame)
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
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
282
283
284
285
286
287
288
289
290
291
292
293
294
295
296
297
298
299
300
301
302
303
304
305
306
307
308
309
310
311
312
313
314
315
316
317
318
319
320
321
322
323
324
325
326
327
328
329
330
331
332
333
334
335
336
337
338
339
340
341
342
343
344
345
346
347
348
349
350
351
352
353
354
355
356
357
358
359
360
361
362
363
364
365
366
367
368
369
370
371
372
373
374
375
376
377
378
379
380
381
382
383
384
385
386
387
388
389
390
391
392
393
394
395
396
397
398
399
400
401
402
403
404
405
406
407
408
409
410
411
412
413
414
415
416
417
418
419
420
421
422
423
424
425
426
427
428
429
430
431
432
433
434
435
436
437
438
439
440
441
442
443
444
445
446
447
448
449
450
451
Network Working Group                                          S. Crocker
Request for Comments: 36                                    16 March 1970


                             Protocol Notes

I Overview
  --------

   The network protocol provides three facilities:

         1.  Connection establishment

         2.  Flow control

         3.  Reconnection

   Reconnection is considered separately from connection establishment
   partly because of the complexity of reconnection and partly because I
   don't have enough experience with the protocol to present these
   concepts in an integrated fashion.

   Connection Establishment
   ------------------------

   Connection establishment works essentially the same as in NWG/RFC
   #33.  The major change is that a more general form of switching is
   provided independently of establishment, so establishment is
   simplified by not including switching procedures.

   A rough scenario for connection establishment follows:

   1.  Process PA in host A grabs socket SA and requests connection with
       socket SB.  Process PA accomplishes this through a system call.

   2.  Concurrently with the above, process PB in host B grabs socket SB
       and requests connection with socket SA.

   3.  In response to process PA's request, the network control program
       in host A (referred to as NCPA) sends a Request-for-Connection
       (RFC) command to host B.  NCPB in host B sends a similar command
       to host A.  No ordering is implied: NCPB may send the command to
       NCPA before or after receiving the command from NCPA.

   4.  NCPA and NCPB are both aware the connection is established when
       each has received a RFC command and each has received the RFNM
       for the one it has sent.  They then notify processes PA and PB,
       respectively, that the connection is established.



Crocker                                                         [Page 1]
^L
RFC 36                       Protocol Notes                   March 1970


   One of the rules adhered to is that either SA is a send socket and SB
   is a receive socket or vice versa.  This condition is sometimes
   stated as "SA and SB must be  a send/receive pair."

   5.  The sending process may now send.

   Flow Control
   ------------

   In order to prevent a sending process from flooding a receiving
   processes it is necessary for the receiving process to be able to
   stop the flow(*).  Flow control is integrated into the network RFNM
   handling.  When a receiving host wishes to inhibit flow on a
   particular link, the host sends a special message to its IMP which
   causes the next RFNM on that link to be modified.  The sending host
   interprets this message as a RFNM and as a request to stop sending.
   A confirming control command is returned.

   When the receiving host is ready to receive again, it sends a command
   (RSM) telling the sending host to resume sending.

   Reconnection
   ------------

   For a great many reasons it is desirable to be able to switch one (or
   both) ends of a connection from one socket to another.  Depending
   upon the restrictions placed upon the switching process, it may be
   easy or hard to implement.  To achieve maximum generality, I present
   here a scheme for dynamic reconnection, which means that reconnection
   can take place even after flow has started.  It may turn out that for
   the majority of cases, this scheme is much more expensive than it
   needs to be; however, the following virtues are claimed:

      1. All various forms of switching connections are provided.

      2. Reconnection introduces no overhead in the processing of
         messages sent over a connection i.e., the whole cost is borne
         in processing the protocol.

   ---------------------------------------------------
   *BB&N argues that unlimited buffering should be provided.  It is
   possible that this would be a proper strategy: but it is foreign to
   my way of thinking, and I have based the protocol design on the
   assumption that only a small buffer is provided on the receive end of
   each connection.






Crocker                                                         [Page 2]
^L
RFC 36                       Protocol Notes                   March 1970


II  Data Structures
    ---------------

    1.  Connection Table
    2.  Process Table
    3.  Input Link Table
    4.  Output Link Table
    5.  Link Assignment Table

   Connection Table
   ----------------

   This holds all information pertaining to local sockets, particularly
   whether a socket is engaged in a connection, and if so, what state
   the connection is in.  Entries are keyed by local socket, but other
   tables have pointers into this table also.  (See the Process Table,
   Input Link Table, and Output Link Table.)

   Each entry contains the following information:

         a)  local socket (key)
         b)  foreign socket
         c)  link
         d)  connection state
         e)  flow state and buffer control
         f)  pointer to user's process
         g)  reconnection control state
         h)  queue of waiting callers

   The local socket is a 32 bit number.  If no entry exists for a
   particular socket, it may be created with null values.

   The foreign socket is a 40 bit number.  This field will be unassigned
   if no connection is established.

   The link is an 8 bit number and is the link over which data is sent
   from the sender to the receiver.  A socket is a receive socket iff
   its low-order bit is zero.

   Connection state refers to whether a connection is open or not, etc.
   The following possibilities may occur.

         a)  local process has requested a connection
         b)  foreign process(es) has/have requested a connection
         c)  connection established
         d)  reconnection in progress
         e)  close waiting
         f)  reconnection waiting



Crocker                                                         [Page 3]
^L
RFC 36                       Protocol Notes                   March 1970


   Flow state and buffer control refer to checking for RFNM's sending
   and accepting cease, suspend and resume commands, and keeping track
   of incoming or outgoing data.

   A pointer to the user's process is necessary if the process has
   requested a connection.

   If reconnection is in progress, it is necessary to keep track of the
   sequence of events.  A socket engaged in reconnection is either an
   end or a middle.  If it's a middle, it is necessary to store the
   eight bit name of the other middle attached to the same process, and
   to record receipt of END and RDY commands.

   Finally, if RFC's are received either when the socket is busy or when
   no process has engaged it, the RFC's are stacked first-in-first-out
   on a queue for the named local socket.

   Process Table
   -------------

   This table associates a process with a socket.  It is used to process
   system calls.

   Input Link Table
   ----------------

   This table associates receive links with local sockets.  It is used
   to decide for whom incoming messages are destined.

   Output Link Table
   -----------------

   This table associates send links with local sockets.  It is used to
   interpret RFNM's and RSM commands.

   Link Assignment Table
   ---------------------

   Links are assigned by receivers.  This table shows which links are
   free.











Crocker                                                         [Page 4]
^L
RFC 36                       Protocol Notes                   March 1970


III   Control Commands
      ----------------

                          Command Summary



   0         <NOP>
   1         <RFC> <me> <you>   or   <RFC> <me> <you> <link>
   2         <CLS> <me> <you>
   3         <RSM> <link>
   4         <SPD> <link>
   5         <FND> <me> <you> <asker>
   6         <END> <link> <end>
   7         <RDY> <link>
   8         <ASG> <me> <you> <link>


                               Commands
No Operation

   Form:    NOP
            NOP  is X'00'

   Purpose:  This command is included for completeness and
             convenience.

Request for connection

   Form:    <RFC> <my socket>  <your socket>
     or     <RFC> <my socket>  <your socket>  <link>
            <RFC> is X'01'
            <my socket> is a 32 bit socket number local to the
            sender
            <your socket> is a 32 bit socket number local to the
            receiver
            <link> is an eight bit link number.
            <my socket> and your socket must be a send/receive pair.
            <link> is included if and only if <my socket> is a
            receive socket

   Purpose:  This command is used to initiate a connection.  When
             two hosts have exchanged  RFC  commands with the same
             arguments (reversed), the connection is established.
             Links are assigned by the receiver.






Crocker                                                         [Page 5]
^L
RFC 36                       Protocol Notes                   March 1970


Close

   Form:    <CLS> <my socket> <your socket>
            <CLS> is X'02'
            <my socket> and <your socket> are the same as for <RFC>

   Purpose:  This command is used to block a connection.  It may
             also be used to abort the establishment of a connection
             or to refuse a request.  It may happen that no
             connection between the named sockets was established,
             or was in the process of being established.  In this
             event, the <CLS> should be discarded.

Resume

   Form:    <RSM> <link>
            <RSM> is X'03'

   Purpose:  This command is sent by a receiving host to cause the
             sending host to resume transmission on the named link.
             A sending host suspends sending if it receives a
             special RFNM for some message.  (Special RFNM's are
             generated by the receiving IMP upon request by its
             host.)

Suspended

   Form:    <SPD> <link>
            <SPD> is X'04'

   Purpose:  This command is sent by a sending host to acknowledge
             that it has stopped sending over the named link.
             Transmission will resume if a <RSM> command is
             received.

Final End

   Form:    <FND> <my socket> <your socket> <asker>
            <FND> is X'05'
            <my socket> is a 32 bit socket number of a socket local
            to the sender
            <your socket> is a 32 bit socket number of a socket
            local to the receiver
            <my socket> and <your socket> form a send/receive pair.
            A connection should be established between them.
            <asker> is a 40 bit socket number of the same type as
            <my socket>




Crocker                                                         [Page 6]
^L
RFC 36                       Protocol Notes                   March 1970


   Purpose:  If a process decides to short-circuit itself by connecting
             one of its receive sockets to one of its send sockets, the
             NCP sends out two <FND> commands -- one in each direction.
             Each one has <asker> initialized to <my socket>.

             Upon receiving an <FND> command, the NCP checks its <your
             socket>.  If <your socket> is already engaged in a
             reconnection, the command is passed on with a new <my
             socket> and <your socket>.  However, before it is passed
             on, the <asker> is compared with the new <my socket>.  If
             they are equal, a loop has been detected and both sockets
             are closed.

             If <your socket> is not engaged in a reconnection, it is
             marked as the end of a chain of reconnections and an <END>
             is sent back.

             If the connection named is not in progress, a <CLS> is sent
             back and the <FND> is discarded.

End Found

   Form:    <END> <link> <end socket>

            <END> is X'06'
            <link> is an 8 bit link

            <end socket> is a 40 bit socket

   Purpose:  This command indicates which socket is at the end of a
             chain of reconnections.  It is generated at <end
             socket> and passed back to the other terminal socket
             via all the intermediate sockets.  If <end socket> is a
             send socket, <link> refers to a connection with the
             send socket in the sending host and the receive socket
             in the receiving host.  If <end socket> is a receive
             socket, <link> refers to a connection with the send
             socket in the receiving host and the receive socket in
             the sending hose.  ("sending" end "receiving" refer to
             the transmission of this control command.)











Crocker                                                         [Page 7]
^L
RFC 36                       Protocol Notes                   March 1970


Ready

   Form:    <RDY> <link>

            <RDY> is X'07'
            <link> is an 8 bit link number

   Purpose:  This command is sent from a send socket to a receive
             socket to indicate that all messages have been
             forwarded and that reconnection may occur.

Assign New Link

   Form:    <ASG> <my socket> <your socket> <link>

            <ASG> is X'08'

   Purpose:  This command completes a reconnection.  It is sent from
             a receive socket to a send socket after the receive
             socket has received a <RDY>.  A new link is assigned
             and transmission commences.

          [ This RFC was put into machine readable form for entry ]
           [ into the online RFC archives by Marc Blanchett 3/00 ]



























Crocker                                                         [Page 8]
^L