File: rfc1374.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 (2411 lines) | stat: -rw-r--r-- 100,903 bytes parent folder | download | duplicates (8)
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
2146
2147
2148
2149
2150
2151
2152
2153
2154
2155
2156
2157
2158
2159
2160
2161
2162
2163
2164
2165
2166
2167
2168
2169
2170
2171
2172
2173
2174
2175
2176
2177
2178
2179
2180
2181
2182
2183
2184
2185
2186
2187
2188
2189
2190
2191
2192
2193
2194
2195
2196
2197
2198
2199
2200
2201
2202
2203
2204
2205
2206
2207
2208
2209
2210
2211
2212
2213
2214
2215
2216
2217
2218
2219
2220
2221
2222
2223
2224
2225
2226
2227
2228
2229
2230
2231
2232
2233
2234
2235
2236
2237
2238
2239
2240
2241
2242
2243
2244
2245
2246
2247
2248
2249
2250
2251
2252
2253
2254
2255
2256
2257
2258
2259
2260
2261
2262
2263
2264
2265
2266
2267
2268
2269
2270
2271
2272
2273
2274
2275
2276
2277
2278
2279
2280
2281
2282
2283
2284
2285
2286
2287
2288
2289
2290
2291
2292
2293
2294
2295
2296
2297
2298
2299
2300
2301
2302
2303
2304
2305
2306
2307
2308
2309
2310
2311
2312
2313
2314
2315
2316
2317
2318
2319
2320
2321
2322
2323
2324
2325
2326
2327
2328
2329
2330
2331
2332
2333
2334
2335
2336
2337
2338
2339
2340
2341
2342
2343
2344
2345
2346
2347
2348
2349
2350
2351
2352
2353
2354
2355
2356
2357
2358
2359
2360
2361
2362
2363
2364
2365
2366
2367
2368
2369
2370
2371
2372
2373
2374
2375
2376
2377
2378
2379
2380
2381
2382
2383
2384
2385
2386
2387
2388
2389
2390
2391
2392
2393
2394
2395
2396
2397
2398
2399
2400
2401
2402
2403
2404
2405
2406
2407
2408
2409
2410
2411






Network Working Group                                         J. Renwick
Request for Comments: 1374                                  A. Nicholson
                                                     Cray Research, Inc.
                                                            October 1992
                          IP and ARP on HIPPI



Status of this Memo

   This RFC specifies an IAB standards track protocol for the Internet
   community, and requests discussion and suggestions for improvements.
   Please refer to the current edition of the "IAB Official Protocol
   Standards" for the standardization state and status of this protocol.
   Distribution of this memo is unlimited.

Abstract

   The ANSI X3T9.3 committee has drafted a proposal for the
   encapsulation of IEEE 802.2 LLC PDUs and, by implication, IP on
   HIPPI.  Another X3T9.3 draft describes the operation of HIPPI
   physical switches.  X3T9.3 chose to leave HIPPI networking issues
   largely outside the scope of their standards; this document discusses
   methods of using of ANSI standard HIPPI hardware and protocols in the
   context of the Internet, including the use of HIPPI switches as LANs
   and interoperation with other networks.  


Table of Contents

      Introduction                                                   2
      Scope                                                          2
      Definitions                                                    3
      Equipment                                                      4
      Protocol                                                       6

         Packet Format                                               6
         48 bit Universal LAN MAC addresses                         10
         I-Field Format                                             11
         Rules For Connections                                      13
         MTU                                                        15

      Camp-on                                                       16
      Address Resolution                                            16

         ARP and RARP Message Format                                17
         ARP Procedure                                              21
         ARP Implementation Methods                                 22



Renwick & Nicholson                                             [Page 1]

RFC 1374                  IP and ARP on HIPPI               October 1992


         ARP Example                                                23
         Discovery of One's Own Switch Address                      25

      Path MTU Discovery                                            27
      Channel Data Rate Discovery                                   27
      Performance                                                   29
      Sharing the Switch                                            31
      Appendix A -- HIPPI Basics                                    31
      Appendix B -- How to Build a Practical HIPPI LAN              37
      References                                                    41
      Security Considerations                                       42
      Authors' Addresses                                            42

Introduction

   The ANSI High-Performance Parallel Interface (HIPPI) is a simplex
   data channel.  Configured in pairs, HIPPI can send and receive data
   simultaneously at nearly 800 megabits per second.  (HIPPI has an
   equally applicable 1600 megabit/second option.) Between 1987 and
   1991, the ANSI X3T9.3 HIPPI working group drafted four documents that
   bear on the use of HIPPI as a network interface.  They cover the
   physical and electrical specification (HIPPI-PH [1]), the framing of
   a stream of octets (HIPPI-FP [2]), encapsulation of IEEE 802.2 LLC
   (HIPPI-LE [3]), and the behavior of a standard physical layer switch
   (HIPPI-SC [4]).  HIPPI-LE also implies the encapsulation of Internet
   Protocol[5].  The reader should be familiar with the ANSI HIPPI
   documents, copies of which are archived at the site
   "nsco.network.com" in the directory "hippi," and may be obtained via
   anonymous FTP until they become published standards.

   HIPPI switches can be used to connect a variety of computers and
   peripheral equipment for many purposes, but the working group stopped
   short of describing their use as Local Area Networks.  This memo
   takes up where the working group left off, using the guiding
   principle that except for length and hardware header, Internet
   datagrams sent on HIPPI should be identical to the same datagrams
   sent on a conventional network, and that any datagram sent on a
   conventional 802 network[6] should be valid on HIPPI.

Scope

   This memo describes the HIPPI interface between a host and a
   crosspoint switch that complies with the HIPPI-SC draft standard.
   Issues that have no impact on host implementations are outside the
   scope of this memo.  Host implementations that comply with this memo
   are believed to be interoperable on a network composed of a single
   HIPPI-SC switch.  They are also interoperable on a simple point-to-
   point, two-way HIPPI connection with no switch between them.  They



Renwick & Nicholson                                             [Page 2]

RFC 1374                  IP and ARP on HIPPI               October 1992


   may as well be interoperable on more complex networks, depending on
   the internals of the switches and how they are interconnected;
   however, these details are implementation dependent and outside the
   scope of this memo.  To the extent that a gateway acts as a host on a
   HIPPI-SC LAN, its behavior is within the scope of this memo.

   Within the scope of this memo are:

   1.  Packet format and header contents, including HIPPI-FP, HIPPI-LE,
       IEEE 802.2 LLC[7], SNAP and ARP

   2.  I-Field contents

   3.  HIPPI switch address resolution, including self discovery

   4.  Rules for the use of connections.

   Outside of the scope are

   1.  Vendor dependent solutions for multicast or third party ARP

   2.  Network configuration and management

   3.  Host internal optimizations

   4.  The interface between a host and an outboard protocol processor.

Definitions

   Conventional
      Used with respect to networks, this refers to Ethernet, FDDI and
      802 LAN types, as distinct from HIPPI-SC LANs.

   Destination
      The HIPPI implementation that receives data from a HIPPI Source.

   Node
      An entity consisting of one HIPPI Source/Destination pair that is
      connected by parallel or serial HIPPI to a HIPPI-SC switch and
      that transmits and receives ARP and IP datagrams.  A node may be
      an Internet host, bridge, router or gateway.  This memo uses the
      term node in place of the usual "host" to indicate that a host
      might be connected to the HIPPI LAN not directly, but through an
      external adaptor that does some of the protocol processing for the
      host.






Renwick & Nicholson                                             [Page 3]

RFC 1374                  IP and ARP on HIPPI               October 1992


   Serial HIPPI
      An implementation of HIPPI in serial fashion on coaxial cable or
      optical fiber, informally standardized by implementor's agreement
      in the Spring of 1991.

   Switch Address
      A value used as the address of a node on a HIPPI-SC network.  It
      is transmitted in the I-field.  HIPPI-SC switches may map Switch
      Addresses to physical port numbers.

   Source
      The HIPPI implementation that generates data to send to a HIPPI
      Destination.

   Universal LAN Address (ULA)
      A 48 bit globally unique address, administered by the IEEE,
      assigned to each node on an Ethernet, FDDI, 802 network or HIPPI-
      SC LAN.

Equipment

   A HIPPI network can be composed of nodes with HIPPI interfaces, HIPPI
   cables or serial links, HIPPI-SC switches, gateways to other networks
   and, possibly, proprietary equipment that multicasts or responds to
   ARP requests on behalf of the real nodes.

   Each HIPPI interconnection between a node and a switch shall consist
   of a pair of HIPPI links, one in each direction.

   If a link between a node and the switch is capable of the 1600
   Megabit/second data rate option (i.e. Cable B installed for 64 bit
   wide operation) in either direction, the node's HIPPI-PH
   implementation shall also be capable of 32 bit operation (Cable B
   data suppressed) and shall be able to select or deselect the 1600Mb/s
   data rate option at the establishment of each new connection.

   The following figure shows a sample HIPPI switch configuration.














Renwick & Nicholson                                             [Page 4]

RFC 1374                  IP and ARP on HIPPI               October 1992


                                                   +-----+
   |                                               | H 4 |
   |                                               +--+--+
   |                   +----+    +----+    +----+     |
   |                   | H1 |    | H2 |    | H3 |   +-++
   |   +--+            +-++-+    +-++-+    +-++-+   |PP|
   +---+H5|              ||        ||        ||     ++++
   |   +--+              ||        ||        ||      ||
   |                 +---++--------++--------++------++----+
   |                 |                                     |    +---+
   |   +----+        |              HIPPI-SC               +----+ARP|
   +---+ G1 +--------+                                     +----+   |
   |   |    +--------+               Switch                |    +---+
   |   +----+        |                                     |
   |                 +---++--------++--------++------++----+
   |   +--+              ||        ||        ||      ||
   +---+H6|              ||                         ++++
   |   +--+            +-++-+                       |PP|
   |                   |    |                       +-++
   |                   | G2 |                         |
   |                   |    |                      +--+--+
   |                   +--+-+                      | H 7 |
   |                      |                        +-----+
                          |
        -----+------------+-------+-----------+-------------+------
             |                    |           |             |
             |                    |           |             |
          +--+--+              +--+--+     +--+--+       +--+--+
          | H 8 |              | H 9 |     | H10 |       | H11 |
          +-----+              +-----+     +-----+       +-----+

   Legend:  ---+---+---+--  =  802 network, Ethernet or FDDI
                        ||  =  Paired HIPPI link
                         H  =  Host computer
                        PP  =  Outboard Protocol Processor
                         G  =  Gateway
                       ARP  =  ARP Agent

                    A possible HIPPI configuration

   A single HIPPI-SC switch has a "non-blocking" characteristic, which
   means there is always a path available from any Source to any
   Destination.  If the network consists of more than one switch, the
   path from a Source to a Destination may include a HIPPI link between
   switches.  If this link is used by more than one Source/Destination
   pair, a "blocking" network is created: one Source may be blocked from
   access to a Destination because another Source is using the link it
   shares.  Strategies for establishing connections may be more



