File: rfc1.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 (619 lines) | stat: -rw-r--r-- 21,088 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






Network Working Group                                   Steve Crocker
Request for Comments: 1                                          UCLA
                                                         7 April 1969


                         Title:   Host Software
                        Author:   Steve Crocker
                          Installation:   UCLA
                          Date:   7 April 1969
             Network Working Group Request for Comment:   1


CONTENTS

INTRODUCTION

  I. A Summary of the IMP Software

     Messages

     Links

     IMP Transmission and Error Checking

     Open Questions on the IMP Software

 II. Some Requirements Upon the Host-to-Host Software

     Simple Use

     Deep Use

     Error Checking

III. The Host Software

     Establishment of a Connection

     High Volume Transmission

     A Summary of Primitives

     Error Checking

     Closer Interaction

     Open Questions




Crocker                                                        [Page 1]

RFC 1                        Host Software                 7 April 1969


 IV. Initial Experiments

     Experiment One

     Experiment Two

Introduction

   The software for the ARPA Network exists partly in the IMPs and
   partly in the respective HOSTs.  BB&N has specified the software of
   the IMPs and it is the responsibility of the HOST groups to agree on
   HOST software.

   During the summer of 1968, representatives from the initial four
   sites met several times to discuss the HOST software and initial
   experiments on the network.  There emerged from these meetings a
   working group of three, Steve Carr from Utah, Jeff Rulifson from SRI,
   and Steve Crocker of UCLA, who met during the fall and winter.  The
   most recent meeting was in the last week of March in Utah.  Also
   present was Bill Duvall of SRI who has recently started working with
   Jeff Rulifson.

   Somewhat independently, Gerard DeLoche of UCLA has been working on
   the HOST-IMP interface.

   I present here some of the tentative agreements reached and some of
   the open questions encountered.  Very little of what is here is firm
   and reactions are expected.

I.   A Summary of the IMP Software

Messages

   Information is transmitted from HOST to HOST in bundles called
   messages.  A message is any stream of not more than 8080 bits,
   together with its header.  The header is 16 bits and contains the
   following information:

           Destination     5 bits
           Link            8 bits
           Trace           1 bit
           Spare           2 bits

   The destination is the numerical code for the HOST to which the
   message should be sent.  The trace bit signals the IMPs to record
   status information about the message and send the information back to
   the NMC (Network Measurement Center, i.e., UCLA).  The spare bits are
   unused.



Crocker                                                        [Page 2]

RFC 1                        Host Software                 7 April 1969


Links

   The link field is a special device used by the IMPs to limit certain
   kinds of congestion.  They function as follows.  Between every pair of
   HOSTs there are 32 logical full-duplex connections over which messages
   may be passed in either direction.  The IMPs place the restriction on
   these links that no HOST can send two successive messages over the
   same link before the IMP at the destination has sent back a special
   message called an RFNM (Request for Next Message).  This arrangement
   limits the congestion one HOST can cause another if the sending HOST
   is attempting to send too much over one link.  We note, however, that
   since the IMP at the destination does not have enough capacity to
   handle all 32 links simultaneously, the links serve their purpose only
   if the overload is coming from one or two links.  It is necessary for
   the HOSTs to cooperate in this respect.

   The links have the following primitive characteristics.  They are
   always functioning and there are always 32 of them.

   By "always functioning," we mean that the IMPs are always prepared to
   transmit another message over them.  No notion of beginning or ending
   a conversation is contained in the IMP software.  It is thus not
   possible to query an IMP about the state of a link (although it might
   be possible to query an IMP about the recent history of a link --
   quite a different matter!).

   The other primitive characteristic of the links is that there are
   always 32 of them, whether they are in use or not.  This means that
   each IMP must maintain 18 tables, each with 32 entries, regardless of
   the actual traffic.

   The objections to the link structure notwithstanding, the links are
   easily programmed within the IMPs and are probably a better
   alternative to more complex arrangements just because of their
   simplicity.

