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]
|