File: rfc2353.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 (2691 lines) | stat: -rw-r--r-- 116,972 bytes parent folder | download | duplicates (5)
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
282
283
284
285
286
287
288
289
290
291
292
293
294
295
296
297
298
299
300
301
302
303
304
305
306
307
308
309
310
311
312
313
314
315
316
317
318
319
320
321
322
323
324
325
326
327
328
329
330
331
332
333
334
335
336
337
338
339
340
341
342
343
344
345
346
347
348
349
350
351
352
353
354
355
356
357
358
359
360
361
362
363
364
365
366
367
368
369
370
371
372
373
374
375
376
377
378
379
380
381
382
383
384
385
386
387
388
389
390
391
392
393
394
395
396
397
398
399
400
401
402
403
404
405
406
407
408
409
410
411
412
413
414
415
416
417
418
419
420
421
422
423
424
425
426
427
428
429
430
431
432
433
434
435
436
437
438
439
440
441
442
443
444
445
446
447
448
449
450
451
452
453
454
455
456
457
458
459
460
461
462
463
464
465
466
467
468
469
470
471
472
473
474
475
476
477
478
479
480
481
482
483
484
485
486
487
488
489
490
491
492
493
494
495
496
497
498
499
500
501
502
503
504
505
506
507
508
509
510
511
512
513
514
515
516
517
518
519
520
521
522
523
524
525
526
527
528
529
530
531
532
533
534
535
536
537
538
539
540
541
542
543
544
545
546
547
548
549
550
551
552
553
554
555
556
557
558
559
560
561
562
563
564
565
566
567
568
569
570
571
572
573
574
575
576
577
578
579
580
581
582
583
584
585
586
587
588
589
590
591
592
593
594
595
596
597
598
599
600
601
602
603
604
605
606
607
608
609
610
611
612
613
614
615
616
617
618
619
620
621
622
623
624
625
626
627
628
629
630
631
632
633
634
635
636
637
638
639
640
641
642
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
2412
2413
2414
2415
2416
2417
2418
2419
2420
2421
2422
2423
2424
2425
2426
2427
2428
2429
2430
2431
2432
2433
2434
2435
2436
2437
2438
2439
2440
2441
2442
2443
2444
2445
2446
2447
2448
2449
2450
2451
2452
2453
2454
2455
2456
2457
2458
2459
2460
2461
2462
2463
2464
2465
2466
2467
2468
2469
2470
2471
2472
2473
2474
2475
2476
2477
2478
2479
2480
2481
2482
2483
2484
2485
2486
2487
2488
2489
2490
2491
2492
2493
2494
2495
2496
2497
2498
2499
2500
2501
2502
2503
2504
2505
2506
2507
2508
2509
2510
2511
2512
2513
2514
2515
2516
2517
2518
2519
2520
2521
2522
2523
2524
2525
2526
2527
2528
2529
2530
2531
2532
2533
2534
2535
2536
2537
2538
2539
2540
2541
2542
2543
2544
2545
2546
2547
2548
2549
2550
2551
2552
2553
2554
2555
2556
2557
2558
2559
2560
2561
2562
2563
2564
2565
2566
2567
2568
2569
2570
2571
2572
2573
2574
2575
2576
2577
2578
2579
2580
2581
2582
2583
2584
2585
2586
2587
2588
2589
2590
2591
2592
2593
2594
2595
2596
2597
2598
2599
2600
2601
2602
2603
2604
2605
2606
2607
2608
2609
2610
2611
2612
2613
2614
2615
2616
2617
2618
2619
2620
2621
2622
2623
2624
2625
2626
2627
2628
2629
2630
2631
2632
2633
2634
2635
2636
2637
2638
2639
2640
2641
2642
2643
2644
2645
2646
2647
2648
2649
2650
2651
2652
2653
2654
2655
2656
2657
2658
2659
2660
2661
2662
2663
2664
2665
2666
2667
2668
2669
2670
2671
2672
2673
2674
2675
2676
2677
2678
2679
2680
2681
2682
2683
2684
2685
2686
2687
2688
2689
2690
2691






Network Working Group                                          G. Dudley
Request for Comments: 2353                                           IBM
Category: Informational                                         May 1998


                        APPN/HPR in IP Networks
           APPN Implementers' Workshop Closed Pages Document

Status of this Memo

   This memo provides information for the Internet community.  It does
   not specify an Internet standard of any kind.  Distribution of this
   memo is unlimited.

Copyright Notice

   Copyright (C) The Internet Society (1998).  All Rights Reserved.

Table of Contents

   1.0  Introduction  . . . . . . . . . . . . . . . . . . . . . . .   2
   1.1  Requirements  . . . . . . . . . . . . . . . . . . . . . . .   3
   2.0  IP as a Data Link Control (DLC) for HPR   . . . . . . . . .   3
   2.1  Use of UDP and IP   . . . . . . . . . . . . . . . . . . . .   4
   2.2  Node Structure  . . . . . . . . . . . . . . . . . . . . . .   5
   2.3  Logical Link Control (LLC) Used for IP  . . . . . . . . . .   8
     2.3.1  LDLC Liveness   . . . . . . . . . . . . . . . . . . . .   8
       2.3.1.1  Option to Reduce Liveness Traffic   . . . . . . . .   9
   2.4  IP Port Activation  . . . . . . . . . . . . . . . . . . . .  10
     2.4.1  Maximum BTU Sizes for HPR/IP  . . . . . . . . . . . . .  12
   2.5  IP Transmission Groups (TGs)  . . . . . . . . . . . . . . .  12
     2.5.1  Regular TGs   . . . . . . . . . . . . . . . . . . . . .  12
       2.5.1.1  Limited Resources and Auto-Activation   . . . . . .  19
     2.5.2  IP Connection Networks  . . . . . . . . . . . . . . . .  19
       2.5.2.1  Establishing IP Connection Networks   . . . . . . .  20
       2.5.2.2  IP Connection Network Parameters  . . . . . . . . .  22
       2.5.2.3  Sharing of TGs  . . . . . . . . . . . . . . . . . .  24
       2.5.2.4  Minimizing RSCV Length  . . . . . . . . . . . . . .  25
     2.5.3  XID Changes   . . . . . . . . . . . . . . . . . . . . .  26
     2.5.4  Unsuccessful IP Link Activation   . . . . . . . . . . .  30
   2.6  IP Throughput Characteristics   . . . . . . . . . . . . . .  34
     2.6.1  IP Prioritization   . . . . . . . . . . . . . . . . . .  34
     2.6.2  APPN Transmission Priority and COS  . . . . . . . . . .  36
     2.6.3  Default TG Characteristics  . . . . . . . . . . . . . .  36
     2.6.4  SNA-Defined COS Tables  . . . . . . . . . . . . . . . .  38
     2.6.5  Route Setup over HPR/IP links   . . . . . . . . . . . .  39
     2.6.6  Access Link Queueing  . . . . . . . . . . . . . . . . .  39
   2.7  Port Link Activation Limits   . . . . . . . . . . . . . . .  40



Dudley                       Informational                      [Page 1]

RFC 2353                APPN/HPR in IP Networks                 May 1998


   2.8  Network Management  . . . . . . . . . . . . . . . . . . . .  40
   2.9  IPv4-to-IPv6 Migration  . . . . . . . . . . . . . . . . . .  41
   3.0  References  . . . . . . . . . . . . . . . . . . . . . . . .  42
   4.0  Security Considerations   . . . . . . . . . . . . . . . . .  43
   5.0  Author's Address  . . . . . . . . . . . . . . . . . . . . .  44
   6.0  Appendix - Packet Format  . . . . . . . . . . . . . . . . .  45
   6.1  HPR Use of IP Formats   . . . . . . . . . . . . . . . . . .  45
     6.1.1  IP Format for LLC Commands and Responses  . . . . . . .  45
     6.1.2  IP Format for NLPs in UI Frames   . . . . . . . . . . .  46
   7.0  Full Copyright Statement  . . . . . . . . . . . . . . . . .  48

1.0  Introduction

   The APPN Implementers' Workshop (AIW) is an industry-wide consortium
   of networking vendors that develops Advanced Peer-to-Peer
   Networking(R) (APPN(R)) standards and other standards related to
   Systems Network Architecture (SNA), and facilitates high quality,
   fully interoperable APPN and SNA internetworking products.  The AIW
   approved Closed Pages (CP) status for the architecture in this
   document on December 2, 1997, and, as a result, the architecture was
   added to the AIW architecture of record.  A CP-level document is
   sufficiently detailed that implementing products will be able to
   interoperate; it contains a clear and complete specification of all
   necessary changes to the architecture of record.  However, the AIW
   has procedures by which the architecture may be modified, and the AIW
   is open to suggestions from the internet community.

   The architecture for APPN nodes is specified in "Systems Network
   Architecture Advanced Peer-to-Peer Networking Architecture Reference"
   [1].  A set of APPN enhancements for High Performance Routing (HPR)
   is specified in "Systems Network Architecture Advanced Peer-to-Peer
   Networking High Performance Routing Architecture Reference, Version
   3.0" [2].  The formats associated with these architectures are
   specified in "Systems Network Architecture Formats" [3].  This memo
   assumes the reader is familiar with these specifications.

   This memo defines a method with which HPR nodes can use IP networks
   for communication, and the enhancements to APPN required by this
   method.  This memo also describes an option set that allows the use
   of the APPN connection network model to allow HPR nodes to use IP
   networks for communication without having to predefine link
   connections.

   (R) 'Advanced Peer-to-Peer Networking' and 'APPN' are trademarks of
   the IBM Corporation.






Dudley                       Informational                      [Page 2]

RFC 2353                APPN/HPR in IP Networks                 May 1998


1.1  Requirements

   The following are the requirements for the architecture specified in
   this memo:

   1.  Facilitate APPN product interoperation in IP networks by
       documenting agreements such as the choice of the logical link
       control (LLC).

   2.  Reduce system definition (e.g., by extending the connection
       network model to IP networks) -- Connection network support is an
       optional function.

   3.  Use class of service (COS) to retain existing path selection and
       transmission priority services in IP networks; extend
       transmission priority function to include IP networks.

   4.  Allow customers the flexibility to design their networks for low
       cost and high performance.

   5.  Use HPR functions to improve both availability and scalability
       over existing integration techniques such as Data Link Switching
       (DLSw) which is specified in RFC 1795 [4] and RFC 2166 [5].

2.0  IP as a Data Link Control (DLC) for HPR

   This memo specifies the use of IP and UDP as a new DLC that can be
   supported by APPN nodes with the three HPR option sets:  HPR (option
   set 1400), Rapid Transport Protocol (RTP) (option set 1401), and
   Control Flows over RTP (option set 1402).  Logical Data Link Control
   (LDLC) Support (option set 2006) is also a prerequisite.

   RTP is a connection-oriented, full-duplex protocol designed to
   transport data in high-speed networks.  HPR uses RTP connections to
   transport SNA session traffic.  RTP provides reliability (i.e., error
   recovery via selective retransmission), in-order delivery (i.e., a
   first-in-first-out [FIFO] service provided by resequencing data that
   arrives out of order), and adaptive rate-based (ARB) flow/congestion
   control. Because RTP provides these functions on an end-to-end basis,
   it eliminates the need for these functions on the link level along
   the path of the connection.  The result is improved overall
   performance for HPR.  For a more complete description of RTP, see
   Appendix F of [2].

   This new DLC (referred to as the native IP DLC) allows customers to
   take advantage of APPN/HPR functions such as class of service (COS)
   and ARB flow/congestion control in the IP environment.  HPR links
   established over the native IP DLC are referred to as HPR/IP links.



Dudley                       Informational                      [Page 3]

RFC 2353                APPN/HPR in IP Networks                 May 1998


   The following sections describe in detail the considerations and
   enhancements associated with the native IP DLC.