Renwick & Nicholson                                             [Page 5]

RFC 1374                  IP and ARP on HIPPI               October 1992


   complicated on blocking networks than on non-blocking ones.

   This memo ignores blocking issues, assuming that the HIPPI LAN
   consists of one HIPPI-SC switch or, if the network is more complex
   than that, it presents no additional problems that a node must be
   aware of.

Protocol

   Packet Format

   The HIPPI packet format for Internet datagrams shall conform to the
   HIPPI-FP and HIPPI-LE draft standards.  The HIPPI-FP D1_Area shall
   contain the HIPPI-LE header.  The HIPPI-FP D2_Area, when present,
   shall contain one IEEE 802.2 Type 1 LLC Unnumbered Information (UI)
   PDU.  Support of IEEE 802.2 XID, TEST and Type 2 PDUs is not required
   on HIPPI, and Destinations that receive these PDUs may either ignore
   them or respond correctly according to IEEE 802.2 requirements.

   The length of a HIPPI packet, including trailing fill, shall be a
   multiple of eight octets as required by HIPPI-LE.

   +----------+-----------+---------------------+-----------   ------+
   |          |           |                     | IP . . .     0 - 7 |
   | HIPPI-FP | HIPPI-LE  | IEEE 802.2 LLC/SNAP |              octets|
   |(8 octets)|(24 octets)|     (8 octets)      | ARP . . .     fill |
   +----------+-----------+---------------------+-----------   ------+

                        HIPPI Packet Structure


      HIPPI-FP Header

         ULP-id (8 bits) shall contain 4.

         D1_Data_Set_Present (1 bit) shall be set.

         Start_D2_on_Burst_Boundary (1 bit) shall be zero.

         Reserved (11 bits) shall contain zero.

         D1_Area_Size (8 bits) should be sent as 3.  Destinations shall
         accept any value that HIPPI-FP defines as legal: from 3 to 127
         (32 bit HIPPI) or 3 to 255 (64 bit HIPPI).

         D2_Offset (3 bits) may be any value from 0 to 7.

         D2_Size (32 bits) Shall contain the number of octets in the



Renwick & Nicholson                                             [Page 6]

RFC 1374                  IP and ARP on HIPPI               October 1992


         IEEE 802.2 LLC Type 1 PDU, or zero if no PDU is present.  It
         shall not exceed 65,288 (decimal).  This value includes the
         IEEE 802.2 LLC/SNAP header and the IP datagram.  It does not
         include trailing fill octets.  (See "MTU," below.)

         The first octet of the IEEE 802.2 LLC PDU (SSAP) shall be
         located at offset "n" of the packet, where

             n = 8 + (D1_Area_Size*8) + D2_Offset

         as specified in HIPPI-FP.

      HIPPI-LE Header

         FC (3 bits) shall contain zero unless otherwise defined by
         local administration.

         Double_Wide (1 bit) shall contain one if the Destination
         associated with the sending Source supports 64 bit HIPPI
         operation.  Otherwise it shall contain zero.

         Message_Type (4 bits) contains a code identifying the type of
         HIPPI-LE PDU.  Defined values (binary) are:

            0  Data PDU
            1  Address Resolution Request PDU (AR_Request)
            2  Address Resolution Response PDU (AR_Response)
            3  Self Address Resolution Request PDU (AR_S_Request)
            4  Self Address Resolution Response PDU (AR_S_Response)
            5-11 Reserved by the ANSI X3T9.3 committee
            12-15 Locally Assigned

         Destination_Switch_Address is a 24-bit field containing the
         Switch Address of the Destination if known, otherwise zero.  If
         the address comprises less than 24 bits, it shall be right
         justified (occupying the least significant bits) in the field.

         Destination_Address_Type (4 bits) and Source_Address_Type (4
         bits) contain codes identifying the type of addresses in the
         Destination_Switch_Address and Source_Switch_Address fields
         respectively.  Defined values (binary) are:

            0  Unspecified
            1  HIPPI-SC Source Route (24 bits)
            2  HIPPI-SC Address (12 bits)
            3-11 Reserved by the ANSI X3T9.3 committee
            12-15 Locally Assigned




Renwick & Nicholson                                             [Page 7]

RFC 1374                  IP and ARP on HIPPI               October 1992


         Source_Switch_Address is a 24-bit field containing the Switch
         Address of the Source.  If the address comprises less than 24
         bits, it shall be right justified (occupying the least
         significant bits) in the field.

         Reserved (16 bits) shall contain zero.

         Destination_IEEE_Address (48 bits) shall contain the 48 bit
         Universal LAN MAC Address of the Destination if known,
         otherwise zero.

         LE_Locally_Administered (16 bits) shall contain zero unless
         otherwise defined by local administration.

         Source_IEEE_Address (48 bits) shall contain the 48 bit
         Universal LAN MAC Address of the Source if known, otherwise
         zero.

      IEEE 802.2 LLC

         The IEEE 802.2 LLC Header shall begin in the first octet of the
         HIPPI-FP D2_Area.

         SSAP (8 bits) shall contain 170 (decimal).

         DSAP (8 bits) shall contain 170 (decimal).

         CTL (8 bits) shall contain 3 (Unnumbered Information).

      SNAP

         Organization Code (24 bits) shall be zero.

         EtherType (16 bits) shall be set as defined in Assigned Numbers
         [8] (IP = 2048, ARP = 2054, RARP = 32,821).
















Renwick & Nicholson                                             [Page 8]

RFC 1374                  IP and ARP on HIPPI               October 1992


      31    28        23  21          15        10     7         2   0
      +-----+---------+-+-+-----------+---------+-----+---------+-----+
    0 |      04       |1|0|       Reserved      |      03       |  0  |
      +---------------+-+-+---------------------+---------------+-----+
    1 |                             (n+8)                             |
      +-----+-+-------+-----------------------------------------------+
    2 |[LA] |W|M_Type |          Destination_Switch_Address           |
      +-----+-+-------+-----------------------------------------------+
    3 | D_A_T | S_A_T |             Source_Switch_Address             |
      +-------+-------+---------------+-------------------------------+
    4 |            Reserved           |  [Destination_IEEE_Address]   |
      +-------------------------------+                               |
    5 |                                                               |
      +-------------------------------+-------------------------------+
    6 |             [LA]              |     [Source_IEEE_Address]     |
      +-------------------------------+                               |
    7 |                                                               |
      +===============+===============+===============+===============+
    8 |       AA      |      AA       |       03      |       00      |
      +---------------+---------------+---------------+---------------+
    9 |       00      |      00       |         [EtherType]           |
      +---------------+---------------+---------------+---------------+
   10 |Message octet 0|Message octet 1|Message octet 2| . . .         |
      +---------------+---------------+---------------+---            |
      |                            .  .  .
                                                                      |
      |        -------+---------------+---------------+---------------+
      |         . . . |  octet (n-2)  |  octet (n-1)  |     FILL      |
      +---------------+---------------+---------------+---------------+
   N-1|      FILL     |     FILL      |     FILL      |     FILL      |
      +---------------+---------------+---------------+---------------+

                           HIPPI Packet Format

      Words 0-1:  HIPPI-FP Header
      Words 2-7:  D1 Area (HIPPI-LE Header)
      Words 8-9:  D2 Area (IEEE 802.2 LLC/SNAP)
      Words 10-(N-1):  D2 Area (IP or ARP message)
      (n) is the number of octets in the IP or ARP message.
      +====+ denotes the boundary between D1 and D2 areas.
      [LA] fields are zero unless used otherwise locally.
      Abbreviations:  "W"      = Double_Wide field;
                      "M_Type" = Message_Type field;
                      "D_A_T"  = Destination_Address_Type;
                      "S_A_T"  = Source_Address_Type;
      [FILL] octets complete the HIPPI packet to an even
      number of 32 bit words.  The number of fill octets
      is not counted in the data length.



Renwick & Nicholson                                             [Page 9]

RFC 1374                  IP and ARP on HIPPI               October 1992


   IEEE 802.2 Data

      The IEEE 802.2 Data shall follow the EtherType field immediately.
      Fill octets shall be used following the Data as necessary to make
      the number of octets in the packet a multiple of 8.  In accordance
      with HIPPI-FP, the amount of this fill is not included in the
      D2_Size value in the HIPPI-FP Header.

      The order of the octets in the data stream is from higher numbered
      to lower numbered data signal (left to right) within the HIPPI
      word, as specified in HIPPI-FP Clause 7, "Word and byte formats."
      With the 1600 megabit/second data rate option (64 bit) bits 32
      through 63 are on Cable B, so that the four octets on Cable B come
      logically before those on Cable A.  Within each octet, the most
      significant bit is the highest numbered signal.

48 bit Universal LAN MAC Addresses

   IEEE Standard 802.1A specifies the Universal LAN MAC Address.  The
   globally unique part of the 48 bit space is administered by the IEEE.
   Each node on a HIPPI-SC LAN should be assigned a ULA.  Multiple ULAs
   may be used if a node contains more than one IEEE 802.2 LLC protocol
   entity.

   The format of the address within its 48 bit HIPPI-LE fields follows
   IEEE 802.1A canonical bit order and HIPPI-FP bit and byte order:

   31              23              15               7              0
   +-------------------------------+---------------+---------------+
   |      (not used for ULA)       |ULA octet 0|L|G|  ULA octet 1  |
   +---------------+---------------+---------------+---------------+
   |  ULA octet 2  |  ULA octet 3  |  ULA octet 4  |  ULA octet 5  |
   +---------------+---------------+---------------+---------------+

                    Universal LAN MAC Address Format

      L (U/L bit) = 1 for Locally administered addresses, 0 for
      Universal.
      G (I/G bit) = 1 for Group addresses, 0 for Individual.

   The use of ULAs is optional, but encouraged.  Although ULAs are not
   used by HIPPI-SC switches, they are helpful for HIPPI Switch Address
   resolution, and for distinguishing between multiple logical entities
   that may exist within one node.  They may also be used by gateway
   devices that replace HIPPI hardware headers with the MAC headers of
   other LANs.  Carrying the ULAs in the HIPPI header may simplify these
   devices, and it may also help if HIPPI is used as an interface to
   some future HIPPI based LAN that uses ULAs for addressing.



