File: rfc1237.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 (2973 lines) | stat: -rw-r--r-- 116,989 bytes parent folder | download | duplicates (8)
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
282
283
284
285
286
287
288
289
290
291
292
293
294
295
296
297
298
299
300
301
302
303
304
305
306
307
308
309
310
311
312
313
314
315
316
317
318
319
320
321
322
323
324
325
326
327
328
329
330
331
332
333
334
335
336
337
338
339
340
341
342
343
344
345
346
347
348
349
350
351
352
353
354
355
356
357
358
359
360
361
362
363
364
365
366
367
368
369
370
371
372
373
374
375
376
377
378
379
380
381
382
383
384
385
386
387
388
389
390
391
392
393
394
395
396
397
398
399
400
401
402
403
404
405
406
407
408
409
410
411
412
413
414
415
416
417
418
419
420
421
422
423
424
425
426
427
428
429
430
431
432
433
434
435
436
437
438
439
440
441
442
443
444
445
446
447
448
449
450
451
452
453
454
455
456
457
458
459
460
461
462
463
464
465
466
467
468
469
470
471
472
473
474
475
476
477
478
479
480
481
482
483
484
485
486
487
488
489
490
491
492
493
494
495
496
497
498
499
500
501
502
503
504
505
506
507
508
509
510
511
512
513
514
515
516
517
518
519
520
521
522
523
524
525
526
527
528
529
530
531
532
533
534
535
536
537
538
539
540
541
542
543
544
545
546
547
548
549
550
551
552
553
554
555
556
557
558
559
560
561
562
563
564
565
566
567
568
569
570
571
572
573
574
575
576
577
578
579
580
581
582
583
584
585
586
587
588
589
590
591
592
593
594
595
596
597
598
599
600
601
602
603
604
605
606
607
608
609
610
611
612
613
614
615
616
617
618
619
620
621
622
623
624
625
626
627
628
629
630
631
632
633
634
635
636
637
638
639
640
641
642
643
644
645
646
647
648
649
650
651
652
653
654
655
656
657
658
659
660
661
662
663
664
665
666
667
668
669
670
671
672
673
674
675
676
677
678
679
680
681
682
683
684
685
686
687
688
689
690
691
692
693
694
695
696
697
698
699
700
701
702
703
704
705
706
707
708
709
710
711
712
713
714
715
716
717
718
719
720
721
722
723
724
725
726
727
728
729
730
731
732
733
734
735
736
737
738
739
740
741
742
743
744
745
746
747
748
749
750
751
752
753
754
755
756
757
758
759
760
761
762
763
764
765
766
767
768
769
770
771
772
773
774
775
776
777
778
779
780
781
782
783
784
785
786
787
788
789
790
791
792
793
794
795
796
797
798
799
800
801
802
803
804
805
806
807
808
809
810
811
812
813
814
815
816
817
818
819
820
821
822
823
824
825
826
827
828
829
830
831
832
833
834
835
836
837
838
839
840
841
842
843
844
845
846
847
848
849
850
851
852
853
854
855
856
857
858
859
860
861
862
863
864
865
866
867
868
869
870
871
872
873
874
875
876
877
878
879
880
881
882
883
884
885
886
887
888
889
890
891
892
893
894
895
896
897
898
899
900
901
902
903
904
905
906
907
908
909
910
911
912
913
914
915
916
917
918
919
920
921
922
923
924
925
926
927
928
929
930
931
932
933
934
935
936
937
938
939
940
941
942
943
944
945
946
947
948
949
950
951
952
953
954
955
956
957
958
959
960
961
962
963
964
965
966
967
968
969
970
971
972
973
974
975
976
977
978
979
980
981
982
983
984
985
986
987
988
989
990
991
992
993
994
995
996
997
998
999
1000
1001
1002
1003
1004
1005
1006
1007
1008
1009
1010
1011
1012
1013
1014
1015
1016
1017
1018
1019
1020
1021
1022
1023
1024
1025
1026
1027
1028
1029
1030
1031
1032
1033
1034
1035
1036
1037
1038
1039
1040
1041
1042
1043
1044
1045
1046
1047
1048
1049
1050
1051
1052
1053
1054
1055
1056
1057
1058
1059
1060
1061
1062
1063
1064
1065
1066
1067
1068
1069
1070
1071
1072
1073
1074
1075
1076
1077
1078
1079
1080
1081
1082
1083
1084
1085
1086
1087
1088
1089
1090
1091
1092
1093
1094
1095
1096
1097
1098
1099
1100
1101
1102
1103
1104
1105
1106
1107
1108
1109
1110
1111
1112
1113
1114
1115
1116
1117
1118
1119
1120
1121
1122
1123
1124
1125
1126
1127
1128
1129
1130
1131
1132
1133
1134
1135
1136
1137
1138
1139
1140
1141
1142
1143
1144
1145
1146
1147
1148
1149
1150
1151
1152
1153
1154
1155
1156
1157
1158
1159
1160
1161
1162
1163
1164
1165
1166
1167
1168
1169
1170
1171
1172
1173
1174
1175
1176
1177
1178
1179
1180
1181
1182
1183
1184
1185
1186
1187
1188
1189
1190
1191
1192
1193
1194
1195
1196
1197
1198
1199
1200
1201
1202
1203
1204
1205
1206
1207
1208
1209
1210
1211
1212
1213
1214
1215
1216
1217
1218
1219
1220
1221
1222
1223
1224
1225
1226
1227
1228
1229
1230
1231
1232
1233
1234
1235
1236
1237
1238
1239
1240
1241
1242
1243
1244
1245
1246
1247
1248
1249
1250
1251
1252
1253
1254
1255
1256
1257
1258
1259
1260
1261
1262
1263
1264
1265
1266
1267
1268
1269
1270
1271
1272
1273
1274
1275
1276
1277
1278
1279
1280
1281
1282
1283
1284
1285
1286
1287
1288
1289
1290
1291
1292
1293
1294
1295
1296
1297
1298
1299
1300
1301
1302
1303
1304
1305
1306
1307
1308
1309
1310
1311
1312
1313
1314
1315
1316
1317
1318
1319
1320
1321
1322
1323
1324
1325
1326
1327
1328
1329
1330
1331
1332
1333
1334
1335
1336
1337
1338
1339
1340
1341
1342
1343
1344
1345
1346
1347
1348
1349
1350
1351
1352
1353
1354
1355
1356
1357
1358
1359
1360
1361
1362
1363
1364
1365
1366
1367
1368
1369
1370
1371
1372
1373
1374
1375
1376
1377
1378
1379
1380
1381
1382
1383
1384
1385
1386
1387
1388
1389
1390
1391
1392
1393
1394
1395
1396
1397
1398
1399
1400
1401
1402
1403
1404
1405
1406
1407
1408
1409
1410
1411
1412
1413
1414
1415
1416
1417
1418
1419
1420
1421
1422
1423
1424
1425
1426
1427
1428
1429
1430
1431
1432
1433
1434
1435
1436
1437
1438
1439
1440
1441
1442
1443
1444
1445
1446
1447
1448
1449
1450
1451
1452
1453
1454
1455
1456
1457
1458
1459
1460
1461
1462
1463
1464
1465
1466
1467
1468
1469
1470
1471
1472
1473
1474
1475
1476
1477
1478
1479
1480
1481
1482
1483
1484
1485
1486
1487
1488
1489
1490
1491
1492
1493
1494
1495
1496
1497
1498
1499
1500
1501
1502
1503
1504
1505
1506
1507
1508
1509
1510
1511
1512
1513
1514
1515
1516
1517
1518
1519
1520
1521
1522
1523
1524
1525
1526
1527
1528
1529
1530
1531
1532
1533
1534
1535
1536
1537
1538
1539
1540
1541
1542
1543
1544
1545
1546
1547
1548
1549
1550
1551
1552
1553
1554
1555
1556
1557
1558
1559
1560
1561
1562
1563
1564
1565
1566
1567
1568
1569
1570
1571
1572
1573
1574
1575
1576
1577
1578
1579
1580
1581
1582
1583
1584
1585
1586
1587
1588
1589
1590
1591
1592
1593
1594
1595
1596
1597
1598
1599
1600
1601
1602
1603
1604
1605
1606
1607
1608
1609
1610
1611
1612
1613
1614
1615
1616
1617
1618
1619
1620
1621
1622
1623
1624
1625
1626
1627
1628
1629
1630
1631
1632
1633
1634
1635
1636
1637
1638
1639
1640
1641
1642
1643
1644
1645
1646
1647
1648
1649
1650
1651
1652
1653
1654
1655
1656
1657
1658
1659
1660
1661
1662
1663
1664
1665
1666
1667
1668
1669
1670
1671
1672
1673
1674
1675
1676
1677
1678
1679
1680
1681
1682
1683
1684
1685
1686
1687
1688
1689
1690
1691
1692
1693
1694
1695
1696
1697
1698
1699
1700
1701
1702
1703
1704
1705
1706
1707
1708
1709
1710
1711
1712
1713
1714
1715
1716
1717
1718
1719
1720
1721
1722
1723
1724
1725
1726
1727
1728
1729
1730
1731
1732
1733
1734
1735
1736
1737
1738
1739
1740
1741
1742
1743
1744
1745
1746
1747
1748
1749
1750
1751
1752
1753
1754
1755
1756
1757
1758
1759
1760
1761
1762
1763
1764
1765
1766
1767
1768
1769
1770
1771
1772
1773
1774
1775
1776
1777
1778
1779
1780
1781
1782
1783
1784
1785
1786
1787
1788
1789
1790
1791
1792
1793
1794
1795
1796
1797
1798
1799
1800
1801
1802
1803
1804
1805
1806
1807
1808
1809
1810
1811
1812
1813
1814
1815
1816
1817
1818
1819
1820
1821
1822
1823
1824
1825
1826
1827
1828
1829
1830
1831
1832
1833
1834
1835
1836
1837
1838
1839
1840
1841
1842
1843
1844
1845
1846
1847
1848
1849
1850
1851
1852
1853
1854
1855
1856
1857
1858
1859
1860
1861
1862
1863
1864
1865
1866
1867
1868
1869
1870
1871
1872
1873
1874
1875
1876
1877
1878
1879
1880
1881
1882
1883
1884
1885
1886
1887
1888
1889
1890
1891
1892
1893
1894
1895
1896
1897
1898
1899
1900
1901
1902
1903
1904
1905
1906
1907
1908
1909
1910
1911
1912
1913
1914
1915
1916
1917
1918
1919
1920
1921
1922
1923
1924
1925
1926
1927
1928
1929
1930
1931
1932
1933
1934
1935
1936
1937
1938
1939
1940
1941
1942
1943
1944
1945
1946
1947
1948
1949
1950
1951
1952
1953
1954
1955
1956
1957
1958
1959
1960
1961
1962
1963
1964
1965
1966
1967
1968
1969
1970
1971
1972
1973
1974
1975
1976
1977
1978
1979
1980
1981
1982
1983
1984
1985
1986
1987
1988
1989
1990
1991
1992
1993
1994
1995
1996
1997
1998
1999
2000
2001
2002
2003
2004
2005
2006
2007
2008
2009
2010
2011
2012
2013
2014
2015
2016
2017
2018
2019
2020
2021
2022
2023
2024
2025
2026
2027
2028
2029
2030
2031
2032
2033
2034
2035
2036
2037
2038
2039
2040
2041
2042
2043
2044
2045
2046
2047
2048
2049
2050
2051
2052
2053
2054
2055
2056
2057
2058
2059
2060
2061
2062
2063
2064
2065
2066
2067
2068
2069
2070
2071
2072
2073
2074
2075
2076
2077
2078
2079
2080
2081
2082
2083
2084
2085
2086
2087
2088
2089
2090
2091
2092
2093
2094
2095
2096
2097
2098
2099
2100
2101
2102
2103
2104
2105
2106
2107
2108
2109
2110
2111
2112
2113
2114
2115
2116
2117
2118
2119
2120
2121
2122
2123
2124
2125
2126
2127
2128
2129
2130
2131
2132
2133
2134
2135
2136
2137
2138
2139
2140
2141
2142
2143
2144
2145
2146
2147
2148
2149
2150
2151
2152
2153
2154
2155
2156
2157
2158
2159
2160
2161
2162
2163
2164
2165
2166
2167
2168
2169
2170
2171
2172
2173
2174
2175
2176
2177
2178
2179
2180
2181
2182
2183
2184
2185
2186
2187
2188
2189
2190
2191
2192
2193
2194
2195
2196
2197
2198
2199
2200
2201
2202
2203
2204
2205
2206
2207
2208
2209
2210
2211
2212
2213
2214
2215
2216
2217
2218
2219
2220
2221
2222
2223
2224
2225
2226
2227
2228
2229
2230
2231
2232
2233
2234
2235
2236
2237
2238
2239
2240
2241
2242
2243
2244
2245
2246
2247
2248
2249
2250
2251
2252
2253
2254
2255
2256
2257
2258
2259
2260
2261
2262
2263
2264
2265
2266
2267
2268
2269
2270
2271
2272
2273
2274
2275
2276
2277
2278
2279
2280
2281
2282
2283
2284
2285
2286
2287
2288
2289
2290
2291
2292
2293
2294
2295
2296
2297
2298
2299
2300
2301
2302
2303
2304
2305
2306
2307
2308
2309
2310
2311
2312
2313
2314
2315
2316
2317
2318
2319
2320
2321
2322
2323
2324
2325
2326
2327
2328
2329
2330
2331
2332
2333
2334
2335
2336
2337
2338
2339
2340
2341
2342
2343
2344
2345
2346
2347
2348
2349
2350
2351
2352
2353
2354
2355
2356
2357
2358
2359
2360
2361
2362
2363
2364
2365
2366
2367
2368
2369
2370
2371
2372
2373
2374
2375
2376
2377
2378
2379
2380
2381
2382
2383
2384
2385
2386
2387
2388
2389
2390
2391
2392
2393
2394
2395
2396
2397
2398
2399
2400
2401
2402
2403
2404
2405
2406
2407
2408
2409
2410
2411
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
2692
2693
2694
2695
2696
2697
2698
2699
2700
2701
2702
2703
2704
2705
2706
2707
2708
2709
2710
2711
2712
2713
2714
2715
2716
2717
2718
2719
2720
2721
2722
2723
2724
2725
2726
2727
2728
2729
2730
2731
2732
2733
2734
2735
2736
2737
2738
2739
2740
2741
2742
2743
2744
2745
2746
2747
2748
2749
2750
2751
2752
2753
2754
2755
2756
2757
2758
2759
2760
2761
2762
2763
2764
2765
2766
2767
2768
2769
2770
2771
2772
2773
2774
2775
2776
2777
2778
2779
2780
2781
2782
2783
2784
2785
2786
2787
2788
2789
2790
2791
2792
2793
2794
2795
2796
2797
2798
2799
2800
2801
2802
2803
2804
2805
2806
2807
2808
2809
2810
2811
2812
2813
2814
2815
2816
2817
2818
2819
2820
2821
2822
2823
2824
2825
2826
2827
2828
2829
2830
2831
2832
2833
2834
2835
2836
2837
2838
2839
2840
2841
2842
2843
2844
2845
2846
2847
2848
2849
2850
2851
2852
2853
2854
2855
2856
2857
2858
2859
2860
2861
2862
2863
2864
2865
2866
2867
2868
2869
2870
2871
2872
2873
2874
2875
2876
2877
2878
2879
2880
2881
2882
2883
2884
2885
2886
2887
2888
2889
2890
2891
2892
2893
2894
2895
2896
2897
2898
2899
2900
2901
2902
2903
2904
2905
2906
2907
2908
2909
2910
2911
2912
2913
2914
2915
2916
2917
2918
2919
2920
2921
2922
2923
2924
2925
2926
2927
2928
2929
2930
2931
2932
2933
2934
2935
2936
2937
2938
2939
2940
2941
2942
2943
2944
2945
2946
2947
2948
2949
2950
2951
2952
2953
2954
2955
2956
2957
2958
2959
2960
2961
2962
2963
2964
2965
2966
2967
2968
2969
2970
2971
2972
2973
    
    
    
    
    Network Working Group                            Richard Colella (NIST)
    Request for Comments: 1237                         Ella Gardner (Mitre)
                                                          Ross Callon (DEC)
                                                                  July 1991
    
    
               Guidelines for OSI NSAP Allocation in the Internet
    
    
    
    Status of This Memo
    
    
    This RFC specifies an IAB standards track protocol for the Internet
    community, and requests discussion and suggestions for improvements.
    Please refer to the current edition of the ``IAB Official Protocol
    Standards'' for the standardization state and status of this protocol.
    Distribution of this memo is unlimited.
    
    

    
    
                                     Abstract
    
    
    
    The Internet is moving towards a multi-protocol environment that
    includes OSI. To support OSI in the Internet, an OSI lower layers
    infrastructure is required. This infrastructure comprises the
    connectionless network protocol (CLNP) and supporting routing
    protocols. Also required as part of this infrastructure are guidelines
    for network service access point (NSAP) address assignment. This paper
    provides guidelines for allocating NSAPs in the Internet.
    
    
    This document provides our current best judgment for the allocation
    of NSAP addresses in the Internet. This is intended to guide initial
    deployment of OSI 8473 (Connectionless Network Layer Protocol) in
    the Internet, as well as to solicit comments. It is expected that
    these guidelines may be further refined and this document updated as a
    result of experience gained during this initial deployment.
    
    
    
    
    
    RFC 1237  Guidelines for OSI NSAP Allocation in the Internet  July 1991
    
    
    
    Contents
    
    
    
    1   Introduction                                                      4
    
    
    2   Scope                                                             4
    
    
    3   Background                                                        6
    
        3.1 OSI Routing Standards  .  .  .  .  .  .  .  .  .  .  .  .     7
    
        3.2 Overview of DIS10589    . .  .  .  .  .  .  .  .  .  .  .     8
    
        3.3 Requirements of DIS10589 on NSAPs  .  .  .  .  .  .  .  .    11
    
    
    4   NSAP and Routing                                                 13
    
    
    5   NSAP Administration and Routing in the Internet                  17
    
        5.1 Administration at the Area   .  .  .  .  .  .  .  .  .  .    19
    
        5.2 Administration at the Leaf Routing Domain   .  .  .  .  .    21
    
        5.3 Administration at the Transit Routing Domain   .  .  .  .    21
    
            5.3.1  Regionals  .  .  .  .  .  .  .  .  .  . .  .  .  .    22
    
            5.3.2  Backbones  .  .  .  .  .  .  .  .  .  . .  .  .  .    23
    
        5.4 Multi-homed Routing Domains  .  .  .  .  .  .  .  .  .  .    24
    
        5.5 Private Links  .  . .  .  .  .  .  .  .  .  .  .  .  .  .    29
    
        5.6 Zero-Homed Routing Domains   .  .  .  .  .  .  .  .  .  .    30
    
        5.7 Transition Issues    .  . .  .  .  .  .  .  .  .  .  .  .    31
    
    
    
    6   Recommendations                                                  34
    
        6.1 Recommendations Specific to U.S. Parts of the Internet  .    35
    
    
    
    Colella, Gardner, & Callon                                     [Page 2]
    
    
    
    
    
    RFC 1237  Guidelines for OSI NSAP Allocation in the Internet  July 1991
    
    
    
        6.2 Recommendations Specific to Non-U.S. Parts of the Internet   37
    
        6.3 Recommendations for Multi-Homed Routing Domains   .  .  .    37
    
    
    7   Security Considerations                                          38
    
    
    8   Authors' Addresses                                               39
    
    
    9   Acknowledgments                                                  39
    
    
    A   Administration of NSAPs                                          40
    
        A.1 GOSIP Version 2 NSAPs  .  .  .  .  .  .  .  .  .  .  .  .    41
    
            A.1.1  Application for Administrative Authority Identifiers  42
    
            A.1.2  Guidelines for NSAP Assignment  .  . .  .  .  .  .    44
    
        A.2 Data Country Code NSAPs   .  .  .  .  .  .  .  .  .  .  .    45
    
            A.2.1  Application for Numeric Organization Name   .  .  .   46
    
        A.3 Summary of Administrative Requirements   .  .  .  .  .  .    46
    
    
    
    
    
    
    
    
    
    
    
    
    
    
    
    
    
    
    
    
    
    
    
    
    Colella, Gardner, & Callon                                     [Page 3]
    
    
    
    
    
    RFC 1237  Guidelines for OSI NSAP Allocation in the Internet  July 1991
    
    
    
    1   Introduction
    
    
    
    The Internet is moving towards a multi-protocol environment that
    includes OSI. To support OSI in the Internet, an OSI lower layers
    infrastructure is required. This infrastructure comprises the
    connectionless network protocol (CLNP) [12] (see also RFC 994 [8])
    and supporting routing protocols. Also required as part of this
    infrastructure are guidelines for network service access point (NSAP)
    address assignment. This paper provides guidelines for allocating
    NSAPs in the Internet (NSAP and NSAP address are used interchangeably
    throughout this paper in referring to NSAP addresses).
    
    
    The remainder of this paper is organized into five major sections and
    an appendix. Section 2 defines the boundaries of the problem addressed
    in this paper and Section 3 provides background information on OSI
    routing and the implications for NSAPs.
    
    
    Section 4 addresses the specific relationship between NSAPs and
    routing, especially with regard to hierarchical routing and data
    abstraction. This is followed in Section 5 with an application of
    these concepts to the Internet environment. Section 6 provides
    recommended guidelines for NSAP allocation in the Internet.
    
    
    Appendix A contains a compendium of useful information concerning
    NSAP structure and allocation authorities. The GOSIP Version 2 NSAP
    structure is discussed in detail and the structure for U.S.-based DCC
    (Data Country Code) NSAPs is described. Contact information for the
    registration authorities for GOSIP and DCC-based NSAPs in the U.S.,
    the General Services Administration (GSA) and the American National
    Standards Institute (ANSI), respectively, is provided.
    
    
    
    2   Scope
    
    
    
    There are two aspects of interest when discussing OSI NSAP allocation
    within the Internet. The first is the set of administrative require-
    ments for obtaining and allocating NSAPs; the second is the technical
    aspect of such assignments, having largely to do with routing, both
    within a routing domain (intra-domain routing) and between routing
    
    
    
    
    Colella, Gardner, & Callon                                     [Page 4]
    
    
    
    
    
    RFC 1237  Guidelines for OSI NSAP Allocation in the Internet  July 1991
    
    
    
    domains (inter-domain routing). This paper focuses on the technical
    issues.
    
    
    The technical issues in NSAP allocation are mainly related to routing.
    This paper assumes that CLNP will be widely deployed in the Internet,
    and that the routing of CLNP traffic will normally be based on the OSI
    ES-IS (end-system to intermediate system) routing protocol applicable
    for point-to-point links and LANs [13] (see also RFC 995 [7]) and
    the emerging intra-domain IS-IS protocol [17]. Also expected is the
    deployment of an inter-domain routing protocol similar to Border
    Gateway Protocol (BGP) [18].
    
    
    The guidelines provided in this paper are intended for immediate
    deployment as CLNP is made available in the Internet. This paper
    specifically does not address long-term research issues, such as
    complex policy-based routing requirements.
    
    
    In the current Internet many routing domains (such as corporate and
    campus networks) attach to transit networks (such as NSFNET regionals)
    in only one or a small number of carefully controlled access points.
    Addressing solutions which require substantial changes or constraints
    on the current topology are not considered.
    
    
    The guidelines in this paper are oriented primarily toward the large-
    scale division of NSAP address allocation in the Internet. Topics
    covered include:
    
    
       * Arrangement of parts of the NSAP for efficient operation of the
         DIS10589IS-IS routing protocol;
    
       * Benefits of some topological information in NSAPs to reduce
         routing protocol overhead;
    
       * The anticipated need for additional levels of hierarchy in
         Internet addressing to support network growth;
    
       * The recommended mapping between Internet topological entities
         (i.e., backbone networks, regional networks, and site networks)
         and OSI addressing and routing components;
    
       * The recommended division of NSAP address assignment authority
         among backbones, regionals (also called mid-levels), and sites;
    
    
    
    
    Colella, Gardner, & Callon                                     [Page 5]
    
    
    
    
    
    RFC 1237  Guidelines for OSI NSAP Allocation in the Internet  July 1991
    
    
    
       * Background information on administrative procedures for registra-
         tion of administrative authorities immediately below the national
         level (GOSIP administrative authorities and ANSI organization
         identifiers); and,
    
    
       * Choice of the high-order portion of the NSAP in leaf routing
         domains that are connected to more than one regional or backbone.
    
    
    
    It is noted that there are other aspects of NSAP allocation, both
    technical and administrative, that are not covered in this paper.
    Topics not covered or mentioned only superficially include:
    
    
    
       * Identification of specific administrative domains in the Internet;
    
    
       * Policy or mechanisms for making registered information known to
         third parties (such as the entity to which a specific NSAP or a
         potion of the NSAP address space has been allocated);
    
    
       * How a routing domain (especially a site) should organize its
         internal topology of areas or allocate portions of its NSAP
         address space; the relationship between topology and addresses is
         discussed, but the method of deciding on a particular topology or
         internal addressing plan is not; and,
    
    
       * Procedures for assigning the System Identifier (ID) portion of the
         NSAP.
    
    
    
    3   Background
    
    
    
    Some background information is provided in this section that is
    helpful in understanding the issues involved in NSAP allocation. A
    brief discussion of OSI routing is provided, followed by a review
    of the intra-domain protocol in sufficient detail to understand the
    issues involved in NSAP allocation. Finally, the specific constraints
    that the intra-domain protocol places on NSAPs are listed.
    
    
    
    
    Colella, Gardner, & Callon                                     [Page 6]
    
    
    
    
    
    RFC 1237  Guidelines for OSI NSAP Allocation in the Internet  July 1991
    
    
    
    3.1   OSI Routing Standards
    
    
    
    OSI partitions the routing problem into three parts:
    
    
       * routing exchanges between end systems and intermediate systems
         (ES-IS),
    
       * routing exchanges between ISs in the same routing domain (intra-
         domain IS-IS), and,
    
       * routing among routing domains (inter-domain IS-IS).
    
    
    ES-IS, international standard ISO9542 [13] approved in 1987, is
    available in vendor products and is planned for the next release of
    Berkeley UNIX (UNIX is a trademark of AT&T). It is also cited in GOSIP
    Version 2 [4], which became effective in April 1991 for all applicable
    federal procurements, and mandatory beginning eighteen months later in
    1992.
    
    
    Intra-domain IS-IS advanced to draft international standard (DIS)
    status within ISO in November, 1990 as DIS10589 [17]. It is reasonable
    to expect that final text for the intra-domain IS-IS standard will be
    available by mid-1991.
    
    
    There are two candidate proposals which address OSI inter-domain
    routing, ECMA TR/50 [3] and Border Router Protocol (BRP) [19], a
    direct derivative of the IETF Border Gateway Protocol [18]. ECMA TR/50
    has been proposed as base text in the ISO/IEC JTC1 SC6/WG2 committee,
    which is responsible for the Network layer of the ISO Reference Model
    [11 ].X3S3.3, the ANSI counterpart to WG2, has incorporated features
    of TR/50 into BRP and submitted this as alternate base text at the
    WG2 meeting in October, 1990. Currently, it is out for ISO Member
    Body comment. The proposed protocol is referred to as the Inter-domain
    Routing Protocol (IDRP) [20].
    
    
    This paper examines the technical implications of NSAP assignment
    under the assumption that ES-IS, intra-domain IS-IS, and IDRP routing
    are deployed to support CLNP.
    
    
    
    
    
    
    Colella, Gardner, & Callon                                     [Page 7]
    
    
    
    
    
    RFC 1237  Guidelines for OSI NSAP Allocation in the Internet  July 1991
    
    
    
    3.2   Overview of DIS10589
    
    
    
    The IS-IS intra-domain routing protocol, DIS10589, developed in ISO,
    provides routing for OSI environments. In particular, DIS10589 is
    designed to work in conjunction with CLNP and ES-IS. This section
    briefly describes the manner in which DIS10589 operates.
    
    
    In DIS10589, the internetwork is partitioned into routing domains.
    A routing domain is a collection of ESs and ISs that operate common
    routing protocols and are under the control of a single administra-
    tion. Typically, a routing domain may consist of a corporate network,
    a university campus network, a regional network, or a similar contigu-
    ous network under control of a single administrative organization. The
    boundaries of routing domains are defined by network management by
    setting some links to be exterior, or inter-domain, links. If a link
    is marked as exterior, no DIS10589 routing messages are sent on that
    link.
    
    
    Currently, ISO does not have a standard for inter-domain routing
    (i.e., for routing between separate autonomous routing domains). In
    the interim, DIS10589 uses manual configuration. An inter-domain link
    is statically configured with the set of address prefixes reachable
    via that link, and with the method by which they can be reached (such
    as the DTE address to be dialed to reach that address, or the fact
    that the DTE address should be extracted from the OSI NSAP address).
    
    
    DIS10589 routing makes use of two-level hierarchical routing. A
    routing domain is subdivided into areas (also known as level 1
    subdomains). Level 1 ISs know the topology in their area, including
    all ISs and ESs in their area. However, level 1 ISs do not know the
    identity of ISs or destinations outside of their area. Level 1 ISs
    forward all traffic for destinations outside of their area to a level
    2 IS within their area.
    
    
    Similarly, level 2 ISs know the level 2 topology and know which
    addresses are reachable via each level 2 IS. The set of all level 2
    ISs in a routing domain are known as the level 2 subdomain, which can
    be thought of as a backbone for interconnecting the areas. Level 2
    ISs do not need to know the topology within any level 1 area, except
    to the extent that a level 2 IS may also be a level 1 IS within a
    single area. Only level 2 ISs can exchange data packets or routing
    information directly with external ISs located outside of their
    
    
    
    Colella, Gardner, & Callon                                     [Page 8]
    
    
    
    
    
    RFC 1237  Guidelines for OSI NSAP Allocation in the Internet  July 1991
    
    
    
    routing domain.
    
    
    As illustrated in Figure 1, ISO addresses are subdivided into the
    Initial Domain Part (IDP) and the Domain Specific Part (DSP), as spec-
    ified in ISO8348/Addendum 2, the OSI network layer addressing standard
    [14 ](also RFC 941 [6]). The IDP is the part which is standardized by
    ISO, and specifies the format and authority responsible for assigning
    the rest of the address. The DSP is assigned by whatever addressing
    authority is specified by the IDP (see Appendix A for more discussion
    on the top level NSAP addressing authorities). The DSP is further
    subdivided, by DIS10589, into a High Order Part of DSP (HO-DSP), a
    system identifier (ID), and an NSAP selector (SEL). The HO-DSP may
    use any format desired by the authority which is identified by the
    IDP. Together, the combination of [IDP,HO-DSP] identify an area within
    a routing domain and, implicitly, the routing domain containing the
    area. The combination of [IDP,HO-DSP] is therefore referred to as the
    area address.
    
                  _______________________________________________
                  !____IDP_____!_______________DSP______________!
                  !__AFI_!_IDI_!_____HO-DSP______!___ID___!_SEL_!
    
    
                     IDP     Initial Domain Part
                     AFI     Authority and Format Identifier
                     IDI     Initial Domain Identifier
                     DSP     Domain Specific Part
                     HO-DSP  High-order DSP
                     ID      System Identifier
                     SEL     NSAP Selector
    
    
                  Figure 1: OSI Hierarchical Address Structure.
    
    
    
    The ID field may be from one to eight octets in length, but must have
    a single known length in any particular routing domain. Each router is
    configured to know what length is used in its domain. The SEL field is
    always one octet in length. Each router is therefore able to identify
    the ID and SEL fields as a known number of trailing octets of the NSAP
    address. The area address can be identified as the remainder of the
    address (after truncation of the ID and SEL fields).
    
    
    Usually, all nodes in an area have the same area address. However,
    sometimes an area might have multiple addresses. Motivations for
    allowing this are several:
    
    
    Colella, Gardner, & Callon                                     [Page 9]
    
    
    
    
    
    RFC 1237  Guidelines for OSI NSAP Allocation in the Internet  July 1991
    
    
    
       * It might be desirable to change the address of an area. The most
         graceful way of changing an area from having address A to having
         address B is to first allow it to have both addresses A and B, and
         then after all nodes in the area have been modified to recognize
         both addresses, one by one the ESs can be modified to forget
         address A.
    
       * It might be desirable to merge areas A and B into one area. The
         method for accomplishing this is to, one by one, add knowledge of
         address B into the A partition, and similarly add knowledge of
         address A into the B partition.
    
       * It might be desirable to partition an area C into two areas, A and
         B (where A might equal C, in which case this example becomes one
         of removing a portion of an area). This would be accomplished by
         first introducing knowledge of address A into the appropriate ESs
         (those destined to become area A), and knowledge of address B into
         the appropriate nodes, and then one by one removing knowledge of
         address C.
    
    
    
    Since the addressing explicitly identifies the area, it is very easy
    for level 1 ISs to identify packets going to destinations outside
    of their area, which need to be forwarded to level 2 ISs. Thus, in
    DIS10589 the two types of ISs route as follows:
    
    
       * Level 1 intermediate systems -- these nodes route based on the ID
         portion of the ISO address. They route within an area. Level 1 ISs
         recognize, based on the destination address in a packet, whether
         the destination is within the area. If so, they route towards the
         destination. If not, they route to the nearest level 2 IS.
    
       * Level 2 intermediate systems -- these nodes route based on address
         prefixes, preferring the longest matching prefix, and preferring
         internal routes over external routes. They route towards areas,
         without regard to the internal structure of an area; or towards
         level 2 ISs on the routing domain boundary that have advertised
         external address prefixes into the level 2 subdomain. A level 2 IS
         may also be operating as a level 1 IS in one area.
    
    
    
    A level 1 IS will have the area portion of its address manually
    configured. It will refuse to become a neighbor with an IS whose area
    addresses do not overlap its own area addresses. However, if a level 1
    IS has area addresses A, B, and C, and a neighbor has area addresses
    
    
    
    Colella, Gardner, & Callon                                    [Page 10] 
    
    
    
    
    RFC 1237  Guidelines for OSI NSAP Allocation in the Internet  July 1991
    
    
    
    B and D, then the level 1 IS will accept the other IS as a level 1
    neighbor.
    
    
    A level 2 IS will accept another level 2 IS as a neighbor, regardless
    of area address. However, if the area addresses do not overlap, the
    link would be considered by both ISs to be level 2 only, and only
    level 2 routing packets would flow on the link. External links (i.e.,
    to other routing domains) must be between level 2 ISs in different
    routing domains.
    
    
    DIS10589 provides an optional partition repair function. In the
    unlikely case that a level 1 area becomes partitioned, this function,
    if implemented, allows the partition to be repaired via use of level 2
    routes.
    
    
    DIS10589 requires that the set of level 2 ISs be connected. Should the
    level 2 backbone become partitioned, there is no provision for use of
    level 1 links to repair a level 2 partition.
    
    
    In unusual cases, a single level 2 IS may lose connectivity to the
    level 2 backbone. In this case the level 2 IS will indicate in its
    level 1 routing packets that it is not attached, thereby allowing
    level 1 ISs in the area to route traffic for outside of the area
    to a different level 2 IS. Level 1 ISs therefore route traffic to
    destinations outside of their area only to level 2 ISs which indicate
    in their level 1 routing packets that they are attached.
    
    
    An ES may autoconfigure the area portion of its address by extracting
    the area portion of a neighboring IS's address. If this is the case,
    then an ES will always accept an IS as a neighbor. Since the standard
    does not specify that the end system must autoconfigure its area
    address, an end system may be pre-configured with an area address. In
    this case the end system would ignore IS neighbors with non-matching
    area addresses.
    
    
    
    3.3   Requirements of DIS10589 on NSAPs
    
    
    
    The preferred NSAP format for DIS10589 is shown in Figure 1. A number
    of points should be noted from DIS10589:
    
    
    
    Colella, Gardner, & Callon                                    [Page 11]
    
    
    
    
    
    RFC 1237  Guidelines for OSI NSAP Allocation in the Internet  July 1991
    
    
    
       * The IDP is as specified in ISO 8348/Addendum 2, the OSI network
         layer addressing standard [14];
    
    
       * The high-order portion of the DSP (HO-DSP) is that portion of the
         DSP whose assignment, structure, and meaning are not constrained
         by DIS10589;
    
    
       * The concatenation of the IDP and the HO-DSP, the area address,
         must be globally unique (if the area address of an NSAP matches
         one of the area addresses of a system, it is in the system's area
         and is routed to by level 1 routing);
    
    
       * Level 2 routing acts on address prefixes, using the longest
         address prefix that matches the destination address;
    
    
       * Level 1 routing acts on the ID field. The ID field must be unique
         within an area for ESs and level 1 ISs, and unique within the
         routing domain for level 2 ISs. The ID field is assumed to be
         flat;
    
    
       * The one-octet NSAP Selector, SEL, determines the entity to receive
         the CLNP packet within the system identified by the rest of the
         NSAP (i.e., a transport entity) and is always the last octet of
         the NSAP; and,
    
    
       * A system shall be able to generate and forward data packets
         containing addresses in any of the formats specified by ISO
         8348/Addendum 2. However, within a routing domain that conforms to
         DIS10589, the lower-order octets of the NSAP should be structured
         as the ID and SEL fields shown in Figure 1 to take full advantage
         of DIS10589 routing. End systems with addresses which do not
         conform may require additional manual configuration and be subject
         to inferior routing performance.
    
    
    For purposes of efficient operation of the IS-IS routing protocol,
    several observations may be made. First, although the IS-IS protocol
    specifies an algorithm for routing within a single routing domain, the
    routing algorithm must efficiently route both: (i) Packets whose final
    destination is in the domain (these must, of course, be routed to the
    correct destination end system in the domain); and (ii) Packets whose
    final destination is outside of the domain (these must be routed to a
    correct ``border'' router, from which they will exit the domain).
    
    
    Colella, Gardner, & Callon                                    [Page 12]
    
    
    
    
    
    RFC 1237  Guidelines for OSI NSAP Allocation in the Internet  July 1991
    
    
    
    For those destinations which are in the domain, level 2 routing treats
    the entire area address (i.e., all of the NSAP address except the ID
    and SEL fields) as if it were a flat field. Thus, the efficiency of
    level 2 routing to destinations within the domain is affected only by
    the number of areas in the domain, and the number of area addresses
    assigned to each area (which can range from one up to a maximum of
    three).
    
    
    For those destinations which are outside of the domain, level 2
    routing routes according to address prefixes. In this case, there
    is considerable potential advantage (in terms of reducing the amount
    of routing information that is required) if the number of address
    prefixes required to describe any particular set of destinations can
    be minimized.
    
    
    
    4   NSAPs and Routing
    
    
    
    When determining an administrative policy for NSAP assignment, it
    is important to understand the technical consequences. The objective
    behind the use of hierarchical routing is to achieve some level
    of routing data abstraction, or summarization, to reduce the cpu,
    memory, and transmission bandwidth consumed in support of routing.
    This dictates that NSAPs be assigned according to topological
    routing structures. However, administrative assignment falls along
    organizational or political boundaries. These may not be congruent to
    topological boundaries and therefore the requirements of the two may
    collide. It is necessary to find a balance between these two needs.
    
    
    Routing data abstraction occurs at the boundary between hierarchically
    arranged topological routing structures. An element lower in the
    hierarchy reports summary routing information to its parent(s). Within
    the current OSI routing framework [16] and routing protocols, the
    lowest boundary at which this can occur is the boundary between an
    area and the level 2 subdomain within a DIS10589 routing domain. Data
    abstraction is designed into DIS10589 at this boundary, since level 1
    ISs are constrained to reporting only area addresses, and a maximum
    number of three area addresses are allowed in one area (This is an
    architectural constant in DIS10589. See [17], Clause 7.2.11 and Table
    2 of Clause 7.5.1).
    
    
    
    
    
    
    Colella, Gardner, & Callon                                    [Page 13]
    
    
    
    
    
    RFC 1237  Guidelines for OSI NSAP Allocation in the Internet  July 1991
    
    
    
    Level 2 routing is based upon address prefixes. Level 2 ISs dis-
    tribute, throughout the level 2 subdomain, the area addresses of the
    level 1 areas to which they are attached (and any manually configured
    reachable address prefixes). Level 2 ISs compute next-hop forwarding
    information to all advertised address prefixes. Level 2 routing is
    determined by the longest advertised address prefix that matches the
    destination address.
    
    
    At routing domain boundaries, address prefix information is exchanged
    (statically or dynamically) with other routing domains. If area
    addresses within a routing domain are all drawn from distinct NSAP
    assignment authorities (allowing no abstraction), then the boundary
    prefix information consists of an enumerated list of all area
    addresses.
    
    
    Alternatively, should the routing domain ``own'' an address prefix
    and assign area addresses based upon it, boundary routing information
    can be summarized into the single prefix. This can allow substantial
    data reduction and, therefore, will allow much better scaling (as
    compared to the uncoordinated area addresses discussed in the previous
    paragraph).
    
    
    If routing domains are interconnected in a more-or-less random (non-
    hierarchical) scheme, it is quite likely that no further abstraction
    of routing data can occur. Since routing domains would have no defined
    hierarchical relationship, administrators would not be able to assign
    area addresses out of some common prefix for the purpose of data
    abstraction. The result would be flat inter-domain routing; all
    routing domains would need explicit knowledge of all other routing
    domains that they route to. This can work well in small- and medium-
    sized internets, up to a size somewhat larger than the current IP
    Internet. However, this does not scale to very large internets. For
    example, we expect growth in the future to an international Internet
    which has tens or hundreds of thousands of routing domains in the U.S.
    alone. This requires a greater degree of data abstraction beyond that
    which can be achieved at the ``routing domain'' level.
    
    
    In the Internet, however, it should be possible to exploit the
    existing hierarchical routing structure interconnections, as discussed
    in Section 5. Thus, there is the opportunity for a group of routing
    domains each to be assigned an address prefix from a shorter prefix
    assigned to another routing domain whose function is to interconnect
    the group of routing domains. Each member of the group of routing
    
    
    
    
    Colella, Gardner, & Callon                                    [Page 14]
    
    
    
    
    
    RFC 1237  Guidelines for OSI NSAP Allocation in the Internet  July 1991
    
    
    
    domains now ``owns'' its (somewhat longer) prefix, from which it
    assigns its area addresses.
    
    
    The most straightforward case of this occurs when there is a set
    of routing domains which are all attached only to a single regional
    (or backbone) domain, and which use that regional for all external
    (inter-domain) traffic. A small address prefix may be assigned to
    the regional, which then assigns slightly longer prefixes (based
    on the regional's prefix) to each of the routing domains that it
    interconnects. This allows the regional, when informing other
    routing domains of the addresses that it can reach, to abbreviate
    the reachability information for a large number of routing domains
    as a single prefix. This approach therefore can allow a great deal
    of hierarchical abbreviation of routing information, and thereby can
    greatly improve the scalability of inter-domain routing.
    
    
    Clearly, this approach is recursive and can be carried through several
    iterations. Routing domains at any ``level'' in the hierarchy may
    use their prefix as the basis for subsequent suballocations, assuming
    that the NSAP addresses remain within the overall length and structure
    constraints. The GOSIP Version 2 NSAP structure, discussed later in
    this section, allows for multiple levels of routing hierarchy.
    
    
    At this point, we observe that the number of nodes at each lower
    level of a hierarchy tends to grow exponentially. Thus the greatest
    gains in data abstraction occur at the leaves and the gains drop
    significantly at each higher level. Therefore, the law of diminishing
    returns suggests that at some point data abstraction ceases to
    produce significant benefits. Determination of the point at which data
    abstraction ceases to be of benefit requires a careful consideration
    of the number of routing domains that are expected to occur at each
    level of the hierarchy (over a given period of time), compared to the
    number of routing domains and address prefixes that can conveniently
    and efficiently be handled via dynamic inter-domain routing protocols.
    
    
    There is a balance that must be sought between the requirements
    on NSAPs for efficient routing and the need for decentralized NSAP
    administration. The NSAP structure from Version 2 of GOSIP (Figure 2)
    offers an example of how these two needs might be met. The AFI,
    IDI, DFI, and AA fields provide for administrative decentralization.
    The AFI/IDI pair of values 47/0005 identify the U.S. government
    as the authority responsible for defining the DSP structure and
    allocating values within it (see Appendix A for more information on
    NSAP structure).
    
    
    
    Colella, Gardner, & Callon                                    [Page 15]
    
    
    
    
    
    RFC 1237  Guidelines for OSI NSAP Allocation in the Internet  July 1991
    
    
    
        [Note: It is not important that NSAPs be allocated from the
        GOSIP Version 2 authority under 47/0005. The ANSI format under
        the Data Country Code for the U.S. (DCC=840) and formats
        assigned to other countries and ISO members or liaison
        organizations are also expected to be used, and will work
        equally well. For parts of the Internet outside of the U.S.
        there may in some cases be strong reasons to prefer a local
        format rather than the GOSIP format. However, GOSIP addresses
        are used in most cases in the examples in this paper because:
    
          * The DSP format has been defined and allows hierarchical
            allocation; and,
    
          * An operational registration authority for suballocation of
            AA values under the GOSIP address space has already been
            established at GSA.]
    
    
    
    GOSIP Version 2 defines the DSP structure as shown (under DFI=80h) and
    provides for the allocation of AA values to administrations. Thus, the
    fields from the AFI to the AA, inclusive, represent a unique address
    prefix assigned to an administration.
    
                    _______________
                    !<--__IDP_-->_!___________________________________
                    !AFI_!__IDI___!___________<--_DSP_-->____________!
                    !_47_!__0005__!DFI_!AA_!Rsvd_!_RD_!Area_!ID_!Sel_!
             octets !_1__!___2____!_1__!_3_!__2__!_2__!_2___!_6_!_1__!
    
    
                      IDP   Initial Domain Part
                      AFI   Authority and Format Identifier
                      IDI   Initial Domain Identifier
                      DSP   Domain Specific Part
                      DFI   DSP Format Identifier
                      AA    Administrative Authority
                      Rsvd  Reserved
                      RD    Routing Domain Identifier
                      Area  Area Identifier
                      ID    System Identifier
                      SEL   NSAP Selector
    
                    Figure 2: GOSIP Version 2 NSAP structure.
    
    
    Currently, a proposal is being progressed in ANSI for an American
    National Standard (ANS) for the DSP of the NSAP address space
    
    
    
    Colella, Gardner, & Callon                                    [Page 16]
    
    
    
    
    
    RFC 1237  Guidelines for OSI NSAP Allocation in the Internet  July 1991
    
    
    
    administered by ANSI. This will provide an identical DSP structure
    to that provided by GOSIP Version 2. The ANSI format, therefore,
    differs from that illustrated above only in that the IDP is based
    on an ISO DCC assignment, and in that the AA will be administered
    by a different organization (ANSI secretariat instead of GSA).
    The technical considerations applicable to NSAP administration are
    independent of whether a GOSIP Version 2 or an ANSI value is used for
    the NSAP assignment.
    
    
    Similarly, although other countries may make use of slightly different
    NSAP formats, the principles of NSAP assignment and use are the same.
    
    
    In the low-order part of the GOSIP Version 2 NSAP format, two
    fields are defined in addition to those required by DIS10589. These
    fields, RD and Area, are defined to allow allocation of NSAPs along
    topological boundaries in support of increased data abstraction.
    Administrations assign RD identifiers underneath their unique address
    prefix (the reserved field is left to accommodate future growth and
    to provide additional flexibility for inter-domain routing). Routing
    domains allocate Area identifiers from their unique prefix. The result
    is:
    
    
       * AFI+IDI+DFI+AA = administration prefix,
    
       * administration prefix(+Rsvd)+RD = routing domain prefix, and,
    
       * routing domain prefix+Area = area address.
    
    
    
    This provides for summarization of all area addresses within a routing
    domain into one prefix. If the AA identifier is accorded topological
    significance (in addition to administrative significance), an
    additional level of data abstraction can be obtained, as is discussed
    in the next section.
    
    
    
    5   NSAP Administration and Routing in the Internet
    
    
    Internet routing components---backbones, regionals, and sites
    or campuses---are arranged hierarchically for the most part. A
    natural mapping from these components to OSI routing components
    is that backbones, regionals, and sites act as routing domains.
    
    
    
    Colella, Gardner, & Callon                                    [Page 17]
    
    
    
    
    
    RFC 1237  Guidelines for OSI NSAP Allocation in the Internet  July 1991
    
    
    
    (Alternatively, a site may choose to operate as an area within a
    regional. However, in such a case the area is part of the regional's
    routing domain and the discussion in Section 5.1 applies. We assume
    that some, if not most, sites will prefer to operate as routing
    domains. By operating as a routing domain, a site operates a level 2
    subdomain as well as one or more level 1 areas.)
    
    
    Given such a mapping, where should address administration and alloca-
    tion be performed to satisfy both administrative decentralization and
    data abstraction? Three possibilities are considered:
    
      1. at the area,
    
      2. at the leaf routing domain, and,
    
      3. at the transit routing domain (TRD).
    
    Leaf routing domains correspond to sites, where the primary purpose is
    to provide intra-domain routing services. Transit routing domains are
    deployed to carry transit (i.e., inter-domain) traffic; backbones and
    regionals are TRDs.
    
    
    The greatest burden in transmitting and operating on routing informa-
    tion is at the top of the routing hierarchy, where routing information
    tends to accumulate. In the Internet, for example, regionals must man-
    age the set of network numbers for all networks reachable through the
    regional. Traffic destined for other networks is generally routed to
    the backbone. The backbones, however, must be cognizant of the network
    numbers for all attached regionals and their associated networks.
    
    
    In general, the advantage of abstracting routing information at a
    given level of the routing hierarchy is greater at the higher levels
    of the hierarchy. There is relatively little direct benefit to the
    administration that performs the abstraction, since it must maintain
    routing information individually on each attached topological routing
    structure.
    
    
    For example, suppose that a given site is trying to decide whether
    to obtain an NSAP address prefix based on an AA value from GSA
    (implying that the first four octets of the address would be those
    assigned out of the GOSIP space), or based on an RD value from its
    regional (implying that the first seven octets of the address are
    those assigned to that regional). If considering only their own
    
    
    
    
    Colella, Gardner, & Callon                                    [Page 18]
    
    
    
    
    
    RFC 1237  Guidelines for OSI NSAP Allocation in the Internet  July 1991
    
    
    
    self-interest, the site itself, and the attached regional, have
    little reason to choose one approach or the other. The site must use
    one prefix or another; the source of the prefix has little effect
    on routing efficiency within the site. The regional must maintain
    information about each attached site in order to route, regardless of
    any commonality in the prefixes of the sites.
    
    
    However, there is a difference when the regional distributes routing
    information to backbones and other regionals. In the first case, the
    regional cannot aggregate the site's address into its own prefix;
    the address must be explicitly listed in routing exchanges, resulting
    in an additional burden to backbones and other regionals which must
    exchange and maintain this information.
    
    
    In the second case, each other regional and backbone sees a single
    address prefix for the regional, which encompasses the new site. This
    avoids the exchange of additional routing information to identify the
    new site's address prefix. Thus, the advantages primarily accrue to
    other regionals and backbones which maintain routing information about
    this site and regional.
    
    
    One might apply a supplier/consumer model to this problem: the higher
    level (e.g., a backbone) is a supplier of routing services, while
    the lower level (e.g., an attached regional) is the consumer of these
    services. The price charged for services is based upon the cost of
    providing them. The overhead of managing a large table of addresses
    for routing to an attached topological entity contributes to this
    cost.
    
    
    The Internet, however, is not a market economy. Rather, efficient
    operation is based on cooperation. The guidelines discussed below
    describe reasonable ways of managing the OSI address space that
    benefit the entire community.
    
    
    
    5.1   Administration at the Area
    
    
    If areas take their area addresses from a myriad of unrelated NSAP
    allocation authorities, there will be effectively no data abstraction
    beyond what is built into DIS10589. For example, assume that within a
    routing domain three areas take their area addresses, respectively,
    out of:
    
    
    
    Colella, Gardner, & Callon                                    [Page 19]
    
    
    
    
    
    RFC 1237  Guidelines for OSI NSAP Allocation in the Internet  July 1991
    
    
    
       * the GOSIP Version 2 authority assigned to the Department of
         Commerce, with an AA of nnn:
    
                      AFI=47, IDI=0005, DFI=80h, AA=nnn, ... ;
    
       * the GOSIP Version 2 authority assigned to the Department of the
         Interior, with an AA of mmm:
    
                    AFI=47, IDI=0005, DFI=80h, AA=mmm, ... ; and,
    
       * the ANSI authority under the U.S. Data Country Code (DCC) (Section
         A.2) for organization XYZ with ORG identifier = xxx:
    
                       AFI=39, IDI=840, DFI=dd, ORG=xxx, ....
    
    
    As described in Section 3.3, from the point of view of any particular
    routing domain, there is no harm in having the different areas in
    the routing domain use addresses obtained from a wide variety of
    administrations. For routing within the domain, the area addresses are
    treated as a flat field.
    
    
    However, this does have a negative effect on inter-domain routing,
    particularly on those other domains which need to maintain routes to
    this domain. There is no common prefix that can be used to represent
    these NSAPs and therefore no summarization can take place at the
    routing domain boundary. When addresses are advertised by this routing
    domain to other routing domains, an enumerated list must be used
    consisting of the three area addresses.
    
    
    This situation is roughly analogous to the dissemination of routing
    information in the TCP/IP Internet. Areas correspond roughly to
    networks and area addresses to network numbers. The result of allowing
    areas within a routing domain to take their NSAPs from unrelated
    authorities is flat routing at the area address level. The number
    of address prefixes that leaf routing domains would advertise is on
    the order of the number of attached areas; the number of prefixes a
    regional routing domain would advertise is approximately the number of
    areas attached to the client leaf routing domains; and for a backbone
    this would be summed across all attached regionals. Although this
    situation is just barely acceptable in the current Internet, as the
    Internet grows this will quickly become intractable. A greater degree
    of hierarchical information reduction is necessary to allow continued
    growth in the Internet.
    
    
    
    
    
    Colella, Gardner, & Callon                                    [Page 20]
    
    
    
    
    
    RFC 1237  Guidelines for OSI NSAP Allocation in the Internet  July 1991
    
    
    
    5.2   Administration at the Leaf Routing Domain
    
    
    
    As mentioned previously, the greatest degree of data abstraction comes
    at the lowest levels of the hierarchy. Providing each leaf routing
    domain (that is, site) with a unique prefix results in the biggest
    single increase in abstraction, with each leaf domain assigning area
    addresses from its prefix. From outside the leaf routing domain, the
    set of all addresses reachable in the domain can then be represented
    by a single prefix.
    
    
    As an example, assume NSF has been assigned the AA value of zzz
    under ICD=0005. NSF then assigns a routing domain identifier to a
    routing domain under its administrative authority identifier, rrr. The
    resulting prefix for the routing domain is:
    
    
               AFI=47, IDI=0005, DFI=80h, AA=zzz, Rsvd=0, RD=rrr.
    
    
    All areas attached to this routing domain would have area addresses
    comprising this prefix followed by an Area identifier. The prefix
    represents the summary of reachable addresses within the routing
    domain.
    
    
    There is a close relationship between areas and routing domains
    implicit in the fact that they operate a common routing protocol and
    are under the control of a single administration. The routing domain
    administration subdivides the domain into areas and structures a level
    2 subdomain (i.e., a level 2 backbone) which provides connectivity
    among the areas. The routing domain represents the only path between
    an area and the rest of the internetwork. It is reasonable that
    this relationship also extend to include a common NSAP addressing
    authority. Thus, the areas within the leaf RD should take their NSAPs
    from the prefix assigned to the leaf RD.
    
    
    
    5.3   Administration at the Transit Routing Domain
    
    
    
    Two kinds of transit routing domains are considered, backbones and
    regionals. Each is discussed separately below.
    
    
    
    
    Colella, Gardner, & Callon                                    [Page 21]
    
    
    
    
    
    RFC 1237  Guidelines for OSI NSAP Allocation in the Internet  July 1991
    
    
    
    5.3.1   Regionals
    
    
    
    It is interesting to consider whether regional routing domains should
    be the common authority for assigning NSAPs from a unique prefix to
    the leaf routing domains that they serve. The benefits derived from
    data abstraction are less than in the case of leaf routing domains,
    and the additional degree of data abstraction provided by this is
    not necessary in the short term. However, in the long term the number
    of routing domains in the Internet will grow to the point that it
    will be infeasible to route on the basis of a flat field of routing
    domains. It will therefore be essential to provide a greater degree of
    information abstraction.
    
    
    Regionals may assign prefixes to leaf domains, based on a single
    (shorter length) address prefix assigned to the regional. For example,
    given the GOSIP Version 2 address structure, an AA value may be
    assigned to each regional, and routing domain values may be assigned
    by the regional to each attached leaf routing domain. A similar
    hierarchical address assignment based on a prefix assigned to each
    regional may be used for other NSAP formats. This results in regionals
    advertising to backbones a small fraction of the number of address
    prefixes that would be necessary if they enumerated the individual
    prefixes of the leaf routing domains. This represents a significant
    savings given the expected scale of global internetworking.
    
    
    Are leaf routing domains willing to accept prefixes derived from
    the regional's? In the supplier/consumer model, the regional is
    offering connectivity as the service, priced according to its costs
    of operation. This includes the ``price'' of obtaining service from
    one or more backbones. In general, backbones will want to handle as
    few address prefixes as possible to keep costs low. In the Internet
    environment, which does not operate as a typical marketplace, leaf
    routing domains must be sensitive to the resource constraints of the
    regionals and backbones. The efficiencies gained in routing clearly
    warrant the adoption of NSAP administration by the regionals.
    
    
    The mechanics of this scenario are straightforward. Each regional
    is assigned a unique prefix, from which it allocates slightly longer
    routing domain prefixes for its attached leaf routing domains.
    For GOSIP NSAPs, this means that a regional would be assigned an
    AA identifier. Attached leaf routing domains would be assigned RD
    identifiers under the regional's unique prefix. For example, assume
    
    
    
    
    Colella, Gardner, & Callon                                    [Page 22]
    
    
    
    
    
    RFC 1237  Guidelines for OSI NSAP Allocation in the Internet  July 1991
    
    
    
    NIST is a leaf routing domain whose sole inter-domain link is via
    SURANet. If SURANet is assigned an AA identifier kkk, NIST could be
    assigned an RD of jjj, resulting in a unique prefix for SURANet of:
    
    
                        AFI=47, IDI=0005, DFI=80h, AA=kkk
    
    
    and a unique prefix for NIST of
    
    
              AFI=47, IDI=0005, DFI=80h, AA=kkk, (Rsvd=0), RD=jjj.
    
    
    A similar scheme can be established using NSAPs allocated under
    DCC=840. In this case, a regional applies for an ORG identifier from
    ANSI, which serves the same purpose as the AA identifier in GOSIP.
    The current direction in ANSI is to standardize on an NSAP structure
    identical to GOSIP Version 2 (see Section A.2).
    
    
    
    5.3.2   Backbones
    
    
    
    There does not appear to be a strong case for regionals to take their
    address spaces from the the NSAP space of a backbone. The benefit in
    routing data abstraction is relatively small. The number of regionals
    today is in the tens and an order of magnitude increase would not
    cause an undue burden on the backbones. Also, it may be expected that
    as time goes by there will be increased direct interconnection of the
    regionals, leaf routing domains directly attached to the backbones,
    and international links directly attached to the regionals. Under
    these circumstances, the distinction between regionals and backbones
    may become blurred.
    
    
    An additional factor that discourages allocation of NSAPs from a
    backbone prefix is that the backbones and their attached regionals are
    perceived as being independent. Regionals may take their long-haul
    service from one or more backbones, or may switch backbones should
    a more cost-effective service be provided elsewhere (essentially,
    backbones can be thought of the same way as long-distance telephone
    carriers). Having NSAPs derived from the backbone is inconsistent with
    the nature of the relationship.
    
    
    
    
    
    Colella, Gardner, & Callon                                    [Page 23]
    
    
    
    
    
    RFC 1237  Guidelines for OSI NSAP Allocation in the Internet  July 1991
    
    
    
    5.4   Multi-homed Routing Domains
    
    
    
    The discussions in Section 5.3 suggest methods for allocating NSAP
    addresses based on regional or backbone connectivity. This allows a
    great deal of information reduction to be achieved for those routing
    domains which are attached to a single TRD. In particular, such
    routing domains may select their NSAP addresses from a space allocated
    to them by the regional. This allows the regional, when announcing the
    addresses that it can reach to other regionals and backbones, to use
    a single address prefix to describe a large number of NSAP addresses
    corresponding to multiple routing domains.
    
    
    However, there are additional considerations for routing domains
    which are attached to multiple regionals and backbones. Such ``multi-
    homed'' routing domains may, for example, consist of single-site
    campuses and companies which are attached to multiple backbones, large
    organizations which are attached to different regionals at different
    locations in the same country, or multi-national organizations which
    are attached to backbones in a variety of countries worldwide. There
    are a number of possible ways to deal with these multi-homed routing
    domains.
    
    
    One possible solution is to assign addresses to each multi-homed
    organization independently from the regionals and backbones to which
    it is attached. This allows each multi-homed organization to base its
    NSAP assignments on a single prefix, and to thereby summarize the set
    of all NSAPs reachable within that organization via a single prefix.
    The disadvantage of this approach is that since the NSAP address
    for that organization has no relationship to the addresses of any
    particular TRD, the TRDs to which this organization is attached will
    need to advertise the prefix for this organization to other regionals
    and backbones. Other regionals and backbones (potentially worldwide)
    will need to maintain an explicit entry for that organization in their
    routing tables.
    
    
    For example, suppose that a very large U.S.-wide company ``Mega
    Big International Incorporated'' (MBII) has a fully interconnected
    internal network and is assigned a single AA value under the U.S.
    GOSIP Version 2 address space. It is likely that outside of the U.S.,
    a single entry may be maintained in routing tables for all U.S. GOSIP
    addresses. However, within the U.S., every backbone and regional
    will need to maintain a separate address entry for MBII. If MBII
    
    
    
    
    Colella, Gardner, & Callon                                    [Page 24]
    
    
    
    
    
    RFC 1237  Guidelines for OSI NSAP Allocation in the Internet  July 1991
    
    
    
    is in fact an international corporation, then it may be necessary
    for every backbone worldwide to maintain a separate entry for MBII
    (including backbones to which MBII is not attached). Clearly this
    may be acceptable if there are a small number of such multi-homed
    routing domains, but would place an unacceptable load on routers
    within backbones if all organizations were to choose such address
    assignments. This solution may not scale to internets where there are
    many hundreds of thousands of multi-homed organizations.
    
    
    A second possible approach would be for multi-homed organizations to
    be assigned a separate NSAP space for each connection to a TRD, and
    to assign a single address prefix to each area within its routing
    domain(s) based on the closest interconnection point. For example, if
    MBII had connections to two regionals in the U.S. (one east coast, and
    one west coast), as well as three connections to national backbones
    in Europe, and one in the far east, then MBII may make use of six
    different address prefixes. Each area within MBII would be assigned a
    single address prefix based on the nearest connection.
    
    
    For purposes of external routing of traffic from outside MBII to a
    destination inside of MBII, this approach works similarly to treating
    MBII as six separate organizations. For purposes of internal routing,
    or for routing traffic from inside of MBII to a destination outside of
    MBII, this approach works the same as the first solution.
    
    
    If we assume that incoming traffic (coming from outside of MBII, with
    a destination within MBII) is always to enter via the nearest point to
    the destination, then each TRD which has a connection to MBII needs
    to announce to other TRDs the ability to reach only those parts of
    MBII whose address is taken from its own address space. This implies
    that no additional routing information needs to be exchanged between
    TRDs, resulting in a smaller load on the inter-domain routing tables
    maintained by TRDs when compared to the first solution. This solution
    therefore scales better to extremely large internets containing very
    large numbers of multi-homed organizations.
    
    
    One problem with the second solution is that backup routes to multi-
    homed organizations are not automatically maintained. With the first
    solution, each TRD, in announcing the ability to reach MBII, specifies
    that it is able to reach all of the NSAPs within MBII. With the second
    solution, each TRD announces that it can reach all of the NSAPs based
    on its own address prefix, which only includes some of the NSAPs
    within MBII. If the connection between MBII and one particular TRD
    
    
    
    
    Colella, Gardner, & Callon                                    [Page 25]
    
    
    
    
    
    RFC 1237  Guidelines for OSI NSAP Allocation in the Internet  July 1991
    
    
    
    were severed, then the NSAPs within MBII with addresses based on that
    TRD would become unreachable via inter-domain routing. The impact
    of this problem can be reduced somewhat by maintenance of additional
    information within routing tables, but this reduces the scaling
    advantage of the second approach.
    
    
    The second solution also requires that when external connectivity
    changes, internal addresses also change.
    
    
    Also note that this and the previous approach will tend to cause
    packets to take different routes. With the first approach, packets
    from outside of MBII destined for within MBII will tend to enter via
    the point which is closest to the source (which will therefore tend to
    maximize the load on the networks internal to MBII). With the second
    solution, packets from outside destined for within MBII will tend to
    enter via the point which is closest to the destination (which will
    tend to minimize the load on the networks within MBII, and maximize
    the load on the TRDs).
    
    
    These solutions also have different effects on policies. For example,
    suppose that country ``X'' has a law that traffic from a source
    within country X to a destination within country X must at all
    times stay entirely within the country. With the first solution, it
    is not possible to determine from the destination address whether
    or not the destination is within the country. With the second
    solution, a separate address may be assigned to those NSAPs which are
    within country X, thereby allowing routing policies to be followed.
    Similarly, suppose that ``Little Small Company'' (LSC) has a policy
    that its packets may never be sent to a destination that is within
    MBII. With either solution, the routers within LSC may be configured
    to discard any traffic that has a destination within MBII's address
    space. However, with the first solution this requires one entry;
    with the second it requires many entries and may be impossible as a
    practical matter.
    
    
    There are other possible solutions as well. A third approach is to
    assign each multi-homed organization a single address prefix, based on
    one of its connections to a TRD. Other TRDs to which the multi-homed
    organization are attached maintain a routing table entry for the
    organization, but are extremely selective in terms of which other
    TRDs are told of this route. This approach will produce a single
    ``default'' routing entry which all TRDs will know how to reach
    
    
    
    
    
    Colella, Gardner, & Callon                                    [Page 26]
    
    
    
    
    
    RFC 1237  Guidelines for OSI NSAP Allocation in the Internet  July 1991
    
    
    
    (since presumably all TRDs will maintain routes to each other), while
    providing more direct routing in some cases.
    
    
    There is at least one situation in which this third approach is
    particularly appropriate. Suppose that a special interest group of
    organizations have deployed their own backbone. For example, lets
    suppose that the U.S. National Widget Manufacturers and Researchers
    have set up a U.S.-wide backbone, which is used by corporations
    who manufacture widgets, and certain universities which are known
    for their widget research efforts. We can expect that the various
    organizations which are in the widget group will run their internal
    networks as separate routing domains, and most of them will also
    be attached to other TRDs (since most of the organizations involved
    in widget manufacture and research will also be involved in other
    activities). We can therefore expect that many or most of the
    organizations in the widget group are dual-homed, with one attachment
    for widget-associated communications and the other attachment for
    other types of communications. Let's also assume that the total number
    of organizations involved in the widget group is small enough that
    it is reasonable to maintain a routing table containing one entry
    per organization, but that they are distributed throughout a larger
    internet with many millions of (mostly not widget-associated) routing
    domains.
    
    
    With the third approach, each multi-homed organization in the widget
    group would make use of an address assignment based on its other
    attachment(s) to TRDs (the attachments not associated with the widget
    group). The widget backbone would need to maintain routes to the
    routing domains associated with the various member organizations.
    Similarly, all members of the widget group would need to maintain a
    table of routes to the other members via the widget backbone. However,
    since the widget backbone does not inform other general worldwide TRDs
    of what addresses it can reach (since the backbone is not intended
    for use by other outside organizations), the relatively large set
    of routing prefixes needs to be maintained only in a limited number
    of places. The addresses assigned to the various organizations which
    are members of the widget group would provide a ``default route'' via
    each members other attachments to TRDs, while allowing communications
    within the widget group to use the preferred path.
    
    
    A fourth solution involves assignment of a particular address prefix
    for routing domains which are attached to precisely two (or more)
    specific routing domains. For example, suppose that there are two
    regionals ``SouthNorthNet'' and ``NorthSouthNet'' which have a very
    
    
    
    
    Colella, Gardner, & Callon                                    [Page 27]
    
    
    
    
    
    RFC 1237  Guidelines for OSI NSAP Allocation in the Internet  July 1991
    
    
    
    large number of customers in common (i.e., there are a large number
    of routing domains which are attached to both). Rather than getting
    two address prefixes (such as two AA values assigned under the GOSIP
    address space) these organizations could obtain three prefixes. Those
    routing domains which are attached to NorthSouthNet but not attached
    to SouthNorthNet obtain an address assignment based on one of the
    prefixes. Those routing domains which are attached to SouthNorthNet
    but not to NorthSouthNet would obtain an address based on the second
    prefix. Finally, those routing domains which are multi-homed to both
    of these networks would obtain an address based on the third prefix.
    Each of these two TRDs would then advertise two prefixes to other
    TRDs, one prefix for leaf routing domains attached to it only, and one
    prefix for leaf routing domains attached to both.
    
    
    This fourth solution is likely to be important when use of public data
    networks becomes more common. In particular, it is likely that at some
    point in the future a substantial percentage of all routing domains
    will be attached to public data networks. In this case, nearly all
    government-sponsored networks (such as some current NSFNET regionals)
    may have a set of customers which overlaps substantially with the
    public networks.
    
    
    There are therefore a number of possible solutions to the problem
    of assigning NSAP addresses to multi-homed routing domains. Each
    of these solutions has very different advantages and disadvantages.
    Each solution places a different real (i.e., financial) cost on the
    multi-homed organizations, and on the TRDs (including those to which
    the multi-homed organizations are not attached).
    
    
    In addition, most of the solutions described also highlight the need
    for each TRD to develop policy on whether and under what conditions
    to accept addresses that are not based on its own address prefix, and
    how such non-local addresses will be treated. For example, a somewhat
    conservative policy might be that non-local NSAP prefixes will be
    accepted from any attached leaf RD, but not advertised to other TRDs.
    In a less conservative policy, a TRD might accept such non-local
    prefixes and agree to exchange them with a defined set of other TRDs
    (this set could be an a priori group of TRDs that have something in
    common such as geographical location, or the result of an agreement
    specific to the requesting leaf RD). Various policies involve real
    costs to TRDs, which may be reflected in those policies.
    
    
    
    
    
    
    
    Colella, Gardner, & Callon                                    [Page 28]
    
    
    
    
    
    RFC 1237  Guidelines for OSI NSAP Allocation in the Internet  July 1991
    
    
    
    5.5   Private Links
    
    
    
    The discussion up to this point concentrates on the relationship
    between NSAP addresses and routing between various routing domains
    over transit routing domains, where each transit routing domain
    interconnects a large number of routing domains and offers a more-or-
    less public service.
    
    
    However, there may also exist a large number of private point-to-point
    links which interconnect two private routing domains. In many cases
    such private point-to-point links may be limited to forwarding packets
    directly between the two private routing domains.
    
    
    For example, let's suppose that the XYZ corporation does a lot of
    business with MBII. In this case, XYZ and MBII may contract with a
    carrier to provide a private link between the two corporations, where
    this link may only be used for packets whose source is within one of
    the two corporations, and whose destination is within the other of the
    two corporations. Finally, suppose that the point-to-point link is
    connected between a single router (router X) within XYZ corporation
    and a single router (router M) within MBII. It is therefore necessary
    to configure router X to know which addresses can be reached over
    this link (specifically, all addresses reachable in MBII). Similarly,
    it is necessary to configure router M to know which addresses can be
    reached over this link (specifically, all addresses reachable in XYZ
    Corporation).
    
    
    The important observation to be made here is that such private
    links may be ignored for the purpose of NSAP allocation, and do not
    pose a problem for routing. This is because the routing information
    associated with private links is not propagated throughout the
    internet, and therefore does not need to be collapsed into a TRD's
    prefix.
    
    
    In our example, lets suppose that the XYZ corporation has a single
    connection to an NSFNET regional, and has therefore received an
    address allocation from the space administered by that regional.
    Similarly, let's suppose that MBII, as an international corporation
    with connections to six different backbones or regionals, has chosen
    the second solution from Section 5.4, and therefore has obtained six
    different address allocations. In this case, all addresses reachable
    in the XYZ Corporation can be described by a single address prefix
    
    
    
    Colella, Gardner, & Callon                                    [Page 29]
    
    
    
    
    
    RFC 1237  Guidelines for OSI NSAP Allocation in the Internet  July 1991
    
    
    
    (implying that router M only needs to be configured with a single
    address prefix to represent the addresses reachable over this point-
    to-point link). All addresses reachable in MBII can be described by
    six address prefixes (implying that router X needs to be configured
    with six address prefixes to represent the addresses reachable over
    the point-to-point link).
    
    
    In some cases, such private point-to-point links may be permitted
    to forward traffic for a small number of other routing domains,
    such as closely affiliated organizations. This will increase the
    configuration requirements slightly. However, provided that the number
    of organizations using the link is relatively small, then this still
    does not represent a significant problem.
    
    
    Note that the relationship between routing and NSAP addressing
    described in other sections of this paper is concerned with problems
    in scaling caused by large, essentially public transit routing domains
    which interconnect a large number of routing domains. However, for
    the purpose of NSAP allocation, private point-to-point links which
    interconnect only a small number of private routing domains do not
    pose a problem, and may be ignored. For example, this implies that
    a single leaf routing domain which has a single connection to a
    ``public'' backbone (e.g., the NSFNET), plus a number of private
    point-to-point links to other leaf routing domains, can be treated
    as if it were single-homed to the backbone for the purpose of NSAP
    address allocation.
    
    
    
    5.6   Zero-Homed Routing Domains
    
    
    
    Currently, a very large number of organizations have internal
    communications networks which are not connected to any external
    network. Such organizations may, however, have a number of private
    point-to-point links that they use for communications with other
    organizations. Such organizations do not participate in global
    routing, but are satisfied with reachability to those organizations
    with which they have established private links. These are referred to
    as zero-homed routing domains.
    
    
    Zero-homed routing domains can be considered as the degenerate case
    of routing domains with private links, as discussed in the previous
    section, and do not pose a problem for inter-domain routing. As above,
    
    
    
    Colella, Gardner, & Callon                                    [Page 30]
    
    
    
    
    
    RFC 1237  Guidelines for OSI NSAP Allocation in the Internet  July 1991
    
    
    
    the routing information exchanged across the private links sees very
    limited distribution, usually only to the RD at the other end of the
    link. Thus, there are no address abstraction requirements beyond those
    inherent in the address prefixes exchanged across the private link.
    
    
    However, it is important that zero-homed routing domains use valid
    globally unique NSAP addresses. Suppose that the zero-homed routing
    domain is connected through a private link to an RD. Further, this
    RD participates in an internet that subscribes to the global OSI
    addressing plan (i.e., Addendum 2 to ISO8348). This RD must be able
    to distinguish between the zero-homed routing domain's NSAPs and any
    other NSAPs that it may need to route to. The only way this can be
    guaranteed is if the zero-homed routing domain uses globally unique
    NSAPs.
    
    
    
    5.7   Transition Issues
    
    
    
    Allocation of NSAP addresses based on connectivity to TRDs is
    important to allow scaling of inter-domain routing to an internet
    containing millions of routing domains. However, such address
    allocation based on topology also implies that a change in topology
    may result in a change of address.
    
    
    This need to allow for change in addresses is a natural, inevitable
    consequence of routing data abstraction. The basic notion of routing
    data abstraction is that there is some correspondence between the
    address and where a system (i.e., a routing domain, area, or end
    system) is located. Thus if the system moves, in some cases the
    address will have to change. If it were possible to change the
    connectivity between routing domains without changing the addresses,
    then it would clearly be necessary to keep track of the location of
    that routing domain on an individual basis.
    
    
    In the short term, due to the rapid growth and increased commer-
    cialization of the Internet, it is possible that the topology may be
    relatively volatile. This implies that planning for address transition
    is very important. Fortunately, there are a number of steps which can
    be taken to help ease the effort required for address transition. A
    complete description of address transition issues is outside of the
    scope of this paper. However, a very brief outline of some transition
    issues is contained in this section.
    
    
    
    Colella, Gardner, & Callon                                    [Page 31]
    
    
    
    
    
    RFC 1237  Guidelines for OSI NSAP Allocation in the Internet  July 1991
    
    
    
    Also note that the possible requirement to transition addresses
    based on changes in topology imply that it is valuable to anticipate
    the future topology changes before finalizing a plan for address
    allocation. For example, in the case of a routing domain which is
    initially single-homed, but which is expecting to become multi-homed
    in the future, it may be advantageous to assign NSAP addresses based
    on the anticipated future topology.
    
    
    In general, it will not be practical to transition the NSAP addresses
    assigned to a routing domain in an instantaneous ``change the address
    at midnight'' manner. Instead, a gradual transition is required in
    which both the old and the new addresses will remain valid for a
    limited period of time. During the transition period, both the old and
    new addresses are accepted by the end systems in the routing domain,
    and both old and new addresses must result in correct routing of
    packets to the destination.
    
    
    Provision for transition has already been built into DIS10589.
    As described in Section 3, DIS10589 allows multiple addresses to
    be assigned to each area specifically for the purpose of easing
    transition.
    
    
    Similarly, there are provisions in OSI for the autoconfiguration of
    area addresses. This allows OSI end systems to find out their area
    addresses automatically by observing the ISO9542 IS-Hello packets
    transmitted by routers. If the ID portion of the address is assigned
    by using IEEE style ``stamped in PROM at birth'' identifiers, then
    an end system can reconfigure its entire NSAP address automatically
    without the need for manual intervention. However, routers will still
    need manual address reconfiguration.
    
    
    During the transition period, it is important that packets using
    the old address be forwarded correctly, even when the topology has
    changed. This is facilitated by the use of ``best match'' inter-domain
    routing.
    
    
    For example, suppose that the XYZ Corporation was previously connected
    only to the NorthSouthNet NSFNET regional. The XYZ Corporation
    therefore went off to the NorthSouthNet administration and got a
    routing domain assignment based on the AA value assigned to the
    NorthSouthNet regional under the GOSIP address space. However, for
    a variety of reasons, the XYZ Corporation decided to terminate its
    association with the NorthSouthNet, and instead connect directly to
    
    
    
    Colella, Gardner, & Callon                                    [Page 32]
    
    
    
    
    
    RFC 1237  Guidelines for OSI NSAP Allocation in the Internet  July 1991
    
    
    
    the NewCommercialNet public data network. Thus the XYZ Corporation
    now has a new address assignment under the ANSI address assigned to
    the NewCommercialNet. The old address for the XYZ Corporation would
    seem to imply that traffic for the XYZ Corporation should be routed to
    the NorthSouthNet, which no longer has any direct connection with XYZ
    Corporation.
    
    
    If the old TRD (NorthSouthNet) and the new TRD (NewCommercialNet) are
    adjacent and cooperative, then this transition is easy to accomplish.
    In this case, packets routed to the XYZ Corporation using the old
    address assignment could be routed to the NorthSouthNet, which would
    directly forward them to the NewCommercialNet, which would in turn
    forward them to XYZ Corporation. In this case only NorthSouthNet
    and NewCommercialNet need be aware of the fact that the old address
    refers to a destination which is no longer directly attached to
    NorthSouthNet.
    
    
    If the old TRD and the new TRD are not adjacent, then the situation
    is a bit more complex, but there are still several possible ways to
    forward traffic correctly.
    
    
    If the old TRD and the new TRD are themselves connected by other
    cooperative transit routing domains, then these intermediate domains
    may agree to forward traffic for XYZ correctly. For example, suppose
    that NorthSouthNet and NewCommercialNet are not directly connected,
    but that they are both directly connected to the NSFNET backbone.
    In this case, all three of NorthSouthNet, NewCommercialNet, and
    the NSFNET backbone would need to maintain a special entry for XYZ
    corporation so that traffic to XYZ using the old address allocation
    would be forwarded via NewCommercialNet. However, other routing
    domains would not need to be aware of the new location for XYZ
    Corporation.
    
    
    Suppose that the old TRD and the new TRD are separated by a non-
    cooperative routing domain, or by a long path of routing domains. In
    this case, the old TRD could encapsulate traffic to XYZ Corporation in
    order to deliver such packets to the correct backbone.
    
    
    Also, those locations which do a significant amount of business with
    XYZ Corporation could have a specific entry in their routing tables
    added to ensure optimal routing of packets to XYZ. For example,
    suppose that another commercial backbone ``OldCommercialNet'' has a
    large number of customers which exchange traffic with XYZ Corporation,
    
    
    
    Colella, Gardner, & Callon                                    [Page 33]
    
    
    
    
    
    RFC 1237  Guidelines for OSI NSAP Allocation in the Internet  July 1991
    
    
    
    and that this third TRD is directly connected to both NorthSouthNet
    and NewCommercialNet. In this case OldCommercialNet will continue
    to have a single entry in its routing tables for other traffic
    destined for NorthSouthNet, but may choose to add one additional (more
    specific) entry to ensure that packets sent to XYZ Corporation's old
    address are routed correctly.
    
    
    Whichever method is used to ease address transition, the goal is that
    knowledge relating XYZ to its old address that is held throughout the
    global internet would eventually be replaced with the new information.
    It is reasonable to expect this to take weeks or months and will be
    accomplished through the distributed directory system. Discussion of
    the directory, along with other address transition techniques such as
    automatically informing the source of a changed address, are outside
    the scope of this paper.
    
    
    
    6   Recommendations
    
    
    
    We anticipate that the current exponential growth of the Internet will
    continue or accelerate for the foreseeable future. In addition, we
    anticipate a rapid internationalization of the Internet. The ability
    of routing to scale is dependent upon the use of data abstraction
    based on hierarchical NSAP addresses. As OSI is introduced in the
    Internet, it is therefore essential to choose a hierarchical structure
    for NSAP addresses with great care.
    
    
    It is in the best interests of the internetworking community that the
    cost of operations be kept to a minimum where possible. In the case of
    NSAP allocation, this again means that routing data abstraction must
    be encouraged.
    
    
    In order for data abstraction to be possible, the assignment of NSAP
    addresses must be accomplished in a manner which is consistent with
    the actual physical topology of the Internet. For example, in those
    cases where organizational and administrative boundaries are not
    related to actual network topology, address assignment based on such
    organization boundaries is not recommended.
    
    
    The intra-domain IS-IS routing protocol allows for information
    abstraction to be maintained at two levels: systems are grouped
    
    
    
    Colella, Gardner, & Callon                                    [Page 34]
    
    
    
    
    
    RFC 1237  Guidelines for OSI NSAP Allocation in the Internet  July 1991
    
    
    
    into areas, and areas are interconnected to form a routing domain.
    For zero-homed and single-homed routing domains (which are expected
    to remain zero-homed or single-homed), we recommend that the NSAP
    addresses assigned for OSI use within a single routing domain use
    a single address prefix assigned to that domain. Specifically, this
    allows the set of all NSAP addresses reachable within a single domain
    to be fully described via a single prefix.
    
    
    We anticipate that the total number of routing domains existing on a
    worldwide OSI Internet to be great enough that additional levels of
    hierarchical data abstraction beyond the routing domain level will be
    necessary.
    
    
    In most cases, network topology will have a close relationship with
    national boundaries. For example, the degree of network connectivity
    will often be greater within a single country than between countries.
    It is therefore appropriate to make specific recommendations based on
    national boundaries, with the understanding that there may be specific
    situations where these general recommendations need to be modified.
    
    
    
    6.1   Recommendations Specific to U.S. Parts of the Internet
    
    
    
    NSAP addresses for use within the U.S. portion of the Internet are
    expected to be based primarily on two address prefixes: the IDP format
    used by NIST for GOSIP Version 2, and the DCC=840 format defined by
    ANSI.
    
    
    We anticipate that, in the U.S., public interconnectivity between
    private routing domains will be provided by a diverse set of TRDs,
    including (but not necessarily limited to):
    
       * the NSFNET backbone;
    
       * a number of NSFNET regional networks; and,
    
       * a number of commercial Public Data Networks.
    
    It is also expected that these networks will not be interconnected
    in a strictly hierarchical manner (for example, there is expected
    to be direct connectivity between NSFNET regionals, and all three of
    these types of networks may have direct international connections).
    
    
    
    Colella, Gardner, & Callon                                    [Page 35]
    
    
    
    
    
    RFC 1237  Guidelines for OSI NSAP Allocation in the Internet  July 1991
    
    
    
    However, the total number of such TRDs is expected to remain (for the
    foreseeable future) small enough to allow addressing of this set of
    TRDs via a flat address space. These TRDs will be used to interconnect
    a wide variety of routing domains, each of which may comprise a single
    corporation, part of a corporation, a university campus, a government
    agency, or other organizational unit.
    
    
    In addition, some private corporations may be expected to make use of
    dedicated private TRDs for communication within their own corporation.
    
    
    We anticipate that the great majority of routing domains will be
    attached to only one of the TRDs. This will permit hierarchical
    address abbreviation based on TRD. We therefore strongly recommend
    that addresses be assigned hierarchically, based on address prefixes
    assigned to individual TRDs.
    
    
    For the GOSIP address format, this implies that Administrative
    Authority (AA) identifiers should be assigned to all TRDs (explicitly
    including the NSFNET backbone, the NSFNET regionals, and other major
    government backbones). For those leaf routing domains which are
    connected to a single TRD, they should be assigned a Routing Domain
    (RD) value from the space assigned to that TRD.
    
    
    We recommend that all TRDs explicitly be involved in the task of
    address administration for those leaf routing domains which are
    single-homed to them. This will offer a valuable service to their
    customers, and will also greatly reduce the resources (including
    human and network resources) necessary for that TRD to take part in
    inter-domain routing.
    
    
    Each TRD should develop policy on whether and under what conditions to
    accept addresses that are not based on its own address prefix, and how
    such non-local addresses will be treated. Policies should reflect the
    issue of cost associated with implementing such policies.
    
    
    We recommend that a similar hierarchical model be used for NSAP
    addresses using the DCC-based address format. The structure for
    DCC=840-based NSAPs is provided in Section A.2.
    
    
    For routing domains which are not attached to any publically-
    available TRD, there is not the same urgent need for hierarchical
    address abbreviation. We do not, therefore, make any additional
    recommendations for such ``isolated'' routing domains, except to
    
    Colella, Gardner, & Callon                                    [Page 36]
    
    
    
    
    
    RFC 1237  Guidelines for OSI NSAP Allocation in the Internet  July 1991
    
    
    
    note that there is no technical reason to preclude assignment of
    GOSIP AA identifier values or ANSI organization identifiers to such
    domains. Where such domains are connected to other domains by private
    point-to-point links, and where such links are used solely for routing
    between the two domains that they interconnect, again no additional
    technical problems relating to address abbreviation is caused by such
    a link, and no specific additional recommendations are necessary.
    
    
    
    6.2   Recommendations Specific to Non-U.S. Parts of the Internet
    
    
    
    For the part of the Internet which is outside of the U.S., it is
    recommended that the DSP format be structured similarly to that
    specified within GOSIP Version 2 no matter whether the addresses are
    based on DCC or ICD format.
    
    
    Further, in order to allow aggregation of NSAPs at national boundaries
    into as few prefixes as possible, we further recommend that NSAPs
    allocated to routing domains should be assigned based on each routing
    domain's connectivity to a national Internet backbone.
    
    
    
    6.3   Recommendations for Multi-Homed Routing Domains
    
    
    
    Some routing domains will be attached to multiple TRDs within the
    same country, or to TRDs within multiple different countries. We
    refer to these as ``multi-homed'' routing domains. Clearly the strict
    hierarchical model discussed above does not neatly handle such routing
    domains.
    
    
    There are several possible ways that these multi-homed routing domains
    may be handled. Each of these methods vary with respect to the amount
    of information that must be maintained for inter-domain routing
    and also with respect to the inter-domain routes. In addition, the
    organization that will bear the brunt of this cost varies with the
    possible solutions. For example, the solutions vary with respect to:
    
       * resources used within routers within the TRDs;
    
       * administrative cost on TRD personnel; and,
    
    
    
    Colella, Gardner, & Callon                                    [Page 37]
    
    
    
    
    
    RFC 1237  Guidelines for OSI NSAP Allocation in the Internet  July 1991
    
    
    
       * difficulty of configuration of policy-based inter-domain routing
         information within leaf routing domains.
    
    
    Also, the solution used may affect the actual routes which packets
    follow, and may effect the availability of backup routes when the
    primary route fails.
    
    
    For these reasons it is not possible to mandate a single solution for
    all situations. Rather, economic considerations will require a variety
    of solutions for different routing domains, regionals, and backbones.
    
    
    
    7   Security Considerations
    
    
    
    Security issues are not discussed in this memo.
    
    
    
    
    
    
    
    
    
    
    
    
    
    
    
    
    
    
    
    
    
    
    
    
    
    
    
    
    
    
    
    Colella, Gardner, & Callon                                    [Page 38]
    
    
    
    
    
    RFC 1237  Guidelines for OSI NSAP Allocation in the Internet  July 1991
    
    
    
    8   Authors' Addresses
    
    
    
                  Richard P. Colella
                  National Institute of Standards & Technology
                  Building 225/Room B217
                  Gaithersburg, MD 20899
    
    
                  Phone: (301) 975-3627
                  EMail:  colella@osi3.ncsl.nist.gov
    
    
    
                  EllaP. Gardner
                  The MITRE Corporation
                  7525 Colshire Drive
                  McLean, VA 22102
    
    
                  Phone: (703) 883-5826
                  EMail:  epg@gateway.mitre.org
    
    
    
                  Ross Callon
                  c/o Digital Equipment Corporation, 1-2/A19
                  550 King Street
                  Littleton, MA 01460-1289
    
    
                  Phone: (508) 486-5009
                  Email:  Callon@bigfut.enet.dec.com
    
    
    
    9   Acknowledgments
    
    
    
    The authors would like to thank the members of the IETF OSI-NSAP
    Working Group for the helpful suggestions made during the writing of
    this paper.
    
    
    
    
    
    
    
    Colella, Gardner, & Callon                                    [Page 39]
    
    
    
    
    
    RFC 1237  Guidelines for OSI NSAP Allocation in the Internet  July 1991
    
    
    
    A   Administration of NSAPs
    
    
    
    NSAPs represent the endpoints of communication through the Network
    Layer and must be globally unique [5]. Addendum 2 to ISO8348 defines
    the semantics of the NSAP and the abstract syntaxes in which the
    semantics of the Network address can be expressed [14].
    
    
    The NSAP consists of the initial domain part (IDP) and the domain
    specific part (DSP). The initial domain part of the NSAP consists
    of an authority and format identifier (AFI) and an initial domain
    identifier (IDI). The AFI specifies the format of the IDI, the network
    addressing authority responsible for allocating values of the IDI,
    and the abstract syntax of the DSP. The IDI specifies the addressing
    subdomain from which values of the DSP are allocated and the network
    addressing authority responsible for allocating values of the DSP from
    that domain. The structure and semantics of the DSP are determined by
    the authority identified by the IDI. Figure 3 shows the NSAP address
    structure.
                  _______________
                  !_____IDP_____!________________________________
                  !__AFI_!_IDI__!______________DSP______________!
    
    
                      IDP  Initial Domain Part
                      AFI  Authority and Format Identifier
                      IDI  Initial Domain Identifier
                      DSP  Domain Specific Part
    
                        Figure 3: NSAP address structure.
    
    
    The global network addressing domain consists of all the NSAP
    addresses in the OSI environment. Within that environment, seven
    second-level addressing domains and corresponding IDI formats are
    described in ISO8348/Addendum 2:
    
       * X.121 for public data networks
    
       * F.69 for telex
    
       * E.163 for the public switched telephone network numbers
    
       * E.164 for ISDN numbers
    
       * ISO Data Country Code (DCC), allocated according to ISO3166 [9]
    
    
    
    Colella, Gardner, & Callon                                    [Page 40]
    
    
    
    
    
    RFC 1237  Guidelines for OSI NSAP Allocation in the Internet  July 1991
    
    
    
       * ISO International Code Designator (ICD), allocated according to
         ISO6523 [10]
    
       * Local to accommodate the coexistence of OSI and non-OSI network
         addressing schemes.
    
    
    For OSI networks in the U.S., portions of the ICD subdomain are
    available for use through the U.S. Government, and the DCC subdo-
    main is available for use through The American National Standards
    Institute (ANSI). The British Standards Institute is the registration
    authority for the ICD subdomain, and has registered four IDIs for
    the U.S. Government: those used for GOSIP, DoD, OSINET, and the OSI
    Implementors Workshop. ANSI, as the U.S. ISO Member Body, is the
    registration authority for the DCC domain in the United States. (The
    U.S. Government is registered as an organization by ANSI under the
    DCC, and in turn, will register object identifiers and X.400 names
    under this authority.)
    
    
    
    A.1   GOSIP Version 2 NSAPs
    
    
    
    GOSIP Version 2 makes available for government use an NSAP addressing
    subdomain with a corresponding address format as illustrated in
    Figure 2 on page 16. The ``47'' signifies that it is based on the ICD
    format and uses a binary syntax for the DSP. The 0005 is an IDI value
    which has been assigned to the U.S. Government. Although GOSIP Version
    2 NSAPs are intended primarily for U.S. government use, requests from
    non-government and non-U.S. organizations will be considered on a
    case-by-case basis.
    
    
    The format for the DSP under ICD=0005 has been established by the
    National Institute of Standards and Technology (NIST), the authority
    for the ICD=0005 domain, in GOSIP Version 2 [4] (see Figure 2,
    page 16). NIST has delegated the authority to register AA identifiers
    for GOSIP Version 2 NSAPs to the General Services Administration
    (GSA).
    
    
    Addendum 2 to ISO8348 allows a maximum length of 20 octets for the
    NSAP. The AFI of 47 occupies one octet, and the IDI of 0005 occupies
    two octets. The DSP is encoded as binary as indicated by the AFI of
    47. One octet is allocated for a DSP Format Identifier, three octets
    for an Administrative Authority identifier, two octets for Routing
    
    
    
    Colella, Gardner, & Callon                                    [Page 41]
    
    
    
    
    
    RFC 1237  Guidelines for OSI NSAP Allocation in the Internet  July 1991
    
    
    
    Domain, two octets for Area, six octets for the System Identifier,
    and one octet for the NSAP selector. Note that two octets have been
    reserved to accommodate future growth and to provide additional
    flexibility for inter-domain routing. The last seven octets of the
    GOSIP NSAP format are structured in accordance with DIS10589 [17], the
    intra-domain IS-IS routing protocol. The DSP Format Identifier (DFI)
    identifies the format of the remaining DSP structure and may be used
    in the future to identify additional DSP formats; the value 80h in the
    DFI identifies the GOSIP Version 2 NSAP structure.
    
    
    The Administrative Authority identifier names the administrative
    authority which is responsible for registration within its domain.
    The administrative authority may delegate the responsibility for
    registering areas to the routing domains, and the routing domains
    may delegate the authority to register System Identifiers to the
    areas. The main responsibility of a registration authority at any
    level of the addressing hierarchy is to assure that names of entities
    are unambiguous, i.e., no two entities have the same name. The
    registration authority is also responsible for advertising the names.
    
    
    A routing domain is a set of end systems and intermediate systems
    which operate according to the same routing procedures and is wholly
    contained within a single administrative domain. An area uniquely
    identifies a subdomain of the routing domain. The system identifier
    names a unique system within an area. The value of the system
    field may be a physical address (SNPA) or a logical value. Address
    resolution between the NSAP and the SNPA may be accomplished by an ES-
    IS protocol [13], locally administered tables, or mapping functions.
    The NSAP selector field identifies the end user of the network layer
    service, i.e., a transport layer entity.
    
    
    
    A.1.1   Application for Administrative Authority Identifiers
    
    
    
    The steps required for an agency to acquire an NSAP Administrative
    Authority identifier under ICD=0005 from GSA will be provided in the
    updated GOSIP users' guide for Version 2 [2] and are given below.
    Requests from non-government and non-U.S. organizations should
    originate from a senior official, such as a vice-president or chief
    operating officer.
    
    
    
    
    
    
    Colella, Gardner, & Callon                                    [Page 42]
    
    
    
    
    
    RFC 1237  Guidelines for OSI NSAP Allocation in the Internet  July 1991
    
    
    
       * Identify all end systems, intermediate systems, subnetworks, and
         their topological and administrative relationships.
    
       * Designate one individual (usually the agency head) within an
         agency to authorize all registration requests from that agency
         (NOTE: All agency requests must pass through this individual).
    
       * Send a letter on agency letterhead and signed by the agency head
         to GSA:
    
    
                Telecommunications Customer Requirements Office
                U. S. General Services Administration
                Information Resource Management Service
                Office of Telecommunications Services
                18th and F Streets, N.W.
                Washington, DC 20405
    
                Fax 202 208-5555
    
    
         The letter should contain the following information:
    
           - Requestor's Name and Title,
    
           - Organization,
    
           - Postal Address,
    
           - Telephone and Fax Numbers,
    
           - Electronic Mail Address(es), and,
    
           - Reason Needed (one or two paragraphs explaining the intended
             use).
    
    
       * If accepted, GSA will send a return letter to the agency head
         indicating the NSAP Administrative Authority identifier as-
         signed,effective date of registration, and any other pertinent
         information.
    
       * If rejected, GSA will send a letter to the agency head explaining
         the reason for rejection.
    
       * Each Authority will administer its own subaddress space in
         accordance with the procedures set forth by the GSA in Section
         A.1.2.
    
    
    
    Colella, Gardner, & Callon                                    [Page 43]
    
    
    
    
    
    RFC 1237  Guidelines for OSI NSAP Allocation in the Internet  July 1991
    
    
    
       * The GSA will maintain, publicize, and disseminate the assigned
         values of Administrative Authority identifiers unless specifically
         requested by an agency not to do so.
    
    
    
    A.1.2   Guidelines for NSAP Assignment
    
    
    
    Recommendations which should be followed by an administrative
    authority in making NSAP assignments are given below.
    
    
    
       * The authority should determine the degree of structure of the
         DSP under its control. Further delegation of address assignment
         authority (resulting in additional levels of hierarchy in the
         NSAP) may be desired.
    
       * The authority should make sure that portions of NSAPs that it
         specifies are unique, current, and accurate.
    
       * The authority should ensure that procedures exist for dissemi-
         nating NSAPs to routing domains and to areas within each routing
         domain.
    
       * The systems administrator must determine whether a logical or a
         physical address should be used in the System Identifier field
         (Figure2, page 16). An example of a physical address is a 48-bit
         MAC address; a logical address is merely a number that meets the
         uniqueness requirements for the System Identifier field, but bears
         no relationship to an address on a physical subnetwork.
    
       * The network address itself contains no routing information [15].
         Information that enables next-hop determination based on NSAPs
         is gathered and maintained by each intermediate system through
         routing protocol exchanges.
    
       * GOSIP end systems and intermediate systems in federal agencies
         must be capable of routing information correctly to and from any
         subdomain defined by ISO8348/Addendum 2.
    
       * An agency may request the assignment of more than one Administra-
         tive Authority identifier. The particular use of each should be
         specified.
    
    
    
    
    
    Colella, Gardner, & Callon                                    [Page 44]
    
    
    
    
    
    RFC 1237  Guidelines for OSI NSAP Allocation in the Internet  July 1991
    
    
    
    A.2   Data Country Code NSAPs
    
    
    
    NSAPs from the Data Country Code (DCC) subdomain will also be common
    in the international Internet. Currently, there is a draft proposed
    American National Standard (dpANS) in the U.S. for the DSP structure
    under DCC=840 [1]. Subsequent to an upcoming ANSI X3 Committee ballot,
    the dpANS will be distributed for public comment.
    
    
    In the dpANS, the DSP structure is identical to that specified in
    GOSIP Version 2, with the Administrative Authority identifier replaced
    by the numeric form of the ANSI-registered organization name, as shown
    in Figure 4.
    
    
    Referring to Figure 4, when the value of the AFI is 39, the IDI
    denotes an ISO DCC and the abstract syntax of the DSP is binary
    octets. The value of the IDI for the U.S. is 840, the three-digit
    numeric code for the United States under ISO3166 [9]. The numeric
    form of organization name is analogous to the Administrative Authority
    identifier in the GOSIP Version 2 NSAP.
    
                    ______________
                    !<--_IDP_-->_!_____________________________________
                    !AFI_!__IDI__!____________<--_DSP_-->_____________!
                    !_39_!__840__!DFI_!_ORG_!Rsvd_!RD_!Area_!_ID_!Sel_!
             octets !_1__!___2___!_1__!__3__!_2___!_2_!__2__!_6__!_1__!
    
    
    
                     IDP   Initial Domain Part
                     AFI   Authority and Format Identifier
                     IDI   Initial Domain Identifier
                     DSP   Domain Specific Part
                     DFI   DSP Format Identifier
                     ORG   Organization Name (numeric form)
                     Rsvd  Reserved
                     RD    Routing Domain Identifier
                     Area  Area Identifier
                     ID    System Identifier
                     SEL   NSAP Selector
    
    
         Figure 4: NSAP format for DCC=840 as proposed in ANSI X3S3.3.
    
    
    
    
    
    Colella, Gardner, & Callon                                    [Page 45]
    
    
    
    
    
    RFC 1237  Guidelines for OSI NSAP Allocation in the Internet  July 1991
    
    
    
    A.2.1   Application for Numeric Organization Name
    
    
    
    The procedures for registration of numeric organization names in
    the U.S. have been defined and are operational. To register a
    numeric organization name, the applicant must submit a request for
    registration and the $1,000 (U.S.) fee to the registration authority,
    the American National Standards Institute (ANSI). ANSI will register a
    numeric value, along with the information supplied for registration,
    in the registration database. The registration information will be
    sent to the applicant within ten working days. The values for numeric
    organization names are assigned beginning at 113527.
    
    
    The application form for registering a numeric organization name may
    be obtained from the ANSI Registration Coordinator at the following
    address:
    
    
               Registration Coordinator
               American National Standards Institute
               11 West 42nd Street
               New York, NY 10036
               +1 212 642 4976 (tel)
               +1 212 398 0023 (fax)
    
    
    Once an organization has registered with ANSI, it becomes a registra-
    tion authority itself. In turn, it may delegate registration authority
    to routing domains, and these may make further delegations, for in-
    stance, from routing domains to areas. Again, the responsibilities of
    each Registration Authority are to assure that NSAPs within the domain
    are unambiguous and to advertise them as applicable.
    
    
    
    A.3   Summary of Administrative Requirements
    
    
    
    NSAPs must be globally unique, and an organization may assure this
    uniqueness for OSI addresses in two ways. The organization may
    apply to GSA for an Administrative Authority identifier. Although
    registration of Administrative Authority identifiers by GSA primarily
    serves U.S. Government agencies, requests for non-Government and
    non-U.S. organizations will be considered on a case-by-case basis.
    Alternatively, the organization may apply to ANSI for a numeric
    
    
    
    Colella, Gardner, & Callon                                    [Page 46]
    
    
    
    
    
    RFC 1237  Guidelines for OSI NSAP Allocation in the Internet  July 1991
    
    
    
    organization name. In either case, the organization becomes the
    registration authority for its domain and can register NSAPs or
    delegate the authority to do so.
    
    
    In the case of GOSIP Version 2 NSAPs, the complete DSP structure is
    given in GOSIP Version 2. For ANSI DCC-based NSAPs, there is a draft
    proposed American National Standard that specifies the DSP structure
    under DCC=840. The dpANS specifies a DSP structure that is identical
    to that specified in GOSIP Version 2.
    
    
    
    References
    
    
    
      [1] ANSI. American National Standard for the Structure and Semantics
          of the Domain Specific Part (DSP) of the OSI Network Service
          Access Point (NSAP) Address.  Draft Proposed American National
          Standard, 1991 (pending final approval by ANSI).
    
    
      [2] Tim Boland.  Government Open Systems Interconnection Profile
          Users' Guide Version 2 [DRAFT].  NIST Special Publication,
          National Institute of Standards and Technology, Computer Systems
          Laboratory, Gaithersburg, MD, June 1991.
    
    
      [3] ECMA. Inter-Domain Routeing.  Technical Report 50, ISO/IEC JTC 1,
          Switzerland, 1989.
    
    
      [4] GOSIP Advanced Requirements Group.  Government Open Systems
          Interconnection Profile (GOSIP) Version 2.  Federal Information
          Processing Standard 146-1, U.S. Department of Commerce, National
          Institute of Standards and Technology, Gaithersburg, MD, April
          1991.
    
    
      [5] Christine Hemrick.  The OSI Network Layer Addressing Scheme, Its
          Implications, and Considerations for Implementation. NTIA Report
          85-186, U.S. Department of Commerce, National Telecommunications
          and Information Administration, 1985.
    
    
      [6] ISO. Addendum to the Network Service Definition Covering Network
          Layer Addressing.  RFC 941,Network Working Group, April 1985.
    
    
    
    Colella, Gardner, & Callon                                    [Page 47]
    
    
    
    
    
    RFC 1237  Guidelines for OSI NSAP Allocation in the Internet  July 1991
    
    
    
      [7] ISO. End System to Intermediate System Routing Exchange Protocol
          for use in conjunction with ISO 8473.  RFC 995, Network Working
          Group, April 1986.
    
      [8] ISO. Final Text of DIS 8473, Protocol for Providing the
          Connectionless-mode Network Service.  RFC 994, Network Working
          Group, March 1986.
    
      [9] ISO/IEC.  Codes for the Representation of Names of Countries.
          International Standard 3166, ISO/IEC JTC 1, Switzerland, 1984.
    
     [10] ISO/IEC.  Data Interchange - Structures for the Identification
          of Organization.  International Standard 6523, ISO/IEC JTC 1,
          Switzerland, 1984.
    
     [11] ISO/IEC.  Information Processing Systems - Open Systems Intercon-
          nection- Basic Reference Model.  International Standard 7498,
          ISO/IEC JTC 1, Switzerland, 1984.
    
     [12] ISO/IEC.  Protocol for Providing the Connectionless-mode Network
          Service.  International Standard 8473, ISO/IEC JTC 1, Switzerland,
          1986.
    
     [13] ISO/IEC.  End System to Intermediate System Routing Exchange
          Protocol for use in Conjunction with the Protocol for the Provi-
          sion of the Connectionless-mode Network Service. International
          Standard 9542, ISO/IEC JTC 1, Switzerland, 1987.
    
     [14] ISO/IEC.  Information Processing Systems -- Data Communications
          -- Network Service Definition Addendum 2: Network Layer Address-
          ing. International Standard 8348/Addendum 2, ISO/IEC JTC 1,
          Switzerland, 1988.
    
     [15] ISO/IEC.  Information Processing Systems - OSI Reference Model
          - Part3: Naming and Addressing.  Draft International Standard
          7498-3, ISO/IEC JTC 1, Switzerland, March 1989.
    
     [16] ISO/IEC.  Information Technology - Telecommunications and
          Information Exchange Between Systems - OSI Routeing Framework.
          Technical Report 9575, ISO/IEC JTC 1, Switzerland, 1989.
    
     [17] ISO/IEC.  Intermediate System to Intermediate System Intra-Domain
          Routeing Exchange Protocol for use in Conjunction with the
    
    
    
    
    
    
    
    
    Colella, Gardner, & Callon                                    [Page 48]
    
    
    
    
    
    RFC 1237  Guidelines for OSI NSAP Allocation in the Internet  July 1991
    
    
    
          Protocol for Providing the Connectionless-mode Network Service
          (ISO 8473).  Draft International Standard 10589, ISO/IEC JTC 1,
          Switzerland, November 1990.
    
    
     [18] K. Loughheed and Y. Rekhter.  A Border Gateway Protocol (BGP).
          RFC 1105, Network Working Group, 1989.
    
    
     [19] K. Loughheed and Y. Rekhter.  A Border Router Protocol(BRP).
          Draft, Network Working Group, February 1990.
    
    
     [20] ASC X3S3.3.  Intermediate System to Intermediate System Inter-
          Domain Routeing Exchange Protocol. Working Document 90-216, ANSI,
          New York, July 1990.
    
    
    
    
    
    
    
    
    
    
    
    
    
    
    
    
    
    
    
    
    
    
    
    
    
    
    
    
    
    
    
    
    
    
    Colella, Gardner, & Callon                                    [Page 49]