2.1  Use of UDP and IP

   The native IP DLC will use the User Datagram Protocol (UDP) defined
   in RFC 768 [6] and the Internet Protocol (IP) version 4 defined in
   RFC 791 [7].

   Typically, access to UDP is provided by a sockets API.  UDP provides
   an unreliable connectionless delivery service using IP to transport
   messages between nodes.  UDP has the ability to distinguish among
   multiple destinations within a given node, and allows port-number-
   based prioritization in the IP network.  UDP provides detection of
   corrupted packets, a function required by HPR.  Higher-layer
   protocols such as HPR are responsible for handling problems of
   message loss, duplication, delay, out-of-order delivery, and loss of
   connectivity.  UDP is adequate because HPR uses RTP to provide end-
   to-end error recovery and in-order delivery; in addition, LDLC
   detects loss of connectivity.  The Transmission Control Protocol
   (TCP) was not chosen for the native IP DLC because the additional
   services provided by TCP such as error recovery are not needed.
   Furthermore, the termination of TCP connections would require
   additional node resources (control blocks, buffers, timers, and
   retransmit queues) and would, thereby, reduce the scalability of the
   design.

   The UDP header has four two-byte fields.  The UDP Destination Port is
   a 16-bit field that contains the UDP protocol port number used to
   demultiplex datagrams at the destination.  The UDP Source Port is a
   16-bit field that contains the UDP protocol port number that
   specifies the port to which replies should be sent when other
   information is not available.  A zero setting indicates that no
   source port number information is being provided.  When used with the
   native IP DLC, this field is not used to convey a port number for
   replies; moreover, the zero setting is not used.  IANA has registered
   port numbers 12000 through 12004 for use in these two fields by the
   native IP DLC; use of these port numbers allows prioritization in the
   IP network.  For more details of the use of these fields, see 2.6.1,
   "IP Prioritization" on page 28.

   The UDP Checksum is a 16-bit optional field that provides coverage of
   the UDP header and the user data; it also provides coverage of a
   pseudo-header that contains the source and destination IP addresses.
   The UDP checksum is used to guarantee that the data has arrived
   intact at the intended receiver.  When the UDP checksum is set to





Dudley                       Informational                      [Page 4]

RFC 2353                APPN/HPR in IP Networks                 May 1998


   zero, it indicates that the checksum was not calculated and should
   not be checked by the receiver.  Use of the checksum is recommended
   for use with the native IP DLC.

   IP provides an unreliable, connectionless delivery mechanism.  The IP
   protocol defines the basic unit of data transfer through the IP
   network, and performs the routing function (i.e., choosing the path
   over which data will be sent).  In addition, IP characterizes how
   "hosts" and "gateways" should process packets, the circumstances
   under which error messages are generated, and the conditions under
   which packets are discarded.  An IP version 4 header contains an 8-
   bit Type of Service field that specifies how the datagram should be
   handled.  As defined in RFC 1349 [8], the type-of-service byte
   contains two defined fields.  The 3-bit precedence field allows
   senders to indicate the priority of each datagram.  The 4-bit type of
   service field indicates how the network should make tradeoffs between
   throughput, delay, reliability, and cost.  The 8-bit Protocol field
   specifies which higher-level protocol created the datagram.  When
   used with the native IP DLC, this field is set to 17 which indicates
   the higher-layer protocol is UDP.

2.2  Node Structure

   Figure 1 on page 6 shows a possible node functional decomposition for
   transport of HPR traffic across an IP network.  There will be
   variations in different platforms based on platform characteristics.

   The native IP DLC includes a DLC manager, one LDLC component for each
   link, and a link demultiplexor.  Because UDP is a connectionless
   delivery service, there is no need for HPR to activate and deactivate
   lower-level connections.

   The DLC manager activates and deactivates a link demultiplexor for
   each port and an instance of LDLC for each link established in an IP
   network.  Multiple links (e.g., one defined link and one dynamic link
   for connection network traffic) may be established between a pair of
   IP addresses.  Each link is identified by the source and destination
   IP addresses in the IP header and the source and destination service
   access point (SAP) addresses in the IEEE 802.2 LLC header (see 6.0,
   "Appendix - Packet Format" on page 37); the link demultiplexor passes
   incoming packets to the correct instance of LDLC based on these
   identifiers.  Moreover, the IP address pair associated with an active
   link and used in the IP header may not change.

   LDLC also provides other functions (for example, reliable delivery of
   Exchange Identification [XID] commands).  Error recovery for HPR RTP
   packets is provided by the protocols between the RTP endpoints.




Dudley                       Informational                      [Page 5]

RFC 2353                APPN/HPR in IP Networks                 May 1998


   The network control layer (NCL) uses the automatic network routing
   (ANR) information in the HPR network header to either pass incoming
   packets to RTP or an outgoing link.

   All components are shown as single entities, but the number of
   logical instances of each is as follows:

   o   DLC manager -- 1 per node

   o   LDLC -- 1 per link

   o   Link demultiplexor -- 1 per port

   o   NCL -- 1 per node (or 1 per port for efficiency)

   o   RTP -- 1 per RTP connection

   o   UDP -- 1 per port

   o   IP -- 1 per port

   Products are free to implement other structures.  Products
   implementing other structures will need to make the appropriate
   modifications to the algorithms and protocol boundaries shown in this
   document.


























Dudley                       Informational                      [Page 6]

RFC 2353                APPN/HPR in IP Networks                 May 1998


   --------------------------------------------------------------------

                                         -*
      *-------------*       *-------*     |
      |Configuration|       | Path  |     |
      |   Services  |       |Control|     |
      *-------------*       *-------*     |
            A A                 A         |
            | |                 |         |
            | |                 V         |
            | |              *-----*      | APPN/HPR
            | |              | RTP |      |
            | |              *-----*      |
            | |                 A         |
            | |                 |         |
            | |                 V         |
            | |              *-----*      |
            | |              | NCL |      |
            | |              *-----*      |
            | *------------*    A        -*
            |              |    |
            V              V    V        -*
          *---------*    *---------*      |
          |   DLC   |--->|  LDLC   |      |
          | manager |    |         |      |
          *---------*    *---------*      |
               |              A |         | IP DLC
               *-----------*  | *----*    |
                           V  |      |    |
                         *---------* |    |
                         |  LINK   | |    |
                         |  DEMUX  | |    |
                         *---------* |    |
                              A    *-*   -*
                              |    |
                              |    V
                           *---------*
                           |   UDP   |
                           *---------*
                                A
                                |
                                V
                           *---------*
                           |   IP    |
                           *---------*

   --------------------------------------------------------------------
                      Figure 1. HPR/IP Node Structure



Dudley                       Informational                      [Page 7]

RFC 2353                APPN/HPR in IP Networks                 May 1998


2.3  Logical Link Control (LLC) Used for IP

   Logical Data Link Control (LDLC) is used by the native IP DLC.  LDLC
   is defined in [2].  LDLC uses a subset of the services defined by
   IEEE 802.2 LLC type 2 (LLC2).  LDLC uses only the TEST, XID, DISC,
   DM, and UI frames.

   LDLC was defined to be used in conjunction with HPR (with the HPR
   Control Flows over RTP option set 1402) over reliable links that do
   not require link-level error recovery.  Most frame loss in IP
   networks (and the underlying frame networks) is due to congestion,
   not problems with the facilities.  When LDLC is used on a link, no
   link-level error recovery is available; as a result, only RTP traffic
   is supported by the native IP DLC.  Using LDLC eliminates the need
   for LLC2 and its associated cost (adapter storage, longer path
   length, etc.).

2.3.1  LDLC Liveness

   LDLC liveness (using the LDLC TEST command and response) is required
   when the underlying subnetwork does not provide notification of
   connection outage.  Because UDP is connectionless, it does not
   provide outage notification; as a result, LDLC liveness is required
   for HPR/IP links.

   Liveness should be sent periodically on active links except as
   described in the following subsection when the option to reduce
   liveness traffic is implemented.  The default liveness timer period
   is 10 seconds.  When the defaults for the liveness timer and retry
   timer (15 seconds) are used, the period between liveness tests is
   smaller than the time required to detect failure (retry count
   multiplied by retry timer period) and may be smaller than the time
   for liveness to complete successfully (on the order of round-trip
   delay).  When liveness is implemented as specified in the LDLC
   finite-state machine (see [2]) this is not a problem because the
   liveness protocol works as follows:  The liveness timer is for a
   single link.  The timer is started when the link is first activated
   and each time a liveness test completes successfully.  When the timer
   expires, a liveness test is performed.  When the link is operational,
   the period between liveness tests is on the order of the liveness
   timer period plus the round-trip delay.

   For each implementation, it is necessary to check if the liveness
   protocol will work in a satisfactory manner with the default settings
   for the liveness and retry timers.  If, for example, the liveness
   timer is restarted immediately upon expiration, then a different
   default for the liveness timer should be used.




Dudley                       Informational                      [Page 8]

RFC 2353                APPN/HPR in IP Networks                 May 1998


2.3.1.1  Option to Reduce Liveness Traffic

   In some environments, it is advantageous to reduce the amount of
   liveness traffic when the link is otherwise idle.  (For example, this
   could allow underlying facilities to be temporarily deactivated when
   not needed.)  As an option, implementations may choose not to send
   liveness when the link is idle (i.e., when data was neither sent nor
   received over the link while the liveness timer was running).  (If
   the implementation is not aware of whether data has been received,
   liveness testing may be stopped while data is not being sent.)
   However, the RTP connections also have a liveness mechanism which
   will generate traffic.  Some implementations of RTP will allow
   setting a large value for the ALIVE timer, thus reducing the amount
   of RTP liveness traffic.

   If LDLC liveness is turned off while the link is idle, one side of
   the link may detect a link failure much earlier than the other.  This
   can cause the following problems:

   o   If a node that is aware of a link failure attempts to reactivate
       the link, the partner node (unaware of the link failure) may
       reject the activation as an unsupported parallel link between the
       two ports.

   o   If a node that is unaware of an earlier link failure sends data
       (including new session activations) on the link, it may be
       discarded by a node that detected the earlier failure and
       deactivated the link.  As a result, session activations would
       fail.

   The mechanisms described below can be used to remedy these problems.
   These mechanisms are needed only in a node not sending liveness when
   the link is idle; thus, they would not be required of a node not
   implementing this option that just happened to be adjacent to a node
   implementing the option.

   o   (Mandatory unless the node supports multiple active defined links
       between a pair of HPR/IP ports and supports multiple active
       dynamic links between a pair of HPR/IP ports.)  Anytime a node
       rejects the activation of an HPR/IP link as an unsupported
       parallel link between a pair of HPR/IP ports (sense data
       X'10160045' or X'10160046'), it should perform liveness on any
       active link between the two ports that is using a different SAP
       pair.  Thus, if the activation was not for a parallel link but
       rather was a reactivation because one of these active links had
       failed, the failed link will be detected.  (If the SAP pair for
       the link being activated matches the SAP pair for an active link,
       a liveness test would succeed because the adjacent node would



Dudley                       Informational                      [Page 9]

RFC 2353                APPN/HPR in IP Networks                 May 1998


       respond for the link being activated.)  A simple way to implement
       this function is for LDLC, upon receiving an activation XID, to
       run liveness on all active links with a matching IP address pair
       and a different SAP pair.

   o   (Mandatory) Anytime a node receives an activation XID with an IP
       address pair and a SAP pair that match those of an active link,
       it should deactivate the active link and allow it to be
       reestablished.  A timer is required to prevent stray XIDs from
       deactivating an active link.

   o   (Recommended) A node should attempt to reactivate an HPR/IP link
       before acting on an LDLC-detected failure.  This mechanism is
       helpful in preventing session activation failures in scenarios
       where the other side detected a link failure earlier, but the
       network has recovered.

2.4  IP Port Activation

   The node operator (NO) creates a native IP DLC by issuing
   DEFINE_DLC(RQ) (containing customer-configured parameters) and
   START_DLC(RQ) commands to the node operator facility (NOF).  NOF, in
   turn, passes DEFINE_DLC(RQ) and START_DLC(RQ) signals to
   configuration services (CS), and CS creates the DLC manager.  Then,
   the node operator can define a port by issuing DEFINE_PORT(RQ) (also
   containing customer-configured parameters) to NOF with NOF passing
   the associated signal to CS.

   A node with adapters attached to multiple IP subnetworks may
   represent the multiple adapters as a single HPR/IP port.  However, in
   that case, the node associates a single IP address with that port.
   RFC 1122 [9] requires that a node with multiple adapters be able to
   use the same source IP address on outgoing UDP packets regardless of
   the adapter used for transmission.

















Dudley                       Informational                     [Page 10]