Renwick & Nicholson                                            [Page 10]

RFC 1374                  IP and ARP on HIPPI               October 1992


Recommended HIPPI-FP Options

   HIPPI-FP allows some flexibility in the construction of a HIPPI
   packet, including placement of short bursts, optional fill and offset
   octets between the D1 and D2 areas and fill following the D2 data.
   For efficiency, Sources should limit the use of these options:

   1.  Send the short burst as the last burst of the packet rather than
       the first.

   2.  Do not place fill octets between the HIPPI-LE header and the
       start of the D2_Area.

   3.  Use no more than seven octets after the D2 Data, as needed to
       make the total packet length a multiple of 8 octets.

One HIPPI-FP option is forbidden: setting the Start_D2_on_Burst_Boundary
flag to one.  This places no limitation on the formation of packets into
a series of bursts; a Source may segment the packet in any legal manner
according to HIPPI-FP, including forcing the D2_Area to start on a burst
boundary.  The purpose of the Start_D2_on_Burst_Boundary flag is to help
preserve the segmentation of the packet for some device-control
protocols that use the first burst boundary to separate command and data
areas within the packet.  Requiring this flag to be clear means that
when a packet arrives at the Destination its burst boundaries might not
be exactly as the Source sent them.  This may occur if a HIPPI packet
passes over some other medium in the route between HIPPI LANs.

Notwithstanding these recommendations, each Destination shall accept any
well-formed HIPPI packet within the definitions in HIPPI-FP.

Note that neither HIPPI-FP nor HIPPI-LE limits the number of fill bytes
placed between the end of the IP packet and the end of the HIPPI-PH
packet.  Some source implementations may add fill sufficient to overflow
a destination input buffer.  To avoid interpreting valid packets as
errors, destinations should ignore overflow conditions and verify that
at least the number of bytes indicated by the IP header actually
arrived.

I-Field format

   The I-field bits, as defined in HIPPI-SC, shall be set as follows:

      Locally Administered (bit 31) shall be zero.

      Reserved (bits 30, 29) should be zero.  Destinations shall accept
      any value for these bits.




Renwick & Nicholson                                            [Page 11]