IMP Transmission and Error Checking

   After receiving a message from a HOST, an IMP partitions the message
   into one or more packets.  Packets are not more than 1010 bits long
   and are the unit of data transmission from IMP to IMP.  A 24 bit
   cyclic checksum is computed by the transmission hardware and is
   appended to an outgoing packet.  The checksum is recomputed by the
   receiving hardware and is checked against the transmitted checksum.
   Packets are reassembled into messages at the destination IMP.

Open Questions on the IMP Software




Crocker                                                        [Page 3]

RFC 1                        Host Software                 7 April 1969


   1.  An 8 bit field is provided for link specification, but only 32
   links are provided, why?

   2.  The HOST is supposed to be able to send messages to its IMP.  How
   does it do this?

   3.  Can a HOST, as opposed to its IMP, control RFNMs?

   4.  Will the IMPs perform code conversion?  How is it to be
   controlled?

II. Some Requirements Upon the Host-to-Host Software

Simple Use

   As with any new facility, there will be a period of very light usage
   until the community of users experiments with the network and begins
   to depend upon it.  One of our goals must be to stimulate the
   immediate and easy use by a wide class of users.  With this goal, it
   seems natural to provide the ability to use any remote HOST as if it
   had been dialed up from a TTY (teletype) terminal.  Additionally, we
   would like some ability to transmit a file in a somewhat different
   manner perhaps than simulating a teletype.

Deep Use

   One of the inherent problems in the network is the fact that all responses
   from a remote HOST will require on the order of a half-second or so,
   no matter how simple.  For teletype use, we could shift to a
   half-duplex local-echo arrangement, but this would destroy some of the
   usefulness of the network.  The 940 Systems, for example, have a very
   specialized echo.

   When we consider using graphics stations or other sophisticated
   terminals under the control of a remote HOST, the problem becomes more
   severe. We must look for some method which allows us to use our most
   sophisticated equipment as much as possible as if we were connected
   directly to the remote computer.

Error Checking

   The point is made by Jeff Rulifson at SRI that error checking at major
   software interfaces is always a good thing. He points to some
   experience at SRI where it has saved much dispute and wasted effort.
   On these grounds, we would like to see some HOST to HOST checking.
   Besides checking the software interface, it would also check the
   HOST-IMP transmission hardware.  (BB&N claims the HOST-IMP hardware
   will be as reliable as the internal registers of the HOST.  We believe



Crocker                                                        [Page 4]

RFC 1                        Host Software                 7 April 1969


   them, but we still want the error checking.)

III.  The Host Software

Establishment of a Connection

   The simplest connection we can imagine is where the local HOST acts as
   if it is a TTY and has dialed up the remote HOST.  After some
   consideration of the problems of initiating and terminating such a
   connection , it has been decided to reserve link 0 for communication
   between HOST operating systems.  The remaining 31 links are thus to be
   used as dial-up lines.

   Each HOST operating system must provide to its user level programs a
   primitive to establish a connection with a remote HOST and a primitive
   to break the connection.  When these primitives are invoked, the
   operating system must select a free link and send a message over link
   0 to the remote HOST requesting a connection on the selected link.
   The operating system in the remote HOST must agree and send back an
   accepting message over link 0.  In the event both HOSTs select the same
   link to initiate a connection and both send request messages at
   essentially the same time, a simple priority scheme will be invoked in
   which the HOST of lower priority gives way and selects another free
   link.  One usable priority scheme is simply the ranking of HOSTS
   by their identification numbers.  Note that both HOSTs are aware that
   simultaneous requests have been made, but they take complementary
   actions: The higher priority HOST disregards the request while the
   lower priority HOST sends both an acceptance and another request.

   The connection so established is a TTY-like connection in the
   pre-log-in state.  This means the remote HOST operating system will
   initially treat the link as if a TTY had just called up.  The remote
   HOST will generate the same echos, expect the same log-in sequence and
   look for the same interrupt characters.