RFC 2353                APPN/HPR in IP Networks                 May 1998


     *----------------------------------------------*
     |  NOF                CS                  DLC  |
     *----------------------------------------------*
         . DEFINE_DLC(RQ)   .
   1     o----------------->o
         . DEFINE_DLC(RSP)  |
   2     o<-----------------*
         . START_DLC(RQ)    .      create
   3     o----------------->o------------------->o
         . START_DLC(RSP)   |                    .
   4     o<-----------------*                    .
         . DEFINE_PORT(RQ)  .                    .
   5     o----------------->o                    .
         . DEFINE_PORT(RSP) |                    .
   6     o<-----------------*                    .

             Figure 2. IP Port Activation

   The following parameters are received in DEFINE_PORT(RQ):

   o   Port name

   o   DLC name

   o   Port type (if IP connection networks are supported, set to shared
       access transport facility [SATF]; otherwise, set to switched)

   o   Link station role (set to negotiable)

   o   Maximum receive BTU size (default is 1461 [1492 less an allowance
       for the IP, UDP, and LLC headers])

   o   Maximum send BTU size (default is 1461 [1492 less an allowance
       for the IP, UDP, and LLC headers])

   o   Link activation limits (total, inbound, and outbound)

   o   IPv4 supported (set to yes)

   o   The local IPv4 address (required if IPv4 is supported)

   o   IPv6 supported (set to no; may be set to yes in the future; see
       2.9, "IPv4-to-IPv6 Migration" on page 35)

   o   The local IPv6 address (required if IPv6 is supported)

   o   Retry count for LDLC (default is 3)




Dudley                       Informational                     [Page 11]

RFC 2353                APPN/HPR in IP Networks                 May 1998


   o   Retry timer period for LDLC (default is 15 seconds; a smaller
       value such as 10 seconds can be used for a campus network)

   o   LDLC liveness timer period (default is 10 seconds; see 2.3.1,
       "LDLC Liveness" on page 7)

   o   IP precedence (the setting of the 3-bit field within the Type of
       Service byte of the IP header for the LLC commands such as XID
       and for each of the APPN transmission priorities; the defaults
       are given in 2.6.1, "IP Prioritization" on page 28.)

2.4.1  Maximum BTU Sizes for HPR/IP

   When IP datagrams are larger than the underlying physical links
   support, IP performs fragmentation.  When HPR/IP links are
   established, the default maximum basic transmission unit (BTU) sizes
   are 1461 bytes, which corresponds to the typical IP maximum
   transmission unit (MTU) size of 1492 bytes supported by routers on
   token-ring networks.  1461 is 1492 less 20 bytes for the IP header, 8
   bytes for the UDP header, and 3 bytes for the IEEE 802.2 LLC header.
   The IP header is larger than 20 bytes when optional fields are
   included; smaller maximum BTU sizes should be configured if optional
   IP header fields are used in the IP network.  For IPv6, the default
   is reduced to 1441 bytes to allow for the typical IPv6 header size of
   40 bytes.  Smaller maximum BTU sizes (but not less than 768) should
   be used to avoid fragmentation when necessary.  Larger BTU sizes
   should be used to improve performance when the customer's IP network
   supports a sufficiently large IP MTU size.  The maximum receive and
   send BTU sizes are passed to CS in DEFINE_PORT(RQ).  These maximum
   BTU sizes can be overridden in DEFINE_CN_TG(RQ) or DEFINE_LS(RQ).

   The Flags field in the IP header should be set to allow
   fragmentation.  Some products will not be able to control the setting
   of the bit allowing fragmentation; in that case, fragmentation will
   most likely be allowed.  Although fragmentation is slow and prevents
   prioritization based on UDP port numbers, it does allow connectivity
   across paths with small MTU sizes.

2.5  IP Transmission Groups (TGs)

2.5.1  Regular TGs

   Regular HPR TGs may be established in IP networks using the native IP
   DLC architecture.  Each of these TGs is composed of one or more
   HPR/IP links.  Configuration services (CS) identifies the TG with the
   destination control point (CP) name and TG number; the destination CP





Dudley                       Informational                     [Page 12]

