File: rfc107.txt

package info (click to toggle)
doc-rfc 20181229-2
  • links: PTS, VCS
  • area: non-free
  • in suites: buster
  • size: 570,944 kB
  • sloc: xml: 285,646; sh: 107; python: 90; perl: 42; makefile: 14
file content (642 lines) | stat: -rw-r--r-- 18,109 bytes parent folder | download | duplicates (5)
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
452
453
454
455
456
457
458
459
460
461
462
463
464
465
466
467
468
469
470
471
472
473
474
475
476
477
478
479
480
481
482
483
484
485
486
487
488
489
490
491
492
493
494
495
496
497
498
499
500
501
502
503
504
505
506
507
508
509
510
511
512
513
514
515
516
517
518
519
520
521
522
523
524
525
526
527
528
529
530
531
532
533
534
535
536
537
538
539
540
541
542
543
544
545
546
547
548
549
550
551
552
553
554
555
556
557
558
559
560
561
562
563
564
565
566
567
568
569
570
571
572
573
574
575
576
577
578
579
580
581
582
583
584
585
586
587
588
589
590
591
592
593
594
595
596
597
598
599
600
601
602
603
604
605
606
607
608
609
610
611
612
613
614
615
616
617
618
619
620
621
622
623
624
625
626
627
628
629
630
631
632
633
634
635
636
637
638
639
640
641
642






Network Working Group
Request for Comments # 107

NIC # 5806








                    Output of the Host-Host Protocol
                       Glitch Cleaning Committee





                                  UCLA
                             23 March 1971





                            Robert Bressler
                             Steve Crocker
                            William Crowter
                             Gary Grossman
                             Ray Tomlinson
                              James Withe



















                                                                [Page 1]

Introduction