High Volume Transmission

   Teletypes acting as terminals have two special drawbacks when we
   consider the transmission of a large file.  The first is that some
   characters are special interrupt characters.  The second is that
   special buffering techniques are often employed, and these are
   appropriate only for low-speed character at time transmission.

   We therefore define another class of connection to be used for the
   transmission of files or other large volumes of data.  To initiate
   this class of link, user level programs at both ends of an established
   TTY-like link must request the establishment of a file-like connection
   parallel to the TTY-like link.  Again the priority scheme comes into



Crocker                                                        [Page 5]

RFC 1                        Host Software                 7 April 1969


   play, for the higher priority HOST sends a message over link 0 while
   the lower priority HOST waits for it.  The user level programs are, of
   course, not concerned with this.  Selection of the free link is done
   by the higher priority HOST.

   File-like links are distinguished by the fact that no searching for
   interrupt characters takes place and buffering techniques appropriate
   for the higher data rates takes place.

A Summary of Primitives

   Each HOST operating systems must provide at least the following
   primitives to its users.  This list knows not to be necessary but not
   sufficient.

   a)  Initiate TTY-like connection with HOST x.

   b)  Terminate connection.

   c)  Send/Receive character(s) over TTY-like connection.

   d)  Initiate file-like connection parallel to TTY-like connection.

   e)  Terminate file-like connection.

   f)  Send/Receive over file-like connection.

Error Checking

   We propose that each message carry a message number, bit count, and a
   checksum in its body, that is transparent to the IMP.  For a checksum
   we suggest a 16-bit end-around-carry sum computed on 1152 bits and
   then circularly shifted right one bit.  The right circular shift every
   1152 bits is designed to catch errors in message reassembly by the IMPs.

Closer Interaction

   The above described primitives suggest how a user can make simple use
   of a remote facility.  They shed no light on how much more intricate
   use of the network is to be carried out.  Specifically, we are
   concerned with the fact that as some sites a great deal of work has
   gone into making the computer highly responsive to a sophisticated
   console.  Culler's consoles at UCSB and Englebart's at SRI are at
   least two examples.  It is clear that delays of a half-second or so
   for trivial echo-like responses degrade the interaction to the point
   of making the sophistication of the console irrelevant.

   We believe that most console interaction can be divided into two



Crocker                                                        [Page 6]

RFC 1                        Host Software                 7 April 1969


   parts, an essentially local, immediate and trivial part and a remote,
   more lengthy and significant part.  As a simple example, consider a
   user at a console consisting of a keyboard and refreshing display
   screen.  The program the user is talking typing into accumulates a
   string of characters until a carriage return is encountered and then
   it processes the string.  While characters are being typed, it
   displays the characters on the screen.  When a rubout character is
   typed, it deletes the previous non-rubout character.  If the user
   types H E L L O <- <- P <CR> where <- is rubout and <CR> is
   carriage-return, he has made nine keystrokes.  If each of these
   keystrokes causes a message to be sent which in return invokes
   instructions to our display station we will quickly become bored.

   A better solution would be to have the front-end of the remote program
   -- that is the part scanning for <- and <CR> -- be resident in our
   computer.  In that case, only one five character message would be
   sent, i.e., H E L P <CR>, and the screen would be managed locally.

   We propose to implement this solution by creating a language for
   console control.  This language, current named DEL, would be used by
   subsystem designers to specify what components are needed in a
   terminal and how the terminal is to respond to inputs from its
   keyboard, Lincoln Wand, etc.  Then, as a part of the initial protocol,
   the remote HOST would send to the local HOST, the source language text
   of the program which controls the console.  This program would have
   been by the subsystem designer in DEL, but will be compiled locally.

   The specifications of DEL are under discussion.  The following
   diagrams show the sequence of actions.






















Crocker                                                        [Page 7]

RFC 1                        Host Software                 7 April 1969