RFC 2353                APPN/HPR in IP Networks                 May 1998


   name may be configured or learned via XID, and the TG number, which
   may be configured, is negotiated via XID.  For auto-activatable
   links, the destination CP name and TG number must be configured.

   When multiple links (dynamic or defined) are established between a
   pair of IP ports (each associated with a single IP address), an
   incoming packet can be mapped to its associated link using the IP
   address pair and the service access point (SAP) address pair.  If a
   node receives an activation XID for a defined link with an IP address
   pair and a SAP pair that are the same as for an active defined link,
   that node can assume that the link has failed and that the partner
   node is reactivating the link.  In such a case as an optimization,
   the node receiving the XID can take down the active link and allow
   the link to be reestablished in the IP network.  Because UDP packets
   can arrive out of order, implementation of this optimization requires
   the use of a timer to prevent a stray XID from deactivating an active
   link.

   Support for multiple defined links between a pair of HPR/IP ports is
   optional.  There is currently no value in defining multiple HPR/IP
   links between a pair of ports.  In the future if HPR/IP support for
   the Resource ReSerVation Protocol (RSVP) [10] is defined, it may be
   advantageous to define such parallel links to segregate traffic by
   COS on RSVP "sessions."  Using RSVP, HPR would be able to reserve
   bandwidth in IP networks.  An HPR logical link would be mapped to an
   RSVP "session" that would likely be identified by either a specific
   application-provided UDP port number or a dynamically-assigned UDP
   port number.

   When multiple defined HPR/IP links between ports are not supported,
   an incoming activation for a defined HPR/IP link may be rejected with
   sense data X'10160045' if an active defined HPR/IP link already
   exists between the ports.  If the SAP pair in the activation XID
   matches the SAP pair for the existing link, the optimization
   described above may be used instead.

   If parallel defined HPR/IP links between ports are not supported, an
   incoming activation XID is mapped to the defined link station (if it
   exists) associated with the port on the adjacent node using the
   source IP address in the incoming activation XID.  This source IP
   address should be the same as the destination IP address associated
   with the matching defined link station.  (They may not be the same if
   the adjacent node has multiple IP addresses, and the configuration
   was not coordinated correctly.)

   If parallel HPR/IP links between ports are supported, multiple
   defined link stations may be associated with the port on the adjacent
   node.  In that case, predefined TG numbers (see "Partitioning the TG



Dudley                       Informational                     [Page 13]

RFC 2353                APPN/HPR in IP Networks                 May 1998


   Number Space" in Chapter 9 Configuration Services of [1]) may be used
   to map the XID to a specific link station.  However, because the same
   TG characteristics may be used for all HPR/IP links between a given
   pair of ports, all the link stations associated with the port in the
   adjacent node should be equivalent; as a result, TG number
   negotiation using negotiable TG numbers may be used.

   In the future, if multiple HPR/IP links with different
   characteristics are defined between a pair of ports using RSVP,
   defined link stations will need sufficient configured information to
   be matched with incoming XIDs.  (Correct matching of an incoming XID
   to a defined link station allows CS to provide the correct TG
   characteristics to topology and routing services (TRS).)  At that
   time CS will do the mapping based on both the IP address of the
   adjacent node and a predefined TG number.

   The node initiating link activation knows which link it is
   activating.  Some parameters sent in prenegotiation XID are defined
   in the regular link station configuration and not allowed to change
   in following negotiation-proceeding XIDs.  To allow for forward
   migration to RSVP, when a regular TG is activated in an IP network,
   the node receiving the first XID (i.e., the node not initiating link
   activation) must also understand which defined link station is being
   activated before sending a prenegotiation XID in order to correctly
   set parameters that cannot change.  For this reason, the node
   initiating link activation will indicate the TG number in
   prenegotiation XIDs by including a TG Descriptor (X'46') control
   vector containing a TG Identifier (X'80') subfield.  Furthermore, the
   node receiving the first XID will force the node activating the link
   to send the first prenegotiation XID by responding to null XIDs with
   null XIDs.  To prevent potential deadlocks, the node receiving the
   first XID has a limit (the LDLC retry count can be used) on the
   number of null XIDs it will send.  Once this limit is reached, that
   node will send an XID with an XID Negotiation Error (X'22') control
   vector in response to a null XID; sense data X'0809003A' is included
   in the control vector to indicate unexpected null XID.  If the node
   that received the first XID receives a prenegotiation XID without the
   TG Identifier subfield, it will send an XID with an XID Negotiation
   Error control vector to reject the link connection; sense data
   X'088C4680' is included in the control vector to indicate the
   subfield was missing.

   For a regular TG, the TG parameters are provided by the node operator
   based on customer configuration in DEFINE_PORT(RQ) and DEFINE_LS(RQ).
   The following parameters are supplied in DEFINE_LS(RQ) for HPR/IP
   links:





Dudley                       Informational                     [Page 14]

RFC 2353                APPN/HPR in IP Networks                 May 1998


   o   The destination IP host name (this parameter can usually be
       mapped to the destination IP address):  If the link is not
       activated at node initialization, the IP host name should be
       mapped to an IP address, and the IP address should be stored with
       the link station definition.  This is required to allow an
       incoming link activation to be matched with the link station
       definition.  If the adjacent node activates the link with a
       different IP address (e.g., it could have multiple ports), it
       will not be possible to match the link activation with the link
       station definition, and the default parameters specified in the
       local port definition will be used.

   o   The destination IP version (set to version 4, support for version
       6 may be required in the future; this parameter is only required
       if the address and version cannot be determined using the
       destination IP host name.)

   o   The destination IP address (in the format specified by the
       destination IP version; this parameter is only required if the
       address cannot be determined using the destination IP host name.)

   o   Source service access point address (SSAP) used for XID, TEST,
       DISC, and DM (default is X'04'; other values may be specified
       when multiple links between a pair of IP addresses are defined)

   o   Destination service access point address (DSAP) used for XID,
       TEST, DISC, and DM (default is X'04')

   o   Source service access point address (SSAP) used for HPR network
       layer packets (NLPs) (default is X'C8'; other values may be
       specified when multiple links between a pair of IP addresses are
       defined.)

   o   Maximum receive BTU size (default is 1461; this parameter is used
       to override the setting in DEFINE_PORT.)

   o   Maximum send BTU size (default is 1461; this parameter is used to
       override the setting in DEFINE_PORT.)

   o   IP precedence (the setting of the 3-bit field within the Type of
       Service byte of the IP header for LLC commands such as XID and
       for each of the APPN transmission priorities; the defaults are
       given in 2.6.1, "IP Prioritization" on page 28; this parameter is
       used to override the settings in DEFINE_PORT)

   o   Shareable with connection network traffic (default is yes for
       non-RSVP links)




Dudley                       Informational                     [Page 15]

RFC 2353                APPN/HPR in IP Networks                 May 1998


   o   Retry count for LDLC (default is 3; this parameter is used to
       override the setting in DEFINE_PORT)

   o   Retry timer period for LDLC (default is 15 seconds; a smaller
       value such as 10 seconds can be used for a campus link; this
       parameter is used to override the setting in DEFINE_PORT)

   o   LDLC liveness timer period (default is 10 seconds; this parameter
       is to override the setting in DEFINE_PORT; see 2.3.1, "LDLC ness"
       on page 7)

   o   Auto-activation supported (default is no; may be set to yes when
       the local node has switched access to the IP network)

   o   Limited resource (default is to set in concert with auto-
       activation supported)

   o   Limited resource liveness timer (default is 45 sec.)

   o   Port name

   o   Adjacent CP name (optional)

   o   Local CP-CP sessions supported

   o   Defined TG number (optional)

   o   TG characteristics

   The following figures show the activation and deactivation of regular
   TGs.




















Dudley                       Informational                     [Page 16]

RFC 2353                APPN/HPR in IP Networks                 May 1998


*------------------------------------------------------------------*
|CS              DLC             LDLC           DMUX            UDP|
*------------------------------------------------------------------*
 .                .                              .               .
 .CONNECT_OUT(RQ) .  create                      .               .
 o--------------->o-------------->o              .               .
 .                |        new LDLC              .               .
 .                o----------------------------->o               .
 CONNECT_OUT(+RSP)|               .              .               .
 o<---------------*               .              .               .
 |               XID              .           XID(CMD)           . XID
 *------------------------------->o----------------------------->o----->

               Figure 3. Regular TG Activation (outgoing)

   In Figure 3 upon receiving START_LS(RQ) from NOF, CS starts the link
   activation process by sending CONNECT_OUT(RQ) to the DLC manager.
   The DLC manager creates an instance of LDLC for the link, informs the
   link demultiplexor, and sends CONNECT_OUT(+RSP) to CS.  Then, CS
   starts the activation XID exchange.

*------------------------------------------------------------------*
|CS              DLC             LDLC           DMUX            UDP|
*------------------------------------------------------------------*
 .                .                              .               .
 . CONNECT_IN(RQ) .          XID(CMD)            .     XID       . XID
 o<---------------o<-----------------------------o<--------------o<-----
 | CONNECT_IN(RSP).    create                    .               .
 *--------------->o-------------->o              .               .
 .                |          new LDLC            .               .
 .                o----------------------------->o               .
 .                |  XID(CMD)     .              .               .
 .                *-------------->o              .               .
 .               XID              |              .               .
 o<-------------------------------*              .               .
 |               XID              .            XID(RSP)          . XID
 *------------------------------->o----------------------------->o----->

               Figure 4. Regular TG Activation (incoming)

   In Figure 4, when an XID is received for a new link, it is passed to
   the DLC manager.  The DLC manager sends CONNECT_IN(RQ) to notify CS
   of the incoming link activation, and CS sends CONNECT_IN(+RSP)
   accepting the link activation.  The DLC manager then creates a new
   instance of LDLC, informs the link demultiplexor, and forwards the
   XID to to CS via LDLC.  CS then responds by sending an XID to the
   adjacent node.




Dudley                       Informational                     [Page 17]

RFC 2353                APPN/HPR in IP Networks                 May 1998


   The two following figures show normal TG deactivation (outgoing and
   incoming).

*------------------------------------------------------------------*
|CS              DLC             LDLC           DMUX            UDP|
*------------------------------------------------------------------*
 .                .               .              .               .
 .             DEACT              .            DISC              . DISC
 o------------------------------->o----------------------------->o----->
 .             DEACT              .       DM     .       DM      . DM
 o<-------------------------------o<-------------o<--------------o<-----
 | DISCONNECT(RQ) .    destroy    .              .               .
 *--------------->o-------------->o              .               .
  DISCONNECT(RSP) |                              .               .
 o<---------------*                              .               .

              Figure 5. Regular TG Deactivation (outgoing)

   In Figure 5 upon receiving STOP_LS(RQ) from NOF, CS sends DEACT to
   notify the partner node that the HPR link is being deactivated.  When
   the response is received, CS sends DISCONNECT(RQ) to the DLC manager,
   and the DLC manager deactivates the instance of LDLC.  Upon receiving
   DISCONNECT(RSP), CS sends STOP_LS(RSP) to NOF.

*------------------------------------------------------------------*
|CS              DLC             LDLC           DMUX            UDP|
*------------------------------------------------------------------*
 .                .               .              .               .
 .             DEACT              .      DISC    .      DISC     . DISC
 o<-------------------------------o<-------------o<--------------o<-----
 |                .               |             DM               . DM
 |                .               *----------------------------->o----->
 | DISCONNECT(RQ) .    destroy    .              .               .
 *--------------->o-------------->o              .               .
 .DISCONNECT(RSP) |                              .               .
 o<---------------*                              .               .

              Figure 6. Regular TG Deactivation (incoming)

   In Figure 6, when an adjacent node deactivates a TG, the local node
   receives a DISC.  CS sends STOP_LS(IND) to NOF.  Because IP is
   connectionless, the DLC manager is not aware that the link has been
   deactivated.  For that reason, CS also needs to send DISCONNECT(RQ)
   to the DLC manager; the DLC manager deactivates the instance of LDLC.







Dudley                       Informational                     [Page 18]

RFC 2353                APPN/HPR in IP Networks                 May 1998


2.5.1.1  Limited Resources and Auto-Activation

   To reduce tariff charges, the APPN architecture supports the
   definition of switched links as limited resources.  A limited-
   resource link is deactivated when there are no sessions traversing
   the link.  Intermediate HPR nodes are not aware of sessions between
   logical units (referred to as LU-LU sessions) carried in crossing RTP
   connections; in HPR nodes, limited-resource TGs are deactivated when
   no traffic is detected for some period of time.  Furthermore, APPN
   links may be defined as auto-activatable.  Auto-activatable links are
   activated when a new session has been routed across the link.

   An HPR node may have access to an IP network via a switched access
   link.  In such environments, it may be advisable for customers to
   define regular HPR/IP links as limited resources and as being auto-
   activatable.

2.5.2  IP Connection Networks

   Connection network support for IP networks (option set 2010), is
   described in this section.

   APPN architecture defines single link TGs across the point-to-point
   lines connecting APPN nodes.  The natural extension of this model
   would be to define a TG between each pair of nodes connected to a
   shared access transport facility (SATF) such as a LAN or IP network.
   However, the high cost of the system definition of such a mesh of TGs
   is prohibitive for a network of more than a few nodes.  For that
   reason, the APPN connection network model was devised to reduce the
   system definition required to establish TGs between APPN nodes.

   Other TGs may be defined through the SATF which are not part of the
   connection network.  Such TGs (referred to as regular TGs in this
   document) are required for sessions between control points (referred
   to as CP-CP sessions) but may also be used for LU-LU sessions.

   In the connection network model, a virtual routing node (VRN) is
   defined to represent the SATF.  Each node attached to the SATF
   defines a single TG to the VRN rather than TGs to all other attached
   nodes.

   Topology and routing services (TRS) specifies that a session is to be
   routed between two nodes across a connection network by including the
   connection network TGs between each of those nodes and the VRN in the
   Route Selection control vector (RSCV).  When a network node has a TG
   to a VRN, the network topology information associated with that TG
   includes DLC signaling information required to establish connectivity
   to that node across the SATF.  For an end node, the DLC signaling



Dudley                       Informational                     [Page 19]

RFC 2353                APPN/HPR in IP Networks                 May 1998


   information is returned as part of the normal directory services (DS)
   process.  TRS includes the DLC signaling information for TGs across
   connection networks in RSCVs.

   CS creates a dynamic link station when the next hop in the RSCV of an
   ACTIVATE_ROUTE signal received from session services (SS) is a
   connection network TG or when an adjacent node initiates link
   activation upon receiving such an ACTIVATE_ROUTE signal.  Dynamic
   link stations are normally treated as limited resources, which means
   they are deactivated when no sessions are using them.  CP-CP sessions
   are not supported on connections using dynamic link stations because
   CP-CP sessions normally need to be kept up continuously.

   Establishment of a link across a connection network normally requires
   the use of CP-CP sessions to determine the destination IP address.
   Because CP-CP sessions must flow across regular TGs, the definition
   of a connection network does not eliminate the need to define regular
   TGs as well.

   Normally, one connection network is defined on a LAN (i.e., one VRN
   is defined.)  For an environment with several interconnected campus
   IP networks, a single wide-area connection network can be defined; in
   addition, separate connection networks can be defined between the
   nodes connected to each campus IP network.

2.5.2.1  Establishing IP Connection Networks

   Once the port is defined, a connection network can be defined on the
   port.  In order to support multiple TGs from a port to a VRN, the
   connection network is defined by the following process:

   1.  A connection network and its associated VRN are defined on the
       port.  This is accomplished by the node operator issuing a
       DEFINE_CONNECTION_NETWORK(RQ) command to NOF and NOF passing a
       DEFINE_CN(RQ) signal to CS.

   2.  Each TG from the port to the VRN is defined by the node operator
       issuing DEFINE_CONNECTION_NETWORK_TG(RQ) to NOF and NOF passing
       DEFINE_CN_TG(RQ) to CS.

   Prior to implementation of Resource ReSerVation Protocol (RSVP)
   support, only one connection network TG between a port and a VRN is
   required.  In that case, product support for the DEFINE_CN_TG(RQ)
   signal is not required because a single set of port configuration
   parameters for each connection network is sufficient.  If a NOF
   implementation does not support DEFINE_CN_TG(RQ), the parameters
   listed in the following section for DEFINE_CN_TG(RQ), are provided by
   DEFINE_CN(RQ) instead.  Furthermore, the Connection Network TG



Dudley                       Informational                     [Page 20]

RFC 2353                APPN/HPR in IP Networks                 May 1998


   Numbers (X'81') subfield in the TG Descriptor (X'46') control vector
   on an activation XID is only required to support multiple connection
   network TGs to a VRN, and its use is optional.

     *-----------------------------------------------------*
     |   NO                        NOF                CS   |
     *-----------------------------------------------------*
        DEFINE_CONNECTION_NETWORK(RQ)   DEFINE_CN(RQ)  .
          o------------------------>o----------------->o
       DEFINE_CONNECTION_NETWORK(RSP)   DEFINE_CN(RSP) |
          o<------------------------o<-----------------*
     DEFINE_CONNECTION_NETWORK_TG(RQ) DEFINE_CN_TG(RQ) .
          o------------------------>o----------------->o
    DEFINE_CONNECTION_NETWORK_TG(RSP) DEFINE_CN_TG(RSP)|
          o<------------------------o<-----------------*

          Figure 7. IP Connection Network Definition

   An incoming dynamic link activation may be rejected with sense data
   X'10160046' if there is an existing dynamic link between the two
   ports over the same connection network (i.e., with the same VRN CP
   name).  If a node receives an activation XID for a dynamic link with
   an IP address pair, a SAP pair, and a VRN CP name that are the same
   as for an active dynamic link, that node can assume that the link has
   failed and that the partner node is reactivating the link.  In such a
   case as an optimization, the node receiving the XID can take down the
   active link and allow the link to be reestablished in the IP network.
   Because UDP packets can arrive out of order, implementation of this
   optimization requires the use of a timer to prevent a stray XID from
   deactivating an active link.

   Once all the connection networks are defined, the node operator
   issues START_PORT(RQ), NOF passes the associated signal to CS, and CS
   passes ACTIVATE_PORT(RQ) to the DLC manager.  Upon receiving the
   ACTIVATE_PORT(RSP) signal from the DLC manager, CS sends a TG_UPDATE
   signal to TRS for each defined connection network TG.  Each signal
   notifies TRS that a TG to the VRN has been activated and includes TG
   vectors describing the TG.  If the port fails or is deactivated, CS
   sends TG_UPDATE indicating the connection network TGs are no longer
   operational.  Information about TGs between a network node and the
   VRN is maintained in the network topology database.  Information
   about TGs between an end node and the VRN is maintained only in the
   local topology database.  If TRS has no node entry in its topology
   database for the VRN, TRS dynamically creates such an entry.  A VRN
   node entry will become part of the network topology database only if






Dudley                       Informational                     [Page 21]

RFC 2353                APPN/HPR in IP Networks                 May 1998


   a network node has defined a TG to the VRN; however, TRS is capable
   of selecting a direct path between two end nodes across a connection
   network without a VRN node entry.

*--------------------------------------------------------------------*
|   CS                   TRS                 DLC               DMUX  |
*--------------------------------------------------------------------*
     .            ACTIVATE_PORT(RQ)           .     create
     o--------------------------------------->o----------------->o
     .            ACTIVATE_PORT(RSP)          |                  .
     o<---------------------------------------*                  .
     |  TG_UPDATE         .                   .                  .
     *------------------->o                   .                  .
     .                    .                   .                  .

           Figure 8. IP Connection Network Establishment

The TG vectors for IP connection network TGs include the following
information:

   o   TG number

   o   VRN CP name

   o   TG characteristics used during route selection

       -   Effective capacity
       -   Cost per connect time
       -   Cost per byte transmitted
       -   Security
       -   Propagation delay
       -   User defined parameters

   o   Signaling information

       -   IP version (indicates the format of the IP header including
           the IP address)

       -   IP address

       -   Link service access point address (LSAP) used for XID, TEST,
           DISC, and DM

2.5.2.2  IP Connection Network Parameters

   For a connection network TG, the parameters are determined by CS
   using several inputs.  Parameters that are particular to the local
   port, connection network, or TG are system defined and received in



Dudley                       Informational                     [Page 22]

RFC 2353                APPN/HPR in IP Networks                 May 1998


   DEFINE_PORT(RQ), DEFINE_CN(RQ), or DEFINE_CN_TG(RQ).  Signaling
   information for the destination node including its IP address is
   received in the ACTIVATE_ROUTE request from SS.

   The following configuration parameters are received in DEFINE_CN(RQ):

   o   Connection network name (CP name of the VRN)

   o   Limited resource liveness timer (default is 45 sec.)

   o   IP precedence (the setting of the 3-bit field within the Type of
       Service byte of the IP header for LLC commands such as XID and
       for each of the APPN transmission priorities; the defaults are
       given in 2.6.1, "IP Prioritization" on page 28; this parameter is
       used to override the settings in DEFINE_PORT)

   The following configuration parameters are received in
   DEFINE_CN_TG(RQ):

   o   Port name

   o   Connection network name (CP name of the VRN)

   o   Connection network TG number (set to a value between 1 and 239)

   o   TG characteristics (see 2.6.3, "Default TG Characteristics" on
       page 30)

   o   Link service access point address (LSAP) used for XID, TEST,
       DISC, and DM (default is X'04')

   o   Link service access point address (LSAP) used for HPR network
       layer packets (default is X'C8')

   o   Limited resource (default is yes)

   o   Retry count for LDLC (default is 3; this parameter is used to
       override the setting in DEFINE_PORT)

   o   Retry timer period for LDLC (default is 15 sec.; a smaller value
       such as 10 seconds can be used for a campus connection network;
       this parameter is used to override the setting in DEFINE_PORT)

   o   LDLC liveness timer period (default is 10 seconds; this parameter
       is used to override the setting in DEFINE_PORT; see 2.3.1, "LDLC
       Liveness" on page 7)





Dudley                       Informational                     [Page 23]

RFC 2353                APPN/HPR in IP Networks                 May 1998


   o   Shareable with other HPR traffic (default is yes for non-RSVP
       links)

   o   Maximum receive BTU size (default is 1461; this parameter is used
       to override the value in DEFINE_PORT(RQ).)

   o   Maximum send BTU size (default is 1461; this parameter is used to
       override the value in DEFINE_PORT(RQ).)

   The following parameters are received in ACTIVATE_ROUTE for
   connection network TGs:

   o   The TG pair

   o   The destination IP version (if this version is not supported by
       the local node, the ACTIVATE_ROUTE_RSP reports the activation
       failure with sense data X'086B46A5'.)

   o   The destination IP address (in the format specified by the
       destination IP version)

   o   Destination service access point address (DSAP) used for XID,
       TEST, DISC, and DM

2.5.2.3  Sharing of TGs

   Connection network traffic is multiplexed onto a regular defined IP
   TG (usually used for CP-CP session traffic) in order to reduce the
   control block storage.  No XIDs flow to establish a new TG on the IP
   network, and no new LLC is created.  When a regular TG is shared,
   incoming traffic is demultiplexed using the normal means.  If the
   regular TG is deactivated, a path switch is required for the HPR
   connection network traffic sharing the TG.

   Multiplexing is possible if the following conditions hold:

   1.  Both the regular TG and the connection network TG to the VRN are
       defined as shareable between HPR traffic streams.

   2.  The destination IP address is the same.

   3.  The regular TG is established first.  (Because links established
       for connection network traffic do not support CP-CP sessions,
       there is little value in allowing a regular TG to share such a
       link.)

   The destination node is notified via XID when a TG can be shared
   between HPR data streams.  At either end, upon receiving



Dudley                       Informational                     [Page 24]

RFC 2353                APPN/HPR in IP Networks                 May 1998


   ACTIVATE_ROUTE requesting a shared TG for connection network traffic,
   CS checks its TGs for one meeting the required specifications before
   initiating a new link.  First, CS looks for a link established for
   the TG pair; if there is no such link, CS determines if there is a
   regular TG that can be shared and, if multiple such TGs exist, which
   TG to choose.  As a result, RTP connections routed over the same TG
   pair may actually use different links, and RTP connections routed
   over different TG pairs may use the same link.

2.5.2.4  Minimizing RSCV Length

   The maximum length of a Route Selection (X'2B') control vector (RSCV)
   is 255 bytes.  Use of connection networks significantly increases the
   size of the RSCV contents required to describe a "hop" across an
   SATF.  First, because two connection network TGs are used to specify
   an SATF hop, two TG Descriptor (X'46') control vectors are required.
   Furthermore, inclusion of DLC signaling information within the TG
   Descriptor control vectors increases the length of these control
   vectors.  As a result, the total number of hops that can be specified
   in RSCVs traversing connection networks is reduced.

   To avoid unnecessarily limiting the number of hops, a primary goal in
   designing the formats for IP signaling information is to minimize
   their size.  Additional techniques are also used to reduce the effect
   of the RSCV length limitation.

   For an IP connection network, DLC signaling information is required
   only for the second TG (i.e., from the VRN to the destination node);
   the signaling information for the first TG is locally defined at the
   origin node.  For this reason, the topology database does not include
   DLC signaling information for the entry describing a connection
   network TG from a network node to a VRN.  The DLC signaling
   information is included in the allied entry for the TG in the
   opposite direction.  This mechanism cannot be used for a connection
   network TG between a VRN and an end node.  However, a node
   implementing IP connection networks does not include IP signaling
   information for the first connection network TG when constructing an
   RSCV.

   In an environment where APPN network nodes are used to route between
   legacy LANs and wide-area IP networks, it is recommended that
   customers not define connection network TGs between these network
   nodes and VRNs representing legacy LANs.  Typically, defined links
   are required between end nodes on the legacy LANs and such network
   nodes which also act as network node servers for the end nodes.
   These defined links can be used for user traffic as well as control
   traffic.  This technique will reduce the number of connection network
   hops in RSCVs between end nodes on different legacy LANs.



Dudley                       Informational                     [Page 25]

RFC 2353                APPN/HPR in IP Networks                 May 1998


   Lastly, for environments where RSCVs are still not able to include
   enough hops, extended border nodes (EBNs) can be used to partition
   the network.  In this case, the EBNs will also provide piecewise
   subnet route calculation and RSCV swapping.  Thus, the entire route
   does not need to be described in a single RSCV with its length
   limitation.

2.5.3  XID Changes

   Packets transmitted over IP networks are lost or arrive out of order
   more often than packets transmitted over other "link" technologies.
   As a result, the following problem with the XID3 negotiation protocol
   was exposed:

   --------------------------------------------------------------------

         *---------------------------------*
         |Node A                     Node B|
         *---------------------------------*
                          o
                          o
                          o
                           XID3 (np, NEG)
             o<-------------------------o
             |XID3 (np, SEC)
             *------------------------->o
                          XID3 (np, PRI)|
                        lost<-----------*

           time out
              XID3 (np, SEC)
             o------------------------->o
                               SETMODE  |
             o<-------------------------*
    fail because never
    received XID3 (np, PRI)

   Notation: np  - negotiation proceeding
             NEG - negotiable link station role
             SEC - secondary link station role
             PRI - primary link station role

   --------------------------------------------------------------------
                      Figure 9. XID3 Protocol Problem

   In the above sequence, the XID3(np, PRI), which is a link-level
   response to the received XID3(np, SEC), is lost.  Node A times out
   and resends the XID3(np, SEC) as a link-level command.  When Node B



Dudley                       Informational                     [Page 26]

RFC 2353                APPN/HPR in IP Networks                 May 1998


   receives this command, it thinks that the XID3(np, PRI) was
   successfully received by Node A and that the activation XID exchange
   is complete.  As a result, Node B sends SETMODE (SNRM, SABME, or
   XID_DONE_RQ, depending upon the link type).  When Node A receives
   SETMODE, it fails the link activation because it has not received an
   XID3(np, PRI) from Node B confirming that Node B does indeed agree to
   be the primary.  Moreover, there are similar problems with incomplete
   TG number negotiation.

   To solve the problems with incomplete role and TG number negotiation,
   two new indicators are defined in XID3.  The problems are solved only
   if both link stations support these new indicators:

   o   Negotiation Complete Supported indicator (byte 12 bit 0) -- this
       1-bit field indicates whether the Negotiation Complete indicator
       is supported.  This field is meaningful when the XID exchange
       state is negotiation proceeding; otherwise, it is reserved.  A
       value of 0 means the Negotiation Complete indicator is not
       supported; a value of 1 means the indicator is supported.

   o   Negotiation Complete indicator (byte 12 bit 1) -- this 1-bit
       field is meaningful only when the XID exchange state is
       negotiation proceeding, the XID3 is sent by the secondary link
       station, and the Negotiation Complete Supported indicator is set
       to 1; otherwise, this field is reserved.  This field is set to 1
       by a secondary link station that supports enhanced XID
       negotiation when it considers the activation XID negotiation to
       be complete for both link station role and TG number (i.e., it is
       ready to receive a SETMODE command from the primary link
       station.)

   When a primary link station that supports enhanced XID negotiation
   receives an XID3(np) with both the Negotiation Complete Supported
   indicator and the Negotiation Complete indicator set to 1, the
   primary link station will know that it can safely send SETMODE if it
   also considers the XID negotiation to be complete.  The new
   indicators are used as shown in the following sequence when both the
   primary and secondary link stations support enhanced XID negotiation.













Dudley                       Informational                     [Page 27]

RFC 2353                APPN/HPR in IP Networks                 May 1998


   --------------------------------------------------------------------

         *----------------------------------*
         |Node A                     Node B |
         *----------------------------------*
                          o
                          o
                          o
                    XID3 (np, NEG, S, ^C)
   1         o<--------------------------o
             |XID3 (np, SEC, S, ^C)
   2         *-------------------------->o
                    XID3 (np, PRI, S, ^C)|
   3                    lost <-----------*

           time out
              XID3 (np, SEC, S, ^C)
   4         o-------------------------->o
                    XID3 (np, PRI, S, ^C)|
   5         o<--------------------------*
             |XID3 (np, SEC, S, C)
   6         *-------------------------->o
                                SETMODE  |
   7         o<--------------------------*

   ^S indicates that byte 12 bit 0 is set to 0.
    S indicates that byte 12 bit 0 is set to 1.
   ^C indicates that byte 12 bit 1 is set to 0.
    C indicates that byte 12 bit 1 is set to 1.

   --------------------------------------------------------------------
   Figure 10. Enhanced XID Negotiation

   When Node B receives the XID in flow 4, it realizes that the Node A
   does not consider XID negotiation to be complete; as a result, it
   resends its current XID information in flow 5.  When Node A receives
   this XID, it responds in flow 6 with an XID that indicates XID
   negotiation is complete.  At this point, Node B, acting as the
   primary link station, sends SETMODE, and the link is activated
   successfully.

   Migration cases with only one link station supporting enhanced XID
   negotiation are shown in the two following sequences.  In the next
   sequence, only Node A (acting as the secondary link station) supports
   the new function.






Dudley                       Informational                     [Page 28]

RFC 2353                APPN/HPR in IP Networks                 May 1998


   --------------------------------------------------------------------

         *---------------------------------*
         |Node A                     Node B|
         *---------------------------------*
                          o
                          o
                          o
                       XID3 (np, NEG, ^S)
   1         o<--------------------------o
             |XID3 (np, SEC, S, ^C)
   2         *-------------------------->o
                       XID3 (np, PRI, ^S)|
   3                    lost <-----------*

           time out
              XID3 (np, SEC, S, ^C)
   4         o-------------------------->o
                                SETMODE  |
   5         o<--------------------------*
           fail


   --------------------------------------------------------------------
                      Figure 11. First Migration Case

   The XID negotiation fails because Node B does not understand the new
   indicators and responds to flow 4 with SETMODE.

   In the next sequence, Node B supports the new indicators but Node A
   does not.




















Dudley                       Informational                     [Page 29]

RFC 2353                APPN/HPR in IP Networks                 May 1998


   --------------------------------------------------------------------

         *---------------------------------*
         |Node A                     Node B|
         *---------------------------------*
                          o
                          o
                          o
                    XID3 (np, NEG, S, ^C)
   1         o<--------------------------o
             |XID3 (np, SEC, ^S)
   2         *-------------------------->o
                    XID3 (np, PRI, S, ^C)|
   3                    lost <-----------*

           time out
              XID3 (np, SEC, ^S)
   4         o-------------------------->o
                                 SETMODE |
   5         o<--------------------------*
           fail


   ------------------------------------------------------------------------
                     Figure 12. Second Migration Case

   The XID negotiation fails because Nobe A does not understand the new
   indicators and thus cannot indicate that it thinks XID negotiation is
   not complete in flow 4.  Node B understands that the secondary link
   station (node A) does not support the new indicators and respond with
   SETMODE in flow 5.

   Products that support HPR/IP links are required to support enhanced
   XID negotiation.  Moreover, it is recommended that products
   implementing this solution for HPR/IP links also support it for other
   link types.

2.5.4  Unsuccessful IP Link Activation

   Link activation may fail for several different reasons.  When link
   activation over a connection network or of an auto-activatable link
   is attempted upon receiving ACTIVATE_ROUTE from SS, activation
   failure is reported with ACTIVATE_ROUTE_RSP containing sense data
   explaining the cause of failure.  Likewise, when activation fails for
   other regular defined links, the failure is reported with
   START_LS(RSP) containing sense data.





Dudley                       Informational                     [Page 30]

RFC 2353                APPN/HPR in IP Networks                 May 1998


   As is normal for session activation failures, the sense data is also
   sent to the node that initiated the session.  At the APPN-to-HPR
   boundary, a -RSP(BIND) or an UNBIND with an Extended Sense Data
   control vector is generated and returned to the primary logical unit
   (PLU).

   At an intermediate HPR node, link activation failure can be reported
   with sense data X'08010000' or X'80020000'.  At a node with route-
   selection responsibility, such failure can be reported with sense
   data X'80140001'.

   The following table contains the sense data for the various causes of
   link activation failure:






































Dudley                       Informational                     [Page 31]

RFC 2353                APPN/HPR in IP Networks                 May 1998


+----------------------------------------------------------------------+
| Table 1 (Page 1 of 2). Native IP DLC Link Activation Failure Sense   |
|                        Data                                          |
+--------------------------------------------------------+-------------+
| ERROR DESCRIPTION                                      | SENSE DATA  |
+--------------------------------------------------------+-------------+
| The link specified in the RSCV is not available.       | X'08010000' |
+--------------------------------------------------------+-------------+
| The limit for null XID responses by a called node was  | X'0809003A' |
| reached.                                               |             |
+--------------------------------------------------------+-------------+
| A BIND was received over a subarea link, but the next  | X'08400002' |
| hop is over a port that supports only HPR links.  The  |             |
| receiver does not support this configuration.          |             |
+--------------------------------------------------------+-------------+
| The contents of the DLC Signaling Type (X'91')         | X'086B4691' |
| subfield of the TG Descriptor (X'46') control vector   |             |
| contained in the RSCV were invalid.                    |             |
+--------------------------------------------------------+-------------+
| The contents of the IP Address and Link Service Access | X'086B46A5' |
| Point Address (X'A5') subfield of the TG Descriptor    |             |
| (X'46') control vector contained in the RSCV were      |             |
| invalid.                                               |             |
+--------------------------------------------------------+-------------+
| No DLC Signaling Type (X'91') subfield was found in    | X'086D4691' |
| the TG Descriptor (X'46') control vector contained in  |             |
| the RSCV.                                              |             |
+--------------------------------------------------------+-------------+
| No IP Address and Link Service Access Point Address    | X'086D46A5' |
| (X'A5') subfield was found in the TG Descriptor        |             |
| (X'46') control vector contained in the RSCV.          |             |
+--------------------------------------------------------+-------------+
| Multiple sets of DLC signaling information were found  | X'08770019' |
| in the TG Descriptor (X'46') control vector contained  |             |
| in the RSCV.  IP supports only one set of DLC          |             |
| signaling information.                                 |             |
+--------------------------------------------------------+-------------+
| Link Definition Error:  A link is defined as not       | X'08770026' |
| supporting HPR, but the port only supports HPR links.  |             |
+--------------------------------------------------------+-------------+
| A called node found no TG Identifier (X'80') subfield  | X'088C4680' |
| within a TG Descriptor (X'46') control vector in a     |             |
| prenegotiation XID for a defined link in an IP         |             |
| network.                                               |             |
+--------------------------------------------------------+-------------+






Dudley                       Informational                     [Page 32]

RFC 2353                APPN/HPR in IP Networks                 May 1998


+----------------------------------------------------------------------+
| Table 1 (Page 2 of 2). Native IP DLC Link Activation Failure Sense   |
|                        Data                                          |
+--------------------------------------------------------+-------------+
| The XID3 received from the adjacent node does not      | X'10160031' |
| contain an HPR Capabilities (X'61') control vector.    |             |
| The IP port supports only HPR links.                   |             |
+--------------------------------------------------------+-------------+
| The RTP Supported indicator is set to 0 in the HPR     | X'10160032' |
| Capabilities (X'61') control vector of the XID3        |             |
| received from the adjacent node.  The IP port supports |             |
| only links to nodes that support RTP.                  |             |
+--------------------------------------------------------+-------------+
| The Control Flows over RTP Supported indicator is set  | X'10160033' |
| to 0 in the HPR Capabilities (X'61') control vector of |             |
| the XID3 received from the adjacent node.  The IP port |             |
| supports only links to nodes that support control      |             |
| flows over RTP.                                        |             |
+--------------------------------------------------------+-------------+
| The LDLC Supported indicator is set to 0 in the HPR    | X'10160034' |
| Capabilities (X'61') control vector of the XID3        |             |
| received from the adjacent node.  The IP port supports |             |
| only links to nodes that support LDLC.                 |             |
+--------------------------------------------------------+-------------+
| The HPR Capabilities (X'61') control vector received   | X'10160044' |
| in XID3 does not include an IEEE 802.2 LLC (X'80') HPR |             |
| Capabilities subfield.  The subfield is required on an |             |
| IP link.                                               |             |
+--------------------------------------------------------+-------------+
| Multiple defined links between a pair of switched      | X'10160045' |
| ports is not supported by the local node.  A link      |             |
| activation request was received for a defined link,    |             |
| but there is an active defined link between the paired |             |
| switched ports.                                        |             |
+--------------------------------------------------------+-------------+
| Multiple dynamic links across a connection network     | X'10160046' |
| between a pair of switched ports is not supported by   |             |
| the local node.  A link activation request was         |             |
| received for a dynamic link, but there is an active    |             |
| dynamic link between the paired switched ports across  |             |
| the same connection network.                           |             |
+--------------------------------------------------------+-------------+
| Link failure                                           | X'80020000' |
+--------------------------------------------------------+-------------+
| Route selection services has determined that no path   | X'80140001' |
| to the destination node exists for the specified COS.  |             |
+--------------------------------------------------------+-------------+




Dudley                       Informational                     [Page 33]

RFC 2353                APPN/HPR in IP Networks                 May 1998


2.6  IP Throughput Characteristics

2.6.1  IP Prioritization

   Typically, IP routers process packets on a first-come-first-served
   basis; i.e., no packets are given transmission priority.  However,
   some IP routers prioritize packets based on IP precedence (the 3-bit
   field within the Type of Service byte of the IP header) or UDP port
   numbers.  (With the current plans for IP security, the UDP port
   numbers are encrypted; as a result, IP routers would not be able to
   prioritize encrypted traffic based on the UDP port numbers.)  HPR
   will be able to exploit routers that provide priority function.

   The 5 UDP port numbers, 12000-12004 (decimal), have been assigned by
   the Internet Assigned Number Authority (IANA).  Four of these port
   numbers are used for ANR-routed network layer packets (NLPs) and
   correspond to the APPN transmission priorities (network, 12001; high,
   12002; medium, 12003; and low, 12004), and one port number (12000) is
   used for a set of LLC commands (i.e., XID, TEST, DISC, and DM) and
   function-routed NLPs (i.e., XID_DONE_RQ and XID_DONE_RSP).  These
   port numbers are used for "listening" and are also used in the
   destination port number field of the UDP header of transmitted
   packets.  The source port number field of the UDP header can be set
   either to one of these port numbers or to an ephemeral port number.

   The IP precedence for each transmission priority and for the set of
   LLC commands (including function-routed NLPs) are configurable.  The
   implicit assumption is that the precedence value is associated with
   priority queueing and not with bandwidth allocation; however,
   bandwidth allocation policies can be administered by matching on the
   precedence field.  The default mapping to IP precedence is shown in
   the following table:



















Dudley                       Informational                     [Page 34]

RFC 2353                APPN/HPR in IP Networks                 May 1998


   +---------------------------------------------+
   | Table 2. Default IP Precedence Settings     |
   +----------------------+----------------------+
   | PRIORITY             |      PRECEDENCE      |
   +----------------------+----------------------+
   | LLC commands and     |          110         |
   | function-routed NLPs |                      |
   +----------------------+----------------------+
   | Network              |          110         |
   +----------------------+----------------------+
   | High                 |          100         |
   +----------------------+----------------------+
   | Medium               |          010         |
   +----------------------+----------------------+
   | Low                  |          001         |
   +----------------------+----------------------+

   As an example, with this default mapping, telnet, interactive ftp,
   and business-use web traffic could be mapped to a precedence value of
   011, and batch ftp could be mapped to a value of 000.

   These settings were devised based on the AIW's understanding of the
   intended use of IP precedence.  The use of IP precedence will be
   modified appropriately if the IETF standardizes its use differently.
   The other fields in the IP TOS byte are not used and should be set to
   0.

   For outgoing ANR-routed NLPs, the destination (and optionally the
   source) UDP port numbers and IP precedence are set based on the
   transmission priority specified in the HPR network header.

   It is expected that the native IP DLC architecture described in this
   document will be used primarily for private campus or wide-area
   intranets where the customer will be able to configure the routers to
   honor the transmission priority associated with the UDP port numbers
   or IP precedence.  The architecture can be used to route HPR traffic
   in the Internet; however, in that environment, routers do not
   currently provide the priority function, and customers may find the
   performance unacceptable.

   In the future, a form of bandwidth reservation may be possible in IP
   networks using the Resource ReSerVation Protocol (RSVP), or the
   differentiated services currently being studied by the Integrated
   Services working group of the IETF.  Bandwidth could be reserved for
   an HPR/IP link thus insulating the HPR traffic from congestion
   associated with the traffic of other protocols.





Dudley                       Informational                     [Page 35]

RFC 2353                APPN/HPR in IP Networks                 May 1998


2.6.2  APPN Transmission Priority and COS

   APPN transmission priority and class of service (COS) allow APPN TGs
   to be highly utilized with batch traffic without impacting the
   performance of response-time sensitive interactive traffic.
   Furthermore, scheduling algorithms guarantee that lower-priority
   traffic is not completely blocked.  The result is predictable
   performance.

   When a session is initiated across an APPN network, the session's
   mode is mapped into a COS and transmission priority.  For each COS,
   APPN has a COS table that is used in the route selection process to
   select the most appropriate TGs (based on their TG characteristics)
   for the session to traverse.  The TG characteristics and COS tables
   are defined such that APPN topology and routing services (TRS) will
   select the appropriate TG for the traffic of each COS.

2.6.3  Default TG Characteristics

   In Chapter 7 (TRS) of [1], there is a set of SNA-defined TG default
   profiles.  When a TG (connection network or regular) is defined as
   being of a particular technology (e.g., ethernet or X.25) without
   specification of the TG's characteristics, parameters from the
   technology's default profile are used in the TG's topology entry.
   The customer is free to override these values via configuration.
   Some technologies have multiple profiles (e.g., ISDN has both a
   profile for switched and nonswitched.)  Two default profiles are
   required for IP TGs.  This many are needed because there are both
   campus and wide-area IP networks.  As a result for each HPR/IP TG, a
   customer should specify, at minimum, campus or wide area.  HPR/IP TGs
   traversing the Internet should be specified as wide-area links.  If
   no specification is made, a campus network is assumed.

   The 2 IP profiles are as follows:

+----------------------------------------------------------------------+
| Table 3. IP Default TG Characteristics                               |
+-------------------+---------+----------+---------+---------+---------+
|                   | Cost    | Cost per | Security| Propa-  | Effec-  |
|                   | per     | byte     |         | gation  | tive    |
|                   | connect |          |         | delay   | capacity|
|                   | time    |          |         |         |         |
+-------------------+---------+----------+---------+---------+---------+
| Campus            | 0       | 0        | X'01'   | X'71'   | X'75'   |
+-------------------+---------+----------+---------+---------+---------+
| Wide area         | 0       | 0        | X'20'   | X'91'   | X'43'   |
+-------------------+---------+----------+---------+---------+---------+




Dudley                       Informational                     [Page 36]

RFC 2353                APPN/HPR in IP Networks                 May 1998


   Typically, a TG is either considered to be "free" if it is owned or
   leased or "costly" if it is a switched carrier facility.  Free TGs
   have 0 for both cost parameters, and costly TGs have 128 for both
   parameters.  For campus IP networks, the default for both cost
   parameters is 0.

   It is less clear what the defaults should be for wide area.  Because
   a router normally has leased access to an IP network, the defaults
   for both costs are also 0.  This assumes the IP network is not
   tariffed.  However, if the IP network is tariffed, then the customer
   should set the cost per byte to 0 or 128 depending on whether the
   tariff contains a component based on quantity of data transmitted,
   and the customer should set the cost per connect time to 0 or 128
   based on whether there is a tariff component based on connect time.
   Furthermore, for switched access to the IP network, the customer
   settings for both costs should also reflect the tariff associated
   with the switched access link.

   Only architected values (see "Security" in [1]) may be used for a
   TG's security parameter.  The default security value is X'01'
   (lowest) for campus and X'20' (public switched network; secure in the
   sense that there is no predetermined route the traffic will take) for
   wide-area IP networks.  The network administrator may override the
   default value but should, in that case, ensure that an appropriate
   level of security exists.

   For wide area, the value X'91' (packet switched) is the default for
   propagation delay; this is consistent with other wide-area facilities
   and indicates that IP packets will experience both terrestrial
   propagation delay and queueing delay in intermediate routers.  This
   value is suitable for both the Internet and wide-area intranets;
   however, the customer could use different values to favor intranets
   over the Internet during route selection.  The value X'99' (long) may
   be appropriate for some international links across the Internet.  For
   campus, the default is X'71' (terrestrial); this setting essentially
   equates the queueing delay in IP networks with terrestrial
   propagation delay.

   For wide area, X'43' (56 kbs) is shown as the default effective
   capacity; this is at the low-end of typical speeds for wide-area IP
   links.  For campus, X'75' (4 Mbs) is the default; this is at the
   low-end of typical speeds for campus IP links.  However, customers
   should set the effective capacity for both campus and wide area IP
   links based on the actual physical speed of the access link to the IP
   network; for regular links, if both the source and destination access
   speeds are known, customers should set the effective capacity based
   on the minimum of these two link speeds.  If there are multiple
   access links, the capacity setting should be based on the physical



Dudley                       Informational                     [Page 37]

RFC 2353                APPN/HPR in IP Networks                 May 1998


   speed of the access link that is expected to be used for the link.

   For the encoding technique for effective capacity in the topology
   database, see "Effective Capacity" in Chapter 7, Topology and Routing
   Services of [1].  The table in that section can be extended as
   follows for higher speeds:

+----------------------------------------------------------------------+
| Table 4. Calculated Effective Capacity Representations               |
+-----------------------------------+----------------------------------+
| Link Speed (Approx.)              | Effective Capacity               |
+-----------------------------------+----------------------------------+
| 25M                               | X'8A'                            |
+-----------------------------------+----------------------------------+
| 45M                               | X'91'                            |
+-----------------------------------+----------------------------------+
| 100M                              | X'9A'                            |
+-----------------------------------+----------------------------------+
| 155M                              | X'A0'                            |
+-----------------------------------+----------------------------------+
| 467M                              | X'AC'                            |
+-----------------------------------+----------------------------------+
| 622M                              | X'B0'                            |
+-----------------------------------+----------------------------------+
| 1G                                | X'B5'                            |
+-----------------------------------+----------------------------------+
| 1.9G                              | X'BC'                            |
+-----------------------------------+----------------------------------+

2.6.4  SNA-Defined COS Tables

   SNA-defined batch and interactive COS tables are provided in [1].
   These tables are enhanced in [2] (see section 18.7.2) for the
   following reasons:

   o   To ensure that the tables assign reasonable weights to ATM TGs
       relative to each other and other technologies based on cost,
       speed, and delay

   o   To facilitate use of other new higher-speed facilities - This
       goal is met by providing several speed groupings above 10 Mbps.
       To keep the tables from growing beyond 12 rows, low-speed
       groupings are merged.

   Products implementing the native IP DLC should use the new COS
   tables.  Although the effective capacity values in the old tables are
   sufficient for typical IP speeds, the new tables are valuable because
   higher-speed links can be used for IP networks.



Dudley                       Informational                     [Page 38]

RFC 2353                APPN/HPR in IP Networks                 May 1998


2.6.5  Route Setup over HPR/IP links

   The Resequence ("REFIFO") indicator is set in Route Setup request and
   reply when the RTP path uses a multi-link TG because packets may not
   be received in the order sent.  The Resequence indicator is also set
   when the RTP path includes an HPR/IP link as packets sent over an IP
   network may arrive out of order.

   Adaptive rate-based congestion control (ARB) is an HPR Rapid
   Transport Protocol (RTP) function that controls the data transmission
   rate over RTP connections.  ARB also provides fairness between the
   RTP traffic streams sharing a link.  For ARB to perform these
   functions in the IP environment, it is necessary to coordinate the
   ARB parameters with the IP TG characteristics.  This is done for IP
   links in a similar manner to that done for other link types.

2.6.6  Access Link Queueing

   Typically, nodes implementing the native IP DLC have an access link
   to a network of IP routers.  These IP routers may be providing
   prioritization based on UDP port numbers or IP precedence.  A node
   implementing the native IP DLC can be either an IP host or an IP
   router; in both cases, such nodes should also honor the priorities
   associated with either the UDP port numbers or the IP precedence when
   transmitting HPR data over the access link to the IP network.

--------------------------------------------------------------------

*--------* access link *--------*     *--------*
|  HPR   |-------------|   IP   |-----|   IP   |
|  node  |             | Router |     | Router |
*--------*             *--------*     *--------*
                            |              |
                            |              |
                            |              |
                       *--------*     *--------* access link *--------*
                       |   IP   |-----|   IP   |-------------|  HPR   |
                       | Router |     | Router |             |  node  |
                       *--------*     *--------*             *--------*


--------------------------------------------------------------------
                        Figure 13. Access Links

   Otherwise, the priority function in the router network will be
   negated with the result being HPR interactive traffic delayed by
   either HPR batch traffic or the traffic of other higher-layer
   protocols at the access link queues.



Dudley                       Informational                     [Page 39]

RFC 2353                APPN/HPR in IP Networks                 May 1998


2.7  Port Link Activation Limits

   Three parameters are provided by NOF to CS on DEFINE_PORT(RQ) to
   define the link activation limits for a port: total limit, inbound
   limit, and outbound limit.  The total limit is the desired maximum
   number of active link stations allowed on the port for both regular
   TGs and connection network TGs.  The inbound limit is the desired
   number of link stations reserved for connections initiated by
   adjacent nodes; the purpose of this field is to insure that a minimum
   number of link stations may be activated by adjacent nodes.  The
   outbound limit is the desired number of link stations reserved for
   connections initiated by the local node.  The sum of the inbound and
   outbound limits must be less than or equal to the total limit.  If
   the sum is less than the total limit, the difference is the number of
   link stations that can be activated on a demand basis as either
   inbound or outbound.  These limits should be based on the actual
   adapter capability and the node's resources (e.g., control blocks).

   A connection network TG will be reported to topology as quiescing
   when its port's total limit threshold is reached; likewise, an
   inactive auto-activatable regular TG is reported as nonoperational.
   When the number of active link stations drops far enough below the
   threshold (e.g., so that at least 20 percent of the original link
   activation limit has been recovered), connection network TGs are
   reported as not quiescing, and auto-activatable TGs are reported as
   operational.

2.8  Network Management

   APPN and HPR management information is defined by the APPN MIB (RFC
   2155 [11]) and the HPR MIB (RFC 2238 [13]).  In addition, the SNANAU
   working group of the IETF plans to define an HPR-IP-MIB that will
   provide HPR/IP-specific management information.  In particular, this
   MIB will provide a mapping of APPN traffic types to IP Type of
   Service Precedence values, as well as a count of UDP packets sent for
   each traffic type.

   There are also rules that must be specified concerning the values an
   HPR/IP implementation returns for objects in the APPN MIB:

   o   Several objects in the APPN MIB have the syntax IANAifType.  The
       value 126, defined as "IP (for APPN HPR in IP networks)" should
       be returned by the following three objects when they identify an
       HPR/IP link:

       -   appnPortDlcType
       -   appnLsDlcType
       -   appnLsStatusDlcType



Dudley                       Informational                     [Page 40]

RFC 2353                APPN/HPR in IP Networks                 May 1998


   o   Link-level addresses are reported in the following objects:

       -   appnPortDlcLocalAddr
       -   appnLsLocalAddr
       -   appnLsRemoteAddr
       -   appnLsStatusLocalAddr
       -   appnLsStatusRemoteAddr

       All of these objects should return ASCII character strings that
       represent IP addresses in the usual dotted-decimal format.  (At
       this point it's not clear what the "usual...format" will be for
       IPv6 addresses, but whatever it turns out to be, that is what
       these objects will return when an HPR/IP link traverses an IP
       network.)

   o   The following two objects return Object Identifiers that tie
       table entries in the APPN MIB to entries in lower-layer MIBs:

       -   appnPortSpecific
       -   appnLsSpecific

       Both of these objects should return the same value:  a RowPointer
       to the ifEntry in the agent's ifTable for the physical interface
       associated with the local IP address for the port.  If the agent
       implements the IP-MIB (RFC 2011 [12]), this association between
       the IP address and the physical interface will be represented in
       the ipNetToMediaTable.

2.9  IPv4-to-IPv6 Migration

   The native IP DLC is architected to use IP version 4 (IPv4).
   However, support for IP version 6 (IPv6) may be required in the
   future.

   IP routers and hosts can interoperate only if both ends use the same
   version of the IP protocol.  However, most IPv6 implementations
   (routers and hosts) will actually have dual IPv4/IPv6 stacks.  IPv4
   and IPv6 traffic can share transmission facilities provided that the
   router/host at each end has a dual stack.  IPv4 and IPv6 traffic will
   coexist on the same infrastructure in most areas.  The version number
   in the IP header is used to map incoming packets to either the IPv4
   or IPv6 stack.  A dual-stack host which wishes to talk to an IPv4
   host will use IPv4.

   Hosts which have an IPv4 address can use it as an IPv6 address using
   a special IPv6 address prefix (i.e., it is an embedded IPv4 address).
   This mapping was provided mainly for "legacy" application
   compatibility purposes as such applications don't have the socket



Dudley                       Informational                     [Page 41]

RFC 2353                APPN/HPR in IP Networks                 May 1998


   structures needed to store full IPv6 addresses.  Two IPv6 hosts may
   communicate using IPv6 with embedded-IPv4 addresses.

   Both IPv4 and IPv6 addresses can be stored by the domain name service
   (DNS). When an application queries DNS, it asks for IPv4 addresses,
   IPv6 addresses, or both. So, it's the application that decides which
   stack to use based on which addresses it asks for.

   Migration for HPR/IP ports will work as follows:

   An HPR/IP port is configured to support IPv4, IPv6, or both.  If IPv4
   is supported, a local IPv4 address is defined; if IPv6 is supported,
   a local IPv6 address (which can be an embedded IPv4 address) is
   defined.  If both IPv4 and IPv6 are supported, both a local IPv4
   address and a local IPv6 address are defined.

   Defined links will work as follows:  If the local node supports IPv4
   only, a destination IPv4 address may be defined, or an IP host name
   may be defined in which case DNS will be queried for an IPv4 address.
   If the local node supports IPv6 only, a destination IPv6 address may
   be defined, or an IP host name may be defined in which case DNS will
   be queried for an IPv6 address.  If both IPv4 and IPv6 are supported,
   a destination IPv4 address may be defined, a destination IPv6 address
   may be defined, or an IP host name may be defined in which case DNS
   will be queried for both IPv4 and IPv6 addresses; if provided by DNS,
   an IPv6 address can be used, and an IPv4 address can be used
   otherwise.

   Separate IPv4 and IPv6 connection networks can be defined.  If the
   local node supports IPv4, it can define a connection network TG to
   the IPv4 VRN.  If the local node supports IPv6, it can define a TG to
   the IPv6 VRN.  If both are supported, TGs can be defined to both
   VRNs.  Therefore, the signaling information received in RSCVs will be
   compatible with the local node's capabilities unless a configuration
   error has occurred.

3.0  References

   [1]  IBM, Systems Network Architecture Advanced Peer-to-Peer
   Networking Architecture Reference, SC30-3442-04. Viewable at URL:
   http://www.raleigh.ibm.com/cgi-bin/bookmgr/BOOKS/D50L0000/CCONTENTS

   [2]  IBM, Systems Network Architecture Advanced Peer-to-Peer
   Networking High Performance Routing Architecture Reference, Version
   3.0, SV40-1018-02.  Viewable at URL: http://www.raleigh.ibm.com/cgi-
   bin/bookmgr/BOOKS/D50H6001/CCONTENTS





Dudley                       Informational                     [Page 42]

RFC 2353                APPN/HPR in IP Networks                 May 1998


   [3]  IBM, Systems Network Architecture Formats, GA27-3136-16.
   Viewable at URL: http://www.raleigh.ibm.com/cgi-
   bin/bookmgr/BOOKS/D50A5003/CCONTENTS

   [4]  Wells, L. and A. Bartky, "Data Link Switching: Switch-to-Switch
   Protocol, AIW DLSw RIG:  DLSw Closed Pages, DLSw Standard Version
   1.0", RFC 1795, April 1995.

   [5]  Bryant, D. and P. Brittain, "APPN Implementers' Workshop Closed
   Pages Document DLSw v2.0 Enhancements", RFC 2166, June 1997.

   [6]  Postel, J., "User Datagram Protocol", STD 6, RFC 768, August
   1980.

   [7]  Postel, J., "Internet Protocol", STD 5, RFC 791, September 1981.

   [8]  Almquist, P., "Type of Service in the Internet Protocol Suite",
   RFC 1349, July 1992.

   [9]  Braden, R., "Requirements for Internet Hosts -- Communication
   Layers", STD 3, RFC 1122, October 1989.

   [10] Braden, R., Zhang, L., Berson, S., Herzog, S., and S. Jamin,
   "Resource ReSerVation Protocol (RSVP) -- Version 1 Functional
   Specification", RFC 2205, September 1997.

   [11] Clouston, B., and B. Moore, "Definitions of Managed Objects for
   APPN using SMIv2", RFC 2155, June 1997.

   [12] McCloghrie, K., "SNMPv2 Management Information Base for the
   Internet Protocol using SMIv2", RFC 2011, November 1996.

   [13] Clouston, B., and B. Moore, "Definitions of Managed Objects for
   HPR using SMIv2", RFC 2238, November 1997.

4.0  Security Considerations

   For HPR, the IP network appears to be a link.  For that reason, the
   SNA session-level security functions (user authentication, LU
   authentication, session encryption, etc.) are still available for
   use.  In addition, as HPR traffic flows as UDP datagrams through the
   IP network, IPsec can be used to provide network-layer security
   inside the IP network.

   There are firewall considerations when supporting HPR traffic using
   the native IP DLC.  First, the firewall filters can be set to allow
   the HPR traffic to pass.  Traffic can be restricted based on the
   source and destination IP addresses and the destination port number;



Dudley                       Informational                     [Page 43]

RFC 2353                APPN/HPR in IP Networks                 May 1998


   the source port number is not relevant.  That is, the firewall should
   accept traffic with the IP addresses of the HPR/IP nodes and with
   destination port numbers in the range 12000 to 12004.  Second, the
   possibility exists for an attack using forged UDP datagrams; such
   attacks could cause the RTP connection to fail or even introduce
   false data on a session.  In environments where such attacks are
   expected, the use of network-layer security is recommended.

5.0  Author's Address

   Gary Dudley
   C3BA/501
   IBM Corporation
   P.O. Box 12195
   Research Triangle Park, NC 27709, USA

   Phone: +1 919-254-4358
   Fax:   +1 919-254-6243
   EMail: dudleyg@us.ibm.com
































Dudley                       Informational                     [Page 44]

RFC 2353                APPN/HPR in IP Networks                 May 1998


6.0  Appendix - Packet Format

6.1  HPR Use of IP Formats

+----------------------------------------------------------------------+
| 6.1.1  IP Format for LLC Commands and Responses                      |
|                                                                      |
|                     The formats described here are used for the      |
|                     following LLC commands and responses:  XID       |
|                     command and response, TEST command and response, |
|                     DISC command, and DM response.                   |
+----------------------------------------------------------------------+


+----------------------------------------------------------------------+
| IP Format for LLC Commands and Responses                             |
+-------+-----+--------------------------------------------------------+
| Byte  | Bit | Content                                                |
+-------+-----+--------------------------------------------------------+
+-------+-----+--------------------------------------------------------+
| 0-p   |     | IP header (see note 1)                                 |
+-------+-----+--------------------------------------------------------+
+-------+-----+--------------------------------------------------------+
| p+1-  |     | UDP header (see note 2)                                |
| p+8   |     |                                                        |
+-------+-----+--------------------------------------------------------+
+-------+-----+--------------------------------------------------------+
| p+9-  |     | IEEE 802.2 LLC header (see note 3)                     |
                _____________________
| p+11  |     |                                                        |
+-------+-----+--------------------------------------------------------+
+-------+-----+--------------------------------------------------------+
| p+9   |     | DSAP:  same as for the base APPN (i.e., X'04' or an    |
|       |     | installation-defined value)                            |
+-------+-----+--------------------------------------------------------+
+-------+-----+--------------------------------------------------------+
| p+10  |     | SSAP:  same as for the base APPN (i.e., X'04' or an    |
|       |     | installation-defined value)                            |
+-------+-----+--------------------------------------------------------+
+-------+-----+--------------------------------------------------------+
| p+11  |     | Control: set as appropriate                            |
+-------+-----+--------------------------------------------------------+
+-------+-----+--------------------------------------------------------+
| p+12-n|     | Remainder of PDU:  XID3 or TEST information field, or  |
|       |     | null for DISC command and DM response                  |
+-------+-----+--------------------------------------------------------+





Dudley                       Informational                     [Page 45]

RFC 2353                APPN/HPR in IP Networks                 May 1998


+-------+-----+--------------------------------------------------------+
|       |     | Note 1:  Rules for encoding the IP header can be found |
|       |     | in RFC 791.                                            |
+-------+-----+--------------------------------------------------------+
+-------+-----+--------------------------------------------------------+
|       |     | Note 2:  Rules for encoding the UDP header can be      |
|       |     | found in RFC 768.                                      |
+-------+-----+--------------------------------------------------------+

+----------------------------------------------------------------------+
| IP Format for LLC Commands and Responses                             |
+-------+-----+--------------------------------------------------------+
| Byte  | Bit | Content                                                |
+-------+-----+--------------------------------------------------------+

+-------+-----+--------------------------------------------------------+
|       |     | Note 3:  Rules for encoding the IEEE 802.2 LLC header  |
|       |     | can be found in ISO/IEC 8802-2:1994 (ANSI/IEEE Std     |
|       |     | 802.2, 1994 Edition), Information technology -         |
|       |     | Telecommunications and information exchange between    |
|       |     | systems - Local and metropolitan area networks -       |
|       |     | Specific requirements - Part 2:  Logical Link Control. |
+-------+-----+--------------------------------------------------------+

+----------------------------------------------------------------------+
| 6.1.2  IP Format for NLPs in UI Frames                               |
|                                                                      |
|                     This format is used for either LDLC specific     |
|                     messages or HPR session and control traffic.     |
+----------------------------------------------------------------------+
+----------------------------------------------------------------------+
| IP Format for NLPs in UI Frames                                      |
+-------+-----+--------------------------------------------------------+
| Byte  | Bit | Content                                                |
+-------+-----+--------------------------------------------------------+
+-------+-----+--------------------------------------------------------+
| 0-p   |     | IP header (see note 1)                                 |
+-------+-----+--------------------------------------------------------+
+-------+-----+--------------------------------------------------------+
| p+1-  |     | UDP header (see note 2)                                |
| p+8   |     |                                                        |
+-------+-----+--------------------------------------------------------+
+-------+-----+--------------------------------------------------------+
| p+9-  |     | IEEE 802.2 LLC header                                  |
                _____________________
| p+11  |     |                                                        |
+-------+-----+--------------------------------------------------------+




Dudley                       Informational                     [Page 46]

RFC 2353                APPN/HPR in IP Networks                 May 1998


+-------+-----+--------------------------------------------------------+
| p+9   |     | DSAP:  the destination SAP obtained from the IEEE      |
|       |     | 802.2 LLC (X'80') subfield in the HPR Capabilities     |
|       |     | (X'61') control vector in the received XID3 (see note  |
|       |     | 3)                                                     |
+-------+-----+--------------------------------------------------------+
+-------+-----+--------------------------------------------------------+
| p+10  |     | SSAP:  the source SAP obtained from the IEEE 802.2 LLC |
|       |     | (X'80') subfield in the HPR Capabilities (X'61')       |
|       |     | control vector in the sent XID3 (see note 4)           |
+-------+-----+--------------------------------------------------------+
+-------+-----+--------------------------------------------------------+
| p+11  |     | Control:                                               |
+-------+-----+-------+------------------------------------------------+
|       |     | X'03' | UI with P/F bit off                            |
+-------+-----+-------+------------------------------------------------+
+-------+-----+--------------------------------------------------------+
| p+12-n|     | Remainder of PDU:  NLP                                 |
+-------+-----+--------------------------------------------------------+
+-------+-----+--------------------------------------------------------+
|       |     | Note 1:  Rules for encoding the IP header can be found |
|       |     | in RFC 791.                                            |
+-------+-----+--------------------------------------------------------+
+-------+-----+--------------------------------------------------------+
|       |     | Note 2:  Rules for encoding the UDP header can be      |
|       |     | found in RFC 768.                                      |
+-------+-----+--------------------------------------------------------+
+----------------------------------------------------------------------+
| IP Format for NLPs in UI Frames                                      |
+-------+-----+--------------------------------------------------------+
| Byte  | Bit | Content                                                |
+-------+-----+--------------------------------------------------------+
+-------+-----+--------------------------------------------------------+
|       |     | Note 3:  The User-Defined Address bit is considered    |
|       |     | part of the DSAP.  The Individual/Group bit in the     |
|       |     | DSAP field is set to 0 by the sender and ignored by    |
|       |     | the receiver.                                          |
+-------+-----+--------------------------------------------------------+
+-------+-----+--------------------------------------------------------+
|       |     | Note 4:  The User-Defined Address bit is considered    |
|       |     | part of the SSAP.  The Command/Response bit in the     |
|       |     | SSAP field is set to 0 by the sender and ignored by    |
|       |     | the receiver.                                          |
+-------+-----+--------------------------------------------------------+







Dudley                       Informational                     [Page 47]

RFC 2353                APPN/HPR in IP Networks                 May 1998


7.0  Full Copyright Statement

Copyright (C) The Internet Society (1997).  All Rights Reserved.

This document and translations of it may be copied and furnished to
others, and derivative works that comment on or otherwise explain it or
assist in its implementation may be prepared, copied, published and
distributed, in whole or in part, without restriction of any kind,
provided that the above copyright notice and this paragraph are included
on all such copies and derivative works.  However, this document itself
may not be modified in any way, such as by removing the copyright notice
or references to the Internet Society or other Internet organizations,
except as needed for the purpose of developing Internet standards in
which case the procedures for copyrights defined in the Internet
Standards process must be followed, or as required to translate it into
languages other than English.

The limited permissions granted above are perpetual and will not be
revoked by the Internet Society or its successors or assigns.

This document and the information contained herein is provided on an "AS
IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK
FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT
LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT
INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR
FITNESS FOR A PARTICULAR PURPOSE.

























Dudley                       Informational                     [Page 48]