The Host-Host Protocol Glitch Cleaning Committee met for the second
time at UCLA on 8, 9 March 1971, after canvassing the network com-
munity.  [The result of the (slightly larger) committee's first
meeting are documented in RFC #102.]  The committee agreed on
several modifications to the protocol in Document #1; these modi-
fications are listed below.

At each of the meeting, the committee quickly treated all but one
of the extant topics.  At the first meeting, the bulk of time was
spent considering the interrupt mechanism, and that discussion is
summarized in RFC #102.  At the second meeting, the committee spent
almost all of its time discussing the notion of bytes; this dis-
cussion is summarized after the list of modifications.

This RFC entirely supercedes RFC #102, and is an official modi-
fication of Document #1.  A revision of Document #1 will be written
shortly which incorporates the changes listed here.


NCP implementers are to incorporate these changes as soon as
possible.  NCP implementers also are to estimate on what date
theis NCP's will be ready and to communicate this estimate to
Steve Crocker or his secretary, Byrna Kristel.


























                                                                [Page 2]

Modifications


I Bytes

Heretofore, a connection has been a bit stream.  Henceforth, it is to
be a byte stream, with the byte size, S, indicated in the STR command
and in each message.  The byte size meets the constraints: 1 <= S <=
255.

The choice of the byte size for a connection is a 3rd level protocol
issue, but the size is constant for the life of a connection.  Each
message must contain an integral number of text bytes (see below).


II Message Format

The message format is changed to the format shown in figure 1.

The fields S and C are the byte size and byte count, respectively.
The S field is 8 bits wide and must match the byte size specified in
the STR which created the connection.  The C field is 16 bit long and
specifies the number of bytes in the text portion of the message.  A
zero value in the C field serves no purpose, but is explicitly
permitted.

The M1 and M2 field are each 8 bits long and must contain zero.  The
M3 field is zero or more bits long and must be all zero.  The M3 may
be used to fill out a message to a word boundary.  It is followed by
padding.

The text field consists of C bytes, where each byte is S bit long.
The text field starts 72 bits after the start of the message.

   The partition of a byte stream into messages is an artifact
   required by the subnet.  No semantic contents be attacched
   to message boundaries. In particular,














                                                                [Page 3]

                              32 bits
                |<--------------------------------->|


                +-----------------------------------+
                |                                   |
                |              leader               |
                |                                   |
                +--------+--------+-----------------+
                |        |        |                 |
                |   M1   |    S   |        C        |
                |        |        |                 |
                +--------+--------+-----------------+
                |        |        ^                 |
                |   M2   |        |                 |
                |        |        |                 |
                +--------+        |                 |
                |                 |                 |
                |                 |                 |
                |                                   |
                |                Text               |
                //                                 //
                |                 |                 |
                |                 |                 |
                |                 |                 |
                |                 |                 |
                |                 |        +--------+
                |                 |        |        |
                |                 |        |   M3   |
                |                 v        |        |
                +-----------------+--------+--------+
                |                 |
                |  10 --------- 0 | <-- Padding
                |                 |
                +-----------------+

                            Typical Message

                                Figure 1












                                                                [Page 4]

1.  A message with a zero value for C has no meaning, although
    it is legal and it does use up resource allocation.  (See
    Flow Control below.)

2.  A receiver may not expect to see 3rd level control infor-
    mation synchronized with message boundaries.  Particuralrly,
    if the notion of record is defined for a connection, the
    receiver must expect multiple records and/or record frag-
    ments within one message.  (However, control message obey
    special rules.  See below.)


III Message Data Types

No notion of data type is defined as part of the 2nd level pro- tocol.
3rd level protocols may include the notion. Data types cannot be
synchronized on message boundaries.


IV Reset and Reset Reply

A new pair of one bit control commands RST (reset) and RRP (reset
reply) are added.  The RST is interpreted as a signal to purge the NCP
tables of all existing entries which arose from the Host which sent to
RST.  The Host receiving the RST acknowledges by returning a RRP.  The
Host sending the RST may proceed to request connection after receiving
either a RST or RRP in return.  An RST is returned if the second Host
comes up after the first Host.


V Flow Control

The flow control techniques are changed in two ways.  First, the Cease
mechanism is discontinued.  The 10HI and 11HI message will no longer
be recognized by the Imps, and the Imps will no loger generate the
10HI, 11HI or 12HI messages.















                                                                [Page 5]

Second, the allocation mechanism now deals with two quantities, bits
and messages.  The receiver allocates each of these quantities
separately.  The sender and receiver each must mantain a 16 bit
unsigned counter for message and a 32 bit unsigned counter for bits.
When sending a message, the sender subtract one from the message
counter, and the text length from the bit counter. The receiver
decrements his counter similarly when receiving the message.  The
sender is prohibited from sending if either counter would be decre-
mented below zero.  Similarly, the receiver is prohibited from raising
the current message allocation above 2**16 - 1, or the current bit
allocation above 2**32 - 1.

The TEXT LENGTH of a message is the product of S, the byte size, and
C, the number of bytes.  These values always appear in the first part
of the message, as described under Message Format.


The ALL, GVB, and RET command are modified to treat two quantities.
Their formats are given under Control Command, below. The GVB command
is further modified to make it possible to ask for none of the
allocation to be returned.  The new GVB command has four eight bit
fields.  The first two fields are the op code and the link, as before.
The next two fields contain number fM and fB which control how much of
message and a bit allocation are to be returned.  Each of these
numbers is interpreted as "the number of 128ths of the current
allocation" to be returned if it is in the range of 0 to 128, and is
to be interpreted as "all of the current allocation", if it is in the
range 128 to 255.


VI Control Message

The control link is chsnged to link 0; link 1 is not to be used.  The
old and new protocols may thereforre coexist.

















                                                                [Page 6]

Message sent over the control link have the same format as other
regular messages, as described above under Message Format.  The byte
size field must contain the value 8.

Control messages may not contain more tha 120 byte of text; the
value in the byte count field is thus limited to 120.  This limi-
tation is intended to help smaller hosts.

Control messages must contain an integral number of control commands.
Control commands, therefore, may not be split across control messages.


VII Link Assignment

The link are now assigned as follows:

   0          control link
   1          old protocol's control link - to be phased out
   2 - 31     links for connections
   32 - 190   reserved -- not for current use
   191        to be used only for measurement work under direction
               of the network measurement center (UCLA)
   192 - 255  available for any private experimental use.


VIII Fixed Length Control Commands

The ECO, ERP and ERR commands are now fixed length.  The ECO and ERP are
now 16 bit long -- 8 bits of op code and 8 bits of data. The ERR command
is now 96 bits long -- 8 bits of op code, 8 bits of error code, and 80
bits of text. 80 bits is long enough to hold the longest non-ERR control
command.



















                                                                [Page 7]

IX Control Command Formats

As mentioned above, the formats of the STR, ALL, GVB, RET, ECO, ERP and
ERR commands have changed; and the commands RST and RRP have been added.
The formats of these commands are given here.

      |  8  |          32           |          32           |  8  |
      +-----+-----------------------+-----------------------+-----+
      |     |                       |                       |     |
1.    | STR | send socket           | receive socket        |     |
      |     |                       |                       |  ^  |
      +-----+-----------------------+-----------------------+--|--+
                                                               |
      |  8  |  8  |   16      |           32          |        +-- byte size
      +-----+-----+-----------+-----------------------+
      |     |     |           |                       |
2.    | ALL | link| msg space | bit space             |
      |     |     |           |                       |
      +-----+-----+-----------+-----------------------+

      |  8  |  8  |   16      |           32          |
      +-----+-----+-----------+-----------------------+
      |     |     |           |                       |
3.    | RET | link| msg space | bit space             |
      |     |     |           |                       |
      +-----+-----+-----------+-----------------------+

      |  8  |  8  |  8  |  8  |
      +-----+-----+-----+-----+
      |     |     |     |     |
4.    | GVB | link|  fM |  fB |
      |     |     |  ^  |  ^  |
      +-----+-----+--|--+--|--+
                     |     |
                     |     +-- bit fraction
                     +-------- message fraction

      |  8  |  8  |
      +-----+-----+
      |     |     |
5.    | ECO |data |
      |     |     |
      +-----+-----+








                                                                [Page 8]

      |  8  |  8  |
      +-----+-----+
      |     |     |
6.    | ERP |data |
      |     |     |
      +-----+-----+

      |  8  |  8  |                       80                        |
      +-----+-----+---------------------- // -----------------------+
      |     |     |                                                 |
7.    | ERR |     |  text                                           |
      |     |  ^  |                                                 |
      +-----+--|--+---------------------- // -----------------------+
               |
               +-- error code

      |  8  |
      +-----+
      |     |
8.    | RST |
      |     |
      +-----+

      |  8  |
      +-----+
      |     |
9.    | RRP |
      |     |
      +-----+



The values of the op codes are

            NOP   =   0
            RTS   =   1
            STR   =   2
            CLS   =   3
            ALL   =   4
            GVB   =   5
            RET   =   6
            INR   =   7
            INS   =   8
            ECO   =   9
            ERP   =  10
            ERR   =  11
            RST   =  12
            RRP   =  13



                                                                [Page 9]

Discussion on Byte Streams

The previous specification that connections would be conduits of bit
streams provided maximum generality and minimum efficiency.  Pressure
for greater efficiency developed and the problen was examined.

Two separate kinds of inefficiency arose from bit streams.

   1.  Receiving Hosts were equired to engage in expensive
       shifting to concatenate the texts of successive
       messages.  Sending Hosts often also had to shift text
       fields to align them on word boundaries.

   2.  Sending NCP's were prohibited from hanging onto ANY
       text for an indefinite time if it were possible to send
       even one bit.  This requirement was necessary to prevent
       possible deadlocks.  For example, suppose processes A
       and B have a conversation in progress over a pair of
       connections, one in each directions.  Also suppose that
       these processes produce exactly one bit of output for
       each bit of input.  Then if A's NCP fails to send a
       waiting bit because it wants to pack it together with
       later output from A, then B will not be able to output
       and neither will A.  It is clear then, that unless there
       is some quantitee that the data in the sending NCP's
       buffers are not crucially needed on the receive side, the
       sending NCP must assume otherwise and transmit any
       waiting data as soon as it is able.

These considerations led to the notion of a "transmission unit," whose
existence would be known to the NCP's.  The questions then became what
were typical and/or possible transmission unit sizes. For



















                                                               [Page 10]

character-oriented interaction, 8-bit transmission units seemed
reasonable.  For line-oriented interaction, the transmission unit might
best be the line itself, and therefore variable length; alternatively,
it might be best consider the transmission unit to be a character.  For
file transfer, it might be desirable for the transmission unit to be a
multiple of the word lengths of both machines; however, the last part of
the file may not form a whole transmission unit, if the transmission
unit is too large.  The consensus became that the transmission unit
should not be divisible under any circumstances, and should, therefore,
be fairly small.  The notion of transmission unit thus seems to be
synonymous with the notation of byte, and the term transmission unit was
dropped.

Subsequent discussion of the deadlocks and wakeup aspect revealed that
there may be two byte sizes associated with a single connection:

   1.  Transmission from the sending process to the sending NCP
       is in bytes of size S.  The sending NCP must send a
       message whenever the link is unblocked, the message
       counter is at least 1, the bit counter is at least S,
       and the least S bits of text are ready.  The message
       must contain an integral number of bytes.

   2.  At the receiving side, there may be  a different byte
       size R for transmission from the receiving NCP to the
       receiving process.  An example of where R <> S, is
       suggested by UCSB which is providing a file system for
       transparently storing binary files.  It is reasonable that
       a using HOST might send with 36 bit bytes, while the UCSB
       file system might want to receive 32-bit increments.

It is clear that from a network protocol point of view, only the byte S
is relevant, and this is quantity which is communicated in the STR
command in every message.  The choice of the byte size R is up

















                                                               [Page 11]

to the receiving user, and its meaning is how often the receiving NCP
should wakeup the receiving process.  It may also happen that a
receiving process has an agreement with the receiving NCP which is more
complex than "please wake me every R bits;" for example, the NCP might
scan for new-line characters before waking up the receiving process.

In the new protocol, it is the option of the receiver to refuse a
request for connection on the basis of the proffered byte size.
Conceptually, we imagine that NCP's are capable of handling all byte
sizes, and that such a choice would be up to the third level pro- grams
(user programs, loggers, telnets, etc.)  Some Hosts, small ones in
particular, may know enough about their third level programs to restrict
the variety of byte sizes which can be sent or received.  While it is a
matter of a local policy, the committee strongly suggests that NCP's be
capable of handling all byte sizes.  One of our committee, moreover,
feels strongly that NCP's should be written to be able to receive all
byte sizes S and provide for different byte sizes R for transmission to
the user process.



       [ This RFC was put into machine readable form for entry ]
        [ into the online RFC archives by Enrico Bertone 4/97 ]




























                                                               [Page 12]