A.  Before Link Establishment


         /                                                      \
        |     +-----------+                    +-----------+    |
        |     |           |                    |           |    |
        |     |           |                    |           |    |
        |     | terminal  |                    | terminal  |    |
        |     |           |                    |           |    |
        |     |           |                    |           |    |
        |     +-----+-----+                    +-----+-----+    |
        |           |                                |          |
        |           |                                |          |
        |           |                                |          |
        |     +-----+-----+                    +-----------+    |
        |     |     |     | Request connection |     |     |    |
   UCLA {     |     |     | -> over link 25    |     |     |    } SRI
        |     |   +-+-+   |  +-+          +-+  |   +-+-+   |    |
        |     |   | OS|---+-=|I|----------|I|=-+---| OS|   |    |
        |     |   +-+-+   |  +-+          +-+  |   +---+   |    |
        |     |           |                    |           |    |
        |     |           |                    |           |    |
        |     +-----------+                    +-----------+    |
        |      HOST: UCLA                        HOST: SRI      |
         \                                                     /


























Crocker                                                        [Page 8]

RFC 1                        Host Software                 7 April 1969


b.  After Link Establishment and Log-in


         /                                                      \
        |     +-----------+                    +-----------+    |
        |     |           |                    |           |    |
        |     |           |                    |           |    |
        |     | terminal  |                    | terminal  |    |
        |     |           |                    |           |    |
        |     |           |                    |           |    |
        |     +-----+-----+                    +-----+-----+    |
        |           |                                |          |
        |           |                                |          |
        |           |                                |          |
        |     +-----+-----+ "Please send front"+-----------+    |
        |     |     |     | end control"       |     |     |    |
   UCLA {     |     |     |        ->          |     |     |    } SRI ___
        |     |   +-+-+   |  +-+          +-+  |  +--+---+ |    |    /   |
        |     |   | OS|---+-=|I|----------|I|=-+--|OS|NLS| +----+---|    |
        |     |   +-+-+   |  +-+          +-+  |  +------+ |    |   |___/
        |     |           |       DEL prog.    |           |    |   |    |
        |     |           |        <-          |           |    |   |____|
        |     +-----------+                    +-----------+    |
        |      HOST: UCLA                        HOST:SRI       |
         \                                                     /


























Crocker                                                        [Page 9]

RFC 1                        Host Software                 7 April 1969


c.  After Receipt and Compilation of the DEL program


         /                                                     \
        |     +-----------+                    +-----------+    |
        |     |           |                    |           |    |
        |     |           |                    |           |    |
        |     | terminal  |                    | terminal  |    |
        |     |           |                    |           |    |
        |     |           |                    |           |    |
        |     +-----+-----+                    +-----+-----+    |
        |           |Trivial                         |          |
        |           |Responses                       |          |
        |           |                                |          |
        |     +-----+------+                    +-----------+   |
        |     |     |      |                    |     |     |   |
   UCLA {     |     |      |  Major Responses   |     |     |   } SRI ___
        |     |  +--+--+   |  +-+          +-+  |  +--+---+ |   |    /   |
        |     |  |DEL  |---+-=|I|----------|I|=-+--|OS|NLS| +---+---|    |
        |     |  |front|   |  +-+          +-+  |  +------+ |   |   |___/
        |     |  | end |   |                    |           |   |   |    |
        |     |  |prog.|   |                    |           |   |   |____|
        |     |  +-----+   |                    |           |   |
        |     |  | OS  |   |                    |           |   |
        |     |  +-----+   |                    |           |   |
        |     |            |                    |           |   |
        |     +------------+                    +-----------+   |
        |      HOST: UCLA                         HOST: SRI     |
         \                                                     /

Open Questions

   1.  If the IMPs do code conversion, the checksum will not be correct.

   2.  The procedure for requesting the DEL front end is not yet
   specified.

IV.  Initial Experiments

Experiment One

   SRI is currently modifying their on-line retrieval system which will
   be the major software component on the Network Documentation Center so
   that it can be operated with model 35 teletypes.  The control of the
   teletypes will be written in DEL.  All sites will write DEL compilers
   and use NLS through the DEL program.

Experiment Two



Crocker                                                       [Page 10]

RFC 1                        Host Software                 7 April 1969


   SRI will write a DEL front end for full NLS, graphics included.  UCLA
   and UTAH will use NLS with graphics.


         [ This RFC was put into machine readable form for entry ]
         [ into the online RFC archives by Celeste Anderson 3/97 ]













































Crocker                                                       [Page 11]