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
643
644
645
646
647
648
649
650
651
652
653
654
655
656
657
658
659
660
661
662
663
664
665
666
667
668
669
670
671
672
673
674
675
676
677
678
679
680
681
682
683
684
685
686
687
688
689
690
691
692
693
694
695
696
697
698
699
700
701
702
703
704
705
706
707
708
709
710
711
712
713
714
715
716
717
718
719
720
721
722
723
724
725
726
727
728
729
730
731
732
733
734
735
736
737
738
739
740
741
742
743
744
745
746
747
748
749
750
751
752
753
754
755
756
757
758
759
760
761
762
763
764
765
766
767
768
769
770
771
772
773
774
775
776
777
778
779
780
781
782
783
784
785
786
787
788
789
790
791
792
793
794
795
796
797
798
799
800
801
802
803
804
805
806
807
808
809
810
811
812
813
814
815
816
817
818
819
820
821
822
823
824
825
826
827
828
829
830
831
832
833
834
835
836
837
838
839
840
841
842
843
844
845
846
847
848
849
850
851
852
853
854
855
856
857
858
859
860
861
862
863
864
865
866
867
868
869
870
871
872
873
874
875
876
877
878
879
880
881
882
883
884
885
886
887
888
889
890
891
892
893
894
895
896
897
898
899
900
901
902
903
904
905
906
907
908
909
910
911
912
913
914
915
916
917
918
919
920
921
922
923
924
925
926
927
928
929
930
931
932
933
934
935
936
937
938
939
940
941
942
943
944
945
946
947
948
949
950
951
952
953
954
955
956
957
958
959
960
961
962
963
964
965
966
967
968
969
970
971
972
973
974
975
976
977
978
979
980
981
982
983
984
985
986
987
988
989
990
991
992
993
994
995
996
997
998
999
1000
1001
1002
1003
1004
1005
1006
1007
1008
1009
1010
1011
1012
1013
1014
1015
1016
1017
1018
1019
1020
1021
1022
1023
1024
1025
1026
1027
1028
1029
1030
1031
1032
1033
1034
1035
1036
1037
1038
1039
1040
1041
1042
1043
1044
1045
1046
1047
1048
1049
1050
1051
1052
1053
1054
1055
1056
1057
1058
1059
1060
1061
1062
1063
1064
1065
1066
1067
1068
1069
1070
1071
1072
1073
1074
1075
1076
1077
1078
1079
1080
1081
1082
1083
1084
1085
1086
1087
1088
1089
1090
1091
1092
1093
1094
1095
1096
1097
1098
1099
1100
1101
1102
1103
1104
1105
1106
1107
1108
1109
1110
1111
1112
1113
1114
1115
1116
1117
1118
1119
1120
1121
1122
1123
1124
1125
1126
1127
1128
1129
1130
1131
1132
1133
1134
1135
1136
1137
1138
1139
1140
1141
1142
1143
1144
1145
1146
1147
1148
1149
1150
1151
1152
1153
1154
1155
1156
1157
1158
1159
1160
1161
1162
1163
1164
1165
1166
1167
1168
1169
1170
1171
1172
1173
1174
1175
1176
1177
1178
1179
1180
1181
1182
1183
1184
1185
1186
1187
1188
1189
1190
1191
1192
1193
1194
1195
1196
1197
1198
1199
1200
1201
1202
1203
1204
1205
1206
1207
1208
1209
1210
1211
1212
1213
1214
1215
1216
1217
1218
1219
1220
1221
1222
1223
1224
1225
1226
1227
1228
1229
1230
1231
1232
1233
1234
1235
1236
1237
1238
1239
1240
1241
1242
1243
1244
1245
1246
1247
1248
1249
1250
1251
1252
1253
1254
1255
1256
1257
1258
1259
1260
1261
1262
1263
1264
1265
1266
1267
1268
1269
1270
1271
1272
1273
1274
1275
1276
1277
1278
1279
1280
1281
1282
1283
1284
1285
1286
1287
1288
1289
1290
1291
1292
1293
1294
1295
1296
1297
1298
1299
1300
1301
1302
1303
1304
1305
1306
1307
1308
1309
1310
1311
1312
1313
1314
1315
1316
1317
1318
1319
1320
1321
1322
1323
1324
1325
1326
1327
1328
1329
1330
1331
1332
1333
1334
1335
1336
1337
1338
1339
1340
1341
1342
1343
1344
1345
1346
1347
1348
1349
1350
1351
1352
1353
1354
1355
1356
1357
1358
1359
1360
1361
1362
1363
1364
1365
1366
1367
1368
1369
1370
1371
1372
1373
1374
1375
1376
1377
1378
1379
1380
1381
1382
1383
1384
1385
1386
1387
1388
1389
1390
1391
1392
1393
1394
1395
1396
1397
1398
1399
1400
1401
1402
1403
1404
1405
1406
1407
1408
1409
1410
1411
1412
1413
1414
1415
1416
1417
1418
1419
1420
1421
1422
1423
1424
1425
1426
1427
1428
1429
1430
1431
1432
1433
1434
1435
1436
1437
1438
1439
1440
1441
1442
1443
1444
1445
1446
1447
1448
1449
1450
1451
1452
1453
1454
1455
1456
1457
1458
1459
1460
1461
1462
1463
1464
1465
1466
1467
1468
1469
1470
1471
1472
1473
1474
1475
1476
1477
1478
1479
1480
1481
1482
1483
1484
1485
1486
1487
1488
1489
1490
1491
1492
1493
1494
1495
1496
1497
1498
1499
1500
1501
1502
1503
1504
1505
1506
1507
1508
1509
1510
1511
1512
1513
1514
1515
1516
1517
1518
1519
1520
1521
1522
1523
1524
1525
1526
1527
1528
1529
1530
1531
1532
1533
1534
1535
1536
1537
1538
1539
1540
1541
1542
1543
1544
1545
1546
1547
1548
1549
1550
1551
1552
1553
1554
1555
1556
1557
1558
1559
1560
1561
1562
1563
1564
1565
1566
1567
1568
1569
1570
1571
1572
1573
1574
1575
1576
1577
1578
1579
1580
1581
1582
1583
1584
1585
1586
1587
1588
1589
1590
1591
1592
1593
1594
1595
1596
1597
1598
1599
1600
1601
1602
1603
1604
1605
1606
1607
1608
1609
1610
1611
1612
1613
1614
1615
1616
1617
1618
1619
1620
1621
1622
1623
1624
1625
1626
1627
1628
1629
1630
1631
1632
1633
1634
1635
1636
1637
1638
1639
1640
1641
1642
1643
1644
1645
1646
1647
1648
1649
1650
1651
1652
1653
1654
1655
1656
1657
1658
1659
1660
1661
1662
1663
1664
1665
1666
1667
1668
1669
1670
1671
1672
1673
1674
1675
1676
1677
1678
1679
1680
1681
1682
1683
1684
1685
1686
1687
1688
1689
1690
1691
1692
1693
1694
1695
1696
1697
1698
1699
1700
1701
1702
1703
1704
1705
1706
1707
1708
1709
1710
1711
1712
1713
1714
1715
1716
1717
1718
1719
1720
1721
1722
1723
1724
1725
1726
1727
1728
1729
1730
1731
1732
1733
1734
1735
1736
1737
1738
1739
1740
1741
1742
1743
1744
1745
1746
1747
1748
1749
1750
1751
1752
1753
1754
1755
1756
1757
1758
1759
1760
1761
1762
1763
1764
1765
1766
1767
1768
1769
1770
1771
1772
1773
1774
1775
1776
1777
1778
1779
1780
1781
1782
1783
1784
1785
1786
1787
1788
1789
1790
1791
1792
1793
1794
1795
1796
1797
1798
1799
1800
1801
1802
1803
1804
1805
1806
1807
1808
1809
1810
1811
1812
1813
1814
1815
1816
1817
1818
1819
1820
1821
1822
1823
1824
1825
1826
1827
1828
1829
1830
1831
1832
1833
1834
1835
1836
1837
1838
1839
1840
1841
1842
1843
1844
1845
1846
1847
1848
1849
1850
1851
1852
1853
1854
1855
1856
1857
1858
1859
1860
1861
1862
1863
1864
1865
1866
1867
1868
1869
1870
1871
1872
1873
1874
1875
1876
1877
1878
1879
1880
1881
1882
1883
1884
1885
1886
1887
1888
1889
1890
1891
1892
1893
1894
1895
1896
1897
1898
1899
1900
1901
1902
1903
1904
1905
1906
1907
1908
1909
1910
1911
1912
1913
1914
1915
1916
1917
1918
1919
1920
1921
1922
1923
1924
1925
1926
1927
1928
1929
1930
1931
1932
1933
1934
1935
1936
1937
1938
1939
1940
1941
1942
1943
1944
1945
1946
1947
1948
1949
1950
1951
1952
1953
1954
1955
1956
1957
1958
1959
1960
1961
1962
1963
1964
1965
1966
1967
1968
1969
1970
1971
1972
1973
1974
1975
1976
1977
1978
1979
1980
1981
1982
1983
1984
1985
1986
1987
1988
1989
1990
1991
1992
1993
1994
1995
1996
1997
1998
1999
2000
2001
2002
2003
2004
2005
2006
2007
2008
2009
2010
2011
2012
2013
2014
2015
2016
2017
2018
2019
2020
2021
2022
2023
2024
2025
2026
2027
2028
2029
2030
2031
2032
2033
2034
2035
2036
2037
2038
2039
2040
2041
2042
2043
2044
2045
2046
2047
2048
2049
2050
2051
2052
2053
2054
2055
2056
2057
2058
2059
2060
2061
2062
2063
2064
2065
2066
2067
2068
2069
2070
2071
2072
2073
2074
2075
2076
2077
2078
2079
2080
2081
2082
2083
2084
2085
2086
2087
2088
2089
2090
2091
2092
2093
2094
2095
2096
2097
2098
2099
2100
2101
2102
2103
2104
2105
2106
2107
2108
2109
2110
2111
2112
2113
2114
2115
2116
2117
2118
2119
2120
2121
2122
2123
2124
2125
2126
2127
2128
2129
2130
2131
2132
2133
2134
2135
2136
2137
2138
2139
2140
2141
2142
2143
2144
2145
|
Network Working Group
Request for Comments: 705
NIC# 33644
FRONT - END PROTOCOL
B6700 VERSION
2 September 1975
This is a working document which has been developed as the specification
and guideline for design of a Burroughs B6700 attachment to an ARPA-Style
network.
The approach is to utilize a front-end processor with a new protocol for
network operation. That protocol, described herein, has been built upon
the concepts expressed by M.A. Padlipsky, et al, in NIC# 31117, RFC# 647.
This proposed, site-specific, FEP implementation is the work of Gerald
Bailey and Keith McCloghrie of NSA and of David Grothe of ACC. It has
already sustained some corrections provided by MAP. It will be helpful
if interested networkers will review and provide comments to us.
Comments to BRYAN@ISI.
Roland Bryan - ACC 1^L
Network Working Group
Request for Comments: 705
Front-End Protocol: B6700 Version
***WORKING DOCUMENT***
FRONT-END PROTOCOL
PREFACE
This document describes the protocol to be used for connecting a general-
purpose computer system (host) to an ARPANET-like network via a "front-end"
computer. The main body of the document is aimed at a reader who is not
conversant with all the details of network protocols. However, a paragraph
marked with [n], refers a reader familiar with network protocols to the
n-th item of Appendix A which will amplify that particular paragraph.
Further information on the network protocols referred to in this document
can be obtained from the Network Information Center.
Appendix B contains diagrams showing the transitions between the different
connection states. Appendices C and D give the implementation details of
this protocol in the Front-End and the Hosts.
This protocol is predicated upon the assumption that for each host, a line
protocol, at a lower level, will be established between the device-driver
modules in the Host and the Front-End, and that this line protocol provides
Front-End Protocol with error-free transmissions.
INTRODUCTION 2
A host computer may be connected to a network for a variety of reasons.
Network connection may be an attempt to expand the usefulness of the
Host to the community of users which it serves by making network resources
available to them. Conversely, the services which the Host provides may
be made available to a larger community of users, with the network providing
the method of access to those services.
In order for members of a network community to communicate in an intelligent
way, there must exist a set of protocols. The implementation of these
protocols in a host computer is typically called the Network Control Program
(NCP). The size and complexity of the NCP is proportional to the number and
complexity of protocols which it implements. For an ARPANET like network,
both the number and complexity are substantial.
***WORKING DOCUMENT***
1^L
RFC 705
Front-End Protocol
***WORKING DOCUMENT***
A host which directly connects into the network must assume the responsibility
for implementing this set of protocols. That is the "price of admission"
to become a network host. It is not necessary to implement every protocol
and every option in every host, but even in the simplest case -- implementation
of an NCP is not a small task. The intrusion into the normal operating
environment of the host is also not small.
An alternative method for network connection is to connect the host to some
intermediate processor, and in turn, directly connect that processor to the
network. This approach is called "Front-Ending." There are many arguments
which may be posed to justify a host connection to a network through a front-
end processor. The most obvious being that the responsibility for
implementation of the network protocols (the NCP) can be delegated to the
front-end (FE), thereby reducing the impact on the host.
The purpose of this document is not to justify Front-Ending as a philosophy,
but rather, to introduce a protocol for communications between a host and
a front-end processor which is providing it network access. The Front End
Protocol (FEP) is intended to permit the host to make use of the network
through existing protocols, without requiring that it be cognizant of the
complexities and implementation detail inherent in their execution.
The FEP is sufficiently general to permit its implementation in the host
to be in terms of the function the host is performing, or the services
which it is providing. Of primary consideration in specification of FEP
was that it must provide the host with a sufficiently robust command
repertoire to perform its network tasks, while buffering it from the
details of network protocols.
CONCEPTS 3
Introduction 3a
Before a detailed description of the command structures is undertaken it
seems appropriate to introduce several of the concepts upon which the FEP
is predicated.
The following section serves to briefly describe the FEP commands, and to
elaborate on the concepts of addressing and types of connections provided.
***WORKING DOCUMENT***
2^L
RFC 705
Front-End Protocol
***WORKING DOCUMENT***
Commands (General) 3b
1. BEGIN Command
This command is sent from the host to the front-end processor. Its function
is to direct the establishment of one or more network connections. The type
and number of connections is specified in the BEGIN command string.
2. LISTEN Command
Through this command the host indicates its willingness to accept requests
for connection arriving from other hosts. It directs the front-end processor
to LISTEN for any such connection requests. The number and type of
connections are specified in the command string.
3. RESPONSE Command
The front-end processor uses the RESPONSE command to indicate to the host that
a particular path specified in a BEGIN or LISTEN command is now open or that
the open attempt failed.
4. MESSAGE Command
Message text passing between the host and its front-end processor is sent in
this command string. The MESSAGE command is bi-directional, and is the same
for host or front-end.
5. INTERRUPT Command
The INTERRUPT command is sent by either the host of FE. Its most common use is
to convey that the user wishes to terminate what he is doing - i.e., he has
depressed the Control-C, ATTN, or INT key.
6. END Command
One or more connections may be closed by either the FE or the host issuing
this command. The connection(s) which are affected by the action of the END
are specified in the command string.
7. REPLY Command
This command is required to be sent by both the host and FE to acknowledge
receipt of all command types (except REPLY). The success or failure of the
command being acknowledged is conveyed in the REPLY command string.
***WORKING DOCUMENT***
3^L
RFC 705
Front-End Protocol
***WORKING DOCUMENT***
Connections 3c
In order to engage in a meaningful conversation, the parties involved must
be connected. A network connection is defined by the ARPA Host-Host Protocol
document (Nic #8246) as follows : "A connection couples two processes so
that output from one process is input to the other. Connections are defined
to be unidirectional, so two connections are necessary if a pair of processes
are to converse in both directions." The components of a connection, the
sockets, are defined: "... a socket forms the reference for one end of a
connection, and a connection is fully specified by a pair of sockets. A
socket is identified by a Host number and a 32-bit socket number. The same
number in different Hosts represents different sockets."
The existing network protocols incorporate prescribed strategies for
selecting socket assignments, pairing sockets to form connections, and in
the number of connections required to implement the protocol.
Conversations, in most cases, are bi-directional. Thus to simplify the
Host's procedures in these cases, FEP permits duplex connections on which
the Host can both send and receive. Send only and Receive only connections
are also available for those situations where communication is one-way.
Thus, FEP provides the flexibility to reduce complexity in the Host, in
addition to accommodating existing protocols and allowing for the
development of new protocols.
Addressing 3d
Conversations in FEP are uniquely identified at initiation by some combination
of Host address, Index number, Path number and Socket assignment. The Host
address and Socket assignment are required to form the connection(s); there-
after the Index and Path are sufficient to identify the conversation.
Host Address
If, through the BEGIN command, the local Host explicitly directs the creation
of network connection(s), it must specify the address of the foreign host to
which it desires communication. If the local host indicates a willingness to
communicate, through the LISTEN command, the Front-End processor will supply
the address of the connecting foreign host(s) in its RESPONSE command(s).
***WORKING DOCUMENT***
4^L
RFC 705
Front-End Protocol
***WORKING DOCUMENT***
Socket
A socket is either a send socket or a receive socket. This property is
called the socket's gender. The sockets at either end of a network
connection must be of opposite gender. As previously defined a socket
forms the reference for one end of a network connection. To the extent
possible, the FEP shields the Host from the responsibility of assigning
sockets for individual conversations. However, because the
socket is a fundamental part of the addressing mechanism of the network,
the Host may need to be aware of socket assignments when establishing
connections.
It is through a "well-advertised" socket that a host provides services
to other members of the network community. The Initial Connection
Protocol (ICP) [1] is used to first connect to the well-advertised socket
in order to exchange the number of a presently unused socket which is then
used for the connections required so that the well-advertised socket can
be freed for others attempting to connect.
When establishing a conversation (with a BEGIN or LISTEN command) the
Host indicates in the value of the CONN-TYPE field whether the socket
specified is to be employed directly, or to be used as an initial
connection socket.
Index/Path Addressing 3e
Indexes are values assigned by the local Host to identify network con-
versations. When conversations are established (with the BEGIN or LISTEN
commands) the Host must specify an index value. This value will be
associated with the resultant conversations for their duration.
It is often necessary to affiliate conversations [2]. To accommodate this,
data paths are defined such that each index has one or more path(s)
associated with it (a path can not exist except as a subordinate to an
index) and all network communication is transmitted on some path.
The maximum number of indexes which may be in use at any one time, and the
maximum number of paths within one index are installation parameters.
Index 0 is reserved for controlling other indexes, and logically represent the
"pipe" through which all other indexes "flow."
***WORKING DOCUMENT***
5^L
RFC 705
Front-End Protocol
***WORKING DOCUMENT***
Addresses in FEP command strings are conveyed by the pair of fields "INDEX"
and "PATH." In commands which cause new indexes to be opened, or new data
paths to be added to an existing index (BEGIN or LISTEN), the PATH field
indicates the first path to be acted upon by this command. For those
commands which do not create new paths or indexes, if PATH is 0, then all
paths associated with this INDEX are addressed; if PATH is non-zero, only the
specific path within the specified INDEX is addressed.
Path Types 3f
A path can be one of three types:
a. DUPLEX - both the Host and the FE can issue MESSAGE commands
on the path.
b. SEND - only the Host can issue MESSAGE commands on the path.
c. RECEIVE - only the FE can issue MESSAGE commands on the path.
The paths within an index may be a mixture of path types but one BEGIN/
LISTEN must be used for each contiguous set of the same type.
An FEP path is analogous to a network connection with the following exception.
Network connections are always simplex. This is true for paths of type SEND
or RECEIVE. However, a DUPLEX path is formed by the FE connecting two local
sockets to two foreign sockets. This is a "duplex connection" which is
composed of two network (simplex) connections.
Modes of Establishing a Path 3g
One or more paths are established by the action of a single BEGIN or LISTEN
command, with the mode specified in the CONN-TYPE field of the command.
Each of the path types is established in one of two modes - directly or via
ICP. The gender of the path (its ability to receive or send or both) is not
affected by the mode.
When any of the path types is specified with the ICP mode, the socket value
in the SOCKET field is used as the "well-advertised" socket and an actual
working socket will be exchanged according to the Initial Connection Protocol.
When the direct mode is indicated, the specified socket is used as the working
socket.
***WORKING DOCUMENT***
6^L
RFC 705
Front-End Protocol
***WORKING DOCUMENT***
In either mode, when multiple paths are indicated, the next higher socket
number values of the appropriate gender are selected for each path. [3]
Translation 3h
When the Host sets up a path(s) (with a BEGIN or LISTEN command) it identifies
what type of translation or data-mapping it requires the FE to perform on all
data transmitted on this path(s). This is specified by two values - one
giving the format of the data transmitted between the FE and the network,
the other giving the format of the data between the Host and the FE. [4]
Flow Control 3i
All commands (except REPLYs) must be REPLYED to by the receiver. The sender
is blocked from sending more commands on the same path until a REPLY has been
received. The REPLY command serves two functions: it indicates the
success/failure of the last transmission on the path, and it also indicates
a willingness of the receiver to accept more data on that path. Receipt of
any valid REPLY on an open path is sufficient to unblock it for END or
INTERRUPT commands. Thus a receiver who will not (or can not) accept more
data (MESSAGE commands) on a given path need not block the sender from
ENDing the path if he desires. An indication of "READY" in the reply serves
to unblock the path for MESSAGE commands also.
In the normal case, the REPLY performs both functions concurrently. However,
when the receiver is not ready to accept more data, he can REPLY indicating
only success/failure of the last command which should be sufficient to
allow the sender to free the transmission buffer, requeue the command for
retransmission if necessary, etc. and wait for another REPLY command
announcing the receiver's ability to accept more data.
Exceptional Conditions 3j
When a command is received and can not be executed, the REPLY command is used
to notify the sender of the command. To do this, the bits of CODE field of
the REPLY are set to show the CATEGORY of the error and its TYPE within that
category (see Section 3h).
***WORKING DOCUMENT***
7^L
RFC 705
Front-End Protocol
***WORKING DOCUMENT***
COMMANDS 4
Introduction 4a
All communications between the Host and the FE is performed by means of
commands. The commands are given names for documentation purposes but are
distinguished by the binary value of the first field of the command string.
Command strings will be padded with zeros up to the next multiple of an
installation defined parameter. (This value will be dependent on the
capabilities of the hardware interface between the Host and the FE.)
Field lengths within a command string are specified as some number of bits.
These information bits will be right-justified within the least number of
bytes needed to hold them. The size of a byte will be an installation
parameter which will normally be 8 bits but other values will be accommodated
as necessary.
The values and meanings of the CODE field of the REPLY command are given for
each command within the following descriptions:
1: BEGIN 4b
Format
BEGIN INDEX PATH HOST SOCKET TRANS-TYPE CONN-TYPE NPATHS
Use
This command is sent only from the Host to the FE. Its function is to direct
the FE to establish one or more logical connections (paths) on the specified
index between the Host and the FE.
Its use has three different modes (depending on the value of the PATH field) :
mode (a) - to set up a new index and to direct the FE to attempt
to establish network connections for the one or more paths
specified within this index.
***WORKING DOCUMENTS***
8^L
RFC 705
Front-End Protocol
***WORKING DOCUMENT***
mode (b) - to attempt to establish network connections for an
existing (but at present closed) path within the already set-up
index.
Mode (c) - to attempt to establish network connections for
one or more new paths within the already set-up index.
Parameters
a) BEGIN is an 8-bit field with the value 1.
b) INDEX is a 16-bit field, specifying the index. Note that
the value 0 is reserved for special use (see Section 4).
c) PATH is an 8-bit field, specifying the path(s) which are
to be established. Its value identifies the mode of the
BEGIN (see above) :
mode (a) - its value must be 1.
mode (b) - its value must be that of the path to be
"re-opened."
mode (c) - its value must be exactly one greater than
the current number of paths defined within this index.
d) HOST is a 32-bit field specifying the foreign host with
which connections are to be established.
e) SOCKET is a 32-bit field, specifying the first or only
socket at the foreign host to which connections are to
be made.
f) TRANS-TYPE is a 16-bit field which directs the FE to
perform this type of translation on all data (i.e. TEXT
in the MESSAGE command string) sent on every path being
established by this command. The first 8 bits specify
the format of the data on the network side; the second
8 bits specify the format of the data on the Host side.
The values assigned to the particular formats (eq. ASCII,
EBCDIC etc.) are installation parameters; however, the
***WORKING DOCUMENT***
9^L
RFC 705
Front-End Protocol
***WORKING DOCUMENT***
value 0 will always mean "bit string" and thus if either
of the 8-bit sub-fields contains 0, then no mapping will
be performed.
g) CONN-TYPE is an 16-bit field, specifying the type and mode
of connection(s) to be established for the specified path(s).
Its value informs the FE how to associate sockets with
indexes/paths (see Sections 2f and 2g).
Value Type Mode
7 Duplex via ICP
6 Duplex direct
5 Receive via ICP
4 Receive direct
3 Send via ICP
2 Send direct
h) NPATHS is an 8-bit field, specifying the number of paths which
this command directs the FE to attempt to establish connections
for. If the BEGIN is of mode (b) then its value must be 1.
Otherwise the sum of its value and the value of the PATH field
is the new current number of paths plus one.
Error CODES in REPLY
Category Type Meaning
3 1 PATH invalid for new index
3 2 PATH invalid for old index
3 3 PATH already open
3 4 HOST unknown
3 5 TRANSLATION-TYPE invalid
3 6 CONNECTION-TYPE invalid
3 7 NPATHS invalid for old path on old index
3 8 Specified socket inconsistent with CONN-TYPE
3 9 INDEX invalid, not ready for business
4 1 No new connections - FE full
4 2 No new connections - closing down soon
***WORKING DOCUMENT***
10^L
RFC 705
Front-End Protocol
***WORKING DOCUMENT***
2: LISTEN 4c
Format
LISTEN INDEX PATH HOST SOCKET TRANS-TYPE CONN-TYPE NPATHS
Use
This command is sent only from the Host to the FE.
Its function is to direct the FE to "listen," i.e., to hold the specified paths
pending until such time as a request for connection (RFC) is received from the
network to the specified local socket. then to set up connections and to
respond with a RESPONSE command for each path.
Its use has three different modes (depending on the value of the PATH field) :
mode (a) - to set up a new index and to listen on the specified local
socket in order to establish connections for the specified paths.
mode (b) - to listen on the specified socket in order to establish
connections for the specified, existing (but at present closed)
path within the already set-up index.
mode (c) - to listen on the specified socket in order to establish
connections for the specified new path(s) within the already set-up
index.
By use of the HOST parameter, the FE can be directed to accept RFCs from any
host or only from the specified host.
Parameters
a) LISTEN is an 8-bit field with value 2.
b) INDEX is a 16-bit field specifying the index.
c) PATH is an 8-bit field specifying the first of the one or more
paths which are to be held pending receipt of a RFC. Its
value identifies the mode of the LISTEN (see above) :
***WORKING DOCUMENT***
11^L
RFC 705
Front-End Protocol
***WORKING DOCUMENT***
mode (a) - its value must be 1.
mode (b) - its value must be that of the existing path.
mode (c) - its value must be exactly one greater than
the current number of paths within this index.
d) HOST is a 32-bit field specifying the host from which RFCs
are to be accepted; a value of 0 implies from any host.
e) SOCKET is a 32-bit field specifying the local socket on which
the FE is to listen for RFCs.
f) TRANS-TYPE is a 16-bit field specifying the type of translation
the FE is to perform on all data sent on every path established
as a result of this command. Its values are the same as in the
BEGIN command.
g) CONN-TYPE is an 16-bit field specifying the type and mode of the
connection(s) to be established for the specified path(s) when
an RFC is received. Its values are the same as in the BEGIN
command.
h) NPATHS is an 8-bit field specifying the number of paths which
this command associates with the specified index and which are
to be established. If the LISTEN is of mode (b) then its value
must be 1. Otherwise the sum of its value and the value of the
PATH field is the new current number of paths plus one, within
this index. Thus its value is the number of extra RFCs for
which the FE is listening on this socket.
Error CODEs in REPLY
Category Type Meaning
3 1 PATH invalid for new index
3 2 PATH invalid for old index
3 3 PATH already open
3 4 HOST unknown
3 5 TRANSLATION-TYPE invalid
***WORKING DOCUMENT***
12^L
RFC 705
Front-End Protocol
***WORKING DOCUMENT***
3 6 CONNECTION-TYPE INVALID
3 7 NPATHS invalid for old path on old index
3 8 Specified socket inconsistent with CONN-TYPE
3 9 INDEX invalid, not ready for business
3 10 Socket already in use.
4 1 No new listens - FE full
4 2 No new listens - closing down soon
3: RESPONSE 4d
Format
RESPONSE INDEX PATH CODE HOST SOCKET
Use
This command is sent only from the FE to the Host - once per path specified in
a BEGIN or a LISTEN command.
For paths specified in a BEGIN, it is sent to indicate the success or failure
of the connection attempt. For paths specified in a LISTEN, it is sent at
the time when the FE has received a matching RFC and has established the
connection.
The HOST and SOCKET parameters are purely informational which the Host can
ignore if it so desires. Their contents are only guaranteed if the connection
attempt succeeded.
Parameters
a) RESPONSE is an 8-bit field with value 3.
b) INDEX is a 16-bit field specifying the index.
c) PATH is an 8-bit field specifying the particular path.
d) CODE is a 16-bit field indicating the outcome of the
connection attempt:
***WORKING DOCUMENT***
13^L
RFC 705
Front-End Protocol
***WORKING DOCUMENT***
Value Meaning
0 Path successfully established.
1 Local IMP dead.
2 Foreign IMP inaccessible.
3 Foreign Host dead.
4 Foreign Host not responding.
5 Connection refused.
e) HOST is a 32-bit field specifying the foreign host to which the
connection has been made.
f) SOCKET is a 32-bit field specifying the socket at the foreign
host. If the connection type is simplex, then it is the only
foreign socket for this path; if duplex, then it is the lower
of the two foreign sockets.
Error CODES in REPLY
Category Type Meaning
3 11 INDEX unknown
3 12 PATH unknown
3 13 CODE invalid
4: MESSAGE 4e
Format
MESSAGE INDEX PATH COUNT PAD TEXT
Use
This command is sent by either the Host or the FE to transmit data on the
specified path and index.
Parameters
a) MESSAGE is an 8-bit field with value 4.
b) INDEX is a 16-bit field specifying the index.
***WORKING DOCUMENT***
14^L
RFC 705
Front-End Protocol
***WORKING DOCUMENT***
c) PATH is an 8-bit field specifying the path. Note that the value
0 is used in the broadcast option (see Section 3j).
d) COUNT is a 16-bit field specifying the number of bits of data
in the TEXT field.
e) PAD is an n-bit field, where n is an installation parameter.
It contains only padding (in the present protocol specification)
and can be used to enable the host to have the TEXT field start
on a convenient boundary.
f) TEXT is a field containing COUNT bits of data being transmitted
on this path.
Error CODES in REPLY
Category Type Meaning
2 1 This option not implemented
3 12 PATH unknown
3 14 No connection opened in this direction
3 15 PATH blocked at this time, resent later
3 16 PATH suspended at this time, resent later
3 17 PATH closed
3 17 COUNT too large
4 3 Error in transmitting data, resend command
4 4 Data lost, resent command.
5: INTERRUPT 4f
Format
INTERRUPT INDEX PATH CODE
Use
This command is sent by either the Host or the FE.
Its most common use is to pass the information that a terminal user has
pressed his INT (or ATTN or Control-C) key, thereby requesting his
applications program to quit what it is doing for him.[5]
***WORKING DOCUMENT***
15^L
RFC 705
Front-End Protocol
***WORKING DOCUMENT***
Parameters
a) INTERRUPT is a 8-bit field with value 5.
b) INDEX is a 16-bit field specifying the index.
c) PATH is an 8-bit field specifying the path on which the
INTERRUPT is transmitted. Note that the value 0 is used in
the broadcast option (see Section 3j).
d) CODE is a 16-bit field. It has no defined meanings as yet
and should contain 0.
Error CODES in REPLY
Category Type Meaning
2 1 This option not implemented
3 11 INDEX unknown
3 12 PATH unknown
3 14 No connection opened in this direction
3 15 PATH blocked at this time, resend later
3 17 PATH closed.
6: END 4g
Format
END INDEX PATH CODE
Use
This command is sent by either the Host or the FE, to terminate a connection.
If PATH is 0, then the index and all its paths are terminated, otherwise just
the specified path of the index is terminated.
Parameters
a) END is an 8-bit field with value 6.
b) INDEX is a 16-bit field specifying the index.
***WORKING PARAMETER***
16^L
RFC 705
Front-End Protocol
***WORKING DOCUMENT***
c) PATH is an 8-bit field containing the path to be closed, or 0 if
the whole index is to be closed.
d) CODE is a 16-bit field indicating the reason for the closure:
Value Meaning
0 Normal close
1 Retries exhausted
2 Foreign Host failure
3 Foreign IMP failure
4 Network failure
5 Local IMP failure.
The "Retries exhausted" code indicates that the FE has been
retrying a transmission to the foreign host without success.
Error CODES in REPLY
Category Type Meaning
3 11 INDEX unknown
3 12 PATH unknown
3 13 CODE unknown
3 15 PATH blocked at this time, resend later
3 17 PATH closed.
7: REPLY 4h
Format
REPLY INDEX PATH CODE
Use
This command is sent by both the Host and the FE to acknowledge receipt of
every other type of command (including those on index 0, see Section 4) and/or
to unblock that particular direction of an opened path for the transmission
of another command.
Note that the INDEX and PATH fields contain exactly the same as those of the
command being replied to.
***WORKING DOCUMENT***
17^L
RFC 705
Front-End Protocol
***WORKING DOCUMENT***
Parameters
a) REPLY is an 8-bit field with value 7.
b) INDEX is a 16-bit field specifying the index.
c) PATH is a 8-bit field specifying the path.
d) CODE is a 16-bit field indicating the success/failure of the
command being REPLYed to, and the sender's readiness for more
commands on the same path. It is divided into four subfields -
STATUS, COMMAND, CATEGORY, and TYPE.
1) STATUS is 4 bits wide
bit 0 (right-most) - READY
bit 1 - NOT-READY
bit 2 - ACK
bit 3 - NAK
ACK=1 indicates that the sender (of the REPLY) has accepted
the command (being REPLYed to). NAK=1 indicates that the
sender has discarded the command (with the reason given by
the settings of the other bits of the CODE field).
NOT-READY=1 indicates that the sender (of the REPLY) is
willing to receive an END or INTERRUPT on this path.
READY=1 indicates that MESSAGE commands will also be received.
Normally only one REPLY command will be sent for each
other command. However MESSAGE, INTERRUPT, RESPONSE and
invalid END commands can be replied to by a REPLY with
ACK (or NAK)=1 and NOT-READY=1 and another REPLY, some
time later, with READY=1. [6]
The ACK and NAK bits are mutually exclusive and should
never both be on simultaneously, and similarly the READY
and NOT-READY bits.
Note that the READY/NOT-READY bit settings are only
relevant when a path is open.
***WORKING DOCUMENT***
18^L
RFC 705
Front-End Protocol
***WORKING DOCUMENT***
2) COMMAND is 4 bits wide. It indicates the command for
which this is a REPLY :
Value Meaning
0 any of the following
1 BEGIN
2 LISTEN
3 RESPONSE
4 MESSAGE
5 INTERRUPT
6 END
The value 0 is defined for cases where a Host does not
wish to incur any overhead required to fill in the
non-zero value.
3) CATEGORY is 3 bits wide. It specifies the category of
the error indicated by the ACK bit being off :
Value Meaning
1 Command not recognized
2 Option not implemented
3 Invalid
4 Action failed.
Its value is relevant only when NAK=1.
4) TYPE is 5 bits wide. It specifies which error occurred.
Its value is relevant only when NAK=1. The possible values
and meanings for the various errors and their corresponding
CATEGORY subfield values are given under the description
of each command.
Sequencing 4i
Once communication between the Host and the FE has been established and each
side is "Ready for Business" (see Section 4b) the Host may at any time send
BEGIN or LISTEN commands for new indexes. The FE will acknowledge a BEGIN or
***WORKING DOCUMENT***
19^L
RFC 705
Front-End Protocol
***WORKING DOCUMENT***
LISTEN with a REPLY and the index is then set-up providing that the REPLY
indicates no errors. Other BEGIN or LISTEN commands for the new paths on the
same index may be sent at any time after the index is set-up.
The FE will send a RESPONSE command for each path on completion of its attempts
to fulfill the Host's instructions. If an attempt failed (indicated by the
CODE field) then the path remains closed and another BEGIN or LISTEN for that
path can be sent. If the attempt was successful, then MESSAGE or INTERRUPT
commands can be sent after the Host has REPLYED to the RESPONSE.
An INTERRUPT or END command may be sent on any opened path after receiving
a REPLY for the previous command on the same path in the same direction. A
MESSAGE command may be sent if in addition the READY bit was on in the last
REPLY command.
New paths on the same index may be opened at any time after the index has
been set-up, or particular paths may be ENDed and then have new BEGINs or
LISTENs for them issued. An index remains set-up, even if all its paths are
closed, until an END command with PATH=0 is issued for the index.
Communication between the Host and the FE is terminated by an END with INDEX=0
and this will abort any remaining open paths and indexes.
Broadcasting 4j
Broadcasting is an optional feature of the protocol. If it has been enabled
by the installation parameter, then the Host may send a MESSAGE or INTERRUPT
command on a particular index with PATH=0. This instructs the FE to send the
data contained in the TEXT field of the MESSAGE command (or an interrupt) on
every network connection corresponding to an open path of the specified index.
This feature will only occur on MESSAGEs from the Host to the FE (since no
utilization of it in the other direction is envisaged).
A broadcast MESSAGE is replied to with one or two REPLYs in the same way
as any other MESSAGE command. Flow control within the index is maintained
as if broadcast MESSAGEs were sent on a separate path, i.e., flow control
on other paths is not directly affected.
***WORKING DOCUMENT***
20^L
RFC 705
Front-End Protocol
***WORKING DOCUMENT***
Note that for a broadcast MESSAGE command the FE will perform translation
on the data for each path in accordance with the BEGIN or LISTEN which
initiated that path. Thus, care must be taken when all paths of the
particular index do not have the same format on the Host side specified in
their TRANS-TYPE (see Section 6b).
Index 0 5
Introduction 5a
Index 0 provides a control link between the Host and the FE, and thus has no
network connections directly associated with it. The commands on this index
are used to establish and terminate the connection between Host and FE and to
control other indexes.
Path 0 5b
Path 0 of Index 0 is used to pass global commands - i.e., those which do not
refer to any particular index or path. The currently defined commands are :
MESSAGE INDEX=0 COUNT PAD TEXT
where TEXT = COMMAND [PARM1] [PARM2]
COMMAND is 8 bits long
PARM1 and PARM2 are 16 bits long
a) COMMAND=1 , PARM1=Hostid
This is the "Ready for Business" command which must be sent by both
Host and FE to establish communication between them. Count gives the
length of the TEXT field as usual. If COUNT=8, then just the COMMAND
field is present. If COUNT=24, then both the COMMAND and Hostid are
present.
The FE will never send a Hostid. The Host may send its Hostid in the
event that the FE is connected to more than one IMP or if alternate
routes to the network exist (e.g., via patch panels).
Until both sides have sent this command no other command is valid.
b) COMMAND=2 , PARM1=M , PARM2=N
***WORKING DOCUMENT***
21^L
RFC 705
Front-End Protocol
***WORKING DOCUMENT***
This is the "CLOSING" command which is a purely information indication
that the sender's FEP module has been told that communication will be
terminated in M minutes for a period of N minutes (N=0 implies
unknown).
No action is required of the receiver, however he may be able to
distribute the information to his users.
c) COMMAND=3
This is the "CONTINUE" command which indicates that any previous
CLOSING command is now no longer true.
END INDEX=0 PATH+0 CODE
This command terminates the connection between the HOST and FE. All
other paths/indexes are automatically aborted and the FE will close
all network connections. The values of the CODE field are the same
as in the general END command.
Path 1 5c
Path 1 is reserved for commands specific to a particular path or index. No
commands are presently defined; they will be at a later date when more
experience has been gained on the need for them.
Path 2 5d
Path 2 of Index 0 is used for Operator-to-Operator communication between the
Host and the FE. It is an optional feature which is enabled by an installation
parameter.
MESSAGE commands are formatted in the normal manner with the sender requesting
that the TEXT field be displayed to the receiver's system operator.
Scenarios 6
The following scenarios are included to provide the reader with a "feeling" for
FEP in a varied set of applications. The examples selected relate to existing
ARPANET protocols or other networking applications, and do not represent an
exhaustive list of capabilities. 6a
***WORKING DOCUMENT***
22^L
RFC 705
Front-End Protocol
***WORKING DOCUMENT***
Fields which are variable or not relevant are not shown (for purposes of
clarity) in the command strings in the following examples. 6b
Host Implementation of User TELNET 6c
BEGIN ndxa,PATH=1,host,SKT=1,,CONN-TYPE=duplex+ICP,NPATHS=1
The User TELNET process in the Host causes the BEGIN command to be issued.
When a successful RESPONSE has been returned by the FE, a typical duplex
TELNET connection will have been made to the Host specified in the BEGIN.
Host is Providing Server TELNET 6d
LISTEN ndxa,PATH-1,HOST=0,SKT=1,,CONN-TYPE=duplex+ICP,NPATHS=32
With this one command the Server TELNET process in the Host has conditioned
the FE to LISTEN on Socket 1 (the well-advertised TELNET socket) and to
establish as many as 32 duplex data paths. The FE, through the RESPONSE
command, will report each connection as it occurs. Path 1 will represent
the first such duplex connection, etc. The Host may then manage the data
paths individually. Individual paths may be ended and placed back into a
LISTENing state by the Host. If at any time an END command specifying this
INDEX with a PATH of 0 were to be sent by the Host, all connections would
be dissolved, and for all practical purposes, the Host is no longer willing
to provide Server TELNET services.
Host is Providing Server FTP 6e
LISTEN ndxa,PATH=1,HOST=0,SKT=3,,CONN-TYPE=duplex+ICP,NPATH=1
As soon as a RESPONSE for this LISTEN comes from the FE, the Host Server FTP
process should select a new INDEX and issue a new LISTEN for ndxb on socket 3.
The duplex connection which has been made is the control path for the file
transfer. Based upon control information passed between server and user on
ndxa (path 1) the server FTP will either:
BEGIN ndxa,PATH=2,(hostid etc. from response),NPATHS=1
OR
LISTEN ndxa,PATH=2,(hostid etc. from response),NPATHS=1
***WORKING DOCUMENT***
23^L
RFC 705
Front-End Protocol
***WORKING DOCUMENT***
When a RESPONSE command has been received to the previous command, the data
connection (PATH 2) will have been made and transfer of data may begin. The
values for TRANS-TYPE and CONN-TYPE for the LISTEN or BEGIN will be derived
from the exchange of information on the control path.
Host Is User FTP 6f
BEGIN NDXA,PATH=1,HOSTID,SKT-3,,CONN-TYPE-duplex+ICP,NPATH=1
when a RESPONSE to this command has been returned by the FE the control path
will have been connected. The Host, after exchanging information on the
control path, may then proceed by issuing a BEGIN or LISTEN as in the Server
FTP example.
Teleconferencing 6g
An INDEX with n PATHs permits up to n otherwise disassociated conversations
to be affiliated. Each path can be manipulated individually, or all paths as
a group. With the broadcast option -- a MESSAGE command specifying INDEX but
not specifying PATH will be broadcast to all open paths on that index. Thus
each host may direct its messages to any or all parties.
A "conference" may be initiated by any host who issues a LISTEN with multiple
duplex paths on an agreed upon (but not necessarily well advertised) socket.
When some foreign host connects, an ordinary TELNET connection exists. If,
however, a third or forth or more parties connect, the hosts already engaged
in the conversation may elect to inform the late comers of the members already
involved. Each host may then elect to connect to as many other hosts as he
desires. (The parties could agree as to who would BEGIN and who would LISTEN).
Following this scheme [it is not a protocol] all parties participate equally,
there is no moderator. Each host decides to whom he will speak. Using the
initial LISTEN, a variation on this would permit the LISTENer to be moderator
and require that he relay messages to other parties, as desired.
In summary, the data path mechanism permits a group of users to select an
agreed upon socket, appoint a "moderator," and at a prescribed time engage in
a conference without benefit of special protocol implementations in the FE
or in any of the hosts (except possibly the moderator).
***WORKING DOCUMENT***
24^L
RFC 705
Front-End Protocol
***WORKING DOCUMENT***
Example of the Use of Simplex Connections 6h
The Simplex connection types permits a host to LISTEN on a group of simplex
sockets of a particular gender. If the host supported a group of line
printers, for example, the Line Printer Applications Program could perform a
LISTEN on a socket advertised to be his "Printing Socket," specifying as many
receive paths as he had printers. Foreign hosts could then connect (via ICP)
to his print socket. They would be given an appropriate working socket value
and then connect to an available printer. In this way up to n foreign hosts
may be connected to his n printers at all times. All that any needs to know
to avail themselves of printing services is the server host's print socket.
[1]
Host Implementation 7
Concepts 7a
The Front-End Protocol permits a Host to make use of the network through
existing low-level protocols, without requiring that it be cognizant of the
implementation details of those protocols.
Implementation of FEP in the Host is in terms of the function it is performing
or the service it is providing. Information regarding sockets is available
to the sophisticated user, but can be ignored if not relevant to the problem
at hand.
The Host should provide the equivalent of a BEGIN, LISTEN, MESSAGE, INTERRUPT,
and END command. In other words, the human user or applications level process
has at its disposal the full power of FEP.
The FEP module in the Host serves as a control mechanism to multiplex/
demultiplex traffic between itself and the FE. In appearance and function it
is much like any multi-line interface driver. It handles REPLYS, reports
errors, etc. The FEP module must also assume the responsibility for assignment
of indexes. This could easily be implemented as a "GETINDEX" subroutine
which would allow a user to ask for an index to be assigned to him. The
user could then proceed to do BEGINs, LISTENs, etc. on that index.
A server process makes itself available to the network at large by issuing an
appropriate LISTEN. The Host FEP module would not have to be aware of what
servers were implemented or in operation. The server process, when it was
***WORKING DOCUMENT***
25^L
RFC 705
Front-End Protocol
***WORKING DOCUMENT***
activated, could do a "GETINDEX," followed by a LISTEN on its well-advertised
socket, and then proceed from there. The Host FEP module simply associates
indexes to processes and passes the incoming traffic to the appropriate process
for analysis and response. It maintains flow between itself and the FE through
the generation and receipt of REPLYs.
The type of data structures, or format of information employed in the
implementation of the FEP commands in the Host is, of course, up to the
implementor. BEGIN could be a macro call, with the various information
passed as parameters to the Host FEP module -- which would then arrange it
into a command for delivery to the Front-End processor. The important
consideration is not how the commands are implemented, but simply that their
function is provided. It might be desirable, for instance, to implement the
Host such that the front-end processor looks like a special I/O device. In
this case, it may be appropriate to implement a form of OPEN [for BEGIN or
LISTEN], a GET or PUT [for MESSAGE], CLOSE [for END], etc...
Regardless of the implementation details, it appears that, while it is the
responsibility of one control module to assign and manage INDEXes, data paths
are entirely the responsibility of the process which "owns" the INDEX.
Installation Parameters 7b
To package the software for the FE for a given Host, that Host supplies a
number of parameters defining what FE capabilities it requires. These
parameters are input to a system-generation procedure to produce the particular
FE code.
The parameters are:
Byte Size
This gives the size in bits, into a multiple of which each and every
field of a command string will be right-justified (i.e., the
information bits come last, preceded by as many padding bits as are
needed to complete the least integral number of bytes).
Its value will normally be 8 but other values will be accommodated
as necessary.
***WORKING DOCUMENT***
26^L
RFC 705
Front-End Protocol
***WORKING DOCUMENT***
Command String Padding
This gives the size in bits of the width of the hardware interface
between the Host and the FE, such that every command string
transmitted in either direction will have padding appended to
complete the least multiple of this width.
In the typical implementation, this parameter will be 0 and any
padding required will be appended/discarded by the line protocol
underlying FEP.
Pad Field Length
This gives the size in bits of the PAD field in the MESSAGE command.
This enable a Host to have the TEXT field start on a convenient
boundary.
Its value can be anywhere in the range 0 to 64.
Maximum of MESSAGE
This gives the maximum length of a MESSAGE command string.
Because buffer allocation in the FE is based on this parameter,
its value should be chosen with care.
Maximum number of Indexes
This gives the maximum number of indexes which may be set-up at any one
time.
Maximum Number of Paths
This gives the maximum number of paths within one index which may be
open at any one time.
Translation Types
This gives the set of required values and meanings of the TRANS-TYPE
field of the BEGIN/LISTEN commands. The TRANS-TYPE field is divided
into two 8-bit subfields; the first giving the format of data on the
***WORKING DOCUMENT***
27^L
RFC 705
Front-End Protocol
***WORKING DOCUMENT***
network side; the second giving the format of data on the Host side.
The FE is required to translate between these formats all data
contained in the TEXT field of MESSAGE commands.
This parameter specifies the required formats and their values in the
8-bit subfields. The value 0 is reserved to mean "bit-string" and
when it appears as either (or both) of the subfields it implies no
translation is to be done.
Broadcast Option
This specifies whether the Host wants to be able to use the Broadcast
feature (see Section 3j).
Operator-to-Operator Communication Option
This specifies whether the Host wants the ability to send messages
to the FE operator or to have the Host's operator receive messages
from the FE.
Other options may be included in the protocol at some later date and these will
be available through installation parameters similar to the Broadcast option.
Note that all of these parameters affect the size and complexity of the FE
code. Thus it is important that their values be chosen carefully so as to
maximize FE efficiency while minimizing Host implementation effort.
For descriptions of individual Host implementations and a list of the options
available so far, see Appendix D.
FE Implementation 8
FEP is device independent. For the present however, an initial implementation
will be accomplished using the DEC PDP/11 computer as the FE device and the
front-end software is to be based upon an extended version of the original ELF
system developed at SCRL.
For more detailed information, see Appendix C.
by : 9
G. W. Bailey (BAILEY@OFFICE-1)
K. McCloghrie (MCCLOGHRIE@OFFICE-1)
***WORKING DOCUMENT***
28^L
RFC 705
Front-End Protocol
***WORKING DOCUMENT***
APPENDIX A 10
References
[1] ICP is used in this document in a less strict manner than specified
in NIC 7101, in that it is not necessarily two simplex connections
that are set up as the result of the exchange of the socket number
on the initial connection.
[2] An example of connections needing to be affiliated, is in the
implementation of FTP, where the control connection and the data
connection have a defined relationship in their socket assignments.
[3] Note that a range of socket numbers is reserved for use by an index
when it is set-up (cf. AEN).
However, socket numbers for the paths of an index are not necessarily
contiguous. For instance, when the next path opened after a SEND
path is another SEND path, or when a path other than the first of an
index is opened with ICP specified. Nevertheless, if a protocol
requires contiguous sockets, then the opening of the paths in a logical
manner will provide the contiguity.
[4] One possible translation will be from a Network Virtual Terminal on
the network side to a local terminal type on the Host side.
[5] The FE will directly equate the INTERRUPT command with the Host-Host
protocol INR/INS commands.
[6] Note that the READY indication in a REPLY is, in the general case,
not directly related to a network RFNM; unless it is heavily loaded,
the FE will be buffering possibly more than one message (in either
direction) until flow control mechanism allow the messages to be sent
on.
However, it is possible that a particular Host might wish to have
knowledge of receipt of a previous message before transmitting the
next. In this case, the FEP implementation could be set up to only
indicate READY after receiving the RFNM and possibly only send RFNMs
after receiving a REPLY containing an ACK.
***WORKING DOCUMENT***
29^L
RFC 705
Front-End Protocol
***WORKING DOCUMENT***
APPENDIX B 11
State Diagrams
In the state diagrams below the following notation is used:
REPLY(A) - REPLY with ACK=1, READY/NOT-READY irrelevant
REPLY(N) - REPLY with NAK=1, READY/NOT-READY irrelevant
REPLY(R) - REPLY with ACK=0, NAK=0, READY=1
REPLY(A+R) - REPLY with ACK=1, READY=1
REPLY(N+R) - REPLY with NAK=1, READY=1
REPLY(A+NR) - REPLY with ACK=1, NOT-READY=1
REPLY(N+NR) - REPLY with NAK=1, NOT-READY=1
State Diagram for INDEX
/ ------\ /-------\ /-----\
! !BEGIN(new index) ! ! ! !
! !->--------------->-!Index ! ! !
!Index !LISTEN(new index) !Open ! ! !
!Closed ! !Pending! !Index!
! ! REPLY(N)! !REPLY(A) !Open !
! !-<---------------<-! !->------->-! !
! ! \-------/ ! !
! ! ! !
! ! /-------\ END(Path=0)! !
! ! ! !-<-------------<-! !
! ! REPLY(A)!Index ! ! !
! !-<---------<-!Close !REPLY(N) ! !
! ! !Pending!->------------->-! !
\-------/ \-------/ \-----/
***WORKING DOCUMENT***
30^L
RFC 705
Front-End Protocol
***WORKING DOCUMENT***
APPENDIX B (continued)
State Diagram for Whole Path
/------\BEGIN /----------\
! !->-------->-! !
! !LISTEN !Connection!
!Path ! !Pending !REPLY(A) /-------\
!Closed! REPLY(N)! !->------------>-! !
! !-<--------<-! ! ! !
! ! \----------/ !Path !
! ! !Conn- !
! ! /-----\ RESPONSE(CODE>0)! ecting!
! ! ! !-<-----------------<-! !
! ! !Path ! ! !
! ! REPLY(A)!Abort! END(PATH>0)! !
! !-<--------<-!Pend-!-<-----------------<-! !
! ! ! ing ! ! !
! ! ! !REPLY(N) ! !
\------/ ! !->----------------->-! !
\-----/ ! !
! !
/-------\ ! !
! ! RESPONSE(CODE=0)! !
/----\ !Path !-<--------------<-! !
! ! !Open ! ! !
!Path! !Pending!REPLY(N) ! !
!Open! REPLY(A)! !->-------------->-! !
! !-<--------<-! ! \-------/
\----/ \-------/
***WORKING DOCUMENT***
31^L
RFC 705
Front-End protocol
***WORKING DOCUMENT***
APPENDIX B (continued)
State Diagram for Each Direction of Path
/----\MESSAGE /-------\ /-------\
! !->---------------->-! !REPLY(A+NR) ! !
!Path!INTERRUPT !Command!->--------->-!Message!
!Open! !Blocked!REPLY(N+NR) !Blocked!
! ! ! ! ! !
! ! REPLY(A+R)! ! INTERRUPT! !
! !-<----------------<-! !-<---------<-! !
! ! REPLY(N+R)\-------/ ! !
! ! REPLY(R)! !
! !-<----------------------<---------------<-! !
! ! ! !
! !END(PATH>0) /-------\ END(PATH>0)! !
! !->---------------->-! !-<---------<-! !
! ! ! ! ! !
! ! REPLY(N+R)!Path !REPLY(N) ! !
! !-<----------------<-!Close !->--------->-! !
\----/ !Pending! \-------/
! !
/------\ REPLY(A)! !
!Path !-<--------------<-! !
!Closed! ! !
! ! \-------/
\------/
***WORKING DOCUMENT***
32^L
RFC 705
Front-End Protocol
***WORKING DOCUMENT***
APPENDIX C
Front-End Implementation
Introduction
A Network Access System (NAS), developed for a DEC PDP/11 computer, supports
the current Imp-Host, Host-Host and ICP protocols. The implementation of
these protocols facilitate process-process communications across the network
and multi-user TELNET access to foreign hosts. This NAS provides the FE
environment in which FEP is implemented.
The NAS system is comprised of a Kernel or executive section and a Network
Control Program (NCP) plus a collection of modules to support device
interfaces, handle terminals, and implement applications, as appropriate. The
software is modular and extensible.
The KERNEL
The Kernel of the system consists of a set of functional modules which perform
the task of resource management in a multiprocessing environment. This allows
processes to be created, vie for processor service according to priority,
intercommunicate, and be terminated. System primitives exist for various
tasks such as process creation and synchronization, storage allocation, and
sharing of the interval timer.
The term process used here describes an autonomous sequence of states brought
about by the PDP-11 processor; a process' state is characterized by the set of
processor registers, a stock, and process-owned storage areas. Process share
storage areas which are accessed only (eq. pure code). Processes also share
storage areas which may be updated (eq. control tables). In this case an
allocation mechanism is utilized to prevent simultaneous ownership of an
updatable storage area. The storage area is thus viewed as a sequentially
sharable resource which is allocated by the process, modified, and then
released.
Processes are given control of the processor by a single procedure called the
Dispatcher. Processes are said to be in a ready state or in a waiting state.
When a process blocks itself, control is given to the highest priority ready
process.
***WORKING DOCUMENT***
33^L
RFC 705
Front-End Protocol
***WORKING DOCUMENT***
Each process has an associated input message queue. This queue is the vehicle
for interprocess communication. A process is blocked (put into a wait state)
when its input message queue becomes empty (voluntary wait), or when an
interrupt occurs (involuntary wait) because a higher priority process is to
receive control of the processor. A process may voluntarily block itself
waiting for any signal, or it may block itself for a specific event to be
posted to its input message queue.
The Network Control Program
The NCP provides "third level" protocol functions to local processes. It
contains a process which decodes and passes messages which have been received
from the IMP and placed on the IMP-Host queue. This process interacts with
other processes which call the NCP to establish connections or to transmit
data. Thus the NCP is essentially divided into two parts:
1) a process which handles incoming messages from the network,
interprets IMP-Host and Host-Host control messages, and forwards
regular messages on established connections; and
2) a set of primitives which allow local processes to establish
connections to other processes across the network, and to perform
requests for data to be transferred on these connections.
There are two primary data structures used by the NCP to monitor the status
of network connections. The first is called the Host Table, and describes
that which is peculiar to each given host; the second is referred to as a
Connection Table and contains all information on the state of a local NCP
socket (connection). Connection Tables may be created either through
external requests (e.q., an RFC is received from a remote host) or through
internal requests (e.g., a local process performs a LISTEN).
Flow control is that portion of the NCP which governs the flow of data on
connections. There are two procedures which perform this task; one which
handles receive connections and one which handles send connections. These
procedures receive control when an event has occurred which may now make it
possible to transfer data on a connection.
Both send and receive flow control procedures have the responsibility of moving
data between local process buffers and messages being received or transmitted
over the network. In addition, they handle the formatting and unpacking of
***WORKING DOCUMENT***
34^L
RFC 705
Front-End Protocol
***WORKING DOCUMENT***
messages received. Local processes are unaware that data is being transmitted
as discrete messages.
The NCP watchdog process monitors the state of network connections, checking
for error conditions and performing garbage collection tasks. It receives
control at periodic intervals and scans the list of known hosts, looking for
existing connections. For each host to which an input or output connection
exists, the Watchdog causes a Host-Host NOP message to be sent. Thus if a
remote Host crashes while data is being awaited, local processes are informed
of the error condition. The NCP takes notice of the remote crash when it
receives a IMP--Host type 7 control message (Destination Host Dead). It then
automatically closes all connections to that Host, and notifies using processes
of that fact.
A second function of the NCP Watchdog is to check for connections hung because
of an outstanding RFNM. If a RFNM is not received for a specified interval,
the message is discarded, and the associated connection closed.
The FEP Handler
The Front-End Protocol is implemented as a collection of related, but
specialized processes which manage network connections on the one side, and
manage FEP paths and indexes on the other. Some FEP processes are NCP users.
They cause network connections to be made, rule on incoming RFCs, and both
accept and generate network data. Other FEP processes support the Host.
These processes parse incoming commands, create indexes and paths, control
the generation of replies and generally manage the paths. Certain FEP
processes control specialized tasks such as translation of data, servicing of
LISTEN commands and generation of RESPONSE commands.
Two data structures provide control information for FEP activities. An Index
Table exists for each active index. Each Index Table associates one or more
Path Table entries. Information in the Path Table reflects the state of the
path, the translation type specified for data on this path, and necessary
information to associate the path to any appropriate NCP Connection Tables.
The Path Table is the common interface for all of the FEP modules. Most FEP
processes are activated to service some event which is usually associated to
a path. The action of the process will likely be dictated by the state of the
path as indicated by the Path Table entry, and may result in altering the state
of the path or the activation of one or more other FEP processes.
***WORKING DOCUMENT***
35^L
RFC 705
Front-End Protocol
***WORKING DOCUMENT***
Two message queues provide Host input and output to the FEP modules. A line
protocol mechanism services these queues. Commands from the Host are placed
on the FEP Input queue by the line protocol process and the FEP Host Input
process is signaled. When an FEP Host Output module places a Command for the
Host on the host Output queue it signals the line protocol process.
The FEP implementation is basically Host independent down to the level of the
Host Input and Host Output queues.
The Line Protocol Mechanism
The device interface and the line protocol between the FE and the Host are
installation dependent. Because of this dependency, only a general discussion
of the Line Protocol Mechanism is possible in this context. Detailed
descriptions of the specific line protocols are included in the section for
each Host.
The communications discipline and physical device characteristics may vary
considerably from host to host. All FEP line protocols, however, will show
certain common characteristics. The interface between the FEP handler and the
Line Protocol Mechanism will always be Host Input and Host Output queues. All
line protocol mechanisms will be expected to guarantee the integrity of the
data. This implies some form of flow control, error detection/correction and
retransmission capability, as well as normal transmit/receive responsibilities.
The Line Protocol Mechanism will be expected to report failure after
unsuccessfully attempting to perform an I/O operation. The number of retries
etc. before reporting failure is an installation parameter. The FEP Handler
works only in terms of FEP commands. The line protocol may provide for block
transfers where each physical block is comprised of one or more FEP commands.
If such is the case, it is encumbent upon the Line Protocol Mechanism to
deblock the incoming Host commands before placing them in the Host Input queue.
The Line Protocol Mechanism will, in the general case, not manage any buffers.
After successfully transmitting a command to the Host it is responsible for
reporting the I/O complete, but the buffer space is freed or reused only by
the FEP process which "owns" that space. The FEP Handler might use buffer
assignment to control the rate of incoming traffic. When the FEP Host Input
queue is ready to accept an additional command, it would acquire a buffer and
signal the Line Protocol Mechanism, passing it a pointer to a buffer. This
***WORKING DOCUMENT***
36^L
RFC 705
Front-End Protocol
***WORKING DOCUMENT***
is effectively a "read" request. When the line protocol handler has filled
the buffer, it adds it to the Host Input queue and signals I/O complete to
the appropriate FEP process.
If the nature of the physical connection is such that the FE must accept
unsolicited input, it may be necessary for the Line Protocol Mechanism to
have its own buffer pool, in addition. If this is the case, it must be
entirely managed by the line handler and transparent to the FEP Handler.
Data Translations
The TRANS-TYPE provisions in FeP may be employed for at least two general
services. First, it can be used for normal character set substitutions. This
is where, in the general case, there is a one-to-one relationship between the
two character sets.
The second service addresses the problem of data transformation. In this case,
there need not be a one-to-one relationship between incoming data and outgoing
data.
The translation mechanism uses a token (e.g., a character) from the incoming
data stream to index into a translation table. The result may be one of the
following:
a) do nothing, drop the character
b) output the character unchanged
c) substitute input character by output character
d) substitute input character by output string
e) activate a procedure indicated by the table
f) change the translation
g) test the translation mode and do any of the above depending
on the result.
For each translation/transformation required by the Host a translation table
must be defined. For simplicity and clarity the TRANS-TYPE field in the FEP
commands allows the user to specify Host side and Network side as independent
entities. In actual execution the Host/Network pair addresses a translation
table which must have been previously defined. Note that for a duplex path
two translation tables are necessary (A->B is not the same as A<-B).
A collection of "standard" character sets will be addressed initially (EBCDIC,
ASC117, ASCII8, BCD, etc.) and at least NVT. As new requirements are defined
these will be added to a library which will then be available to subsequent
users.
***WORKING DOCUMENT***
37^L
RFC 705
Front-End Protocol
***WORKING DOCUMENT***
APPENDIX D
Host Implementations
To be written at a later date.
***WORKING DOCUMENT***
38^L
|