RFC 1374                  IP and ARP on HIPPI               October 1992


      Double wide (bit 28) shall be set when Source Cable B is connected
      and the Source wants a 64 bit connection.  It shall be zero
      otherwise.

      Direction (bit 27) should be sent as zero, however Destinations
      shall accept either zero or one and interpret the Routing Control
      field accordingly, per HIPPI-SC.

      Path Selection (bits 26, 25) shall be 00, 01, or 11 (binary) at
      the Source's option.  00 (source route mode) indicates that the
      I-field bits 23-00 contain a 24 bit source route; 01 or 11
      (logical address mode) indicate that bits 23-00 contain 12 bit
      Source and Destination Addresses.  The value 11 is meaningful when
      more than one route exists from a Source to a Destination; it
      allows the switch to choose the route.  Use of 01 forces the
      switch always to use the same route for the same
      Source/Destination pair.

      Camp-on (bit 24) may be 1 or 0; however, a Source shall not make
      consecutive requests without Camp-on to the same Destination while
      the requests are being rejected.  The purpose of this restriction
      is to prevent a node from circumventing the fair share arbitration
      mechanism of the switch by repeating requests at a very high rate.

      If logical address mode is used:

         Source Address (bits 23-12) is not used.

         Destination Address (bits 11-0) shall contain the Switch
         Address of the Destination.

      If source route mode is used:

         Routing control (bits 23-00) shall contain the route to the
         Destination.

      Note:  the outcome of Switch Address Resolution (see "Address
      Resolution" below) determines whether to use logical address mode
      or source route mode.  If source route mode is used with multiple
      interconnected switches, different sources may use different
      addresses to reach the same destination, and multicast-based
      address resolution may not be possible because a target node may
      not know the route to itself from a given remote source.
      Regardless of this difficulty, it may be possible to use source
      route mode if the network consists of a single switch, or if
      address resolution is supported by an ARP agent that is able to
      deliver correct routes to each node.  The nodes themselves need
      not be concerned with these problems if they use the addressing



Renwick & Nicholson                                            [Page 12]

RFC 1374                  IP and ARP on HIPPI               October 1992


      mode suggested by the value of the Source_Address_Type field in a
      HIPPI-LE Address Resolution Response packet.

Rules For Connections

   The following rules for connection management by Source and
   Destination are intended to insure frequent, fair share access to
   Destinations for which multiple Sources are contending.  If possible,
   nodes should transfer data at full HIPPI speeds and hold connections
   no longer than necessary.

   A source may hold a connection for as long as it takes to send 68
   HIPPI bursts at what ever speed the two connected nodes can achieve
   together.  The number of packets sent in one connection is not
   limited, except that the number of bursts over all the packets should
   not exceed 68.  This is not a recommendation to send as many packets
   as possible per connection; one packet per connection is acceptable.
   The purpose of this limit is to give each Source an fair share of a
   common Destination's bandwidth.  Without a limit, if there is a
   Destination that is constantly in demand by multiple Sources, the
   Source that sends the most data per connection wins the greatest
   share of bandwidth.

   The limit of 68 bursts is not absolute.  An implementation may check
   the burst count after transmission of a packet and end the connection
   if it is greater than or equal to some threshold.  If this is done,
   the threshold should be less than 68 depending on the typical packet
   size, to ensure that the 68 burst limit is not normally exceeded.
   For instance, a Source sending 64K packets would send two per
   connection (130 bursts) if it checked for 68 at the end of each
   packet.  In this situation the Source is required to check for a
   value small enough that it will not send a second packet in the same
   connection.

   Destinations shall accept all packets that arrive during a
   connection, and may discard those that exceed its buffering capacity.
   A Destination shall not abort a connection (deassert CONNECT) simply
   because too many bursts were received; however a Destination may
   abort a connection whose duration has exceeded a time period of the
   Destination's choosing, as long as the Source is allowed ample time
   to transmit its quota of bursts.

   The rules admonish the node to do certain things as fast as it can,
   however there is no absolute measure of compliance.  Nodes that
   cannot transfer data at full HIPPI speeds can still interoperate but
   the faster the implementation, the better the performance of the
   network will be.




Renwick & Nicholson                                            [Page 13]

RFC 1374                  IP and ARP on HIPPI               October 1992


   Assuming that bursts flow at the maximum rate, the most important
   factor in network throughput is the connection switching time,
   measured from the deassertion of REQUEST by the Source at the end of
   one connection to its first assertion of BURST after the
   establishment of the new connection.  Implementations should keep
   this time as short as possible.  For a guideline, assuming parallel
   HIPPI and a single HIPPI-SC switch, ten microseconds permits nearly
   full HIPPI throughput with full-sized packets, and at 60 microseconds
   the available throughput is reduced by about 10%.  (See
   "Performance," below.)

   All HIPPI electrical signaling shall comply with HIPPI-PH.  In every
   case, the following rules go beyond what HIPPI-PH requires.

   Rules for the Source

      1.  Do not assert REQUEST until a packet is ready to send.

      2.  Transmit bursts as quickly as READYs permit.  Except for the
          required HIPPI Source Wait states, there should be no delay in
          the assertion of BURST whenever the Source's READY counter is
          nonzero.

      3.  Make a best effort to ensure that connection durations do not
          exceed 68 bursts.

      4.  Deassert REQUEST immediately when no packet is available for
          immediate transmission or the last packet of the connection
          has been sent.

   Rules for the Destination

      1.  Reject all connections if unable to receive packets.  This
          frees the requesting Source to connect to other Destinations
          with a minimum of delay.  Inability to receive packets is not
          a transient condition, but is the state of the Destination
          when its network interface is not initialized.

      2.  A HIPPI node should be prepared to efficiently accept
          connections and process incoming data packets.  While this may
          be best achieved by not asserting connect unless 68 bursts
          worth of buffers is available, it may be possible to meet this
          requirement with fewer buffers.  This may be due to a priori
          agreement between nodes on packet sizes, the speed of the
          interface to move buffers, or other implementation dependent
          considerations.





Renwick & Nicholson                                            [Page 14]

RFC 1374                  IP and ARP on HIPPI               October 1992


      3.  Accept a connection immediately when buffers are available.
          The Destination should never delay the acceptance of a
          connection unnecessarily.

      4.  Once initialized, a Destination may reject connection requests
          only for one of the following reasons:

          1.  The I-field was received with incorrect parity.

          2.  The I-field contents are invalid, e.g. the "W" bit set
              when the Destination does not support the 1600 megabit
              data rate option, the "Locally Administered" bit is set,
              the Source is not permitted to send to this Destination,
              etc.

          Transient conditions within the Destination, such as temporary
          buffer shortages, must never cause rejected connections.

      5.  Ignore aborted connection sequences.  Sources may time out and
          abandon attempts to connect; therefore aborted connection
          sequences are normal events.

   MTU

      Maximum Transmission Unit (MTU) is defined as the length of the IP
      packet, including IP header, but not including any overhead below
      IP.  Conventional LANs have MTU sizes determined by physical layer
      specification.  MTUs may be required simply because the chosen
      medium won't work with larger packets, or they may serve to limit
      the amount of time a node must wait for an opportunity to send a
      packet.

      HIPPI has no inherent limit on packet size.  The HIPPI-FP header
      contains a 32 bit D2_Size field that, while it may limit packets
      to about 4 gigabytes, imposes no practical limit for networking
      purposes.  Even so, a HIPPI-SC switch used as a LAN needs an MTU
      so that Destination buffer sizes can be determined.

      The MTU for HIPPI-SC LANs is 65280 (decimal) octets.

      This value was selected because it allows the IP packet to fit in
      one 64K octet buffer with up to 256 octets of overhead.  The
      overhead is 40 octets at the present time; there are 216 octets of
      room for expansion.







Renwick & Nicholson                                            [Page 15]

RFC 1374                  IP and ARP on HIPPI               October 1992


         HIPPI-FP Header                  8 octets
         HIPPI-LE Header                 24 octets
         IEEE 802.2 LLC/SNAP Headers      8 octets
         Maximum IP packet size (MTU) 65280 octets
                                      ------------
                           Total      65320 octets (64K - 216)


Camp-on

   When several Sources contend for a single Destination, the Camp-on
   feature allows the HIPPI-SC switch to arbitrate and ensure that all
   Sources have fair access.  (HIPPI-SC does not specify the method of
   arbitration.)  Without Camp-on, the contending Sources would simply
   have to retry the connection repeatedly until it was accepted, and
   the fastest Source would usually win.  To guarantee fair share
   arbitration, Sources are prohibited from making repeated requests to
   the same Destination without Camp-on in such a way as to defeat the
   arbitration.

   There is another important reason to use Camp-on: when a connection
   without Camp-on is rejected, the Source cannot determine whether the
   rejection came from the requested Destination or from the switch.
   The Source also cannot tell the reason for the rejection, which could
   be either that the Destination was off line or not cabled, or the I-
   field was erroneous or had incorrect parity.  Sources should not
   treat a rejection of a request without Camp-on as an error.  Camp-on
   prevents rejection due to the temporary busy case; with one
   exception, rejection of a Camp-on request indicates an error
   condition, and an error event can be recorded.  The exception occurs
   when a 64 bit connection is attempted to a Destination that does not
   have Cable B connected, resulting in a reject.  This case is covered
   in "Channel Data Rate Discovery," below.

Address Resolution

   The Internet Address Resolution Protocol (ARP) is defined in RFC 826
   [9].  Ethernet, FDDI and 802 networks use ARP to discover another
   host's ULA knowing the Internet address.  Reverse ARP [10] is used to
   discover the Internet address, knowing the ULA.  ARP can be used in
   the conventional way on HIPPI-SC LANs equipped with a multicast
   capability or third party ARP agent.

   HIPPI-LE defines similar lower-level address resolution between ULAs
   and switches.  HIPPI-LE adds a self-address resolution mechanism not
   defined for Internet ARP, which allows a node to discover its own
   switch address dynamically.




Renwick & Nicholson                                            [Page 16]

RFC 1374                  IP and ARP on HIPPI               October 1992


   ARP for the purpose of discovering ULAs is not necessary for the
   operation of a HIPPI-SC LAN, but it serves as the vehicle for
   discovery of HIPPI-SC Switch Addresses, without which the HIPPI-SC
   LAN cannot function.  In other words, at the same time a node is
   using ARP to map another node's IP address to its ULA, it is also
   mapping the ULA to the 12 bit HIPPI Switch Address, from which it
   will construct the I-field value for sending messages to that node.
   This additional level of hardware addressing uses the address fields
   in the HIPPI-LE header.

   In the following discussion, the terms "requester" and "target" are
   used to identify the node requesting address resolution and the node
   whose address it wishes to discover, respectively.  In third party
   ARP (see "ARP Implementation Methods," below) the source of a reply
   is an ARP agent node, not the target node.

   ARP and RARP Message Format

      The HIPPI ARP/RARP protocol uses the same packet format as ARP for
      Ethernet.  ARP packets shall be transmitted with a hardware type
      code of 1 (as for Ethernet).  Furthermore, ARP packets shall be
      accepted if received with hardware type codes of either 1 or 6
      (IEEE 802 networks).

      ar$hrd (16 bits) shall contain 1.

      ar$pro (16 bits) shall contain the IP protocol code 2048
      (decimal).

      ar$hln (8 bits) shall contain 6.

      ar$pln (8 bits) shall contain 4.

      ar$op  (16 bits) shall contain 1 for requests, 2 for responses.

      ar$sha (48 bits) in requests shall contain the requester's ULA.
      In replies it shall contain the target node's ULA.

      ar$spa (32 bits) in requests shall contain the requester's IP
      address if known, otherwise zero.  In replies it shall contain the
      target node's IP address.

      ar$tha (48 bits) in requests shall contain the target's ULA if
      known, otherwise zero.  In replies it shall contain the
      requester's ULA.

      ar$tpa (32 bits) in requests shall contain the target's IP address
      if known, otherwise zero.  In replies it shall contain the



Renwick & Nicholson                                            [Page 17]

RFC 1374                  IP and ARP on HIPPI               October 1992


      requester's IP address.

      The format of the six octets of the ULA shall be the same as
      required in the HIPPI-LE header (see "48 bit Universal LAN MAC
      Addresses" above), except for the alignment of the Source ULA with
      respect to the 32 bit HIPPI word, which is different between ARP
      and HIPPI-LE.  No bit reversal is necessary as is required with
      FDDI [11].

      31    28        23  21          15        10     7         2   0
      +-----+---------+-+-+-----------+---------+-----+---------+-----+
    0 |      04       |1|0|         000         |      03       |  0  |
      +---------------+-+-+---------------------+---------------+-----+
    1 |                              36                               |
      +-----+-+-------+-----------------------+-----------------------+
    2 |[LA] |W|   1   |          000          |   Target Switch Addr  |
      +-----+-+-------+-----------------------+-----------------------+
    3 |   2   |   2   |          000          |Requester's Switch Addr|
      +---------------+---------------+-------+-----------------------+
    4 |             00 00             |                               |
      +-------------------------------+                               |
    5 |                           Target ULA                          |
      +-------------------------------+-------------------------------+
    6 |             [LA]              |                               |
      +-------------------------------+                               |
    7 |                        Requester's ULA                        |
      +===============+===============+===============+===============+
    8 |       AA      |      AA       |       03      |       00      |
      +---------------+---------------+---------------+---------------+
    9 |       00      |      00       |        EtherType (2054)       |
      +---------------+---------------+-------------------------------+
   10 |            hrd (1)            |           pro (2048)          |
      +---------------+---------------+-------------------------------+
   11 |    hln (6)    |    pln (4)    |            op (1)             |
      +---------------+---------------+-------------------------------+
   12 |                 Requester's ULA octets 0 - 3                  |
      +-------------------------------+-------------------------------+
   13 | Requester's ULA octets 4 - 5  | Requester's IP Address upper  |
      +-------------------------------+-------------------------------+
   14 | Requester's IP Address lower  |    Target ULA octets 0 - 1    |
      +-------------------------------+-------------------------------+
   15 |                   Target ULA octets 2 - 5                     |
      +---------------------------------------------------------------+
   16 |                       Target IP Address                       |
      +---------------------------------------------------------------+

                HIPPI ARP/RARP Request (logical address mode)




Renwick & Nicholson                                            [Page 18]

RFC 1374                  IP and ARP on HIPPI               October 1992


   All ARP requests shall be sent with the I-field bit 28 set to zero,
   i.e. requesting a 32 bit connection.

   Unless another convention is locally defined for ARP requests, the
   I-field Path Selection bits may be set to binary 01 or 11 (logical
   address mode), and Destination Address field set to the HIPPI-SC
   address reserved for traffic conventionally directed to the IEEE
   802.1[12] broadcast address (which HIPPI-SC defines as FE0, hex).

   Reply packets shall be sent with I-field Path Selection and Routing
   Control fields set according to the Source_Address_Type and
   Source_Switch_Address fields in the request.

   In the HIPPI-LE header of ARP/RARP requests and replies the following
   fields shall be set:

   Double-Wide should be 1 if the HIPPI Destination at the sending node
   can accept 64 bit HIPPI connections.

   Message_Type shall contain an address resolution type code as defined
   in HIPPI-LE.  It shall be set appropriately to the value of the ARP
   operation code (ar$op) in piggybacked ARP messages:

         +-----------------------+-----------------------+
         |       ARP ar$op       | HIPPI-LE Message_Type |
         +=======================+=======================+
         |ARP Request (1)        |AR_Request (1)         |
         |ARP Reply (2)          |AR_Response (2)        |
         +-----------------------+-----------------------+
         |Reverse ARP Request (3)|AR_Request (1)         |
         |Reverse ARP Reply (4)  |AR_Response (2)        |
         +-----------------------+-----------------------+

   There is no ARP message corresponding to HIPPI-LE self address
   discovery; these packets are sent without ULP data.

   Destination_Switch_Address in requests shall be the Switch Address of
   the target node if known, otherwise zero.  In replies it shall be the
   requesting node's Switch Address

   Destination_Address_Type shall be 1 if the Destination_Switch_Address
   is a source route, 2 if it is a 12 bit address.

   Source_Address_Type shall be 1 if the Source_Switch_Address is a
   source route, 2 if it is a 12 bit address.

   Source_Switch_Address in requests shall be the Switch Address of the
   requesting node if known, otherwise zero.  In replies it shall be the



Renwick & Nicholson                                            [Page 19]

RFC 1374                  IP and ARP on HIPPI               October 1992


   target node's Switch Address.

   Destination_IEEE_Address shall be the same as the ar$tha field in the
   ARP message.

   Source_IEEE_Address shall be the same as the ar$sha field in the ARP
   message.

      31    28        23  21          15        10     7         2   0
      +-----+---------+-+-+-----------+---------+-----+---------+-----+
    0 |      04       |1|0|         000         |      03       |  0  |
      +---------------+-+-+---------------------+---------------+-----+
    1 |                              36                               |
      +-----+-+-------+-----------------------+-----------------------+
    2 |[LA] |W|   2   |          000          |Requester's Switch Addr|
      +-----+-+-------+-----------------------+-----------------------+
    3 |   2   |   2   |          000          | Target Switch Address |
      +---------------+---------------+-------+-----------------------+
    4 |             00 00             |                               |
      +-------------------------------+                               |
    5 |                        Requester's ULA                        |
      +-------------------------------+-------------------------------+
    6 |             [LA]              |                               |
      +-------------------------------+                               |
    7 |                           Target ULA                          |
      +===============+===============+===============+===============+
    8 |       AA      |      AA       |       03      |       00      |
      +---------------+---------------+---------------+---------------+
    9 |       00      |      00       |        EtherType (2054)       |
      +---------------+---------------+-------------------------------+
   10 |            hrd (1)            |           pro (2048)          |
      +---------------+---------------+-------------------------------+
   11 |    hln (6)    |    pln (4)    |            op (2)             |
      +---------------+---------------+-------------------------------+
   12 |                    Target ULA octets 0 - 3                    |
      +-------------------------------+-------------------------------+
   13 |    Target ULA octets 4 - 5    |    Target IP Address upper    |
      +-------------------------------+-------------------------------+
   14 |    Target IP Address lower    | Requester's ULA octets 0 - 1  |
      +-------------------------------+-------------------------------+
   15 |                 Requester's ULA octets 2 - 5                  |
      +---------------------------------------------------------------+
   16 |                    Requester's IP Address                     |
      +---------------------------------------------------------------+

                     HIPPI ARP/RARP Reply (logical address mode)





Renwick & Nicholson                                            [Page 20]

RFC 1374                  IP and ARP on HIPPI               October 1992


ARP procedure

   The combined HIPPI-LE/ARP packet contains six addresses, three each
   for the requester and the target:

      Requester's IP Address          (ARP)
      Requester's ULA                 (ARP and HIPPI-LE)
      Requester's Switch Address      (HIPPI-LE)

      Target's IP Address             (ARP)
      Target's ULA                    (ARP and HIPPI-LE)
      Target's Switch Address         (HIPPI-LE)

   Internet ARP concerns the IP Address and ULA; HIPPI-LE address
   resolution concerns the ULA and Switch Address.  Thus the ULA appears
   in both parts of the packet.

   Successful ARP results in tables in each node that map remote nodes'
   IP addresses to ULAs and ULAs to Switch Addresses, so that when an
   application requests a connection to a remote node by its IP address,
   both the remote ULA and Switch Address can be determined, a correct
   HIPPI-LE header can be built, and a connection to the node can be
   established using the correct Switch Address in the I-field.  Any
   recipient of an ARP request or reply may use information in the
   packet to augment its tables, even if it is neither the target node
   nor the requester.

   Note that the use of ULAs with HIPPI is not required.  In both the
   HIPPI-LE header and the Internet ARP message, the fields that contain
   ULAs should be set to zero when the ULA is not known.  Address
   resolution consists of two separate protocols, HIPPI-LE address
   resolution and Internet ARP, neither of which can function
   independently without ULAs.  However HIPPI Switch Address resolution
   can work without ULAs if the two protocols are piggybacked and
   treated as one operation in which Internet addresses are mapped
   directly to switch addresses.  With the exception of the optional
   self-address resolution request, which has no analogous Internet
   protocol, HIPPI-LE address resolution and Internet ARP messages
   should be sent together as a single HIPPI packet.

   If ULAs are used, the HIPPI-LE address resolution request can be sent
   without a piggybacked 802.2 LLC PDU, so it is possible to map ULAs to
   HIPPI Switch Addresses without using ARP.  Nodes shall accept both
   piggybacked and non-piggybacked forms of HIPPI-LE address resolution
   messages.

   The recipient of an address resolution request, having first updated
   its address mapping tables with any new information it can find in



Renwick & Nicholson                                            [Page 21]

RFC 1374                  IP and ARP on HIPPI               October 1992


   the request, checks to see if it is the target node.  If it is, it
   generates a reply by filling in the unknown target address fields
   according to the HIPPI-LE message type and the ARP operation code,
   and swapping the four pairs of source/target address fields.  Then it
   connects to the requesting node with the Source Switch Address from
   the request, and sends the reply packet.

   A node is the target of an address resolution request if the request
   contains one of the following:

   1.  the node's ULA in the Destination_IEEE_Address field of a HIPPI-
       LE AR_Request message

   2.  the node's IP address in the target protocol address field
       (ar$tpa) of a piggybacked Internet ARP message

   If two target fields are known but are not mapped together in the
   recipient's address mapping tables, it may do one of three things:

   1.  treat the request as having two targets, and send correct replies
       for both to the requester.

   2.  assume its own tables are invalid and ignore the request.

   3.  assume one of the "known" target fields is correct and respond as
       if the other had been unknown.

   The best choice depends on which fields conflict and the nature of
   the implementation.  Choice 3 is probably best for ordinary nodes,
   but third party ARP agents may have reason to use one of the other
   two.  Future experience may shed light on this.

ARP Implementation Methods

   The requirements for nodes to handle address resolution messages
   depend on the means by which address resolution is implemented on the
   LAN.

   In conventional networks ARP is a distributed function. ARP requests
   are broadcast; each host may update its address mappings with any ARP
   request or reply it sees, and responds to ARP requests that contain
   its own address in the target protocol address field.  HIPPI-SC
   switches are not required to provide multicast service, although some
   do.  Even if the switches do not multicast, one or more nodes can act
   as multicast servers, receiving packets sent to the HIPPI-SC
   broadcast address and repeating them to each other node in turn.
   Either way, if multicast exists on a HIPPI-SC LAN, ARP can be a
   distributed function.  In this situation each node is required to



Renwick & Nicholson                                            [Page 22]

RFC 1374                  IP and ARP on HIPPI               October 1992


   respond correctly to address resolution requests for which it is the
   target.

   Third party ARP is a second method that does not depend on multicast.
   The switches can map the HIPPI ARP multicast address to a node that
   acts as an ARP agent, replying to ARP requests on behalf of the real
   target nodes.  Ordinary nodes never receive ARP requests or generate
   replies and never have the opportunity to update mapping tables based
   on ARP requests from other nodes, as usually happens on conventional
   networks.  Each node must request any address information it needs,
   but never has to process ARP information it doesn't need.  Under
   third party ARP a node should not receive address resolution
   requests, and each node that is not an ARP agent should ignore those
   that it does receive.

   As a third possibility, one can omit the implementation of ARP
   entirely, choosing instead to build address mapping tables in each
   node from information available to a network administrator.  Such a
   technique is implementation dependent and outside the scope of this
   memo.  It may be helpful in prototype networks without multicast
   where no ARP agent is yet implemented.  In this case, nodes are not
   required to respond to address resolution requests, but must accept
   any they may receive.

ARP Example

   Assume a HIPPI-SC switch is installed with two nodes, X and Y,
   connected.  Each node has a unique Switch Address.  Both nodes have
   access to the host data base (e.g. /etc/hosts) in which the network
   administrator has configured the network and given the two nodes IP
   addresses.  There is an ARP agent connected to a switch port that is
   mapped to the address FE0 (hex).  The ARP agent contains no mappings
   of any IP, IEEE or Switch addresses.  Both nodes know their own ULAs
   and Switch Addresses.  They want to talk to each other; each knows
   the other's IP address (from the host data base) but neither knows
   the other's ULA or Switch Address.  Node X starts:

   1.  Node X connects to FE0 and sends a piggyback ARP Request
       requesting addresses for Y:

           HIPPI-LE Message_Type is 1, AR_Request
           HIPPI-LE Destination_Switch_Address = 0
           HIPPI-LE Source_Switch_Address = X's Switch Address
           HIPPI-LE Destination_IEEE_Address = 0
           HIPPI-LE Source_IEEE_Address = X's ULA
           ARP ar$op = 1 (request)
           ARP ar$sha = X's ULA
           ARP ar$spa = X's IP Address



Renwick & Nicholson                                            [Page 23]

RFC 1374                  IP and ARP on HIPPI               October 1992


           ARP ar$tha = 0
           ARP ar$tpa = Y's IP Address

   2.  The ARP agent receives the ARP request and adds an entry for X to
       its address mapping table.  It does not know about Y, so it does
       not generate a reply.

   3.  Node X waits for a reply.  It may set a timer to retransmit the
       request periodically, but its requests will be ignored until node
       Y sends an ARP request.

   4.  Node Y connects to FE0 and sends an ARP request requesting
       addresses for X:

           HIPPI-LE Message_Type is 1, AR_Request
           HIPPI-LE Destination_Switch_Address = 0
           HIPPI-LE Source_Switch_Address = Y's Switch Address
           HIPPI-LE Destination_IEEE_Address = 0
           HIPPI-LE Source_IEEE_Address = Y's ULA
           ARP ar$op = 1 (request)
           ARP ar$sha = Y's ULA
           ARP ar$spa = Y's IP Address
           ARP ar$tha = 0
           ARP ar$tpa = X's IP Address

   5.  The ARP agent receives Y's request and adds an entry for Y to its
       address mapping table.  It knows about the target node, X, so it
       connects to Y (using the Source_Switch_Address given in the
       request) and sends an ARP Reply:

           HIPPI-LE Message_Type is 2, AR_Reply
           HIPPI-LE Destination_Switch_Address = Y's Switch Address
           HIPPI-LE Source_Switch_Address = X's Switch Address
           HIPPI-LE Destination_IEEE_Address = Y's ULA
           HIPPI-LE Source_IEEE_Address = X's ULA
           ARP ar$op = 2 (reply)
           ARP ar$sha = X's ULA
           ARP ar$spa = X's IP Address
           ARP ar$tha = Y's ULA
           ARP ar$tpa = Y's IP Address

   6.  Node Y receives the ARP reply and builds its address mapping
       table entry for Node X.

   7.  Node Y connects to node X and transmits an IP packet with the
       following information in the HIPPI-LE header:

           HIPPI-LE Message_Type is 0, AR_Data



Renwick & Nicholson                                            [Page 24]

RFC 1374                  IP and ARP on HIPPI               October 1992


           HIPPI-LE Destination_Switch_Address = X's Switch Address
           HIPPI-LE Source_Switch_Address = Y's Switch Address
           HIPPI-LE Destination_IEEE_Address = X's ULA
           HIPPI-LE Source_IEEE_Address = Y's ULA

   8.  Node X receives the IP packet.  Since the ARP agent now knows
       about node Y, node X can retransmit its ARP request (repeating
       step 1) and receive an ARP reply:

           HIPPI-LE Message_Type is 2, AR_Reply
           HIPPI-LE Destination_Switch_Address = X's Switch Address
           HIPPI-LE Source_Switch_Address = Y's Switch Address
           HIPPI-LE Destination_IEEE_Address = X's ULA
           HIPPI-LE Source_IEEE_Address = Y's ULA
           ARP ar$op = 2 (reply)
           ARP ar$sha = Y's ULA
           ARP ar$spa = Y's IP Address
           ARP ar$tha = X's ULA
           ARP ar$tpa = X's IP Address

   Address resolution is now complete for both nodes.

   If there had been a multicast facility instead of the ARP agent in
   the configuration, the target nodes themselves would have received
   the requests and responded to them in the same way the ARP agent did.

Discovery of One's Own Switch Address

   The ARP example above assumed that each node had prior knowledge of
   its own switch address.  This may be manually configured, by means
   that are outside the scope of this memo, when each node is connected
   to the switch.  If a multicast capability exists, the node may
   discover its own address automatically when it starts up, using a
   protocol defined in HIPPI-LE.

   In the self-address discovery protocol, a node connects to a
   multicast address and sends a HIPPI-LE message containing its own
   ULA.  It receives a multicast copy of its own message, and learns its
   own switch address from the destination address field of the received
   I-field.

   HIPPI-LE self address resolution uses the same HIPPI-LE message
   format described in "ARP and RARP Message Format," above, with the
   AR_S_Request and AR_S_Response message type codes and no piggybacked
   ULP data.  The HIPPI-LE header contents for the request are:

       Message_Type is 3, AR_S_Request
       Destination_Address_Type = 0 (undefined)



Renwick & Nicholson                                            [Page 25]

RFC 1374                  IP and ARP on HIPPI               October 1992


       Destination_Switch_Address = 0 (unknown)
       Source_Address_Type = 0 (undefined)
       Source_Switch_Address = 0 (unknown)
       Destination_IEEE_Address = my ULA
       Source_IEEE_Address = my ULA

   There is no D2 data; the packet contains only the HIPPI-FP header and
   D1_Area containing the HIPPI-LE header.

   The node that wants to discover its address connects to the multicast
   address for this purpose (hex FE0 in HIPPI-SC) and transmits the
   request packet.  What happens next depends on the particular network:

   With multicast:

      The node receives its own request and can learn its own switch
      address from the I-field it receives.  This is the only time a
      node should use an address from a received I-field.

   With an ARP agent:

      The node may receive an AR_S_Response message with its own ULA in
      the Destination_IEEE_Address field and its own switch address in
      the Destination_Switch_Address field.  This address may be
      different from the address contained in the I-field, and should be
      used instead.

   The ARP agent response alternative requires that the agent have prior
   knowledge of the node's location and ULA through some process not
   specified by this memo.  The node may receive both its request and
   the agent's response if both an ARP agent and multicast are active.
   In this case the address it learns from the I-field is later replaced
   by the address given by the ARP agent in the response.  Agents may
   assign new addresses to nodes and inform them by sending unsolicited
   AR_S_Response messages.  Any node whose switch address is updated in
   this way should invalidate the switch addresses it has saved for
   other nodes, and use ARP to rediscover them.

   If the node reacts correctly to either the multicast request or
   agent-generated response, it can discover its address without having
   to know whether or not an ARP agent is active.  The full procedure
   is:

   1.  Transmit the AR_S_Request







Renwick & Nicholson                                            [Page 26]

RFC 1374                  IP and ARP on HIPPI               October 1992


   2.  When a connection arrives, accept it and save the I-field for
       later analysis.

   3.  Receive the message and look at the HIPPI-LE header.  If the
       message is Message Type AR_S_Request, analyze the I-field to
       discover the node's own switch address.  HIPPI-SC I-field formats
       suggest the following:

          if bit 25 == 1
                  Address type is HIPPI-SC logical address.
                  if bit 27 == 1
                          take address from bits 23-12
                  else
                          take address from bits 11-00
                  endif
          else
                  Address is unusable (source route)
          endif

       This is a one-time operation.  Once the node knows an address for
       itself, it should not take any new address from a received I-
       field.

   4.  If a message of type AR_S_Response arrives and the
       Destination_IEEE_Address field contains the node's own ULA, take
       the new switch address from the Destination_Switch_Address field
       and its type from the Destination_Address_Type field.

   5.  The node should invalidate its ARP tables when an AR_S_Response
       changes its own switch address, to force retransmission of ARP
       requests containing its new address to all the remote nodes with
       which it communicates.


Path MTU Discovery

   RFC 1191 [13] describes the method of determining MTU restrictions on
   an arbitrary network path between two hosts.  HIPPI nodes may use
   this method without modification to discover restrictions on paths
   between HIPPI-SC LANs and other networks.  Gateways between HIPPI-SC
   LANs and other types of networks should implement RFC 1191.

Channel Data Rate Discovery

   HIPPI exists in two data rate options (800 megabit/second and 1600
   megabit/second).  The higher data rate is achieved by making the
   HIPPI 64 bits parallel instead of 32, using an extra cable containing
   32 additional data bits and four parity bits.  HIPPI-SC switches can



Renwick & Nicholson                                            [Page 27]

RFC 1374                  IP and ARP on HIPPI               October 1992


   be designed to attach to both.  Source and Destination HIPPI
   implementations can be designed to operate at either rate, selectable
   at the time a connection is established.  The "W" bit (bit 28) of the
   I-field controls the width of the connection through the switch.
   Sources with both cables A and B attached to the switch may set the
   "W" bit to request a 1600 megabit/second connection.  If the
   requested destination also has both cables attached, the switch can
   connect Source to Destination on both cables.  If the requested
   Destination has only Cable A, the switch rejects the request.
   Sixty-four bit Sources can connect to 32 bit Destinations by
   requesting with the "W" bit clear and not using Cable B.  Sixty-four
   bit Destinations must examine the "W" bit in the received I-field and
   use or ignore Cable B accordingly.  Note that both INTERCONNECT
   signals stay active while a 64 bit HIPPI is used in 32 bit mode.

   The following table summarizes the possible combinations, the
   switch's action for each, and the width of the resulting connection.

                                     Destination
                      +-------------------+-------------------+
                      |        32         |        64         |
           +----+-----+-------------------+-------------------+
           |    | W=0 |     Accept 32     |     Accept 32     |
           | 32 +-----+-------------------+-------------------+
           |    | W=1 |        N/A        |        N/A        |
   Source  +----+-----+-------------------+-------------------+
           |    | W=0 |     Accept 32     |     Accept 32     |
           | 64 +-----+-------------------+-------------------+
           |    | W=1 |      Reject       |     Accept 64     |
           +----+-----+-------------------+-------------------+

                      HIPPI Connection Combinations

   If the path between a 64 bit Source and a 64 bit Destination includes
   more than one switch, and the route between switches uses a link that
   is only 32 bits wide, the switch rejects 64 bit connection requests
   as if the Destination did not have 64 bit capability.

   In a mixed LAN of 32 bit and 64 bit HIPPIs, a 64 bit Source needs to
   know the data rates available at each Destination and on the path to
   it.  This can be known a priori by manual configuration, or it can be
   discovered dynamically.  The only reliable method of discovery is
   simply to attempt a 64 bit connection with Camp-on.  As long as 64
   bit connections succeed, the Source knows the Destination and path
   are double width.  If a 64 bit connection is rejected, the Source
   tries to connect for 32 bits.  If the 32 bit connection succeeds, the
   Source assumes that the Destination or path is not capable of double
   width operation, and uses only 32 bit requests after that.  If the 32



Renwick & Nicholson                                            [Page 28]

RFC 1374                  IP and ARP on HIPPI               October 1992


   bit request is rejected, the Source assumes that the Destination or
   path is down and makes no determination of its capability.

   The Double_Wide bit in the HIPPI-LE header, if nonzero, gives the
   node that receives it a hint that the 64 bit connection attempt may
   be worthwhile when sending on the return path.

   Note that Camp-on must be used at least in the 64 bit attempt,
   because it removes some ambiguity from the meaning of rejects.  If
   the request is made with the "W" bit and no Camp-on, a reject could
   mean either that the Destination has no Cable B or that it is simply
   busy, and no conclusion can be drawn as to its status for 64 bit
   connections.

Performance

   The HIPPI connection rules are designed to permit best utilization of
   the available HIPPI throughput under the constraint that each
   Destination must be made available frequently to receive packets from
   different Sources.  This discipline asks both Sources and
   Destinations to minimize connection setup overhead to deliver high
   performance.  Low connection setup times are easily achieved by
   hardware implementations, but overhead may be too high if software is
   required to execute between the initial request of a connection and
   the beginning of data transfer.  Hardware implementations in which
   connection setup and data transfer proceed from a single software
   action are very desirable.

   HIPPI connections are controlled by HIPPI Sources; a Destination,
   being unable to initiate a disconnect without the possibility of data
   loss, is a slave to the Source once it has accepted a connection.
   Optimizations of connection strategy are therefore the province of
   the HIPPI Source, and several optimizations are permitted.

   If the rate of available message traffic is less than the available
   HIPPI throughput and Destinations are seldom busy when a connection
   is requested, connection optimizations do not pay off and the
   simplest strategy of waiting indefinitely for each connection to be
   made and sending messages strictly in the order queued cannot be
   improved upon.  However if some nodes are slow, or network
   applications can send or receive messages at a higher aggregate rate
   than the available HIPPI bandwidth, Sources may frequently encounter
   a busy Destination.  In these cases, certain host output queuing
   strategies may enhance channel utilization.  Sources may maintain
   separate output queues for different HIPPI Destinations, and abandon
   one Destination in favor of another if a connection attempt without
   Camp-on is rejected or a connection request with Camp-on is not
   accepted within a predetermined interval.  Such a strategy results in



Renwick & Nicholson                                            [Page 29]

RFC 1374                  IP and ARP on HIPPI               October 1992


   aborted connection sequences (defined in HIPPI-PH:  REQUEST is
   deasserted before any data is sent).  Destinations must treat these
   as normal events, perhaps counting them but otherwise ignoring them.

   Two components of connection setup time are out of the control of
   both Source and Destination.  One is the time required for the switch
   to connect Source to Destination, currently less than four
   microseconds in the largest commercially available (32 port) switch.
   The second component is the round trip propagation time of the
   REQUEST and CONNECT signals, negligible on a standard 25 meter copper
   HIPPI cable, but contributing a total of about 10 microseconds per
   kilometer on fiber optic links.  HIPPI-SC LANs spanning more than a
   few kilometers will have reduced throughput.  Limited span networks
   with buffered gateways or bridges between them may perform better
   than long serial HIPPI links.

   A Source is required to drop its connection after the transmission of
   68 HIPPI bursts.  This number was chosen to allow the transmission of
   one maximum sized packet or a reasonable number of smaller sized
   packets.  The following table lists some possibilities, with
   calculated maximum burst and throughput rates in millions (10**6) of
   bytes per second:

                     Maximum HIPPI Throughput Rates

        Number  Number  Hold  Burst  ------Max throughput MB/sec-------
   User   of      of    Time  Rate    Connection Setup Overhead (usec)
   Data Packets Bursts (usec) MB/sec  10    30    60    90   120   150
   ---- ------- ------ ------ ------ ----  ----  ----  ----  ----  ----
   63K     1      64    654    98.7  97.2  94.4  90.4  86.8  83.4  80.3
   32K     2      66    665    98.6  97.1  94.3  90.4  86.8  83.5  80.4
   16K     4      68    667    98.3  96.8  94.1  90.2  86.6  83.3  80.2
    8K     7      63    587    97.8  96.1  93.0  88.7  84.8  81.2  77.8
    4K    13      65    551    96.7  95.0  91.7  87.2  83.1  79.4  76.0
    2K    22      66    476    94.6  92.7  89.0  84.0  79.6  75.6  72.0
    1K    34      68    384    90.8  88.5  84.2  78.5  73.5  75.8  65.3

   These calculations are based 259 40 ns clock periods to transmit a
   full burst and 23 clock periods for a short burst.  (HIPPI-PH
   specifies three clock periods of overhead per burst.) A packet of "n"
   kilobytes of user data consists of "n" full bursts and one short
   burst equal in length to the number of bytes in the HIPPI, LLC, IP
   and TCP headers.  "Hold Time" is the minimum connection duration
   needed to send the packets.  "Burst Rate" is the effective transfer
   rate for the duration of the connection, not counting connection
   switching time.  Throughput rates are in megabytes/second, accounting
   for connection switching times of 10, 30, 60, 90, 120 and 150
   microseconds.  These calculations ignore any limit on the rate at



Renwick & Nicholson                                            [Page 30]

RFC 1374                  IP and ARP on HIPPI               October 1992


   which a Source or Destination can process small packets; such limits
   may further reduce the available throughput if small packets are
   used.

Sharing the Switch

   Network interconnection is only one potential application of HIPPI
   and HIPPI-SC switches.  While network applications need very frequent
   transient connections, other applications may favor longer term or
   even permanent connections between Source and Destination.  Since the
   switch can serve each Source or Destination with hardware paths
   totally separate from every other, it is quite feasible to use the
   same switch to support LAN interconnects and computer/peripheral
   applications simultaneously.

   Switch sharing is no problem when unlike applications do not share a
   HIPPI cable on any path.  However if a host must use a single input
   or output cable for network as well as other kinds of traffic, or if
   a link between switches must be shared, care must be taken to ensure
   that all applications are compatible with the connection discipline
   described in this memo.  Applications that hold connections too long
   on links shared with network traffic may cause loss of network
   packets or serious degradation of network service.


Appendix A -- HIPPI Basics

   This section is included as an aid to readers who are not completely
   familiar with the HIPPI standards.

   HIPPI-PH describes a parallel copper data channel between a Source
   and a Destination.  HIPPI transmits data in one direction only, so
   that two sets are required for bidirectional flow.  The following
   figure shows a simple point-to-point link between two computer
   systems:
















Renwick & Nicholson                                            [Page 31]

RFC 1374                  IP and ARP on HIPPI               October 1992


   +----------+                                        +----------+
   |          |                                        |          |
   |          +--------+                      +--------+          |
   |          | HIPPI  |        Cable         | HIPPI  |          |
   |          |        +--------------------->|        |          |
   |          | Source |                      | Dest.  |          |
   |  System  +--------+                      +--------+  System  |
   |    X     +--------+                      +--------+    Y     |
   |          | HIPPI  |        Cable         | HIPPI  |          |
   |          |        |<---------------------+        |          |
   |          | Dest.  |                      | Source |          |
   |          +--------+                      +--------+          |
   |          |                                        |          |
   +----------+                                        +----------+

                      A Simple HIPPI Duplex Link

   Parallel copper cables may be up to 25 meters in length.

   In this document, all HIPPI connections are assumed to be paired
   HIPPI channels.

   HIPPI-PH has a single optional feature: it can use a single cable in
   each direction for a 32 bit parallel channel with a maximum data rate
   of 800 megabit/second, or two cables for 64 bits and 1600
   megabit/second.  Cable A carries bits 0-31 and is used in both modes;
   Cable B carries bits 32-63 and is use only with the 1600
   megabit/second data rate option.

   HIPPI Signal Hierarchy

      HIPPI has the following hardware signals:

      Source to Destination

         INTERCONNECT A
         INTERCONNECT B (64 bit only)
         CLOCK (25 MHz)
         REQUEST
         PACKET
         BURST
         DATA (32 or 64 signals)
         PARITY (4 or 8 signals)

      Destination to Source

         INTERCONNECT A
         INTERCONNECT B (64 bit only)



Renwick & Nicholson                                            [Page 32]

RFC 1374                  IP and ARP on HIPPI               October 1992


         CONNECT
         READY

      The INTERCONNECT lines carry DC voltages that indicate that the
      cable is connected and that the remote interface has power.
      INTERCONNECT is not used for signaling.

      The CLOCK signal is a continuous 25 MHz (40 ns period) square
      wave.  All Source-to-Destination signals are synchronized to the
      clock.

      The REQUEST and CONNECT lines are used to establish logical
      connections.  A connection is always initiated by a Source as it
      asserts REQUEST.  At the same time it puts 32 bits of data on DATA
      lines 0-31, called the I-field.  The Destination samples the DATA
      lines and can complete a connection by asserting CONNECT.  Packets
      can be transmitted only while both REQUEST and CONNECT are
      asserted.

      A Destination can also reject a connection by asserting CONNECT
      for only a short interval between 4 and 16 HIPPI clock periods
      (160-640 nanoseconds).  The Source knows a connection has been
      accepted when CONNECT is asserted for more than 16 clocks or it
      receives a READY pulse.

      Either Source or Destination can terminate a connection by
      deasserting REQUEST or CONNECT, respectively.  Normally
      connections are terminated by the Source after its last Packet has
      been sent.  A Destination cannot terminate a connection without
      potential loss of data.





















Renwick & Nicholson                                            [Page 33]

RFC 1374                  IP and ARP on HIPPI               October 1992


                +------+-------------------------+------+
                | Idle |        Connected        | Idle | . . .
                +------+-------------------------+------+
                     /                           \
                    /                             \
                   /                               \
                  /                                 \
                 /                                   \
                +-------+ +-------+ +-------+ +-------+
                |I-field| |Packet | |Packet | |Packet |
                +-------+ +-------+ +-------+ +-------+
                         /         \
                        /           \
                       /             \
                      /               \
                     /                 \
                    /                   \
                   /                     \
                  +-----+ +-----+   +-----+
                  |Burst| |Burst|...|Burst|
                  +-----+ +-----+   +-----+

                   HIPPI Logical Framing Hierarchy

      The Source asserts PACKET for the duration of a Packet
      transmission, deasserting it to indicate the end of a Packet.  A
      sequence of Bursts comprise a Packet.  To send a burst, a Source
      asserts the BURST signal for 256 clock periods, during which it
      places 256 words of data on the DATA lines.  The first or last
      Burst of a Packet may be less than 256 clock periods, allowing the
      transmission of any integral number of 32 or 64 bit words in a
      Packet.

      The READY signal is a pulse four or more clock periods long.  Each
      pulse signals the Source that the Destination can receive one
      Burst.  The Destination need not wait for a burst before sending
      another READY if it has burst buffers available; up to 63
      unanswered READYs may be sent, allowing HIPPI to operate at full
      speed over distances of many kilometers.  If a Source must wait
      for flow control, it inserts idle periods between Bursts.











Renwick & Nicholson                                            [Page 34]

RFC 1374                  IP and ARP on HIPPI               October 1992


                +------------------------------------------------+
      REQUEST---+                                                +----
                      +--------------------------------------------+
      CONNECT---------+                                            +--
                         +---------------------------------------+
      PACKET-------------+                                       +----

                       +-+   +-+   +-+   +-+   +-+   +-+   +-+   +-+
      READY------------+ +---+ +---+ +---+ +---+ +---+ +---+ +---+ +--

                         +-------+ +-------+ +-------+ +-----+
      BURST--------------+       +-+       +-+       +-+     +--------

      DATA------I-field----DATA------DATA------DATA-----DATA----------

                        HIPPI Signal Timing Diagram

   Serial HIPPI

      There is no ANSI standard for HIPPI other than the parallel copper
      cable version.  However an implementors' agreement exists,
      specifying a serial protocol to extend HIPPI signals on optical
      fiber or coaxial copper cable.  Serial links may be used
      interchangeably with parallel links to overcome HIPPI distance
      limitations; they are transparent to the Source and Destination,
      except for the possibility of longer propagation delays.

   I-Field and Switch Control

      The REQUEST, CONNECT and I-field features of HIPPI-PH were
      designed for the control of switches as described in HIPPI-SC.  A
      switch is a hub with a number of input and output HIPPI ports.
      HIPPI Sources are cabled to switch input ports, and switch output
      ports are cabled to HIPPI Destinations.  When a HIPPI Source
      requests a connection, the switch interprets the I-field to select
      an output port and electrically connects the HIPPI Source to the
      HIPPI Destination on that port.  Once connected, the switch does
      not interact with the HIPPIs in any way until REQUEST or CONNECT
      is deasserted, at which time it breaks the physical connection and
      deasserts its output signals to both sides.  Some existing switch
      implementations can switch connections in less than one
      microsecond.  There is the potential for as many simultaneous
      connections, each transferring data at HIPPI speeds, as there are
      input or output ports on the switch.  A switch offers much greater
      total throughput capacity than broadcast or ring media.






Renwick & Nicholson                                            [Page 35]

RFC 1374                  IP and ARP on HIPPI               October 1992


      31    28  26    23                      11                     0
      +-+---+-+-+---+-+-----------------------+-----------------------+
      |L|   |W|D|PS |C|    Source Address     |  Destination Address  |
      +-+---+-+-+---+-+-----------------------+-----------------------+

                  HIPPI-SC I-field Format (Logical Address Mode)

           L  = Locally defined (1 => entire I-field is locally defined)
           W  = Width (1 => 64 bit connection)
           D  = Direction (1 => swap Source and Destination Address)
           PS = Path Selection (01 => Logical Address Mode)
           C  = Camp-on (1 => wait until Destination is free)

      HIPPI-SC defines I-field formats for two different addressing
      modes.  The first, called Source Routing, encodes a string of port
      numbers in the lower 24 bits.  This string specifies a route over
      a number of switches.  A Destination's address may differ from one
      Source to another if multiple switches are used.

      The second format, called Logical Address Mode, defines two 12 bit
      fields, Source Address and Destination Address.  A Destination's
      12 bit Switch Address is the same for all Sources.  Switches
      commonly have address lookup tables to map 12 bit logical
      addresses to physical ports.  This mode is used for networking.

      Control fields in the I-field are:


      L  The "Locally Defined" bit, when set, indicates that the I-field
         is not in the standard format.  The meaning of bits 30-0 are
         locally defined.

      W  The Width bit, when set, requests a 64 bit connection through
         the switch.  It is meaningless if Cable B is not installed at
         the Source.  If W is set and either the Source or the requested
         Destination has no Cable B to the switch, the switch rejects
         the connection.  Otherwise the switch connects both Cable A and
         Cable B if W is set, or Cable A only if W is clear.  This
         feature is useful if both Source and Destination
         implementations can selectively disable or enable Cable B on
         each new connection.

      D  The Direction bit, when set, reverses the sense of the Source
         Address and Destination Address fields.  In other words, D=1
         means that the Source Address is in bits 0-11 and the
         Destination Address is in bits 12-23.  This bit was defined to
         give devices a simple way to route return messages.  It is not
         useful for LAN operations.



Renwick & Nicholson                                            [Page 36]

RFC 1374                  IP and ARP on HIPPI               October 1992


      PS The Path Selection field determines whether the I-field
         contains Source Route or Address information, and in Logical
         Address mode, whether the switch may select from multiple
         possible routes to the destination.  The value "01" selects
         Logical Address mode and fixed routes.

      C  The Camp-on bit requests the switch not to reject the
         connection if the selected Destination is busy (connected to
         another Source) but wait and make the connection when the
         Destination is free.


Appendix B -- How to Build a Practical HIPPI LAN

   "IP and ARP on HIPPI" describes the network host's view of a HIPPI
   local area network without providing much information on the
   architecture of the network itself.  Here we describe a network
   constructed from available HIPPI components, having the following
   characteristics:

   1.  A tree structure with a central HIPPI-SC compliant hub and
       optional satellite switches

   2.  Each satellite is connected to the hub by just one bidirectional
       HIPPI link.

   3.  Serial HIPPI or transparent fiber optic HIPPI extender devices
       may be used in any link.

   4.  Some satellites may be a particular switch product which is not
       HIPPI-SC compliant.

   5.  Host systems are attached either directly to the hub or to
       satellites, by single bidirectional links in which both HIPPI
       cables go to the same numbered switch port.

   6.  A server system is attached to the hub.  It provides multicast
       and ARP services.

   7.  All options of the Internet Draft are supported.  Hosts may use
       any form of address resolution: manual configuration, ARP with
       multicast, or ARP with a server.

   Switch Address Management

      Switch addresses use a flat address space.  The 12-bit address is
      subdivided into 6 bits of switch number and 6 bits of port number.




Renwick & Nicholson                                            [Page 37]

RFC 1374                  IP and ARP on HIPPI               October 1992


      11                       5                     0
      +-----------------------+-----------------------+
      |     Switch Number     |      Port Number      |
      +-----------------------+-----------------------+

                 Logical Address Construction

      Switches may be numbered arbitrarily.  A given host's address
      consists of the number of the switch it is directly attached to
      and the physical port number on that switch to which its input
      channel is attached.

      In the singly-connected tree structure, there is exactly one path
      between any pair of hosts.  Since each satellite must be connected
      directly to the hub, the maximum length of this path is three
      hops, and the minimum length is one.  Each HIPPI-SC compliant
      switch is programmed to map each of the host switch addresses to
      the appropriate output port: either the port to which the host is
      directly attached or a port that is linked to another switch in
      the path to it.

   Special Treatment of Nonstandard Switches

      There is one commercially available switch that was designed
      before the drafting of HIPPI-SC and is not fully compliant.  It is
      in common use, so it is worth making some special provisions to
      allow its use in a HIPPI LAN.  This switch supports only the
      Source Route mode of addressing with a four bit right shift that
      can be disabled by a hardware switch on each input port.
      Addresses cannot be mapped.  The switch does not support the "W,"
      "D," or "PS" fields of the I-field; it ignores their contents.
      Use of this switch as a satellite will require a slight deviation
      from normal I-field usage by the hosts that are directly attached
      to it.  Hosts attached to standard switches are not affected.

      For a destination connected to a non compliant satellite, the
      satellite uses only the least significant four bits of the I-field
      as the address.  Since the address contains the destination's
      physical port number in the least significant bits, its port will
      be selected.  Nonstandard switches should be set to disable I-
      field shifting at the input from the hub, so that the destination
      host will see its correct switch address in the I-field when
      performing self-address discovery.  I-field shifting must be
      enabled on the satellite for each input port to which a host is
      attached.

      Hosts attached to nonstandard satellites must deviate from the
      normal I-field usage when connecting to hosts on another switch.



Renwick & Nicholson                                            [Page 38]

RFC 1374                  IP and ARP on HIPPI               October 1992


      It is suggested that all host implementations have this capability
      as long as the nonstandard switches remain in use.  The host must
      know, by some manual configuration method, that it is connected to
      a nonstandard switch, and it must have its "link port" number;
      that is, the number of the port on the satellite that is connected
      to the hub.

      The normal I-field format for a 32-bit connection, per the
      Internet Draft, is this:

      31        26    23                      11                     0
      +---------+---+-+-----------------------+-----------------------+
      |0 0 0 0 0|x 1|C|        Unused         |  Destination Address  |
      +---------+---+-+-----------------------+-----------------------+

      The special I-field format is:

      31        26  24                15                     4 3     0
      +---------+---+-+---------------+-----------------------+-------+
      |0 0 0 0 0|x 1|C|    Unused     |  Destination Address  | Link  |
      +---------+---+-+---------------+-----------------------+-------+

      This I-field is altered by shifting the lower 24 bits left by four
      and adding the link port number.  Camp-on is optional, and the PS
      field is set to 01 or 11 (the host's option) as if the switch
      supported logical address mode.  All other I-field bits are set to
      zero.  When the host requests a connection with this I-field, the
      switch selects a connection through the link port to the hub, and
      shifts the lower 24 bits of the I-field right by four bits.  The
      link port number is discarded and the I-field passed through to
      the hub is a proper HIPPI-SC I-field selecting logical address
      mode.

      A host on a nonstandard satellite may use the special I-field
      format for all connection requests.  If connecting to another host
      on the same satellite, this will cause the connection to take an
      unnecessarily long path through the hub and back.  If an
      optimization is desired, the host can be given additional
      information to allow it to use the standard I-field format when
      connecting to another host on the same switch.  This information
      could consist of a list of the other hosts on the same switch, or
      the details of address formation, along with the switch number of
      the local satellite, which would allow the host to analyze the
      switch address to determine whether or not the destination is on
      the local switch.  This optimization is fairly complicated and may
      not always be worthwhile.





Renwick & Nicholson                                            [Page 39]

RFC 1374                  IP and ARP on HIPPI               October 1992


   Server Algorithm

      Different host implementations may take any of three approaches to
      address resolution:

      1.  Manual configuration, no ARP

      2.  Send ARP requests but expect a server to reply on its behalf

      3.  Send ARP requests and expect to receive them via multicast.

      If the network includes a server that is capable of both multicast
      and ARP service, and that knows the services expected by each
      host, all can coexist on the same net.

      The HIPPI-SC compliant switches are programmed to route the
      HIPPI-SC "broadcast" address FE0 (hex) to the server's port.  It
      is initially given the following information by a human network
      administrator:

      1.  The list of all addresses eligible to be used by network hosts

      2.  The list of addresses that should not receive multicast
          messages (a subset of list 1).  This is also the list of all
          hosts that either do manual configuration or expect a server
          to answer ARP requests.

      3.  The list of addresses of hosts that do manual configuration
          and do not send ARP requests (a subset of list 2) with the IP
          address corresponding to each one.

      The server maintains an address resolution cache that it
      initializes from list 3 (the manually configured hosts).  It will
      add to its cache as other hosts send ARP requests.

      When the server receives a message sent to the broadcast address
      FE0, it

      1.  Repeats the message to all addresses in list 1 but not in list
          2

      2.  If the message is a HIPPI-LE AR_Request with a piggybacked ARP
          Request, update the cache with information about the sender.

      3.  If the message is a HIPPI-LE AR_Request with a piggybacked ARP
          Request, the target system has an entry in the cache and the
          target is in list 2, respond to the ARP request.




Renwick & Nicholson                                            [Page 40]

RFC 1374                  IP and ARP on HIPPI               October 1992


      Server Optimizations

         1.  The server could be given a topological map of the hub and
             satellites from which it could construct list 1.

         2.  If all the hosts in list 2 ignore ARP messages as required
             in the Internet Draft, list 2 may be eliminated and the
             server can respond to all ARP requests (redundant replies
             may be sent).


   Sharing Switch Hardware With Other Devices

      Some host channels and peripheral devices that are connected to
      the switches may use protocols other than IP, and not participate
      in the LAN.  Since connections in a switch are independent, these
      applications can share switch hardware with no effect on LAN
      operation.  To ensure success:

         The server's lists of addresses should not include addresses
         for ports that are not used by LAN links or hosts.

         If non-LAN applications use paths between switches, separate
         links should be installed for them so that they do not use the
         same inter-switch links the LAN does.

References


[1]  ANSI X3.183-1991, High-Performance Parallel Interface - Mechanical,
     Electrical and Signalling Protocol Specification (HIPPI-PH).

[2]  ANSI X3.210-199X, High-Performance Parallel Interface - Framing
     Protocol (HIPPI-FP).

[3]  ANSI X3.218-199X, High-Performance Parallel Interface -
     Encapsulation of IEEE 802.2 (IEEE Std 802.2) Logical Link Control
     Protocol Data Units (802.2 Link Encapsulation) (HIPPI-LE).

[4]  ANSI X3.222-199X, High-Performance Parallel Interface - Physical
     Switch Control (HIPPI-SC).

[5]  Postel, J., "Internet Protocol", RFC 791, USC/Information Sciences
     Institute, September 1981.







Renwick & Nicholson                                            [Page 41]

RFC 1374                  IP and ARP on HIPPI               October 1992


[6]  Postel, J., and Reynolds, J., "A Standard for the Transmission of
     IP Datagrams over IEEE 802 Networks", RFC 1042, USC/Information
     Sciences Institute, February 1988.

[7]  IEEE, "IEEE Standards for Local Area Networks: Logical Link
     Control", IEEE, New York, New York, 1985.

[8]  Reynolds, J.K., and Postel, J., "Assigned Numbers", RFC 1340,
     USC/Information Sciences Institute, July 1992.

[9]  Plummer, D., "An Ethernet Address Resolution Protocol - or -
     Converting Network Protocol Addresses to 48.bit Ethernet Address
     for Transmission on Ethernet Hardware", RFC 826, MIT, November
     1982.

[10] Finlayson, R., Mann, T., Mogul, J., and  Theimer, M., "A Reverse
     Address Resolution Protocol", RFC 903, Stanford University, June
     1984.

[11] Katz, D., "A Proposed Standard for the Transmission of IP Datagrams
     over FDDI Networks", RFC 1188, Merit/NSFNET, October, 1990.

[12] IEEE, "Draft Standard P802.1A--Overview and Architecture", 1989.

[13] Mogul, J.C., and Deering, S.E., "Path MTU discovery", RFC 1191,
     Stanford University, November, 1990.


Security Considerations

   Security issues are not discussed in this memo.

Authors' Addresses

   John K. Renwick
   Cray Research, Inc.
   655F Lone Oak Drive
   Eagan, MN 55121

   Phone: (612) 683-5573

   Mailing List: (none)
   EMail: jkr@CRAY.COM








Renwick & Nicholson                                            [Page 42]

RFC 1374                  IP and ARP on HIPPI               October 1992


   Andy Nicholson
   Cray Research, Inc.
   655F Lone Oak Drive
   Eagan, MN 55121

   Phone: (612) 683-5473

   Mailing List: (none)
   EMail: droid@CRAY.COM










































Renwick & Nicholson                                            [Page 43]